Re: [RFC] situation with fput() locking (was Re: [PULL REQUEST] :ima-appraisal patches)

[Kasatkin, Dmitry]

On Fri, Apr 27, 2012 at 8:34 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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(&current->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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/