Age | Commit message (Collapse) | Author | Files | Lines |
|
Kernel headers must be installed into $(objtree)/usr/include to avoid
the build failure of samples.
Commit ddea05fa148b ("kbuild: make samples depend on headers_install")
addressed this, but "samples/" is only used for the single target build.
"make samples/" properly installs kernel headers, but it does not work
for general building because a phony target "sample" (no trailing slash)
is used.
Reported-by: David Howells <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Tested-by: David Howells <[email protected]>
|
|
Now that '%asm-generic' is added to no-dot-config-targets,
'make asm-generic' does not include the kernel configuration.
You can simply do 'make asm-generic' in the recursed top Makefile
without bothering syncconfig.
Signed-off-by: Masahiro Yamada <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Acked-by: Richard Weinberger <[email protected]>
|
|
asm-generic and uapi-asm-generic do not depend on the kernel
configuration. In fact, uapi-asm-generic is the prerequisite of
headers_{install,check}, hence it should not require the .config file.
Signed-off-by: Masahiro Yamada <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Acked-by: Richard Weinberger <[email protected]>
|
|
Randy Dunlap reports UML occasionally fails to build with -j<N> and
O=<builddir> options.
make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64'
UPD include/generated/uapi/linux/version.h
WRAP arch/x86/include/generated/asm/dma-contiguous.h
WRAP arch/x86/include/generated/asm/export.h
WRAP arch/x86/include/generated/asm/early_ioremap.h
WRAP arch/x86/include/generated/asm/mcs_spinlock.h
WRAP arch/x86/include/generated/asm/mm-arch-hooks.h
WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/x86/include/generated/uapi/asm/poll.h
GEN ./Makefile
make[2]: *** No rule to make target 'archheaders'. Stop.
arch/um/Makefile:119: recipe for target 'archheaders' failed
make[1]: *** [archheaders] Error 2
make[1]: *** Waiting for unfinished jobs....
UPD include/config/kernel.release
make[1]: *** wait: No child processes. Stop.
Makefile:146: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
The cause of the problem is the use of '$(MAKE) KBUILD_SRC=',
which recurses to the top Makefile via the $(objtree)/Makefile
generated by scripts/mkmakefile.
When you run "make -j<N> O=<builddir> ARCH=um", Make can execute
'archheaders' and 'outputmakefile' targets simultaneously because
there is no dependency between them.
If it happens,
$(Q)$(MAKE) KBUILD_SRC= ARCH=$(HEADER_ARCH) archheaders
... tries to run $(objtree)/Makefile that is being updated.
The correct way for the recursion is
$(Q)$(MAKE) -f $(srctree)/Makefile ARCH=$(HEADER_ARCH) archheaders
..., which does not rely on the generated Makefile.
Reported-by: Randy Dunlap <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Acked-by: Richard Weinberger <[email protected]>
|
|
Use the print function. This maintains Python 2 support and should have
no functional change.
Signed-off-by: Jeremy Cline <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Different generations of the SH architecture are not very compatible,
so there are/were separate Debian ports for SH3 and SH4.
Move the fallback out of the "case" statement, so that it will also be
used in case we find some SH architecture version without a known
mapping.
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Debian currently only defines "riscv64", but it seems safe to assume
that any 32-bit port will now be called "riscv32", also matching
$UTS_MACHINE.
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
We currently label 64-bit kernel packages as sparc (32-bit), mostly
because it was officially supported while sparc64 was not. Now
neither is officially supported, so label these packages as sparc64.
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
MIPS R6 is not fully backward-compatible, so Debian has separate
architecture names for userland built for R6. Label kernel
packages accordingly.
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
We currently label 64-bit little-endian kernel packages as
mipsel (32-bit little-endian), mostly it was officially supported
while mips64el (64-bit little-endian) was not. Now both are
officially supported, so label these packages as mips64el.
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
We currently label 64-bit big-endian kernel packages as
powerpc (32-bit), mostly because it was officially supported while
ppc64 (64-bit big-endian) was not. Now neither is officially
supported, so label these packages as ppc64.
Debian also has a powerpcspe (32-bit with SPE) architecture.
Label packages with a suitable configuration as powerpcspe.
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
We now have many repetitive greps over the kernel config. Refactor
them into functions.
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
s390 now only supports 64-bit configurations.
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
We currently use dpkg --print-architecture, which reports the
architecture of the build machine. We can make a better guess
than this by asking dpkg-architecture what the host architecture,
i.e. the default architecture for building packages, is. This is
sensitive to environment variables such as CC and DEB_HOST_ARCH,
which should already be set in a cross-build environment.
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
If KBUILD_DEBARCH is set then we will not use the result of
architecture detection, and we may also warn unnecessarily.
Move the check for KBUILD_DEBARCH further up to avoid this.
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Currently, filechk unconditionally opens the first prerequisite and
redirects it as the stdin of a filechk_* rule. Hence, every target
using $(call filechk,...) must list something as the first prerequisite
even if it is unneeded.
'< $<' is actually unneeded in most cases. Each rule can explicitly
adds it if necessary.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
The filechk_offsets in arch/arm/mach-at91/Makefile is never
used because it is always overridden by the equivalent one in
scripts/Makefile.lib
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
|
|
Users of if_changed could easily feel invited to use it to divide a
recipe into parts like:
a: prereq FORCE
$(call if_changed,do_a)
$(call if_changed,do_b)
But this is problematic, because if_changed should not be used more
than once per target: in the above example, if_changed stores the
command-line of the given command in .a.cmd and when a is up-to-date
with respect to prereq, the file .a.cmd contains the command-line for
the last command executed, i.e. do_b.
When the recipe is then executed again, without any change of
prerequisites, the command-line check for do_a will fail, do_a will be
executed and stored in .a.cmd. The next check, however, will still see
the old content (the file isn't re-read) and if_changed will skip
do_b, because the command-line test will not recognize a change. On
the next execution of the recipe the roles will flip: do_a is OK but
do_b not and it will be executed. And so on...
Signed-off-by: Dirk Gouders <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Make 'make tar-pkg' work on arm64.
Cc: Will Deacon <[email protected]>
Cc: Catalin Marinas <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
ARCH=vax isn't in mainline; it can be added back if/when it shows up.
Signed-off-by: Olof Johansson <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Put $(LDFLAGS_$(@F)) into ld_flags so that $(LDFLAGS_pcap.o) and
$(LDFLAGS_vde.o) in arch/um/drivers/Makefile are absorbed.
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
|
|
$(LDFLAGS) $(ldflags-y) is equivalent to $(ld_flags).
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
|
|
Since commit ce99d0bf312d ("kbuild: clear LDFLAGS in the top Makefile"),
the top-level Makefile caters to this.
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
|
|
This is already exported by the top-level Makefile.
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
|
|
Now that we have the rename in place, reuse the HOST*FLAGS options as
something that can be set from the command line and included with the
rest of the flags.
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
In preparation for enabling command line LDLIBS, re-name HOST_LOADLIBES
to KBUILD_HOSTLDLIBS as the internal use only flags. Also rename
existing usage to HOSTLDLIBS for consistency. This should not have any
visible effects.
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
In preparation for enabling command line LDFLAGS, re-name HOSTLDFLAGS
to KBUILD_HOSTLDFLAGS as the internal use only flags. This should not
have any visible effects.
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
In preparation for enabling command line CXXFLAGS, re-name HOSTCXXFLAGS
to KBUILD_HOSTCXXFLAGS as the internal use only flags. This should not
have any visible effects.
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
In preparation for enabling command line CFLAGS, re-name HOSTCFLAGS to
KBUILD_HOSTCFLAGS as the internal use only flags. This should not have
any visible effects.
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Acked-by: Andy Lutomirski <[email protected]>
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
In Fedora, the debug information is packaged separately (foo-debuginfo) and
can be installed separately. There's been a long standing issue where only
one version of a debuginfo info package can be installed at a time. There's
been an effort for Fedora for parallel debuginfo to rectify this problem.
Part of the requirement to allow parallel debuginfo to work is that build ids
are unique between builds. The existing upstream rpm implementation ensures
this by re-calculating the build-id using the version and release as a
seed. This doesn't work 100% for the kernel because of the vDSO which is
its own binary and doesn't get updated when embedded.
Fix this by adding some data in an ELF note for both the kernel and modules.
The data is controlled via a Kconfig option so distributions can set it
to an appropriate value to ensure uniqueness between builds.
Suggested-by: Masahiro Yamada <[email protected]>
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Verify that 'depmod' ($DEPMOD) is installed.
This is a partial revert of commit 620c231c7a7f
("kbuild: do not check for ancient modutils tools").
Also update Documentation/process/changes.rst to refer to
kmod instead of module-init-tools.
Fixes kernel bugzilla #198965:
https://bugzilla.kernel.org/show_bug.cgi?id=198965
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Michal Marek <[email protected]>
Cc: Jessica Yu <[email protected]>
Cc: Chih-Wei Huang <[email protected]>
Cc: [email protected] # any kernel since 2012
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Commit 8370edea81e3 ("bin2c: move bin2c in scripts/basic") moved bin2c
to the scripts/basic/ directory, incorrectly stating "Kexec wants to
use bin2c and it wants to use it really early in the build process.
See arch/x86/purgatory/ code in later patches."
Commit bdab125c9301 ("Revert "kexec/purgatory: Add clean-up for
purgatory directory"") and commit d6605b6bbee8 ("x86/build: Remove
unnecessary preparation for purgatory") removed the redundant
purgatory build magic entirely.
That means that the move of bin2c was unnecessary in the first place.
fixdep is the only host program that deserves to sit in the
scripts/basic/ directory.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
atomic_as_refcounter.cocci script allows detecting
cases when refcount_t type and API should be used
instead of atomic_t.
Signed-off-by: Elena Reshetova <[email protected]>
Acked-by: Julia Lawall <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
- A fix for OMAP5 and DRA7 to make the branch predictor hardening
settings take proper effect on secondary cores
- Disable USB OTG on am3517 since current driver isn't working
- Fix thermal sensor register settings on Armada 38x
- Fix suspend/resume IRQs on pxa3xx
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: dts: am3517.dtsi: Disable reference to OMAP3 OTG controller
ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for secondary cores
ARM: pxa: irq: fix handling of ICMR registers in suspend/resume
ARM: dts: armada-38x: use the new thermal binding
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC fixes from Alexandre Belloni:
"Two fixes for 4.18:
- an important core fix for RTCs using the core offsetting only one
driver is affected
- a fix for the error path of mrst"
* tag 'rtc-4.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
rtc: fix alarm read and set offset
rtc: mrst: fix error code in probe()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Two omap fixes for v4.18-rc cycle
Turns out the recent patches for ARM branch predictor hardening are
not working on omap5 and dra7 as planned because the secondary CPU
is parked to the bootrom code. We can't configure it in the bootloader.
So we must enable invalidates of BTB for omap5 and dra7 secondary
core in the kernel.
And there's a fix for reserved register access for am3517. The
usb otg module on am3517 is not the same as for other omap3.
* tag 'omap-for-v4.18/fixes-rc4-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: am3517.dtsi: Disable reference to OMAP3 OTG controller
ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for secondary cores
Signed-off-by: Olof Johansson <[email protected]>
|
|
mvebu fixes for 4.18 (part 1)
Use the new thermal binding on Armada 38x allowing to use a driver fix
which is already part of the kernel.
* tag 'mvebu-fixes-4.18-1' of git://git.infradead.org/linux-mvebu:
ARM: dts: armada-38x: use the new thermal binding
Signed-off-by: Olof Johansson <[email protected]>
|
|
This is the fixes set for v4.18 cycle.
This is a fix for suspending all pxa3xx platforms, where high
number interrupts are not reenabled.
* tag 'pxa-fixes-4.18' of https://github.com/rjarzmik/linux:
ARM: pxa: irq: fix handling of ICMR registers in suspend/resume
Signed-off-by: Olof Johansson <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen fixes from Juergen Gross:
"Two related fixes for a boot failure of Xen PV guests"
* tag 'for-linus-4.18-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen: setup pv irq ops vector earlier
xen: remove global bit from __default_kernel_pte_mask for pv guests
|
|
Pull block fix from Jens Axboe:
"Just a single regression fix (from 4.17) for bsg, fixing an EINVAL
return on non-data commands"
* tag 'for-linus-20180713' of git://git.kernel.dk/linux-block:
bsg: fix bogus EINVAL on non-data commands
|
|
Merge misc fixes from Andrew Morton:
"11 fixes"
* emailed patches form Andrew Morton <[email protected]>:
reiserfs: fix buffer overflow with long warning messages
checkpatch: fix duplicate invalid vsprintf pointer extension '%p<foo>' messages
mm: do not bug_on on incorrect length in __mm_populate()
mm/memblock.c: do not complain about top-down allocations for !MEMORY_HOTREMOVE
fs, elf: make sure to page align bss in load_elf_library
x86/purgatory: add missing FORCE to Makefile target
net/9p/client.c: put refcount of trans_mod in error case in parse_opts()
mm: allow arch to supply p??_free_tlb functions
autofs: fix slab out of bounds read in getname_kernel()
fs/proc/task_mmu.c: fix Locked field in /proc/pid/smaps*
mm: do not drop unused pages when userfaultd is running
|
|
ReiserFS prepares log messages into a 1024-byte buffer with no bounds
checks. Long messages, such as the "unknown mount option" warning when
userspace passes a crafted mount options string, overflow this buffer.
This causes KASAN to report a global-out-of-bounds write.
Fix it by truncating messages to the buffer size.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: [email protected]
Signed-off-by: Eric Biggers <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Multiline statements with invalid %p<foo> uses produce multiple
warnings. Fix that.
e.g.:
$ cat t_block.c
void foo(void)
{
MY_DEBUG(drv->foo,
"%pk",
foo->boo);
}
$ ./scripts/checkpatch.pl -f t_block.c
WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
#1: FILE: t_block.c:1:
+void foo(void)
WARNING: Invalid vsprintf pointer extension '%pk'
#3: FILE: t_block.c:3:
+ MY_DEBUG(drv->foo,
+ "%pk",
+ foo->boo);
WARNING: Invalid vsprintf pointer extension '%pk'
#3: FILE: t_block.c:3:
+ MY_DEBUG(drv->foo,
+ "%pk",
+ foo->boo);
total: 0 errors, 3 warnings, 6 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
t_block.c has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Joe Perches <[email protected]>
Cc: "Tobin C. Harding" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
syzbot has noticed that a specially crafted library can easily hit
VM_BUG_ON in __mm_populate
kernel BUG at mm/gup.c:1242!
invalid opcode: 0000 [#1] SMP
CPU: 2 PID: 9667 Comm: a.out Not tainted 4.18.0-rc3 #644
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
RIP: 0010:__mm_populate+0x1e2/0x1f0
Code: 55 d0 65 48 33 14 25 28 00 00 00 89 d8 75 21 48 83 c4 20 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 75 18 f1 ff 0f 0b e8 6e 18 f1 ff <0f> 0b 31 db eb c9 e8 93 06 e0 ff 0f 1f 00 55 48 89 e5 53 48 89 fb
Call Trace:
vm_brk_flags+0xc3/0x100
vm_brk+0x1f/0x30
load_elf_library+0x281/0x2e0
__ia32_sys_uselib+0x170/0x1e0
do_fast_syscall_32+0xca/0x420
entry_SYSENTER_compat+0x70/0x7f
The reason is that the length of the new brk is not page aligned when we
try to populate the it. There is no reason to bug on that though.
do_brk_flags already aligns the length properly so the mapping is
expanded as it should. All we need is to tell mm_populate about it.
Besides that there is absolutely no reason to to bug_on in the first
place. The worst thing that could happen is that the last page wouldn't
get populated and that is far from putting system into an inconsistent
state.
Fix the issue by moving the length sanitization code from do_brk_flags
up to vm_brk_flags. The only other caller of do_brk_flags is brk
syscall entry and it makes sure to provide the proper length so t here
is no need for sanitation and so we can use do_brk_flags without it.
Also remove the bogus BUG_ONs.
[[email protected]: fix up vm_brk_flags s@request@len@]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Michal Hocko <[email protected]>
Reported-by: syzbot <[email protected]>
Tested-by: Tetsuo Handa <[email protected]>
Reviewed-by: Oscar Salvador <[email protected]>
Cc: Zi Yan <[email protected]>
Cc: "Aneesh Kumar K.V" <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: "Kirill A. Shutemov" <[email protected]>
Cc: Michael S. Tsirkin <[email protected]>
Cc: Al Viro <[email protected]>
Cc: "Huang, Ying" <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|