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]
Message-Id: <20080415014110.88DFA26FA5F@magilla.localdomain>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ