Bug 11321
| Summary: | ext4 mount problem (proc_dir_entry 'stats' already registered) | ||
|---|---|---|---|
| Product: | File System | Reporter: | Ralf Hildebrandt (ralf.hildebrandt) |
| Component: | ext4 | Assignee: | Alexey Dobriyan (adobriyan) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | akpm |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.27-rc3 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
dmesg.output
dmes output with additional printk() |
||
|
Description
Ralf Hildebrandt
2008-08-13 11:15:06 UTC
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. |