From: Eric Biggers <ebiggers@kernel.org>
To: Wu Bo <bo.wu@vivo.com>
Cc: Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>,
dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
Wu Bo <wubo.oduw@gmail.com>
Subject: Re: [PATCH 2/2] dm verity: don't verity if readahead failed
Date: Tue, 21 Nov 2023 15:01:04 -0800 [thread overview]
Message-ID: <20231121230104.GB2172@sol.localdomain> (raw)
In-Reply-To: <e18ec7ad7449f2aba885b93467005848745f4853.1700555778.git.bo.wu@vivo.com>
On Tue, Nov 21, 2023 at 01:55:29AM -0700, Wu Bo wrote:
> We found an issue under Android OTA scenario that many BIOs have to do
> FEC where the data under dm-verity is 100% complete and no corruption.
>
> Android OTA has many dm-block layers, from upper to lower:
> dm-verity
> dm-snapshot
> dm-origin & dm-cow
> dm-linear
> ufs
>
> Dm tables have to change 2 times during Android OTA merging process.
> When doing table change, the dm-snapshot will be suspended for a while.
> During this interval, we found there are many readahead IOs are
> submitted to dm_verity from filesystem. Then the kverity works are busy
> doing FEC process which cost too much time to finish dm-verity IO. And
> cause system stuck.
>
> We add some debug log and find that each readahead IO need around 10s to
> finish when this situation occurred. Because here has a IO
> amplification:
>
> dm-snapshot suspend
> erofs_readahead // 300+ io is submitted
> dm_submit_bio (dm_verity)
> dm_submit_bio (dm_snapshot)
> bio return EIO
> bio got nothing, it's empty
> verity_end_io
> verity_verify_io
> forloop range(0, io->n_blocks) // each io->nblocks ~= 20
> verity_fec_decode
> fec_decode_rsb
> fec_read_bufs
> forloop range(0, v->fec->rsn) // v->fec->rsn = 253
> new_read
> submit_bio (dm_snapshot)
> end loop
> end loop
> dm-snapshot resume
>
> Readahead BIO got nothing during dm-snapshot suspended. So all of them
> will do FEC.
> Each readahead BIO need to do io->n_blocks ~= 20 times verify.
> Each block need to do fec, and every block need to do v->fec->rsn = 253
> times read.
> So during the suspend interval(~200ms), 300 readahead BIO make
> 300*20*253 IOs on dm-snapshot.
>
> As readahead IO is not required by user space, and to fix this issue,
> I think it would be better to pass it to upper layer to handle it.
>
> Signed-off-by: Wu Bo <bo.wu@vivo.com>
> ---
> drivers/md/dm-verity-target.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
> index 42b2483eb08c..d242e50ec869 100644
> --- a/drivers/md/dm-verity-target.c
> +++ b/drivers/md/dm-verity-target.c
> @@ -668,7 +668,9 @@ static void verity_end_io(struct bio *bio)
>
> verity_fec_init_io(io);
> if (bio->bi_status &&
> - (!verity_fec_is_enabled(io->v) || verity_is_system_shutting_down())) {
> + (!verity_fec_is_enabled(io->v) ||
> + verity_is_system_shutting_down() ||
> + (bio->bi_opf & REQ_RAHEAD))) {
> verity_finish_io(io, bio->bi_status);
> return;
> }
Thanks, this seems reasonable to me. As with your previous patch: what commit
introduced this issue? To me this looks like a longstanding issue, maybe dating
back to the original addition of FEC support to dm-verity by commit a739ff3f543a
("dm verity: add support for forward error correction"); do you agree? Can you
please add Fixes and "Cc stable" tags to your patch? Thanks!
- Eric
prev parent reply other threads:[~2023-11-21 23:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 8:55 [PATCH 0/2] dm verity: fix FEC stuck during lower dm suspend Wu Bo
2023-11-21 8:55 ` [PATCH 1/2] dm verity: init fec io before cleaning it Wu Bo
2023-11-21 22:57 ` Eric Biggers
2023-11-21 8:55 ` [PATCH 2/2] dm verity: don't verity if readahead failed Wu Bo
2023-11-21 23:01 ` Eric Biggers [this message]
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=20231121230104.GB2172@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=agk@redhat.com \
--cc=bo.wu@vivo.com \
--cc=dm-devel@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=snitzer@kernel.org \
--cc=wubo.oduw@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.