<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/s390/kernel/debug.c, branch master</title>
<subtitle>Linux kernel mainline source</subtitle>
<id>http://mirrors.hust.edu.cn/git/linux.git/atom?h=master</id>
<link rel='self' href='http://mirrors.hust.edu.cn/git/linux.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/'/>
<updated>2026-05-26T06:15:39+00:00</updated>
<entry>
<title>s390/debug: Remove s390dbf_sysctl_header variable</title>
<updated>2026-05-26T06:15:39+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>hca@linux.ibm.com</email>
</author>
<published>2026-05-19T06:20:40+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/commit/?id=3f90f58eb7979a3145a65071f597942e7cbc04e5'/>
<id>urn:sha1:3f90f58eb7979a3145a65071f597942e7cbc04e5</id>
<content type='text'>
allmodconfig with clang W=1 points out an unused global variable:

arch/s390/kernel/debug.c:1237:33: error: variable
 's390dbf_sysctl_header' set but not used [-Werror,-Wunused-but-set-global]

Just remove the variable. There is no point in adding error handling for a
failing register_sysctl() call.

Reviewed-by: Christian Borntraeger &lt;borntraeger@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/debug: Add s390dbf kernel parameter</title>
<updated>2026-05-11T14:42:31+00:00</updated>
<author>
<name>Peter Oberparleiter</name>
<email>oberpar@linux.ibm.com</email>
</author>
<published>2026-05-06T14:53:27+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/commit/?id=a2cec6863709d6673a025acc066c962b85a75842'/>
<id>urn:sha1:a2cec6863709d6673a025acc066c962b85a75842</id>
<content type='text'>
Problem determination using s390dbf logging sometimes requires changing
the default logging level or log area size. While this is possible
using sysfs interfaces, there is no easy way to adjust these parameters
for early boot code that emits logs before userspace is available.

Add an s390dbf kernel parameter to address this shortcoming. The
parameter can be used to specify log level and area size (in units of
pages). A level of '-' turns logging off for an area. Logs can be
identified by name or a shell-style pattern.

Parameter format:

  s390dbf=&lt;name|pattern&gt;:[&lt;level&gt;|-]:[&lt;pages&gt;][,...]

Example:

  s390dbf=cio*:6:128,sclp_err::2

Specified parameters are applied immediately during debug area
registration for regular log areas. For early, static debug areas,
log levels are changed during early_param() parsing, while size
changes are applied at arch_initcall-time.

Signed-off-by: Peter Oberparleiter &lt;oberpar@linux.ibm.com&gt;
Tested-by: Vineeth Vijayan &lt;vneethv@linux.ibm.com&gt;
Reviewed-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/debug: Reject zero-length input in debug_input_flush_fn()</title>
<updated>2026-04-28T12:45:02+00:00</updated>
<author>
<name>Vasily Gorbik</name>
<email>gor@linux.ibm.com</email>
</author>
<published>2026-04-17T12:33:43+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/commit/?id=e14622a7584f9608927c59a7d6ae4a0999dc545e'/>
<id>urn:sha1:e14622a7584f9608927c59a7d6ae4a0999dc545e</id>
<content type='text'>
debug_input_flush_fn() always copies one byte from the userspace buffer
with copy_from_user() regardless of the supplied write length. A
zero-length write therefore reads one byte beyond the caller's buffer.
If the stale byte happens to be '-' or a digit the debug log is
silently flushed. With an unmapped buffer the call returns -EFAULT.

Reject zero-length writes before copying from userspace.

Cc: stable@vger.kernel.org # v5.10+
Acked-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/debug: Reject zero-length input before trimming a newline</title>
<updated>2026-04-28T12:45:02+00:00</updated>
<author>
<name>Pengpeng Hou</name>
<email>pengpeng@iscas.ac.cn</email>
</author>
<published>2026-04-17T07:35:30+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/commit/?id=c366a7b5ed7564e41345c380285bd3f6cb98971b'/>
<id>urn:sha1:c366a7b5ed7564e41345c380285bd3f6cb98971b</id>
<content type='text'>
debug_get_user_string() duplicates the userspace buffer with
memdup_user_nul() and then unconditionally looks at buffer[user_len - 1]
to strip a trailing newline.

A zero-length write reaches this helper unchanged, so the newline trim
reads before the start of the allocated buffer.

Reject empty writes before accessing the last input byte.

Fixes: 66a464dbc8e0 ("[PATCH] s390: debug feature changes")
Cc: stable@vger.kernel.org
Signed-off-by: Pengpeng Hou &lt;pengpeng@iscas.ac.cn&gt;
Reviewed-by: Benjamin Block &lt;bblock@linux.ibm.com&gt;
Reviewed-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Tested-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20260417073530.96002-1-pengpeng@iscas.ac.cn
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>Convert 'alloc_obj' family to use the new default GFP_KERNEL argument</title>
<updated>2026-02-22T01:09:51+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2026-02-22T00:37:42+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/commit/?id=bf4afc53b77aeaa48b5409da5c8da6bb4eff7f43'/>
<id>urn:sha1:bf4afc53b77aeaa48b5409da5c8da6bb4eff7f43</id>
<content type='text'>
This was done entirely with mindless brute force, using

    git grep -l '\&lt;k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
        xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'

to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.

Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.

For the same reason the 'flex' versions will be done as a separate
conversion.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>treewide: Replace kmalloc with kmalloc_obj for non-scalar types</title>
<updated>2026-02-21T09:02:28+00:00</updated>
<author>
<name>Kees Cook</name>
<email>kees@kernel.org</email>
</author>
<published>2026-02-21T07:49:23+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/commit/?id=69050f8d6d075dc01af7a5f2f550a8067510366f'/>
<id>urn:sha1:69050f8d6d075dc01af7a5f2f550a8067510366f</id>
<content type='text'>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations:	kmalloc(sizeof(TYPE), ...)
are replaced with:	kmalloc_obj(TYPE, ...)

Array allocations:	kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with:	kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations:	kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with:	kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook &lt;kees@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/debug: Convert debug area lock from a spinlock to a raw spinlock</title>
<updated>2026-02-18T14:22:59+00:00</updated>
<author>
<name>Benjamin Block</name>
<email>bblock@linux.ibm.com</email>
</author>
<published>2026-02-17T13:29:12+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/commit/?id=3ce500aac0e71f71b358fe68aa69f0912047968c'/>
<id>urn:sha1:3ce500aac0e71f71b358fe68aa69f0912047968c</id>
<content type='text'>
With PREEMPT_RT as potential configuration option, spinlock_t is now
considered as a sleeping lock, and thus might cause issues when used in
an atomic context. But even with PREEMPT_RT as potential configuration
option, raw_spinlock_t remains as a true spinning lock/atomic context.
This creates potential issues with the s390 debug/tracing feature. The
functions to trace errors are called in various contexts, including
under lock of raw_spinlock_t, and thus the used spinlock_t in each debug
area is in violation of the locking semantics.

Here are two examples involving failing PCI Read accesses that are
traced while holding `pci_lock` in `drivers/pci/access.c`:

=============================
[ BUG: Invalid wait context ]
6.19.0-devel #18 Not tainted
-----------------------------
bash/3833 is trying to lock:
0000027790baee30 (&amp;rc-&gt;lock){-.-.}-{3:3}, at: debug_event_common+0xfc/0x300
other info that might help us debug this:
context-{5:5}
5 locks held by bash/3833:
 #0: 0000027efbb29450 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x7c/0xf0
 #1: 00000277f0504a90 (&amp;of-&gt;mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x13e/0x260
 #2: 00000277beed8c18 (kn-&gt;active#339){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x164/0x260
 #3: 00000277e9859190 (&amp;dev-&gt;mutex){....}-{4:4}, at: pci_dev_lock+0x2e/0x40
 #4: 00000383068a7708 (pci_lock){....}-{2:2}, at: pci_bus_read_config_dword+0x4a/0xb0
stack backtrace:
CPU: 6 UID: 0 PID: 3833 Comm: bash Kdump: loaded Not tainted 6.19.0-devel #18 PREEMPTLAZY
Hardware name: IBM 9175 ME1 701 (LPAR)
Call Trace:
 [&lt;00000383048afec2&gt;] dump_stack_lvl+0xa2/0xe8
 [&lt;00000383049ba166&gt;] __lock_acquire+0x816/0x1660
 [&lt;00000383049bb1fa&gt;] lock_acquire+0x24a/0x370
 [&lt;00000383059e3860&gt;] _raw_spin_lock_irqsave+0x70/0xc0
 [&lt;00000383048bbb6c&gt;] debug_event_common+0xfc/0x300
 [&lt;0000038304900b0a&gt;] __zpci_load+0x17a/0x1f0
 [&lt;00000383048fad88&gt;] pci_read+0x88/0xd0
 [&lt;00000383054cbce0&gt;] pci_bus_read_config_dword+0x70/0xb0
 [&lt;00000383054d55e4&gt;] pci_dev_wait+0x174/0x290
 [&lt;00000383054d5a3e&gt;] __pci_reset_function_locked+0xfe/0x170
 [&lt;00000383054d9b30&gt;] pci_reset_function+0xd0/0x100
 [&lt;00000383054ee21a&gt;] reset_store+0x5a/0x80
 [&lt;0000038304e98758&gt;] kernfs_fop_write_iter+0x1e8/0x260
 [&lt;0000038304d995da&gt;] new_sync_write+0x13a/0x180
 [&lt;0000038304d9c5d0&gt;] vfs_write+0x200/0x330
 [&lt;0000038304d9c88c&gt;] ksys_write+0x7c/0xf0
 [&lt;00000383059cfa80&gt;] __do_syscall+0x210/0x500
 [&lt;00000383059e4c06&gt;] system_call+0x6e/0x90
INFO: lockdep is turned off.

=============================
[ BUG: Invalid wait context ]
6.19.0-devel #3 Not tainted
-----------------------------
bash/6861 is trying to lock:
0000009da05c7430 (&amp;rc-&gt;lock){-.-.}-{3:3}, at: debug_event_common+0xfc/0x300
other info that might help us debug this:
context-{5:5}
5 locks held by bash/6861:
 #0: 000000acff404450 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x7c/0xf0
 #1: 000000acff41c490 (&amp;of-&gt;mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x13e/0x260
 #2: 0000009da36937d8 (kn-&gt;active#75){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x164/0x260
 #3: 0000009dd15250d0 (&amp;zdev-&gt;state_lock){+.+.}-{4:4}, at: enable_slot+0x2e/0xc0
 #4: 000001a19682f708 (pci_lock){....}-{2:2}, at: pci_bus_read_config_byte+0x42/0xa0
stack backtrace:
CPU: 16 UID: 0 PID: 6861 Comm: bash Kdump: loaded Not tainted 6.19.0-devel #3 PREEMPTLAZY
Hardware name: IBM 9175 ME1 701 (LPAR)
Call Trace:
 [&lt;000001a194837ec2&gt;] dump_stack_lvl+0xa2/0xe8
 [&lt;000001a194942166&gt;] __lock_acquire+0x816/0x1660
 [&lt;000001a1949431fa&gt;] lock_acquire+0x24a/0x370
 [&lt;000001a19596b810&gt;] _raw_spin_lock_irqsave+0x70/0xc0
 [&lt;000001a194843b6c&gt;] debug_event_common+0xfc/0x300
 [&lt;000001a194888b0a&gt;] __zpci_load+0x17a/0x1f0
 [&lt;000001a194882d88&gt;] pci_read+0x88/0xd0
 [&lt;000001a195453b88&gt;] pci_bus_read_config_byte+0x68/0xa0
 [&lt;000001a195457bc2&gt;] pci_setup_device+0x62/0xad0
 [&lt;000001a195458e70&gt;] pci_scan_single_device+0x90/0xe0
 [&lt;000001a19488a0f6&gt;] zpci_bus_scan_device+0x46/0x80
 [&lt;000001a19547f958&gt;] enable_slot+0x98/0xc0
 [&lt;000001a19547f134&gt;] power_write_file+0xc4/0x110
 [&lt;000001a194e20758&gt;] kernfs_fop_write_iter+0x1e8/0x260
 [&lt;000001a194d215da&gt;] new_sync_write+0x13a/0x180
 [&lt;000001a194d245d0&gt;] vfs_write+0x200/0x330
 [&lt;000001a194d2488c&gt;] ksys_write+0x7c/0xf0
 [&lt;000001a195957a30&gt;] __do_syscall+0x210/0x500
 [&lt;000001a19596cbb6&gt;] system_call+0x6e/0x90
INFO: lockdep is turned off.

Since it is desired to keep it possible to create trace records in most
situations, including this particular case (failing PCI config space
accesses are relevant), convert the used spinlock_t in `struct
debug_info` to raw_spinlock_t.

The impact is small, as the debug area lock only protects bounded memory
access without external dependencies, apart from one function
debug_set_size() where kfree() is implicitly called with the lock held.
Move debug_info_free() out of this lock, to keep remove this external
dependency.

Acked-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Benjamin Block &lt;bblock@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: Remove KMSG_COMPONENT macro</title>
<updated>2025-11-24T10:45:21+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>hca@linux.ibm.com</email>
</author>
<published>2025-11-20T15:30:53+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/commit/?id=c3d17464f0262c9e3c156d4c6306e32cf530fa47'/>
<id>urn:sha1:c3d17464f0262c9e3c156d4c6306e32cf530fa47</id>
<content type='text'>
The KMSG_COMPONENT macro is a leftover of the s390 specific "kernel
message catalog" which never made it upstream.

Remove the macro in order to get rid of a pointless indirection. Replace
all users with the string it defines. In almost all cases this leads to a
simple replacement like this:

 - #define KMSG_COMPONENT "appldata"
 - #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
 + #define pr_fmt(fmt) "appldata: " fmt

Except for some special cases this is just mechanical/scripted work.

Acked-by: Thomas Richter &lt;tmricht@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/debug: Replace kmalloc() + copy_from_user() with memdup_user_nul()</title>
<updated>2025-09-09T13:03:12+00:00</updated>
<author>
<name>Thorsten Blum</name>
<email>thorsten.blum@linux.dev</email>
</author>
<published>2025-09-04T11:40:29+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/commit/?id=f5507aefc9114ced49d1ee527f63ea12ff5d7751'/>
<id>urn:sha1:f5507aefc9114ced49d1ee527f63ea12ff5d7751</id>
<content type='text'>
Replace kmalloc() followed by copy_from_user() with memdup_user_nul() to
improve and simplify debug_get_user_string(). Remove the manual
NUL-termination.

No functional changes intended.

Signed-off-by: Thorsten Blum &lt;thorsten.blum@linux.dev&gt;
Reviewed-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/debug: Fix typo in debug_sprintf_format_fn() comment</title>
<updated>2025-08-06T15:18:27+00:00</updated>
<author>
<name>Tigran Mkrtchyan</name>
<email>tigran.mkrtchyan@desy.de</email>
</author>
<published>2025-08-04T09:33:21+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux.git/commit/?id=2baf16f381decee303da406ca5a0991134260270'/>
<id>urn:sha1:2baf16f381decee303da406ca5a0991134260270</id>
<content type='text'>
Signed-off-by: Tigran Mkrtchyan &lt;tigran.mkrtchyan@desy.de&gt;
Link: https://lore.kernel.org/r/20250804093321.434674-1-tigran.mkrtchyan@desy.de
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
</content>
</entry>
</feed>
