Messages in this thread | | | From | Linus Torvalds <> | Date | Fri, 20 Apr 2012 08:56:57 -0700 | Subject | Re: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches) |
| |
On Fri, Apr 20, 2012 at 1:09 AM, Al Viro <viro@zeniv.linux.org.uk> wrote: > > Note that we do *not* need to bother with fput_light() - even if it does > fput(), that fput() won't usually be the final one.
Ack. Most of the time the fput_light()->fput will just decrement the use count.
> We also get something else out of that - AFAICS, the kludge in __scm_destroy() > can be killed after that. We did it to prevent recursion on fput(), right? > Now that recursion will be gone...
Hmm.. That points out that we may have a *lot* of these pending final fput's, though. So the deferral queueing should be fairly light. What were your particular plans for it?
This actually sounds like a fairly good usage-case for Oleg's new task_work_add() thing. That would defer the final fput, but at the same time guarantee that it gets done before returning to user space - in case there are any issues with synchronous actions. Have you looked at Oleg's series? You weren't cc'd because it didn't affect you, but look at lkml for "task_work_add()" to find it.
NOTE! If pure kernel threads do fput() deferral (and maybe they do - I'm thinking nfsd etc), then the task-work thing might need some extra thought.
Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |