-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
handle_bdev_mount_event has a null pointer。kernel panic #365
Comments
Hi, |
[root@host-192-168-126-181 ~]# uname -r
yes thank you swistusmen |
Hi, We have been getting similar errors since upgrading Ubuntu 22.04 LTS to the newest released kernel. Dmesg below: We also have CentOS Stream 8 servers that completely crash but we are migrating away from these servers, so not as concerned. |
Hi, can you provide your scenario? Was it only on shutdown/reboot or also in other scenarios? I have observed such trace in /var/crash in following scenario:
|
Hi and thank you for your response. Yes, it's on bootup it occurs. However it can occur on a clean start without dattobd loaded. If I load dattobd, start docker, then running " docker run --rm hello-world", the panic shows and the docker command never returns, unresponsive to ctrl+c, and ctrl+z, only kill -9 will terminate the process. It repeats the panic any time a docker command becomes unresponsive, for example when I tried starting it again in the below example. I have found the following: • When dattobd is inserted and when docker is stopped, it appears to be placed in a “crashed” state. (process is no longer running, but starting it again causes it to be unresponsive if dattobd is loaded at the time) So whilst the module is loaded and docker is in a “clean” (responsive) state, we can successfully stop docker, but it appears to put it in this “crashed” state and starting it again causes the freeze if the dattobd module is still loaded, this includes only starting it after a clean reboot. However if I remove the dattobd module before stopping docker, we can successfully start it again afterwards, even with dattobd loaded during the startup, for example: rmmod dattobd && systemctl stop docker && modprobe dattobd && systemctl start docker Docker remains responsive. I don’t think it’s the full answer, because whilst docker is responsive and dattobd is loaded, I could cause it to stop responding by running the command “docker run --rm hello-world”, so it’s not strictly on stop/start that causes issues. |
Hi, thanks for the explanation. |
I've found any kernel above 5.15.0-94 causes a kernel panic. I'd be curious about what versions others are running? |
It is going to be solved by #377 (review) |
[ 126.460209] TECH PREVIEW: Overlay filesystem may not be fully supported.
Please review provided documentation for limitations.
[ 126.637468] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 126.637520] IP: [] handle_bdev_mount_event+0x67/0x1b0 [dattobd]
[ 126.637566] PGD 0
[ 126.637582] Oops: 0000 [#1] SMP
[ 126.637604] Modules linked in: overlay(T) fuse btrfs raid6_pq xor vfat msdos fat ext4 mbcache jbd2 nls_utf8 isofs dm_mod kvm_intel kvm irqbypass aesni_intel lrw gf128mul glue_helper ablk_helper sg ppdev cryptd virtio_balloon pcspkr joydev parport_pc parport i2c_piix4 ip_tables xfs libcrc32c sr_mod cdrom ata_generic pata_acpi virtio_net virtio_console virtio_blk cirrus drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix libata virtio_pci virtio_ring drm_panel_orientation_quirks serio_raw virtio floppy dattobd(OE)
[ 126.637989] CPU: 0 PID: 2629 Comm: dockerd Kdump: loaded Tainted: G OE ------------ T 3.10.0-957.el7.x86_64 #1
[ 126.638057] Hardware name: Huayun ArStack, BIOS 1.11.0-2.el7 04/01/2014
[ 126.638093] task: ffff8b6592a49040 ti: ffff8b65a3608000 task.ti: ffff8b65a3608000
[ 126.638133] RIP: 0010:[] [] handle_bdev_mount_event+0x67/0x1b0 [dattobd]
[ 126.638189] RSP: 0018:ffff8b65a360bed8 EFLAGS: 00010246
[ 126.638218] RAX: 00000000fffffffe RBX: 0000000000000000 RCX: 0000000000000000
[ 126.638256] RDX: 0000000000003dc9 RSI: 0000000000000000 RDI: 0000000000000000
[ 126.638293] RBP: ffff8b65a360bf10 R08: 000000000001f1a0 R09: ffffffff88452abd
[ 126.638331] R10: ffff8b65ae61f1a0 R11: fffff8a400d75600 R12: ffff8b65a360bf24
[ 126.638368] R13: 000000c000a24380 R14: 0000000000000000 R15: 0000000000000000
[ 126.638405] FS: 00007f01cf7fe700(0000) GS:ffff8b65ae600000(0000) knlGS:0000000000000000
[ 126.638447] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 126.638478] CR2: 0000000000000000 CR3: 0000000035fb4000 CR4: 00000000001206f0
[ 126.638519] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 126.638558] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 126.638595] Call Trace:
[ 126.638615] [] ftrace_sys_umount+0x39/0x90 [dattobd]
[ 126.638654] [] system_call_fastpath+0x22/0x27
[ 126.638685] Code: 31 d2 48 8d 4d c8 83 e3 08 0f 94 c2 4c 89 ee bf 9c ff ff ff e8 6b 1a 33 c8 8b 35 2d 91 00 00 85 f6 0f 85 00 01 00 00 48 8b 7d c8 <48> 8b 07 48 39 45 d0 74 50 8b 0d 12 91 00 00 85 c9 0f 85 0b 01
[ 126.638936] RIP [] handle_bdev_mount_event+0x67/0x1b0 [dattobd]
[ 126.638981] RSP
[ 126.639009] CR2: 0000000000000000
datto may not support backing up docker on VMs
The text was updated successfully, but these errors were encountered: