From: Leon Romanovsky <leon@kernel.org>
To: Haris Iqbal <haris.iqbal@ionos.com>
Cc: linux-rdma@vger.kernel.org, bvanassche@acm.org, jgg@ziepe.ca,
jinpu.wang@ionos.com,
Grzegorz Prajsner <grzegorz.prajsner@ionos.com>
Subject: Re: [PATCH for-next 01/13] RDMA/rtrs-srv: Make rtrs_srv_open fail if its a second call
Date: Mon, 12 Aug 2024 15:15:20 +0300 [thread overview]
Message-ID: <20240812121520.GF12060@unreal> (raw)
In-Reply-To: <CAJpMwyh7ytEawa=Yzg8CM=QZROvoBY70unhFvJdbAW9BU+xoUg@mail.gmail.com>
On Mon, Aug 12, 2024 at 01:17:11PM +0200, Haris Iqbal wrote:
> On Mon, Aug 12, 2024 at 12:59 PM Leon Romanovsky <leon@kernel.org> wrote:
> >
> > On Mon, Aug 12, 2024 at 12:39:06PM +0200, Haris Iqbal wrote:
> > > On Mon, Aug 12, 2024 at 12:34 PM Leon Romanovsky <leon@kernel.org> wrote:
> > > >
> > > > On Mon, Aug 12, 2024 at 12:16:19PM +0200, Haris Iqbal wrote:
> > > > > On Sun, Aug 11, 2024 at 10:38 AM Leon Romanovsky <leon@kernel.org> wrote:
> > > > > >
> > > > > > On Fri, Aug 09, 2024 at 03:15:26PM +0200, Md Haris Iqbal wrote:
> > > > > > > Do not allow opening RTRS server if it is already in use and print
> > > > > > > proper error message.
> > > > > >
> > > > > > 1. How is it even possible? I see only one call to rtrs_srv_open() and
> > > > > > it is happening when the driver is loaded.
> > > > >
> > > > > rtrs_srv_open() is NOT called during RTRS driver load. It is called
> > > > > during RNBD driver load, which is a client which uses RTRS.
> > > > > RTRS server currently works with only a single client. Hence if, while
> > > > > in use by RNBD, another driver wants to use RTRS and calls
> > > > > rtrs_srv_open(), it should fail.
> > > >
> > > > ➜ kernel git:(rdma-next) ✗ git grep rtrs_srv_open
> > > > drivers/block/rnbd/rnbd-srv.c: rtrs_ctx = rtrs_srv_open(&rtrs_ops, port_nr); <---- SINGLE CALL
> > > > drivers/block/rnbd/rnbd-srv.c: pr_err("rtrs_srv_open(), err: %pe\n", rtrs_ctx);
> > > > drivers/infiniband/ulp/rtrs/rtrs-srv.c: * rtrs_srv_open() - open RTRS server context
> > > > drivers/infiniband/ulp/rtrs/rtrs-srv.c:struct rtrs_srv_ctx *rtrs_srv_open(struct rtrs_srv_ops *ops, u16 port)
> > > > drivers/infiniband/ulp/rtrs/rtrs-srv.c:EXPORT_SYMBOL(rtrs_srv_open);
> > > > drivers/infiniband/ulp/rtrs/rtrs.h:struct rtrs_srv_ctx *rtrs_srv_open(struct rtrs_srv_ops *ops, u16 port);
> > > >
> > > > 807 static int __init rnbd_srv_init_module(void)
> > > > 808 {
> > > > 809 int err = 0;
> > > > 810
> > > > 811 BUILD_BUG_ON(sizeof(struct rnbd_msg_hdr) != 4);
> > > > 812 BUILD_BUG_ON(sizeof(struct rnbd_msg_sess_info) != 36);
> > > > 813 BUILD_BUG_ON(sizeof(struct rnbd_msg_sess_info_rsp) != 36);
> > > > 814 BUILD_BUG_ON(sizeof(struct rnbd_msg_open) != 264);
> > > > 815 BUILD_BUG_ON(sizeof(struct rnbd_msg_close) != 8);
> > > > 816 BUILD_BUG_ON(sizeof(struct rnbd_msg_open_rsp) != 56);
> > > > 817 rtrs_ops = (struct rtrs_srv_ops) {
> > > > 818 .rdma_ev = rnbd_srv_rdma_ev,
> > > > 819 .link_ev = rnbd_srv_link_ev,
> > > > 820 };
> > > > 821 rtrs_ctx = rtrs_srv_open(&rtrs_ops, port_nr);
> > > > 822 if (IS_ERR(rtrs_ctx)) {
> > > > 823 pr_err("rtrs_srv_open(), err: %pe\n", rtrs_ctx); <---- ALREADY PRINTED ERROR
> > > > 824 return PTR_ERR(rtrs_ctx);
> > > > 825 }
> > > >
> > > > ...
> > > >
> > > > 843 module_init(rnbd_srv_init_module); <---- SINGLE CALL
> > > >
> > > > Upstream code has only on RNBD and one RTRS.
> > >
> > > Yes. But they are different drivers. RTRS as a stand-alone ULP does
> > > not know about RNBD or for that matter any other client driver, which
> > > may use it, either out of tree or in the future. If RTRS can serve
> > > only a single client, then it should should have protection for
> > > multiple calls to *_open().
> >
> > For now, there is only one upstream client and server.
>
> In my understanding, its the general rule of abstraction that this
> type of limitation is handled where it exists.
We have such protection and it is called "monolithic kernel".
>
> >
> > I want to remind you that during initial submission of RTR code, the
> > feedback was that this ULP shouldn't exist in first place and right
> > thing to do it is to use NVMe over fabrics.
> >
> > So chances that we will have real out-of-tree client are very low.
>
> One reason for us to write this patch is that we are working on
> another client which uses RTRS. We could have kept this change
> out-of-tree, but frankly, it felt right to add this protection.
So once you will have this client upstream, we can discuss this change.
Thanks
next prev parent reply other threads:[~2024-08-12 12:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-09 13:15 [PATCH for-next 00/13] Misc patches for RTRS Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 01/13] RDMA/rtrs-srv: Make rtrs_srv_open fail if its a second call Md Haris Iqbal
2024-08-11 8:38 ` Leon Romanovsky
2024-08-12 10:16 ` Haris Iqbal
2024-08-12 10:34 ` Leon Romanovsky
2024-08-12 10:39 ` Haris Iqbal
2024-08-12 10:59 ` Leon Romanovsky
2024-08-12 11:17 ` Haris Iqbal
2024-08-12 12:15 ` Leon Romanovsky [this message]
2024-08-13 9:42 ` Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 02/13] RDMA/rtrs-srv: Fix use-after-free during session establishment Md Haris Iqbal
2024-08-11 8:41 ` Leon Romanovsky
2024-08-12 10:52 ` Jinpu Wang
2024-08-12 11:00 ` Leon Romanovsky
2024-08-13 10:54 ` Jinpu Wang
2024-08-09 13:15 ` [PATCH for-next 03/13] RDMA/rtrs: For HB error add additional clt/srv specific logging Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 04/13] RDMA/rtrs-clt: Fix need_inv setting in error case Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 05/13] RDMA/rtrs-clt: Rate limit errors in IO path Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 06/13] RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 07/13] RDMA/rtrs-clt: Reuse need_inval from mr Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 08/13] RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 09/13] RDMA/rtrs-clt: Print request type for errors Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 10/13] RDMA/rtrs-srv: Avoid null pointer deref during path establishment Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 11/13] RDMA/rtrs: register ib event handler Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 12/13] RDMA/rtrs-clt: Do local invalidate after write io completion Md Haris Iqbal
2024-08-09 13:15 ` [PATCH for-next 13/13] RDMA/rtrs-clt: Remove an extra space Md Haris Iqbal
2024-08-11 8:43 ` Leon Romanovsky
2024-08-12 4:10 ` Jinpu Wang
2024-08-12 9:48 ` Zhu Yanjun
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=20240812121520.GF12060@unreal \
--to=leon@kernel.org \
--cc=bvanassche@acm.org \
--cc=grzegorz.prajsner@ionos.com \
--cc=haris.iqbal@ionos.com \
--cc=jgg@ziepe.ca \
--cc=jinpu.wang@ionos.com \
--cc=linux-rdma@vger.kernel.org \
/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.