linux-ext4 - [Bug 201685] ext4 file system corruption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bug-201685-13602-vycvkbt9h3@https.bugzilla.kernel.org/>
Date:   Mon, 26 Nov 2018 00:00:54 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 201685] ext4 file system corruption

https://bugzilla.kernel.org/show_bug.cgi?id=201685

--- Comment #46 from Theodore Tso (tytso@....edu) ---
So Henrique, the only difference between the 4.19.3 kernel that worked and the
one where you didn't see corruption was CONFIG_SCSI_MQ_DEFAULT?   Can you diff
the two configs to be sure?

What can you tell us about the SSD?  Is it a SATA-attached SSD, or
NVMe-attached?

What I can report is my personal development laptop is running 4.19.0 (plus the
ext4 patches that landed in 4.20-rc1) with CONFIG_SCSI_MQ_DEFAULT=n?  (Although
as others have pointed out, that shouldn't matter since my SSD is
NVMe-attached, and so it doesn't go through the SCSI stack.)   My laptop runs
Debian unstable, and uses an encrypted LUKS partition on top of which I use
LVM.   I do use regular suspend-to-ram (not suspend-to-idle, since that burns
way too much power; there's a kernel BZ open on that issue) since it is a
laptop.

I have also run xfstest runs using 4.19.0, 4.19.1, 4.19.2, and 4.20-rc2 with
CONFIG_SCSI_MQ_DEFAULT=n; it's using the gce-xfstests[1] test appliance which
means I'm using virtio-SCSI on top of LVM, and it runs a large number of
regression tests, many with heavy read/write loads, but none of the file
systems is mounted for more than 5-6 minutes before we unmount and then run
fsck on it.  We do *not* do any suspend/resumes, although we do test the file
system side of suspend/resume using the freeze and thaw ioctls.  There were no
unusual problems noticed.  

[1] https://thunk.org/gce-xfstests

I have also run gce-xfstests on 4.20-rc2 with CONFIG_SCSI_MQ_DEFAULT=y, with
the same configuration as above --- vrtio-scsi with LVM on top.   There was
nothing unusual that was detected there.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.