<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/tools/include/linux, branch v5.15.215</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.215</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.215'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-07-24T13:51:56+00:00</updated>
<entry>
<title>bitops: make BYTES_TO_BITS() treewide-available</title>
<updated>2026-07-24T13:51:56+00:00</updated>
<author>
<name>Alexander Lobakin</name>
<email>aleksander.lobakin@intel.com</email>
</author>
<published>2026-07-14T02:09:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d4989777a1141af847c0332543c6029d7da81911'/>
<id>urn:sha1:d4989777a1141af847c0332543c6029d7da81911</id>
<content type='text'>
[ Upstream commit 7d8296b250f2eed73f1758607926d4d258dea5d4 ]

Avoid open-coding that simple expression each time by moving
BYTES_TO_BITS() from the probes code to &lt;linux/bitops.h&gt; to export
it to the rest of the kernel.
Simplify the macro while at it. `BITS_PER_LONG / sizeof(long)` always
equals to %BITS_PER_BYTE, regardless of the target architecture.
Do the same for the tools ecosystem as well (incl. its version of
bitops.h). The previous implementation had its implicit type of long,
while the new one is int, so adjust the format literal accordingly in
the perf code.

Suggested-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Przemek Kitszel &lt;przemyslaw.kitszel@intel.com&gt;
Acked-by: Yury Norov &lt;yury.norov@gmail.com&gt;
Signed-off-by: Alexander Lobakin &lt;aleksander.lobakin@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Stable-dep-of: 55052184ac90 ("iio: common: st_sensors: honour channel endianness in read_axis_data")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>XArray: Add calls to might_alloc()</title>
<updated>2025-08-28T14:24:13+00:00</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2022-07-06T18:51:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=461125e8f46c32b220fac9656ef279e1e5abf740'/>
<id>urn:sha1:461125e8f46c32b220fac9656ef279e1e5abf740</id>
<content type='text'>
[ Upstream commit 1dd685c414a7b9fdb3d23aca3aedae84f0b998ae ]

Catch bogus GFP flags deterministically, instead of occasionally
when we actually have to allocate memory.

Reported-by: Nikolay Borisov &lt;nborisov@suse.com&gt;
Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Stable-dep-of: 99765233ab42 ("NFS: Fixup allocation flags for nfsiod's __GFP_NORETRY")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools: move alignment-related macros to new &lt;linux/align.h&gt;</title>
<updated>2024-09-04T11:23:37+00:00</updated>
<author>
<name>Alexander Lobakin</name>
<email>aleksander.lobakin@intel.com</email>
</author>
<published>2024-03-27T15:23:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ce0aa899c9099a1ba3bbc8a23d543d06973b51a4'/>
<id>urn:sha1:ce0aa899c9099a1ba3bbc8a23d543d06973b51a4</id>
<content type='text'>
commit 10a04ff09bcc39e0044190ffe9f00f998f13647c upstream.

Currently, tools have *ALIGN*() macros scattered across the unrelated
headers, as there are only 3 of them and they were added separately
each time on an as-needed basis.
Anyway, let's make it more consistent with the kernel headers and allow
using those macros outside of the mentioned headers. Create
&lt;linux/align.h&gt; inside the tools/ folder and include it where needed.

Signed-off-by: Yury Norov &lt;yury.norov@gmail.com&gt;
Signed-off-by: Alexander Lobakin &lt;aleksander.lobakin@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bitmap: introduce generic optimized bitmap_size()</title>
<updated>2024-09-04T11:23:16+00:00</updated>
<author>
<name>Alexander Lobakin</name>
<email>aleksander.lobakin@intel.com</email>
</author>
<published>2024-03-27T15:23:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0f00902172b26d756c43c62968affae74fe0bde4'/>
<id>urn:sha1:0f00902172b26d756c43c62968affae74fe0bde4</id>
<content type='text'>
commit a37fbe666c016fd89e4460d0ebfcea05baba46dc upstream.

The number of times yet another open coded
`BITS_TO_LONGS(nbits) * sizeof(long)` can be spotted is huge.
Some generic helper is long overdue.

Add one, bitmap_size(), but with one detail.
BITS_TO_LONGS() uses DIV_ROUND_UP(). The latter works well when both
divident and divisor are compile-time constants or when the divisor
is not a pow-of-2. When it is however, the compilers sometimes tend
to generate suboptimal code (GCC 13):

48 83 c0 3f          	add    $0x3f,%rax
48 c1 e8 06          	shr    $0x6,%rax
48 8d 14 c5 00 00 00 00	lea    0x0(,%rax,8),%rdx

%BITS_PER_LONG is always a pow-2 (either 32 or 64), but GCC still does
full division of `nbits + 63` by it and then multiplication by 8.
Instead of BITS_TO_LONGS(), use ALIGN() and then divide by 8. GCC:

8d 50 3f             	lea    0x3f(%rax),%edx
c1 ea 03             	shr    $0x3,%edx
81 e2 f8 ff ff 1f    	and    $0x1ffffff8,%edx

Now it shifts `nbits + 63` by 3 positions (IOW performs fast division
by 8) and then masks bits[2:0]. bloat-o-meter:

add/remove: 0/0 grow/shrink: 20/133 up/down: 156/-773 (-617)

Clang does it better and generates the same code before/after starting
from -O1, except that with the ALIGN() approach it uses %edx and thus
still saves some bytes:

add/remove: 0/0 grow/shrink: 9/133 up/down: 18/-538 (-520)

Note that we can't expand DIV_ROUND_UP() by adding a check and using
this approach there, as it's used in array declarations where
expressions are not allowed.
Add this helper to tools/ as well.

Reviewed-by: Przemek Kitszel &lt;przemyslaw.kitszel@intel.com&gt;
Acked-by: Yury Norov &lt;yury.norov@gmail.com&gt;
Signed-off-by: Alexander Lobakin &lt;aleksander.lobakin@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bpf: Fix BTF_ID symbol generation collision in tools/</title>
<updated>2023-10-06T11:18:23+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2023-09-15T17:34:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=132a5ae4136b3f244bfc55589bee6eddc234e569'/>
<id>urn:sha1:132a5ae4136b3f244bfc55589bee6eddc234e569</id>
<content type='text'>
commit c0bb9fb0e52a64601d38b3739b729d9138d4c8a1 upstream.

Marcus and Satya reported an issue where BTF_ID macro generates same
symbol in separate objects and that breaks final vmlinux link.

  ld.lld: error: ld-temp.o &lt;inline asm&gt;:14577:1: symbol
  '__BTF_ID__struct__cgroup__624' is already defined

This can be triggered under specific configs when __COUNTER__ happens to
be the same for the same symbol in two different translation units,
which is already quite unlikely to happen.

Add __LINE__ number suffix to make BTF_ID symbol more unique, which is
not a complete fix, but it would help for now and meanwhile we can work
on better solution as suggested by Andrii.

Cc: stable@vger.kernel.org
Reported-by: Satya Durga Srinivasu Prabhala &lt;quic_satyap@quicinc.com&gt;
Reported-by: Marcus Seyfarth &lt;m.seyfarth@gmail.com&gt;
Closes: https://github.com/ClangBuiltLinux/linux/issues/1913
Debugged-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Co-developed-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Link: https://lore.kernel.org/bpf/CAEf4Bzb5KQ2_LmhN769ifMeSJaWfebccUasQOfQKaOd0nQ51tw@mail.gmail.com/
Signed-off-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Link: https://lore.kernel.org/r/20230915-bpf_collision-v3-2-263fc519c21f@google.com
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>x86/ibt: Add ANNOTATE_NOENDBR</title>
<updated>2023-08-26T12:23:39+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2022-03-08T15:30:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f624ce6c7fc27468cb52623222ed61921822edc0'/>
<id>urn:sha1:f624ce6c7fc27468cb52623222ed61921822edc0</id>
<content type='text'>
[ Upstream commit c8c301abeae58ec756b8fcb2178a632bd3c9e284 ]

In order to have objtool warn about code references to !ENDBR
instruction, we need an annotation to allow this for non-control-flow
instances -- consider text range checks, text patching, or return
trampolines etc.

Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Link: https://lore.kernel.org/r/20220308154317.578968224@infradead.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>objtool: Add frame-pointer-specific function ignore</title>
<updated>2023-08-26T12:23:38+00:00</updated>
<author>
<name>Josh Poimboeuf</name>
<email>jpoimboe@redhat.com</email>
</author>
<published>2021-09-14T14:41:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f1171d455d94f15ae70b8965b82c3f039f187a63'/>
<id>urn:sha1:f1171d455d94f15ae70b8965b82c3f039f187a63</id>
<content type='text'>
[ Upstream commit e028c4f7ac7ca8c96126fe46c54ab3d56ffe6a66 ]

Add a CONFIG_FRAME_POINTER-specific version of
STACK_FRAME_NON_STANDARD() for the case where a function is
intentionally missing frame pointer setup, but otherwise needs
objtool/ORC coverage when frame pointers are disabled.

Link: https://lkml.kernel.org/r/163163047364.489837.17377799909553689661.stgit@devnote2

Signed-off-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Reviewed-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Tested-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Stable-dep-of: c8c301abeae5 ("x86/ibt: Add ANNOTATE_NOENDBR")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools: fix ARRAY_SIZE defines in tools and selftests hdrs</title>
<updated>2023-02-06T06:59:01+00:00</updated>
<author>
<name>Shuah Khan</name>
<email>skhan@linuxfoundation.org</email>
</author>
<published>2021-12-08T17:47:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c9e52db90031b7a89bf667057df5ca9c25cd68ff'/>
<id>urn:sha1:c9e52db90031b7a89bf667057df5ca9c25cd68ff</id>
<content type='text'>
commit 066b34aa5461f6072dbbecb690f4fe446b736ebf upstream.

tools/include/linux/kernel.h and kselftest_harness.h are missing
ifndef guard around ARRAY_SIZE define. Fix them to avoid duplicate
define errors during compile when another file defines it. This
problem was found when compiling selftests that include a header
with ARRAY_SIZE define.

ARRAY_SIZE is defined in several selftests. There are about 25+
duplicate defines in various selftests source and header files.
Add ARRAY_SIZE to kselftest.h in preparation for removing duplicate
ARRAY_SIZE defines from individual test files.

Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Cc: Kyle Huey &lt;me@kylehuey.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tools/include: Add _RET_IP_ and math definitions to kernel.h</title>
<updated>2022-12-31T12:14:44+00:00</updated>
<author>
<name>Karolina Drobnik</name>
<email>karolinadrobnik@gmail.com</email>
</author>
<published>2022-12-23T00:09:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6215904fe29537067ff938fae1732b204abf8ea7'/>
<id>urn:sha1:6215904fe29537067ff938fae1732b204abf8ea7</id>
<content type='text'>
commit 5cf67a6051ea2558fd7c3d39c5a808db73073e9d upstream.

Add max_t, min_t and clamp functions, together with _RET_IP_
definition, so they can be used in testing.

Signed-off-by: Karolina Drobnik &lt;karolinadrobnik@gmail.com&gt;
Signed-off-by: Mike Rapoport &lt;rppt@kernel.org&gt;
Link: https://lore.kernel.org/r/230fea382cb1e1659cdd52a55201854d38a0a149.1643796665.git.karolinadrobnik@gmail.com
[tyhicks: Backport around contextual differences due to the lack of v5.16 commit
 d6e6a27d960f ("tools: Fix math.h breakage"). That commit fixed a commit
 that was merged in v5.16-rc1 and, therefore, doesn't need to go back to
 the stable branches.]
Signed-off-by: Tyler Hicks (Microsoft) &lt;code@tyhicks.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>objtool: Re-add UNWIND_HINT_{SAVE_RESTORE}</title>
<updated>2022-07-23T10:54:08+00:00</updated>
<author>
<name>Josh Poimboeuf</name>
<email>jpoimboe@kernel.org</email>
</author>
<published>2022-06-24T10:52:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c590fa2d2dac50e9e1ea6946506636617b2f8694'/>
<id>urn:sha1:c590fa2d2dac50e9e1ea6946506636617b2f8694</id>
<content type='text'>
commit 8faea26e611189e933ea2281975ff4dc7c1106b6 upstream.

Commit

  c536ed2fffd5 ("objtool: Remove SAVE/RESTORE hints")

removed the save/restore unwind hints because they were no longer
needed. Now they're going to be needed again so re-add them.

Signed-off-by: Josh Poimboeuf &lt;jpoimboe@kernel.org&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thadeu Lima de Souza Cascardo &lt;cascardo@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
