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-Ihut4uy30z@https.bugzilla.kernel.org/>
Date:   Thu, 22 Nov 2018 02:02:26 +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 #25 from Jens Axboe (axboe@...nel.dk) ---
Ted, it seems to be affecting nvme as well, so there's really no escaping for
you. But there has to be some other deciding factor here, or all the block
testing would surely have caught this. Question is just what it is.

What would be the most helpful is if someone who can reproduce this at well
could run a bisect between 4.18 and 4.19 to figure out wtf is going on here.
This commit:

commit 410306a0f2baa5d68970cdcf6763d79c16df5f23
Author: Ming Lei <ming.lei@...hat.com>
Date:   Wed Nov 14 16:25:51 2018 +0800

    SCSI: fix queue cleanup race before queue initialization is done

might explain the SCSI issues seen, but the very first comment is from someone
using nvme that the above patch has no bearing on that at all. It is, however,
possible that some of the queue sync patches caused a blk-mq issue, and that is
why nvme is affected as well, and why the above commit seems to fix things on
the SCSI side.

I'm going to attach a patch here for 4.19 and it'd be great if folks could try
that.

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