linux-kernel - Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

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:	Fri, 30 Aug 2013 14:22:58 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Waiman Long <waiman.long@...com>
Cc:	Al Viro <viro@...iv.linux.org.uk>, Ingo Molnar <mingo@...nel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jeff Layton <jlayton@...hat.com>,
	Miklos Szeredi <mszeredi@...e.cz>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Chandramouleeswaran, Aswin" <aswin@...com>,
	"Norton, Scott J" <scott.norton@...com>
Subject: Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless
 update of refcount

On Fri, Aug 30, 2013 at 2:10 PM, Waiman Long <waiman.long@...com> wrote:
>
> Actually, prepend_path() was called with rename_lock taken. So d_move()
> couldn't be run at the same time. Am I right?

Al was discussing the case I mentioned: getting rid of that lock
entirely, running it all just under RCU, and then just checking the
rename sequence count around it all and retrying if required.

It would have the advantage of not only not having to get the lock,
but by doing it as an RCU walk, we would avoid all the nasty reference
counting costs too. We wouldn't even need to get refcounts on the
root/pwd entries (which currently cost us quite a bit), since we could
just check the sequence number in "struct fs_struct" too. That also
gets rid of the necessity for the fs->lock spinlock.

You do have to be a bit careful when following the dentry pointers
under RCU (and you cannot just do a "memcpy()" on the name, as Al
points out), but it really doesn't look nasty. It just looks "you have
to be careful".

              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/