On Mon, 24 Jun 2013 10:10:08 +0100 James Hogan <james.hogan@xxxxxxxxxx> wrote: > On 22/06/13 20:09, Oleg Nesterov wrote: > > On 06/21, David Daney wrote: > >> I am proposing that we just reduce the number of usable signals such > >> that existing libc status checking macros/functions don't change in any > >> way. > > > > And I fully agree! Absolutely, sorry for confusion. > > > > > > What I tried to say, _if_ we change the ABI instead, lets make this > > change sane. > > I agree that this approach isn't very nice (I was really just trying to > explore the options) and reducing the number of signals is nicer. But is > anybody here confident enough that the number of signals changing under > the feet of existing binaries/libc won't actually break anything real? > I.e. anything trying to use SIGRTMAX() to get a lower priority signal. Meanwhile, unprivileged users can make a MIPS kernel go BUG. How much of a problem is this? Obviously less of a problem with MIPS than it would be with some other CPU types, but I'd imagine it's still awkward in some environments. If this _is_ considered a problem, can we think of some nasty little hack which at least makes the effects less damaging, which we can also put into -stable kernels?
