linux-kernel - Re: [PATCH v3] Add MO(mod objs) variable to process ext modules with subdirs

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] [day] [month] [year] [list]

Message-ID: <ZhlMwQhlxm7QVlPx@goliath>
Date: Fri, 12 Apr 2024 15:01:25 +0000
From: "Daniel Walker (danielwa)" <danielwa@...co.com>
To: Nicolas Schier <nicolas@...sle.eu>
CC: "Valerii Chernous -X (vchernou - GLOBALLOGIC INC at Cisco)"
	<vchernou@...co.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nathan
 Chancellor <nathan@...nel.org>,
        "xe-linux-external(mailer list)"
	<xe-linux-external@...co.com>,
        Jonathan Corbet <corbet@....net>,
        "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] Add MO(mod objs) variable to process ext modules with
 subdirs

On Fri, Apr 12, 2024 at 08:34:31AM +0200, Nicolas Schier wrote:
> On Thu, Apr 11, 2024 at 08:50:10PM +0000, Daniel Walker (danielwa) wrote:
> > On Thu, Apr 11, 2024 at 09:25:35PM +0200, Nicolas Schier wrote:
> > > On Thu, Apr 11, 2024 at 05:27:42PM +0000 Daniel Walker (danielwa) wrote:
> [...]
> > > > If that were true we would not have driver/uio/ for example. It seems like
> > > > Cisco and NVM should work together produce a solution.
> > > > 
> > > > You could run into this issue even with entirely in tree modules. For example,
> > > > we may have a v6.6 kernel but we need some modules from v5.15 for some incompatibility
> > > > reason in v6.6. Then we may build the v5.15 modules as out of tree modules
> > > > against the v6.6 kernel.
> >  
> > All problems should be fixed or worked around. One bit of code maybe isn't
> > the best choice or maybe another is, but not fixing or working around the
> > problem is not really an option.
> 
> Let me sum up: It is possible to build out-of-tree kmods with subdirs
> in their source tree.
> The patch attempts to put support for _out-of-source builds_ of
> out-of-tree kmods with subdirs into kbuild itself.
> 
> If you really out-of-source builds for your complex out-of-tree kmods,
> than, as a "work-around", you can simply put those 'src' override lines
> into your oot-Kbuild files.  But you probably know that already, right?

I tried "make src=..." and Valerii also tried it.  I think that's what your referring
to. There must have been a defect added which prevents that from working. It
has some sort of recursion issue. It seems this method was not "official" and
only work by accident. 


> > > If your in-tree module in question does compile and run properly in v5.15 and
> > > in v6.6: why don't you just compile it in-tree in v6.6?  Which driver/module do
> > > you refer to?
> > 
> > I believe it was this driver drivers/crypto/marvell/octeontx2 . I don't recall
> > every aspect of the issues but it has to do with what Marvell supported in their
> > SDK and the exact hardware we were using and the bootloader we had on the
> > product.
> > 
> > > > You also have just normal developers making kernel modules which always start as
> > > > out of tree modules before they are upstreamed. Those modules could be any level
> > > > of complexity.
> > > 
> > > I do not agree, but there is no need to convince me as I am not in the position
> > > to decide between acceptance or denial.  I just thought it might be fair to
> > > warn that I do not expect acceptance.
> > 
> > I think it's incorrect, unhealthy even, to look at it that way. If your using
> > Linux to make a product and you have an issue, it should be consider as a real
> > issue. Not something maintainer can just discard. Unless the maintainer has
> > a suggestion to do what is needed or different code to do it.
> > 
> > Daniel
> 
> Daniel,
> 
> I am confused about the outcome from your argumentation that you might
> expect.  And I think, I as a spare-time reviewer (not maintainer), am
> not the one you want to argue with.

I don't care if your a maintainer or not.

> If you have a concrete technical issue or bug, please explain it
> concretely to linux-kbuild and we will probably find someone trying to
> help you.  If you want me to hide critical thoughts when reviewing
> patches under your pillow, then please tell me so.

I don't think it's critical thinking to effectively tell someone to stop
submitting code.

Daniel