linux-kernel - Re: [PATCH 1/2] nbd: implement the 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZrHVbQ5_lvCCegK_@pc220518.home.grep.be>
Date: Tue, 6 Aug 2024 09:49:01 +0200
From: Wouter Verhelst <w@...r.be>
To: Eric Blake <eblake@...hat.com>
Cc: Josef Bacik <josef@...icpanda.com>, Jens Axboe <axboe@...nel.dk>,
	linux-block@...r.kernel.org, nbd@...er.debian.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] nbd: implement the WRITE_ZEROES command

On Mon, Aug 05, 2024 at 07:52:42AM -0500, Eric Blake wrote:
> On Sat, Aug 03, 2024 at 03:04:30PM GMT, Wouter Verhelst wrote:
> > The NBD protocol defines a message for zeroing out a region of an export
> > 
> > Add support to the kernel driver for that message.
> > 
> > Signed-off-by: Wouter Verhelst <w@...r.be>
> > ---
> >  drivers/block/nbd.c      | 8 ++++++++
> >  include/uapi/linux/nbd.h | 5 ++++-
> >  2 files changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> > index 5b1811b1ba5f..215e7ea9a3c3 100644
> > --- a/drivers/block/nbd.c
> > +++ b/drivers/block/nbd.c
> > @@ -352,6 +352,8 @@ static int __nbd_set_size(struct nbd_device *nbd, loff_t bytesize,
> >  	}
> >  	if (nbd->config->flags & NBD_FLAG_ROTATIONAL)
> >  		lim.features |= BLK_FEAT_ROTATIONAL;
> > +	if (nbd->config->flags & NBD_FLAG_SEND_WRITE_ZEROES)
> > +		lim.max_write_zeroes_sectors = UINT_MAX;
> 
> Is that number accurate, when the kernel has not yet been taught to
> use 64-bit transactions and can therefore only request a 32-bit byte
> length on any one transaction?  Would a better limit be
> UINT_MAX/blksize?

Thanks, good catch.

I copied the logic from the handling of the TRIM command (i.e., the
discard logic), which has the same flawed UINT_MAX behavior. I will fix
this in v2 and add a fix for the discard code.

-- 
     w@...r.{be,co.za}
wouter@...ep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.