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:	Mon, 9 Sep 2013 07:39:31 +0530
From:	Ramkumar Ramachandra <artagnon@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Al Viro <viro@...iv.linux.org.uk>, Ingo Molnar <mingo@...nel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Waiman Long <Waiman.Long@...com>,
	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

Linus Torvalds wrote:
> On Sun, Sep 8, 2013 at 5:03 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>>
>> Well...  unlazy_walk() is always followed by terminate_walk() very shortly,
>> but there's a minor problem - terminate_walk() uses "are we in RCU
>> mode?" for two things:
>>         a) do we need to do path_put() here?
>>         b) do we need to unlock?
>> If you introduce the third case ("no need to do unlock and no need to
>> do path_put()"), we'd better decide how to check for that case...

Yeah, I think b is a crucial step: it depends on how you unlock. Does
the unlocking result in data corruption and chaos, or does it result
in ordered data being unlocked? If it's the former case, people are
sure to take advantage of you; otherwise, you can use people.

> Actually, I decided to take advantage of those two cases instead, and
> I have a patch that I think does the right thing. Basically, I start
> off unlazy_walk() with just doing that lockref_get_not_dead() on the
> parent dentry, and if that fails I just return an error in RCU mode
> (so terminate_walk() does what it always used to do, and we haven't
> done anything else to any refcounts).

LRU cache requires that a single processor is accessing memory at a
time: if there are multiple processors, L1/ L2 cache concurrent access
is a problem.

> Now, if the lockref_get_not_dead() succeeded, that means that we have
> a reference on the nd->path.dentry, and we can now just do
> "mntget(nd->path.mnt);". Ta-Daa! We now have everything done for the
> non-RCU case for terminate_walk().

How efficient is the mounting? Has data been corrupted while taking
the portable filesystem around?

> So after that point, we clear LOOKUP_RCU, and make the rule be that
> any return (error or success) has to do unlock_rcu_walk(). And then
> all the other refcounts are easy, we can just "dput(dentry);" after
> that.

Drag ropes.

> I haven't tested it yet, I was going to reboot into it just now. But
> I'm attaching the patch here. Maybe I missed some detail, but it all
> seems simpler.

Some amount of garbage collection is healthy every once in a while,
but the project requires more yak shavers than anything else at this
point.

> Note that this patch requires the "lockref_get_not_dead()" cleanup at
> the top of my current -git.

Why is the current gitster not up to date? We should discuss automated
version control.
--
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/