Messages in this thread | | | Subject | Re: avr32: handle_signal() bug? | From | Matt Fleming <> | Date | Tue, 16 Aug 2011 10:57:28 +0100 |
| |
On Mon, 2011-08-15 at 22:55 -0700, Håvard Skinnemoen wrote: > Hi, > > Sorry for taking so long to test this.
No worries!
> On Mon, Aug 8, 2011 at 3:25 AM, Matt Fleming <matt@console-pimps.org> wrote: > > On Sun, 2011-08-07 at 10:20 -0700, Håvard Skinnemoen wrote: > >> Looks good to me. I'm not sure how to test it though...I can try to > >> build a kernel, run it on my board and see if it explodes, but I > >> suspect this bug is a lot more subtle than that. > > > > I suspect the best test would be one that makes use of SA_NODEFER. > > Something like this, > > Thanks for the test. Unfortunately, the result is the same regardless > of whether I apply the patches or not. In both cases: > > /root # ./nodefer > SIGUSR2: not blocked > SIGTERM: not blocked
Hmm.. that's interesting. I had a quick look through the rest of the code in the signal path and couldn't find anything obviously wrong. The only thing that looked suspicious is that you don't clear TIF_RESTORE_SIGMASK if you successsfully deliver a signal. Maybe try adding a clear_thread_flag(TIF_RESTORE_SIGMASK); to the success path in handle_signal() and see if you get better results? See the x86 implementation for more details.
> On my desktop, it behaves as expected: > > $ ./nodefer-pc > SIGUSR2: blocked > SIGTERM: blocked > > Your patch doesn't appear to do any harm though, and it looks correct > to me. Perhaps there's another bug lurking somewhere as well. Some > preliminary debugging makes me suspicious about libc, but I can't tell > for sure yet.
Which libc is this by the way?
-- Matt Fleming, Intel Open Source Technology Center
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |