linux-kernel - Re: [PATCH 16/16] ptrace: remove the extra wake_up_process() from ptrace

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20101207001043.13BCE400CE@magilla.sf.frob.com>
Date:	Mon,  6 Dec 2010 16:10:43 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	oleg@...hat.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	rjw@...k.pl, jan.kratochvil@...hat.com
Subject: Re: [PATCH 16/16] ptrace: remove the extra wake_up_process() from ptrace_detach()

The plain wake_up_process was certainly wrong from the beginning.

We were conservative about changing it because of the difficulty of
chasing all the corners where userland debuggers' behavior might be
made to regress when it had been reliable in practice before (even
if not always in theory, such as possible races that didn't bite in
reality).  The userland code has gone to many contortions to cope
with how the kernel behaved in the past, whether or not that
behavior ever made any good sense.

For that sort of reason, none of this stuff should change at all in
a -stable kernel, nor late in a release cycle.

For new kernels, I think changing the behavior in the direction of
something that can actually be described is OK as long as userland
debugger maintainers like Jan agree to the new behavior and that the
behavior really and truly does follow an articulated set of rules
that the kernel and userland sides agree to.

Thanks,
Roland
--
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/