[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0904212031120.10256@blonde.anvils>
Date: Tue, 21 Apr 2009 20:39:06 +0100 (BST)
From: Hugh Dickins <hugh@...itas.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Oleg Nesterov <oleg@...hat.com>, Al Viro <viro@...IV.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Joe Malicki <jmalicki@...acarta.com>,
Michael Itz <mitz@...acarta.com>,
Kenneth Baker <bakerk@...acarta.com>,
Chris Wright <chrisw@...s-sol.org>,
David Howells <dhowells@...hat.com>,
Alexey Dobriyan <adobriyan@...il.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Q: check_unsafe_exec() races (Was: [PATCH 2/4] fix setuid
sometimes doesn't)
On Tue, 21 Apr 2009, Linus Torvalds wrote:
> On Tue, 21 Apr 2009, Oleg Nesterov wrote:
> >
> > OK, I agree, it doesn't really matter from latency/etc pov.
> >
> > But still I can't understand why it is better to take fs->lock under
> > RCU lock. I mean, "fs->lock is the innermost lock" should not apply
> > to rcu_read_lock(). Because the latter is a bit special, no?
>
> Oh, I don't think it matters. If you want to put the RCU read-lock
> innermost, that's fine by me. I just reacted to your latency argument as
> not being very strong :)
>
> All I personally want is a patch that everybody can agree on, and that
> has sane semantics.
Right, that ordering scarcely matters, and can probably be argued
either way. I should have been clearer when I suggested inverting
them to Oleg: I meant it merely as a suggestion, that we go back
to the ordering which came more naturally to Al in the first place.
And since Al hasn't spoken up (probably has more important things
to care about), please do go ahead with your two patches, Oleg,
with the rcu_read_lock() on whichever side takes your fancy!
Thanks,
Hugh
--
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