FS#51983 - [linux] kernel null pointer dereference when preforming a disk write with nilfs2

Attached to Project: Arch Linux
Opened by Adam Jimerson (vendion) - Monday, 28 November 2016, 04:22 GMT
Last edited by David Thurstenson (thurstylark) - Wednesday, 27 April 2022, 20:38 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: I'm not sure if the issue is exactly with the kernel-space modules for nilfs2 or with the userland. I have a Seagate 4TB backup drive that I have partitioned with GPT, my system is definitely new enough to read GPT partition information, encrypted with LUKS (this was going to be my backup drive), and formatted with nilfs2 (for automatic pseudo-versioning via checkpoints/snapshots). Every time I do something that triggers a write operation (running touch/cp/mv/etc) on this drive I notice that my system becomes unresponsive with any task that requires disk I/O, this doesn't always happen immediately after running a command but can be triggered by calling sync. I haven't found a way to recover from this other than rebooting the whole system, in which case if I unlock the external hard drive and mount it the drive appears empty as the write operation failed.


Additional info:
* linux: 4.8.10-1 cryptsetup: 1.7.3-1 nilfs-utils: 2.2.6-1
* Output of dmesg attached


Steps to reproduce:
# cryptsetup luksFormat /dev/sdxN (Replace x with drive letter and N with partition)
# cryptsetup luksOpen /dev/sdxN test
(insert password to decrypt drive)
# mkfs.nilfs2 /dev/mapper/test
# mount /dev/mapper/test /mnt
# touch /mnt/foo
# sync

I doubt it is the drive itself because if I format the drive with a different filesystem (tested with JFS) it works fine.
   dmesg.log (113.8 KiB)
This task depends upon

Closed by  David Thurstenson (thurstylark)
Wednesday, 27 April 2022, 20:38 GMT
Reason for closing:  No response
Comment by Adam Jimerson (vendion) - Monday, 28 November 2016, 18:33 GMT
This attached dmesg output is a bit different than the previous one but it seems like a similar issue but with a different (brand new) drive same setup.
   dmesg2.log (373.6 KiB)
Comment by Pablo Lezaeta (Jristz) - Wednesday, 07 December 2016, 06:19 GMT
Are you using AMD or Intel and are you using Efi or Bios?
Comment by Adam Jimerson (vendion) - Wednesday, 07 December 2016, 12:08 GMT
Apologies for not including that in the original report, I didn't think it would be relevant here.

I have a Intel(R) Core(TM) i7-6820HQ CPU, I do have the intel-ucode package installed (version 20161104-1) and loaded although I don't know if the order matters but this is my bootloader config

title Arch Linux
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options cryptdevice=/dev/tank/root:root:allow-discards root=/dev/mapper/root quiet rw splash intel_iommu=on pcie_port_pm=off transparent_hugepage=never

I have Efi enabled and using SystemD-boot for my bootloader if that matters.

Comment by mattia (nTia89) - Sunday, 27 February 2022, 09:25 GMT
Is it still a valid issue for you?

Loading...