<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/scripts/Makefile.lib, branch v6.13.4</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.13.4</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.13.4'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2025-02-08T09:02:18Z</updated>
<entry>
<title>kbuild: fix Clang LTO with CONFIG_OBJTOOL=n</title>
<updated>2025-02-08T09:02:18Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2025-01-31T14:04:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3c51227c637fa96faa82f133e9560d19256c602f'/>
<id>urn:sha1:3c51227c637fa96faa82f133e9560d19256c602f</id>
<content type='text'>
[ Upstream commit 695ed93bb30e03e9f826ee70abdd83f970741a37 ]

Since commit bede169618c6 ("kbuild: enable objtool for *.mod.o and
additional kernel objects"), Clang LTO builds do not perform any
optimizations when CONFIG_OBJTOOL is disabled (e.g., for ARCH=arm64).
This is because every LLVM bitcode file is immediately converted to
ELF format before the object files are linked together.

This commit fixes the breakage.

Fixes: bede169618c6 ("kbuild: enable objtool for *.mod.o and additional kernel objects")
Reported-by: Yonghong Song &lt;yonghong.song@linux.dev&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Tested-by: Yonghong Song &lt;yonghong.song@linux.dev&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: switch from lz4c to lz4 for compression</title>
<updated>2024-11-27T23:11:56Z</updated>
<author>
<name>Parth Pancholi</name>
<email>parth.pancholi@toradex.com</email>
</author>
<published>2024-11-14T14:56:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e397a603e49cc7c7c113fad9f55a09637f290c34'/>
<id>urn:sha1:e397a603e49cc7c7c113fad9f55a09637f290c34</id>
<content type='text'>
Replace lz4c with lz4 for kernel image compression.
Although lz4 and lz4c are functionally similar, lz4c has been deprecated
upstream since 2018. Since as early as Ubuntu 16.04 and Fedora 25, lz4
and lz4c have been packaged together, making it safe to update the
requirement from lz4c to lz4.

Consequently, some distributions and build systems, such as OpenEmbedded,
have fully transitioned to using lz4. OpenEmbedded core adopted this
change in commit fe167e082cbd ("bitbake.conf: require lz4 instead of
lz4c"), causing compatibility issues when building the mainline kernel
in the latest OpenEmbedded environment, as seen in the errors below.

This change also updates the LZ4 compression commands to make it backward
compatible by replacing stdin and stdout with the '-' option, due to some
unclear reason, the stdout keyword does not work for lz4 and '-' works for
both. In addition, this modifies the legacy '-c1' with '-9' which is also
compatible with both. This fixes the mainline kernel build failures with
the latest master OpenEmbedded builds associated with the mentioned
compatibility issues.

LZ4     arch/arm/boot/compressed/piggy_data
/bin/sh: 1: lz4c: not found
...
...
ERROR: oe_runmake failed

Link: https://github.com/lz4/lz4/pull/553
Suggested-by: Francesco Dolcini &lt;francesco.dolcini@toradex.com&gt;
Signed-off-by: Parth Pancholi &lt;parth.pancholi@toradex.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: enable objtool for *.mod.o and additional kernel objects</title>
<updated>2024-11-27T23:11:55Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2024-11-13T23:45:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bede169618c68379e1be7ace14e8ac85b964a9ec'/>
<id>urn:sha1:bede169618c68379e1be7ace14e8ac85b964a9ec</id>
<content type='text'>
Currently, objtool is disabled in scripts/Makefile.{modfinal,vmlinux}.

This commit moves rule_cc_o_c and rule_as_o_S to scripts/Makefile.lib
and set objtool-enabled to y there.

With this change, *.mod.o, .module-common.o,  builtin-dtb.o, and
vmlinux.export.o will now be covered by objtool.

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: move cmd_cc_o_c and cmd_as_o_S to scripts/Malefile.lib</title>
<updated>2024-11-27T23:11:55Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2024-11-13T23:45:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=000e22a80de0727839bb753159ac05c8ba20c3e3'/>
<id>urn:sha1:000e22a80de0727839bb753159ac05c8ba20c3e3</id>
<content type='text'>
The cmd_cc_o_c and cmd_as_o_S macros are duplicated in
scripts/Makefile.{build,modfinal,vmlinux}.

This commit factors them out to scripts/Makefile.lib.

No functional changes are intended.

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: support building external modules in a separate build directory</title>
<updated>2024-11-27T23:11:55Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2024-11-10T01:34:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=11b3d5175e6bc3779159228e6077be202d2b0069'/>
<id>urn:sha1:11b3d5175e6bc3779159228e6077be202d2b0069</id>
<content type='text'>
There has been a long-standing request to support building external
modules in a separate build directory.

This commit introduces a new environment variable, KBUILD_EXTMOD_OUTPUT,
and its shorthand Make variable, MO.

A simple usage:

 $ make -C &lt;kernel-dir&gt; M=&lt;module-src-dir&gt; MO=&lt;module-build-dir&gt;

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Reviewed-by: Nicolas Schier &lt;nicolas@fjasle.eu&gt;
</content>
</entry>
<entry>
<title>kbuild: Add Propeller configuration for kernel build</title>
<updated>2024-11-27T00:38:27Z</updated>
<author>
<name>Rong Xu</name>
<email>xur@google.com</email>
</author>
<published>2024-11-02T17:51:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d5dc95836147f2e25b134c0ca3a0bc1a5867ea29'/>
<id>urn:sha1:d5dc95836147f2e25b134c0ca3a0bc1a5867ea29</id>
<content type='text'>
Add the build support for using Clang's Propeller optimizer. Like
AutoFDO, Propeller uses hardware sampling to gather information
about the frequency of execution of different code paths within a
binary. This information is then used to guide the compiler's
optimization decisions, resulting in a more efficient binary.

The support requires a Clang compiler LLVM 19 or later, and the
create_llvm_prof tool
(https://github.com/google/autofdo/releases/tag/v0.30.1). This
commit is limited to x86 platforms that support PMU features
like LBR on Intel machines and AMD Zen3 BRS.

Here is an example workflow for building an AutoFDO+Propeller
optimized kernel:

1) Build the kernel on the host machine, with AutoFDO and Propeller
   build config
      CONFIG_AUTOFDO_CLANG=y
      CONFIG_PROPELLER_CLANG=y
   then
      $ make LLVM=1 CLANG_AUTOFDO_PROFILE=&lt;autofdo_profile&gt;

“&lt;autofdo_profile&gt;” is the profile collected when doing a non-Propeller
AutoFDO build. This step builds a kernel that has the same optimization
level as AutoFDO, plus a metadata section that records basic block
information. This kernel image runs as fast as an AutoFDO optimized
kernel.

2) Install the kernel on test/production machines.

3) Run the load tests. The '-c' option in perf specifies the sample
   event period. We suggest using a suitable prime number,
   like 500009, for this purpose.
   For Intel platforms:
      $ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c &lt;count&gt; \
        -o &lt;perf_file&gt; -- &lt;loadtest&gt;
   For AMD platforms:
      The supported system are: Zen3 with BRS, or Zen4 with amd_lbr_v2
      # To see if Zen3 support LBR:
      $ cat proc/cpuinfo | grep " brs"
      # To see if Zen4 support LBR:
      $ cat proc/cpuinfo | grep amd_lbr_v2
      # If the result is yes, then collect the profile using:
      $ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a \
        -N -b -c &lt;count&gt; -o &lt;perf_file&gt; -- &lt;loadtest&gt;

4) (Optional) Download the raw perf file to the host machine.

5) Generate Propeller profile:
   $ create_llvm_prof --binary=&lt;vmlinux&gt; --profile=&lt;perf_file&gt; \
     --format=propeller --propeller_output_module_name \
     --out=&lt;propeller_profile_prefix&gt;_cc_profile.txt \
     --propeller_symorder=&lt;propeller_profile_prefix&gt;_ld_profile.txt

   “create_llvm_prof” is the profile conversion tool, and a prebuilt
   binary for linux can be found on
   https://github.com/google/autofdo/releases/tag/v0.30.1 (can also build
   from source).

   "&lt;propeller_profile_prefix&gt;" can be something like
   "/home/user/dir/any_string".

   This command generates a pair of Propeller profiles:
   "&lt;propeller_profile_prefix&gt;_cc_profile.txt" and
   "&lt;propeller_profile_prefix&gt;_ld_profile.txt".

6) Rebuild the kernel using the AutoFDO and Propeller profile files.
      CONFIG_AUTOFDO_CLANG=y
      CONFIG_PROPELLER_CLANG=y
   and
      $ make LLVM=1 CLANG_AUTOFDO_PROFILE=&lt;autofdo_profile&gt; \
        CLANG_PROPELLER_PROFILE_PREFIX=&lt;propeller_profile_prefix&gt;

Co-developed-by: Han Shen &lt;shenhan@google.com&gt;
Signed-off-by: Han Shen &lt;shenhan@google.com&gt;
Signed-off-by: Rong Xu &lt;xur@google.com&gt;
Suggested-by: Sriraman Tallam &lt;tmsriram@google.com&gt;
Suggested-by: Krzysztof Pszeniczny &lt;kpszeniczny@google.com&gt;
Suggested-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Suggested-by: Stephane Eranian &lt;eranian@google.com&gt;
Tested-by: Yonghong Song &lt;yonghong.song@linux.dev&gt;
Tested-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Reviewed-by: Kees Cook &lt;kees@kernel.org&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: Add AutoFDO support for Clang build</title>
<updated>2024-11-06T13:41:09Z</updated>
<author>
<name>Rong Xu</name>
<email>xur@google.com</email>
</author>
<published>2024-11-02T17:51:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=315ad8780a129e82e2c5c65ee6e970d91a577acb'/>
<id>urn:sha1:315ad8780a129e82e2c5c65ee6e970d91a577acb</id>
<content type='text'>
Add the build support for using Clang's AutoFDO. Building the kernel
with AutoFDO does not reduce the optimization level from the
compiler. AutoFDO uses hardware sampling to gather information about
the frequency of execution of different code paths within a binary.
This information is then used to guide the compiler's optimization
decisions, resulting in a more efficient binary. Experiments
showed that the kernel can improve up to 10% in latency.

The support requires a Clang compiler after LLVM 17. This submission
is limited to x86 platforms that support PMU features like LBR on
Intel machines and AMD Zen3 BRS. Support for SPE on ARM 1,
 and BRBE on ARM 1 is part of planned future work.

Here is an example workflow for AutoFDO kernel:

1) Build the kernel on the host machine with LLVM enabled, for example,
       $ make menuconfig LLVM=1
    Turn on AutoFDO build config:
      CONFIG_AUTOFDO_CLANG=y
    With a configuration that has LLVM enabled, use the following
    command:
       scripts/config -e AUTOFDO_CLANG
    After getting the config, build with
      $ make LLVM=1

2) Install the kernel on the test machine.

3) Run the load tests. The '-c' option in perf specifies the sample
   event period. We suggest     using a suitable prime number,
   like 500009, for this purpose.
   For Intel platforms:
      $ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c &lt;count&gt; \
        -o &lt;perf_file&gt; -- &lt;loadtest&gt;
   For AMD platforms:
      The supported system are: Zen3 with BRS, or Zen4 with amd_lbr_v2
     For Zen3:
      $ cat proc/cpuinfo | grep " brs"
      For Zen4:
      $ cat proc/cpuinfo | grep amd_lbr_v2
      $ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a \
        -N -b -c &lt;count&gt; -o &lt;perf_file&gt; -- &lt;loadtest&gt;

4) (Optional) Download the raw perf file to the host machine.

5) To generate an AutoFDO profile, two offline tools are available:
   create_llvm_prof and llvm_profgen. The create_llvm_prof tool is part
   of the AutoFDO project and can be found on GitHub
   (https://github.com/google/autofdo), version v0.30.1 or later. The
   llvm_profgen tool is included in the LLVM compiler itself. It's
   important to note that the version of llvm_profgen doesn't need to
   match the version of Clang. It needs to be the LLVM 19 release or
   later, or from the LLVM trunk.
      $ llvm-profgen --kernel --binary=&lt;vmlinux&gt; --perfdata=&lt;perf_file&gt; \
        -o &lt;profile_file&gt;
   or
      $ create_llvm_prof --binary=&lt;vmlinux&gt; --profile=&lt;perf_file&gt; \
        --format=extbinary --out=&lt;profile_file&gt;

   Note that multiple AutoFDO profile files can be merged into one via:
      $ llvm-profdata merge -o &lt;profile_file&gt;  &lt;profile_1&gt; ... &lt;profile_n&gt;

6) Rebuild the kernel using the AutoFDO profile file with the same config
   as step 1, (Note CONFIG_AUTOFDO_CLANG needs to be enabled):
      $ make LLVM=1 CLANG_AUTOFDO_PROFILE=&lt;profile_file&gt;

Co-developed-by: Han Shen &lt;shenhan@google.com&gt;
Signed-off-by: Han Shen &lt;shenhan@google.com&gt;
Signed-off-by: Rong Xu &lt;xur@google.com&gt;
Suggested-by: Sriraman Tallam &lt;tmsriram@google.com&gt;
Suggested-by: Krzysztof Pszeniczny &lt;kpszeniczny@google.com&gt;
Suggested-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Suggested-by: Stephane Eranian &lt;eranian@google.com&gt;
Tested-by: Yonghong Song &lt;yonghong.song@linux.dev&gt;
Tested-by: Yabin Cui &lt;yabinc@google.com&gt;
Tested-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Reviewed-by: Kees Cook &lt;kees@kernel.org&gt;
Tested-by: Peter Jung &lt;ptr1337@cachyos.org&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'rust-6.12' of https://github.com/Rust-for-Linux/linux</title>
<updated>2024-09-25T17:25:40Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-09-25T17:25:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=570172569238c66a482ec3eb5d766cc9cf255f69'/>
<id>urn:sha1:570172569238c66a482ec3eb5d766cc9cf255f69</id>
<content type='text'>
Pull Rust updates from Miguel Ojeda:
 "Toolchain and infrastructure:

   - Support 'MITIGATION_{RETHUNK,RETPOLINE,SLS}' (which cleans up
     objtool warnings), teach objtool about 'noreturn' Rust symbols and
     mimic '___ADDRESSABLE()' for 'module_{init,exit}'. With that, we
     should be objtool-warning-free, so enable it to run for all Rust
     object files.

   - KASAN (no 'SW_TAGS'), KCFI and shadow call sanitizer support.

   - Support 'RUSTC_VERSION', including re-config and re-build on
     change.

   - Split helpers file into several files in a folder, to avoid
     conflicts in it. Eventually those files will be moved to the right
     places with the new build system. In addition, remove the need to
     manually export the symbols defined there, reusing existing
     machinery for that.

   - Relax restriction on configurations with Rust + GCC plugins to just
     the RANDSTRUCT plugin.

  'kernel' crate:

   - New 'list' module: doubly-linked linked list for use with reference
     counted values, which is heavily used by the upcoming Rust Binder.

     This includes 'ListArc' (a wrapper around 'Arc' that is guaranteed
     unique for the given ID), 'AtomicTracker' (tracks whether a
     'ListArc' exists using an atomic), 'ListLinks' (the prev/next
     pointers for an item in a linked list), 'List' (the linked list
     itself), 'Iter' (an iterator over a 'List'), 'Cursor' (a cursor
     into a 'List' that allows to remove elements), 'ListArcField' (a
     field exclusively owned by a 'ListArc'), as well as support for
     heterogeneous lists.

   - New 'rbtree' module: red-black tree abstractions used by the
     upcoming Rust Binder.

     This includes 'RBTree' (the red-black tree itself), 'RBTreeNode' (a
     node), 'RBTreeNodeReservation' (a memory reservation for a node),
     'Iter' and 'IterMut' (immutable and mutable iterators), 'Cursor'
     (bidirectional cursor that allows to remove elements), as well as
     an entry API similar to the Rust standard library one.

   - 'init' module: add 'write_[pin_]init' methods and the
     'InPlaceWrite' trait. Add the 'assert_pinned!' macro.

   - 'sync' module: implement the 'InPlaceInit' trait for 'Arc' by
     introducing an associated type in the trait.

   - 'alloc' module: add 'drop_contents' method to 'BoxExt'.

   - 'types' module: implement the 'ForeignOwnable' trait for
     'Pin&lt;Box&lt;T&gt;&gt;' and improve the trait's documentation. In addition,
     add the 'into_raw' method to the 'ARef' type.

   - 'error' module: in preparation for the upcoming Rust support for
     32-bit architectures, like arm, locally allow Clippy lint for
     those.

  Documentation:

   - https://rust.docs.kernel.org has been announced, so link to it.

   - Enable rustdoc's "jump to definition" feature, making its output a
     bit closer to the experience in a cross-referencer.

   - Debian Testing now also provides recent Rust releases (outside of
     the freeze period), so add it to the list.

  MAINTAINERS:

   - Trevor is joining as reviewer of the "RUST" entry.

  And a few other small bits"

* tag 'rust-6.12' of https://github.com/Rust-for-Linux/linux: (54 commits)
  kasan: rust: Add KASAN smoke test via UAF
  kbuild: rust: Enable KASAN support
  rust: kasan: Rust does not support KHWASAN
  kbuild: rust: Define probing macros for rustc
  kasan: simplify and clarify Makefile
  rust: cfi: add support for CFI_CLANG with Rust
  cfi: add CONFIG_CFI_ICALL_NORMALIZE_INTEGERS
  rust: support for shadow call stack sanitizer
  docs: rust: include other expressions in conditional compilation section
  kbuild: rust: replace proc macros dependency on `core.o` with the version text
  kbuild: rust: rebuild if the version text changes
  kbuild: rust: re-run Kconfig if the version text changes
  kbuild: rust: add `CONFIG_RUSTC_VERSION`
  rust: avoid `box_uninit_write` feature
  MAINTAINERS: add Trevor Gross as Rust reviewer
  rust: rbtree: add `RBTree::entry`
  rust: rbtree: add cursor
  rust: rbtree: add mutable iterator
  rust: rbtree: add iterator
  rust: rbtree: add red-black tree implementation backed by the C version
  ...
</content>
</entry>
<entry>
<title>Merge tag 'kbuild-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild</title>
<updated>2024-09-24T20:02:06Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-09-24T20:02:06Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=68e5c7d4cefb66de3953a874e670ec8f1ce86a24'/>
<id>urn:sha1:68e5c7d4cefb66de3953a874e670ec8f1ce86a24</id>
<content type='text'>
Pull Kbuild updates from Masahiro Yamada:

 - Support cross-compiling linux-headers Debian package and kernel-devel
   RPM package

 - Add support for the linux-debug Pacman package

 - Improve module rebuilding speed by factoring out the common code to
   scripts/module-common.c

 - Separate device tree build rules into scripts/Makefile.dtbs

 - Add a new script to generate modules.builtin.ranges, which is useful
   for tracing tools to find symbols in built-in modules

 - Refactor Kconfig and misc tools

 - Update Kbuild and Kconfig documentation

* tag 'kbuild-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (51 commits)
  kbuild: doc: replace "gcc" in external module description
  kbuild: doc: describe the -C option precisely for external module builds
  kbuild: doc: remove the description about shipped files
  kbuild: doc: drop section numbering, use references in modules.rst
  kbuild: doc: throw out the local table of contents in modules.rst
  kbuild: doc: remove outdated description of the limitation on -I usage
  kbuild: doc: remove description about grepping CONFIG options
  kbuild: doc: update the description about Kbuild/Makefile split
  kbuild: remove unnecessary export of RUST_LIB_SRC
  kbuild: remove append operation on cmd_ld_ko_o
  kconfig: cache expression values
  kconfig: use hash table to reuse expressions
  kconfig: refactor expr_eliminate_dups()
  kconfig: add comments to expression transformations
  kconfig: change some expr_*() functions to bool
  scripts: move hash function from scripts/kconfig/ to scripts/include/
  kallsyms: change overflow variable to bool type
  kallsyms: squash output_address()
  kbuild: add install target for modules.builtin.ranges
  scripts: add verifier script for builtin module range data
  ...
</content>
</entry>
<entry>
<title>kbuild: rust: Enable KASAN support</title>
<updated>2024-09-16T16:04:37Z</updated>
<author>
<name>Matthew Maurer</name>
<email>mmaurer@google.com</email>
</author>
<published>2024-08-20T19:48:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e3117404b41124c88a4d834fc3222669a880addc'/>
<id>urn:sha1:e3117404b41124c88a4d834fc3222669a880addc</id>
<content type='text'>
Rust supports KASAN via LLVM, but prior to this patch, the flags aren't
set properly.

Suggested-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
Signed-off-by: Matthew Maurer &lt;mmaurer@google.com&gt;
Reviewed-by: Andrey Konovalov &lt;andreyknvl@gmail.com&gt;
Link: https://lore.kernel.org/r/20240820194910.187826-4-mmaurer@google.com
[ Applied "SW_TAGS KASAN" nit. - Miguel ]
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</content>
</entry>
</feed>
