Bug 173218 - audit_inode causes an Oops after some time
Summary: audit_inode causes an Oops after some time
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: David Woodhouse
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-15 05:32 UTC by Thomas M Steenholdt
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-02 06:18:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
First log I have of the Oops (2.6.14-1.1657_FC5) (3.47 KB, text/plain)
2005-11-15 05:32 UTC, Thomas M Steenholdt
no flags Details
Second loged Oops (2.6.14-1.1665_FC5) (3.52 KB, text/plain)
2005-11-15 05:33 UTC, Thomas M Steenholdt
no flags Details

Description Thomas M Steenholdt 2005-11-15 05:32:51 UTC
Description of problem:

After running for some interval of time (within 24 hours is all i've seen),
audit_inode is causing a kernel Oops.

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

Currently confirmed on my system with kernels 2.6.14-1.1657_FC5, 2.6.14-1.1665_FC5

How reproducible:

So far, always

Steps to Reproduce:
1. Turn the system on
2. Wait

Actual results:


Expected results:

No Oops

Additional info:

It appears as if the Oops occurs after a few crond (pam_unix) messages in the
log at *:10:01 (only recorded this twice) each time, so that might be triggered
by that somehow.

Comment 1 Thomas M Steenholdt 2005-11-15 05:32:51 UTC
Created attachment 121047 [details]
First log I have of the Oops (2.6.14-1.1657_FC5)

Comment 2 Thomas M Steenholdt 2005-11-15 05:33:43 UTC
Created attachment 121048 [details]
Second loged Oops (2.6.14-1.1665_FC5)

Comment 3 Thomas M Steenholdt 2005-11-15 05:39:00 UTC
Let me just throw an Oops example here to make it easier to find duplicates and
such without opening attachments:

kernel: EIP:    0060:[<c014171e>]    Not tainted VLI
kernel: EFLAGS: 00010286   (2.6.14-1.1657_FC5)
kernel: EIP is at audit_inode+0x79/0xae
kernel: eax: f747a000   ebx: 6b6b6b6b   ecx: f41c8f60   edx: f41c8f60
kernel: esi: 00000000   edi: f747a000   ebp: 00000101   esp: df74aea4
kernel: ds: 007b   es: 007b   ss: 0068
kernel: Process sadc (pid: 16910, threadinfo=df74a000 task=f0a09570)
kernel: Stack: fffffffe df74af44 f747a000 f747a000 c016ee47 00000101 df74af44
kernel:        ffffffe9 f747a000 c016ee86 00000001 df74af44 00000004 df74af44
kernel:        00000001 00000000 f747a000 c016f574 00000001 de128b7c 00000001
kernel: Call Trace:
kernel:  [<c016ee47>] path_lookup+0x1a0/0x1a5
kernel:  [<c016ee86>] __path_lookup_intent_open+0x3a/0x6f
kernel:  [<c016eed3>] path_lookup_open+0x18/0x1d
kernel:  [<c016f574>] open_namei+0x70/0x62f
kernel:  [<c014a1a4>] poison_obj+0x20/0x3d
kernel:  [<c014a398>] check_poison_obj+0x24/0x17b
kernel:  [<c01414cc>] audit_syscall_exit+0x2ba/0x391
kernel:  [<c016041a>] filp_open+0x1c/0x35
kernel:  [<c014bc69>] cache_alloc_debugcheck_after+0x2f/0x11b
kernel:  [<c01411bf>] audit_syscall_entry+0x10a/0x15d
kernel:  [<c01605e3>] get_unused_fd+0xa9/0xcb
kernel:  [<c0141610>] audit_getname+0x6d/0xd2
kernel:  [<c01606be>] do_sys_open+0x31/0xad
kernel:  [<c0102ec1>] syscall_call+0x7/0xb
kernel: Code: 8b 40 3c 85 c0 74 04 39 f8 74 51 83 fa 0c 7f 47 8d 42 01 89 41 38
89 d0 c1 e0 05 c7 44 08 3c 00 00 00 00 c1 e2 05 01 ca 89 6a 58 <8b> 43 20 89 42
40 8b 83 c4 00 00 00 8b 40 08 89 42 44 0f b7 43

Comment 4 Thomas M Steenholdt 2005-12-01 22:17:44 UTC
I haven't seen this in a while, however, the changelogs does not reveal anything
like this (to me) as being fixed???

Comment 5 Dave Jones 2005-12-02 06:18:39 UTC
If you refer to the Fedora kernel changelogs, they don't list every change.
Rebasing to a daily -git snapshot could bring in hundreds of upstream changes
for example.

I'll close it out, but if it reappears, don't hesitate to reopen.


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