I was able to reproduce this on -42.el5. GFS2: can't parse mount arguments BUG: unable to handle kernel NULL pointer dereference at virtual address 0000062c printing eip: c0438933 *pde = e6e55067 Oops: 0002 [#1] SMP last sysfs file: /fs/gfs2/morph-cluster:morph-cluster8/lock_module/block Modules linked in: gnbd(U) lock_nolock gfs(U) lock_dlm gfs2 dlm configfs autofs4 hidp rfcomm l2cap bluetooth sunrpc ipv6 dm_multipath video sbs backlight i2c_ec button battery asus_acpi ac lp parport_pc i2c_i801 floppy parport ide_cd intel_rng i2c_core e7xxx_edac sg cdrom edac_mc e1000 pcspkr dm_snapshot dm_zero dm_mirror dm_mod qla2xxx scsi_transport_fc ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd CPU: 1 EIP: 0060:[<c0438933>] Not tainted VLI EFLAGS: 00010246 (2.6.18-42.el5 #1) EIP is at down_write+0xf/0x19 eax: 0000062c ebx: 0000062c ecx: f7aa1740 edx: ffff0001 esi: 00000000 edi: 0000062c ebp: f6099280 esp: ea845d60 ds: 007b es: 007b ss: 0068 Process mount.gfs2 (pid: 6315, ti=ea845000 task=f7529550 task.ti=ea845000) Stack: 00000000 f8d34b34 c327e23c f8d55060 00000000 f8d55060 c327e200 f6099280 f8d34de3 c327e200 f8d39cbd c327e200 c047574b ffffffea 00000000 c0475d2b 332d6d64 f7850600 c0678c80 000080d0 c0678c80 f7529550 c0458d4e 00000044 Call Trace: [<f8d34b34>] gfs2_log_flush+0x18/0x2bd [gfs2] [<f8d34de3>] gfs2_meta_syncfs+0xa/0x31 [gfs2] [<f8d39cbd>] gfs2_kill_sb+0x19/0x21 [gfs2] [<c047574b>] deactivate_super+0x52/0x65 [<c0475d2b>] get_sb_bdev+0xdb/0x110 [<c0458d4e>] __alloc_pages+0x57/0x282 [<f8d39cd9>] gfs2_get_sb+0x14/0x30 [gfs2] [<f8d3a945>] fill_super+0x0/0x51a [gfs2] [<c04757db>] vfs_kern_mount+0x7d/0xf2 [<c0475882>] do_kern_mount+0x25/0x36 [<c04883c2>] do_mount+0x5d6/0x646 [<c0436025>] autoremove_wake_function+0x0/0x2d [<c05a2fd8>] do_sock_read+0xae/0xb7 [<c05a356b>] sock_aio_read+0x53/0x61 [<c0458a7d>] get_page_from_freelist+0x96/0x310 [<c0487357>] copy_mount_options+0xaa/0x109 [<c048849f>] sys_mount+0x6d/0xa5 [<c0404eff>] syscall_call+0x7/0xb ======================= Code: 0f c1 10 78 41 c3 ba ff ff 00 00 f0 0f c1 10 75 42 c3 f0 81 00 00 00 01 00 78 45 c3 53 89 c3 e8 02 b7 1c 00 ba 01 00 ff ff 89 d8 <f0> 0f c1 10 85 d2 75 38 5b c3 53 89 c3 e8 e9 b6 1c 00 89 d8 f0 EIP: [<c0438933>] down_write+0xf/0x19 SS:ESP 0068:ea845d60 <0>Kernel panic - not syncing: Fatal exception
Created attachment 164441 [details] check for NULL sdp in gfs2_kill_sb This patch should fix the problem. Basically, when you try to mount gfs2 with -o garbage, the mount fails and the gfs2 superblock is deallocated and becomes NULL. The vfs comes around later on and calls gfs2_kill_sb. At this point the hidden gfs2 superblock pointer (sb->s_fs_info) is NULL and dereferencing it through gfs2_meta_syncfs causes the panic. (the other function call to gfs2_delete_debugfs_file() succeeds because this function already checks for a NULL pointer)
Tested and verified against kernel-2.6.18-43.gfs2abhi.001.
Changing summary so that it's not confused with other bug #253289
Posted fix to rhkernel-list: http://post-office.corp.redhat.com/archives/rhkernel-list/2007-August/msg00826.html
in 2.6.18-44.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0959.html