[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200521233940.GH28818@bombadil.infradead.org>
Date: Thu, 21 May 2020 16:39:40 -0700
From: Matthew Wilcox <willy@...radead.org>
To: Dave Chinner <david@...morbit.com>
Cc: linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 14/36] iomap: Support large pages in
iomap_adjust_read_range
On Fri, May 22, 2020 at 08:24:38AM +1000, Dave Chinner wrote:
> > @@ -571,7 +572,6 @@ static int
> > __iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, int flags,
> > struct page *page, struct iomap *srcmap)
> > {
> > - struct iomap_page *iop = iomap_page_create(inode, page);
> > loff_t block_size = i_blocksize(inode);
> > loff_t block_start = pos & ~(block_size - 1);
> > loff_t block_end = (pos + len + block_size - 1) & ~(block_size - 1);
> > @@ -580,9 +580,10 @@ __iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, int flags,
> >
> > if (PageUptodate(page))
> > return 0;
> > + iomap_page_create(inode, page);
>
> What problem does this fix? i.e. if we can get here with an
> uninitialised page, why isn't this a separate bug fix. I don't see
> anything in this patch that actually changes behaviour, and there's
> nothing in the commit description to tell me why this is here,
> so... ???
I'm not fixing anything ... just moving the call to iomap_page_create()
from the opening stanza to down here because we no longer need a struct
iomap_page pointer in this function.
Powered by blists - more mailing lists