lkml.org 
[lkml]   [2017]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes


Oleg Nesterov <oleg@redhat.com> writes:

> On 07/18, Eric W. Biederman wrote:
>>
>> - BUG_ON((reason & __SI_MASK) != __SI_POLL);
>> + BUG_ON((reason < POLL_IN) || (reason > NSIGPOLL));
> ^^^^^^^^^^^^^^^^^
> looks obviously wrong? Say, POLL_IN is obviously > NSIGPOLL == 6.

Strictly speaking that code is wrong until the next patch
when I remove __SI_POLL. That is my mistake.

When the values are not their messed up internal kernel variants
the code works fine and makes sense.

#define POLL_IN 1 /* data input available */
#define POLL_OUT 2 /* output buffers available */
#define POLL_MSG 3 /* input message available */
#define POLL_ERR 4 /* i/o error */
#define POLL_PRI 5 /* high priority input available */
#define POLL_HUP 6 /* device disconnected */
#define NSIGPOLL 6

> Probably you meant
>
> BUG_ON((reason < POLL_IN) || (reason - POLL_IN > NSIGPOLL)
>
> ?
>
> but this contradicts with the next line:

>> if (reason - POLL_IN >= NSIGPOLL)
>> si.si_band = ~0L;
>
> confused...

I am mystified why we test for a condition that we have been bugging on
for ages.

Eric




\
 
 \ /
  Last update: 2017-07-21 04:42    [W:0.160 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site