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/7/20 8:28 PM, Jason Gunthorpe wrote:
On Wed, Oct 07, 2020 at 04:38:45PM +0800, Ka-Cheong Poon wrote:
On 10/6/20 8:46 PM, Jason Gunthorpe wrote:
On Tue, Oct 06, 2020 at 05:36:32PM +0800, Ka-Cheong Poon wrote:

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

A user starts a namespace.  The module is loaded for servicing
requests.  The module starts a listener.  The user deletes
the namespace.  This scenario will have everything cleaned up
properly if the listener is a kernel socket.  This is not the
case with RDMA.

Please point to reputable code in upstream doing this


It is not clear what "reputable" here really means.  If it just
means something in kernel, then nearly all, if not all, Internet
protocols code in kernel create a control kernel socket for every
network namespaces.  That socket is deleted in the per namespace
exit function.  If it explicitly means listening socket, AFS and
TIPC in kernel do that for every namespaces.  That socket is
deleted in the per namespace exit function.

AFS and TIPC are not exactly well reviewed mainstream areas.


How about all the other Internet protocol code?  They all
create a kernel socket without user interaction.  If it is
using rdma_create_id(), it will prevent a namespace from
being deleted.


It is very common for a network protocol to have something like
this for protocol processing.  It is not clear why RDMA subsystem
behaves differently and forbids this common practice.  Could you
please elaborate the issues this practice has such that the RDMA
subsystem cannot support it?

The kernel should not have rouge listening sockets just because a
model is loaded. Creation if listening kernel side sockets should be
triggered by userspace.


It is unclear why the socket is "rogue".  A sys admin loads a
kernel module for a reason.  It cannot be randomly loaded by
itself.  In this respect, it is not different from a user space
daemon.  No one will describe a listening socket started by a daemon
when it starts as "rogue".  Why is a listening socket started by a
kernel module "rogue"?  If a user is remote, without the listening
socket, how can anything work in the first place?



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