linux-kernel - Re: [PATCH] block: initialize auto integrity buffer opaque

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: <CADUfDZqJ0_7f+r-V0MsFwMT49NqQdwdHNGkQyqMOq50oqPBYFw@mail.gmail.com>
Date: Thu, 8 Jan 2026 08:31:37 -0800
From: Caleb Sander Mateos <csander@...estorage.com>
To: Christoph Hellwig <hch@....de>
Cc: Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: initialize auto integrity buffer opaque

On Thu, Jan 8, 2026 at 5:58 AM Christoph Hellwig <hch@....de> wrote:
>
> The subject sounds a little weird.  From looking at the commit
> message and the code change I'd expect it to be something like:
>
> block: zero auto integrity buffer when not fully occupied by PI tuple
>
> does that make sense?

Yes, that sounds fine. "opaque" is how the FS_IOC_GETLBMD_CAP ioctl
refers to the non-PI metadata, but I guess it's not widely used
terminology?

>
> > Switch the gfp_t variable to bool zero_buffer since it's only used to
> > compute the zero_buffer argument to bio_integrity_alloc_buf().
>
> Yeah, that also makes total sense now.  But maybe split it into a
> separate cleanup patch to not detract from the bug fix?

Sure.

Thanks,
Caleb