Re: Kernel build system broken in 5.8?

[Masahiro Yamada]

Hi.


On Wed, Aug 19, 2020 at 5:50 AM Martin Burnicki
<martin.burnicki@xxxxxxxxxxx> wrote:
>
> Hello Masahiro,
>
> Masahiro Yamada wrote:
> > On Wed, Aug 19, 2020 at 1:14 AM Martin Burnicki
> > <martin.burnicki@xxxxxxxxxxx> wrote:
> [...]
> >> I usually build the kernel module as standard user, and only install the
> >> new module as root, e.g.:
> >>
> >>   git checkout devel   # The 'devel' branch is appropriate for testing
> >>   cd mbgclock          # the subdirectory of the kernel module
> >>   git clean -fd; make  # or make V=1 for verbose output
> >>   sudo make install
> >
> >
> > This is a bad way for reporting a bug
> > because your project is too big.
>
> Sorry for this. I wasn't sure which was the best way to get a contact to
> folks who are more familiar with details of the kernel build system, and
> what may have been changed.

Sorry, if my response was too harsh.

> A possibility could have
>
> > mbgclock/Makefile include the top Makefile,
> > which is more than 1000 lines.
>
> If you run 'make' in the mbgclock subdirectory then the kernel build
> system is just called as usual, i.e.
>
>   make -C <path-to-the-kernel-build-system> M=$PWD <some EXTRA_CFLAGS>


I know.

I tried this, and then
"sudo make modules_install -C <path-to-the-kernel-build-system> M=$PWD"
but I did not see the issue.

So, I have no idea what the root-cause is
at this point.


> This has been working without problems for many years, for many popular
> distros, and all kernels from 2.6 up to 5.7 (except that for older
> kernels SUBDIRS=$PWD was used instead of M=$PWD).
>
> > Please provide steps to reproduce it
> > with a tiny test module.
>
> I was just hoping that someone had an idea like "Oh, this is because xyz
> has changed in kernel 5.18" when he read what I've observed.
>
> In the past I've seen cases where folks e.g. from RedHat or SuSE had
> backported patches from newer kernels to older ones, causing build
> errors in my driver code, and I was able to apply workarounds to my
> source code.
>
> However, this case is different because obviously the kernel source tree
> is modified under certain circumstances. Is my assumption correct that
> this should not happen if I install Linux header packages for a distro,
> that have been pre-configured according to the running kernel?

Right.
External modules should never ever attempt
to modify the kernel tree since it is often read-only.

I did not change that behavior
(unless I was doing a horrible mistake)



>
> Anyway, I'm going to try to set up an example which makes it easier to
> duplicate the problem.
>
> > You state 5.7.15 was fine.
>
> Yes.
>
> > So, could you also run git-bisect, please?
>
> Sorry, I've just recently started using git, and yet I'm not too
> familiar with some of the commands. How could git-bisect help in this case?



"git bisect" is really useful to find the first bad commit.
If you have not tried it yet,
it is worth learning the usage.



Can you reproduce the issue in the linux-stable source tree
instead of the ubuntu kernel?


You can get the stable kernel repository, like follows:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
$ cd linux-stable
$ git checkout v5.8.1


Once you find how to reproduce the bug
in the git repository,
it is pretty easy to start bisecting
with "git bisect start <bad> <good>"

For example,

git bisect start v5.8.1  v5.7.15

Then, repeat "git bisect good" or "git bisect bad",
depending on whether the bug happens.






> >> Also, I was under the impression that the kernel source tree should be
> >> read-only, and kept clean, but this doesn't seem to be the case anymore.
> >>
> >>
> >> For example:
> >>
> >> On Ubuntu 19.10 with kernel 5.8.1-050801-generic from
> >> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8.1/
> >
> >
> > I cannot try it since that is not what
> > I install on my machine, sorry.
>
> What distro are you using? Or do you only run kernels you have compiled
> yourself? ;-)


I also use Ubuntu, but my one is 5.4.0-42-generic.


I am not sure if 5.8.1-050801-generic
is exactly the same as v5.8.1, though.




>
> > Please provide steps to reproduce it
> > for a person using a different environment.
>
> I'm going to try to do this. Do you have any hints what this should look
> like?


I'd like to know the steps to reproduce the bug
in the kernel source tree instead of the distro's one.
(See above to get the stable kernel tree)



We could use your project to debug this, but
if this is purely a problem of the kernel build system,
it is easier and faster to use a small hello-world module.


For example, the minimal Makefile
of an external module will look like follows:



------------------------>8---------------------------
KERNEL=$(HOME)/workspace/linux-stable

.PHONY: __default
__default:
        $(MAKE) -C $(KERNEL) M=$(CURDIR)

.PHONY: $(MAKECMDGOALS)
$(MAKECMDGOALS):
        $(MAKE) -C $(KERNEL) M=$(CURDIR) $@

obj-m := helloworld.o
------------------------>8---------------------------






>
> Should this topic be continued on linux-kernel@, or better on
> linux-kbuild@, or elsewhere?


Please include both lists in To or Cc.

linux-kernel@ is a large amount.

I often miss mails if they are only
sent to linux-kernel@.




Thanks.




>
>
> Thanks,
>
> Martin
> --
> Martin Burnicki
>
> Senior Software Engineer
>
> MEINBERG Funkuhren GmbH & Co. KG
> Email: martin.burnicki@xxxxxxxxxxx
> Phone: +49 5281 9309-414
> Linkedin: https://www.linkedin.com/in/martinburnicki/
>
> Lange Wand 9, 31812 Bad Pyrmont, Germany
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
> Andre Hartmann, Heiko Gerstung
> Websites: https://www.meinberg.de  https://www.meinbergglobal.com
> Training: https://www.meinberg.academy
>


-- 
Best Regards
Masahiro Yamada