lkml.org 
[lkml]   [2000]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch-2.4.0-test5-pre2] forced umount with a few fixes
Tigran Aivazian wrote:
>
> Hi Manfred
>
> The patch below has the fixes for the problems you mentioned and also one
> you didn't mention (the munmap case didn't know about the possibility of
> multiple mounted instances per superblock).
>
> Now I will think about the more serious issues you mentioned:
>
> a) race with module unload (meaning the corresponding filesystem module's
> unload, not nullfs)
>

Exactly, it's a special case of b)

> b) need to synchronize with a thread in between fget/fput (is that what
> you meant by coda_release() example?)
>

Yes. If a thread is within kernel space, touching that
filp->f_dentry->d_inode is dangerous.

> c) deadlock with concurrent rename (not sure yet if there is a deadlock
> here - need to open my eyes wider :)
>

Check fs/namei.c.
Al Viro is cursing because the logic is too complicated.

fs layout:
/mntpoint
/mntpoint/directory
/mntpoint/directory/file

thread 1:
rename("/mntpoint/directory/file","/mntpoint/file");
thread 2:
disable_fd for a fd that points to /mntpoint/directory


It seems that your disable_fd calls
down(&root->d_inode->i_sem); /mntpoint
down(&inode->i_sem); /mntpoint/directory


The problem is that a rename will acquire i_sem for /mntpoint and
/mntpoint/directory as well, but it might to that in a different order
(it relies on the memory ordering, see double_down or triple_down)

down(&inode->i_sem);
down(&root->d_inode->i_sem);

--> deadlock.

--
Manfred


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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