Petr Mladek | 28 Jul 16:39 2015

[RFC PATCH 00/14] kthread: Use kthread worker API more widely

Kthreads are currently implemented as an infinite loop. Each
has its own variant of checks for terminating, freezing,
awakening. Sometimes, it is hard to say if they are done
correctly. They are also harder to maintain if there is
a generic problem found in the area.

I have proposed a so-called kthread iterant API to improve the situation,
see The RFC opened and/or answered
several questions.

This RFC is reaction on Tejun's suggestion to use the existing kthread
worker API instead of a new one, see
I wanted to give it a try.

Structure of this patch set:

1st..6th patches: improve the existing kthread worker API

7th, 8th, 11th patches: converts three kthreads into the new API,
     namely: RCU gp kthreas, khugepaged, my favorite ring buffer

12th..14th patches: show how we could further improve the API

9th, 10th patches:  do some further clean up of the ring buffer
     benchmark; they allow easier conversion into the new API;
     but they might be applied independently

(Continue reading)

Shuah Khan | 27 Jul 17:01 2015

[GIT PULL] Kselftest fixes for 4.2-rc5

Hi Linus,

Please pull the following Kselftest fixes for 4.2-rc5

-- Shuah

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

  Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:


for you to fetch changes up to fee50f3c8427aacabfb603229bf0a9056c3f2638:

  selftests/futex: Fix futex_cmp_requeue_pi() error handling (2015-07-20
18:29:38 -0600)


Kselftest fixes for 4.2-rc5

Darren Hart (1):
      selftests/futex: Fix futex_cmp_requeue_pi() error handling

(Continue reading)

Michael Kerrisk (man-pages | 27 Jul 16:44 2015

Re: Next round: revised futex(2) man page for review

On 07/27/2015 04:17 PM, Heinrich Schuchardt wrote:
> instruction. A thread maybe unable
> to << missing word
> acquire a lock because it is
> already acquired by another thread. It then may pass the lock's
> flag as futex word and the value representing the acquired state
> as the expected value to a futex() wait operation.

Thanks, Heinrich. Fixed.



Mark Damion | 27 Jul 11:48 2015


Attention: Email ID Owner RE: 2000 - 2015 SCAM VICTIM'S COMPENSATION

The International Monetary Fund (IMF) is compensating all the scam
victims and your email address was found in the scam victim's list.
This Western Union office has been fully mandated by the IMF to
transfer your compensation to you via Western Union® Money Transfer.
However, we have concluded to affect your own payment through Western
Union® Money Transfer, $5,000 twice daily until the total sum of
$1.800.000 Million is completely transferred to you. We can not be
able to send the payment with your email address alone; thereby we
need your information as to where we will be sending the funds, such

Receiver’s name:................... (Your Full Name)
Phone  number:...................
Copy of your ID ..................
Sex ....................
Age ......................

Reply back to this E-mail: (markdamion46@...) with your full
information. Note that your payment files will be returned to the IMF
within 72 hours if we did not hear from you, this instruction was
given by general official of IMF Benin. We will start the transfer as
soon as we received your information.

Much Oblige,
Mr.Mark Damion
(Continue reading)

Yann Cantin | 25 Jul 20:48 2015

[RFC ebeam PATCH v2 0/2] Add a new USB eBeam input driver


New USB input driver for eBeam devices.

Notable stuff :
- need userspace gui tool for calibration (
- This driver breaks Luidia's proprietary application suite.

Patch 1 to blacklist the devices for hid generic-usb.

Patch 2 is the actual driver.

Changes :
RFC : move usb id definitions out of ebeam.c
RFC : Fix ABI documentation

Thanks for your help.

Yann Cantin (2):
hid: Blacklist eBeam devices
input: misc: New USB eBeam input driver

Documentation/ABI/testing/sysfs-driver-ebeam |  53 ++
drivers/hid/hid-core.c                       |   6 +
drivers/hid/hid-ids.h                        |   6 +
drivers/input/misc/Kconfig                   |  22 +
drivers/input/misc/Makefile                  |   1 +
drivers/input/misc/ebeam.c                   | 759 +++++++++++++++++++++++++++
6 files changed, 847 insertions(+)
(Continue reading)

Masami Hiramatsu | 25 Jul 03:13 2015

[PATCH] kselftests/ftrace : Add event trigger testcases

This adds simple event trigger testcases for ftracetest,
which covers following triggers.
 - traceon-traceoff trigger
 - enable/disable_event trigger
 - snapshot trigger
 - stacktrace trigger
 - trigger filters

Signed-off-by: Masami Hiramatsu <>
Cc: Steven Rostedt <rostedt@...>
Cc: Ingo Molnar <mingo@...>
Cc: Shuah Khan <shuahkh@...>
Cc: Namhyung Kim <namhyung@...>
Cc: Tom Zanussi <tom.zanussi@...>
 tools/testing/selftests/ftrace/test.d/functions    |    9 +++
 .../ftrace/test.d/trigger/    |   64 ++++++++++++++++++++
 .../ftrace/test.d/trigger/        |   59 ++++++++++++++++++
 .../ftrace/test.d/trigger/      |   56 ++++++++++++++++++
 .../ftrace/test.d/trigger/    |   53 +++++++++++++++++
 .../ftrace/test.d/trigger/    |   58 ++++++++++++++++++
 6 files changed, 299 insertions(+)
 create mode 100644 tools/testing/selftests/ftrace/test.d/trigger/
 create mode 100644 tools/testing/selftests/ftrace/test.d/trigger/
 create mode 100644 tools/testing/selftests/ftrace/test.d/trigger/
 create mode 100644 tools/testing/selftests/ftrace/test.d/trigger/
 create mode 100644 tools/testing/selftests/ftrace/test.d/trigger/

diff --git a/tools/testing/selftests/ftrace/test.d/functions b/tools/testing/selftests/ftrace/test.d/functions
index 5d8cd06..36ca18e 100644
(Continue reading)

Stephen Chandler Paul | 21 Jul 21:07 2015

[RFC] ps2emu - PS/2 emulation module

Hi! So, following this is a patch to add the ps2emu module to the kernel. This
module basically allows for us to create virtual PS/2 devices and control them
from userspace. With this, we can do useful things such as playing back
recordings of PS/2 devices in a similar manner to evemu-replay and hid-replay.
This lets us debug PS/2 devices that we may not have physical access to, such
as laptop touchpads. This is a huge help when we receive bug reports for devices that
we can't get access to. We've already used this module to assist with fixing
bugs[1] where we needed to be able to replicate the device on a lower level then
we could with evemu-replay or hid-replay. This module could also come into use
when trying to debug the initialization process of devices, along with testing
for regressions with various devices.

The module itself creates a character device at /dev/ps2emu, which userspace
applications can connect to and use to send/receive data straight through the
serio driver. It doesn't need to do much more then that, so it's not a very
large driver. There is a very basic command protocol used for this which has
room for potentially being extended upon in the future if the situation calls
for it.

Right now we make use of this module with the ps2emu userland tools[2] that I've
wrote recently. Recording of PS/2 devices is done by enabling the debugging
output from i8042, triggering a rescan of the PS/2 ports, and doing some clever
trimming of data to remove anything that goes across the i8042 chip that isn't
relevant to the PS/2 protocol. The replay application is pretty simple, and just
sends all of the events from the log through /dev/ps2emu. No additional
processing of the log has to be done, making the replay process very trivial so
long as the behavior of the driver in question is the same as it was when the
recording was done. This also means any bugs encountered during the recording
are easy to reproduce when we play the device back, and we don't need to be
concerned about a virtual device potentially exhibiting different behaviors in
(Continue reading)

Darren Hart | 21 Jul 00:48 2015

[PATCH] selftests/futex: Fix futex_cmp_requeue_pi() error handling

An earlier (pre-kernel-integration) refactoring of this code mistakenly
replaced the error condition, <, with a >. Use < to detect an error as
opposed to a successful requeue or signal race.

Reported-by: David Binderman <dcb314@...>
Cc: Shuah Khan <shuahkh@...>
Signed-off-by: Darren Hart <dvhart@...>
 .../selftests/futex/functional/futex_requeue_pi_signal_restart.c        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c b/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
index 7f0c756..3d7dc6a 100644
--- a/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
 <at>  <at>  -191,7 +191,7  <at>  <at>  int main(int argc, char *argv[])
 		if (res > 0) {
 			atomic_set(&requeued, 1);
-		} else if (res > 0) {
+		} else if (res < 0) {
 			error("FUTEX_CMP_REQUEUE_PI failed\n", errno);
 			ret = RET_ERROR;


Darren Hart
Intel Open Source Technology Center
(Continue reading)

Andy Lutomirski | 20 Jul 23:09 2015

Re: [RFC PATCH] getcpu_cache system call: caching current CPU number (x86)

On Mon, Jul 20, 2015 at 1:50 PM, Linus Torvalds
<torvalds@...> wrote:
> On Jul 20, 2015 10:41 AM, "Andy Lutomirski" <luto@...> wrote:
>> glibc will have to expose a way to turn it off, I guess. (ELF flag?)
> Ugh. That just sounds nasty.
> I'm on mobile, so can't check right now, but don't we already have a per-cpu
> gdt? We could just make a very simple rule:
> - create a single gdt entry with a segment that is per-cpu and points to one
> single read-only page in kernel space that contains the virtual address of
> that segment in vmalloc space (and maybe we can have the CPU number there
> somewhere, and extend it to something else later)

Annoying problem one: the segment base field is only 32 bits in the GDT.

> - make the rule be that if you hold that segment in %fs or %gs in your user
> space state, it gets cleared when the thread is scheduled out.

That sounds a bit evil, but okay.

> What does this get you?
> It basically means that:
(Continue reading)

Yann Cantin | 20 Jul 23:03 2015

[RFC ebeam PATCH 0/3] new USB eBeam input driver


New USB input driver for eBeam devices.

Currently supported (tested) :
- Luidia eBeam classic projection and edge projection models
- Nec "interactive solution" NP01Wi1 & NP01Wi2 accessories.

Patch 1 to blacklist the devices for hid generic-usb.

Patch 2 is the actual driver.

Notable stuff :
- use div64_s64 for portable 64/64-bits divisions.
- 13 sysfs custom files : 9 values for the transformation matrix,
  4 for xy ranges and a calibration trigger.
- need userspace gui tool for calibration (

Side notes :
- The module run fine since 3.3.6, both x86_32 and 64.
- Already reviewed in 2012 and 2013, but i have'nt pushed for inclusion.
- The only recent change is switching to non world-writable sysfs files.
- There is a proprietary application suite based on libusb, hope it won't
  break with this driver.

Thanks for your help.

David Binderman | 20 Jul 11:26 2015

[linux-4.2-rc3/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c:194: bad if condition ?


(style) Expression is always false because 'else if' condition matches previous condition at line 191.

Source code is

        if (res> 0) {
            atomic_set(&requeued, 1);
        } else if (res> 0) {


David Binderman

To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@...
More majordomo info at