Messages in this thread | | | Date | Tue, 5 Jan 2010 07:34:02 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [RFC][PATCH 6/8] mm: handle_speculative_fault() |
| |
On Tue, 5 Jan 2010, Peter Zijlstra wrote: > > If it were only unmount it would be rather easy to fix by putting that > RCU synchronization in unmount, unmount does a lot of sync things > anyway. But I suspect there's more cases where that non-busy matters > (but I'd need to educate myself on filesystems/vfs to come up with any).
unmount may well be the only really huge piece.
The only other effects of delaying closing a file I can see are
- the ETXTBUSY thing, but we don't need to delay _that_ part, so this may be a non-issue.
- the actual freeing of the data on disk (ie people may expect that the last close really frees up the space on the filesystem). However, this is _such_ a subtle semantic thing that maybe nobody cares.
It's perhaps worth noting that I think Nick's VFS scalability patches did at least _some_ of the "struct filp" freeing in RCU context too, so this whole "vfs delays things in RCU" is not a new thing.
But I think that in Nick's case it was stricly just the freeing of the inode/dentry data structure (because he needed to traverse the dentry list locklessly - he didn't then _use_ the results locklessly). So the actual filesystem operations didn't get deferred, and as a result it didn't have this particular semantic nightmare.
Linus
| |