BUG: unable to handle kernel NULL pointer dereference
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
BUG: unable to handle kernel NULL pointer dereference
I had the "unable to handle kernel NULL pointer dereference" message in syslog at 00:31 today (see log below). This machine was unresponsive after that until a reboot at 9:00 the next morning -- although it did respond to pings.
Any idea what this is about? There are some instructions at https://wiki.ubuntu.com/DebuggingKernelOops about submitting a bug report. However, that is for Canonical/Ubuntu. Is there a similar bug report location for Slackware? The referenced Ubuntu page has good information on this situation including decoding the 'Tainted' message. My Tainted flags are G, W and O which are: G - all modules loaded have a GPL or compatible license ; W - a warning has previously been issued by the kernel; O - not listed on that page.
Is filing a bug report advisable? Do I have a remedy to prevent this from happening again?
Slackware64 14.2, kernel 4.4.38
Code:
Jun 8 00:31:40 mail kernel: [226041.366182] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
Jun 8 00:31:40 mail kernel: [226041.366336] IP: [<ffffffff812102f1>] lock_get_status+0xa1/0x340
Jun 8 00:31:40 mail kernel: [226041.366492] PGD 2d0d74067 PUD 2d9550067 PMD 0
Jun 8 00:31:40 mail kernel: [226041.366649] Oops: 0000 [#1] SMP
Jun 8 00:31:40 mail kernel: [226041.366809] Modules linked in: cifs fscache nfnetlink_queue nfnetlink_log nfnetlink bluetooth rfkill xt_limit xt_recent nf_log_ipv4 nf_log_common xt_LOG xt_conntrack xt_nat xt_multiport xt_REDIRECT nf_nat_redirect xt_tcpudp ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_raw iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 fuse joydev hid_thingm hid_generic uas usb_storage usbhid i2c_dev coretemp hwmon intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm alx irqbypass snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi mxm_wmi evdev crct10dif_pclmul mdio crc32_pclmul crc32c_intel psmouse serio_raw snd_hda_intel battery i915 thermal i2c_hid sdhci_acpi sdhci iosf_mbi drm_kms_helper snd_hda_codec mmc_core dw_dmac fjes elan_i2c drm intel_gtt agpgart i2c_algo_bit fb_sys_fops syscopyarea hid snd_hda_core dw_dmac_core sysfillr
Jun 8 00:31:40 mail kernel: [226041.369120] CPU: 0 PID: 28884 Comm: lsof Tainted: G W O 4.4.38 #2
Jun 8 00:31:40 mail kernel: [226041.369478] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD5H/Z97X-UD5H, BIOS F8 06/17/2014
Jun 8 00:31:40 mail kernel: [226041.369849] task: ffff8803a694e200 ti: ffff88012dd58000 task.ti: ffff88012dd58000
Jun 8 00:31:40 mail kernel: [226041.370230] RIP: 0010:[<ffffffff812102f1>] [<ffffffff812102f1>] lock_get_status+0xa1/0x340
Jun 8 00:31:40 mail kernel: [226041.370625] RSP: 0018:ffff88012dd5bd68 EFLAGS: 00010286
Jun 8 00:31:40 mail kernel: [226041.371023] RAX: 0000000000000000 RBX: ffff88040a20bee0 RCX: 0000000000000000
Jun 8 00:31:40 mail kernel: [226041.371433] RDX: ffffffff821589fb RSI: ffffffff82158a26 RDI: ffff880400e5cfec
Jun 8 00:31:40 mail kernel: [226041.371850] RBP: ffff88012dd5bd98 R08: 0000000000001000 R09: 000000000000ffff
Jun 8 00:31:40 mail kernel: [226041.372275] R10: 0000000000000001 R11: ffff880400e5cfe4 R12: ffff880346162e40
Jun 8 00:31:40 mail kernel: [226041.372709] R13: ffff88040d898000 R14: 0000000000000ce6 R15: ffff88040a20bef8
Jun 8 00:31:40 mail kernel: [226041.373149] FS: 00007f75f6c99700(0000) GS:ffff88041fa00000(0000) knlGS:0000000000000000
Jun 8 00:31:40 mail kernel: [226041.373601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 8 00:31:40 mail kernel: [226041.374059] CR2: 0000000000000050 CR3: 000000031a821000 CR4: 00000000001426f0
Jun 8 00:31:40 mail kernel: [226041.374528] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun 8 00:31:40 mail kernel: [226041.375000] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jun 8 00:31:40 mail kernel: [226041.375475] Stack:
Jun 8 00:31:40 mail kernel: [226041.375951] ffffffff82124485 000000000000004a ffff88040a20bef8 ffff88040a20bee0
Jun 8 00:31:40 mail kernel: [226041.376448] ffff880346162e40 ffff880405fa2840 ffff88012dd5bdc8 ffffffff81210674
Jun 8 00:31:40 mail kernel: [226041.376951] 0000000000000000 ffff88012dd5bf20 ffff880405d03900 ffff880346162e40
Jun 8 00:31:40 mail kernel: [226041.377462] Call Trace:
Jun 8 00:31:40 mail kernel: [226041.377973] [<ffffffff81210674>] locks_show+0x34/0x70
Jun 8 00:31:40 mail kernel: [226041.378495] [<ffffffff811e4414>] seq_read+0x2b4/0x370
Jun 8 00:31:40 mail kernel: [226041.379020] [<ffffffff8122a442>] proc_reg_read+0x42/0x70
Jun 8 00:31:40 mail kernel: [226041.379551] [<ffffffff811c15f8>] __vfs_read+0x28/0xe0
Jun 8 00:31:40 mail kernel: [226041.380087] [<ffffffff8159e2c0>] ? security_file_permission+0xa0/0xc0
Jun 8 00:31:40 mail kernel: [226041.380632] [<ffffffff811c1edf>] ? rw_verify_area+0x4f/0xe0
Jun 8 00:31:40 mail kernel: [226041.381182] [<ffffffff811c1ff6>] vfs_read+0x86/0x130
Jun 8 00:31:40 mail kernel: [226041.381715] [<ffffffff811c2ca6>] SyS_read+0x46/0xa0
Jun 8 00:31:40 mail kernel: [226041.382228] [<ffffffff81c7119b>] entry_SYSCALL_64_fastpath+0x16/0x6a
Jun 8 00:31:40 mail kernel: [226041.382740] Code: 85 b5 01 00 00 48 c7 c6 20 8a 15 82 4c 89 e7 e8 16 44 fd ff 4d 85 ed 48 c7 c2 f1 89 15 82 74 29 49 8b 45 28 48 c7 c2 fb 89 15 82 <f6> 40 50 40 74 18 41 0f b7 45 00 66 25 08 04 66 3d 00 04 48 c7
Jun 8 00:31:40 mail kernel: [226041.383874] RIP [<ffffffff812102f1>] lock_get_status+0xa1/0x340
Jun 8 00:31:40 mail kernel: [226041.384437] RSP <ffff88012dd5bd68>
Jun 8 00:31:40 mail kernel: [226041.384996] CR2: 0000000000000050
Jun 8 00:31:40 mail kernel: [226041.388290] ---[ end trace b29c72fcb99ad21a ]---
The O taint flag says there are out-of-tree modules loaded, which indeed there are (virtualbox). It's worth upgrading virtualbox too, or, if you're not actively using it, don't use it at all, or, if you're doing something clever with virtualbox shared folders or filesystems, use something less clever, like nfs.
Looks like an lsof command triggered a kernel bug related to file locks. Are you using filesystems mounted via NFS or SMB/CIFS on this machine?
Yes, I am using NFS, though as an exporter, not a mounter. I do run an lsof command as part of a backup script to see if there are any other users of /mnt/backup. If not, I umount it. The backup script runs at 0:01AM and this problem occured at 00:31. Interestingly, the backup didn't finish - it obviously crashed on the lsof command. Today's backup finished exactly at 00:31.
Quote:
As for a fix, tThe first thing you might want to do is upgrade the kernel. 4.4.38 was released in December 2016, and a lot has happened since then.
This is the current kernel available from Slackware. I did run a slackpkg update-all after hours in case there was something new in the kernel modules, but no. I'm disinclined to wander outside the official distro for such stuff.
Quote:
Originally Posted by 55020
The O taint flag says there are out-of-tree modules loaded, which indeed there are (virtualbox). It's worth upgrading virtualbox too, or, if you're not actively using it, don't use it at all, or, if you're doing something clever with virtualbox shared folders or filesystems, use something less clever, like nfs.
This computer is indeed hosting a virtual machine (lastest version as of a week or so ago), and it needs to. It is hosting a legacy XP database server needed currently while migrating Excel/SQLServer2003 applications, and will be needed ongoing for occasional reference/verification. The VM is mapping a network drive located on another (Samba) file server; and specifies a local shared directory: /tmp. The latter I don't really need to mount every time. It's just for file-exchange convenience between the host and VM guest.
I've never had such a crash before and it stands to reason that the VM, being a new element in the mix, might be causing lsof to hiccup.
I think the safe thing to do is not use lsof for the time being. Agreed? I don't really *need* to check if the backup drive is in use by anyone else. For one thing, there is no one else -- it's a server. For another, if the drive is in use the umount will fail. Big deal.
Great detective work guys! I was skeptical that anyone would be able to make head-r-tails of this, but LQ's Slackware experts come through again!
BTW - does Slackware have a place to report such bugs? lsof shouldn't do this, even with "out-of-tree modules loaded".
This is the current kernel available from Slackware. I did run a slackpkg update-all after hours in case there was something new in the kernel modules, but no. I'm disinclined to wander outside the official distro for such stuff.
Slackware is one of a few distributions that use a stock kernel with no patches applied, so there's really no such thing as an "official Slackware kernel".
You could try the kernel from Slackware64-current. And if you edit the bootloader settings, you can keep the old kernel around as a boot option in the extremely unlikely event that the new kernel causes compatibility issues.
As for a Slackware bug report forum, you're looking at it. The LQ Slackware forum is the official support channel for Slackware.
This would seem to be a kernel bug and since you're not running the latest 4.4.x kernel, your best approach would seem to be to first upgrade your kernel.
If you're not comfortable building and installing a kernel, 55020 provides the most recent 4.4.x and 4.9.x generic kernels here: https://gitlab.com/idlemoor/dusk
OTOH, maybe Pat and the team will provide an upgrade sometime soon ... there have been a few CVEs addressed since 4.4.38 ( see below )...
-- kjh
These are CVEs referenced in the Kernel ChangeLogs since 4.4.38 was released:
kjhambrick and Ser Olmy: thanks for the very useful info on Slackware kernels. I have seen occasional kernel updates with slackpkg when the kernel modules are unblacklisted; probably those listed in kjhambrick's message. This particular server is the email, AD/DC, dhcp, and name server, plus hosting all the users' redirected folders for a public retirement fund manager. As I said, I am reluctant step outside "normal" updates. I have removed the lsof command from within the backup script, which apparently was the original culprit. I'll run like that for now unless this crash happens again, then I'll definitely try the suggested kernel upgrade.
If this is the forum for bug reports, the the bug has been reported and I will hope that 14.3 addresses it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
The LQ Slackware forum is the official support channel for Slackware.
