linux-kernel - Re: [PATCH] loop: Increase bsize variable from unsigned short to unsigned int

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: <CAEemH2d9uzDv030eYRs_hsu_PcbVTXR75YPyN4Ux2v9AVxd5Lg@mail.gmail.com>
Date: Tue, 27 Aug 2024 16:02:51 +0800
From: Li Wang <liwang@...hat.com>
To: John Garry <john.g.garry@...cle.com>
Cc: linux-kernel@...r.kernel.org, ltp@...ts.linux.it, 
	Jan Stancek <jstancek@...hat.com>, Damien Le Moal <dlemoal@...nel.org>, 
	Stefan Hajnoczi <stefanha@...hat.com>, linux-block@...r.kernel.org, axboe@...nel.dk
Subject: Re: [PATCH] loop: Increase bsize variable from unsigned short to
 unsigned int

John Garry <john.g.garry@...cle.com> wrote:

> On 27/08/2024 08:35, Li Wang wrote:
> > On Tue, Aug 27, 2024 at 3:20 PM John Garry <john.g.garry@...cle.com> wrote:
> >>
> >> On 27/08/2024 04:22, Li Wang wrote:
> >>
> >> +linux-block, Jens
> >>
> >>> This change allows the loopback driver to handle larger block sizes
> >>
> >> larger than what? PAGE_SIZE?
> >
> > Yes,
>
> Please then explicitly mention that

Sure.

>
> > system should return EINVAL when the tested bsize is larger than PAGE_SIZE.
> > But due to the loop_reconfigure_limits() cast it to 'unsined short' that
>  > never gets an expected error when testing invalid logical block size.>
> > That's why LTP/ioctl_loop06 failed on a system with 64k (ppc64le) pagesize
> > (since kernel-v6.11-rc1 with patches):
> >
> >    9423c653fe6110 ("loop: Don't bother validating blocksize")
> >    fe3d508ba95bc6 ("block: Validate logical block size in blk_validate_limits()")
> >
> >
> >
>
> I feel that you should be adding a fixes tag, but it seems that those
> commits only expose the issue, and whatever introduced unsigned short
> usage was not right. Maybe you can just get this included for 6.11,
> where 9423c653fe6110 was introduced.

Ok, we can mention that two commits exposed the problem since v6.11-rc1.
I will send V2 including that. Thanks!

-- 
Regards,
Li Wang