Bug 151072 - crash in __d_lookup due to "Unable to handle kernel paging request"
crash in __d_lookup due to "Unable to handle kernel paging request"
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-14 11:16 EST by satish
Modified: 2015-01-04 17:17 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 01:35:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description satish 2005-03-14 11:16:27 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9)
Gecko/20020408

Description of problem:
I am seeing this bug a lots of times. This is becos the dentry has
junk pointer.

Unable to handle kernel paging request at virtual address 80badb9b /g
printing eip:

c016654b
*pde = 1165b001
Oops: 0000 [#1]
SMP
Modules linked in: panfs nfsd exportfs ipv6 parport_pc lp parport nfs
lockd sunrpc e100 mii floppy sg microcode dm_mod ohci_hcd button
battery asus_acpi ac aic7xxx sd_mod scsi_mod
CPU: 0
EIP: 0060:[<c016654b>] Tainted: P
EFLAGS: 00010282 (2.6.6-1.435.2.3.lair6smp)
EIP is at __d_lookup+0x67/0x10b
eax: 80badb9b ebx: dd1ad720 ecx: 818d485a edx: c1520000
esi: d8047f2c edi: d8047ee0 ebp: 80badb9b esp: d8047e84
ds: 007b es: 007b ss: 0068
rocess perl (pid: 20032, threadinfo=d8044000 task=d981c750

MStack: 00000000 c1536738 d2e90015 818d485a 00000009 d8047ee0 dd3b9608
818d485a
d8047f2c d8047ee0 d8047ed8 c015d7dc dff738e0 818d485a fffffdee c5683320
d8047f2c c015de8a 00000001 00000000 d2e9001e dff738e0 dd3b9608 818d485a
Call Trace:
[<c015d7dc>] do_lookup+0x18/0x72
[<c015de8a>] link_path_walk+0x654/0x874
[<c015e397>] path_lookup+0x13f/0x16f
[<c015e4d3>] __user_walk+0x21/0x51
[<c0159ef7>] vfs_stat+0x14/0x3a
[<c011d4ae>] scheduler_tick+0x28f/0x425
[<c015a4d7>] sys_stat64+0xf/0x23

<c0117383>] smp_apic_timer_interrupt+0x124/0x129
[<c02c55cb>] syscall_call+0x7/0xb
[<c02c007b>] unix_stream_recvmsg+0x6/0x3af

Code: 8b 45 00 0f 18 00 90 8d 5d 90 f0 83 44 24 00 00 8b 4c 24 0c




 (gdb) bt  
#0  0xc0169bd0 in __d_lookup (parent=0xec3f4220, name=0xd473bf78) at
processor.h:660  
#1  0xc01608ee in cached_lookup (parent=0xec3f4220, name=0xd473bf78,
nd=0x0)  
    at fs/namei.c:287  
#2  0xc01617fe in __lookup_hash (name=0xd473bf78, base=0xec3f4220,
nd=0x0) at fs/namei.c:958  
#3  0xc01621df in lookup_create (nd=0xd473bf70, is_dir=1) at
fs/namei.c:1472  
#4  0xc01625f5 in sys_mkdir (pathname=0x4d4d4d4d <Address 0x4d4d4d4d
out of bounds>,  
    mode=511) at fs/namei.c:1598  
#5  0xc02d241f in syscall_call () at uaccess.h:516  
#6  0x09f007a0 in ?? ()  
#7  0x000001ff in ?? ()  
#8  0x0000013c in ?? ()  
#9  0x09f005f8 in ?? ()  
#10 0xb8097060 in ?? ()  
#11 0xbff22728 in ?? ()  
#12 0x00000027 in ?? ()  
#13 0xc02d007b in .text.lock.af_packet () at net/packet/af_packet.c:1858  
  
 
gdb) fr 0 
#0  0xc0169bd0 in __d_lookup (parent=0xec3f4220, name=0xd473bf78) at
processor.h:660 
660     in processor.h 
(gdb) p *parent 
$1 = {d_count = {counter = 3}, d_flags = 8, d_lock = {lock = 1},
d_inode = 0xc5ecc080, 
  d_parent = 0xec3f42bc, d_bucket = 0xf7f4e9f8, d_name = {hash =
282957070, 
    name = 0xec3f4298 "d_Rlk", len = 5}, d_lru = {next = 0xec3f42e0,
prev = 0xec3f41a8}, 
  d_child = {next = 0xec3f42f0, prev = 0xca97bad4}, d_subdirs = {next
= 0xdc774de0, 
    prev = 0xec3f41b0}, d_alias = {next = 0xc5ecc090, prev = 0xc5ecc090}, 
  d_time = 1109008540, d_op = 0xfa70ac54, d_sb = 0xf71ede00, d_mounted
= 0, d_fsdata = 0x0, 
  d_extra_attributes = 0x0, d_rcu = {list = {next = 0x15e82404, prev =
0x8dffffe9}, 
    func = 0xffbf3085, arg = 0x240489ff}, d_cookie = 0x0, d_hash =
{next = 0xf5fede24, 
    pprev = 0xd830f290}, d_iname = "d_Rlk\000\022���\215e�\211�[^_��
\203�\bh��:\b�u\b����"} 
(gdb) p name 
$2 = (struct qstr *) 0xd473bf78 
(gdb) p *name 
$3 = {hash = 440507695, name = 0xe4b58072 "d_oNRQvamNStrgO", len = 15} 
(gdb) p found 
$4 = (struct dentry *) 0x0 
(gdb) p str 
$5 = (const unsigned char *) 0xe4b58072 "d_oNRQvamNStrgO" 
(gdb) p head 
$8 = {0x0 <repeats 32 times>}


I saw a few links with related issues as 
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01279.html

http://www.ussg.iu.edu/hypermail/linux/kernel/0407.3/1187.html

http://www.thisishull.net/archive/index.php/t-31212.html

https://bugzilla.redhat.com/beta/show_bug.cgi?id=128670

http://www.webservertalk.com/message333123-4.html

http://lkml.org/lkml/2004/10/1/101

Is there any patch available ?

Version-Release number of selected component (if applicable):
kernel  2.6.6-1.435.2.3

How reproducible:
Always

Steps to Reproduce:
1. Run a few compiles annd the machine crashes after a few hrs
2.
3.
    

Actual Results:  crashes

Expected Results:  work fine

Additional info:
Comment 1 Dave Jones 2005-04-16 01:35:46 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

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