linux-kernel - Re: Regression v6.11 booting cannot mount harddisks (xfs)

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] [day] [month] [year] [list]

Message-ID: <64ab096c-c493-42b1-945e-ba3547723720@kernel.dk>
Date: Tue, 10 Sep 2024 13:43:25 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Jesper Dangaard Brouer <hawk@...nel.org>,
 Damien Le Moal <dlemoal@...nel.org>,
 Linus Torvalds <torvalds@...uxfoundation.org>,
 LKML <linux-kernel@...r.kernel.org>, Christoph Hellwig <hch@...radead.org>
Cc: Netdev <netdev@...r.kernel.org>, linux-ide@...r.kernel.org,
 cassel@...nel.org, handan.babu@...cle.com, djwong@...nel.org,
 Linux-XFS <linux-xfs@...r.kernel.org>, hdegoede@...hat.com,
 "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 kernel-team <kernel-team@...udflare.com>, rjones@...hat.com
Subject: Re: Regression v6.11 booting cannot mount harddisks (xfs)

On 9/10/24 1:40 PM, Jesper Dangaard Brouer wrote:
> 
> 
> On 10/09/2024 21.21, Jens Axboe wrote:
>> On 9/10/24 1:19 PM, Jesper Dangaard Brouer wrote:
>>>
>>>
>>> On 10/09/2024 20.38, Jens Axboe wrote:
>>>> On 9/10/24 11:53 AM, Jesper Dangaard Brouer wrote:
>>>>> Hi Hellwig,
>>>>>
>>>>> I bisected my boot problem down to this commit:
>>>>>
>>>>> $ git bisect good
>>>>> af2814149883e2c1851866ea2afcd8eadc040f79 is the first bad commit
>>>>> commit af2814149883e2c1851866ea2afcd8eadc040f79
>>>>> Author: Christoph Hellwig <hch@....de>
>>>>> Date:   Mon Jun 17 08:04:38 2024 +0200
>>>>>
>>>>>       block: freeze the queue in queue_attr_store
>>>>>
>>>>>       queue_attr_store updates attributes used to control generating I/O, and
>>>>>       can cause malformed bios if changed with I/O in flight.  Freeze the queue
>>>>>       in common code instead of adding it to almost every attribute.
>>>>>
>>>>>       Signed-off-by: Christoph Hellwig <hch@....de>
>>>>>       Reviewed-by: Bart Van Assche <bvanassche@....org>
>>>>>       Reviewed-by: Damien Le Moal <dlemoal@...nel.org>
>>>>>       Reviewed-by: Hannes Reinecke <hare@...e.de>
>>>>>       Reviewed-by: Chaitanya Kulkarni <kch@...dia.com>
>>>>>       Link: https://lore.kernel.org/r/20240617060532.127975-12-hch@lst.de
>>>>>       Signed-off-by: Jens Axboe <axboe@...nel.dk>
>>>>>
>>>>>    block/blk-mq.c    | 5 +++--
>>>>>    block/blk-sysfs.c | 9 ++-------
>>>>>    2 files changed, 5 insertions(+), 9 deletions(-)
>>>>>
>>>>> git describe --contains af2814149883e2c1851866ea2afcd8eadc040f79
>>>>> v6.11-rc1~80^2~66^2~15
>>>>
>>>> Curious, does your init scripts attempt to load a modular scheduler
>>>> for your root drive?
>>>
>>> I have no idea, this is just a standard Fedora 40.
>>>
>>>>
>>>> Reference: https://git.kernel.dk/cgit/linux/commit/?h=for-6.12/block&id=3c031b721c0ee1d6237719a6a9d7487ef757487b
>>>
> 
> [1] https://git.kernel.dk/cgit/linux/commit/?h=for-6.12/block&id=3c031b721c0ee1d6237719a6a9d7487ef757487b
> 
>>> The commit doesn't apply cleanly on top of af2814149883e2c185.
>>>
>>> $ patch --dry-run -p1 < ../block-jens/block-jens-bootfix.patch
>>> checking file block/blk-sysfs.c
>>> Hunk #1 FAILED at 23.
>>> Hunk #2 succeeded at 469 (offset 56 lines).
>>> Hunk #3 succeeded at 484 (offset 56 lines).
>>> Hunk #4 succeeded at 723 with fuzz 1 (offset 45 lines).
>>> 1 out of 4 hunks FAILED
>>> checking file block/elevator.c
>>> Hunk #1 FAILED at 698.
>>> 1 out of 1 hunk FAILED
>>> checking file block/elevator.h
>>> Hunk #1 FAILED at 148.
>>> 1 out of 1 hunk FAILED
>>>
>>> I will try to apply and adjust manually.
>>
>> Just apply it on top of current -git, doesn't have to be your bisection
>> point.
>>
> 
> I applied it manually and now my testlab server boots :-)

Excellent! I'll get it staged for 6.11 instead. Thank for reporting and
testing.

> Just with the patch[1] on top of bisection point
> ... as it was faster to recompile this way ;-)

That's a pathetic excuse for a test box then ;-)

-- 
Jens Axboe