Searched +hist:59 +hist:b2bd05 (Results 1 - 3 of 3) sorted by relevance

/linux-master/scripts/
H A DMakefile.headersinstdiff 59b2bd05 Tue Jun 04 04:14:02 MDT 2019 Masahiro Yamada <yamada.masahiro@socionext.com> kbuild: add 'headers' target to build up uapi headers in usr/include

In Linux build system, build targets and installation targets are
separated.

Examples are:

- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'

The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.

We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.

If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.

Anyway, I believe it makes sense to split the header installation into
two stages.

[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include

[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include

For the backward compatibility, 'headers_install' depends on 'headers'.

Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.

Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.

Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
diff 59b2bd05 Tue Jun 04 04:14:02 MDT 2019 Masahiro Yamada <yamada.masahiro@socionext.com> kbuild: add 'headers' target to build up uapi headers in usr/include

In Linux build system, build targets and installation targets are
separated.

Examples are:

- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'

The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.

We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.

If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.

Anyway, I believe it makes sense to split the header installation into
two stages.

[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include

[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include

For the backward compatibility, 'headers_install' depends on 'headers'.

Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.

Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.

Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
/linux-master/lib/
H A DKconfig.debugdiff cf536e18 Thu May 06 01:34:59 MDT 2021 Feng Tang <feng.tang@intel.com> Makefile: extend 32B aligned debug option to 64B aligned

Commit 09c60546f04f ("./Makefile: add debug option to enable
function aligned on 32 bytes") was introduced to help debugging
strange kernel performance changes caused by code alignment
change.

Recently we found 2 similar cases [1][2] caused by code-alignment
changes, which can only be identified by forcing 64 bytes aligned
for all functions.

Originally, 32 bytes was used mainly for not wasting too much
text space, but this option is only for debug anyway where text
space is not a big concern. So extend the alignment to 64 bytes
to cover more similar cases.

[1].https://lore.kernel.org/lkml/20210427090013.GG32408@xsang-OptiPlex-9020/
[2].https://lore.kernel.org/lkml/20210420030837.GB31773@xsang-OptiPlex-9020/
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff e9d338a0 Wed Jun 24 16:59:59 MDT 2020 Paul E. McKenney <paulmck@kernel.org> scftorture: Add smp_call_function() torture test

This commit adds an smp_call_function() torture test that repeatedly
invokes this function and complains if things go badly awry.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
diff e9d338a0 Wed Jun 24 16:59:59 MDT 2020 Paul E. McKenney <paulmck@kernel.org> scftorture: Add smp_call_function() torture test

This commit adds an smp_call_function() torture test that repeatedly
invokes this function and complains if things go badly awry.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
diff c71fd893 Mon May 20 14:59:00 MDT 2019 Waiman Long <longman@redhat.com> locking/rwsem: Make owner available even if !CONFIG_RWSEM_SPIN_ON_OWNER

The owner field in the rw_semaphore structure is used primarily for
optimistic spinning. However, identifying the rwsem owner can also be
helpful in debugging as well as tracing locking related issues when
analyzing crash dump. The owner field may also store state information
that can be important to the operation of the rwsem.

So the owner field is now made a permanent member of the rw_semaphore
structure irrespective of CONFIG_RWSEM_SPIN_ON_OWNER.

Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: huang ying <huang.ying.caritas@gmail.com>
Link: https://lkml.kernel.org/r/20190520205918.22251-2-longman@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
diff 59b2bd05 Tue Jun 04 04:14:02 MDT 2019 Masahiro Yamada <yamada.masahiro@socionext.com> kbuild: add 'headers' target to build up uapi headers in usr/include

In Linux build system, build targets and installation targets are
separated.

Examples are:

- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'

The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.

We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.

If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.

Anyway, I believe it makes sense to split the header installation into
two stages.

[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include

[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include

For the backward compatibility, 'headers_install' depends on 'headers'.

Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.

Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.

Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
diff 59b2bd05 Tue Jun 04 04:14:02 MDT 2019 Masahiro Yamada <yamada.masahiro@socionext.com> kbuild: add 'headers' target to build up uapi headers in usr/include

In Linux build system, build targets and installation targets are
separated.

Examples are:

- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'

The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.

We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.

If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.

Anyway, I believe it makes sense to split the header installation into
two stages.

[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include

[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include

For the backward compatibility, 'headers_install' depends on 'headers'.

Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.

Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.

Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
diff e949f4c2 Tue Jun 04 04:13:59 MDT 2019 Masahiro Yamada <yamada.masahiro@socionext.com> kbuild: add CONFIG_HEADERS_INSTALL and loosen the dependency of samples

Commit 5318321d367c ("samples: disable CONFIG_SAMPLES for UML") used
a big hammer to fix the build errors under the samples/ directory.
Only some samples actually include uapi headers from usr/include.

Introduce CONFIG_HEADERS_INSTALL since 'depends on HEADERS_INSTALL' is
clearer than 'depends on !UML'. If this option is enabled, uapi headers
are installed before starting directory descending.

I added 'depends on HEADERS_INSTALL' to per-sample CONFIG options.
This allows UML to compile some samples.

$ make ARCH=um allmodconfig samples/
[ snip ]
CC [M] samples/configfs/configfs_sample.o
CC [M] samples/kfifo/bytestream-example.o
CC [M] samples/kfifo/dma-example.o
CC [M] samples/kfifo/inttype-example.o
CC [M] samples/kfifo/record-example.o
CC [M] samples/kobject/kobject-example.o
CC [M] samples/kobject/kset-example.o
CC [M] samples/trace_events/trace-events-sample.o
CC [M] samples/trace_printk/trace-printk.o
AR samples/vfio-mdev/built-in.a
AR samples/built-in.a

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
diff 0b0600c8 Thu Apr 04 07:58:59 MDT 2019 Tobin C. Harding <tobin@kernel.org> lib: Add test module for strscpy_pad

Add a test module for the new strscpy_pad() function. Tie it into the
kselftest infrastructure for lib/ tests.

Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tobin C. Harding <tobin@kernel.org>
Signed-off-by: Shuah Khan <shuah@kernel.org>
diff 72deb455 Fri Apr 05 10:08:59 MDT 2019 Christoph Hellwig <hch@lst.de> block: remove CONFIG_LBDAF

Currently support for 64-bit sector_t and blkcnt_t is optional on 32-bit
architectures. These types are required to support block device and/or
file sizes larger than 2 TiB, and have generally defaulted to on for
a long time. Enabling the option only increases the i386 tinyconfig
size by 145 bytes, and many data structures already always use
64-bit values for their in-core and on-disk data structures anyway,
so there should not be a large change in dynamic memory usage either.

Dropping this option removes a somewhat weird non-default config that
has cause various bugs or compiler warnings when actually used.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
diff 8ab8ba38 Mon Jun 18 14:59:29 MDT 2018 Matthew Wilcox <willy@infradead.org> ida: Start new test_ida module

Start transitioning the IDA tests into kernel space. Framework heavily
cribbed from test_xarray.c.

Signed-off-by: Matthew Wilcox <willy@infradead.org>
/linux-master/
H A DMakefilediff 64570fbc Sun Oct 10 18:01:59 MDT 2021 Linus Torvalds <torvalds@linux-foundation.org> Linux 5.15-rc5
diff cf536e18 Thu May 06 01:34:59 MDT 2021 Feng Tang <feng.tang@intel.com> Makefile: extend 32B aligned debug option to 64B aligned

Commit 09c60546f04f ("./Makefile: add debug option to enable
function aligned on 32 bytes") was introduced to help debugging
strange kernel performance changes caused by code alignment
change.

Recently we found 2 similar cases [1][2] caused by code-alignment
changes, which can only be identified by forcing 64 bytes aligned
for all functions.

Originally, 32 bytes was used mainly for not wasting too much
text space, but this option is only for debug anyway where text
space is not a big concern. So extend the alignment to 64 bytes
to cover more similar cases.

[1].https://lore.kernel.org/lkml/20210427090013.GG32408@xsang-OptiPlex-9020/
[2].https://lore.kernel.org/lkml/20210420030837.GB31773@xsang-OptiPlex-9020/
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff eec08090 Tue Mar 09 13:59:15 MST 2021 Nathan Chancellor <nathan@kernel.org> Makefile: Only specify '--prefix=' when building with clang + GNU as

When building with LLVM_IAS=1, there is no point to specifying
'--prefix=' because that flag is only used to find GNU cross tools,
which will not be used indirectly when using the integrated assembler.
All of the tools are invoked directly from PATH or a full path specified
via the command line, which does not depend on the value of '--prefix='.

Sharing commands to reproduce issues becomes a little bit easier without
a '--prefix=' value because that '--prefix=' value is specific to a
user's machine due to it being an absolute path.

Some further notes from Fangrui Song:

clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU
objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]).
objcopy is only used for GNU as assembled object files.
With integrated assembler, the object file streamer creates .o and
.dwo simultaneously.
With GNU as, two objcopy commands are needed to extract .debug*.dwo to
.dwo files && another command to remove .debug*.dwo sections.

A small consequence of this change (to keep things simple) is that
'--prefix=' will always be specified now, even with a native build, when
it was not before. This should not be an issue due to the way that the
Makefile searches for the prefix (based on elfedit's location). This
ends up improving the experience for host builds because PATH is better
respected and matches GCC's behavior more closely. See the below thread
for more details:

https://lore.kernel.org/r/20210205213651.GA16907@Ryzen-5-4500U.localdomain/

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff c91d4e47 Tue Mar 09 13:59:14 MST 2021 Nathan Chancellor <nathan@kernel.org> Makefile: Remove '--gcc-toolchain' flag

This flag was originally added to allow clang to find the GNU cross
tools in commit 785f11aa595b ("kbuild: Add better clang cross build
support"). This flag was not enough to find the tools at times so
'--prefix' was added to the list in commit ef8c4ed9db80 ("kbuild: allow
to use GCC toolchain not in Clang search path") and improved upon in
commit ca9b31f6bb9c ("Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang
cross compilation"). Now that '--prefix' specifies a full path and
prefix, '--gcc-toolchain' serves no purpose because the kernel builds
with '-nostdinc' and '-nostdlib'.

This has been verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as
well as a distribution version of LLVM 11.1.0 without binutils in the
LLVM toolchain locations.

Link: https://reviews.llvm.org/D97902
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Fangrui Song <maskray@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff 5e95325f Tue Feb 23 14:59:52 MST 2021 Sami Tolvanen <samitolvanen@google.com> kbuild: lto: force rebuilds when switching CONFIG_LTO

When doing non-clean builds and switching between CONFIG_LTO=n and
CONFIG_LTO=y, the build system (correctly) didn't notice that assembly
and LTO-excluded C object files were rewritten in place by objtool (to
add the .orc_unwind* sections), since their build command lines were the
same between CONFIG_LTO=y and CONFIG_LTO=n. The objtool step would fail:

vmlinux.o: warning: objtool: file already has .orc_unwind section, skipping
make: *** [Makefile:1194: vmlinux] Error 255

Avoid this by making sure the build will see a difference between an LTO
and non-LTO build (by including "-fno-lto" in KBUILD_*FLAGS). This will
get ignored when CC_FLAGS_LTO is present, and will not be included at
all when CONFIG_LTO=n.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
diff 7d4eb0d8 Thu Sep 10 07:51:19 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> kbuild: remove cc-option test of -fno-stack-check

The minimal compiler version, GCC 4.9 supports this flag.

Nathan Chancellor pointed out:
"This flag is technically ignored by clang (see commit
05b0798916f01690b5903302e51f3136274e291f) but that obviously
does not matter for the sake of this."

Here is the godbolt:
https://godbolt.org/z/59cK6o

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
diff 893ab004 Fri Jun 26 12:59:12 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> kbuild: remove cc-option test of -fno-stack-protector

Some Makefiles already pass -fno-stack-protector unconditionally.
For example, arch/arm64/kernel/vdso/Makefile, arch/x86/xen/Makefile.

No problem report so far about hard-coding this option. So, we can
assume all supported compilers know -fno-stack-protector.

GCC 4.8 and Clang support this option (https://godbolt.org/z/_HDGzN)

Get rid of cc-option from -fno-stack-protector.

Remove CONFIG_CC_HAS_STACKPROTECTOR_NONE, which is always 'y'.

Note:
arch/mips/vdso/Makefile adds -fno-stack-protector twice, first
unconditionally, and second conditionally. I removed the second one.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
diff e4a42c82 Sun Jun 07 15:59:44 MDT 2020 Denis Efremov <efremov@linux.com> kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables

Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp.
GZIP, BZIP2, LZOP env variables are reserved by the tools. The original
attempt to redefine them internally doesn't work in makefiles/scripts
intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in
broken builds. There can be other broken build commands because of this,
so the universal solution is to use non-reserved env variables for the
compression tools.

Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools")
Signed-off-by: Denis Efremov <efremov@linux.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff f0d50ca0 Sun May 31 23:56:59 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> kbuild: refactor KBUILD_VMLINUX_{OBJS,LIBS} calculation

Do not overwrite core-y or drivers-y. Remove libs-y1 and libs-y2.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff b480fec9 Thu May 21 19:59:59 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> kbuild: clear KBUILD_MODULES in top Makefile if CONFIG_MODULES=n

Do not try to build any module-related artifacts when CONFIG_MODULES
is disabled.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff b480fec9 Thu May 21 19:59:59 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> kbuild: clear KBUILD_MODULES in top Makefile if CONFIG_MODULES=n

Do not try to build any module-related artifacts when CONFIG_MODULES
is disabled.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Completed in 440 milliseconds