Bug 150270 - Unable to handle kernel NULL pointer dereference
Unable to handle kernel NULL pointer dereference
Status: CLOSED DUPLICATE of bug 147638
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-03-03 21:51 EST by Jeff Burke
Modified: 2015-01-04 17:17 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-03 22:01:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Script that reproduces the issue (5.27 KB, text/plain)
2005-03-03 21:58 EST, Jeff Burke
no flags Details

  None (edit)
Description Jeff Burke 2005-03-03 21:51:11 EST
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: 
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):

How reproducible:

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
Comment 1 Jeff Burke 2005-03-03 21:58:52 EST
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 &);
Comment 2 Jeff Burke 2005-03-03 22:01:14 EST

*** This bug has been marked as a duplicate of 147638 ***
Comment 3 dave bashaw 2012-05-06 21:11:12 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.