[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070420170738.e269fcae.akpm@linux-foundation.org>
Date: Fri, 20 Apr 2007 17:07:38 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Jeff Mahoney <jeffm@...e.com>
Cc: "Vladimir V. Saveliev" <vs@...esys.com>, a.righi@...eca.it,
linux-kernel@...r.kernel.org, reiserfs-dev@...esys.com,
Edward Shishkin <edward@...esys.com>, zam@...sterfs.com
Subject: Re: Fwd: Fw: [2.6.20.4] BUG: dentry xattrs still in use in
shrink_dcache_for_umount() with reiserfs
On Wed, 18 Apr 2007 11:00:00 -0400
Jeff Mahoney <jeffm@...e.com> wrote:
> > Do you think that could be a reason of the extra reference count on xattr_root dentry?
>
> No, I don't think it is. Looking at the code now, it seems obvious, but
> I didn't notice it before and nobody else has reported a problem.
>
> getxattr() doesn't require any VFS locking. When we get down into the
> reiserfs code, it takes a read lock. If we get two concurrent threads
> looking up an xattr before the root has been saved, there's a window
> where REISERFS_SB(s)->xattr_root is NULL but we've already looked it up
> and taken a reference on it.
>
> I have a patch set to clean up the extended attribute code that fixes
> this problem along the way by killing off the xattr locks and using the
> backing files/dirs i_mutex instead. I'll post them to the reiserfs
> mailing list.
Do we have anything suitable for 2.6.21 which will address this crash?
Also, it's not clear to me how many users we can expect to be impacted by it.
I assume that if the same bug is in 2.6.20 then the answer is "not many".
How come Andrea is able to keep hitting it?
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists