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".
