netdev - Re: [RFC 04/20] RDMA/irdma: Add driver framework definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 5 Oct 2019 09:08:27 +0200
From:   "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Jason Gunthorpe <jgg@...lanox.com>,
        "dledford@...hat.com" <dledford@...hat.com>,
        Mustafa Ismail <mustafa.ismail@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        Shiraz Saleem <shiraz.saleem@...el.com>
Subject: Re: [RFC 04/20] RDMA/irdma: Add driver framework definitions

On Sat, Oct 05, 2019 at 09:28:05AM +0300, Leon Romanovsky wrote:
> On Fri, Oct 04, 2019 at 05:46:15PM -0700, Jeff Kirsher wrote:
> > On Fri, 2019-10-04 at 23:45 +0000, Jason Gunthorpe wrote:
> > > On Fri, Oct 04, 2019 at 01:12:22PM -0700, Jeff Kirsher wrote:
> > >
> > > > > > +	if (ldev->version.major != I40E_CLIENT_VERSION_MAJOR ||
> > > > > > +	    ldev->version.minor != I40E_CLIENT_VERSION_MINOR) {
> > > > > > +		pr_err("version mismatch:\n");
> > > > > > +		pr_err("expected major ver %d, caller specified
> > > > > > major
> > > > > > ver %d\n",
> > > > > > +		       I40E_CLIENT_VERSION_MAJOR, ldev-
> > > > > > >version.major);
> > > > > > +		pr_err("expected minor ver %d, caller specified
> > > > > > minor
> > > > > > ver %d\n",
> > > > > > +		       I40E_CLIENT_VERSION_MINOR, ldev-
> > > > > > >version.minor);
> > > > > > +		return -EINVAL;
> > > > > > +	}
> > > > >
> > > > > This is can't be in upstream code, we don't support out-of-tree
> > > > > modules,
> > > > > everything else will have proper versions.
> > > >
> > > > Who is the "we" in this context?
> > >
> > > Upstream sensibility - if we start doing stuff like this then we will
> > > end up doing it everwhere.
> >
> > I see you cut out the part of my response about Linux distributions
> > disagreeing with this stance.
> >
> > >
> > > > you support out-of-tree drivers, they do exist and this code would
> > > > ensure that if a "out-of-tree" driver is loaded, the driver will do a
> > > > sanity check to ensure the RDMA driver will work.
> > >
> > > I don't see how this is any different from any of the other myriad of
> > > problems out of tree modules face.
> > >
> > > Someone providing out of tree modules has to provide enough parts of
> > > their driver so that it only consumes the stable ABI from the distro
> > > kernel.
> > >
> > > Pretty normal stuff really.
> >
> > Your right, if the dependency was reversed and the out-of-tree (OOT) driver
> > was dependent upon the RDMA driver, but in this case it is not.  The LAN
> > driver does not "need" the RDMA driver to work.  So the RDMA driver should
> > at least check that the LAN driver loaded has the required version to work.
> 
> Not in upstream code, there is an expectation that kernel and modules are aligned.

s/expectation/requirement/

If you do not do that, all bets are off.

Distros can decide to do whatever they want with their kernels, but
that's not what we require upstream.

thanks,

greg k-h