linux-kernel - Re: [PATCH v14 098/138] iomap: Use folio offsets instead of page offsets

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, 15 Jul 2021 15:55:39 -0700
From:   "Darrick J. Wong" <djwong@...nel.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v14 098/138] iomap: Use folio offsets instead of page
 offsets

On Thu, Jul 15, 2021 at 11:48:00PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 15, 2021 at 02:26:57PM -0700, Darrick J. Wong wrote:
> > > +	size_t poff = offset_in_folio(folio, *pos);
> > > +	size_t plen = min_t(loff_t, folio_size(folio) - poff, length);
> > 
> > I'm confused about 'size_t poff' here vs. 'unsigned end' later -- why do
> > we need a 64-bit quantity for poff?  I suppose some day we might want to
> > have folios larger than 4GB or so, but so far we don't need that large
> > of a byte offset within a page/folio, right?
> > 
> > Or are you merely moving the codebase towards using size_t for all byte
> > offsets?
> 
> Both.  'end' isn't a byte count -- it's a block count.
> 
> > >  	if (orig_pos <= isize && orig_pos + length > isize) {
> > > -		unsigned end = offset_in_page(isize - 1) >> block_bits;
> > > +		unsigned end = offset_in_folio(folio, isize - 1) >> block_bits;
> 
> That right shift makes it not-a-byte-count.
> 
> I don't especially want to do all the work needed to support folios >2GB,
> but I do like using size_t to represent a byte count.

DOH.  Yes, I just noticed that.

TBH I doubt anyone's really going to care about 4GB folios anyway.

Reviewed-by: Darrick J. Wong <djwong@...nel.org>

--D