linux-kernel - Re: [PATCH BUGFIX] block, bfq: deschedule empty bfq

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: <65fc0bffbcb2296d121b3d5a79108e76@natalenko.name>
Date:   Wed, 13 Nov 2019 15:25:14 +0100
From:   Oleksandr Natalenko <oleksandr@...alenko.name>
To:     Paolo Valente <paolo.valente@...aro.org>
Cc:     Jens Axboe <axboe@...nel.dk>,
        linux-block <linux-block@...r.kernel.org>,
        linux-kernel@...r.kernel.org, ulf.hansson@...aro.org,
        linus.walleij@...aro.org, bfq-iosched@...glegroups.com,
        Chris Evich <cevich@...hat.com>,
        Patrick Dung <patdung100@...il.com>,
        Thorsten Schubert <tschubert@...h.org>
Subject: Re: [PATCH BUGFIX] block, bfq: deschedule empty bfq_queues not
 referred by any process

On 13.11.2019 14:52, Paolo Valente wrote:
>> I'm not sure if I see things right, but this commit along with v5.3.11 
>> kernel causes almost all boots to hang (for instance, on mounting the 
>> FS). Once the scheduler is changed to something else than BFQ (I set 
>> the I/O scheduler early via udev rule), multiple reboots go just fine.
>> 
> 
> If you switch back to bfq after the boot, can you still reproduce the 
> hang?

I didn't try to switch schedulers, but what I see now is once the system 
is able to boot with BFQ, the I/O can still hang on I/O burst (which for 
me happens to happen during VM reboot).

This may also not hang forever, but just slow down considerably. I've 
noticed this inside a KVM VM, not on a real HW.

>> Is this commit also applicable to 5.3 kernels?
> 
> It is.

OK, thanks for clarification.

-- 
   Oleksandr Natalenko (post-factum)