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: <eb5fc9ae-45a7-44d3-0238-5cdaa1ae3558@gmail.com>
Date:   Sun, 6 Feb 2022 10:59:07 +1300
From:   Michael Schmitz <schmitzmic@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Jens Axboe <axboe@...nel.dk>,
        Laibin Qiu <qiulaibin@...wei.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>
Subject: Re: Regression in 5.17-rc1 on pata-falcon

Hi Geert, Jens,

thanks for the hint - applying 10825410b956dc1e on top of 5.17-rc1 does 
indeed fix the issue.

nr_tags == 1 on the Falcon may explain why I ran into this. Oddly 
enough, I have the same on ARAnyM. Adding a second 'disk' there does 
reproduce the issue on ARAnyM though. nr_tags == 1 && nr_disks > 1 
appears to be sufficient to reproduce this.

I surmised I couldn't be the only one to run into this, but hadn't seen 
any other reports yet.

Cheers,

	Michael


Am 05.02.2022 um 21:31 schrieb Geert Uytterhoeven:
> Hi Michael,
>
> On Sat, Feb 5, 2022 at 1:04 AM Michael Schmitz <schmitzmic@...il.com> wrote:
>> commit 180dccb0dba4f5e84a4a70c1be1d34cbb6528b32 (blk-mq: fix tag_get
>> wait task can't be awakened) does cause a regression on my m68k hardware
>> test rig (m68k Falcon030, IDE disk attached through pata-falcon driver
>> which does use polled IO instead of interrupts, so may be a little on
>> the slow side).
>
>> Bisection between v5.16 and v5.17-rc1 points to
>> 180dccb0dba4f5e84a4a70c1be1d34cbb6528b32 as the culprit, which is
>> corroborated by reverting that commit in v5.17-rc1 and booting as
>> rapidly as before.
>
> Now you know the culprit, it looks like several other people ran into this.
> Does this fix help?
> https://lore.kernel.org/all/1643040870.3bwvk3sis4.none@localhost/
>
> It is commit 10825410b956dc1e ("blk-mq: Fix wrong wakeup
> batch configuration which will cause hang") in v5.17-rc2.
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ