On 01/19/2015 11:45 AM, Thomas Gleixner wrote:

On Fri, 16 Jan 2015, Darren Hart wrote:

quoted

On 1/16/15, 12:54 PM, "Michael Kerrisk (man-pages)"
[off-list ref] wrote:

quoted

On 01/16/2015 04:20 PM, Thomas Gleixner wrote:

quoted

On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:

quoted

Hello Thomas,

On 01/15/2015 11:23 PM, Thomas Gleixner wrote:

quoted

On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:

quoted

quoted

[EINVAL] uaddr equal uaddr2. Requeue to same futex.

??? I added this, but does this error not occur only for PI requeues?

It's equally wrong for normal futexes. And its actually the same code
checking for this for all variants.

I don't understand "equally wrong" in your reply, I'm sorry. Do you
mean:

a) This error text should be there for both normal and PI requeues

It is there for both. The requeue code has that check independent of
the requeue type (normal/pi). It never makes sense to requeue
something to itself whether normal or pi futex. We added this for PI,
because there it is harmful, but we did not special case it. So normal
futexes get the same treatment.

Hello Thomas, 

Color me stupid, but I can't see this in futex_requeue(). Where is that
check that is "independent of the requeue type (normal/pi)"?

When I look through futex_requeue(), all the likely looking sources
of EINVAL are governed by a check on the 'requeue_pi' argument.

Right, in the non-PI case, I believe there are valid use cases: move to
the back of the FIFO, for example (OK, maybe the only example?). Both
tests ensuring uaddr1 != uaddr2 are under the requeue_pi conditional
block. The second compares the keys in case they are not FUTEX_PRIVATE
(uaddrs would be different, but still the same backing store).

Thomas, am I missing a test for this someplace else?

No, I had a short look at the code misread it. So, yes, it's a valid
operation for the non PI case. Sorry for the confusion.

Thanks for the confirmation, Thomas. Page updated to remove 
FUTEX_CMP_REQUEUE from that error case.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/