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]
Message-Id: <838D0FCD-EA9C-46C8-BCA7-FECFD3DC04D8@linux.dev>
Date: Tue, 10 Dec 2024 12:06:32 +0100
From: Thorsten Blum <thorsten.blum@...ux.dev>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org,
 cocci@...ia.fr
Subject: Re: [PATCH v2 05/11] kbuild: change working directory to external
 module directory with M=

On 10. Dec 2024, at 11:47, Masahiro Yamada wrote:
> On Mon, Dec 9, 2024 at 10:56 PM Thorsten Blum wrote:
>> On 9. Dec 2024, at 14:46, Thorsten Blum wrote:
>>> On 10. Nov 2024, at 02:34, Masahiro Yamada wrote:
>>>> 
>>>> Currently, Kbuild always operates in the output directory of the kernel,
>>>> even when building external modules. This increases the risk of external
>>>> module Makefiles attempting to write to the kernel directory.
>>>> 
>>>> This commit switches the working directory to the external module
>>>> directory, allowing the removal of the $(KBUILD_EXTMOD)/ prefix from
>>>> some build artifacts.
>>>> 
>>>> The command for building external modules maintains backward
>>>> compatibility, but Makefiles that rely on working in the kernel
>>>> directory may break. In such cases, $(objtree) and $(srctree) should
>>>> be used to refer to the output and source directories of the kernel.
>>>> 
>>>> The appearance of the build log will change as follows:
>>>> 
>>>> [Before]
>>>> 
>>>> $ make -C /path/to/my/linux M=/path/to/my/externel/module
>>>> make: Entering directory '/path/to/my/linux'
>>>> CC [M]  /path/to/my/externel/module/helloworld.o
>>>> MODPOST /path/to/my/externel/module/Module.symvers
>>>> CC [M]  /path/to/my/externel/module/helloworld.mod.o
>>>> CC [M]  /path/to/my/externel/module/.module-common.o
>>>> LD [M]  /path/to/my/externel/module/helloworld.ko
>>>> make: Leaving directory '/path/to/my/linux'
>>>> 
>>>> [After]
>>>> 
>>>> $ make -C /path/to/my/linux M=/path/to/my/externel/module
>>>> make: Entering directory '/path/to/my/linux'
>>>> make[1]: Entering directory '/path/to/my/externel/module'
>>>> CC [M]  helloworld.o
>>>> MODPOST Module.symvers
>>>> CC [M]  helloworld.mod.o
>>>> CC [M]  .module-common.o
>>>> LD [M]  helloworld.ko
>>>> make[1]: Leaving directory '/path/to/my/externel/module'
>>>> make: Leaving directory '/path/to/my/linux'
>>>> 
>>>> Printing "Entering directory" twice is cumbersome. This will be
>>>> addressed later.
>>>> 
>>>> Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
>>>> ---
>>> 
>>> Hi Masahiro,
>>> 
>>> I get the following error since this patch is in master, but only when
>>> using COCCI= in combination with M=<relative or absolute path>.
>>> 
>>> It works when I either use COCCI= or M=, but not with both.
>> 
>> Using the absolute path of the cocci script fixes my problem, but this
>> used to work with relative paths too.
>> 
>> $ make coccicheck COCCI=$(pwd)/scripts/coccinelle/misc/flexible_array.cocci M=arch/
> 
> M= looks a bit weird for the upstream code, but
> I think using the absolute path is the right thing to do.

The documentation[1] uses M= and also COCCI= with relative paths and
some of the examples don't work anymore.

Could you try this one?

```
export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd
```

I get this:

$ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
$ make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd
make[1]: Entering directory '/home/fedora/linux/drivers/mfd'

Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

grep: scripts/coccinelle/misc/irqf_oneshot.cocci: No such file or directory
grep: scripts/coccinelle/misc/irqf_oneshot.cocci: No such file or directory
coccicheck failed
make[2]: *** [/home/fedora/linux/Makefile:2089: coccicheck] Error 2
make[1]: *** [/home/fedora/linux/Makefile:251: __sub-make] Error 2
make[1]: Leaving directory '/home/fedora/linux/drivers/mfd'
make: *** [Makefile:251: __sub-make] Error 2

Thanks,
Thorsten

[1] https://www.kernel.org/doc/html/latest/dev-tools/coccinelle.html


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ