linux-kernel - Re: [development-gcc] Re: do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Sep 2006 22:17:16 +0200
From:	Andi Kleen <ak@...e.de>
To:	"Jan Beulich" <jbeulich@...ell.com>
Cc:	"Michael Matz" <matz@...e.de>,
	"Richard Guenther" <rguenther@...e.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [development-gcc] Re: do_exit stuck

On Monday 11 September 2006 17:37, Jan Beulich wrote:
> >>> Andi Kleen <ak@...e.de> 30.08.06 17:40 >>>
> >
> >On Wednesday 30 August 2006 17:28, Jan Beulich wrote:
> >> >Hmm, yes.  Sigh, so it's either gcc changes or binutils changes, and
> >> > none of that can be relied upon, except someone has a better idea to
> >> > identify signal frames with high enough assurance to be sensible for
> >> > debugging.
> >>
> >> The only alternative idea I have is to take into consideration the
> >> location of the return address: if it's at the default location (top of
> >> call frame), then assume this is a normal frame, in all other cases
> >> assume it's an interrupt/exception one. This will probably get a few
> >> cases wrong (where the return address is being played with), but it
> >> might be better than the current situation. Andi?
> >
> >Fine by me.
> >
> >At least it will likely be less controversal than changing all the
> > noreturns :)
>
> Here's a patch, including all that I think is necessary once we selectively
> enable (auto-detect) CONFIG_AS_CFI_SIGNAL_FRAME for newer binutils.
> It doesn't include adjustment of the printed address (i.e. for the original
> example, it'd still be kernel_math_error+0 that gets displayed, but the
> unwinder wouldn't get confused anymore.

Thanks.

Isn't a Kconfig patch missing? I don't see any place that defines 
CONFIG_AS_CFI_SIGNAL_FRAME. Actually Kconfig wouldn't 
be very good for this, so auto testing would be preferable
(like the cfi test is doing) 

BTW the tree you generated it against doesn't seem to match the latest
tree. I had to fix some rejects.

Also it would be nice if you could give a full description that could
be used as a commit message.

Other than that it looks good.

Ok maybe a one liner comment on why UNW_DEFAULT_RA does this magic.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/