[SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

siyia · 2018-02-01 13:48:24

Hello, i cannot mount any usb flash drives under kernel 4.15 i am using the mq-bfq scheduler for all disks,with the same settings and flashdrives in kernel 4.14.15 everything works as expected.In kernel 4.15 an endless loop of mounting persists i cannot eject the drive , or stop the process.

Last edited by siyia (2018-02-05 15:00:13)

ewaller · 2018-02-01 14:11:30

Moving to Testing

siyia · 2018-02-04 12:59:16

Problem persists with kernel 4.15.1-1

siyia · 2018-02-04 14:39:09

I cannot even reboot the system because disk manager is trying to stop the process of mounting for ever.Only option after trying to mount a usb drive is hard reset.

siyia · 2018-02-05 02:48:56

The situation has gotten worse with kernel 4.15.1-2 from the staging repo.Before with linux 4.15.1-1 i could only mount 1 of my 5 usb drives,now none of them work,also when i try to reboot the system it hangs, this time with no disk manager job running no error logs or anything.Kernel 4.15.x seems to be borked, probably because the spectre and meltdown work happened in the middle of its development. Filed a bug report ---> https://bugs.freedesktop.org/show_bug.cgi?id=104937

Last edited by siyia (2018-02-05 02:49:20)

WorMzy · 2018-02-05 07:04:47

Please change your topic title to something that actually describes your issue. Also, post the journal from an affected session. You should post it on the bug report too.

You explicitly mention bfq-mq, so presumably something is logged/printed to make you feel this is relevant to the problem, please share this information too.

Do you have any problems using the other schedulers?

What is 'disk manager', and do you have problems mounting disks with 'mount'?

siyia · 2018-02-05 14:30:49

journalctl -p 3 -xb:

-- Logs begin at Sun 2018-02-04 14:53:01 EET, end at Mon 2018-02-05 16:25:06 EET. --
Φεβ 05 16:24:31 archlinux kernel: do_IRQ: 1.55 No irq handler for vector
Φεβ 05 16:24:31 archlinux kernel: do_IRQ: 2.55 No irq handler for vector
Φεβ 05 16:24:31 archlinux kernel: do_IRQ: 3.55 No irq handler for vector
Φεβ 05 16:24:31 archlinux kernel: do_IRQ: 4.55 No irq handler for vector
Φεβ 05 16:24:31 archlinux kernel: do_IRQ: 5.55 No irq handler for vector
Φεβ 05 16:24:31 archlinux kernel: do_IRQ: 6.55 No irq handler for vector
Φεβ 05 16:24:31 archlinux kernel: do_IRQ: 7.55 No irq handler for vector
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKA (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKB (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKC (20170831/dspkginit-381)
Φεβ 05 16:24:31 archlinux kernel: ACPI Exception: Could not find/resolve named package element: LNKD (20170831/dspkginit-381)
Φεβ 05 16:24:46 minimal-pc kernel: sd 8:0:0:0: [sdc] No Caching mode page found
Φεβ 05 16:24:46 minimal-pc kernel: sd 8:0:0:0: [sdc] Assuming drive cache: write through

siyia · 2018-02-05 14:35:17

Cannot mount with "mount" because according to fdisk device does not exist,despite showing in the log as /dev/sdc,other programs as well like blkid and gparted hang while reading devices.Also cannot reboot the system after i plug and unplug a usb drive, that's really weird,i will try non blk schedulers.

siyia · 2018-02-05 14:40:34

With default cfq scheduler everything works as expected under kernel 4.15.1-2!!! so the problem is down to the blk-mq schedulers.

siyia · 2018-02-05 14:56:24

So, i suppose i should mark this as solved, the solution is do not use blk-mq shedulers until this is fixed upstream

loqs · 2018-02-06 17:25:28

The issue does not occur on this system using mq-deadline can reproduce using bfq. You also reported it upstream against udisks instead of upstream against linux.
Edit:
Does not occur using kyber either looking like an issue specific to bfq.
Edit2:
Does not occur using none, mq-deadline or kyber on a usb thumb drive, can use any mq scheduler for internal sata devices including bfq.
So the issue seems to require the device use usb and the scheduler be bfq.

Last edited by loqs (2018-02-06 17:43:36)

siyia · 2018-02-06 20:43:00

Confirmed that other mq schedulers work fine, i ll close the bug maybe report it under kernel bugzilla

Last edited by siyia (2018-02-06 20:44:55)

loqs · 2018-02-06 20:47:11

I am bisecting the issue between 4.15 and 4.14 using ls to see if /dev/sde* returns partitions if not that commit is bad otherwise good.
If nothing unexpected happens I hope to find the first bad commit within 24 hours which you could then cross check.

siyia · 2018-02-06 20:53:16

new bug report ---> https://bugzilla.kernel.org/show_bug.cgi?id=198705

siyia · 2018-02-06 21:01:31

wow much appreciated loqs

loqs · 2018-02-06 21:36:14

Using /dev/sde* was a idea if the device is left present partitions are enumerated running #blkid appears to be a more reliable test.
Edit:
bisection log the result seems wrong need to double check it

$ git bisect log
git bisect start
# good: [bebc6082da0a9f5d47a1ea2edc099bf671058bd4] Linux 4.14
git bisect good bebc6082da0a9f5d47a1ea2edc099bf671058bd4
# bad: [d8a5b80568a9cb66810e75b182018e9edb68e8ff] Linux 4.15
git bisect bad d8a5b80568a9cb66810e75b182018e9edb68e8ff
# bad: [5d352e69c60e54b5f04d6e337a1d2bf0dbf3d94a] Merge tag 'media/v4.15-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect bad 5d352e69c60e54b5f04d6e337a1d2bf0dbf3d94a
# bad: [4e4510fec4af08ead21f6934c1410af1f19a8cad] Merge tag 'sound-4.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect bad 4e4510fec4af08ead21f6934c1410af1f19a8cad
# good: [fb0255fb2941ef6f21742b2bc146d6b9aef4fedc] Merge tag 'tty-4.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect good fb0255fb2941ef6f21742b2bc146d6b9aef4fedc
# bad: [e2c5923c349c1738fe8fda980874d93f6fb2e5b6] Merge branch 'for-4.15/block' of git://git.kernel.dk/linux-block
git bisect bad e2c5923c349c1738fe8fda980874d93f6fb2e5b6
# good: [808eb24e0e0939b487bf90e3888a9636f1c83acb] Merge tag 'xfs-4.15-merge-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
git bisect good 808eb24e0e0939b487bf90e3888a9636f1c83acb
# bad: [6e78f21ae4488cdab4318f781de05c8ffc4de951] nvme: set the chunk size before freezing the queue
git bisect bad 6e78f21ae4488cdab4318f781de05c8ffc4de951
# good: [77c77a98f8a4dd4d33810e25a8780f65d6fa00e9] bcache: Add Michael Lyle to MAINTAINERS
git bisect good 77c77a98f8a4dd4d33810e25a8780f65d6fa00e9
# good: [a806c6c81e6c0d07c8a8b2643bad4a37a196d681] nvme: comment typo fixed in clearing AER
git bisect good a806c6c81e6c0d07c8a8b2643bad4a37a196d681
# good: [474f5da2354e9fd5376b968e4c5a0f1807dc19e8] skd: use ktime_get_real_seconds()
git bisect good 474f5da2354e9fd5376b968e4c5a0f1807dc19e8
# good: [6d6f167ce74158903e7fc20dfbecf89c71aa1c00] blk-mq: put the driver tag of nxt rq before first one is requeued
git bisect good 6d6f167ce74158903e7fc20dfbecf89c71aa1c00
# bad: [6a468d5990ecd1c2d07dd85f8633bbdd0ba61c40] nbd: don't start req until after the dead connection logic
git bisect bad 6a468d5990ecd1c2d07dd85f8633bbdd0ba61c40
# good: [a6a252e6491443c1c18eab7e254daee63d4a7a04] blk-mq-sched: decide how to handle flush rq via RQF_FLUSH_SEQ
git bisect good a6a252e6491443c1c18eab7e254daee63d4a7a04
# good: [923218f6166a84688973acdc39094f3bee1e9ad4] blk-mq: don't allocate driver tag upfront for flush rq
git bisect good 923218f6166a84688973acdc39094f3bee1e9ad4
# bad: [ff57dc94faec023abc267cdc45766fccff497557] nbd: wait uninterruptible for the dead timeout
git bisect bad ff57dc94faec023abc267cdc45766fccff497557
# first bad commit: [ff57dc94faec023abc267cdc45766fccff497557] nbd: wait uninterruptible for the dead timeout

Edit2:
# good: [923218f6166a84688973acdc39094f3bee1e9ad4] blk-mq: don't allocate driver tag upfront for flush rq
should be bad need to recheck the last few steps some more.
Edit3:

git bisect log
git bisect start
# good: [bebc6082da0a9f5d47a1ea2edc099bf671058bd4] Linux 4.14
git bisect good bebc6082da0a9f5d47a1ea2edc099bf671058bd4
# bad: [d8a5b80568a9cb66810e75b182018e9edb68e8ff] Linux 4.15
git bisect bad d8a5b80568a9cb66810e75b182018e9edb68e8ff
# bad: [5d352e69c60e54b5f04d6e337a1d2bf0dbf3d94a] Merge tag 'media/v4.15-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect bad 5d352e69c60e54b5f04d6e337a1d2bf0dbf3d94a
# bad: [4e4510fec4af08ead21f6934c1410af1f19a8cad] Merge tag 'sound-4.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect bad 4e4510fec4af08ead21f6934c1410af1f19a8cad
# good: [fb0255fb2941ef6f21742b2bc146d6b9aef4fedc] Merge tag 'tty-4.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect good fb0255fb2941ef6f21742b2bc146d6b9aef4fedc
# bad: [e2c5923c349c1738fe8fda980874d93f6fb2e5b6] Merge branch 'for-4.15/block' of git://git.kernel.dk/linux-block
git bisect bad e2c5923c349c1738fe8fda980874d93f6fb2e5b6
# good: [808eb24e0e0939b487bf90e3888a9636f1c83acb] Merge tag 'xfs-4.15-merge-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
git bisect good 808eb24e0e0939b487bf90e3888a9636f1c83acb
# bad: [6e78f21ae4488cdab4318f781de05c8ffc4de951] nvme: set the chunk size before freezing the queue
git bisect bad 6e78f21ae4488cdab4318f781de05c8ffc4de951
# good: [77c77a98f8a4dd4d33810e25a8780f65d6fa00e9] bcache: Add Michael Lyle to MAINTAINERS
git bisect good 77c77a98f8a4dd4d33810e25a8780f65d6fa00e9
# good: [a806c6c81e6c0d07c8a8b2643bad4a37a196d681] nvme: comment typo fixed in clearing AER
git bisect good a806c6c81e6c0d07c8a8b2643bad4a37a196d681
# good: [474f5da2354e9fd5376b968e4c5a0f1807dc19e8] skd: use ktime_get_real_seconds()
git bisect good 474f5da2354e9fd5376b968e4c5a0f1807dc19e8
# good: [6d6f167ce74158903e7fc20dfbecf89c71aa1c00] blk-mq: put the driver tag of nxt rq before first one is requeued
git bisect good 6d6f167ce74158903e7fc20dfbecf89c71aa1c00
# bad: [6a468d5990ecd1c2d07dd85f8633bbdd0ba61c40] nbd: don't start req until after the dead connection logic
git bisect bad 6a468d5990ecd1c2d07dd85f8633bbdd0ba61c40
# good: [a6a252e6491443c1c18eab7e254daee63d4a7a04] blk-mq-sched: decide how to handle flush rq via RQF_FLUSH_SEQ
git bisect good a6a252e6491443c1c18eab7e254daee63d4a7a04
# bad: [923218f6166a84688973acdc39094f3bee1e9ad4] blk-mq: don't allocate driver tag upfront for flush rq
git bisect bad 923218f6166a84688973acdc39094f3bee1e9ad4
# bad: [244c65a3ccaa06fd15cc940315606674d3108b2f] blk-mq: move blk_mq_put_driver_tag*() into blk-mq.h
git bisect bad 244c65a3ccaa06fd15cc940315606674d3108b2f
# first bad commit: [244c65a3ccaa06fd15cc940315606674d3108b2f] blk-mq: move blk_mq_put_driver_tag*() into blk-mq.h

This bisect still looks wrong more checking to do
Edit3:

$ git bisect log
git bisect start
# good: [bebc6082da0a9f5d47a1ea2edc099bf671058bd4] Linux 4.14
git bisect good bebc6082da0a9f5d47a1ea2edc099bf671058bd4
# bad: [d8a5b80568a9cb66810e75b182018e9edb68e8ff] Linux 4.15
git bisect bad d8a5b80568a9cb66810e75b182018e9edb68e8ff
# bad: [5d352e69c60e54b5f04d6e337a1d2bf0dbf3d94a] Merge tag 'media/v4.15-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect bad 5d352e69c60e54b5f04d6e337a1d2bf0dbf3d94a
# bad: [4e4510fec4af08ead21f6934c1410af1f19a8cad] Merge tag 'sound-4.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect bad 4e4510fec4af08ead21f6934c1410af1f19a8cad
# good: [fb0255fb2941ef6f21742b2bc146d6b9aef4fedc] Merge tag 'tty-4.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect good fb0255fb2941ef6f21742b2bc146d6b9aef4fedc
# bad: [e2c5923c349c1738fe8fda980874d93f6fb2e5b6] Merge branch 'for-4.15/block' of git://git.kernel.dk/linux-block
git bisect bad e2c5923c349c1738fe8fda980874d93f6fb2e5b6
# good: [808eb24e0e0939b487bf90e3888a9636f1c83acb] Merge tag 'xfs-4.15-merge-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
git bisect good 808eb24e0e0939b487bf90e3888a9636f1c83acb
# bad: [6e78f21ae4488cdab4318f781de05c8ffc4de951] nvme: set the chunk size before freezing the queue
git bisect bad 6e78f21ae4488cdab4318f781de05c8ffc4de951
# good: [77c77a98f8a4dd4d33810e25a8780f65d6fa00e9] bcache: Add Michael Lyle to MAINTAINERS
git bisect good 77c77a98f8a4dd4d33810e25a8780f65d6fa00e9
# good: [a806c6c81e6c0d07c8a8b2643bad4a37a196d681] nvme: comment typo fixed in clearing AER
git bisect good a806c6c81e6c0d07c8a8b2643bad4a37a196d681
# good: [474f5da2354e9fd5376b968e4c5a0f1807dc19e8] skd: use ktime_get_real_seconds()
git bisect good 474f5da2354e9fd5376b968e4c5a0f1807dc19e8
# good: [6d6f167ce74158903e7fc20dfbecf89c71aa1c00] blk-mq: put the driver tag of nxt rq before first one is requeued
git bisect good 6d6f167ce74158903e7fc20dfbecf89c71aa1c00
# bad: [6a468d5990ecd1c2d07dd85f8633bbdd0ba61c40] nbd: don't start req until after the dead connection logic
git bisect bad 6a468d5990ecd1c2d07dd85f8633bbdd0ba61c40
# bad: [a6a252e6491443c1c18eab7e254daee63d4a7a04] blk-mq-sched: decide how to handle flush rq via RQF_FLUSH_SEQ
git bisect bad a6a252e6491443c1c18eab7e254daee63d4a7a04
# good: [b0850297c749ea79a5717d597931366b3d7f4b09] block: pass 'run_queue' to blk_mq_request_bypass_insert
git bisect good b0850297c749ea79a5717d597931366b3d7f4b09
# good: [598906f814280762157629ba8833bf5cb11def74] blk-flush: use blk_mq_request_bypass_insert()
git bisect good 598906f814280762157629ba8833bf5cb11def74
# first bad commit: [a6a252e6491443c1c18eab7e254daee63d4a7a04] blk-mq-sched: decide how to handle flush rq via RQF_FLUSH_SEQ

This seems more reasonable still needs a cross check.
Edit:
Double checked the commit seems to be the first bad commit reported on the upstream bug report.
Edit2:
Attempt at a backported fix with this blkid works successfully so it does appear to be http://lkml.org/lkml/2018/2/7/529

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index bcb6d21baf12..2f0cf6796c8d 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -3640,10 +3640,11 @@ static struct request *__bfq_dispatch_request(struct blk_mq_hw_ctx *hctx)
 		 * bfq_schedule_dispatch to be invoked uselessly.
 		 *
 		 * As for implementing an exact solution, the
-		 * put_request hook, if defined, is probably invoked
-		 * also on this request. So, by exploiting this hook,
-		 * we could 1) increment rq_in_driver here, and 2)
-		 * decrement it in put_request. Such a solution would
+		 * bfq_finish_requeue_request hook, if defined, is
+		 * probably invoked also on this request. So, by
+		 * exploiting this hook, we could 1) increment
+		 * rq_in_driver here, and 2) decrement it in
+		 * bfq_finish_requeue_request. Such a solution would
 		 * let the value of the counter be always accurate,
 		 * but it would entail using an extra interface
 		 * function. This cost seems higher than the benefit,
@@ -4276,16 +4277,16 @@ static bool __bfq_insert_request(struct bfq_data *bfqd, struct request *rq)
 	return idle_timer_disabled;
 }
 
+static void bfq_prepare_request(struct request *rq, struct bio *bio);
+
 static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq,
 			       bool at_head)
 {
 	struct request_queue *q = hctx->queue;
 	struct bfq_data *bfqd = q->elevator->elevator_data;
-#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
 	struct bfq_queue *bfqq = RQ_BFQQ(rq);
 	bool idle_timer_disabled = false;
 	unsigned int cmd_flags;
-#endif
 
 	spin_lock_irq(&bfqd->lock);
 	if (blk_mq_sched_try_insert_merge(q, rq)) {
@@ -4304,7 +4305,19 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq,
 		else
 			list_add_tail(&rq->queuelist, &bfqd->dispatch);
 	} else {
-#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
+		if (!bfqq) {
+			/*
+			 * This should never happen. Most likely rq is
+			 * a requeued regular request, being
+			 * re-inserted without being first
+			 * re-prepared. Do a prepare, to avoid
+			 * failure.
+			 */
+			pr_warn("Regular request associated with no queue");
+			WARN_ON(1);
+			bfq_prepare_request(rq, rq->bio);
+			bfqq = RQ_BFQQ(rq);
+		}
 		idle_timer_disabled = __bfq_insert_request(bfqd, rq);
 		/*
 		 * Update bfqq, because, if a queue merge has occurred
@@ -4312,9 +4325,6 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq,
 		 * redirected into a new queue.
 		 */
 		bfqq = RQ_BFQQ(rq);
-#else
-		__bfq_insert_request(bfqd, rq);
-#endif
 
 		if (rq_mergeable(rq)) {
 			elv_rqhash_add(q, rq);
@@ -4323,14 +4333,12 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq,
 		}
 	}
 
-#if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
 	/*
 	 * Cache cmd_flags before releasing scheduler lock, because rq
 	 * may disappear afterwards (for example, because of a request
 	 * merge).
 	 */
 	cmd_flags = rq->cmd_flags;
-#endif
 	spin_unlock_irq(&bfqd->lock);
 
 #if defined(CONFIG_BFQ_GROUP_IOSCHED) && defined(CONFIG_DEBUG_BLK_CGROUP)
@@ -4482,22 +4490,44 @@ static void bfq_completed_request(struct bfq_queue *bfqq, struct bfq_data *bfqd)
 		bfq_schedule_dispatch(bfqd);
 }
 
-static void bfq_put_rq_priv_body(struct bfq_queue *bfqq)
+static void bfq_finish_requeue_request_body(struct bfq_queue *bfqq)
 {
 	bfqq->allocated--;
 
 	bfq_put_queue(bfqq);
 }
 
-static void bfq_finish_request(struct request *rq)
+/*
+ * Handle either a requeue or a finish for rq. The things to do are
+ * the same in both cases: all references to rq are to be dropped. In
+ * particular, rq is considered completed from the point of view of
+ * the scheduler.
+ */
+static void bfq_finish_requeue_request(struct request *rq)
 {
-	struct bfq_queue *bfqq;
+	struct bfq_queue *bfqq = RQ_BFQQ(rq);
 	struct bfq_data *bfqd;
 
-	if (!rq->elv.icq)
+	/*
+	 * Requeue and finish hooks are invoked in blk-mq without
+	 * checking whether the involved request is actually still
+	 * referenced in the scheduler. To handle this fact, the
+	 * following two checks make this function exit in case of
+	 * spurious invocations, for which there is nothing to do.
+	 *
+	 * First, check whether rq has nothing to do with an elevator.
+	 */
+	if (unlikely(!(rq->rq_flags & RQF_ELVPRIV)))
+		return;
+
+	/*
+	 * rq either is not associated with any icq, or is an already
+	 * requeued request that has not (yet) been re-inserted into
+	 * a bfq_queue.
+	 */
+	if (!rq->elv.icq || !bfqq)
 		return;
 
-	bfqq = RQ_BFQQ(rq);
 	bfqd = bfqq->bfqd;
 
 	if (rq->rq_flags & RQF_STARTED)
@@ -4512,13 +4542,14 @@ static void bfq_finish_request(struct request *rq)
 		spin_lock_irqsave(&bfqd->lock, flags);
 
 		bfq_completed_request(bfqq, bfqd);
-		bfq_put_rq_priv_body(bfqq);
+		bfq_finish_requeue_request_body(bfqq);
 
 		spin_unlock_irqrestore(&bfqd->lock, flags);
 	} else {
 		/*
 		 * Request rq may be still/already in the scheduler,
-		 * in which case we need to remove it. And we cannot
+		 * in which case we need to remove it (this should
+		 * never happen in case of requeue). And we cannot
 		 * defer such a check and removal, to avoid
 		 * inconsistencies in the time interval from the end
 		 * of this function to the start of the deferred work.
@@ -4533,9 +4564,26 @@ static void bfq_finish_request(struct request *rq)
 			bfqg_stats_update_io_remove(bfqq_group(bfqq),
 						    rq->cmd_flags);
 		}
-		bfq_put_rq_priv_body(bfqq);
+		bfq_finish_requeue_request_body(bfqq);
 	}
 
+	/*
+	 * Reset private fields. In case of a requeue, this allows
+	 * this function to correctly do nothing if it is spuriously
+	 * invoked again on this same request (see the check at the
+	 * beginning of the function). Probably, a better general
+	 * design would be to prevent blk-mq from invoking the requeue
+	 * or finish hooks of an elevator, for a request that is not
+	 * referred by that elevator.
+	 *
+	 * Resetting the following fields would break the
+	 * request-insertion logic if rq is re-inserted into a bfq
+	 * internal queue, without a re-preparation. Here we assume
+	 * that re-insertions of requeued requests, without
+	 * re-preparation, can happen only for pass_through or at_head
+	 * requests (which are not re-inserted into bfq internal
+	 * queues).
+	 */
 	rq->elv.priv[0] = NULL;
 	rq->elv.priv[1] = NULL;
 }
@@ -4818,6 +4866,9 @@ static void bfq_exit_queue(struct elevator_queue *e)
 	hrtimer_cancel(&bfqd->idle_slice_timer);
 
 #ifdef CONFIG_BFQ_GROUP_IOSCHED
+	/* release oom-queue reference to root group */
+	bfqg_and_blkg_put(bfqd->root_group);
+
 	blkcg_deactivate_policy(bfqd->queue, &blkcg_policy_bfq);
 #else
 	spin_lock_irq(&bfqd->lock);
@@ -5207,7 +5258,8 @@ static struct elv_fs_entry bfq_attrs[] = {
 static struct elevator_type iosched_bfq_mq = {
 	.ops.mq = {
 		.prepare_request	= bfq_prepare_request,
-		.finish_request		= bfq_finish_request,
+		.requeue_request        = bfq_finish_requeue_request,
+		.finish_request		= bfq_finish_requeue_request,
 		.exit_icq		= bfq_exit_icq,
 		.insert_requests	= bfq_insert_requests,
 		.dispatch_request	= bfq_dispatch_request,

Last edited by loqs (2018-02-08 17:17:04)

siyia · 2018-02-14 02:33:26

Resolved after updating to kernel 4.15.3

loqs · 2018-02-14 08:46:33

Strange there was no patch in the in 4.15.3 to bfq or the block subsystem. See also https://bugs.archlinux.org/task/57496

siyia · 2018-02-15 08:32:08

let me double check and i ll post back

siyia · 2018-02-15 11:29:48

no its not fixed its just that 2 of my flash drives play nice witn bfq

siyia · 2018-02-15 11:30:25

Out of the 5 drives i own only two work with current bfq lol

tydynrain · 2018-03-14 00:32:24

This issue has affected me on all 4.15 versions, though in [core], not [testing]. I finally just went back to CFQ for the time being. It's annoying, but at least the 'fix' is easy enough.

Arch Linux

#1 2018-02-01 13:48:24

[SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#2 2018-02-01 14:11:30

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#3 2018-02-04 12:59:16

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#4 2018-02-04 14:39:09

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#5 2018-02-05 02:48:56

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#6 2018-02-05 07:04:47

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#7 2018-02-05 14:30:49

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#8 2018-02-05 14:35:17

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#9 2018-02-05 14:40:34

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#10 2018-02-05 14:56:24

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#11 2018-02-06 17:25:28

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#12 2018-02-06 20:43:00

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#13 2018-02-06 20:47:11

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#14 2018-02-06 20:53:16

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#15 2018-02-06 21:01:31

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#16 2018-02-06 21:36:14

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#17 2018-02-14 02:33:26

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#18 2018-02-14 08:46:33

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#19 2018-02-15 08:32:08

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#20 2018-02-15 11:29:48

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#21 2018-02-15 11:30:25

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

#22 2018-03-14 00:32:24

Re: [SOLVED] Kernel 4.15.1-2 cannot mount any usb drives with mq-bfq

Board footer