Re: RDMA subsystem namespace related questions (was Re: Finding the namespace of a struct ib_device)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/9/20 12:08 AM, Jason Gunthorpe wrote:
On Thu, Oct 08, 2020 at 07:08:42PM +0800, Ka-Cheong Poon wrote:
Note that namespace does not really play a role in this "rogue" reasoning.
The init_net is also a namespace.  The "rogue" reasoning means that no
kernel module should start a listening RDMA endpoint by itself with or
without any extra namespaces.  In fact, to conform to this reasoning, the
"right" thing to do would be to change the code already in upstream to get
rid of the listening RDMA endpoint in init_net!

Actually I think they all already need user co-ordination?
- NFS, user has to setup and load exports
- Storage Targets, user has to setup the target
- IPoIB, user has to set the link up

etc.

Each of those could provide the anchor to learn the namespace.


It is unclear how this is related to the question at hand.  It
is not about learning the namespace.  A kernel module knows
when a namespace is created.  There is no need to learn it.  The
question is creating a kernel RDMA endpoint in a namespace without
adding a reference to that namespace.  The analogy to the daemon
scenario is that a daemon starts a socket endpoint at start up.
No one calls that endpoint "rogue".  Why is that a kernel module
should not start a socket endpoint at start up?  Why is that socket
endpoint "rogue"?  The reason is still not being given.

As I mentioned before, this is a very serious restriction on how
the RDMA subsystem can be used in a namespace environment by kernel
module.  The reason given for this restriction is that any kernel
socket without a corresponding user space file descriptor is "rogue".
All Internet protocol code create a kernel socket without user
interaction.  Are they all "rogue"?



--
K. Poon
ka-cheong.poon@xxxxxxxxxx





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux