On Fri, Apr 20, 2012 at 10:21:35AM -0700, Linus Torvalds wrote: > On Fri, Apr 20, 2012 at 9:42 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > Actually, I like the per-CPU spinlock variant better; the thing is, > > with that scheme we get normal fput() (i.e. non-nodefer variant) > > non-blocking. ?How about this: > > What's the advantage of a per-cpu lock? > > If you make the work be per-cpu, then you're better with no locking at > all: just disable interrupts (which you do anyway). Point taken. > The thing I do not like about the schedule_work approach is that it > (a) totally hides the real cost - which is the scheduling - and (b) > it is so asynchronous that it will happen potentially long after the > task dropped the reference. [snip] > This is why I suggested you look at Oleg's patches. If we guarantee > that things won't be delayed past re-entering user mode, all those > issues go away. I've looked at them. One obvious problem is that it tracehook_notify_resume() is not universally called. AFAICS, hexagon, m68k, microblaze, score, um and xtensa never call tracehook_notify_resume(). Out of those, hexagon is manually checking TIF_NOTIFY_RESUME and does key_replace_session_keyring(), so the call could be easily added into the same place; the rest of those guys don't even look at TIF_NOTIFY_RESUME anywhere near their signal*.c and m68k/um/xtensa don't even have it defined, let alone handled. So this stuff depends on some amount of asm glue hacking on several architectures ;-/ Another is that final fput() can, indeed, happen in kernel threads, so pure switch to task_work_add() won't be enough. I agree that having this stuff flushed before we return to userland would be a good thing; the question is, can we easily tell if there will be such a return to userland? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
