On Wed, 2019-02-20 at 13:05 -0700, Jason Gunthorpe wrote:
> On Wed, Feb 20, 2019 at 02:57:59PM -0500, Doug Ledford wrote:
> > On Wed, 2019-02-20 at 12:49 -0700, Jason Gunthorpe wrote:
> > > On Wed, Feb 20, 2019 at 02:37:21PM -0500, Doug Ledford wrote:
> > > > gap. I say this because I don't know of any real world use involving
> > > > RDMA, containers, non-init_net namespaces, and RDMA access. Do you?
> > >
> > > Yes, sites are mixing RDMA and net namespace'd containers. They need
> > > things to not change while they review their orchestration/etc.
> >
> > Ok, if the sites exist, then we need to accommodate them.
> >
> > > This is the whole philosophy for Linux, don't break the
> > > userspace. Parav's solution is really ugly, but does get the job done.
> >
> > Ok, then back to the question of the netlink control. I say we drop it
> > entirely and only support the kernel module. That is no more work for
> > the admin than running a new iproute2 command to change the mode, so
> > there's no argument for "but we can't require them to make any changes",
> > they would have to make a change either way, and then we don't have to
> > worry about leakage on change.
>
> This makes a bug chunk of these patches pointless as we can just
> create the sysfs class properly depending on module option.
>
> But we've been very against module options for a long time now, I'm
> not sure.
>
> Would distros accept this kind of breaking change?
Distros require proper security. And to be fair, *upstream* is on the
anti-module option kick. Distros put means in place to control module
options easily long ago, so for those things that are appropriate
(settings you don't ever want to change at runtime, things needed for
init, etc.), distros don't have the module option hangup that upstream
does.
The module option enforces security right out the gate. The netlink
control does not. We could say that changing things post-boot is not
guaranteed to stop existing connections (which is what the current code
does), but it was exactly my distro-hat security consciousness that made
me balk at that left the way it is. We can fix it by doing as I
suggested and making there be a second option to the netlink command to
force tear down connections outside of the security scope on change. Or
we can punt and just do the kernel module option exclusively.
Obviously, fixing the netlink would be the more robust solution.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
