Re: [PATCH v3] kernel/signal.c: fix BUG_ON with SIG128 (MIPS)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/21/2013 01:22 PM, Oleg Nesterov wrote:
On 06/21, David Daney wrote:

On 06/21/2013 06:39 AM, James Hogan wrote:
Therefore add sig_to_exitcode() and exitcode_to_sig() functions which
map signal numbers > 126 to exit code 126 and puts the remainder (i.e.
sig - 126) in higher bits. This allows WIFSIGNALED() to return true for
both SIG127 and SIG128, and allows WTERMSIG to be later updated to read
the correct signal number for SIG127 and SIG128.

I really hate this approach.

Can we just change the ABI to reduce the number of signals so that all
the standard C library wait related macros don't have to be changed?

Think about it, any user space program using signal numbers 127 and 128
doesn't work correctly as things exist today, so removing those two will
be no great loss.

Oh, I agree.

Besides, this changes ABI anyway. And if we change it we can do this in
a more clean way, afaics. MIPS should simply use 2 bytes in exit_code for
signal number.

Wouldn't that break *all* existing programs that use signals? Perhaps I misunderstand what you are suggesting.

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.

 Yes, this means we need replace 0x80/0x7f in exit.c by
ifdef'ed numbers. And yes, this means that WIFSIGNALED/etc should be
updated too, but this is also true with this patch.

Oleg.





[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux