linux-kernel - Re: [tip:locking/core] locking/rwsem: Fix lock optimistic spinning when owner is not running

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: <CA+55aFwyfhSFk69nLAsqUy44vVAH+28g7U221L-JDdz1o9f2wA@mail.gmail.com>
Date:	Tue, 10 Mar 2015 10:45:45 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>,
	Davidlohr Bueso <dave@...olabs.net>,
	Peter Anvin <hpa@...or.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jason Low <jason.low2@...com>,
	Michel Lespinasse <walken@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Dave Jones <davej@...emonkey.org.uk>,
	Ming Lei <ming.lei@...onical.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Kirill Tkhai <tkhai@...dex.ru>
Subject: Re: [tip:locking/core] locking/rwsem: Fix lock optimistic spinning
 when owner is not running

On Tue, Mar 10, 2015 at 10:28 AM, Oleg Nesterov <oleg@...hat.com> wrote:
>
> But this won't fix other problems we might have. For example, suppose
> that we will need get_task_struct(owner) in this code, this won't work.

I agree that SLAB_DESTROY_BY_RCU in general is fairly fragile, and
leads to subtle issues. If speculatively taking locks, for example,
they might need to be initialized in the constructor function, and not
ever touched at actual allocation time. Etc etc.

So I'm not a huge fan of SLAB_DESTROY_BY_RCU in general, but for
really core data structures like this, I think it's worth it. The
overhead of "call_rcu()" can be quite noticeable, and the other
alternative solutions (like that suggested task_rcu_dereference()) are
even *more* complex and subtle and generally perform worse.

I'm not claiming it's perfect, but I think the "access the task
pointer without locking" is kind of special and worth making work in
reasonable ways.

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