lkml.org 
[lkml]   [1997]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.042 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site