linux-kernel - Re: parsic/sh/sparc tracehook breakage when tracing signals

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:	Thu, 11 Feb 2010 19:56:03 -0500
From:	Mike Frysinger <vapier@...too.org>
To:	David Miller <davem@...emloft.net>
Cc:	linux-sh@...r.kernel.org, linux-parisc@...r.kernel.org,
	sparclinux@...r.kernel.org, roland@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: parsic/sh/sparc tracehook breakage when tracing signals

On Thursday 11 February 2010 19:39:50 David Miller wrote:
> From: Mike Frysinger <vapier@...too.org>
> > when i ported the Blackfin code to the tracehook framework, i copied a
> > latent bug from the sparc port.  trying to trace another process while
> > handling signals no longer worked (and subsequently broke some of the gdb
> > tests).
> 
> What you seem to be missing is that on Sparc TIF_SINGLESTEP will never
> be set, because it does not support hardware single step.
> 
> This thread flag is not even defined on that platform.

my point is that these arches never call ptrace_notify(SIGTRAP) from their 
signal handlers.  maybe the arch is unable to due to some port/hardware 
limitation and this is currently the expected behavior.

dont get me wrong ... i dont particularly care if your arch has a bug in it 
here.  my arch did have a bug and on the off chance that others did too, i 
thought i'd drop an e-mail to people.  if your arch is in the "limited" 
category, feel free to ignore this.
-mike

Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)