Latest working kernel version: Earliest failing kernel version: 2.6.27-rc3 Distribution: Debian Hardware Environment: Software Environment: Problem Description: Steps to reproduce: Freshly created fs using: mkfs -E test_fs -t ext3 /dev/cciss/c0d0p8 tune2fs -O extents -E test_fs /dev/cciss/c0d0p8 then mounted via: mount /squid-cache0 from fstab: # <file system> <mount point> <type> <options> <dump> <pass> /dev/cciss/c0d0p8 /squid-cache0 auto defaults,noatime,nodev,noexec,errors=panic 0 1 results in: /dev/cciss/c0d0p8 on /squid-cache0 type ext4dev (rw,noexec,nodev,noatime,errors=panic) in dmesg I get: [ 5.586583] proc_dir_entry 'stats' already registered complete dmesg (attached)
Created attachment 17221 [details] dmesg.output
Do you know if 2.6.26 was OK? Thanks.
Hard to tell, I know that my last tests (which are a while back) didn't expose that problem. 2.6.25 or 2.6.26 I could retry with 2.6.26.2
2.6.26.2 gives the same message: [ 5.792376] kjournald2 starting. Commit interval 5 seconds [ 5.794054] EXT4 FS on cciss/c0d0p8, internal journal [ 5.794054] EXT4-fs: mounted filesystem with ordered data mode. [ 5.794054] EXT4-fs: file extents enabled [ 5.794372] EXT4-fs: mballoc enabled [ 5.818376] kjournald2 starting. Commit interval 5 seconds [ 5.825571] EXT4 FS on cciss/c0d0p9, internal journal [ 5.825571] EXT4-fs: mounted filesystem with ordered data mode. [ 5.825571] EXT4-fs: file extents enabled [ 5.825571] proc_dir_entry 'stats' already registered [ 5.825571] Pid: 643, comm: mount Not tainted 2.6.26.2 #1 [ 5.825571] [<c019b49a>] proc_register+0xc7/0x13a [ 5.825571] [<c019b5fb>] create_proc_entry+0x54/0x8c [ 5.825571] [<f8abe0e5>] ext4_mb_init+0x4a5/0x86e [ext4dev] [ 5.825571] [<c011a7a7>] __wake_up+0x32/0x42 [ 5.826337] [<c0122cc5>] printk+0x1b/0x1f [ 5.826425] [<f8ab0b99>] ext4_fill_super+0x1605/0x1eb8 [ext4dev] [ 5.826525] [<c01d9cc7>] snprintf+0x1f/0x23 [ 5.826614] [<c01a01e8>] disk_name+0x72/0xa6 [ 5.826704] [<c016cf2f>] get_sb_bdev+0xea/0x10d [ 5.826794] [<c01d53b4>] idr_pre_get+0x17/0x38 [ 5.826883] [<f8aad990>] ext4_get_sb+0x20/0x25 [ext4dev] [ 5.826980] [<f8aaf594>] ext4_fill_super+0x0/0x1eb8 [ext4dev] [ 5.827076] [<c016c9d0>] vfs_kern_mount+0x37/0x88 [ 5.827165] [<c016ca68>] do_kern_mount+0x31/0xbc [ 5.827251] [<c0180225>] do_new_mount+0x69/0x8e [ 5.827346] [<c01803ad>] do_mount+0x163/0x1ab [ 5.827435] [<c017e282>] copy_mount_options+0x28/0x113 [ 5.827525] [<c0172745>] getname+0x8c/0x9b [ 5.827612] [<c018046c>] sys_mount+0x77/0xbb [ 5.827700] [<c0103a5a>] syscall_call+0x7/0xb [ 5.827790] =======================
2.6.26: same problem
with 2.6.25.10: [ 0.677898] kjournald2 starting. Commit interval 5 seconds [ 1.507773] EXT4 FS on cciss/c0d0p8, internal journal [ 1.507773] EXT4-fs: mounted filesystem with ordered data mode. [ 1.507773] EXT4-fs: file extents enabled [ 1.507773] EXT4-fs: mballoc enabled [ 0.680897] kjournald2 starting. Commit interval 5 seconds [ 1.511772] EXT4 FS on cciss/c0d0p9, internal journal [ 1.511778] EXT4-fs: mounted filesystem with ordered data mode. [ 1.511833] EXT4-fs: file extents enabled [ 1.511945] proc_dir_entry 'stats' already registered [ 1.511999] Pid: 634, comm: mount Not tainted 2.6.25.10 #1 [ 1.512053] [<c0197a08>] proc_register+0xc7/0x13a [ 1.512147] [<c0197b62>] create_proc_entry+0x54/0x8c [ 1.512235] [<f8ac45c9>] ext4_mb_init+0x464/0x84b [ext4dev] [ 1.512337] [<c0119829>] __wake_up+0x32/0x42 [ 1.512425] [<c01205fd>] printk+0x1b/0x1f [ 1.512514] [<f8ab6cb5>] ext4_fill_super+0x1711/0x1e98 [ext4dev] [ 1.512614] [<c01d5438>] snprintf+0x1f/0x23 [ 1.512704] [<c019c778>] disk_name+0x72/0xa6 [ 1.512823] [<c016970e>] get_sb_bdev+0xe9/0x10c [ 1.512915] [<f8ab3870>] ext4_get_sb+0x20/0x25 [ext4dev] [ 1.513011] [<f8ab55a4>] ext4_fill_super+0x0/0x1e98 [ext4dev] [ 1.513107] [<c01691b0>] vfs_kern_mount+0x37/0x88 [ 1.513195] [<c0169248>] do_kern_mount+0x31/0xbc [ 1.513284] [<c017bd41>] do_new_mount+0x69/0x8e [ 1.513373] [<c017bebd>] do_mount+0x157/0x19f [ 1.513461] [<c017a225>] copy_mount_options+0x28/0x113 [ 1.513550] [<c016ee85>] getname+0x8c/0x9b [ 1.513637] [<c017bf7c>] sys_mount+0x77/0xbb [ 1.513723] [<c0103a36>] syscall_call+0x7/0xb [ 1.513824] =======================
Does this problem still exist if you mount it explicitly? Like this: mkfs -E test_fs -t ext3 /dev/cciss/c0d0p8 tune2fs -O extents -E test_fs /dev/cciss/c0d0p8 then mounted via: mount -t ext4dev /dev/cciss/c0d0p8 /squid-cache0 Also I noticed from dmesg log that the "proc_dir_entry 'stats' already registered" messages was coming from the second ext4 filesystem /dev/cciss/c0d0p9, ext4 on /dev/cciss/c0d0p8 was successfully mounted: [ 5.561423] EXT4 FS on cciss/c0d0p8, internal journal [ 5.561423] EXT4-fs: mounted filesystem with ordered data mode. [ 5.561423] EXT4-fs: delayed allocation enabled [ 5.561423] EXT4-fs: file extents enabled [ 5.561423] EXT4-fs: mballoc enabled [ 5.569001] kjournald2 starting. Commit interval 5 seconds [ 5.586583] EXT4 FS on cciss/c0d0p9, internal journal [ 5.586583] EXT4-fs: mounted filesystem with ordered data mode. [ 5.586583] EXT4-fs: delayed allocation enabled [ 5.586583] EXT4-fs: file extents enabled [ 5.586583] proc_dir_entry 'stats' already registered [ 5.586583] Pid: 655, comm: mount Not tainted 2.6.27-rc3 #1
In that case it seems to work...
need to retract my statement, since my dmesg output is cluttered. Gotta start from scratch...
Something is chopping partition number internally, methinks, so base directory remains the same and proc complains. Ralf, please, add printk("%s: devname = '%s'\n", __func__, devname); right after bdevname() call in ext4_mb_init_per_dev_proc() (any kernel) and retest.
New dmesg output with additional printk...
Created attachment 17637 [details] dmes output with additional printk()
Uh-oh, proc assumes that everything but last path component already created. There is /proc/stats , /proc/max_to_scan ..., right?
So it seems: proxy-cvk-1:~# ll /proc/stats /proc/max_to_scan -rw-r--r-- 1 root root 0 Sep 5 22:45 /proc/max_to_scan -rw-r--r-- 1 root root 0 Sep 5 22:45 /proc/stats
Patch testing time http://marc.info/?l=linux-ext4&m=122064879204828&w=2
That patch makes the error go away. Big cheers!
This patch is in mainline, closing.