<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/scripts, branch v5.4.50</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.50</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.50'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-06-30T19:37:05+00:00</updated>
<entry>
<title>recordmcount: support &gt;64k sections</title>
<updated>2020-06-30T19:37:05+00:00</updated>
<author>
<name>Sami Tolvanen</name>
<email>samitolvanen@google.com</email>
</author>
<published>2020-04-24T19:30:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8ed391a3dbc497f83a5fc6eabdd86784a3172b3c'/>
<id>urn:sha1:8ed391a3dbc497f83a5fc6eabdd86784a3172b3c</id>
<content type='text'>
[ Upstream commit 4ef57b21d6fb49d2b25c47e4cff467a0c2c8b6b7 ]

When compiling a kernel with Clang and LTO, we need to run
recordmcount on vmlinux.o with a large number of sections, which
currently fails as the program doesn't understand extended
section indexes. This change adds support for processing binaries
with &gt;64k sections.

Link: https://lkml.kernel.org/r/20200424193046.160744-1-samitolvanen@google.com
Link: https://lore.kernel.org/lkml/CAK7LNARbZhoaA=Nnuw0=gBrkuKbr_4Ng_Ei57uafujZf7Xazgw@mail.gmail.com/

Cc: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Matt Helsley &lt;mhelsley@vmware.com&gt;
Signed-off-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: improve cc-option to clean up all temporary files</title>
<updated>2020-06-30T19:37:05+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2020-06-14T14:43:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=803d114e8f19cb5e9e40b5c26d8ea33829916d09'/>
<id>urn:sha1:803d114e8f19cb5e9e40b5c26d8ea33829916d09</id>
<content type='text'>
[ Upstream commit f2f02ebd8f3833626642688b2d2c6a7b3c141fa9 ]

When cc-option and friends evaluate compiler flags, the temporary file
$$TMP is created as an output object, and automatically cleaned up.
The actual file path of $$TMP is .&lt;pid&gt;.tmp, here &lt;pid&gt; is the process
ID of $(shell ...) invoked from cc-option. (Please note $$$$ is the
escape sequence of $$).

Such garbage files are cleaned up in most cases, but some compiler flags
create additional output files.

For example, -gsplit-dwarf creates a .dwo file.

When CONFIG_DEBUG_INFO_SPLIT=y, you will see a bunch of .&lt;pid&gt;.dwo files
left in the top of build directories. You may not notice them unless you
do 'ls -a', but the garbage files will increase every time you run 'make'.

This commit changes the temporary object path to .tmp_&lt;pid&gt;/tmp, and
removes .tmp_&lt;pid&gt; directory when exiting. Separate build artifacts such
as *.dwo will be cleaned up all together because their file paths are
usually determined based on the base name of the object.

Another example is -ftest-coverage, which outputs the coverage data into
&lt;base-name-of-object&gt;.gcno

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scripts: headers_install: Exit with error on config leak</title>
<updated>2020-06-24T15:50:33+00:00</updated>
<author>
<name>Siddharth Gupta</name>
<email>sidgup@codeaurora.org</email>
</author>
<published>2020-05-06T01:52:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4c8a62c939840b2ad41ac6c6aadc44535761f9e4'/>
<id>urn:sha1:4c8a62c939840b2ad41ac6c6aadc44535761f9e4</id>
<content type='text'>
[ Upstream commit 5967577231f9b19acd5a59485e9075964065bbe3 ]

Misuse of CONFIG_* in UAPI headers should result in an error. These config
options can be set in userspace by the user application which includes
these headers to control the APIs and structures being used in a kernel
which supports multiple targets.

Signed-off-by: Siddharth Gupta &lt;sidgup@codeaurora.org&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mksysmap: Fix the mismatch of '.L' symbols in System.map</title>
<updated>2020-06-24T15:50:19+00:00</updated>
<author>
<name>ashimida</name>
<email>ashimida@linux.alibaba.com</email>
</author>
<published>2020-06-02T07:45:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d782d6a142d51d84fc08d9d93aa3235900303ffc'/>
<id>urn:sha1:d782d6a142d51d84fc08d9d93aa3235900303ffc</id>
<content type='text'>
[ Upstream commit 72d24accf02add25e08733f0ecc93cf10fcbd88c ]

When System.map was generated, the kernel used mksysmap to
filter the kernel symbols, but all the symbols with the
second letter 'L' in the kernel were filtered out, not just
the symbols starting with 'dot + L'.

For example:
ashimida@ubuntu:~/linux$ cat System.map |grep ' .L'
ashimida@ubuntu:~/linux$ nm -n vmlinux |grep ' .L'
ffff0000088028e0 t bLength_show
......
ffff0000092e0408 b PLLP_OUTC_lock
ffff0000092e0410 b PLLP_OUTA_lock

The original intent should be to filter out all local symbols
starting with '.L', so the dot should be escaped.

Fixes: 00902e984732 ("mksysmap: Add h8300 local symbol pattern")
Signed-off-by: ashimida &lt;ashimida@linux.alibaba.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpf: Support llvm-objcopy for vmlinux BTF</title>
<updated>2020-06-17T14:40:20+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>maskray@google.com</email>
</author>
<published>2020-03-18T22:27:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f04d1e880f17b935b5a181d446ff82b4193eee85'/>
<id>urn:sha1:f04d1e880f17b935b5a181d446ff82b4193eee85</id>
<content type='text'>
commit 90ceddcb495008ac8ba7a3dce297841efcd7d584 upstream.

Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.

'file format' output of llvm-objdump&gt;=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code
can reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2&gt;/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

Fixes: df786c9b9476 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc635c7a9 ("powerpc: Include .BTF section")
Reported-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Fangrui Song &lt;maskray@google.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Tested-by: Stanislav Fomichev &lt;sdf@google.com&gt;
Tested-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Reviewed-by: Stanislav Fomichev &lt;sdf@google.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Acked-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt; (powerpc)
Link: https://github.com/ClangBuiltLinux/linux/issues/871
Link: https://lore.kernel.org/bpf/20200318222746.173648-1-maskray@google.com
Signed-off-by: Maria Teguiani &lt;teguiani@google.com&gt;
Tested-by: Matthias Maennich &lt;maennich@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kbuild: Remove debug info from kallsyms linking</title>
<updated>2020-05-27T15:46:44+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2020-03-04T02:18:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bb6524537dc2f8b2a2bae63926b02e5e008be0fd'/>
<id>urn:sha1:bb6524537dc2f8b2a2bae63926b02e5e008be0fd</id>
<content type='text'>
[ Upstream commit af73d78bd384aa9b8789aa6e7ddbb165f971276f ]

When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
time collecting and writing the dwarf sections to the temporary output
files. kallsyms does not need this information, and leaving it off
halves their linking time. This is especially noticeable without
CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still
need those details.

Refactor the BTF and kallsyms generation stages slightly for more
regularized temporary names. Skip debug during kallsyms links.
Additionally move "info BTF" to the correct place since commit
8959e39272d6 ("kbuild: Parameterize kallsyms generation and correct
reporting"), which added "info LD ..." to vmlinux_link calls.

For a full debug info build with BTF, my link time goes from 1m06s to
0m54s, saving about 12 seconds, or 18%.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Link: https://lore.kernel.org/bpf/202003031814.4AEA3351@keescook
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scripts/gdb: repair rb_first() and rb_last()</title>
<updated>2020-05-27T15:46:36+00:00</updated>
<author>
<name>Aymeric Agon-Rambosson</name>
<email>aymeric.agon@yandex.com</email>
</author>
<published>2020-05-08T01:36:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=02ebbd1da3945a9344f498f4418ff9287eecb86b'/>
<id>urn:sha1:02ebbd1da3945a9344f498f4418ff9287eecb86b</id>
<content type='text'>
[ Upstream commit 50e36be1fb9572b2e4f2753340bdce3116bf2ce7 ]

The current implementations of the rb_first() and rb_last() gdb
functions have a variable that references itself in its instanciation,
which causes the function to throw an error if a specific condition on
the argument is met.  The original author rather intended to reference
the argument and made a typo.  Referring the argument instead makes the
function work as intended.

Signed-off-by: Aymeric Agon-Rambosson &lt;aymeric.agon@yandex.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Reviewed-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Cc: Jan Kiszka &lt;jan.kiszka@siemens.com&gt;
Cc: Kieran Bingham &lt;kbingham@kernel.org&gt;
Cc: Douglas Anderson &lt;dianders@chromium.org&gt;
Cc: Nikolay Borisov &lt;n.borisov.lkml@gmail.com&gt;
Cc: Jackie Liu &lt;liuyun01@kylinos.cn&gt;
Cc: Jason Wessel &lt;jason.wessel@windriver.com&gt;
Link: http://lkml.kernel.org/r/20200427051029.354840-1-aymeric.agon@yandex.com
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gcc-common.h: Update for GCC 10</title>
<updated>2020-05-27T15:46:24+00:00</updated>
<author>
<name>Frédéric Pierret (fepitre)</name>
<email>frederic.pierret@qubes-os.org</email>
</author>
<published>2020-04-07T11:32:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cc6428803d22f63886febb62703ab8a1533681d8'/>
<id>urn:sha1:cc6428803d22f63886febb62703ab8a1533681d8</id>
<content type='text'>
[ Upstream commit c7527373fe28f97d8a196ab562db5589be0d34b9 ]

Remove "params.h" include, which has been dropped in GCC 10.

Remove is_a_helper() macro, which is now defined in gimple.h, as seen
when running './scripts/gcc-plugin.sh g++ g++ gcc':

In file included from &lt;stdin&gt;:1:
./gcc-plugins/gcc-common.h:852:13: error: redefinition of ‘static bool is_a_helper&lt;T&gt;::test(U*) [with U = const gimple; T = const ggoto*]’
  852 | inline bool is_a_helper&lt;const ggoto *&gt;::test(const_gimple gs)
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./gcc-plugins/gcc-common.h:125,
                 from &lt;stdin&gt;:1:
/usr/lib/gcc/x86_64-redhat-linux/10/plugin/include/gimple.h:1037:1: note: ‘static bool is_a_helper&lt;T&gt;::test(U*) [with U = const gimple; T = const ggoto*]’ previously declared here
 1037 | is_a_helper &lt;const ggoto *&gt;::test (const gimple *gs)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~

Add -Wno-format-diag to scripts/gcc-plugins/Makefile to avoid
meaningless warnings from error() formats used by plugins:

scripts/gcc-plugins/structleak_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’:
scripts/gcc-plugins/structleak_plugin.c:253:12: warning: unquoted sequence of 2 consecutive punctuation characters ‘'-’ in format [-Wformat-diag]
  253 |   error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, argv[i].key);
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Signed-off-by: Frédéric Pierret (fepitre) &lt;frederic.pierret@qubes-os.org&gt;
Link: https://lore.kernel.org/r/20200407113259.270172-1-frederic.pierret@qubes-os.org
[kees: include -Wno-format-diag for plugin builds]
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scripts/decodecode: fix trapping instruction formatting</title>
<updated>2020-05-14T05:58:29+00:00</updated>
<author>
<name>Ivan Delalande</name>
<email>colona@arista.com</email>
</author>
<published>2020-05-08T01:35:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1642f114ce2da4aec7c40fbbbbabc991f7f0c8cd'/>
<id>urn:sha1:1642f114ce2da4aec7c40fbbbbabc991f7f0c8cd</id>
<content type='text'>
commit e08df079b23e2e982df15aa340bfbaf50f297504 upstream.

If the trapping instruction contains a ':', for a memory access through
segment registers for example, the sed substitution will insert the '*'
marker in the middle of the instruction instead of the line address:

	2b:   65 48 0f c7 0f          cmpxchg16b %gs:*(%rdi)          &lt;-- trapping instruction

I started to think I had forgotten some quirk of the assembly syntax
before noticing that it was actually coming from the script.  Fix it to
add the address marker at the right place for these instructions:

	28:   49 8b 06                mov    (%r14),%rax
	2b:*  65 48 0f c7 0f          cmpxchg16b %gs:(%rdi)           &lt;-- trapping instruction
	30:   0f 94 c0                sete   %al

Fixes: 18ff44b189e2 ("scripts/decodecode: make faulting insn ptr more robust")
Signed-off-by: Ivan Delalande &lt;colona@arista.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Reviewed-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: http://lkml.kernel.org/r/20200419223653.GA31248@visor
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scripts/config: allow colons in option strings for sed</title>
<updated>2020-05-10T08:31:27+00:00</updated>
<author>
<name>Jeremie Francois (on alpha)</name>
<email>jeremie.francois@gmail.com</email>
</author>
<published>2020-04-10T16:57:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=84778248e013eacafb16ea0261fd4de4dd2f4497'/>
<id>urn:sha1:84778248e013eacafb16ea0261fd4de4dd2f4497</id>
<content type='text'>
[ Upstream commit e461bc9f9ab105637b86065d24b0b83f182d477c ]

Sed broke on some strings as it used colon as a separator.
I made it more robust by using \001, which is legit POSIX AFAIK.

E.g. ./config --set-str CONFIG_USBNET_DEVADDR "de:ad:be:ef:00:01"
failed with: sed: -e expression #1, char 55: unknown option to `s'

Signed-off-by: Jeremie Francois (on alpha) &lt;jeremie.francois@gmail.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
