xfs
[Top] [All Lists]

Re: race in unmount code.

To: Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: race in unmount code.
From: "Andi Kleen" <ak@xxxxxxx>
Date: Wed, 10 May 2000 10:57:54 +0200
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <200005100601.QAA72713@clouds.melbourne.sgi.com>; from dxm@clouds.melbourne.sgi.com on Wed, May 10, 2000 at 04:01:29PM +1000
References: <200005100601.QAA72713@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Wed, May 10, 2000 at 04:01:29PM +1000, Daniel Moore wrote:
> I'm pretty sure the problem is because d_umount (called from do_umount in 
> super.c) sets s_root to NULL then does other stuff which causes the
> kernel to sleep and allows entry to get_filesystem_info from a
> syscall while the superblock is in a screwy state.
> 
> After that, I'm lost - it does seem to be XFS specific.
> 
> (yes it's a contrived example, but it demonstrates a bug I've been
> seeing in more or less normal operation)
> 
> Any ideas people? I've got to get back to testing.

The vfsmnt stuff is very new in linux -- it was introduced only a few
patchlevels before the XFS kernel branched. So it is entirely possible
that the generic code is buggy. Maybe this patch will help:

--- linux/fs/super.c-o  Mon Mar 27 20:31:13 2000
+++ linux/fs/super.c    Wed May 10 10:58:32 2000
@@ -384,6 +384,8 @@
        if (!buffer) return 0;
        for (tmp = vfsmntlist; tmp && len < PAGE_SIZE - 160;
            tmp = tmp->mnt_next) {
+               if (!tmp->mnt_sb || !tmp->mnt_sb->s_root)
+                       continue;
                path = d_path(tmp->mnt_sb->s_root, buffer, PAGE_SIZE);
                if (!path)
                        continue;

-Andi

<Prev in Thread] Current Thread [Next in Thread>