Bug 13151 - Warning about reiserfs
Summary: Warning about reiserfs
Status: CLOSED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: ReiserFS (show other bugs)
Hardware: All Linux
: P1 low
Assignee: ReiseFS developers team
URL:
Keywords:
: maluta 13295 13299 13301 (view as bug list)
Depends on:
Blocks: 13070
  Show dependency tree
 
Reported: 2009-04-22 19:07 UTC by Dâniel Fraga
Modified: 2009-05-16 21:01 UTC (History)
7 users (show)

See Also:
Kernel Version: 2.6.30-rc3
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
[PATCH] reiserfs: Expand i_mutex to enclose lookup_one_len (3.96 KB, text/plain)
2009-05-01 15:59 UTC, Jeff Mahoney
Details

Description Dâniel Fraga 2009-04-22 19:07:51 UTC
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.
Comment 1 Andrew Morton 2009-04-22 19:20:42 UTC
marked as a regression..
Comment 2 Jeff Mahoney 2009-04-22 19:40:45 UTC
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.
Comment 3 Rafael J. Wysocki 2009-04-25 21:11:26 UTC
First-Bad-Commit : 2f9092e1020246168b1309b35e085ecd7ff9ff72
Handled-By : Jeff Mahoney <jeffm@suse.com>
Comment 4 Sergey Senozhatsky 2009-04-27 11:51:53 UTC
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.
Comment 5 Duncan 2009-04-27 16:30:18 UTC
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.
Comment 6 Dâniel Fraga 2009-05-01 10:30:40 UTC
Still present at 2.6.30-rc4.
Comment 7 Jeff Mahoney 2009-05-01 15:59:51 UTC
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.
Comment 8 Dâniel Fraga 2009-05-01 16:27:51 UTC
(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 9 Sergey Senozhatsky 2009-05-01 22:04:01 UTC
> --- 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.
Comment 10 Dâniel Fraga 2009-05-09 22:36:56 UTC
(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.
Comment 11 Sergey Senozhatsky 2009-05-11 16:34:19 UTC
> 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.
Comment 12 Rafael J. Wysocki 2009-05-13 10:41:05 UTC
Handled-By : Jeff Mahoney <jeffm@suse.com>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=21183
Comment 13 Stefan Richter 2009-05-16 20:59:13 UTC
*** Bug 13301 has been marked as a duplicate of this bug. ***
Comment 14 Stefan Richter 2009-05-16 20:59:51 UTC
*** Bug 13299 has been marked as a duplicate of this bug. ***
Comment 15 Stefan Richter 2009-05-16 21:00:44 UTC
*** Bug 13295 has been marked as a duplicate of this bug. ***
Comment 16 Stefan Richter 2009-05-16 21:01:18 UTC
*** Bug 13251 has been marked as a duplicate of this bug. ***
Comment 17 Stefan Richter 2009-05-16 21:01:56 UTC
Fix has been merged by Linux before 2.6.30-rc6.

Note You need to log in before you can comment on or make changes to this bug.