linux-kernel - Re: [PATCH 4/5] block: move queue enter logic into blk_mq_submit

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: <4586fc98-1350-c0f0-594d-888514cba277@gmail.com>
Date:   Sat, 13 Nov 2021 20:02:23 +1300
From:   Michael Schmitz <schmitzmic@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     "Martin K. Petersen" <martin.petersen@...cle.com>,
        Jens Axboe <axboe@...nel.dk>,
        Christoph Hellwig <hch@...radead.org>,
        linux-block@...r.kernel.org,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/5] block: move queue enter logic into
 blk_mq_submit_bio()

Hi Geert, Jens,

On 13/11/21 11:34, Michael Schmitz wrote:
> Hi Geert,
>
> On 12/11/21 20:37, Geert Uytterhoeven wrote:
>> Hi Michael,
>>
>> On Thu, Nov 11, 2021 at 10:35 PM Michael Schmitz
>> <schmitzmic@...il.com> wrote:
>>> how easy is that to reproduce?
>>
>> Fairly easy: it happens either on mounting, or after a few seconds
>> booting
>> into my old Debian userspace.
>
> I must be too thick for this:
>
> EXT4-fs (sda1): Cannot load crc32c driver.
> VFS: Cannot open root device "sda1" or unknown-block(8,1): error -80
>
> (linux-block 5833291ab6de, from kernel.org)
>
> Same config on m68k 5.15 works just fine.

FWIW - I had to revert cad439fc040efe5f4381e3a7d583c5c200dbc186 to 
overcome this, and reproduce Geert's finding.

Cheers,

	Michael

>
> But this looks resolved now, so I'll punt for now ...
>
> Cheers,
>
>     Michael
>
>>
>>> sd_setup_read_write_cmnd() does not validate the request's FUA flag
>>> against sdkp->DPOFUA (not suggesting that it should ...). I'd like to
>>> try and trace when such a mismatch happens.
>>
>> Thanks!
>>
>>> On 12/11/21 03:48, Geert Uytterhoeven wrote:
>>>> On Thu, Nov 11, 2021 at 2:19 PM Martin K. Petersen
>>>> <martin.petersen@...cle.com> wrote:
>>>>>> sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK
>>>>>> driverbyte=DRIVER_OK cmd_age=0s
>>>>>> sd 0:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current]
>>>>>> sd 0:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb
>>>>>> sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 08 00 00 00 01 00 00 08 00
>>>>>> critical target error, dev sda, sector 1 op 0x1:(WRITE) flags
>>>>>> 0x20800 phys_seg 1 prio class 0
>>>>>> Buffer I/O error on dev sda1, logical block 0, lost sync page write
>>>>>
>>>>> Peculiar. That write command looks OK to me. I wonder if it's the FUA
>>>>> bit that trips it?
>>>>>
>>>>> What does:
>>>>>
>>>>> # dmesg | grep FUA
>>>>>
>>>>> say?
>>>>
>>>> sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
>>>> support DPO or FUA
>>
>> 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
>>