Dmitriy Monakhov wrote:
Eric Sandeen <[EMAIL PROTECTED]> writes:
I've been looking at a case where many threads are opening, unlinking, and
hardlinking files on ext3 .
How many concurent threads do you use and how long does it takes to trigger
this race? I've tried to reproduce this with two t
Eric Sandeen <[EMAIL PROTECTED]> writes:
> I've been looking at a case where many threads are opening, unlinking, and
> hardlinking files on ext3 .
How many concurent threads do you use and how long does it takes to trigger
this race? I've tried to reproduce this with two threads, but not succeed
Eric Sandeen wrote:
> Alex Tomas wrote:
>
>> yes, but it shouldn't allow to re-link such inode back, IMHO.
>> a filesystem may start some non-revertable activity in its
>> unlink method.
>>
>> thanks, Alex
>>
>
> I tend to agree, chatting w/ Al I think he does too. :) I'll test
> a patch
> Eric Sandeen (ES) writes:
ES> Al says "no" and I'm not arguing. :)
ES> Apparently this may be OK with some filesystems, and Al says he doesn't
ES> want to know about i_nlink in the vfs in any case.
well, generic_drop_inode() uses i_nlink ...
ES> But I suppose there may be other files
Alex Tomas wrote:
>> Eric Sandeen (ES) writes:
> ES> I tend to agree, chatting w/ Al I think he does too. :) I'll test
> ES> a patch that kicks out ext3_link() with -ENOENT at the top, and resubmit
> ES> that if things go well.
>
> shouldn't VFS do that?
Al says "no" and I'm not arguing.
> Eric Sandeen (ES) writes:
ES> I tend to agree, chatting w/ Al I think he does too. :) I'll test
ES> a patch that kicks out ext3_link() with -ENOENT at the top, and resubmit
ES> that if things go well.
shouldn't VFS do that?
thanks, Alex
-
To unsubscribe from this list: send the line "u
Alex Tomas wrote:
>> Eric Sandeen (ES) writes:
>
> ES> so I think it's possible that link can sneak in there & find it after
> ES> the mutex is dropped...? Is this ok? :) It's certainly -happening-
> ES> anyway
>
> yes, but it shouldn't allow to re-link such inode back, IMHO.
> a fil
> Eric Sandeen (ES) writes:
ES> so I think it's possible that link can sneak in there & find it after
ES> the mutex is dropped...? Is this ok? :) It's certainly -happening-
ES> anyway
yes, but it shouldn't allow to re-link such inode back, IMHO.
a filesystem may start some non-revert
On Sat, 2007-01-13 at 00:02 +0300, Alex Tomas wrote:
> interesting ..
>
> I thought VFS doesn't allow concurrent operations.
> if unlink goes first, then link should wait on the
> parent's i_mutex and then found no source name.
I don't think the VFS ever takes the source's parent's i_mutex. Unle
ah, it seems vfs_link() doesn't check whether source is still alive.
for example, in mkdir case vfs_mkdir() calls may_create() and
checks the parent is still there:
if (IS_DEADDIR(dir))
return -ENOENT;
VFS doesn't set S_DEAD on regular files, but we could check i_nlink.
t
Alex Tomas wrote:
> interesting ..
>
> I thought VFS doesn't allow concurrent operations.
> if unlink goes first, then link should wait on the
> parent's i_mutex and then found no source name.
>
> thanks, Alex
Well... I was wondering that myself, whether this race should even
happen. But the bo
interesting ..
I thought VFS doesn't allow concurrent operations.
if unlink goes first, then link should wait on the
parent's i_mutex and then found no source name.
thanks, Alex
> Eric Sandeen (ES) writes:
ES> )
ES> I've been looking at a case where many threads are opening, unlinking, a
I've been looking at a case where many threads are opening, unlinking, and
hardlinking files on ext3 . At unmount time I see an oops, because the
superblock's
orphan list points to a freed inode.
I did some tracing of the inodes, and it looks like this:
ext3_unlink():[/src/linux-2.6.18/fs/ext
13 matches
Mail list logo
