linux-ext4 - Re: [PATCH 1/3] mm: Add folio_zero

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]

Date:   Thu, 9 Nov 2023 17:37:28 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-ext4@...r.kernel.org, gfs2@...ts.linux.dev,
        linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
        "Darrick J . Wong" <djwong@...nel.org>,
        linux-erofs@...ts.ozlabs.org, Theodore Ts'o <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Andreas Gruenbacher <agruenba@...hat.com>
Subject: Re: [PATCH 1/3] mm: Add folio_zero_tail() and use it in ext4

On Wed, Nov 08, 2023 at 03:06:06PM -0800, Andrew Morton wrote:
> >  
> > +/**
> > + * folio_zero_tail - Zero the tail of a folio.
> > + * @folio: The folio to zero.
> > + * @kaddr: The address the folio is currently mapped to.
> > + * @offset: The byte offset in the folio to start zeroing at.
> 
> That's the argument ordering I would expect.
> 
> > + * If you have already used kmap_local_folio() to map a folio, written
> > + * some data to it and now need to zero the end of the folio (and flush
> > + * the dcache), you can use this function.  If you do not have the
> > + * folio kmapped (eg the folio has been partially populated by DMA),
> > + * use folio_zero_range() or folio_zero_segment() instead.
> > + *
> > + * Return: An address which can be passed to kunmap_local().
> > + */
> > +static inline __must_check void *folio_zero_tail(struct folio *folio,
> > +		size_t offset, void *kaddr)
> 
> While that is not.  addr,len is far more common that len,addr?

But that's not len!  That's offset-in-the-folio.  ie we're doing:

memset(folio_address(folio) + offset, 0, folio_size(folio) - offset);

If we were doing:

memset(folio_address(folio), 0, len);

then yes, your suggestion is the right order.

Indeed, having the arguments in the current order would hopefully make
filesystem authors realise that this _isn't_ "len".