linux-kernel - Re: getter PTRACE_GETSIGINFO should not modify anything [Re: [PATCH 11/11] ptrace: implement group stop notification for ptracer]

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]

Message-ID: <20110516125615.GW23665@htj.dyndns.org>
Date:	Mon, 16 May 2011 14:56:15 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	oleg@...hat.com, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: getter PTRACE_GETSIGINFO should not modify anything  [Re:
 [PATCH 11/11] ptrace: implement group stop notification for ptracer]

Hello,

On Mon, May 16, 2011 at 02:17:11PM +0200, Jan Kratochvil wrote:
> On Mon, 16 May 2011 10:43:50 +0200, Tejun Heo wrote:
> > There's distinction between "broken" and "ugly".  If it's ugly but
> > functional, you don't need to "fix" it.
> 
> The final goal is the user experience (such as the users of GDB), nothing else
> matters.  If it is so "ugly" the userland developers fail to use it the
> project as a whole still broken.

To me, it seems the breakage and mountain of workarounds come more
from lack of proper documentation plus the current ptrace + job
control + signal interaction which is really broken.  For example, it
seems nobody really understood how group stop and ptrace interacts and
the different types of traps being used - strace(2) thought the same
signal was being delivered twice.

> > So, I'm gonna push back quite a bit unless it actually compromises
> > functionality or correctness.
> 
> With your position "if it is workaroundable in userland let's make the new
> kernel API broken again" it no longer makes sense to comment on it.  Yes,
> everything is workaroundable but that is usually not the goal of new APIs.

First of all, let's distinguish "broken" and "ugly" properly and
please keep in mind that what's broken is broken but beauty is in the
eyes of the beholder.

Secondly, I'm listening to your comments and will incorporate them, so
please don't give up so easily.

Thank you.

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