Bugzilla – Full Text Bug Listing
|Summary:||"BUG: unable to handle kernel NULL pointer dereference at 0000000000000029" on OBS job|
|Product:||[openSUSE] openSUSE Tumbleweed||Reporter:||Oliver Kurz <okurz>|
|Component:||Kernel||Assignee:||E-mail List <kernel-maintainers>|
|Status:||RESOLVED WORKSFORME||QA Contact:||E-mail List <qa-bugs>|
|Priority:||P5 - None||CC:||adrian.schroeter, jslaby, nfbrown, okurz, rgoldwyn|
|Found By:||---||Services Priority:|
|Marketing QA Status:||---||IT Deployment:||---|
|Attachments:||full log file of failed OBS job with the kernel bug stack trace|
Description Oliver Kurz 2019-07-17 15:05:57 UTC
Comment 1 Jiri Slaby 2019-08-09 08:00:46 UTC
inode->i_flctx is 1 (rax) in this test in break_lease: if (inode->i_flctx && !list_empty_careful(&inode->i_flctx->flc_lease)) return __break_lease(inode, mode, FL_LEASE); Then, there is 0x28(%rax) in the code to fetch flc_lease which indeed crashes. Goldwyn, any idea how this could happen? Or who else could know? I don't see any fixes post 5.1 in this area, so I suppose this was not fixed upstream yet?
Comment 2 Goldwyn Rodrigues 2019-08-09 15:05:43 UTC
inode->i_flctx should clearly be a pointer. The only way it can have 0x1 is corruption. Without a dump this may be difficult to diagnose. Adding Neil to check if he has seen something similar before.
Comment 3 Neil Brown 2019-08-12 07:40:50 UTC
> Adding Neil to check if he has seen something similar before. No, I haven't seen anything like this. I agree with your analysis.
Comment 4 Jiri Slaby 2019-08-12 09:22:25 UTC
(In reply to Goldwyn Rodrigues from comment #2) > Without a dump this may be difficult to diagnose. Could you setup kdump on OBS workers somehow?
Comment 5 Oliver Kurz 2019-08-12 19:12:05 UTC
no, sorry. Not possible for myself. I don't have that kind of access to OBS workers. I suggest you get in contact with the administrators of the OBS instance or declare the bug as "WORKSFORME" because I have not seen this again so it might not be easily reproducible anyway.
Comment 6 Jiri Slaby 2019-10-31 11:58:30 UTC
If you see it again, feel free to reopen.