[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lgni7c33.fsf@xmission.com>
Date: Thu, 20 Jul 2017 21:33:52 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@...hat.com>
Cc: linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Andrei Vagin <avagin@...tuozzo.com>,
Thomas Gleixner <tglx@...utronix.de>, Greg KH <greg@...ah.com>,
Andrey Vagin <avagin@...nvz.org>,
Serge Hallyn <serge@...lyn.com>,
Pavel Emelyanov <xemul@...tuozzo.com>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
Peter Zijlstra <peterz@...radead.org>,
Willy Tarreau <w@....eu>, linux-arch@...r.kernel.org,
linux-api@...r.kernel.org,
Linux Containers <containers@...ts.linux-foundation.org>,
Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes
Oleg Nesterov <oleg@...hat.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
Powered by blists - more mailing lists