Re: [uml-devel] SIGSEGV and SA_NODEFER

[Blaisorblade <blaisorblade@yahoo.it>]

On Thursday 20 January 2005 01:07, you wrote:
> On Tuesday 18 January 2005 22:28, Jeff Dike wrote:
> > It turns out that caker's crashes were being caused by the lack of
> > SA_NODEFER in the SIGSEGV handler registration.
>
> As Jeff explained me on IRC, the previous patch sent about the same
> subject, actually, was correct, but not related to the caker's problem.
>
> Since Jeff explained everything on IRC (#uml) I'm just explaining it here
> for the archives.
>
> > I know I fixed this, and I have no idea where the fix went.  Do you have
> > any clue what happened to it?
>
> The SA_NODEFER flag was dropped from that call in 2.6.7-2um in the "random"
> patch, in 2.4.24-2um, and finally in
> uml-let-page-faults-always-be-delivered-immediately.patch in 2.6.9-rc2-mm1.
>
> That was compensated by adding the addition of this hunk for TT mode in
> sig_handler_common_tt() :

Are we sure it is a compensation? I started having the doubt that enabling the 
signal inside the handler is not the same thing... because otherwise we don't 
understand why the patch in 2.4 makes difference in TT mode.

Indeed, the blocking is done in the same way, but probably the timing is 
different - i.e. we unblock the signal only after unprotect_kernel_mem() in 
the new code, which somehow *makes* a difference.

I'm going to choose the SA_NODEFER instead of adding the explicit check, at 
least for 2.4. I'd do it for 2.6 too, only that I'm not too sure.

Jeff, what is your suggestion?
>         /* This is done because to allow SIGSEGV to be delivered inside a
> SEGV * handler.  This can happen in copy_user, and if SEGV is disabled, *
> the process will die.
>          */
>         if(sig == SIGSEGV)
>                 change_sig(SIGSEGV, 1);
>

> The relation is obviously hidden somehow... however I sent on the uml-devel
> list a couple of patches from after 2.4.24-1um: without them UML does not
> suffer from the Debian/hwclock crash, while it happens with them. What's
> strange is that the crash happens within TT mode, not within SKAS mode. And
> rather than a crash, it's a hang, due to an infinite number of received
> SIGSEGVs. Inside the couple of patches, there is exactly this problematic
> change.


-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel