Re: [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes

2017-07-20 Thread Eric W. Biederman
Oleg Nesterov writes: > On 07/18, Eric W. Biederman wrote: >> >> -BUG_ON((reason & __SI_MASK) != __SI_POLL); >> +BUG_ON((reason < POLL_IN) || (reason > NSIGPOLL)); > ^ > looks obviously

Re: [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes

2017-07-20 Thread Oleg Nesterov
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

[PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes

2017-07-18 Thread Eric W. Biederman
We have a weird and problematic intersection of features that when they all come together result in ambiguous siginfo values, that we can not support properly. - Supporting fcntl(F_SETSIG,...) with arbitrary valid signals. - Using positive values for POLL_IN, POLL_OUT, POLL_MSG, ..., etc that i