/home is mounted with the following options:

   /dev/mapper/vglinux1-lvhome on /home type reiserfs (rw,noatime,nodiratime,user_xattr)
I guess that beagled (the Beagle desktop search daemon) has populated user

xattrs on almost all files. Now, when I delete a file, two BUGs occur

and the system hangs. Here is the stack for the first BUG (the second

one is very similar):
[partially hand copied stack]

_fput

fput

reiserfs_delete_xattrs

reiserfs_delete_inode

generic_delete_inode

generic_drop_inode

iput

do_unlinkat

sys_unlink

sys_enter_past_esp
I reported a similar BUG in 2.6.22-rc8-mm2 (see

http://lkml.org/lkml/2007/9/27/235). Dave Hansen sent a patch for it, I

tested it and it was OK for 2.6.22-rc8-mm2.
I tried this patch on 2.6.23-mm1, and it fixed the BUGs here too.
----

From: Dave Hansen <haveblue@us.ibm.com>
The bug is caused by reiserfs creating a special 'struct file' with a

NULL vfsmount.  
/* Opens a file pointer to the attribute associated with inode */

static struct file *open_xa_file(const struct inode *inode, const char

*name,

                                 int flags)

{

...

        fp = dentry_open(xafile, NULL, O_RDWR);

        /* dentry_open dputs the dentry if it fails */
As Christoph just said, this is somewhat of a bandaid.  But, it

shouldn't hurt anything.
---
 lxc-dave/fs/file_table.c |    2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/open.c~fix-reiserfs-oops fs/open.c

diff -puN fs/file_table.c~fix-reiserfs-oops fs/file_table.c

--- lxc/fs/file_table.c~fix-reiserfs-oops	2007-09-27 13:32:20.000000000 -0700

+++ lxc-dave/fs/file_table.c	2007-09-27 13:33:11.000000000 -0700

@@ -236,7 +236,7 @@ void fastcall __fput(struct file *file)

 	fops_put(file->f_op);

 	if (file->f_mode & FMODE_WRITE) {

 		put_write_access(inode);

-		if (!special_file(inode->i_mode))

+		if (!special_file(inode->i_mode) && mnt)

 			mnt_drop_write(mnt);

 	}

 	put_pid(file->f_owner.pid);

diff -puN include/li...
[ message continues ]

The delete path is a similar case as the one Dave fixed, also cause by

a NULL vfsmount passed to dentry_open, but through a different code-path.
Untested fix for this problem below:
Index: linux-2.6.23-rc8/fs/reiserfs/xattr.c

===================================================================

--- linux-2.6.23-rc8.orig/fs/reiserfs/xattr.c	2007-09-30 14:13:46.000000000 +0200

+++ linux-2.6.23-rc8/fs/reiserfs/xattr.c	2007-09-30 14:18:30.000000000 +0200

@@ -207,9 +207,8 @@ static struct dentry *get_xa_file_dentry

  * we're called with i_mutex held, so there are no worries about the directory

  * changing underneath us.

  */

-static int __xattr_readdir(struct file *filp, void *dirent, filldir_t filldir)

+static int __xattr_readdir(struct inode *inode, void *dirent, filldir_t filldir)

 {

-	struct inode *inode = filp->f_path.dentry->d_inode;

 	struct cpu_key pos_key;	/* key of current position in the directory (key of directory entry) */

 	INITIALIZE_PATH(path_to_entry);

 	struct buffer_head *bh;

@@ -352,24 +351,19 @@ static int __xattr_readdir(struct file *

  * this is stolen from vfs_readdir

  *

  */

-static

-int xattr_readdir(struct file *file, filldir_t filler, void *buf)

+static int xattr_readdir(struct inode *inode, filldir_t filler, void *buf)

 {

-	struct inode *inode = file->f_path.dentry->d_inode;

 	int res = -ENOTDIR;

-	if (!file->f_op || !file->f_op->readdir)

-		goto out;

+

 	mutex_lock_nested(&inode->i_mutex, I_MUTEX_XATTR);

-//        down(&inode->i_zombie);

 	res = -ENOENT;

 	if (!IS_DEADDIR(inode)) {

 		lock_kernel();

-		res = __xattr_readdir(file, buf, filler);

+		res = __xattr_readdir(inode, buf, filler);

 		unlock_kernel();

 	}

-//        up(&inode->i_zombie);

 	mutex_unlock(&inode->i_mutex);

-      out:

+

 	return res;

 }
@@ -721,7 +715,6 @@ reiserfs_delete_xattrs_filler(void *buf,

 /* This is called w/ inode->i_mutex downed */

 int reiserfs_delete_xattrs(struct inode *inode)

 {

-	struct file ...
[ message continues ]

Does work fine, thanks.
-

Here's a patch I worked up the other night that kills off struct file

completely from the xattr code. I've tested it locally.
 After several posts and bug reports regarding interaction with the NULL

 nameidata, here's a patch to clean up the mess with struct file in the

 reiserfs xattr code.
 As observed in several of the posts, there's really no need for struct file

 to exist in the xattr code. It was really only passed around due to the

 f_op->readdir() and a_ops->{prepare,commit}_write prototypes requiring it.
 reiserfs_prepare_write() and reiserfs_commit_write() don't actually use

 the struct file passed to it, and the xattr code uses a private version of

 reiserfs_readdir() to enumerate the xattr directories.
 I do have patches in my queue to convert the xattrs to use reiserfs_readdir(),

 but I guess I'll just have to rework those.
 This is pretty close to the patch by Dave Hansen for -mm, but I didn't

 notice it until after I wrote this up.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>

---

 fs/reiserfs/xattr.c |  111 ++++++++++++++--------------------------------------

 1 file changed, 31 insertions(+), 80 deletions(-)
--- a/fs/reiserfs/xattr.c	2007-08-27 14:03:39.000000000 -0400

+++ b/fs/reiserfs/xattr.c	2007-10-14 22:11:05.000000000 -0400

@@ -191,28 +191,11 @@ static struct dentry *get_xa_file_dentry

 	dput(xadir);

 	if (err)

 		xafile = ERR_PTR(err);

-	return xafile;

-}

-

-/* Opens a file pointer to the attribute associated with inode */

-static struct file *open_xa_file(const struct inode *inode, const char *name,

-				 int flags)

-{

-	struct dentry *xafile;

-	struct file *fp;

-

-	xafile = get_xa_file_dentry(inode, name, flags);

-	if (IS_ERR(xafile))

-		return ERR_PTR(PTR_ERR(xafile));

 	else if (!xafile->d_inode) {

 		dput(xafile);

-		return ERR_PTR(-ENODATA);

+		xafile = ERR_PTR(-ENODATA);

 	}

-

-	fp = dentry_open(xafile, NULL, O_RDWR);

-	/* dentry_open dputs the dentry if it fails */

-

-	return fp;

+	return xafile;

 }

 ...
[ message continues ]

Looks like a merge of Dave's and my patch :)
ACK from me, I don't care whether it's one or two patches.

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Yeah, it probably is. I did it from scratch since it was my mess, and

the patches I saw were against -mm.
*shrug* Likewise, I don't care if it's one or two.
- -Jeff
- --

Jeff Mahoney

SUSE Labs

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.4-svn0 (GNU/Linux)

Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHFiJHLPWxlyuTD7IRAojqAJwKS+eL1yCtUVHzBSFUxjjkW6KgPwCcDRUE

Q1V7tCPcT9h0a8ahVmYn+ms=

=5kMt

-----END PGP SIGNATURE-----

-

Sorry Jeff, your patch does not apply on 2.6.23-mm1. The 'struct file'

removal from reiserfs_xattr_ function is already in -mm

(make-reiserfs-stop-using-struct-file-for-internal.patch).
The Dave's patch I was refering to is this one: 
==== BEGIN =====

The bug is caused by reiserfs creating a special 'struct file' with a

NULL vfsmount.  
/* Opens a file pointer to the attribute associated with inode */

static struct file *open_xa_file(const struct inode *inode, const char

*name,

                                 int flags)

{

...

        fp = dentry_open(xafile, NULL, O_RDWR);

        /* dentry_open dputs the dentry if it fails */
As Christoph just said, this is somewhat of a bandaid.  But, it

shouldn't hurt anything.
---
 lxc-dave/fs/file_table.c |    2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/open.c~fix-reiserfs-oops fs/open.c

diff -puN fs/file_table.c~fix-reiserfs-oops fs/file_table.c

--- lxc/fs/file_table.c~fix-reiserfs-oops	2007-09-27 13:32:20.000000000 -0700

+++ lxc-dave/fs/file_table.c	2007-09-27 13:33:11.000000000 -0700

@@ -236,7 +236,7 @@ void fastcall __fput(struct file *file)

 	fops_put(file->f_op);

 	if (file->f_mode & FMODE_WRITE) {

 		put_write_access(inode);

-		if (!special_file(inode->i_mode))

+		if (!special_file(inode->i_mode) && mnt)

 			mnt_drop_write(mnt);

 	}

 	put_pid(file->f_owner.pid);

diff -puN include/linux/mount.h~fix-reiserfs-oops include/linux/mount.h

==== END ====
Dave sent it privately to me... I guess this "bandaid" is no longer

needed now, is it?
~~

laurent
-

We'll need to drop Dave's patch first.  Andrew, can you drop it and

put this one in instead?
-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
I'd guess not. This patch was actually against mainline. I should've

specified. I can work up one against -mm later today if it's needed.
- -Jeff
- --

Jeff Mahoney

SUSE Labs

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.4-svn0 (GNU/Linux)

Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHE8wyLPWxlyuTD7IRAiJrAJ4nC6gwH1cFjWx6BI04O5fDIRftmACcD2wb

whyXThHlIBK2phnZ6Pf8Pb8=

=Kx6k

-----END PGP SIGNATURE-----

-