I don't know if it's relevant or should I ignore it, but I'm reporting it anyway (everything is working fine here... I have no problems with reiser)... If it's harmless, please discard my bug report. Thanks. Apr 22 15:29:59 tux kernel: REISERFS (device sda2): found reiserfs format "3.6" with standard journal Apr 22 15:29:59 tux kernel: REISERFS (device sda2): using ordered data mode Apr 22 15:29:59 tux kernel: REISERFS (device sda2): journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Apr 22 15:29:59 tux kernel: REISERFS (device sda2): checking transaction log (sda2) Apr 22 15:29:59 tux kernel: REISERFS (device sda2): Using r5 hash to sort names Apr 22 15:29:59 tux kernel: ------------[ cut here ]------------ Apr 22 15:29:59 tux kernel: WARNING: at fs/namei.c:1251 lookup_one_len+0x108/0x120() Apr 22 15:29:59 tux kernel: Hardware name: System Product Name Apr 22 15:29:59 tux kernel: Modules linked in: Apr 22 15:29:59 tux kernel: Pid: 1, comm: swapper Not tainted 2.6.30-rc3 #1 Apr 22 15:29:59 tux kernel: Call Trace: Apr 22 15:29:59 tux kernel: [<ffffffff80239097>] warn_slowpath+0xa7/0xe0 Apr 22 15:29:59 tux kernel: [<ffffffff802396c0>] ? release_console_sem+0x1b0/0x200 Apr 22 15:29:59 tux kernel: [<ffffffff80309dbb>] ? prepare_error_buf+0x57b/0x680 Apr 22 15:29:59 tux kernel: [<ffffffff80317248>] ? do_journal_end+0x1e8/0xf50 Apr 22 15:29:59 tux kernel: [<ffffffff80318e91>] ? do_journal_begin_r+0x111/0x330 Apr 22 15:29:59 tux kernel: [<ffffffff802a9798>] lookup_one_len+0x108/0x120 Apr 22 15:29:59 tux kernel: [<ffffffff8031b1d5>] reiserfs_xattr_init+0x45/0xb0 Apr 22 15:29:59 tux kernel: [<ffffffff80308b75>] reiserfs_fill_super+0x7f5/0xb20 Apr 22 15:29:59 tux kernel: [<ffffffff802a0300>] ? test_bdev_super+0x0/0x20 Apr 22 15:29:59 tux kernel: [<ffffffff802a1a27>] get_sb_bdev+0x157/0x1a0 Apr 22 15:29:59 tux kernel: [<ffffffff80308380>] ? reiserfs_fill_super+0x0/0xb20 Apr 22 15:29:59 tux kernel: [<ffffffff80306393>] get_super_block+0x13/0x20 Apr 22 15:29:59 tux kernel: [<ffffffff802a1516>] vfs_kern_mount+0x76/0x180 Apr 22 15:29:59 tux kernel: [<ffffffff802a168d>] do_kern_mount+0x4d/0x110 Apr 22 15:29:59 tux kernel: [<ffffffff802b9234>] do_mount+0x344/0x8b0 Apr 22 15:29:59 tux kernel: [<ffffffff802b9834>] sys_mount+0x94/0xf0 Apr 22 15:29:59 tux kernel: [<ffffffff80573e0c>] mount_block_root+0xdb/0x27f Apr 22 15:29:59 tux kernel: [<ffffffff80574006>] mount_root+0x56/0x5a Apr 22 15:29:59 tux kernel: [<ffffffff8057413e>] prepare_namespace+0x134/0x161 Apr 22 15:29:59 tux kernel: [<ffffffff805736d7>] kernel_init+0x17b/0x18b Apr 22 15:29:59 tux kernel: [<ffffffff8020c3ea>] child_rip+0xa/0x20 Apr 22 15:29:59 tux kernel: [<ffffffff8057355c>] ? kernel_init+0x0/0x18b Apr 22 15:29:59 tux kernel: [<ffffffff8020c3e0>] ? child_rip+0x0/0x20 Apr 22 15:29:59 tux kernel: ---[ end trace bd740a0e89f40a36 ]--- Apr 22 15:29:59 tux kernel: VFS: Mounted root (reiserfs filesystem) on device 8:2.
marked as a regression..
This was introduced by commit 2f9092e1020246168b1309b35e085ecd7ff9ff72 expecting the dir inode to be locked when lookup_one_len is called. I can expand the locking around the calls.
First-Bad-Commit : 2f9092e1020246168b1309b35e085ecd7ff9ff72 Handled-By : Jeff Mahoney <jeffm@suse.com>
Hi. 2.6.30-rc3 Same problem: [ 53.960396] REISERFS (device sda8): using ordered data mode [ 53.960899] REISERFS (device sda8): journal params: device sda8, size 8192, j ournal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 53.961486] REISERFS (device sda8): checking transaction log (sda8) [ 54.003083] REISERFS (device sda8): Using r5 hash to sort names [ 54.003295] WARNING: at fs/namei.c:1251 lookup_one_len+0xf0/0x110() [ 54.006379] Pid: 2118, comm: mount Not tainted 2.6.30-rc3-test #1 [ 54.006460] Call Trace: [ 54.006537] [<c04b91d1>] ? printk+0x23/0x36 [ 54.006616] [<c015f0a3>] warn_slowpath+0x93/0xe0 [ 54.006696] [<c03d1878>] ? vt_console_print+0x218/0x2e0 [ 54.006777] [<c0149ff7>] ? default_spin_lock_flags+0x17/0x30 [ 54.006860] [<c0282bad>] ? do_journal_end+0x1dd/0xe50 [ 54.006941] [<c02091d0>] lookup_one_len+0xf0/0x110 [ 54.007030] [<c0178960>] ? autoremove_wake_function+0x0/0x60 [ 54.007112] [<c0289569>] reiserfs_xattr_init+0xe9/0x260 [ 54.007192] [<c0178938>] ? wake_up_bit+0x68/0x90 [ 54.007274] [<c0273f29>] reiserfs_fill_super+0xa99/0xe10 [ 54.007367] [<c035bce9>] ? string+0x59/0x100 [ 54.007446] [<c035cda5>] ? snprintf+0x25/0x40 [ 54.007524] [<c0253556>] ? disk_name+0x66/0xd0 [ 54.007603] [<c0200aed>] get_sb_bdev+0x13d/0x190 [ 54.007681] [<c0273490>] ? reiserfs_fill_super+0x0/0xe10 [ 54.007761] [<c0270e9d>] get_super_block+0x2d/0x50 [ 54.007840] [<c0273490>] ? reiserfs_fill_super+0x0/0xe10 [ 54.007919] [<c0200601>] vfs_kern_mount+0x71/0x160 [ 54.007999] [<c020077d>] do_kern_mount+0x4d/0xf0 [ 54.008088] [<c0219cb0>] do_mount+0x450/0x790 [ 54.008166] [<c021a085>] sys_mount+0x95/0xf0 [ 54.008245] [<c01290d3>] sysenter_do_call+0x12/0x28 [ 54.008326] ---[ end trace 7c022b0b46477b0f ]--- Sergey.
I have it too. 2.6.30-rc3-341-ge4f062f, incl. cherrypicked e4f062ff9e3c995f3b6f20848a272c8f0fa210e7 , x86: hpet: fix periodic mode programming on AMD 81xx, from tip/x86/urgent to fix #13176 which I had as well). I'm also getting a machine-check taint (tainted G, M), however, that the above are not, and that I don't get on 2.6.29.1. This seems to be consistent as I had the tainted, lockdep disabled warning in the log while I was crashing before the above cherrypick. Since the others don't have it it's likely OT for this bug, but can someone point me at some instructions for tracing it down further, and are there other 2.6.30 bugs known to trigger MCEs or taint M,G anyway? I don't see anything else in the log before the tainted/lockdeps-disabled warning indicating a problem, with it being rather early in the kernel boot process, so whatever it is isn't leaving me much to go on.
Still present at 2.6.30-rc4.
Created attachment 21183 [details] [PATCH] reiserfs: Expand i_mutex to enclose lookup_one_len 2.6.30-rc3 introduced some sanity checks in the VFS code to avoid NFS bugs by ensuring that lookup_one_len is always called under i_mutex. This patch expands the i_mutex locking to enclose lookup_one_len. This was always required, but not not enforced in the reiserfs code since it does locking around the xattr interactions with the xattr_sem.
(In reply to comment #7) > Created an attachment (id=21183) [details] > [PATCH] reiserfs: Expand i_mutex to enclose lookup_one_len Thanks Jeff. Your patch works fine here.
> --- Comment #7 from Jeff Mahoney <jeffm@suse.com> 2009-05-01 15:59:51 --- > Created an attachment (id=21183) > --> (http://bugzilla.kernel.org/attachment.cgi?id=21183) > [PATCH] reiserfs: Expand i_mutex to enclose lookup_one_len > Hello Jeff. No crashes during boot at the moment. (Need to test it more). Thanks. Sergey.
(In reply to comment #7) > Created an attachment (id=21183) [details] > [PATCH] reiserfs: Expand i_mutex to enclose lookup_one_len Hi Jeff, this patch wasn't merged in 2.6.30-rc5. Will it be merged before 2.6.30 final release? Thanks.
> Hi Jeff, this patch wasn't merged in 2.6.30-rc5. Will it be merged before > 2.6.30 final release? Thanks. > Hi Daniel. Check out 2.6.30-rc5-git1. Sergey.
Handled-By : Jeff Mahoney <jeffm@suse.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21183
*** Bug 13301 has been marked as a duplicate of this bug. ***
*** Bug 13299 has been marked as a duplicate of this bug. ***
*** Bug 13295 has been marked as a duplicate of this bug. ***
*** Bug 13251 has been marked as a duplicate of this bug. ***
Fix has been merged by Linux before 2.6.30-rc6.