[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALLzPKajCrfPz-V=9yftoq=FGQuMYvzCwFMKDcZpm+=QPnJJ1g@mail.gmail.com>
Date: Fri, 27 Apr 2012 21:52:09 +0300
From: "Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
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>,
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 27, 2012 at 8:34 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Fri, Apr 27, 2012 at 10:35:25AM +0300, Kasatkin, Dmitry wrote:
>
>> But have you seen the proposed patch for __fput()?
>> [PATCH v4 10/12] ima: defer calling __fput()
>>
>> It defers only of course the last AND mmap_sem is locked AND open for write.
>>
>> if (current->mm && rwsem_is_locked(¤t->mm->mmap_sem)) {
>> if (ima_defer_fput(file) == 0)
>> return;
>> }
>>
>> Just 5 out of ~100,000 mmap_sem held fput() calls were deferred.
>
> Let me get it straight.
> a) You still ignore all the problems with that described in the
> posting right in the beginning of this thread.
> b) You ignore the problems with semantics changes from user-visible
> delays of fput() past the return from syscall (described in Linus' posting
> upthread - they apply to this "solution" as well).
> c) You seem to consider the fact that this path will be exercised
> very rarely, thus making any races on it damn hard to reproduce and debug
> as a good thing.
>
> And as for the sentiment expressed in the beginning of your posting (that
> smaller patch size is worth more than clean locking rules, maintainability
> of resulting kernel, etc.)... I'm sorry, but you guys need to decide
> what IMA is. If it's a first-class part of the kernel, you have your
> priorities backwards...
Hello,
I do not ignore anything.
I said that we were thinking about solution to get the list of file to
fput them after mmap unlock.
And I do understand the issues discussed.
I just wanted to know more opinions on proposed patch.
- Dmitry
--
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