From: Guoqing Jiang <guoqing.jiang@linux.dev>
To: "lizhijian@fujitsu.com" <lizhijian@fujitsu.com>,
Bob Pearson <rpearsonhpe@gmail.com>,
Haris Iqbal <haris.iqbal@ionos.com>
Cc: Yanjun Zhu <yanjun.zhu@linux.dev>, Jason Gunthorpe <jgg@ziepe.ca>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Leon Romanovsky <leon@kernel.org>
Subject: Re: [RESEND RFC PATCH for-next] Revert "RDMA/rxe: Create duplicate mapping tables for FMRs"
Date: Mon, 25 Jul 2022 10:16:32 +0800 [thread overview]
Message-ID: <34344e02-fb6f-4ddf-547b-bcbfe81c8e84@linux.dev> (raw)
In-Reply-To: <2b9261f7-8ade-1892-5f71-5e4de13927a4@fujitsu.com>
On 7/25/22 9:13 AM, lizhijian@fujitsu.com wrote:
> On 22/07/2022 06:19, Bob Pearson wrote:
>> On 7/20/22 05:50, Haris Iqbal wrote:
>>> On Wed, Jul 20, 2022 at 12:22 PM Li Zhijian<lizhijian@fujitsu.com> wrote:
>>>> Below 2 commits will be reverted:
>>>> 8ff5f5d9d8cf ("RDMA/rxe: Prevent double freeing rxe_map_set()")
>>>> 647bf13ce944 ("RDMA/rxe: Create duplicate mapping tables for FMRs")
>>>>
>>>> The community has a few bug reports which pointed this commit at last.
>>>> Some proposals are raised up in the meantime but all of them have no
>>>> follow-up operation.
>>>>
>>>> The previous commit led the map_set of FMR to be not avaliable any more if
>>>> the MR is registered again after invalidating. Although the mentioned
>>>> patch try to fix a potential race in building/accessing the same table
>>>> for fast memory regions, it broke rnbd etc ULPs. Since the latter could
>>>> be worse, revert this patch.
>>>>
>>>> With previous commit, it's observed that a same MR in rnbd server will
>>>> trigger below code path:
>>> Looks Good. I tested the patch against rdma for-next and it solves the
>>> problem mentioned in the commit.
>>> One small nitpick. It should be rtrs, and not rnbd in the commit message.
>>>
>>> Feel free to add my,
>>>
>>> Tested-by: Md Haris Iqbal<haris.iqbal@ionos.com>
>>>
>>>> -> rxe_mr_init_fast()
>>>> |-> alloc map_set() # map_set is uninitialized
>>>> |...-> rxe_map_mr_sg() # build the map_set
>>>> |-> rxe_mr_set_page()
>>>> |...-> rxe_reg_fast_mr() # mr->state change to VALID from FREE that means
>>>> # we can access host memory(such rxe_mr_copy)
>>>> |...-> rxe_invalidate_mr() # mr->state change to FREE from VALID
>>>> |...-> rxe_reg_fast_mr() # mr->state change to VALID from FREE,
>>>> # but map_set was not built again
>>>> |...-> rxe_mr_copy() # kernel crash due to access wild addresses
>>>> # that lookup from the map_set
>>>>
>> Where is the use case for this? All the FMR examples I am aware of call rxe_map_mr_sg()
>> between each reg_fast_mr/invalidate_mr() sequence. I am not familiar with rtrs.
>> What is it?
> it would happen when we are creating a rnbd connection.
To be accurate, it is rtrs connection.
> modprobe rnbd_server
> modprobe rnbd_client
>
> echo "sessname=foo path=ip:<server-ip> device_path=/dev/nvme0n1" > /sys/devices/virtual/rnbd-client/ctl/map_device
>
>
> I have tested blktests and above rnbd case, they works fine.
> Further more, your "[PATCH RFC] RDMA/rxe: Allow re-registration of FMRs" does'n fix the above rnbd use case.
Thanks for the effort! I believe rnbd/rtrs over rxe had been broken for
a while, can we agree
the problem need to be fixed?
Thanks,
Guoqing
next prev parent reply other threads:[~2022-07-25 2:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 10:29 [RESEND RFC PATCH for-next] Revert "RDMA/rxe: Create duplicate mapping tables for FMRs" Li Zhijian
2022-07-20 10:50 ` Haris Iqbal
2022-07-21 18:18 ` Bob Pearson
2022-07-25 4:00 ` lizhijian
2022-07-25 19:15 ` Bob Pearson
2022-07-21 22:19 ` Bob Pearson
2022-07-22 10:43 ` Haris Iqbal
2022-07-22 15:13 ` Jason Gunthorpe
2022-07-25 1:13 ` lizhijian
2022-07-25 2:16 ` Guoqing Jiang [this message]
2022-07-25 9:25 ` lizhijian
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=34344e02-fb6f-4ddf-547b-bcbfe81c8e84@linux.dev \
--to=guoqing.jiang@linux.dev \
--cc=haris.iqbal@ionos.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lizhijian@fujitsu.com \
--cc=rpearsonhpe@gmail.com \
--cc=yanjun.zhu@linux.dev \
/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