All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <xiang@kernel.org>
To: Max Kellermann <max.kellermann@ionos.com>
Cc: xiang@kernel.org, chao@kernel.org, zbestahu@gmail.com,
	jefflexu@linux.alibaba.com, dhavale@google.com,
	linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio()
Date: Tue, 29 Apr 2025 11:06:52 +0800	[thread overview]
Message-ID: <aBBCTGo7I4OHyVAH@debian> (raw)
In-Reply-To: <20250428230933.3422273-1-max.kellermann@ionos.com>

On Tue, Apr 29, 2025 at 01:09:33AM +0200, Max Kellermann wrote:
> If bio_add_folio() fails (because it is full),
> erofs_fileio_scan_folio() needs to submit the I/O request via
> erofs_fileio_rq_submit() and allocate a new I/O request with an empty
> `struct bio`.  Then it retries the bio_add_folio() call.
> 
> However, at this point, erofs_onlinefolio_split() has already been
> called which increments `folio->private`; the retry will call
> erofs_onlinefolio_split() again, but there will never be a matching
> erofs_onlinefolio_end() call.  This leaves the folio locked forever
> and all waiters will be stuck in folio_wait_bit_common().
> 
> This bug has been added by commit ce63cb62d794 ("erofs: support
> unencoded inodes for fileio"), but was practically unreachable because
> there was room for 256 folios in the `struct bio` - until commit
> 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts") which
> reduced the array capacity to 16 folios.
> 
> It was now trivial to trigger the bug by manually invoking readahead
> from userspace, e.g.:
> 
>  posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED);
> 
> This should be fixed by invoking erofs_onlinefolio_split() only after
> bio_add_folio() has succeeded.  This is safe: asynchronous completions
> invoking erofs_onlinefolio_end() will not unlock the folio because
> erofs_fileio_scan_folio() is still holding a reference to be released
> by erofs_onlinefolio_end() at the end.
> 
> Fixes: ce63cb62d794 ("erofs: support unencoded inodes for fileio")
> Fixes: 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts")
> Cc: stable@vger.kernel.org
> Signed-off-by: Max Kellermann <max.kellermann@ionos.com>

Thanks for catching this! LGTM:
Reviewed-by: Gao Xiang <xiang@kernel.org>

Thanks,
Gao Xiang


  reply	other threads:[~2025-04-29  3:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-28 23:09 [PATCH] fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio() Max Kellermann
2025-04-29  3:06 ` Gao Xiang [this message]
2025-04-29  3:25 ` Hongbo Li

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=aBBCTGo7I4OHyVAH@debian \
    --to=xiang@kernel.org \
    --cc=chao@kernel.org \
    --cc=dhavale@google.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=max.kellermann@ionos.com \
    --cc=stable@vger.kernel.org \
    --cc=zbestahu@gmail.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.