Messages in this thread | | | From | (Eric W. Biederman) | Date | Thu, 20 Jul 2017 21:33:52 -0500 | Subject | Re: [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
| |