Bug 1381363 - Multiple oops in 4.8.0
Summary: Multiple oops in 4.8.0
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-03 20:43 UTC by darrell pfeifer
Modified: 2016-10-18 13:31 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-18 13:31:49 UTC
Type: Bug


Attachments (Terms of Use)
journalctl output for the boot (134.77 KB, text/x-vhdl)
2016-10-03 20:43 UTC, darrell pfeifer
no flags Details

Description darrell pfeifer 2016-10-03 20:43:25 UTC
Created attachment 1206986 [details]
journalctl output for the boot

Description of problem

Multiple oops on boot.


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

4.8.0-1.fc26.x86_64

Additional info:

Booted back to rc8, which was ok. Rebooted again into 4.8.0 final and there wasn't an oops.

Comment 1 Laura Abbott 2016-10-03 21:55:42 UTC
Just to clarify, this oops was only seen once?

Comment 2 darrell pfeifer 2016-10-03 21:57:11 UTC
Yes, just happened once. The next reboot it was gone. Not sure if it is a timing problem, so will just have to watch reboots to see if it happens again.

Comment 3 Laura Abbott 2016-10-03 22:03:32 UTC
I suspect it may be a random bit flip. The crash occurred in the memory allocator so everything that attempted to allocate crashed. We can monitor and see if it re-occurs.

Comment 4 Neil Horman 2016-10-18 13:31:24 UTC
I agree, this seems like an oddity.  Either it was a bit flip, or the slab allocator returned a pointer so large that when get_alloc_info computed the kasan offset, it overflowed to exactly zero/NULL.  Either way it needs to be reproducible to make progress.

Comment 5 Neil Horman 2016-10-18 13:31:24 UTC
I agree, this seems like an oddity.  Either it was a bit flip, or the slab allocator returned a pointer so large that when get_alloc_info computed the kasan offset, it overflowed to exactly zero/NULL.  Either way it needs to be reproducible to make progress.

Comment 6 Neil Horman 2016-10-18 13:31:49 UTC
please repoen if it occurs again


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