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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 04 Dec 2018 21:43:30 +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 #245 from Jens Axboe (axboe@...nel.dk) ---
I've only reproduced it that one time, but here's what I think is happening:

- Usually a request is queued, inserted into the blk-mq proper

- There's an optimization in place to attempt to issue to the driver directly
before doing that insert. If we fail because of some resource limitation, we
insert the request into blk-mq proper

- But if that failure did trigger, SCSI has already setup the command. This
means we now have a request in the regular blk-mq IO lists that is mergeable
with other commands, but where the SG tables for IO have already been setup.

- If we later do merge with this IO before dispatch, we'll only do DMA to the
original part of the request. This makes the rest very unhappy...

The case is different because from normal dispatch, if IO needs to be requeued,
it will NEVER be merged/changed after the fact. This means that we don't have
to release SG tables/mappings, we can simply reissue later.

This is just a theory... If I could reproduce more reliably, I'd verify it. I'm
going to spin a quick patch.

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

Powered by blists - more mailing lists