On Sat, Aug 29, 2015 at 10:08:30AM -0700, Linus Torvalds wrote: > Hmm. > > I'm wondering if we should just make close_files() (or maybe even > filp_close()) use a synchronous fput(). > > Iirc, the reason we delay fput() is that we had some nasty issues for > the generic fput case. It was called from interrupt context by the aio > code, and just in general there's a lot of nasty cases that can cause > the final fput to happen (so there are lockdep issues with the mmap > locks because the last fput being from munmap etc). > > Maybe I forget some detail - it's been several years by now - but I > think we could make the regular "close()" and "exit()" cases just use > the synchronous fput (it's called "__fput_sync()" and currently > explicitly limited to just kernel threads). > > Al?
First of all, we'd better not count on e.g. delayed fput() *NOT* doing task_work_add() - we still need to check if any new work had been added. After all, final close() might very well have done a final mntput() on a lazy-unmounted filesystem, possibly leaving us with fs shutdown via task_work_add(). And if that sucker e.g. closes a socket, well, we are back to closing an opened struct file, with task_work_add() etc. I'm a bit nervious about filp_close() (that sucker is exported and widely abused), but close_files()... sure, shouldn't be a problem. And yes, we can teach __close_fd() to do the same. I really don't understand what's the benefit, though - it's about the case when we are closing the last descriptor for given opened file, so I would be rather surprised if slower path taken on the way out to userland was not lost in noise... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
