All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Hannes Reinecke <hare@suse.de>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Pankaj Raghav <p.raghav@samsung.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 1/7] buffer: Return bool from grow_dev_folio()
Date: Sat, 30 Dec 2023 09:23:01 +0000	[thread overview]
Message-ID: <ZY/hdUqeKMi0IVp6@casper.infradead.org> (raw)
In-Reply-To: <CAKFNMo=1yLxL9RR4XBY6=SkWej7tstTEiFQjUFWjxMs+5=YPFw@mail.gmail.com>

On Fri, Nov 10, 2023 at 12:43:43PM +0900, Ryusuke Konishi wrote:
> On Fri, Nov 10, 2023 at 6:07 AM Matthew Wilcox (Oracle) wrote:
> > +               /* Caller should retry if this call fails */
> > +               end_block = ~0ULL;
> >                 if (!try_to_free_buffers(folio))
> > -                       goto failed;
> > +                       goto unlock;
> >         }
> >
> 
> > -       ret = -ENOMEM;
> >         bh = folio_alloc_buffers(folio, size, gfp | __GFP_ACCOUNT);
> >         if (!bh)
> > -               goto failed;
> > +               goto unlock;
> 
> Regarding this folio_alloc_buffers() error path,
> If folio_buffers() was NULL, here end_block is 0, so this function
> returns false (which means "have a permanent failure").
> 
> But, if folio_buffers() existed and they were freed with
> try_to_free_buffers() because of bh->b_size != size, here end_block
> has been set to ~0ULL, so it seems to return true ("succeeded").
> 
> Does this semantic change match your intent?
> 
> Otherwise, I think end_block should be set to 0 just before calling
> folio_alloc_buffers().

Thanks for the review, and sorry for taking so long to get back to you.
The change was unintentional (but memory allocation failure wth GFP_KERNEL
happens so rarely that our testing was never going to catch it)

I think I should just move the assignment to end_block inside the 'if'.
It's just more obvious what's going on.  Andrew prodded me to be more
explicit about why memory allocation is a "permanent" failure, but
failing to free buffers is not.

I'll turn this into a proper patch submission later.

diff --git a/fs/buffer.c b/fs/buffer.c
index d5ce6b29c893..d3bcf601d3e5 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1028,8 +1028,8 @@ static sector_t folio_init_buffers(struct folio *folio,
  *
  * This is used purely for blockdev mappings.
  *
- * Returns false if we have a 'permanent' failure.  Returns true if
- * we succeeded, or the caller should retry.
+ * Returns false if we have a failure which cannot be cured by retrying
+ * without sleeping.  Returns true if we succeeded, or the caller should retry.
  */
 static bool grow_dev_folio(struct block_device *bdev, sector_t block,
 		pgoff_t index, unsigned size, gfp_t gfp)
@@ -1051,10 +1051,17 @@ static bool grow_dev_folio(struct block_device *bdev, sector_t block,
 			goto unlock;
 		}
 
-		/* Caller should retry if this call fails */
-		end_block = ~0ULL;
-		if (!try_to_free_buffers(folio))
+		/*
+		 * Retrying may succeed; for example the folio may finish
+		 * writeback, or buffers may be cleaned.  This should not
+		 * happen very often; maybe we have old buffers attached to
+		 * this blockdev's page cache and we're trying to change
+		 * the block size?
+		 */
+		if (!try_to_free_buffers(folio)) {
+			end_block = ~0ULL;
 			goto unlock;
+		}
 	}
 
 	bh = folio_alloc_buffers(folio, size, gfp | __GFP_ACCOUNT);

  reply	other threads:[~2023-12-30  9:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09 21:06 [PATCH v2 0/7] More buffer_head cleanups Matthew Wilcox (Oracle)
2023-11-09 21:06 ` [PATCH v2 1/7] buffer: Return bool from grow_dev_folio() Matthew Wilcox (Oracle)
2023-11-10  3:43   ` Ryusuke Konishi
2023-12-30  9:23     ` Matthew Wilcox [this message]
2023-12-30 12:22       ` Ryusuke Konishi
2023-11-09 21:06 ` [PATCH v2 2/7] buffer: Calculate block number inside folio_init_buffers() Matthew Wilcox (Oracle)
2023-11-09 21:06 ` [PATCH v2 3/7] buffer: Fix grow_buffers() for block size > PAGE_SIZE Matthew Wilcox (Oracle)
2023-11-10  6:37   ` Ryusuke Konishi
2023-11-10 11:29     ` Ryusuke Konishi
2023-11-10 13:23       ` Matthew Wilcox
2023-11-12  4:52   ` kernel test robot
2023-11-13 17:10     ` Andrew Morton
2023-11-13 17:20       ` Nathan Chancellor
2023-11-15 11:14         ` Naresh Kamboju
2023-11-09 21:06 ` [PATCH v2 4/7] buffer: Cast block to loff_t before shifting it Matthew Wilcox (Oracle)
2023-11-09 21:06 ` [PATCH v2 5/7] buffer: Fix various functions for block size > PAGE_SIZE Matthew Wilcox (Oracle)
2023-11-10  7:48   ` Ryusuke Konishi
2023-11-10 13:36     ` Matthew Wilcox
2023-11-10 15:23       ` Ryusuke Konishi
2023-11-09 21:06 ` [PATCH v2 6/7] buffer: Handle large folios in __block_write_begin_int() Matthew Wilcox (Oracle)
2023-11-09 21:06 ` [PATCH v2 7/7] buffer: Fix more functions for block size > PAGE_SIZE Matthew Wilcox (Oracle)
2023-11-10  4:50   ` Eric Biggers
2023-11-10 14:26     ` Matthew Wilcox
2023-11-11 18:06       ` Eric Biggers
2023-11-12  4:52         ` Matthew Wilcox
2023-11-12  6:00           ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZY/hdUqeKMi0IVp6@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=hare@suse.de \
    --cc=konishi.ryusuke@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=p.raghav@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.