Re: [RFC] pdirops: vfs patch

2005-02-23 Thread Alex Tomas
> Jan Blunck (JB) writes: JB> Nope, d_alloc() is setting d_flags to DCACHE_UNHASHED. Therefore it is not found JB> by __d_lookup() until it is rehashed which is implicit done by ->lookup(). that means we can have two processes allocated dentry for same name. they'll call ->lookup() each ag

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

Re: [RFC] pdirops: vfs patch

2005-02-20 Thread Alex Tomas
> Jan Blunck (JB) writes: JB> With luck you have s_pdirops_size (or 1024) different renames altering JB> concurrently one directory inode. Therefore you need a lock protecting JB> your filesystem data. This is basically the job done by i_sem. So in JB> my opinion you only move "The Problem

Re: [RFC] pdirops: vfs patch

2005-02-20 Thread Jan Blunck
Alex Tomas wrote: +static inline struct semaphore * lock_sem(struct inode *dir, struct qstr *name) +{ + if (IS_PDIROPS(dir)) { + struct super_block *sb; + /* name->hash expected to be already calculated */ + sb = dir->i_sb; + BUG_ON(sb->

Re: [RFC] pdirops: vfs patch

2005-02-19 Thread Alex Tomas
fs/inode.c |1 fs/namei.c | 66 ++--- include/linux/fs.h | 11 3 files changed, 54 insertions(+), 24 deletions(-) Index: linux-2.6.10/fs/namei.c ===