<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux/kernel.h, branch v6.12.80</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-03-18T14:33:06+00:00</updated>
<entry>
<title>tracing: Support to dump instance traces by ftrace_dump_on_oops</title>
<updated>2024-03-18T14:33:06+00:00</updated>
<author>
<name>Huang Yiwei</name>
<email>quic_hyiwei@quicinc.com</email>
</author>
<published>2024-02-23T08:31:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=19f0423fd55c301c8edaea286e568ec657f42750'/>
<id>urn:sha1:19f0423fd55c301c8edaea286e568ec657f42750</id>
<content type='text'>
Currently ftrace only dumps the global trace buffer on an OOPs. For
debugging a production usecase, instance trace will be helpful to
check specific problems since global trace buffer may be used for
other purposes.

This patch extend the ftrace_dump_on_oops parameter to dump a specific
or multiple trace instances:

  - ftrace_dump_on_oops=0: as before -- don't dump
  - ftrace_dump_on_oops[=1]: as before -- dump the global trace buffer
  on all CPUs
  - ftrace_dump_on_oops=2 or =orig_cpu: as before -- dump the global
  trace buffer on CPU that triggered the oops
  - ftrace_dump_on_oops=&lt;instance_name&gt;: new behavior -- dump the
  tracing instance matching &lt;instance_name&gt;
  - ftrace_dump_on_oops[=2/orig_cpu],&lt;instance1_name&gt;[=2/orig_cpu],
  &lt;instrance2_name&gt;[=2/orig_cpu]: new behavior -- dump the global trace
  buffer and multiple instance buffer on all CPUs, or only dump on CPU
  that triggered the oops if =2 or =orig_cpu is given

Also, the sysctl node can handle the input accordingly.

Link: https://lore.kernel.org/linux-trace-kernel/20240223083126.1817731-1-quic_hyiwei@quicinc.com

Cc: Ross Zwisler &lt;zwisler@google.com&gt;
Cc: &lt;mhiramat@kernel.org&gt;
Cc: &lt;mark.rutland@arm.com&gt;
Cc: &lt;mcgrof@kernel.org&gt;
Cc: &lt;keescook@chromium.org&gt;
Cc: &lt;j.granados@samsung.com&gt;
Cc: &lt;mathieu.desnoyers@efficios.com&gt;
Cc: &lt;corbet@lwn.net&gt;
Signed-off-by: Huang Yiwei &lt;quic_hyiwei@quicinc.com&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>kernel.h: Move lib/cmdline.c prototypes to string.h</title>
<updated>2024-02-29T21:38:03+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2023-10-03T13:01:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57914905f3ff2212a949e7191d52d9994c2c6215'/>
<id>urn:sha1:57914905f3ff2212a949e7191d52d9994c2c6215</id>
<content type='text'>
The lib/cmdline.c is basically a set of some small string parsers
which are wide used in the kernel. Their prototypes belong to the
string.h rather then kernel.h.

Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20231003130142.2936503-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
</content>
</entry>
<entry>
<title>kernel.h: Move upper_*_bits() and lower_*_bits() to wordpart.h</title>
<updated>2024-02-29T21:38:01+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2024-02-14T17:26:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=adeb04362d74188c1e22ccb824b15a0a7b3de2f4'/>
<id>urn:sha1:adeb04362d74188c1e22ccb824b15a0a7b3de2f4</id>
<content type='text'>
The wordpart.h header is collecting APIs related to the handling
parts of the word (usually in byte granularity). The upper_*_bits()
and lower_*_bits() are good candidates to be moved to there.

This helps to clean up header dependency hell with regard to kernel.h
as the latter gathers completely unrelated stuff together and slows
down compilation (especially when it's included into other header).

Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240214172752.3605073-1-andriy.shevchenko@linux.intel.com
Reviewed-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
</content>
</entry>
<entry>
<title>kernel.h: removed REPEAT_BYTE from kernel.h</title>
<updated>2024-02-01T17:47:59+00:00</updated>
<author>
<name>Tanzir Hasan</name>
<email>tanzirh@google.com</email>
</author>
<published>2023-12-26T18:00:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=66a5c40f60f5d88ad8d47ba6a4ba05892853fa1f'/>
<id>urn:sha1:66a5c40f60f5d88ad8d47ba6a4ba05892853fa1f</id>
<content type='text'>
This patch creates wordpart.h and includes it in asm/word-at-a-time.h
for all architectures. WORD_AT_A_TIME_CONSTANTS depends on kernel.h
because of REPEAT_BYTE. Moving this to another header and including it
where necessary allows us to not include the bloated kernel.h. Making
this implicit dependency on REPEAT_BYTE explicit allows for later
improvements in the lib/string.c inclusion list.

Suggested-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Suggested-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Tanzir Hasan &lt;tanzirh@google.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Link: https://lore.kernel.org/r/20231226-libstringheader-v6-1-80aa08c7652c@google.com
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
</content>
</entry>
<entry>
<title>kernel.h: Move ARRAY_SIZE() to a separate header</title>
<updated>2023-10-03T13:28:40+00:00</updated>
<author>
<name>Alejandro Colomar</name>
<email>alx@kernel.org</email>
</author>
<published>2023-10-03T11:59:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3cd39bc3b11b8d34b7d7c961a35fdfd18b0ebf75'/>
<id>urn:sha1:3cd39bc3b11b8d34b7d7c961a35fdfd18b0ebf75</id>
<content type='text'>
Touching files so used for the kernel,
forces 'make' to recompile most of the kernel.

Having those definitions in more granular files
helps avoid recompiling so much of the kernel.

Signed-off-by: Alejandro Colomar &lt;alx@kernel.org&gt;
Reviewed-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Link: https://lore.kernel.org/r/20230817143352.132583-2-lucas.segarra.fernandez@intel.com
[andy: reduced to cover only string.h for now]
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>lib/vsprintf: split out sprintf() and friends</title>
<updated>2023-08-21T20:46:24+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2023-08-14T16:33:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39ced19b9e60f6f5b80db6b72965a8cf1982439d'/>
<id>urn:sha1:39ced19b9e60f6f5b80db6b72965a8cf1982439d</id>
<content type='text'>
Patch series "lib/vsprintf: Rework header inclusions", v3.

Some patches that reduce the mess with the header inclusions related to
vsprintf.c module.  Each patch has its own description, and has no
dependencies to each other, except the collisions over modifications of
the same places.  Hence the series.


This patch (of 2):

kernel.h is being used as a dump for all kinds of stuff for a long time. 
sprintf() and friends are used in many drivers without need of the full
kernel.h dependency train with it.

Here is the attempt on cleaning it up by splitting out sprintf() and
friends.

Link: https://lkml.kernel.org/r/20230814163344.17429-1-andriy.shevchenko@linux.intel.com
Link: https://lkml.kernel.org/r/20230814163344.17429-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Petr Mladek &lt;pmladek@suse.com&gt;
Cc: Alexander Potapenko &lt;glider@google.com&gt;
Cc: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: Marco Elver &lt;elver@google.com&gt;
Cc: Rasmus Villemoes &lt;linux@rasmusvillemoes.dk&gt;
Cc: Sergey Senozhatsky &lt;senozhatsky@chromium.org&gt;
Cc: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>kernel.h: split out COUNT_ARGS() and CONCATENATE() to args.h</title>
<updated>2023-08-18T17:18:56+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2023-07-18T21:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b229baa374dbb1bb47dccad2cc8887d9438ca3e7'/>
<id>urn:sha1:b229baa374dbb1bb47dccad2cc8887d9438ca3e7</id>
<content type='text'>
Patch series "kernel.h: Split out a couple of macros to args.h", v4.

There are macros in kernel.h that can be used outside of that header. 
Split them to args.h and replace open coded variants.


This patch (of 4):

kernel.h is being used as a dump for all kinds of stuff for a long time. 
The COUNT_ARGS() and CONCATENATE() macros may be used in some places
without need of the full kernel.h dependency train with it.

Here is the attempt on cleaning it up by splitting out these macros().

While at it, include new header where it's being used.

Link: https://lkml.kernel.org/r/20230718211147.18647-1-andriy.shevchenko@linux.intel.com
Link: https://lkml.kernel.org/r/20230718211147.18647-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;	[PCI]
Cc: Brendan Higgins &lt;brendan.higgins@linux.dev&gt;
Cc: Daniel Latypov &lt;dlatypov@google.com&gt;
Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: David Gow &lt;davidgow@google.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Lorenzo Pieralisi &lt;lpieralisi@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Masami Hiramatsu (Google) &lt;mhiramat@kernel.org&gt;
Cc: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Cc: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>kernel.h: split the hexadecimal related helpers to hex.h</title>
<updated>2023-04-08T20:45:38+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2023-03-23T15:50:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=890a3ee3ce416e2f1aed41718a8c1d42c82cf1b2'/>
<id>urn:sha1:890a3ee3ce416e2f1aed41718a8c1d42c82cf1b2</id>
<content type='text'>
For the sake of cleaning up the kernel.h split the hexadecimal related
helpers to own header called 'hex.h'.

Link: https://lkml.kernel.org/r/20230323155029.40000-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Cc: Rasmus Villemoes &lt;linux@rasmusvillemoes.dk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>tracing: Always use canonical ftrace path</title>
<updated>2023-02-18T19:34:09+00:00</updated>
<author>
<name>Ross Zwisler</name>
<email>zwisler@chromium.org</email>
</author>
<published>2023-02-15T22:33:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2455f0e124d317dd08d337a7550a78a224d4ba41'/>
<id>urn:sha1:2455f0e124d317dd08d337a7550a78a224d4ba41</id>
<content type='text'>
The canonical location for the tracefs filesystem is at /sys/kernel/tracing.

But, from Documentation/trace/ftrace.rst:

  Before 4.1, all ftrace tracing control files were within the debugfs
  file system, which is typically located at /sys/kernel/debug/tracing.
  For backward compatibility, when mounting the debugfs file system,
  the tracefs file system will be automatically mounted at:

  /sys/kernel/debug/tracing

Many comments and Kconfig help messages in the tracing code still refer
to this older debugfs path, so let's update them to avoid confusion.

Link: https://lore.kernel.org/linux-trace-kernel/20230215223350.2658616-2-zwisler@google.com

Acked-by: Masami Hiramatsu (Google) &lt;mhiramat@kernel.org&gt;
Reviewed-by: Mukesh Ojha &lt;quic_mojha@quicinc.com&gt;
Signed-off-by: Ross Zwisler &lt;zwisler@google.com&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>hex2bin: make the function hex_to_bin constant-time</title>
<updated>2022-04-27T17:57:33+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2022-04-25T12:07:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e5be15767e7e284351853cbaba80cde8620341fb'/>
<id>urn:sha1:e5be15767e7e284351853cbaba80cde8620341fb</id>
<content type='text'>
The function hex2bin is used to load cryptographic keys into device
mapper targets dm-crypt and dm-integrity.  It should take constant time
independent on the processed data, so that concurrently running
unprivileged code can't infer any information about the keys via
microarchitectural convert channels.

This patch changes the function hex_to_bin so that it contains no
branches and no memory accesses.

Note that this shouldn't cause performance degradation because the size
of the new function is the same as the size of the old function (on
x86-64) - and the new function causes no branch misprediction penalties.

I compile-tested this function with gcc on aarch64 alpha arm hppa hppa64
i386 ia64 m68k mips32 mips64 powerpc powerpc64 riscv sh4 s390x sparc32
sparc64 x86_64 and with clang on aarch64 arm hexagon i386 mips32 mips64
powerpc powerpc64 s390x sparc32 sparc64 x86_64 to verify that there are
no branches in the generated code.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
