From: Sagi Grimberg <sagi@grimberg.me>
To: Lei Lei2 Yin <yinlei2@lenovo.com>,
"kbusch@kernel.org" <kbusch@kernel.org>,
"axboe@fb.com" <axboe@fb.com>, "hch@lst.de" <hch@lst.de>
Cc: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"cybeyond@foxmail.com" <cybeyond@foxmail.com>
Subject: Re: 回复: [External] Re: [PATCH] nvme: fix heap-use-after-free and oops in bio_endio for nvme multipath
Date: Wed, 22 Mar 2023 09:12:18 +0200 [thread overview]
Message-ID: <4ec55800-fe57-11f5-d282-a7e4c58f14ce@grimberg.me> (raw)
In-Reply-To: <PS1PR03MB4939A124F814F35E69C7D59B88819@PS1PR03MB4939.apcprd03.prod.outlook.com>
> No, I have not verified this issue with a system larger than 5.10.y(such as 5.15.y and 6.0 or furthor), because some function we need like cgroup in upper version kernel has changed too much, we can't use these upper version kernel.
Well, this would be the starting point.
> In addition , uptreams have change bi_disk's modify to bio_set_dev(bio, ns->disk->part0), and as you said there is no bi_disk in struct bio anymore. So that is too involving because of code dependencies, i want to do is what you said, to send an alternative surgical fix.
The correct course of action would be to identify and narrow down the
fix for this upstream, and then backport it back to stable kernel 5.10.y
> (I will confirm upstream for this problem in the near future, if it have same problem, i will submit this fix.)
Great.
> I'm not sure what evidence is needed to prove this problem and patch. The following is child bio and parent bio struct when heap-use-after-free occur catched by crash(I turn on kasan and panic_on_warn).
>
> Please help me confirm if this is enough, thanks.
It is clear that there is a bug in 5.10.y, what we are discussing is:
1. Is this problem relevant to upstream kernel?
2. If yes, we can debate the correct fix, as your initial patch is not
If not, then the upstream fix for this needs to be identified and
backported.
Having stable kernels drift away from the original code-base is a bad
idea.
prev parent reply other threads:[~2023-03-22 7:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-21 10:50 [PATCH] nvme: fix heap-use-after-free and oops in bio_endio for nvme multipath Lei Lei2 Yin
2023-03-21 11:09 ` Sagi Grimberg
2023-03-21 11:54 ` [External] " Lei Lei2 Yin
2023-03-21 12:26 ` Sagi Grimberg
2023-03-21 13:30 ` 回复: " Lei Lei2 Yin
2023-03-21 15:00 ` hch
2023-03-22 7:12 ` Sagi Grimberg [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=4ec55800-fe57-11f5-d282-a7e4c58f14ce@grimberg.me \
--to=sagi@grimberg.me \
--cc=axboe@fb.com \
--cc=cybeyond@foxmail.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=yinlei2@lenovo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).