Bug 1321628 - out-of-tree kernel module building broken with CONFIG_STACK_VALIDATION=, loss of automatic kbuild dependencies
Summary: out-of-tree kernel module building broken with CONFIG_STACK_VALIDATION=, loss...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-28 17:00 UTC by Frank Ch. Eigler
Modified: 2016-03-31 12:18 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-03-31 12:18:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Frank Ch. Eigler 2016-03-28 17:00:36 UTC
Description of problem:

Between
      kernel-4.6.0-0.rc0.git5.1.fc25.x86_64
and   kernel-4.6.0-0.rc0.git20.1.fc25.x86_64
basic out-of-tree kernel module building has broken, when the module uses a standard Makefile like:

   obj-m := the_module.o
   the_module-y :=  part1.o part2.o

with nearby (even empty) part1.c and part2.c source files.  It appears that the new objtool machinery interferes with the dependency searching, and 

 make -C /lib/modules/4.6.0-0.rc0.git20.1.fc25.x86_64/build/ M=`pwd` modules                           
make: Entering directory '/usr/src/kernels/4.6.0-0.rc0.git20.1.fc25.x86_64'
make[1]: *** No rule to make target '/tmp/foo/part1.o', needed by '/tmp/foo/the_module.o'.  Stop.
Makefile:1419: recipe for target '_module_/tmp/foo' failed
make: *** [_module_/tmp/foo] Error 2
make: Leaving directory '/usr/src/kernels/4.6.0-0.rc0.git20.1.fc25.x86_64'

This breaks systemtap.  Older kernels work.  Running with make CONFIG_STACK_VALIDATION=  with the new kernel also works.

Comment 1 Josh Boyer 2016-03-28 17:22:33 UTC
Josh, has this been reported upstream?  I would think we'd want to leave stack validation enabled given it's benefits.

Comment 2 Josh Poimboeuf 2016-03-30 13:07:55 UTC
No, this hasn't been reported upstream.  I'm on PTO this week but I'll be sure and look at it next week.

Comment 3 Josh Boyer 2016-03-30 17:33:04 UTC
(In reply to Josh Poimboeuf from comment #2)
> No, this hasn't been reported upstream.  I'm on PTO this week but I'll be
> sure and look at it next week.

I don't think this is an upstream issue after poking at it some.

I noticed that for some of the other tool related things (like recordmcount), we're installing the tools themselves in /lib/modules/`uname -r`/build/scripts/ so that when the make targets get invoked that require them, the tools are there.  However, for CONFIG_STACK_VALIDATION, we are not currently installing the objtool binary itself.  When I copy a locally built objtool to the location, the sample module make invocation works fine.  This isn't a problem when building from a local kernel tree, as the binary will exist in the expected location.

So I think this is simply a packaging bug.  I'll see if I can fix it today.

Comment 4 Josh Boyer 2016-03-30 19:55:46 UTC
I've fixed this in Fedora git.  It will be included in the next build.

Comment 5 poma 2016-03-31 08:52:19 UTC
$ find linux-4.6-rc1 -name Documentation
linux-4.6-rc1/Documentation
linux-4.6-rc1/drivers/staging/iio/Documentation
linux-4.6-rc1/drivers/staging/unisys/Documentation
linux-4.6-rc1/drivers/staging/i4l/Documentation
linux-4.6-rc1/drivers/staging/most/Documentation
linux-4.6-rc1/tools/objtool/Documentation
linux-4.6-rc1/tools/build/Documentation
linux-4.6-rc1/tools/perf/Documentation


Mister Poimboeuf,

is there a reason why documentation is not in one place,
e.g.
$ find linux-4.6-rc1 -name stack-validation.txt
linux-4.6-rc1/tools/objtool/Documentation/stack-validation.txt
rather than here:
linux-4.6-rc1/Documentation/stack-validation.txt

so these fine papers can be read on
https://www.kernel.org/doc/Documentation/

Comment 6 Josh Boyer 2016-03-31 12:18:45 UTC
Fixed in 4.6.0-0.rc1.git0.3.fc25.  Will be in tomorrow's compose.


Note You need to log in before you can comment on or make changes to this bug.