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: <1297778450.2413.11.camel@twins>
Date:	Tue, 15 Feb 2011 15:00:50 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	"Kenneth Albanowski (Palm GBU)" <Kenneth.Albanowski@...m.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Jakub Jelinek <jakub@...hat.com>,
	Andreas Schwab <schwab@...ux-m68k.org>
Subject: Re: Question about clearing of tsk->robust_list in clone

On Tue, 2011-02-15 at 14:16 +0100, Thomas Gleixner wrote:
> 
> And I do not buy the argument about "complex glibc code" at all. glibc
> already handles it for pthread_create() so why the hell can't it
> handle it for fork() ? 

Going by comment #9 they think calling sys_set_robust_list() on every
fork() is too expensive for them, but realistically we cannot do
anything about it, ->robust_list is strictly task state.

I also think their suggestion in comment #11 (lazy state) is flawed,
what if the parent never users robust futexes, in that case the state
will indicate not to initialize the robust state for its children, again
leading to the observed wreckage.

Realistically libpthread should register an on_fork() callback to ensure
the state is properly propagated.
--
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