From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: Unable to handle kernel NULL pointer dereference at 0000000000000030 RIP: <ffffffff801ab2aa>{sysfs_readdir+333} PML4 fa3c067 PGD 17d98067 PMD 0 Oops: 0000 [1] SMP CPU 0 Modules linked in: md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc ds yenta_socket pd Pid: 29145, comm: scsi_id Not tainted 2.6.9-6.16.ELsmp RIP: 0010:[<ffffffff801ab2aa>] <ffffffff801ab2aa>{sysfs_readdir+333} RSP: 0018:000001003be95eb8 EFLAGS: 00010206 RAX: 0000000000000000 RBX: 000001013fc10f88 RCX: 0000000000000009 RDX: 000001013fc10f48 RSI: ffffffff80315d8f RDI: ffffffff80322cac RBP: 000001013fc10f80 R08: 0000000000000a39 R09: 0000000000000005 R10: 000001003be95e78 R11: 0000000000000048 R12: ffffffff80322ca2 R13: 000001009abc5e48 R14: 00000101251f9480 R15: 000001013fc11140 FS: 0000002a95582de0(0000) GS:ffffffff804c0a80(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000030 CR3: 0000000000101000 CR4: 00000000000006e0 Process scsi_id (pid: 29145, threadinfo 000001003be94000, task 00000100a1e0a7f0) Stack: 0000000900000000 ffffffff8018381c 000001003be95f38 00000000fffffffe 00000101251f9480 000001013f4a1918 ffffffff8018381c 000001003be95f38 000000000050d610 ffffffff8018355b Call Trace:<ffffffff8018381c>{filldir64+0} <ffffffff8018381c>{filldir64+0} <ffffffff8018355b>{vfs_readdir+155} <ffffffff8018394c>{sys_getdents64+118} <ffffffff80110ad1>{error_exit+0} <ffffffff80110036>{system_call+126} Code: 48 8b 40 30 eb 11 48 8b 3d 11 5c 2c 00 be 02 00 00 00 e8 fc RIP <ffffffff801ab2aa>{sysfs_readdir+333} RSP <000001003be95eb8> CR2: 0000000000000030 <0>Kernel panic - not syncing: Oops Version-Release number of selected component (if applicable): kernel-2.6.9-6.16 How reproducible: Sometimes Steps to Reproduce: 1.execute regression.sh scsi_id 6 Actual Results: Regression script starts. Runs for several hours. Then Oops. Expected Results: System should remain operational. Additional info: This was originally seen with a test from Doug L. He tested a patch and it appered to be fixed. I created a regression script to test and make sure it was fixed in the offical build. The patch was applied to 2.6.9-6.16 *confirmed by Dave Jones*. [PATCH] sysfs: fix sysfs_dir_close memory leak
Created attachment 111651 [details] Script that reproduces the issue The system configuration is a Dell PowerEdge 2850 with 2 3.6GHz Xeon 4Gig of ram running x86_64 2.6.9-6.16 SMP kernel. It has a HP attached storage array. Doug L original reproducer was this. following caused it: i=0; while [ "$i" -lt "10" ]; do i=`expr $i + 1`; (while true; do /sbin/scsi_id -g -s /block/sde -p 0x80 > /dev/null 2>&1; done &); done
*** This bug has been marked as a duplicate of 147638 ***
Is the patch file still available? I could really use it. I have a 2.6.9 doing the same thing. All I find goggling is a back-port patch from 2.6.22.to 2.6.16 which is not helpful at all.