On Fri, 2018-01-05 at 10:34 -0700, Jason Gunthorpe wrote:
> On Fri, Jan 05, 2018 at 12:21:10PM -0500, Doug Ledford wrote:
>
> > > +static int srp_parse_in(struct sockaddr_storage *sa, const char *addr_port_str)
> > > +{
> > > + char *addr = kstrdup(addr_port_str, GFP_KERNEL);
> > > + char *port_str = addr;
> > > + int ret;
> > > +
> > > + if (!addr)
> > > + return -ENOMEM;
> > > + strsep(&port_str, ":");
> > > + ret = inet_pton_with_scope(&init_net, AF_UNSPEC, addr, port_str, sa);
> > > + kfree(addr);
> > > + return ret;
> > > +}
> > > +
> >
> > This particular function is problematic in that it adds new namespace
> > unaware code. The namespace code in the RDMA stack is in a limbo state
> > of partially implemented, partially not. I'm loathe to add any more
> > code that is not fully namespace aware as that just worsens the
> > hysteresis in the stack. So we need to figure out how to do this in a
> > namespace aware manner. I haven't previously been thinking about this
> > specific namespace issue, so I'm not prepared to even make suggestions
> > for a fix for this yet...
>
> Do the userspace daemon's still manage the connection to SRP?
srp_daemon uses management datagrams to discover SRP targets and these MADs
discover the GID of the target port instead of the IP address. So I have not
even tried to add RDMA/CM support to srp_daemon. If automatic login would be
implemented for SRP and RDMA/CM I think we should define a new discovery
mechanism based on the Internet Protocol.
> If yes, then the networking information should be relative to the
> namespace of the thing that wrote to the sysfs file..
Login occurs by writing into a sysfs file created by the SRP initiator. How
about using the networking namespace of the process that writes into that
sysfs file?
> Also, are there srp_daemon patches for this too? I've been asking to
> see the userspace side for new uAPI features before accepting the
> kernel part so that everything can be well understood. If yes, please
> send, even if it is RFCish..
As explained above there are no corresponding srp_daemon patches. But it may
be interesting to have a look at the srp-test source code since I used that
software to test RDMA/CM support. See also https://github.com/bvanassche/srp-test.
Bart.��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
