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 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.