[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8gXodKIUneO+XQb@casper.infradead.org>
Date: Wed, 18 Jan 2023 16:00:33 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Christoph Hellwig <hch@....de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Hugh Dickins <hughd@...gle.com>, linux-afs@...ts.infradead.org,
linux-btrfs@...r.kernel.org, linux-ext4@...r.kernel.org,
cluster-devel@...hat.com, linux-mm@...ck.org,
linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-nilfs@...r.kernel.org
Subject: Re: [PATCH 7/9] gfs2: handle a NULL folio in gfs2_jhead_process_page
On Wed, Jan 18, 2023 at 10:43:27AM +0100, Christoph Hellwig wrote:
> filemap_get_folio can return NULL, so exit early for that case.
I'm not sure it can return NULL in this specific case. As I understand
this code, we're scanning the journal looking for the log head. We've
just submitted the bio to read this page. I suppose memory pressure
could theoretically push the page out, but if it does, we're doing the
wrong thing by just returning here; we need to retry reading the page.
Assuming we're not willing to do the work to add that case, I think I'd
rather see the crash in folio_wait_locked() than get data corruption
from failing to find the head of the log.
> Signed-off-by: Christoph Hellwig <hch@....de>
> ---
> fs/gfs2/lops.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c
> index 1902413d5d123e..51d4b610127cdb 100644
> --- a/fs/gfs2/lops.c
> +++ b/fs/gfs2/lops.c
> @@ -472,6 +472,8 @@ static void gfs2_jhead_process_page(struct gfs2_jdesc *jd, unsigned long index,
> struct folio *folio;
>
> folio = filemap_get_folio(jd->jd_inode->i_mapping, index);
> + if (!folio)
> + return;
>
> folio_wait_locked(folio);
> if (folio_test_error(folio))
> --
> 2.39.0
>
Powered by blists - more mailing lists