Messages in this thread | | | Date | Sat, 9 Aug 1997 21:44:23 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: patch for fs/dcache race |
| |
On Sat, 9 Aug 1997, Bill Hawes wrote: > > It seems that the kswapd oops bug is still extant, so I checked some > more and found a race in d_move that could account for the problem. The > call to d_remove_from_parent() dputs the parent dentry, and a call to > alloc_new_name is made before the new parent pointer is installed. If > alloc_new_name has to get more memory, it could start the kswapd > process, and a shrink_dcache could then catch the dentry with a stale > parent pointer, leading to the oops.
This shouldn't be a bug: when d_move() is called, the dentry count for the target must be non-zero, so shrink_dcache() will never look at the dentry any closer (certainly not the parent).
So yes, there is a stale pointer, but it's never used, and it will be updated to the correct parent quickly.
Actually, the only reason this all is done this way at all is that the dentry hashes used to be per-directory rather than global. Having a per-directory dentry hash had some advantages, but it had _so_ many disadvantages that I got rid of it. Due to the per-directory hash d_move() had to remove the hash and the parent at the same time, and then re-instate the new parent with the new hash.
I guess I should rewrite d_move() to be more robust: there really isn't any reason for the stale parent pointer in the first place. (And while I don't think this is a bug, I certainly agree that it is very ugly).
Linus
| |