linux-kernel - Re: [PATCH 2/2] ptrace children revamp

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

Date:	Mon, 14 Apr 2008 18:41:10 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ptrace children revamp

> Sorry for delay!

There's no need to apologize!  I heartily appreciate all your help on this.

> Agreed. I never understood why we need __WNOTHREAD. The same for
> ->pdeath_signal in its current "per-thread" form. I think it would be
> very nice to kill them both (or send the ->pdeath_signal when the whole
> process exits). Then we can place all childrens on one signal->children
> list. But this is a bit off-topic for now.

I'm in complete agreement here, but indeed it's to be considered later.
I never understood pdeath_signal, but I recall someone piping up before
and saying it really was used with its current semantics, so go figure.
(Btw, we can move ->children and still keep __WNOTHREAD compatibility.
It just has to check p->parent == current for __WNOTHREAD.  We can do
that if we determine that __WNOTHREAD is purely for anal backward
compatibility, and noone cares about the performance difference of
__WNOTHREAD calls only looping over a shorter list.)

> I think the 4th patch has a small problem,

Thanks.  I think we're moving on to the other variant of the patch now,
so I won't worry about fixing up the version we're abandoning.  

> Yes! I thought about this too. Actually, I was very sure that this is your
> plan from the the very beginning ;)

You were quite right!  I somehow tricked myself into trying something
inferior first.  Silly me.  :-)

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/