<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/scripts, branch v6.1.13</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.1.13</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.1.13'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2023-02-09T10:28:11Z</updated>
<entry>
<title>kbuild: modinst: Fix build error when CONFIG_MODULE_SIG_KEY is a PKCS#11 URI</title>
<updated>2023-02-09T10:28:11Z</updated>
<author>
<name>Jan Luebbe</name>
<email>jlu@pengutronix.de</email>
</author>
<published>2023-01-31T08:43:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=65166bccd0383688524d833ed4c52f64f392be56'/>
<id>urn:sha1:65166bccd0383688524d833ed4c52f64f392be56</id>
<content type='text'>
[ Upstream commit 22e46f6480e83bcf49b6d5e6b66c81872c97a902 ]

When CONFIG_MODULE_SIG_KEY is PKCS#11 URI (pkcs11:*), signing of modules
fails:

  scripts/sign-file sha256 /.../linux/pkcs11:token=foo;object=bar;pin-value=1111 certs/signing_key.x509 /.../kernel/crypto/tcrypt.ko
  Usage: scripts/sign-file [-dp] &lt;hash algo&gt; &lt;key&gt; &lt;x509&gt; &lt;module&gt; [&lt;dest&gt;]
         scripts/sign-file -s &lt;raw sig&gt; &lt;hash algo&gt; &lt;x509&gt; &lt;module&gt; [&lt;dest&gt;]

First, we need to avoid adding the $(srctree)/ prefix to the URL.

Second, since the kconfig string values no longer include quotes, we need to add
them again when passing a PKCS#11 URI to sign-file. This avoids
splitting by the shell if the URI contains semicolons.

Fixes: 4db9c2e3d055 ("kbuild: stop using config_filename in scripts/Makefile.modsign")
Fixes: 129ab0d2d9f3 ("kbuild: do not quote string values in include/config/auto.conf")
Signed-off-by: Jan Luebbe &lt;jlu@pengutronix.de&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>Fix up more non-executable files marked executable</title>
<updated>2023-02-01T07:34:49Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-01-28T19:17:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2fd712538d68a738349d48b34bac99c996afc023'/>
<id>urn:sha1:2fd712538d68a738349d48b34bac99c996afc023</id>
<content type='text'>
[ Upstream commit c96618275234ad03d44eafe9f8844305bb44fda4 ]

Joe found another DT file that shouldn't be executable, and that
frustrated me enough that I went hunting with this script:

    git ls-files -s |
        grep '^100755' |
        cut -f2 |
        xargs grep -L '^#!'

and that found another file that shouldn't have been marked executable
either, despite being in the scripts directory.

Maybe these two are the last ones at least for now.  But I'm sure we'll
be back in a few years, fixing things up again.

Fixes: 8c6789f4e2d4 ("ASoC: dt-bindings: Add Everest ES8326 audio CODEC")
Fixes: 4d8e5cd233db ("locking/atomics: Fix scripts/atomic/ script permissions")
Reported-by: Joe Perches &lt;joe@perches.com&gt;
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>ftrace/scripts: Update the instructions for ftrace-bisect.sh</title>
<updated>2023-02-01T07:34:37Z</updated>
<author>
<name>Steven Rostedt (Google)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2023-01-23T16:22:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f9575ea163ad77b9be27c2cfcb094cb983fd2161'/>
<id>urn:sha1:f9575ea163ad77b9be27c2cfcb094cb983fd2161</id>
<content type='text'>
commit 7ae4ba7195b1bac04a4210a499da9d8c63b0ba9c upstream.

The instructions for the ftrace-bisect.sh script, which is used to find
what function is being traced that is causing a kernel crash, and possibly
a triple fault reboot, uses the old method. In 5.1, a new feature was
added that let the user write in the index into available_filter_functions
that maps to the function a user wants to set in set_ftrace_filter (or
set_ftrace_notrace). This takes O(1) to set, as suppose to writing a
function name, which takes O(n) (where n is the number of functions in
available_filter_functions).

The ftrace-bisect.sh requires setting half of the functions in
available_filter_functions, which is O(n^2) using the name method to enable
and can take several minutes to complete. The number method is O(n) which
takes less than a second to complete. Using the number method for any
kernel 5.1 and after is the proper way to do the bisect.

Update the usage to reflect the new change, as well as using the
/sys/kernel/tracing path instead of the obsolete debugfs path.

Link: https://lkml.kernel.org/r/20230123112252.022003dd@gandalf.local.home

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Acked-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Fixes: f79b3f338564e ("ftrace: Allow enabling of filters via index of available_filter_functions")
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'objtool_urgent_for_v6.1_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2022-11-27T20:08:17Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-11-27T20:08:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b465cf177377033f939224d8f16b5b1dddcd9709'/>
<id>urn:sha1:b465cf177377033f939224d8f16b5b1dddcd9709</id>
<content type='text'>
Pull objtool fix from Borislav Petkov:

 - Handle different output of readelf on different distros running
   ppc64le which confuses faddr2line's function offsets conversion

* tag 'objtool_urgent_for_v6.1_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  scripts/faddr2line: Fix regression in name resolution on ppc64le
</content>
</entry>
<entry>
<title>scripts: add rust in scripts/Makefile.package</title>
<updated>2022-11-24T00:27:57Z</updated>
<author>
<name>Paran Lee</name>
<email>p4ranlee@gmail.com</email>
</author>
<published>2022-11-23T22:00:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=df1f1ea9569eef05c006aeae1d65fbf6c2339677'/>
<id>urn:sha1:df1f1ea9569eef05c006aeae1d65fbf6c2339677</id>
<content type='text'>
Add rust argument at TAR_CONTENT in
scripts/Makefile.package script with alphabetical order.

Signed-off-by: Paran Lee &lt;p4ranlee@gmail.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: Restore .version auto-increment behaviour for Debian packages</title>
<updated>2022-11-17T08:51:45Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-11-15T22:04:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5db8face97f81c9342458c052572e19ac6bd8e52'/>
<id>urn:sha1:5db8face97f81c9342458c052572e19ac6bd8e52</id>
<content type='text'>
Since 2df8220cc511 ("kbuild: build init/built-in.a just once"),
generating Debian packages using 'make bindeb-pkg' results in
packages that are stuck to the same .version, leading to unexpected
behaviours (multiple packages with the same version).

That's because the mkdebian script samples the build version
before building the kernel, and forces the use of that version
number for the actual build.

Restore the previous behaviour by calling init/build-version
instead of reading the .version file. This is likely to result
in too many .version bumps, but this is what was happening before
(although the bump was affecting builds made after the current one).

Fixes: 2df8220cc511 ("kbuild: build init/built-in.a just once")
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>scripts/faddr2line: Fix regression in name resolution on ppc64le</title>
<updated>2022-11-16T09:42:10Z</updated>
<author>
<name>Srikar Dronamraju</name>
<email>srikar@linux.vnet.ibm.com</email>
</author>
<published>2022-09-27T07:52:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2d77de1581bb5b470486edaf17a7d70151131afd'/>
<id>urn:sha1:2d77de1581bb5b470486edaf17a7d70151131afd</id>
<content type='text'>
Commit 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section
failures") can cause faddr2line to fail on ppc64le on some
distributions, while it works fine on other distributions. The failure
can be attributed to differences in the readelf output.

  $ ./scripts/faddr2line vmlinux find_busiest_group+0x00
  no match for find_busiest_group+0x00

On ppc64le, readelf adds the localentry tag before the symbol name on
some distributions, and adds the localentry tag after the symbol name on
other distributions. This problem has been discussed previously:

  https://lore.kernel.org/bpf/20191211160133.GB4580@calabresa/

This problem can be overcome by filtering out the localentry tags in the
readelf output. Similar fixes are already present in the kernel by way
of the following commits:

  1fd6cee127e2 ("libbpf: Fix VERSIONED_SYM_COUNT number parsing")
  aa915931ac3e ("libbpf: Fix readelf output parsing for Fedora")

[jpoimboe: rework commit log]

Fixes: 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section failures")
Signed-off-by: Srikar Dronamraju &lt;srikar@linux.vnet.ibm.com&gt;
Acked-by: Naveen N. Rao &lt;naveen.n.rao@linux.vnet.ibm.com&gt;
Reviewed-by: Thadeu Lima de Souza Cascardo &lt;cascardo@canonical.com&gt;
Link: https://lore.kernel.org/r/20220927075211.897152-1-srikar@linux.vnet.ibm.com
Signed-off-by: Josh Poimboeuf &lt;jpoimboe@kernel.org&gt;
Signed-off-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 's390-6.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux</title>
<updated>2022-11-11T19:49:20Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-11-11T19:49:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f5020a08b2b371162a4a16ef97694cac3980397e'/>
<id>urn:sha1:f5020a08b2b371162a4a16ef97694cac3980397e</id>
<content type='text'>
Pull s390 fixes from Alexander Gordeev:

 - fix memcpy warning about field-spanning write in zcrypt driver

 - minor updates to defconfigs

 - remove CONFIG_DEBUG_INFO_BTF from all defconfigs and add btf.config
   addon config file. It significantly decreases compile time and allows
   quickly enabling that option into the current kernel config

 - add kasan.config addon config file which allows to easily enable
   KASAN into the current kernel config

 - binutils commit 906f69cf65da ("IBM zSystems: Issue error for *DBL
   relocs on misaligned symbols") caused several link errors. Always
   build relocatable kernel to avoid this problem

 - raise the minimum clang version to 15.0.0 to avoid silent generation
   of a corrupted code

* tag 's390-6.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  scripts/min-tool-version.sh: raise minimum clang version to 15.0.0 for s390
  s390: always build relocatable kernel
  s390/configs: add kasan.config addon config file
  s390/configs: move CONFIG_DEBUG_INFO_BTF into btf.config addon config
  s390: update defconfigs
  s390/zcrypt: fix warning about field-spanning write
</content>
</entry>
<entry>
<title>scripts/min-tool-version.sh: raise minimum clang version to 15.0.0 for s390</title>
<updated>2022-11-09T17:41:16Z</updated>
<author>
<name>Heiko Carstens</name>
<email>hca@linux.ibm.com</email>
</author>
<published>2022-10-31T12:34:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=30d17fac6aaedb40d111bb159f4b35525637ea78'/>
<id>urn:sha1:30d17fac6aaedb40d111bb159f4b35525637ea78</id>
<content type='text'>
Before version 15.0.0 llvm's integrated assembler may silently
generate corrupted code on s390. See e.g. commit e9953b729b78
("s390/boot: workaround llvm IAS bug") for further details.

While there have been workarounds applied for all known existing
locations, there is nothing that prevents that new code with
problematic patterns will be added.

Therefore raise the minimum clang version to 15.0.0. Note that llvm
commit e547b04d5b2c ("[SystemZ] Bugfix for symbolic displacements."),
which is included in 15.0.0, fixes the broken code generation.

Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Acked-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Link: https://lore.kernel.org/r/20221031123456.3872220-1-hca@linux.ibm.com
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>kconfig: fix segmentation fault in menuconfig search</title>
<updated>2022-11-02T08:32:05Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2022-10-23T19:10:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7a263a0402561035199cd9049baadb908a92b6b4'/>
<id>urn:sha1:7a263a0402561035199cd9049baadb908a92b6b4</id>
<content type='text'>
Since commit d05377e184fc ("kconfig: Create links to main menu items
in search"), menuconfig shows a jump key next to "Main menu" if the
nearest visible parent is the rootmenu. If you press that jump key,
menuconfig crashes with a segmentation fault.

For example, do this:

  $ make ARCH=arm64 allnoconfig menuconfig

Press '/' to search for the string "ACPI". Press '1' to choose
"(1) Main menu". Then, menuconfig crashed with a segmentation fault.

The following code in search_conf()

    conf(targets[i]-&gt;parent, targets[i]);

results in NULL pointer dereference because targets[i] is the rootmenu,
which does not have a parent.

Commit d05377e184fc tried to fix the issue of top-level items not having
a jump key, but adding the "Main menu" was not the right fix.

The correct fix is to show the searched item itself. This fixes another
weird behavior described in the comment block.

Fixes: d05377e184fc ("kconfig: Create links to main menu items in search")
Reported-by: Johannes Zink &lt;j.zink@pengutronix.de&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Tested-by: Bagas Sanjaya &lt;bagasdotme@gmail.com&gt;
Tested-by: Johannes Zink &lt;j.zink@pengutronix.de&gt;
</content>
</entry>
</feed>
