All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: RDMA subsystem namespace related questions (was Re: Finding the namespace of a struct ib_device)
Date: Mon, 5 Oct 2020 12:45:48 -0300	[thread overview]
Message-ID: <20201005154548.GT9916@ziepe.ca> (raw)
In-Reply-To: <3e9497cb-1ccd-2bc0-bbca-41232ebd6167@oracle.com>

On Mon, Oct 05, 2020 at 11:02:18PM +0800, Ka-Cheong Poon wrote:
> On 10/5/20 10:25 PM, Jason Gunthorpe wrote:
> > On Mon, Oct 05, 2020 at 09:57:47PM +0800, Ka-Cheong Poon wrote:
> > > > > It is a kernel module.  Which FD are you referring to?  It is
> > > > > unclear why a kernel module must associate itself with a user
> > > > > space FD.  Is there a particular reason that rdma_create_id()
> > > > > needs to behave differently than sock_create_kern() in this
> > > > > regard?
> > > > 
> > > > Somehow the kernel module has to be commanded to use this namespace,
> > > > and generally I expect that command to be connected to FD.
> > > 
> > > 
> > > It is an unnecessary restriction on what a kernel module
> > > can do.  Is it a problem if a kernel module initiates its
> > > own RDMA connection for doing various stuff in a namespace?
> > 
> > Yes, someone has to apply policy to authorize this. Kernel modules
> > randomly running around using security objects is not OK.
> 
> The policy is to allow this.  It is not random stuff.
> Can the RDMA subsystem support it?

allow everything is not a policy
 
> > Kernel modules should not be doing networking unless commanded to by
> > userspace.
> 
> It is still not clear why this is an issue with RDMA
> connection, but not with general kernel socket.  It is
> not random networking.  There is a purpose.

It is a problem with sockets too, how do the socket users trigger
their socket usages? AFAIK all cases originate with userspace

> So if the reason of the current rdma_create_id() behavior
> is that there is no such user, I am adding one.  It should
> be clear that this difference between kernel socket and
> rdma_create_id() causes a problem in namespace handling.

It would be helpful to understand how that works, as I've said I don't
think a kernel module should open listening sockets/cm_ids on every
namespace without being told to do this.

> If the cma_wq is re-designed, number of namespaces should be one
> input parameter on creating how many threads and other resources
> allocation/scheduling.  One cma_wq per namespace is the simplest
> allocation.

no, it will just run all CM_IDs concurrently on all processors.

Namespaces are not cgroups, we don't guarentee anything about resource
consumption for namespaces.

Jason

  reply	other threads:[~2020-10-05 15:45 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-03 14:02 Finding the namespace of a struct ib_device Ka-Cheong Poon
2020-09-03 17:39 ` Jason Gunthorpe
2020-09-04  4:01   ` Ka-Cheong Poon
2020-09-04 11:32     ` Jason Gunthorpe
2020-09-04 14:02       ` Ka-Cheong Poon
2020-09-06  7:44         ` Leon Romanovsky
2020-09-07  3:33           ` Ka-Cheong Poon
2020-09-07  7:18             ` Leon Romanovsky
2020-09-07  8:24               ` Ka-Cheong Poon
2020-09-07  9:04                 ` Leon Romanovsky
2020-09-07  9:28                   ` Ka-Cheong Poon
2020-09-07 10:22                     ` Leon Romanovsky
2020-09-07 13:48                       ` Ka-Cheong Poon
2020-09-29 16:57                         ` RDMA subsystem namespace related questions (was Re: Finding the namespace of a struct ib_device) Ka-Cheong Poon
2020-09-29 17:40                           ` Jason Gunthorpe
2020-09-30 10:32                             ` Ka-Cheong Poon
2020-10-02 14:04                               ` Jason Gunthorpe
2020-10-05 10:27                                 ` Ka-Cheong Poon
2020-10-05 13:16                                   ` Jason Gunthorpe
2020-10-05 13:57                                     ` Ka-Cheong Poon
2020-10-05 14:25                                       ` Jason Gunthorpe
2020-10-05 15:02                                         ` Ka-Cheong Poon
2020-10-05 15:45                                           ` Jason Gunthorpe [this message]
2020-10-06  9:36                                             ` Ka-Cheong Poon
2020-10-06 12:46                                               ` Jason Gunthorpe
2020-10-07  8:38                                                 ` Ka-Cheong Poon
2020-10-07 11:16                                                   ` Leon Romanovsky
2020-10-08 10:22                                                     ` Ka-Cheong Poon
2020-10-08 10:36                                                       ` Leon Romanovsky
2020-10-08 11:08                                                         ` Ka-Cheong Poon
2020-10-08 16:08                                                           ` Jason Gunthorpe
2020-10-08 16:21                                                             ` Chuck Lever
2020-10-08 16:46                                                               ` Jason Gunthorpe
2020-10-09  4:49                                                             ` Ka-Cheong Poon
2020-10-09 14:39                                                               ` Jason Gunthorpe
2020-10-09 14:48                                                                 ` Chuck Lever
2020-10-09 14:57                                                                   ` Jason Gunthorpe
2020-10-09 15:00                                                                     ` Chuck Lever
2020-10-09 15:07                                                                       ` Jason Gunthorpe
2020-10-09 15:27                                                                         ` Chuck Lever
2020-10-09 15:34                                                                           ` Jason Gunthorpe
2020-10-09 15:52                                                                             ` Chuck Lever
2020-10-12  8:20                                                                             ` Ka-Cheong Poon
2020-10-16 18:54                                                                               ` Jason Gunthorpe
2020-10-16 20:49                                                                                 ` Chuck Lever
2020-10-19 18:31                                                                                   ` Jason Gunthorpe
2020-10-07 12:28                                                   ` Jason Gunthorpe
2020-10-08 10:49                                                     ` Ka-Cheong Poon

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=20201005154548.GT9916@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=ka-cheong.poon@oracle.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.