[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzEwsW1kdLo2hpgW2PUCRkyaRxS_KB40iwmuk1FDgV+cg@mail.gmail.com>
Date: Fri, 20 Apr 2012 15:35:29 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Hugh Dickins <hughd@...gle.com>, linux-fsdevel@...r.kernel.org,
James Morris <jmorris@...ei.org>,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org,
David Safford <safford@...ux.vnet.ibm.com>,
Dmitry Kasatkin <dmitry.kasatkin@...el.com>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
David Miller <davem@...emloft.net>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC] situation with fput() locking (was Re: [PULL REQUEST] :
ima-appraisal patches)
On Fri, Apr 20, 2012 at 3:13 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Kinda-sorta. I agree that such helpers make sense, but you are too
> optimistic about the number of such places. And clusterfuck around
> mremap() is fairly deep, so propagating all way back to up_write()
> wont' be fun.
Fair enough.
I'll do the helpers and see how much they get rid of, just because
looking at all the callers, those helpers seem to be obviously the
right thing anyway. So even if we don't do anything else, we can
improve things regardless.
For do_brk(), for example, it looks like do_brk() itself should
actually be entirely static to mm/mmap.c, because every single caller
from the outside actually wants the self-locking version.
So plan right now: do "vm_xyzzy()" helper functions that do
"do_xyzzy()" and take the lock (and do not take the "mm" argument,
because it had better always be the current one - keep the calling
convention as simple as possible).
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/
Powered by blists - more mailing lists