linux-kernel - Re: [RESEND PATCH] dm-ebs: Mark full buffer dirty even on partial write

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: <aR8MQOFX0pVldcUT@pc636>
Date: Thu, 20 Nov 2025 13:40:32 +0100
From: Uladzislau Rezki <urezki@...il.com>
To: Christoph Hellwig <hch@....de>, Mikulas Patocka <mpatocka@...hat.com>
Cc: Christoph Hellwig <hch@....de>, Mikulas Patocka <mpatocka@...hat.com>,
	Benjamin Marzinski <bmarzins@...hat.com>,
	Alasdair Kergon <agk@...hat.com>, DMML <dm-devel@...ts.linux.dev>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mike Snitzer <snitzer@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH] dm-ebs: Mark full buffer dirty even on partial
 write

On Thu, Nov 20, 2025 at 01:08:57PM +0100, Uladzislau Rezki wrote:
> On Thu, Nov 20, 2025 at 07:21:46AM +0100, Christoph Hellwig wrote:
> > On Wed, Nov 19, 2025 at 06:26:13PM +0100, Mikulas Patocka wrote:
> > > 
> > > 
> > > On Wed, 19 Nov 2025, Christoph Hellwig wrote:
> > > 
> > > > On Tue, Nov 18, 2025 at 06:21:56PM +0100, Mikulas Patocka wrote:
> > > > > OK - I accepted Uladzislau's patch. As logical block size and physical 
> > > > > block size seem to be unreliable, it's better to set the size in dm-ebs.
> > > > 
> > > > logical and physical block size are reliable.  Uladzislau just seems
> > > > to have a completely broken device that needs fixing, because it will
> > > 
> > > He created a qemu-emulated NVMe device with physical and logical block 
> > > size 8192 in a virtual machine. And logical block size was reported as 512 
> > > in the guest kernel - so it is either a qemu bug or a kernel bug.
> > 
> > No, that's not the case.  If you use his command line you'll see a qemu
> > device with 8192 logical blocks assuming you have support for large
> > folios, or a completely unusuable device that claims to have 512
> > byte blocks for compatibility, but also a capacity of zero so that no
> > one can use it for anything but passthrough.
> > 
> > > in nvme_update_disk_info there is this piece of code:
> > >         if (blk_validate_block_size(bs)) {
> > >                 bs = (1 << 9);
> > >                 valid = false;
> > >         }
> > 
> > Yes, that's what I mentioned above.  The valid=false sets the capacity
> > to zero, so you're not actually going to be able to use this device.
> > 
> > > So, the valid block size depends on whether CONFIG_TRANSPARENT_HUGEPAGE is 
> > > defined, which is quite weird.
> > 
> > And also the page size, and none of that is too weird.  You need support
> > efficiently allocating large order folios to support a
> > block size > PAGE_SIZE and currently CONFIG_TRANSPARENT_HUGEPAGE is
> > the guard for that.  There was some talk of lifting that, but that
> > requires a bit of work.
> > 
> Could you please check below? Is the last one is correctly reported?
> I have enabled the CONFIG_TRANSPARENT_HUGEPAGE option. If i specify,
> 8192, 8192 first case, reports are what i set. Second variant 512, 8129
> shows 512, 512:
> 
> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
> CONFIG_TRANSPARENT_HUGEPAGE=y
> CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
> # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
> # CONFIG_TRANSPARENT_HUGEPAGE_NEVER is not set
> 
> -device nvme,drive=drv0,serial=foo,logical_block_size=8192,physical_block_size=8192
> urezki@...38:~$ sudo nvme list
> Node                  Generic               SN                   Model                                    Namespace Usage                      Format           FW Rev
> --------------------- --------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
> /dev/nvme0n1          /dev/ng0n1            foo                  QEMU NVMe Ctrl                           1           8.49  GB /   8.49  GB      8 KiB +  0 B   10.0.6
> urezki@...38:~$ sudo cat /sys/block/nvme0n1/queue/logical_block_size
> 8192
> urezki@...38:~$ sudo cat /sys/block/nvme0n1/queue/physical_block_size
> 8192
> urezki@...38:~$
> 
> 
> -device nvme,drive=drv0,serial=foo,logical_block_size=512,physical_block_size=8192
> urezki@...38:~$ sudo nvme list
> Node                  Generic               SN                   Model                                    Namespace Usage                      Format           FW Rev
> --------------------- --------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
> /dev/nvme0n1          /dev/ng0n1            foo                  QEMU NVMe Ctrl                           1           8.49  GB /   8.49  GB    512   B +  0 B   10.0.6
> urezki@...38:~$ sudo cat /sys/block/nvme0n1/queue/physical_block_size
> 512
> urezki@...38:~$ sudo cat /sys/block/nvme0n1/queue/logical_block_size
> 512
> urezki@...38:~$
> 
It might be that qemu changes this, i will check.

Christoph, but i assume it is valid case: logical=512B, physical=8192K.
Could you please confirm?

Thanks!

--
Uladzislau Rezki