lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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