lkml.org 
[lkml]   [2010]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: situation with signals
On 9/24/2010 9:33 AM, Arnd Bergmann wrote:
> On Friday 24 September 2010, Al Viro wrote:
>> There are several interesting issues in arch/*/*/*signal* (besides
>> shoggoths starting to show up when one reads that code) and I'd been crawling
>> through that area for the last few weeks. Here are more or less common
>> issues; there are really arch-specific bugs (e.g. roothole on frv that
>> used to allow reading kernel memory by setting the right sa_handler), but
>> that's a separate story.
>
> I still plan to make a counterpart to the asm-generic headers with an
> example architecture that new architectures can copy from. Signal handling
> is one of the areas that I have very limited understanding of. Did you
> encounter any architecture that basically gets signal handling right and that
> can serve as a positive example to others?
>
> arch/tile/kernel/signal.c was the last one that got merged and I tried
> to direct the maintainer in the right direction as much as I could, but
> there are a lot of things I didn't know about.

(Sorry for the belated reply.)

I set aside this thread to look at when I had a minute, and I believe there
is just one of the signal issues present in the tile code. The fix is to
reset regs->fault to something other than the "syscall" fault type when
exiting from do_signal(), so I'll submit that up for 2.6.37 shortly.

Otherwise I think tile is doing things right, though I admit, the signal
support is pretty deep magic generally.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com


\
 
 \ /
  Last update: 2010-10-27 23:05    [W:0.079 / U:2.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site