public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	syzbot+8fcbb77276d43cc8b693@syzkaller.appspotmail.com
Subject: Re: [PATCH rdma-rc] RDMA/cma: Clear all multicast request fields
Date: Mon, 17 Jan 2022 20:20:40 +0200	[thread overview]
Message-ID: <YeWzeA/8TgXalrD8@unreal> (raw)
In-Reply-To: <20220117161621.GC84788@nvidia.com>

On Mon, Jan 17, 2022 at 12:16:21PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 10, 2022 at 08:05:40PM +0200, Leon Romanovsky wrote:
> 
> > > We should probably check the PS even earlier to prevent the IB side
> > > from having the same issue.
> > 
> > What do you think about this?
> 
> IB is a bit different, it has a bunch of PS's that are UD compatible..
> 
> Probably what we really want here is to check/restrict the CM ID to
> SIDR mode, which does have the qkey and is the only mode that makes
> sense to be mixed with multicast, and then forget about port space
> entirely.
> 
> It may be that port space indirectly restricts the CM ID to SIDR mode,
> but the language here should be 'is in sidr mode', not some confusing
> open coded port space check.
> 
> I'm also not sure of the lifecycle of the qkey, qkeys only exist in
> SIDR mode so obviously anything that sets/gets a qkey should be
> restriced to SIDR CM IDs..
> 
> > diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
> > index 835ac54d4a24..0a1f008ca929 100644
> > +++ b/drivers/infiniband/core/cma.c
> > @@ -4669,12 +4669,8 @@ static int cma_join_ib_multicast(struct rdma_id_private *id_priv,
> >         if (ret)
> >                 return ret;
> > 
> > -       ret = cma_set_qkey(id_priv, 0);
> > -       if (ret)
> > -               return ret;
> > -
> >         cma_set_mgid(id_priv, (struct sockaddr *) &mc->addr, &rec.mgid);
> > -       rec.qkey = cpu_to_be32(id_priv->qkey);
> > +       rec.qkey = cpu_to_be32(RDMA_UDP_QKEY);
> 
> And I'm not sure this makes sense? The UD qkey should still be
> negotiated right?

Yes, I think so, it will be changed in SIDR phase.

The original code has "cma_set_qkey(id_priv, 0)" call, that in IB case will
execute this switch anyway:
   515         switch (id_priv->id.ps) {
   516         case RDMA_PS_UDP:
   517         case RDMA_PS_IB:
   518                 id_priv->qkey = RDMA_UDP_QKEY;

The difference is that we won't store RDMA_UDP_QKEY in id_priv->qkey,
but I'm unsure that this is right.

Thanks

> 
> Jason

  reply	other threads:[~2022-01-17 18:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-06 13:15 [PATCH rdma-rc] RDMA/cma: Clear all multicast request fields Leon Romanovsky
2022-01-06 17:39 ` Jason Gunthorpe
2022-01-06 18:24   ` Leon Romanovsky
2022-01-09 12:22   ` Leon Romanovsky
2022-01-10 15:36     ` Jason Gunthorpe
2022-01-10 18:05       ` Leon Romanovsky
2022-01-17 16:16         ` Jason Gunthorpe
2022-01-17 18:20           ` Leon Romanovsky [this message]
2022-01-17 18:38             ` Jason Gunthorpe
2022-01-17 19:06               ` Leon Romanovsky

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=YeWzeA/8TgXalrD8@unreal \
    --to=leon@kernel.org \
    --cc=jgg@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=syzbot+8fcbb77276d43cc8b693@syzkaller.appspotmail.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