All KOTDs since 2.6.25-rc7-git2-HEAD_20080331133119 -default are showing the following problem in the logs :
dentry_open called with NULL vfsmount Apr 3 05:27:05 PC1 kernel: Pid: 5246, comm: kmail Tainted: P N 2.6.25-rc8-HEAD_20080401233651-default #1 Apr 3 05:27:05 PC1 kernel: Apr 3 05:27:05 PC1 kernel: Call Trace: Apr 3 05:27:05 PC1 kernel: [<ffffffff8020d7f2>] dump_trace+0xc4/0x52e Apr 3 05:27:05 PC1 kernel: [<ffffffff8020dc9c>] show_trace+0x40/0x57 Apr 3 05:27:05 PC1 kernel: [<ffffffff8020e421>] dump_stack+0x72/0x7b Apr 3 05:27:05 PC1 kernel: [<ffffffff8029e322>] dentry_open+0x35/0x88 Apr 3 05:27:05 PC1 kernel: [<ffffffff880d60a7>] :reiserfs:xattr_readdir+0x1d/0x52 Apr 3 05:27:05 PC1 kernel: [<ffffffff880d6226>] :reiserfs:reiserfs_for_each_xattr+0x14a/0x23b Apr 3 05:27:05 PC1 kernel: [<ffffffff880d633e>] :reiserfs:reiserfs_delete_xattrs+0x12/0x14 Apr 3 05:27:05 PC1 kernel: [<ffffffff880bdd3a>] :reiserfs:reiserfs_delete_inode+0x72/0x10a Apr 3 05:27:05 PC1 kernel: [<ffffffff802b16e5>] generic_delete_inode+0xaf/0x129 Apr 3 05:27:05 PC1 kernel: [<ffffffff802b1776>] generic_drop_inode+0x17/0x15d Apr 3 05:27:05 PC1 kernel: [<ffffffff802b0e9d>] iput+0x7c/0x80 Apr 3 05:27:05 PC1 kernel: [<ffffffff802a8e8d>] do_unlinkat+0xfc/0x150 Apr 3 05:27:05 PC1 kernel: [<ffffffff802a8ef2>] sys_unlink+0x11/0x13 Apr 3 05:27:05 PC1 kernel: [<ffffffff8020c1aa>] system_call_after_swapgs+0x8a/0x8f Apr 3 05:27:05 PC1 kernel: [<00007fc424f821a7>] Apr 3 05:27:05 PC1 kernel: Apr 3 05:27:05 PC1 kernel: REISERFS warning (device dm-6): jdm-20005 reiserfs_for_each_xattr: Couldn't chown all xattrs (-22) These kernels are a running on a SUSE-10.3 base system , compiled from source with defconfig.default. and gcc 4.2.3 20071030 (prerelease)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Markus Koßmann wrote:
All KOTDs since 2.6.25-rc7-git2-HEAD_20080331133119 -default are showing the following problem in the logs :
dentry_open called with NULL vfsmount
I was wondering how long I'd be able to get away with that. Question answered. I'll come up with a fix today.
- -Jeff
Apr 3 05:27:05 PC1 kernel: Pid: 5246, comm: kmail Tainted: P N 2.6.25-rc8-HEAD_20080401233651-default #1 Apr 3 05:27:05 PC1 kernel: Apr 3 05:27:05 PC1 kernel: Call Trace: Apr 3 05:27:05 PC1 kernel: [<ffffffff8020d7f2>] dump_trace+0xc4/0x52e Apr 3 05:27:05 PC1 kernel: [<ffffffff8020dc9c>] show_trace+0x40/0x57 Apr 3 05:27:05 PC1 kernel: [<ffffffff8020e421>] dump_stack+0x72/0x7b Apr 3 05:27:05 PC1 kernel: [<ffffffff8029e322>] dentry_open+0x35/0x88 Apr 3 05:27:05 PC1 kernel: [<ffffffff880d60a7>] :reiserfs:xattr_readdir+0x1d/0x52 Apr 3 05:27:05 PC1 kernel: [<ffffffff880d6226>] :reiserfs:reiserfs_for_each_xattr+0x14a/0x23b Apr 3 05:27:05 PC1 kernel: [<ffffffff880d633e>] :reiserfs:reiserfs_delete_xattrs+0x12/0x14 Apr 3 05:27:05 PC1 kernel: [<ffffffff880bdd3a>] :reiserfs:reiserfs_delete_inode+0x72/0x10a Apr 3 05:27:05 PC1 kernel: [<ffffffff802b16e5>] generic_delete_inode+0xaf/0x129 Apr 3 05:27:05 PC1 kernel: [<ffffffff802b1776>] generic_drop_inode+0x17/0x15d Apr 3 05:27:05 PC1 kernel: [<ffffffff802b0e9d>] iput+0x7c/0x80 Apr 3 05:27:05 PC1 kernel: [<ffffffff802a8e8d>] do_unlinkat+0xfc/0x150 Apr 3 05:27:05 PC1 kernel: [<ffffffff802a8ef2>] sys_unlink+0x11/0x13 Apr 3 05:27:05 PC1 kernel: [<ffffffff8020c1aa>] system_call_after_swapgs+0x8a/0x8f Apr 3 05:27:05 PC1 kernel: [<00007fc424f821a7>] Apr 3 05:27:05 PC1 kernel: Apr 3 05:27:05 PC1 kernel: REISERFS warning (device dm-6): jdm-20005 reiserfs_for_each_xattr: Couldn't chown all xattrs (-22) These kernels are a running on a SUSE-10.3 base system , compiled from source with defconfig.default. and gcc 4.2.3 20071030 (prerelease)
- -- Jeff Mahoney SUSE Labs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeff Mahoney wrote:
Markus Koßmann wrote:
All KOTDs since 2.6.25-rc7-git2-HEAD_20080331133119 -default are showing the following problem in the logs :
dentry_open called with NULL vfsmount
I was wondering how long I'd be able to get away with that. Question answered. I'll come up with a fix today.
Or not. I've fixed this problem, but run into others. I'll keep the list updated.
- -Jeff
-Jeff
Apr 3 05:27:05 PC1 kernel: Pid: 5246, comm: kmail Tainted: P N 2.6.25-rc8-HEAD_20080401233651-default #1 Apr 3 05:27:05 PC1 kernel: Apr 3 05:27:05 PC1 kernel: Call Trace: Apr 3 05:27:05 PC1 kernel: [<ffffffff8020d7f2>] dump_trace+0xc4/0x52e Apr 3 05:27:05 PC1 kernel: [<ffffffff8020dc9c>] show_trace+0x40/0x57 Apr 3 05:27:05 PC1 kernel: [<ffffffff8020e421>] dump_stack+0x72/0x7b Apr 3 05:27:05 PC1 kernel: [<ffffffff8029e322>] dentry_open+0x35/0x88 Apr 3 05:27:05 PC1 kernel: [<ffffffff880d60a7>] :reiserfs:xattr_readdir+0x1d/0x52 Apr 3 05:27:05 PC1 kernel: [<ffffffff880d6226>] :reiserfs:reiserfs_for_each_xattr+0x14a/0x23b Apr 3 05:27:05 PC1 kernel: [<ffffffff880d633e>] :reiserfs:reiserfs_delete_xattrs+0x12/0x14 Apr 3 05:27:05 PC1 kernel: [<ffffffff880bdd3a>] :reiserfs:reiserfs_delete_inode+0x72/0x10a Apr 3 05:27:05 PC1 kernel: [<ffffffff802b16e5>] generic_delete_inode+0xaf/0x129 Apr 3 05:27:05 PC1 kernel: [<ffffffff802b1776>] generic_drop_inode+0x17/0x15d Apr 3 05:27:05 PC1 kernel: [<ffffffff802b0e9d>] iput+0x7c/0x80 Apr 3 05:27:05 PC1 kernel: [<ffffffff802a8e8d>] do_unlinkat+0xfc/0x150 Apr 3 05:27:05 PC1 kernel: [<ffffffff802a8ef2>] sys_unlink+0x11/0x13 Apr 3 05:27:05 PC1 kernel: [<ffffffff8020c1aa>] system_call_after_swapgs+0x8a/0x8f Apr 3 05:27:05 PC1 kernel: [<00007fc424f821a7>] Apr 3 05:27:05 PC1 kernel: Apr 3 05:27:05 PC1 kernel: REISERFS warning (device dm-6): jdm-20005 reiserfs_for_each_xattr: Couldn't chown all xattrs (-22) These kernels are a running on a SUSE-10.3 base system , compiled from source with defconfig.default. and gcc 4.2.3 20071030 (prerelease)
- -- Jeff Mahoney SUSE Labs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeff Mahoney wrote:
Jeff Mahoney wrote:
Markus Koßmann wrote:
All KOTDs since 2.6.25-rc7-git2-HEAD_20080331133119 -default are showing the following problem in the logs : dentry_open called with NULL vfsmount
I was wondering how long I'd be able to get away with that. Question answered. I'll come up with a fix today.
Or not. I've fixed this problem, but run into others. I'll keep the list updated.
I've just updated the reiserfs xattr patches to fix the problems. Tomorrow's KOTD will have the update.
It should contain the following in the changelog:
- - patches.suse/reiserfs-kill-xattr-readdir.diff: Eliminated use of vfsmount-less dentry_open().
- -Jeff
- -- Jeff Mahoney SUSE Labs
Am Sonntag, 6. April 2008 schrieb Jeff Mahoney:
Jeff Mahoney wrote:
Jeff Mahoney wrote:
Markus Koßmann wrote:
All KOTDs since 2.6.25-rc7-git2-HEAD_20080331133119 -default are showing the following problem in the logs : dentry_open called with NULL vfsmount
I was wondering how long I'd be able to get away with that. Question answered. I'll come up with a fix today.
Or not. I've fixed this problem, but run into others. I'll keep the list updated.
I've just updated the reiserfs xattr patches to fix the problems. Tomorrow's KOTD will have the update.
It should contain the following in the changelog:
- patches.suse/reiserfs-kill-xattr-readdir.diff: Eliminated use of vfsmount-less dentry_open().
Thanks, that made "dentry_open called with NULL vfsmount" disappear.
But unfortnunately, there is another problem introduced with 2.6.25-rc7 that still exists. When I shutdown the system, there is a segmentation fault during the final umount and the system stops with extra sync but filesystems still mounted readonly . Nothing in the logs. Syslog seems to be allready stopped at that time.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Markus Koßmann wrote:
Am Sonntag, 6. April 2008 schrieb Jeff Mahoney:
Jeff Mahoney wrote:
Jeff Mahoney wrote:
Markus Koßmann wrote:
All KOTDs since 2.6.25-rc7-git2-HEAD_20080331133119 -default are showing the following problem in the logs : dentry_open called with NULL vfsmount
I was wondering how long I'd be able to get away with that. Question answered. I'll come up with a fix today.
Or not. I've fixed this problem, but run into others. I'll keep the list updated.
I've just updated the reiserfs xattr patches to fix the problems. Tomorrow's KOTD will have the update.
It should contain the following in the changelog:
- patches.suse/reiserfs-kill-xattr-readdir.diff: Eliminated use of vfsmount-less dentry_open().
Thanks, that made "dentry_open called with NULL vfsmount" disappear.
But unfortnunately, there is another problem introduced with 2.6.25-rc7 that still exists. When I shutdown the system, there is a segmentation fault during the final umount and the system stops with extra sync but filesystems still mounted readonly . Nothing in the logs. Syslog seems to be allready stopped at that time.
Can you switch to console 10 and see what the Oops says?
Thanks.
- -Jeff
- -- Jeff Mahoney SUSE Labs
Am Montag, 7. April 2008 schrieb Jeff Mahoney:
Markus Koßmann wrote:
Am Sonntag, 6. April 2008 schrieb Jeff Mahoney:
Jeff Mahoney wrote:
Jeff Mahoney wrote:
Markus Koßmann wrote:
All KOTDs since 2.6.25-rc7-git2-HEAD_20080331133119 -default are showing the following problem in the logs : dentry_open called with NULL vfsmount
I was wondering how long I'd be able to get away with that. Question answered. I'll come up with a fix today.
Or not. I've fixed this problem, but run into others. I'll keep the list updated.
I've just updated the reiserfs xattr patches to fix the problems. Tomorrow's KOTD will have the update.
It should contain the following in the changelog:
- patches.suse/reiserfs-kill-xattr-readdir.diff: Eliminated use of vfsmount-less dentry_open().
Thanks, that made "dentry_open called with NULL vfsmount" disappear.
But unfortnunately, there is another problem introduced with 2.6.25-rc7 that still exists. When I shutdown the system, there is a segmentation fault during the final umount and the system stops with extra sync but filesystems still mounted readonly . Nothing in the logs. Syslog seems to be allready stopped at that time.
Can you switch to console 10 and see what the Oops says?
Sorry, don't have the time to write down the whole message
Kernel Bug at fs/dcache.c 637 Invalid Opcode:0000 [1] SMP
Backtrace begins with : shrink_dache_for_umount+0x37/0x47
RIP: shrink_dcache_for_umount_subtree 0x146/0x216
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Markus Koßmann wrote:
Am Montag, 7. April 2008 schrieb Jeff Mahoney:
Markus Koßmann wrote:
Am Sonntag, 6. April 2008 schrieb Jeff Mahoney:
Jeff Mahoney wrote:
Jeff Mahoney wrote:
Markus Koßmann wrote: > All KOTDs since 2.6.25-rc7-git2-HEAD_20080331133119 > -default are showing the following problem in the logs : > dentry_open called with NULL vfsmount I was wondering how long I'd be able to get away with that. Question answered. I'll come up with a fix today.
Or not. I've fixed this problem, but run into others. I'll keep the list updated.
I've just updated the reiserfs xattr patches to fix the problems. Tomorrow's KOTD will have the update.
It should contain the following in the changelog:
- patches.suse/reiserfs-kill-xattr-readdir.diff: Eliminated use of vfsmount-less dentry_open().
Thanks, that made "dentry_open called with NULL vfsmount" disappear.
But unfortnunately, there is another problem introduced with 2.6.25-rc7 that still exists. When I shutdown the system, there is a segmentation fault during the final umount and the system stops with extra sync but filesystems still mounted readonly . Nothing in the logs. Syslog seems to be allready stopped at that time.
Can you switch to console 10 and see what the Oops says?
Sorry, don't have the time to write down the whole message
Kernel Bug at fs/dcache.c 637 Invalid Opcode:0000 [1] SMP
Backtrace begins with : shrink_dache_for_umount+0x37/0x47
RIP: shrink_dcache_for_umount_subtree 0x146/0x216
Ok, this means that there's a reference counting problem and a dentry isn't getting released before umount. I can't reproduce it locally, but I've been continuing the development of these patches.
I'll update them as soon as I solve the ABBA deadlock I've been observing under load. What I'm seeing is that one thread is holding the xattr dir i_mutex and waiting on the journal while another thread is in the middle of a transaction and waiting on the xattr dir i_mutex. And then we're stuck.
The solution is probably going to be defining a separate dir_action callback that is responsible for locking the dir in addition to avoiding the deadlock. My old version of these patches had a comment saying "Revisit the lock ordering here." Now I remember why.
- -Jeff
- -- Jeff Mahoney SUSE Labs
Am Montag, 7. April 2008 schrieb Jeff Mahoney:
Can you switch to console 10 and see what the Oops says?
I've opened Bugzilla #378095 for that problem and attached a screenshot of the Kernel BUG message in the bugreport
-
Jeff Mahoney -
Markus Koßmann