linux-kernel - RE: Question about clearing of tsk->robust

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]

Date:	Tue, 15 Feb 2011 14:51:28 -0800
From:	"Kenneth Albanowski (Palm GBU)" <Kenneth.Albanowski@...m.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Jakub Jelinek <jakub@...hat.com>,
	Andreas Schwab <schwab@...ux-m68k.org>
Subject: RE: Question about clearing of tsk->robust_list in clone

On Tue, 15 Feb 2011, Thomas Gleixner wrote:

> The sanity checks in exit_robust_list will catch that mutex_1
> owner is not matching, but that makes it not more correct.

Yes, that's my remaining question: whether the intention was that the
owner filter would often be preventing erroneous unlocks, or whether
there should never be an inappropriate list in normal usage. The owner
check does seem sufficient to prevent mayhem if the list pointer is
copied to the child.

On Tue, 15 Feb 2011, Peter Zijlstra wrote:

> Realistically libpthread should register an on_fork() callback to 
> ensure the state is properly propagated.

Agreed, that seems reasonable, with only the minor impact of an
additional set_robust_list call. That resolves this as a libc issue,
not a kernel issue.

- Kenneth

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