Bug 646216

Summary:	sys-kernel/vanilla-sources-4.15.0: unlocking luks encrypted usb drive fails
Product:	Gentoo Linux	Reporter:	poncho <poncho>
Component:	Current packages	Assignee:	Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ago, poncho
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Attachments:	bisect log cryptsetup fail cryptsetup success

Description poncho 2018-01-31 16:46:49 UTC

Created attachment 517250 [details]
bisect log

It's not possible to unlock my external usb drive that is luks encrypted with kernel 4.15.
There are no issues with the encrypted internal drives.

cryptsetup --verbose --debug luksOpen /dev/sde luks-backup
just hangs after: Udev cookie 0xd4d7eef (semid 131072) waiting for zero


The bisecting ended up at the following commit:

a6a252e6491443c1c18eab7e254daee63d4a7a04 is the first bad commit
commit a6a252e6491443c1c18eab7e254daee63d4a7a04
Author: Ming Lei <ming.lei@redhat.com>
Date:   Thu Nov 2 23:24:36 2017 +0800

    blk-mq-sched: decide how to handle flush rq via RQF_FLUSH_SEQ
    
    In case of IO scheduler we always pre-allocate one driver tag before
    calling blk_insert_flush(), and flush request will be marked as
    RQF_FLUSH_SEQ once it is in flush machinery.
    
    So if RQF_FLUSH_SEQ isn't set, we call blk_insert_flush() to handle
    the request, otherwise the flush request is dispatched to ->dispatch
    list directly.
    
    This is a preparation patch for not preallocating a driver tag for flush
    requests, and for not treating flush requests as a special case. This is
    similar to what the legacy path does.
    
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

Comment 1 poncho 2018-01-31 16:47:14 UTC

Created attachment 517252 [details]
cryptsetup fail

Comment 2 poncho 2018-01-31 16:48:02 UTC

Created attachment 517254 [details]
cryptsetup success

Comment 3 poncho 2018-04-04 08:36:55 UTC

This is fixed with sys-kernel/vanilla-sources-4.16.0

The issue was:
https://patchwork.kernel.org/patch/10206089/