linux-kernel - Re: [PATCH] i386/x86_64 signal handler arg fixes

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4509821C.2050502@zytor.com>
Date:	Thu, 14 Sep 2006 09:23:56 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Albert Cahalan <acahalan@...il.com>
CC:	Andi Kleen <ak@...e.de>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...l.org>,
	Linus Torvalds <torvalds@...l.org>
Subject: Re: [PATCH] i386/x86_64 signal handler arg fixes

Albert Cahalan wrote:
> 
>> > Currently you remap signals. Whatever you do this for
>> > regparm(0) should also be done for regparm(3).
>>
>> Not sure I parse you here. You're asking how to fix the regparm(3)
>> case?
> 
> No. I'd thought that the two cases should match.
> The regparm(3) case should remap signals if and only if
> the regparm(0) case remaps signals. Perhaps this
> is not correct if the remapping is not needed for
> native Linux apps; I doubt iBCS stuff would ever be
> needing regparm(3) support.
> 

The two should definitely match, though.  Otherwise, life will be confusing.

> Since you plan to delete the remapping cruft from
> the regparm(0) case, then obviously it should not
> be added to the regparm(3) case.

Indeed.

	-hpa
-
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/