[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200226170728.GD22837@infradead.org>
Date: Wed, 26 Feb 2020 09:07:28 -0800
From: Christoph Hellwig <hch@...radead.org>
To: "Darrick J. Wong" <darrick.wong@...cle.com>
Cc: Matthew Wilcox <willy@...radead.org>,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-erofs@...ts.ozlabs.org, linux-ext4@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net, cluster-devel@...hat.com,
ocfs2-devel@....oracle.com, linux-xfs@...r.kernel.org
Subject: Re: [PATCH v8 25/25] iomap: Convert from readpages to readahead
On Wed, Feb 26, 2020 at 09:04:25AM -0800, Darrick J. Wong wrote:
> > @@ -456,15 +435,8 @@ iomap_readpages(struct address_space *mapping, struct list_head *pages,
> > unlock_page(ctx.cur_page);
> > put_page(ctx.cur_page);
> > }
> > -
> > - /*
> > - * Check that we didn't lose a page due to the arcance calling
> > - * conventions..
> > - */
> > - WARN_ON_ONCE(!ret && !list_empty(ctx.pages));
> > - return ret;
>
> After all the discussion about "if we still have ctx.cur_page we should
> just stop" in v7, I'm surprised that this patch now doesn't say much of
> anything, not even a WARN_ON()?
The code quoted above puts the cur_page reference. By dropping the
odd refactoring patch there is no need to check for cur_page being
left as a special condition as that still is the normal loop exit
state and properly handled, just as in the original iomap code.
Powered by blists - more mailing lists