Re: [RFC] pdirops: vfs patch

2005-02-22 Thread Jan Blunck
Quoting Alex Tomas <[EMAIL PROTECTED]>: > > Jan Blunck (JB) writes: > > JB> i_sem does NOT protect the dcache. Also not in real_lookup(). The lock > must be > JB> acquired for ->lookup() and because we might sleep on i_sem, we have to > get it > JB> early and check for repopulation of the d

Re: [RFC] pdirops: vfs patch

2005-02-22 Thread Alex Tomas
> Jan Blunck (JB) writes: JB> i_sem does NOT protect the dcache. Also not in real_lookup(). The lock must be JB> acquired for ->lookup() and because we might sleep on i_sem, we have to get it JB> early and check for repopulation of the dcache. dentry is part of dcache, right? i_sem prote

Re: [RFC] pdirops: vfs patch

2005-02-22 Thread Jan Blunck
Quoting Alex Tomas <[EMAIL PROTECTED]>: > > Jan Blunck (JB) writes: > > >> 1) i_sem protects dcache too > > JB> Where? i_sem is the per-inode lock, and shouldn't be used else. > > read comments in fs/namei.c:read_lookup() > i_sem does NOT protect the dcache. Also not in real_lookup(). The l

Re: [RFC] pdirops: vfs patch

2005-02-22 Thread Alex Tomas
> Jan Blunck (JB) writes: >> 1) i_sem protects dcache too JB> Where? i_sem is the per-inode lock, and shouldn't be used else. read comments in fs/namei.c:read_lookup() >> 2) tmpfs has no "own" data, so we can use it this way (see 2nd patch) >> 3) I have pdirops patch for ext3, but it ne

Re: [RFC] pdirops: vfs patch

2005-02-22 Thread Jan Blunck
Quoting Alex Tomas <[EMAIL PROTECTED]>: > > 1) i_sem protects dcache too Where? i_sem is the per-inode lock, and shouldn't be used else. > 2) tmpfs has no "own" data, so we can use it this way (see 2nd patch) > 3) I have pdirops patch for ext3, but it needs some cleaning ... I think you didn't