- Dec 30, 2023
-
-
Douglas Anderson authored
Patch series "watchdog: Better handling of concurrent lockups". When we get multiple lockups at roughly the same time, the output in the kernel logs can be very confusing since the reports about the lockups end up interleaved in the logs. There is some code in the kernel to try to handle this but it wasn't that complete. Li Zhe recently made this a bit better for softlockups (specifically for the case where `kernel.softlockup_all_cpu_backtrace` is not set) in commit 9d02330a ("softlockup: serialized softlockup's log"), but that only handled softlockup reports. Hardlockup reports still had similar issues. This series also has a small fix to avoid dumping all stacks a second time in the case of a panic. This is a bit unrelated to the interleaving fixes but it does also improve the clarity of lockup reports. This patch (of 4): The hardlockup detector and softlockup detector both have the ability to dump the stack of all CPUs (`kernel.hardlockup_all_cpu_backtrace` and `kernel.softlockup_all_cpu_backtrace`). Both detectors also have some logic to attempt to avoid interleaving printouts if two CPUs were trying to do dumps of all CPUs at the same time. However: - The hardlockup detector's logic still allowed interleaving some information. Specifically another CPU could print modules and dump the stack of the locked CPU at the same time we were dumping all CPUs. - In the case where `kernel.hardlockup_panic` was set in addition to `kernel.hardlockup_all_cpu_backtrace`, when two CPUs both detected hardlockups at the same time the second CPU could call panic() while the first was still dumping stacks. This was especially bad if the locked up CPU wasn't responding to the request for a backtrace since the function nmi_trigger_cpumask_backtrace() can wait up to 10 seconds. Let's resolve this by adopting the softlockup logic in the hardlockup handler. NOTES: - As part of this, one might think that we should make a helper function that both the hard and softlockup detectors call. This turns out not to be super trivial since it would have to be parameterized quite a bit since there are separate global variables controlling each lockup detector and they print log messages that are just different enough that it would be a pain. We probably don't want to change the messages that are printed without good reason to avoid throwing log parsers for a loop. - One might also think that it would be a good idea to have the hardlockup and softlockup detector use the same global variable to prevent interleaving. This would make sure that softlockups and hardlockups can't interleave each other. That _almost_ works but has a dangerous flaw if `kernel.hardlockup_panic` is not the same as `kernel.softlockup_panic` because we might skip a call to panic() if one type of lockup was detected at the same time as another. Link: https://lkml.kernel.org/r/20231220211640.2023645-1-dianders@chromium.org Link: https://lkml.kernel.org/r/20231220131534.1.I4f35a69fbb124b5f0c71f75c631e11fabbe188ff@changeid Signed-off-by:
Douglas Anderson <dianders@chromium.org> Cc: John Ogness <john.ogness@linutronix.de> Cc: Lecopzer Chen <lecopzer.chen@mediatek.com> Cc: Li Zhe <lizhe.67@bytedance.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Pingfan Liu <kernelfans@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Yuntao Wang authored
image->control_page represents the starting address for allocating the next control page, while hole_end represents the address of the last valid byte of the currently allocated control page. This bug actually does not affect the correctness of allocating control pages, because image->control_page is currently only used in kimage_alloc_crash_control_pages(), and this function, when allocating control pages, will first align image->control_page up to the nearest `(1 << order) << PAGE_SHIFT` boundary, then use this value as the starting address of the next control page. This ensures that the newly allocated control page will use the correct starting address and not overlap with previously allocated control pages. Although it does not affect the correctness of the final result, it is better for us to set image->control_page to the correct value, in case it might be used elsewhere in the future, potentially causing errors. Therefore, after successfully allocating a control page, image->control_page should be updated to `hole_end + 1`, rather than hole_end. Link: https://lkml.kernel.org/r/20231221042308.11076-1-ytcoode@gmail.com Signed-off-by:
Yuntao Wang <ytcoode@gmail.com> Cc: Baoquan He <bhe@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Yuntao Wang authored
kernel_ident_mapping_init() takes an exclusive memory range [pstart, pend) where pend is not included in the range, while res represents an inclusive memory range [start, end] where end is considered part of the range. Passing [start, end] rather than [start, end+1) to kernel_ident_mapping_init() may result in the identity mapping for the end address not being set up. For example, when res->start is equal to res->end, kernel_ident_mapping_init() will not establish any identity mapping. Similarly, when the value of res->end is a multiple of 2M and the page table maps 2M pages, kernel_ident_mapping_init() will also not set up identity mapping for res->end. Therefore, passing res->end directly to kernel_ident_mapping_init() is incorrect, the correct end address should be `res->end + 1`. Link: https://lkml.kernel.org/r/20231221101702.20956-1-ytcoode@gmail.com Signed-off-by:
-
Tanzir Hasan authored
asm-generic/io.h can be replaced with linux/io.h and the file will still build correctly. It is an asm-generic file which should be avoided if possible. Link: https://lkml.kernel.org/r/20231221-tracereadwrite-v1-1-a434f25180c7@google.com Signed-off-by:
Tanzir Hasan <tanzirh@google.com> Suggested-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Randy Dunlap authored
Correct the function parameter names for nilfs_cpfile_get_info(): cpfile.c:564: warning: Function parameter or member 'cnop' not described in 'nilfs_cpfile_get_cpinfo' cpfile.c:564: warning: Function parameter or member 'mode' not described in 'nilfs_cpfile_get_cpinfo' cpfile.c:564: warning: Function parameter or member 'buf' not described in 'nilfs_cpfile_get_cpinfo' cpfile.c:564: warning: Function parameter or member 'cisz' not described in 'nilfs_cpfile_get_cpinfo' cpfile.c:564: warning: Excess function parameter 'cno' description in 'nilfs_cpfile_get_cpinfo' cpfile.c:564: warning: Excess function parameter 'ci' description in 'nilfs_cpfile_get_cpinfo' Also add missing descriptions of the function's specification. [ konishi.ryusuke@gmail.com: filled in missing descriptions ] Link: https://lkml.kernel.org/r/20231220065931.2372-1-rdunlap@infradead.org Link: https://lkml.kernel.org/r/20231220221342.11505-1-konishi.ryusuke@gmail.com Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by:
-
Randy Dunlap authored
Change @task to @tsk to prevent kernel-doc warnings: kernel/stacktrace.c:138: warning: Excess function parameter 'task' description in 'stack_trace_save_tsk' kernel/stacktrace.c:138: warning: Function parameter or member 'tsk' not described in 'stack_trace_save_tsk' Link: https://lkml.kernel.org/r/20231220054945.17663-1-rdunlap@infradead.org Signed-off-by:
-
Kuan-Ying Lee authored
When I use older version aarch64 objdump (2.24) to disassemble aarch64 vmlinux, I get the result like below. There is no space between sp and offset. ffff800008010000 <dw_apb_ictl_handle_irq>: ffff800008010000: d503233f hint #0x19 ffff800008010004: a9bc7bfd stp x29, x30, [sp,#-64]! ffff800008010008: 90011e60 adrp x0, ffff80000a3dc000 <num_ictlrs> ffff80000801000c: 910003fd mov x29, sp ffff800008010010: a9025bf5 stp x21, x22, [sp,#32] When I use newer version aarch64 objdump (2.35), I get the result like below. There is a space between sp and offset. ffff800008010000 <dw_apb_ictl_handle_irq>: ffff800008010000: d503233f paciasp ffff800008010004: a9bc7bfd stp x29, x30, [sp, #-64]! ffff800008010008: 90011e60 adrp x0, ffff80000a3dc000 <num_ictlrs> ffff80000801000c: 910003fd mov x29, sp ffff800008010010: a9025bf5 stp x21, x22, [sp, #32] Add no space support of regular expression for old version objdump. Link: https://lkml.kernel.org/r/20231220073629.2658-1-Kuan-Ying.Lee@mediatek.com Signed-off-by:
Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> Cc: Casper Li <casper.li@mediatek.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Chinwen Chang <chinwen.chang@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Qun-Wei Lin <qun-wei.lin@mediatek.com> Signed-off-by:
-
Yuntao Wang authored
kexec_dprintk() expects the last argument to be kbuf.memsz, but the actual argument being passed is kbuf.bufsz. Although these two values are currently equal, it is better to pass the correct one, in case these two values become different in the future. Link: https://lkml.kernel.org/r/20231220154105.215610-1-ytcoode@gmail.com Signed-off-by:
-
Yuntao Wang authored
When detecting an error, the current code uses kexec_dprintk() to output log message. This is not quite appropriate as kexec_dprintk() is mainly used for outputting debugging messages, rather than error messages. Replace kexec_dprintk() with pr_err(). This also makes the output method for this error log align with the output method for other error logs in this function. Additionally, the last return statement in set_page_address() is unnecessary, remove it. Link: https://lkml.kernel.org/r/20231220030124.149160-1-ytcoode@gmail.com Signed-off-by:
-
Kevin Hao authored
The kernel thread function nilfs_segctor_thread() invokes the try_to_freeze() in its loop. But all the kernel threads are non-freezable by default. So if we want to make a kernel thread to be freezable, we have to invoke set_freezable() explicitly. Link: https://lkml.kernel.org/r/20231219090918.2329-1-konishi.ryusuke@gmail.com Signed-off-by:
Kevin Hao <haokexin@gmail.com> Signed-off-by:
-
Ahelenia Ziemiańska authored
Documentation/filesystems/relay.rst says to use return debugfs_create_file(filename, mode, parent, buf, &relay_file_operations); and this is the only way relay_file_operations is used. Thus: debugfs_create_file(&relay_file_operations) -> __debugfs_create_file(&debugfs_full_proxy_file_operations, &relay_file_operations) -> dentry{inode: {i_fop: &debugfs_full_proxy_file_operations}, d_fsdata: &relay_file_operations | DEBUGFS_FSDATA_IS_REAL_FOPS_BIT} debugfs_full_proxy_file_operations.open is full_proxy_open, which extracts the &relay_file_operations from the dentry, and allocates via __full_proxy_fops_init() new fops, with trivial wrappers around release, llseek, read, write, poll, and unlocked_ioctl, then replaces the fops on the opened file therewith. Naturally, all thusly-created debugfs files have .splice_read = NULL. This was introduced in commit 49d200de ("debugfs: prevent access to removed files' private data") from 2016-03-22. AFAICT, relay_file_operations is the only struct file_operations used for debugfs which defines a .splice_read callback. Hooking it up with > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c > index 5063434be0fc..952fcf5b2afa 100644 > --- a/fs/debugfs/file.c > +++ b/fs/debugfs/file.c > @@ -328,6 +328,11 @@ FULL_PROXY_FUNC(write, ssize_t, filp, > loff_t *ppos), > ARGS(filp, buf, size, ppos)); > > +FULL_PROXY_FUNC(splice_read, long, in, > + PROTO(struct file *in, loff_t *ppos, struct pipe_inode_info *pipe, > + size_t len, unsigned int flags), > + ARGS(in, ppos, pipe, len, flags)); > + > FULL_PROXY_FUNC(unlocked_ioctl, long, filp, > PROTO(struct file *filp, unsigned int cmd, unsigned long arg), > ARGS(filp, cmd, arg)); > @@ -382,6 +387,8 @@ static void __full_proxy_fops_init(struct file_operations *proxy_fops, > proxy_fops->write = full_proxy_write; > if (real_fops->poll) > proxy_fops->poll = full_proxy_poll; > + if (real_fops->splice_read) > + proxy_fops->splice_read = full_proxy_splice_read; > if (real_fops->unlocked_ioctl) > proxy_fops->unlocked_ioctl = full_proxy_unlocked_ioctl; > } shows it just doesn't work, and splicing always instantly returns empty (subsequent reads actually return the contents). No-one noticed it became dead code in 2016, who knows if it worked back then. Clearly no-one cares; just delete it. Link: https://lkml.kernel.org/r/dtexwpw6zcdx7dkx3xj5gyjp5syxmyretdcbcdtvrnukd4vvuh@tarta.nabijaczleweli.xyz Signed-off-by:Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Li kunyu <kunyu@nfschina.com> Cc: Mike Rapoport (IBM) <rppt@kernel.org> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Zhang Zhengming <zhang.zhengming@h3c.com> Cc: Zhao Lei <zhao_lei1@hoperun.com> Signed-off-by:
-
Tiezhu Yang authored
After commit 7dfbea4c ("scripts: remove namespace.pl"), scripts/namespace.pl has been removed from the kernel, and "make namespacecheck" has been removed from the English version of submit-checklist.rst, so also remove it in the related translations. Link: https://lkml.kernel.org/r/20231219125008.23007-6-yangtiezhu@loongson.cn Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Tiezhu Yang authored
According to Documentation/process/submit-checklist.rst, checkstack does not point out problems explicitly, but any one function that uses more than 512 bytes on the stack is a candidate for change, hence it is better to omit any stack frame sizes smaller than 512 bytes, just change min_stack to 512 by default. Link: https://lkml.kernel.org/r/20231219125008.23007-5-yangtiezhu@loongson.cn Signed-off-by:
-
Tiezhu Yang authored
For some unknown reason the regular expression for checkstack only matches three digit numbers starting with the number "3", or any higher number. Which means that it skips any stack sizes smaller than 304 bytes. This makes the checkstack script a bit less useful than it could be. Change the script to match any number. To be filtered out stack sizes can be configured with the min_stack variable, which omits any stack frame sizes smaller than 100 bytes by default. This is similar with commit aab1f809 ("scripts/checkstack.pl: match all stack sizes for s390"). Link: https://lkml.kernel.org/r/20231219125008.23007-4-yangtiezhu@loongson.cn Signed-off-by:
-
Tiezhu Yang authored
After commit 572220aa ("scripts/checkstack.pl: Add argument to print stacks greather than value."), it is appropriate to add min_stack to the usage comment, then the users know explicitly that "min_stack" can be specified like "arch". Link: https://lkml.kernel.org/r/20231219125008.23007-3-yangtiezhu@loongson.cn Signed-off-by:
-
Tiezhu Yang authored
Patch series "Modify some code about checkstack". This patch (of 5): After commit cf8e8658 ("arch: Remove Itanium (IA-64) architecture"), the ia64 port has been removed from the kernel, so also remove the ia64 specific bits from the checkstack.pl script. Link: https://lkml.kernel.org/r/20231219125008.23007-1-yangtiezhu@loongson.cn Link: https://lkml.kernel.org/r/20231219125008.23007-2-yangtiezhu@loongson.cn Signed-off-by:
-
Mathis Marion authored
crc_ccitt_false() was introduced in commit 0d85adb5 ("lib/crc-ccitt: Add CCITT-FALSE CRC16 variant"), but it is redundant with crc_itu_t(). Since the latter is more used, it is the one being kept. Link: https://lkml.kernel.org/r/20231219131154.748577-1-Mathis.Marion@silabs.com Signed-off-by:
Mathis Marion <mathis.marion@silabs.com> Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Andrey Vostrikov <andrey.vostrikov@cogentembedded.com> Cc: Jérôme Pouiller <jerome.pouiller@silabs.com> Signed-off-by:
-
Uwe Kleine-König authored
DEBUG_STACK_USAGE doesn't only have an influence on the output of sysrq-T and sysrq-P, it also enables a message at process exit. See check_stack_usage() in kernel/exit.c where this is implemented. Link: https://lkml.kernel.org/r/20231219182808.210284-2-u.kleine-koenig@pengutronix.de Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Douglas Anderson <dianders@chromium.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Kees Cook <keescook@chromium.org> Cc: Marco Elver <elver@google.com> Cc: "Paul E. McKenney" <paulmck@kernel.org> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Petr Mladek <pmladek@suse.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Stephen Boyd <sboyd@kernel.org> Cc: Zhaoyang Huang <zhaoyang.huang@unisoc.com> Signed-off-by:
-
Youling Tang authored
scripts/checkstack.pl lacks support for the loongarch architecture. Add support to detect "addi.{w,d} $sp, $sp, -FRAME_SIZE" stack frame generation instruction. Link: https://lkml.kernel.org/r/MW4PR84MB314514273F0B7DBCC5E35A978192A@MW4PR84MB3145.NAMPRD84.PROD.OUTLOOK.COM Signed-off-by:Youling Tang <tangyouling@kylinos.cn> Acked-by:
Huacai Chen <chenhuacai@loongson.cn> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by:
-
Youling Tang authored
An example how to invoke decodecode for loongarch64: $ echo 'Code: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91' | \ ARCH=loongarch CROSS_COMPILE=loongarch64-linux-gnu- \ ./scripts/decodecode Code: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91 All code ======== 0: 380839f6 ldx.w $fp, $t3, $t2 4: 380831f9 ldx.w $s2, $t3, $t0 8: 28412bae ld.h $t2, $s6, 74(0x4a) c:* 24000ca6 ldptr.w $a2, $a1, 12(0xc) <-- trapping instruction 10: 004081ad slli.w $t1, $t1, 0x0 14: 0014cb50 and $t4, $s3, $t6 18: 004083e8 slli.w $a4, $s8, 0x0 1c: 02bff34c addi.w $t0, $s3, -4(0xffc) 20: 58008e91 beq $t8, $t5, 140(0x8c) # 0xac Code starting with the faulting instruction =========================================== 0: 24000ca6 ldptr.w $a2, $a1, 12(0xc) 4: 004081ad slli.w $t1, $t1, 0x0 8: 0014cb50 and $t4, $s3, $t6 c: 004083e8 slli.w $a4, $s8, 0x0 10: 02bff34c addi.w $t0, $s3, -4(0xffc) 14: 58008e91 beq $t8, $t5, 140(0x8c) # 0xa0 Link: https://lkml.kernel.org/r/MW4PR84MB3145B99B9677BB7887BB26CD8192A@MW4PR84MB3145.NAMPRD84.PROD.OUTLOOK.COM Signed-off-by:
-
Yuntao Wang authored
temp_end represents the address of the last available byte. Therefore, the starting address of the memory segment with temp_end as its last available byte and a size of `kbuf->memsz`, that is, the value of temp_start, should be `temp_end - kbuf->memsz + 1` instead of `temp_end - kbuf->memsz`. Additionally, use the ALIGN_DOWN macro instead of open-coding it directly in locate_mem_hole_top_down() to improve code readability. Link: https://lkml.kernel.org/r/20231217033528.303333-3-ytcoode@gmail.com Signed-off-by:
Baoquan He <bhe@redhat.com> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Yuntao Wang authored
The end parameter received by kimage_is_destination_range() should be the last valid byte address of the target memory segment plus 1. However, in the locate_mem_hole_bottom_up() and locate_mem_hole_top_down() functions, the corresponding value passed to kimage_is_destination_range() is the last valid byte address of the target memory segment, which is 1 less. There are two ways to fix this bug. We can either correct the logic of the locate_mem_hole_bottom_up() and locate_mem_hole_top_down() functions, or we can fix kimage_is_destination_range() by making the end parameter represent the last valid byte address of the target memory segment. Here, we choose the second approach. Due to the modification to kimage_is_destination_range(), we also need to adjust its callers, such as kimage_alloc_normal_control_pages() and kimage_alloc_page(). Link: https://lkml.kernel.org/r/20231217033528.303333-2-ytcoode@gmail.com Signed-off-by:
-
Bagas Sanjaya authored
Commit 62c46d55 ("MAINTAINERS: Removing Ohad from remoteproc/rpmsg maintenance") removes his MAINTAINERS entry in regards to remoteproc subsystem due to his inactivity (the last commit with his Signed-off-by is 99c429cb ("remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias") which is authored in 2015 and his last LKML message prior to 62c46d55 was [1]). Remove also his MAINTAINERS entry for hwspinlock subsystem as there is no point of Cc'ing maintainers who never respond in a long time. [1]: https://lore.kernel.org/r/CAK=Wgbbcyi36ef1-PV8VS=M6nFoQnFGUDWy6V7OCnkt0dDrtfg@mail.gmail.com/ Link: https://lkml.kernel.org/r/20231218132830.5104-2-bagasdotme@gmail.com Signed-off-by:
Bagas Sanjaya <bagasdotme@gmail.com> Acked-by:
Ohad Ben Cohen <ohad@wizery.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
- Dec 21, 2023
-
-
Wang Jinchao authored
Remove second include of linux/kexec.h Link: https://lkml.kernel.org/r/202312151654+0800-wangjinchao@xfusion.com Signed-off-by:
Wang Jinchao <wangjinchao@xfusion.com> Acked-by:
-
Yuntao Wang authored
The expression `mstart + resource_size(res) - 1` is actually equivalent to `res->end`, simplify the logic of this function to improve readability. Link: https://lkml.kernel.org/r/20231212150506.31711-1-ytcoode@gmail.com Signed-off-by:
-
Yuntao Wang authored
Use ALIGN macro instead of open-coding it to improve code readability. Link: https://lkml.kernel.org/r/20231212142706.25149-1-ytcoode@gmail.com Signed-off-by:
-
Randy Dunlap authored
Use "Its" or "its" for possessive instead of "it's" (contraction for "it is"). Link: https://lkml.kernel.org/r/20231210053429.23146-1-rdunlap@infradead.org Fixes: db2aa7fd ("initramfs: allow again choice of the embedded initram compression algorithm") Signed-off-by:
Nicolas Schier <nicolas@fjasle.eu> Acked-by:
"Francisco Blas Izquierdo Riera (klondike)" <klondike@klondike.es> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Randy Dunlap authored
KCMP, RSEQ, CACHESTAT_SYSCALL, and PC104 depend on EXPERT but not shown in the EXPERT menu. Move some lines around so that they are displayed in the EXPERT menu. Drop one useless comment. Change "enabled" to "enable" for DEBUG_RSEQ. Link: https://lkml.kernel.org/r/20231208045819.2922-1-rdunlap@infradead.org Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Paul E. McKenney" <paulmck@kernel.org> Cc: Boqun Feng <boqun.feng@gmail.com> Signed-off-by:
-
Kevin Hao authored
TASK_KILLABLE already includes TASK_UNINTERRUPTIBLE, so there is no need to add a separate TASK_UNINTERRUPTIBLE. Link: https://lkml.kernel.org/r/20231208084115.1973285-1-haokexin@gmail.com Signed-off-by:
-
Ryusuke Konishi authored
nilfs_sufile_do_free(), which is called when log write fails or during GC, uses WARN_ONs to check for abnormal status of metadata. In the former case, these WARN_ONs will not be fired, but in the latter case they don't "never-happen". It is possible to trigger these by intentionally modifying the userland GC library to release segments that are not in the expected state. So, replace them with warning output using the dedicated macro nilfs_warn(). This replaces two potentially triggered WARN_ONs with ones that use a warning output macro. Link: https://lkml.kernel.org/r/20231207045730.5205-1-konishi.ryusuke@gmail.com Signed-off-by:
-
Randy Dunlap authored
Correct the function parameter kernel-doc notation to prevent warnings: vxfs_lookup.c:192: warning: Function parameter or member 'ctx' not described in 'vxfs_readdir' vxfs_lookup.c:192: warning: Excess function parameter 'retp' description in 'vxfs_readdir' vxfs_lookup.c:192: warning: Excess function parameter 'filler' description in 'vxfs_readdir' Link: https://lkml.kernel.org/r/20231207212035.25345-3-rdunlap@infradead.org Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Randy Dunlap authored
Correct the function parameter name to prevent kernel-doc warnings: vxfs_immed.c:32: warning: Function parameter or member 'fp' not described in 'vxfs_immed_read_folio' vxfs_immed.c:32: warning: Excess function parameter 'file' description in 'vxfs_immed_read_folio' Link: https://lkml.kernel.org/r/20231207212035.25345-2-rdunlap@infradead.org Signed-off-by:
-
Randy Dunlap authored
Fix -Wall kernel-doc warnings in vxfs_bmap.c: vxfs_bmap.c:44: warning: Function parameter or member 'bn' not described in 'vxfs_bmap_ext4' vxfs_bmap.c:44: warning: Excess function parameter 'iblock' description in 'vxfs_bmap_ext4' vxfs_bmap.c:108: warning: No description found for return value of 'vxfs_bmap_indir' vxfs_bmap.c:187: warning: No description found for return value of 'vxfs_bmap_typed' vxfs_bmap.c:251: warning: No description found for return value of 'vxfs_bmap1' Link: https://lkml.kernel.org/r/20231207212035.25345-1-rdunlap@infradead.org Signed-off-by:
-
Randy Dunlap authored
Correct kernel-doc comments in tsi721.c and tsi721_dma.c to prevent warnings from scripts/kernel-doc. tsi721_dma.c:293: warning: expecting prototype for tsi721_omsg_msix(). Prototype was for tsi721_bdma_msix() instead tsi721.c:215: warning: Function parameter or member 'data' not described in 'tsi721_cread_dma' tsi721.c:215: warning: Excess function parameter 'val' description in 'tsi721_cread_dma' tsi721.c:238: warning: Function parameter or member 'data' not described in 'tsi721_cwrite_dma' tsi721.c:238: warning: Excess function parameter 'val' description in 'tsi721_cwrite_dma' tsi721.c:2548: warning: Function parameter or member 'attr' not described in 'tsi721_query_mport' tsi721.c:2548: warning: Excess function parameter 'mbox' description in 'tsi721_query_mport' and 27 warnings like this one: tsi721.c:59: warning: No description found for return value of 'tsi721_lcread' Link: https://lkml.kernel.org/r/20231206175528.16386-1-rdunlap@infradead.org Signed-off-...
-
Mark Rutland authored
The Kconfig help text for CONFIG_KCOV describes that recorded PC values will not be stable across machines or reboots when RANDOMIZE_BASE is selected. This was the case when KCOV was introduced in commit: 5c9a8750 ("kernel: add kcov code coverage") However, this changed in commit: 4983f0ab ("kcov: make kcov work properly with KASLR enabled") Since that commit KCOV always subtracts the KASLR offset from PC values, which ensures that these are stable across machines and across reboots even when RANDOMIZE_BASE is selected. Unfortunately, that commit failed to update the Kconfig help text, which still suggests disabling RANDOMIZE_BASE even though this is no longer necessary. Remove the stale Kconfig text. Link: https://lkml.kernel.org/r/20231204171807.3313022-1-mark.rutland@arm.com Reported-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Alexander Popov <alex.popov@linux.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Signed-off-by:
-
Baoquan He authored
This was introduced in commit fba8a867 ("RISC-V: Add kexec support"). It should work on CONFIG_KEXEC_CORE, but not CONFIG_KEXEC only, since we could set CONFIG_KEXEC_FILE=y and CONFIG_KEXEC=N, or only set CONFIG_CRASH_DUMP=y and disable both CONFIG_KEXEC and CONFIG_KEXEC_FILE. In these cases, the AFLAGS won't take effect with the current ifdeffery for AFLAGS_kexec_relocate.o. So fix it now. Link: https://lkml.kernel.org/r/20231201062538.27240-1-bhe@redhat.com Signed-off-by:
-
Baoquan He authored
Then when specifying '-d' for kexec_file_load interface, loaded locations of kernel/initrd/cmdline etc can be printed out to help debug. Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file loading related codes. Link: https://lkml.kernel.org/r/20231213055747.61826-8-bhe@redhat.com Signed-off-by:
-
Baoquan He authored
Then when specifying '-d' for kexec_file_load interface, loaded locations of kernel/initrd/cmdline etc can be printed out to help debug. Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file loading related codes. Link: https://lkml.kernel.org/r/20231213055747.61826-7-bhe@redhat.com Signed-off-by:
-
Baoquan He authored
Then when specifying '-d' for kexec_file_load interface, loaded locations of kernel/initrd/cmdline etc can be printed out to help debug. Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file loading related codes. And also replace pr_notice() with kexec_dprintk() in elf_kexec_load() because loaded location of purgatory and device tree are only printed out for debugging, it doesn't make sense to always print them out. And also remove kexec_image_info() because the content has been printed out in generic code. Link: https://lkml.kernel.org/r/20231213055747.61826-6-bhe@redhat.com Signed-off-by:
-
Baoquan He authored
Then when specifying '-d' for kexec_file_load interface, loaded locations of kernel/initrd/cmdline etc can be printed out to help debug. Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file loading related codes. And also remove the kimage->segment[] printing because the generic code has done the printing. Link: https://lkml.kernel.org/r/20231213055747.61826-5-bhe@redhat.com Signed-off-by:
-
