Description of problem: Kel Modderman reported that it is possible to trigger the BUG_ON() in shmem_delete_inode function of mm/shmem.c, while running the insserv program in a directory on a tmpfs mount point. insserv is SuSE's SysV initscript ordering program. It creates, removes and overwrites many files, directories and symlinks in a specific directory hierachy, and tries to do so as quickly and efficiently as possible. It includes a testsuite as well. http://lkml.org/lkml/2008/7/26/71
Proposed upstream patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=14fcc23fdc78e9d32372553ccf21758a9bd56fa1
Created attachment 313169 [details] insserv for reproducing the bug http://users.tpg.com.au/sigm/misc/insserv-1.11.10-shmem.tar.gz
Steps to reproduce the problem is documented in http://lkml.org/lkml/2008/7/26/71. The only difference is that I used /dev/shm instead of /var/tmp. $ mount | grep tmpfs tmpfs on /dev/shm type tmpfs (rw)
I am able to trigger the BUG_ON() by running the testsuite on /dev/shm tmpfs mount point. Note that the x86/x86_64 architecture-specific implementation of BUG() does not panic the machine. ------------[ cut here ]------------ kernel BUG at mm/shmem.c:779! invalid opcode: 0000 [#2] PREEMPT SMP Modules linked in: nfs lockd nfs_acl autofs4 hidp rfcomm l2cap bluetooth sunrpc ipv6 cpufreq_ondemand dm_multipath video output sbs sbshc battery ac parport_pc lp parport sg snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq floppy snd_seq_device snd_pcm_oss snd_mixer_oss sr_mod serio_raw cdrom pata_atiixp snd_pcm pata_acpi button snd_timer i2c_piix4 k8temp tg3 hwmon snd_page_alloc ata_generic i2c_core snd_hwdep snd ati_agp soundcore pcspkr dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd Pid: 4136, comm: rm Tainted: G D (2.6.24.7-75.el5rt #1) EIP: 0060:[<c048684e>] EFLAGS: 00010202 CPU: 0 EIP is at shmem_delete_inode+0xc6/0xfb EAX: 00000008 EBX: c0486788 ECX: c0745f00 EDX: d4548878 ESI: d4548878 EDI: e5d0d984 EBP: d4596ee8 ESP: d4596ed4 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 preempt:00000001 Process rm (pid: 4136, ti=d4596000 task=f74c2850 task.ti=d4596000) Stack: d4548878 f64abb40 c0486788 d4548878 e5d0d984 d4596ef8 c049cbdc d4548878 d4548878 d4596f04 c049c406 e5d0d97c d4596f20 c049a465 00000000 00000000 e5d0d97c e5d0d984 d45c7000 d4596f30 c049a50c e5d0d97c e5d0d984 d4596f40 Call Trace: [<c0486788>] ? shmem_delete_inode+0x0/0xfb [<c049cbdc>] ? generic_delete_inode+0x96/0x100 [<c049c406>] ? iput+0x63/0x66 [<c049a465>] ? dentry_iput+0x88/0xa2 [<c049a50c>] ? d_kill+0x30/0x4a [<c049a844>] ? dput+0xe1/0xea [<c0494a14>] ? do_rmdir+0x92/0xbb [<c0406ea8>] ? do_syscall_trace+0x14c/0x198 [<c0494a7c>] ? sys_rmdir+0x10/0x12 [<c040414e>] ? syscall_call+0x7/0xb ======================= Code: 45 ec 8b 50 f8 8b 43 04 89 42 04 89 10 8b 55 ec b8 80 59 74 c0 89 5b 04 89 5a f8 e8 0f 5a 1a 00 8b 55 ec 8b 42 64 0b 42 68 74 04 <0f> 0b eb fe 8b 45 f0 83 78 08 00 74 19 89 c3 83 c3 18 89 d8 e8 EIP: [<c048684e>] shmem_delete_inode+0xc6/0xfb SS:ESP 0068:d4596ed4 ---[ end trace 3e3c2138bcf04563 ]--- crash> hex output radix: 16 (hex) crash> dis -r shmem_delete_inode+0xc6 [...] 0xc048683e <shmem_delete_inode+0xb6>: call 0xc062c252 0xc0486843 <shmem_delete_inode+0xbb>: mov 0xffffffec(%ebp),%edx 0xc0486846 <shmem_delete_inode+0xbe>: mov 0x64(%edx),%eax 0xc0486849 <shmem_delete_inode+0xc1>: or 0x68(%edx),%eax 0xc048684c <shmem_delete_inode+0xc4>: je 0xc0486852 0xc048684e <shmem_delete_inode+0xc6>: ud2a
Created attachment 313174 [details] Proposed backported patch
(In reply to comment #4) > I am able to trigger the BUG_ON() by running the testsuite on /dev/shm tmpfs > mount point. Note that the x86/x86_64 architecture-specific implementation of > BUG() does not panic the machine. And this is because on mrg kernel, /proc/sys/kernel/panic_on_oops is 0 by default, unlike the rhel kernels.
(In reply to comment #5) > Created an attachment (id=313174) [edit] > Proposed backported patch This is for the real-time kernel.
Luis, please include upstream commit d847471d063663b9f36927d265c66a270c0cfaab to the patch you backported. There's a regression introduced in 14fcc23fdc78e9d32372553ccf21758a9bd56fa1.
Created attachment 314678 [details] Additional upstream patch for this issue
Patch modified and added to the -78 queue. Note: this patch may also fix the issue reported in BZ458487.
This was addressed via: MRG Realtime for RHEL 5 Server (RHSA-2008:0857)