* [patch 01/41] proc: alloc PATH_MAX bytes for /proc/${pid}/fd/ symlinks
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: keescook, jamorris, christian.brauner, adobriyan, haolee.swjtu,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Hao Lee <haolee.swjtu@gmail.com>
Subject: proc: alloc PATH_MAX bytes for /proc/${pid}/fd/ symlinks
It's not a standard approach that use __get_free_page() to alloc path
buffer directly. We'd better use kmalloc and PATH_MAX.
PAGE_SIZE is different on different archs. An unlinked file
with very long canonical pathname will readlink differently
because "(deleted)" eats into a buffer. --adobriyan
[akpm@linux-foundation.org: remove now-unneeded cast]
Link: https://lkml.kernel.org/r/Ye1fCxyZZ0I5lgOL@localhost.localdomain
Signed-off-by: Hao Lee <haolee.swjtu@gmail.com>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: James Morris <jamorris@linux.microsoft.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/base.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/fs/proc/base.c~proc-alloc-path_max-bytes-for-proc-pid-fd-symlinks
+++ a/fs/proc/base.c
@@ -1764,25 +1764,25 @@ out:
static int do_proc_readlink(struct path *path, char __user *buffer, int buflen)
{
- char *tmp = (char *)__get_free_page(GFP_KERNEL);
+ char *tmp = kmalloc(PATH_MAX, GFP_KERNEL);
char *pathname;
int len;
if (!tmp)
return -ENOMEM;
- pathname = d_path(path, tmp, PAGE_SIZE);
+ pathname = d_path(path, tmp, PATH_MAX);
len = PTR_ERR(pathname);
if (IS_ERR(pathname))
goto out;
- len = tmp + PAGE_SIZE - 1 - pathname;
+ len = tmp + PATH_MAX - 1 - pathname;
if (len > buflen)
len = buflen;
if (copy_to_user(buffer, pathname, len))
len = -EFAULT;
out:
- free_page((unsigned long)tmp);
+ kfree(tmp);
return len;
}
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 01/41] proc: alloc PATH_MAX bytes for /proc/${pid}/fd/ symlinks
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: keescook, jamorris, christian.brauner, adobriyan, haolee.swjtu,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Hao Lee <haolee.swjtu@gmail.com>
Subject: proc: alloc PATH_MAX bytes for /proc/${pid}/fd/ symlinks
It's not a standard approach that use __get_free_page() to alloc path
buffer directly. We'd better use kmalloc and PATH_MAX.
PAGE_SIZE is different on different archs. An unlinked file
with very long canonical pathname will readlink differently
because "(deleted)" eats into a buffer. --adobriyan
[akpm@linux-foundation.org: remove now-unneeded cast]
Link: https://lkml.kernel.org/r/Ye1fCxyZZ0I5lgOL@localhost.localdomain
Signed-off-by: Hao Lee <haolee.swjtu@gmail.com>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: James Morris <jamorris@linux.microsoft.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/base.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/fs/proc/base.c~proc-alloc-path_max-bytes-for-proc-pid-fd-symlinks
+++ a/fs/proc/base.c
@@ -1764,25 +1764,25 @@ out:
static int do_proc_readlink(struct path *path, char __user *buffer, int buflen)
{
- char *tmp = (char *)__get_free_page(GFP_KERNEL);
+ char *tmp = kmalloc(PATH_MAX, GFP_KERNEL);
char *pathname;
int len;
if (!tmp)
return -ENOMEM;
- pathname = d_path(path, tmp, PAGE_SIZE);
+ pathname = d_path(path, tmp, PATH_MAX);
len = PTR_ERR(pathname);
if (IS_ERR(pathname))
goto out;
- len = tmp + PAGE_SIZE - 1 - pathname;
+ len = tmp + PATH_MAX - 1 - pathname;
if (len > buflen)
len = buflen;
if (copy_to_user(buffer, pathname, len))
len = -EFAULT;
out:
- free_page((unsigned long)tmp);
+ kfree(tmp);
return len;
}
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 02/41] proc/vmcore: fix possible deadlock on concurrent mmap and read
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: vgoyal, stable, peterz, paulmck, josh, dyoung, boqun.feng, bhe,
david, akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: David Hildenbrand <david@redhat.com>
Subject: proc/vmcore: fix possible deadlock on concurrent mmap and read
Lockdep noticed that there is chance for a deadlock if we have concurrent
mmap, concurrent read, and the addition/removal of a callback.
As nicely explained by Boqun:
"
Lockdep warned about the above sequences because rw_semaphore is a fair
read-write lock, and the following can cause a deadlock:
TASK 1 TASK 2 TASK 3
====== ====== ======
down_write(mmap_lock);
down_read(vmcore_cb_rwsem)
down_write(vmcore_cb_rwsem); // blocked
down_read(vmcore_cb_rwsem); // cannot get the lock because of the fairness
down_read(mmap_lock); // blocked
IOW, a reader can block another read if there is a writer queued by the
second reader and the lock is fair.
"
To fix, convert to srcu to make this deadlock impossible. We need srcu as
our callbacks can sleep. With this change, I cannot trigger any lockdep
warnings.
[ 6.386519] ======================================================
[ 6.387203] WARNING: possible circular locking dependency detected
[ 6.387965] 5.17.0-0.rc0.20220117git0c947b893d69.68.test.fc36.x86_64 #1 Not tainted
[ 6.388899] ------------------------------------------------------
[ 6.389657] makedumpfile/542 is trying to acquire lock:
[ 6.390308] ffffffff832d2eb8 (vmcore_cb_rwsem){.+.+}-{3:3}, at: mmap_vmcore+0x340/0x580
[ 6.391290]
[ 6.391290] but task is already holding lock:
[ 6.391978] ffff8880af226438 (&mm->mmap_lock#2){++++}-{3:3}, at: vm_mmap_pgoff+0x84/0x150
[ 6.392898]
[ 6.392898] which lock already depends on the new lock.
[ 6.392898]
[ 6.393866]
[ 6.393866] the existing dependency chain (in reverse order) is:
[ 6.394762]
[ 6.394762] -> #1 (&mm->mmap_lock#2){++++}-{3:3}:
[ 6.395530] lock_acquire+0xc3/0x1a0
[ 6.396047] __might_fault+0x4e/0x70
[ 6.396562] _copy_to_user+0x1f/0x90
[ 6.397093] __copy_oldmem_page+0x72/0xc0
[ 6.397663] read_from_oldmem+0x77/0x1e0
[ 6.398229] read_vmcore+0x2c2/0x310
[ 6.398742] proc_reg_read+0x47/0xa0
[ 6.399265] vfs_read+0x101/0x340
[ 6.399751] __x64_sys_pread64+0x5d/0xa0
[ 6.400314] do_syscall_64+0x43/0x90
[ 6.400778] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 6.401390]
[ 6.401390] -> #0 (vmcore_cb_rwsem){.+.+}-{3:3}:
[ 6.402063] validate_chain+0x9f4/0x2670
[ 6.402560] __lock_acquire+0x8f7/0xbc0
[ 6.403054] lock_acquire+0xc3/0x1a0
[ 6.403509] down_read+0x4a/0x140
[ 6.403948] mmap_vmcore+0x340/0x580
[ 6.404403] proc_reg_mmap+0x3e/0x90
[ 6.404866] mmap_region+0x504/0x880
[ 6.405322] do_mmap+0x38a/0x520
[ 6.405744] vm_mmap_pgoff+0xc1/0x150
[ 6.406258] ksys_mmap_pgoff+0x178/0x200
[ 6.406823] do_syscall_64+0x43/0x90
[ 6.407339] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 6.407975]
[ 6.407975] other info that might help us debug this:
[ 6.407975]
[ 6.408945] Possible unsafe locking scenario:
[ 6.408945]
[ 6.409684] CPU0 CPU1
[ 6.410196] ---- ----
[ 6.410703] lock(&mm->mmap_lock#2);
[ 6.411121] lock(vmcore_cb_rwsem);
[ 6.411792] lock(&mm->mmap_lock#2);
[ 6.412465] lock(vmcore_cb_rwsem);
[ 6.412873]
[ 6.412873] *** DEADLOCK ***
[ 6.412873]
[ 6.413522] 1 lock held by makedumpfile/542:
[ 6.414006] #0: ffff8880af226438 (&mm->mmap_lock#2){++++}-{3:3}, at: vm_mmap_pgoff+0x84/0x150
[ 6.414944]
[ 6.414944] stack backtrace:
[ 6.415432] CPU: 0 PID: 542 Comm: makedumpfile Not tainted 5.17.0-0.rc0.20220117git0c947b893d69.68.test.fc36.x86_64 #1
[ 6.416581] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 6.417272] Call Trace:
[ 6.417593] <TASK>
[ 6.417882] dump_stack_lvl+0x5d/0x78
[ 6.418346] print_circular_bug+0x5d7/0x5f0
[ 6.418821] ? stack_trace_save+0x3a/0x50
[ 6.419273] ? save_trace+0x3d/0x330
[ 6.419681] check_noncircular+0xd1/0xe0
[ 6.420217] validate_chain+0x9f4/0x2670
[ 6.420715] ? __lock_acquire+0x8f7/0xbc0
[ 6.421234] ? __lock_acquire+0x8f7/0xbc0
[ 6.421685] __lock_acquire+0x8f7/0xbc0
[ 6.422127] lock_acquire+0xc3/0x1a0
[ 6.422535] ? mmap_vmcore+0x340/0x580
[ 6.422965] ? lock_is_held_type+0xe2/0x140
[ 6.423432] ? mmap_vmcore+0x340/0x580
[ 6.423893] down_read+0x4a/0x140
[ 6.424321] ? mmap_vmcore+0x340/0x580
[ 6.424800] mmap_vmcore+0x340/0x580
[ 6.425237] ? vm_area_alloc+0x1c/0x60
[ 6.425661] ? trace_kmem_cache_alloc+0x30/0xe0
[ 6.426174] ? kmem_cache_alloc+0x1e0/0x2f0
[ 6.426641] proc_reg_mmap+0x3e/0x90
[ 6.427052] mmap_region+0x504/0x880
[ 6.427462] do_mmap+0x38a/0x520
[ 6.427842] vm_mmap_pgoff+0xc1/0x150
[ 6.428260] ksys_mmap_pgoff+0x178/0x200
[ 6.428701] do_syscall_64+0x43/0x90
[ 6.429126] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 6.429745] RIP: 0033:0x7fc7359b8fc7
[ 6.430157] Code: 00 00 00 89 ef e8 69 b3 ff ff eb e4 e8 c2 64 01 00 66 90 f3 0f 1e fa 41 89 ca 41 f7 c1 ff 0f 00 00 75 10 b8 09 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 21 c3 48 8b 05 21 7e 0e 00 64 c7 00 16 00 00
[ 6.432147] RSP: 002b:00007fff35b4c208 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
[ 6.432970] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fc7359b8fc7
[ 6.433746] RDX: 0000000000000001 RSI: 0000000000400000 RDI: 0000000000000000
[ 6.434529] RBP: 000055a1125ecf10 R08: 0000000000000003 R09: 0000000000002000
[ 6.435310] R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000002000
[ 6.436093] R13: 0000000000400000 R14: 000055a1124269e2 R15: 0000000000000000
[ 6.436887] </TASK>
Link: https://lkml.kernel.org/r/20220119193417.100385-1-david@redhat.com
Fixes: cc5f2704c934 ("proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reported-by: Baoquan He <bhe@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/vmcore.c | 41 ++++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 19 deletions(-)
--- a/fs/proc/vmcore.c~proc-vmcore-fix-possible-deadlock-on-concurrent-mmap-and-read
+++ a/fs/proc/vmcore.c
@@ -62,7 +62,8 @@ core_param(novmcoredd, vmcoredd_disabled
/* Device Dump Size */
static size_t vmcoredd_orig_sz;
-static DECLARE_RWSEM(vmcore_cb_rwsem);
+static DEFINE_SPINLOCK(vmcore_cb_lock);
+DEFINE_STATIC_SRCU(vmcore_cb_srcu);
/* List of registered vmcore callbacks. */
static LIST_HEAD(vmcore_cb_list);
/* Whether the vmcore has been opened once. */
@@ -70,8 +71,8 @@ static bool vmcore_opened;
void register_vmcore_cb(struct vmcore_cb *cb)
{
- down_write(&vmcore_cb_rwsem);
INIT_LIST_HEAD(&cb->next);
+ spin_lock(&vmcore_cb_lock);
list_add_tail(&cb->next, &vmcore_cb_list);
/*
* Registering a vmcore callback after the vmcore was opened is
@@ -79,14 +80,14 @@ void register_vmcore_cb(struct vmcore_cb
*/
if (vmcore_opened)
pr_warn_once("Unexpected vmcore callback registration\n");
- up_write(&vmcore_cb_rwsem);
+ spin_unlock(&vmcore_cb_lock);
}
EXPORT_SYMBOL_GPL(register_vmcore_cb);
void unregister_vmcore_cb(struct vmcore_cb *cb)
{
- down_write(&vmcore_cb_rwsem);
- list_del(&cb->next);
+ spin_lock(&vmcore_cb_lock);
+ list_del_rcu(&cb->next);
/*
* Unregistering a vmcore callback after the vmcore was opened is
* very unusual (e.g., forced driver removal), but we cannot stop
@@ -94,7 +95,9 @@ void unregister_vmcore_cb(struct vmcore_
*/
if (vmcore_opened)
pr_warn_once("Unexpected vmcore callback unregistration\n");
- up_write(&vmcore_cb_rwsem);
+ spin_unlock(&vmcore_cb_lock);
+
+ synchronize_srcu(&vmcore_cb_srcu);
}
EXPORT_SYMBOL_GPL(unregister_vmcore_cb);
@@ -103,9 +106,8 @@ static bool pfn_is_ram(unsigned long pfn
struct vmcore_cb *cb;
bool ret = true;
- lockdep_assert_held_read(&vmcore_cb_rwsem);
-
- list_for_each_entry(cb, &vmcore_cb_list, next) {
+ list_for_each_entry_srcu(cb, &vmcore_cb_list, next,
+ srcu_read_lock_held(&vmcore_cb_srcu)) {
if (unlikely(!cb->pfn_is_ram))
continue;
ret = cb->pfn_is_ram(cb, pfn);
@@ -118,9 +120,9 @@ static bool pfn_is_ram(unsigned long pfn
static int open_vmcore(struct inode *inode, struct file *file)
{
- down_read(&vmcore_cb_rwsem);
+ spin_lock(&vmcore_cb_lock);
vmcore_opened = true;
- up_read(&vmcore_cb_rwsem);
+ spin_unlock(&vmcore_cb_lock);
return 0;
}
@@ -133,6 +135,7 @@ ssize_t read_from_oldmem(char *buf, size
unsigned long pfn, offset;
size_t nr_bytes;
ssize_t read = 0, tmp;
+ int idx;
if (!count)
return 0;
@@ -140,7 +143,7 @@ ssize_t read_from_oldmem(char *buf, size
offset = (unsigned long)(*ppos % PAGE_SIZE);
pfn = (unsigned long)(*ppos / PAGE_SIZE);
- down_read(&vmcore_cb_rwsem);
+ idx = srcu_read_lock(&vmcore_cb_srcu);
do {
if (count > (PAGE_SIZE - offset))
nr_bytes = PAGE_SIZE - offset;
@@ -165,7 +168,7 @@ ssize_t read_from_oldmem(char *buf, size
offset, userbuf);
}
if (tmp < 0) {
- up_read(&vmcore_cb_rwsem);
+ srcu_read_unlock(&vmcore_cb_srcu, idx);
return tmp;
}
@@ -176,8 +179,8 @@ ssize_t read_from_oldmem(char *buf, size
++pfn;
offset = 0;
} while (count);
+ srcu_read_unlock(&vmcore_cb_srcu, idx);
- up_read(&vmcore_cb_rwsem);
return read;
}
@@ -568,18 +571,18 @@ static int vmcore_remap_oldmem_pfn(struc
unsigned long from, unsigned long pfn,
unsigned long size, pgprot_t prot)
{
- int ret;
+ int ret, idx;
/*
- * Check if oldmem_pfn_is_ram was registered to avoid
- * looping over all pages without a reason.
+ * Check if a callback was registered to avoid looping over all
+ * pages without a reason.
*/
- down_read(&vmcore_cb_rwsem);
+ idx = srcu_read_lock(&vmcore_cb_srcu);
if (!list_empty(&vmcore_cb_list))
ret = remap_oldmem_pfn_checked(vma, from, pfn, size, prot);
else
ret = remap_oldmem_pfn_range(vma, from, pfn, size, prot);
- up_read(&vmcore_cb_rwsem);
+ srcu_read_unlock(&vmcore_cb_srcu, idx);
return ret;
}
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 02/41] proc/vmcore: fix possible deadlock on concurrent mmap and read
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: vgoyal, stable, peterz, paulmck, josh, dyoung, boqun.feng, bhe,
david, akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: David Hildenbrand <david@redhat.com>
Subject: proc/vmcore: fix possible deadlock on concurrent mmap and read
Lockdep noticed that there is chance for a deadlock if we have concurrent
mmap, concurrent read, and the addition/removal of a callback.
As nicely explained by Boqun:
"
Lockdep warned about the above sequences because rw_semaphore is a fair
read-write lock, and the following can cause a deadlock:
TASK 1 TASK 2 TASK 3
====== ====== ======
down_write(mmap_lock);
down_read(vmcore_cb_rwsem)
down_write(vmcore_cb_rwsem); // blocked
down_read(vmcore_cb_rwsem); // cannot get the lock because of the fairness
down_read(mmap_lock); // blocked
IOW, a reader can block another read if there is a writer queued by the
second reader and the lock is fair.
"
To fix, convert to srcu to make this deadlock impossible. We need srcu as
our callbacks can sleep. With this change, I cannot trigger any lockdep
warnings.
[ 6.386519] ======================================================
[ 6.387203] WARNING: possible circular locking dependency detected
[ 6.387965] 5.17.0-0.rc0.20220117git0c947b893d69.68.test.fc36.x86_64 #1 Not tainted
[ 6.388899] ------------------------------------------------------
[ 6.389657] makedumpfile/542 is trying to acquire lock:
[ 6.390308] ffffffff832d2eb8 (vmcore_cb_rwsem){.+.+}-{3:3}, at: mmap_vmcore+0x340/0x580
[ 6.391290]
[ 6.391290] but task is already holding lock:
[ 6.391978] ffff8880af226438 (&mm->mmap_lock#2){++++}-{3:3}, at: vm_mmap_pgoff+0x84/0x150
[ 6.392898]
[ 6.392898] which lock already depends on the new lock.
[ 6.392898]
[ 6.393866]
[ 6.393866] the existing dependency chain (in reverse order) is:
[ 6.394762]
[ 6.394762] -> #1 (&mm->mmap_lock#2){++++}-{3:3}:
[ 6.395530] lock_acquire+0xc3/0x1a0
[ 6.396047] __might_fault+0x4e/0x70
[ 6.396562] _copy_to_user+0x1f/0x90
[ 6.397093] __copy_oldmem_page+0x72/0xc0
[ 6.397663] read_from_oldmem+0x77/0x1e0
[ 6.398229] read_vmcore+0x2c2/0x310
[ 6.398742] proc_reg_read+0x47/0xa0
[ 6.399265] vfs_read+0x101/0x340
[ 6.399751] __x64_sys_pread64+0x5d/0xa0
[ 6.400314] do_syscall_64+0x43/0x90
[ 6.400778] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 6.401390]
[ 6.401390] -> #0 (vmcore_cb_rwsem){.+.+}-{3:3}:
[ 6.402063] validate_chain+0x9f4/0x2670
[ 6.402560] __lock_acquire+0x8f7/0xbc0
[ 6.403054] lock_acquire+0xc3/0x1a0
[ 6.403509] down_read+0x4a/0x140
[ 6.403948] mmap_vmcore+0x340/0x580
[ 6.404403] proc_reg_mmap+0x3e/0x90
[ 6.404866] mmap_region+0x504/0x880
[ 6.405322] do_mmap+0x38a/0x520
[ 6.405744] vm_mmap_pgoff+0xc1/0x150
[ 6.406258] ksys_mmap_pgoff+0x178/0x200
[ 6.406823] do_syscall_64+0x43/0x90
[ 6.407339] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 6.407975]
[ 6.407975] other info that might help us debug this:
[ 6.407975]
[ 6.408945] Possible unsafe locking scenario:
[ 6.408945]
[ 6.409684] CPU0 CPU1
[ 6.410196] ---- ----
[ 6.410703] lock(&mm->mmap_lock#2);
[ 6.411121] lock(vmcore_cb_rwsem);
[ 6.411792] lock(&mm->mmap_lock#2);
[ 6.412465] lock(vmcore_cb_rwsem);
[ 6.412873]
[ 6.412873] *** DEADLOCK ***
[ 6.412873]
[ 6.413522] 1 lock held by makedumpfile/542:
[ 6.414006] #0: ffff8880af226438 (&mm->mmap_lock#2){++++}-{3:3}, at: vm_mmap_pgoff+0x84/0x150
[ 6.414944]
[ 6.414944] stack backtrace:
[ 6.415432] CPU: 0 PID: 542 Comm: makedumpfile Not tainted 5.17.0-0.rc0.20220117git0c947b893d69.68.test.fc36.x86_64 #1
[ 6.416581] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 6.417272] Call Trace:
[ 6.417593] <TASK>
[ 6.417882] dump_stack_lvl+0x5d/0x78
[ 6.418346] print_circular_bug+0x5d7/0x5f0
[ 6.418821] ? stack_trace_save+0x3a/0x50
[ 6.419273] ? save_trace+0x3d/0x330
[ 6.419681] check_noncircular+0xd1/0xe0
[ 6.420217] validate_chain+0x9f4/0x2670
[ 6.420715] ? __lock_acquire+0x8f7/0xbc0
[ 6.421234] ? __lock_acquire+0x8f7/0xbc0
[ 6.421685] __lock_acquire+0x8f7/0xbc0
[ 6.422127] lock_acquire+0xc3/0x1a0
[ 6.422535] ? mmap_vmcore+0x340/0x580
[ 6.422965] ? lock_is_held_type+0xe2/0x140
[ 6.423432] ? mmap_vmcore+0x340/0x580
[ 6.423893] down_read+0x4a/0x140
[ 6.424321] ? mmap_vmcore+0x340/0x580
[ 6.424800] mmap_vmcore+0x340/0x580
[ 6.425237] ? vm_area_alloc+0x1c/0x60
[ 6.425661] ? trace_kmem_cache_alloc+0x30/0xe0
[ 6.426174] ? kmem_cache_alloc+0x1e0/0x2f0
[ 6.426641] proc_reg_mmap+0x3e/0x90
[ 6.427052] mmap_region+0x504/0x880
[ 6.427462] do_mmap+0x38a/0x520
[ 6.427842] vm_mmap_pgoff+0xc1/0x150
[ 6.428260] ksys_mmap_pgoff+0x178/0x200
[ 6.428701] do_syscall_64+0x43/0x90
[ 6.429126] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 6.429745] RIP: 0033:0x7fc7359b8fc7
[ 6.430157] Code: 00 00 00 89 ef e8 69 b3 ff ff eb e4 e8 c2 64 01 00 66 90 f3 0f 1e fa 41 89 ca 41 f7 c1 ff 0f 00 00 75 10 b8 09 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 21 c3 48 8b 05 21 7e 0e 00 64 c7 00 16 00 00
[ 6.432147] RSP: 002b:00007fff35b4c208 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
[ 6.432970] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fc7359b8fc7
[ 6.433746] RDX: 0000000000000001 RSI: 0000000000400000 RDI: 0000000000000000
[ 6.434529] RBP: 000055a1125ecf10 R08: 0000000000000003 R09: 0000000000002000
[ 6.435310] R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000002000
[ 6.436093] R13: 0000000000400000 R14: 000055a1124269e2 R15: 0000000000000000
[ 6.436887] </TASK>
Link: https://lkml.kernel.org/r/20220119193417.100385-1-david@redhat.com
Fixes: cc5f2704c934 ("proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reported-by: Baoquan He <bhe@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/vmcore.c | 41 ++++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 19 deletions(-)
--- a/fs/proc/vmcore.c~proc-vmcore-fix-possible-deadlock-on-concurrent-mmap-and-read
+++ a/fs/proc/vmcore.c
@@ -62,7 +62,8 @@ core_param(novmcoredd, vmcoredd_disabled
/* Device Dump Size */
static size_t vmcoredd_orig_sz;
-static DECLARE_RWSEM(vmcore_cb_rwsem);
+static DEFINE_SPINLOCK(vmcore_cb_lock);
+DEFINE_STATIC_SRCU(vmcore_cb_srcu);
/* List of registered vmcore callbacks. */
static LIST_HEAD(vmcore_cb_list);
/* Whether the vmcore has been opened once. */
@@ -70,8 +71,8 @@ static bool vmcore_opened;
void register_vmcore_cb(struct vmcore_cb *cb)
{
- down_write(&vmcore_cb_rwsem);
INIT_LIST_HEAD(&cb->next);
+ spin_lock(&vmcore_cb_lock);
list_add_tail(&cb->next, &vmcore_cb_list);
/*
* Registering a vmcore callback after the vmcore was opened is
@@ -79,14 +80,14 @@ void register_vmcore_cb(struct vmcore_cb
*/
if (vmcore_opened)
pr_warn_once("Unexpected vmcore callback registration\n");
- up_write(&vmcore_cb_rwsem);
+ spin_unlock(&vmcore_cb_lock);
}
EXPORT_SYMBOL_GPL(register_vmcore_cb);
void unregister_vmcore_cb(struct vmcore_cb *cb)
{
- down_write(&vmcore_cb_rwsem);
- list_del(&cb->next);
+ spin_lock(&vmcore_cb_lock);
+ list_del_rcu(&cb->next);
/*
* Unregistering a vmcore callback after the vmcore was opened is
* very unusual (e.g., forced driver removal), but we cannot stop
@@ -94,7 +95,9 @@ void unregister_vmcore_cb(struct vmcore_
*/
if (vmcore_opened)
pr_warn_once("Unexpected vmcore callback unregistration\n");
- up_write(&vmcore_cb_rwsem);
+ spin_unlock(&vmcore_cb_lock);
+
+ synchronize_srcu(&vmcore_cb_srcu);
}
EXPORT_SYMBOL_GPL(unregister_vmcore_cb);
@@ -103,9 +106,8 @@ static bool pfn_is_ram(unsigned long pfn
struct vmcore_cb *cb;
bool ret = true;
- lockdep_assert_held_read(&vmcore_cb_rwsem);
-
- list_for_each_entry(cb, &vmcore_cb_list, next) {
+ list_for_each_entry_srcu(cb, &vmcore_cb_list, next,
+ srcu_read_lock_held(&vmcore_cb_srcu)) {
if (unlikely(!cb->pfn_is_ram))
continue;
ret = cb->pfn_is_ram(cb, pfn);
@@ -118,9 +120,9 @@ static bool pfn_is_ram(unsigned long pfn
static int open_vmcore(struct inode *inode, struct file *file)
{
- down_read(&vmcore_cb_rwsem);
+ spin_lock(&vmcore_cb_lock);
vmcore_opened = true;
- up_read(&vmcore_cb_rwsem);
+ spin_unlock(&vmcore_cb_lock);
return 0;
}
@@ -133,6 +135,7 @@ ssize_t read_from_oldmem(char *buf, size
unsigned long pfn, offset;
size_t nr_bytes;
ssize_t read = 0, tmp;
+ int idx;
if (!count)
return 0;
@@ -140,7 +143,7 @@ ssize_t read_from_oldmem(char *buf, size
offset = (unsigned long)(*ppos % PAGE_SIZE);
pfn = (unsigned long)(*ppos / PAGE_SIZE);
- down_read(&vmcore_cb_rwsem);
+ idx = srcu_read_lock(&vmcore_cb_srcu);
do {
if (count > (PAGE_SIZE - offset))
nr_bytes = PAGE_SIZE - offset;
@@ -165,7 +168,7 @@ ssize_t read_from_oldmem(char *buf, size
offset, userbuf);
}
if (tmp < 0) {
- up_read(&vmcore_cb_rwsem);
+ srcu_read_unlock(&vmcore_cb_srcu, idx);
return tmp;
}
@@ -176,8 +179,8 @@ ssize_t read_from_oldmem(char *buf, size
++pfn;
offset = 0;
} while (count);
+ srcu_read_unlock(&vmcore_cb_srcu, idx);
- up_read(&vmcore_cb_rwsem);
return read;
}
@@ -568,18 +571,18 @@ static int vmcore_remap_oldmem_pfn(struc
unsigned long from, unsigned long pfn,
unsigned long size, pgprot_t prot)
{
- int ret;
+ int ret, idx;
/*
- * Check if oldmem_pfn_is_ram was registered to avoid
- * looping over all pages without a reason.
+ * Check if a callback was registered to avoid looping over all
+ * pages without a reason.
*/
- down_read(&vmcore_cb_rwsem);
+ idx = srcu_read_lock(&vmcore_cb_srcu);
if (!list_empty(&vmcore_cb_list))
ret = remap_oldmem_pfn_checked(vma, from, pfn, size, prot);
else
ret = remap_oldmem_pfn_range(vma, from, pfn, size, prot);
- up_read(&vmcore_cb_rwsem);
+ srcu_read_unlock(&vmcore_cb_srcu, idx);
return ret;
}
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 03/41] proc/vmcore: fix vmcore_alloc_buf() kernel-doc comment
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: bhe, abaci, yang.lee, akpm, patches, linux-mm, mm-commits,
torvalds, akpm
From: Yang Li <yang.lee@linux.alibaba.com>
Subject: proc/vmcore: fix vmcore_alloc_buf() kernel-doc comment
Fix a spelling problem to remove warnings found by running
scripts/kernel-doc, which is caused by using 'make W=1'.
fs/proc/vmcore.c:492: warning: Function parameter or member 'size' not
described in 'vmcore_alloc_buf'
fs/proc/vmcore.c:492: warning: Excess function parameter 'sizez'
description in 'vmcore_alloc_buf'
Link: https://lkml.kernel.org/r/20220129011449.105278-1-yang.lee@linux.alibaba.com
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/vmcore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/proc/vmcore.c~proc-vmcore-fix-vmcore_alloc_buf-kernel-doc-comment
+++ a/fs/proc/vmcore.c
@@ -480,7 +480,7 @@ static const struct vm_operations_struct
/**
* vmcore_alloc_buf - allocate buffer in vmalloc memory
- * @sizez: size of buffer
+ * @size: size of buffer
*
* If CONFIG_MMU is defined, use vmalloc_user() to allow users to mmap
* the buffer to user-space by means of remap_vmalloc_range().
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 03/41] proc/vmcore: fix vmcore_alloc_buf() kernel-doc comment
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: bhe, abaci, yang.lee, akpm, patches, linux-mm, mm-commits,
torvalds, akpm
From: Yang Li <yang.lee@linux.alibaba.com>
Subject: proc/vmcore: fix vmcore_alloc_buf() kernel-doc comment
Fix a spelling problem to remove warnings found by running
scripts/kernel-doc, which is caused by using 'make W=1'.
fs/proc/vmcore.c:492: warning: Function parameter or member 'size' not
described in 'vmcore_alloc_buf'
fs/proc/vmcore.c:492: warning: Excess function parameter 'sizez'
description in 'vmcore_alloc_buf'
Link: https://lkml.kernel.org/r/20220129011449.105278-1-yang.lee@linux.alibaba.com
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/vmcore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/proc/vmcore.c~proc-vmcore-fix-vmcore_alloc_buf-kernel-doc-comment
+++ a/fs/proc/vmcore.c
@@ -480,7 +480,7 @@ static const struct vm_operations_struct
/**
* vmcore_alloc_buf - allocate buffer in vmalloc memory
- * @sizez: size of buffer
+ * @size: size of buffer
*
* If CONFIG_MMU is defined, use vmalloc_user() to allow users to mmap
* the buffer to user-space by means of remap_vmalloc_range().
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 04/41] linux/types.h: remove unnecessary __bitwise__
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: ndesaulniers, nathan, mst, corbet, bhelgaas, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: Bjorn Helgaas <bhelgaas@google.com>
Subject: linux/types.h: remove unnecessary __bitwise__
There are no users of "__bitwise__" except the definition of "__bitwise".
Remove __bitwise__ and define __bitwise directly.
This is a follow-up to 05de97003c77 ("linux/types.h: enable endian checks
for all sparse builds").
[akpm@linux-foundation.org: change the tools/include/linux/types.h definition also]
Link: https://lkml.kernel.org/r/20220310220927.245704-2-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/uapi/linux/types.h | 5 ++---
tools/include/linux/types.h | 5 ++---
2 files changed, 4 insertions(+), 6 deletions(-)
--- a/include/uapi/linux/types.h~linux-typesh-remove-unnecessary-__bitwise__
+++ a/include/uapi/linux/types.h
@@ -20,11 +20,10 @@
*/
#ifdef __CHECKER__
-#define __bitwise__ __attribute__((bitwise))
+#define __bitwise __attribute__((bitwise))
#else
-#define __bitwise__
+#define __bitwise
#endif
-#define __bitwise __bitwise__
typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
--- a/tools/include/linux/types.h~linux-typesh-remove-unnecessary-__bitwise__
+++ a/tools/include/linux/types.h
@@ -43,11 +43,10 @@ typedef __u8 u8;
typedef __s8 s8;
#ifdef __CHECKER__
-#define __bitwise__ __attribute__((bitwise))
+#define __bitwise __attribute__((bitwise))
#else
-#define __bitwise__
+#define __bitwise
#endif
-#define __bitwise __bitwise__
#define __force
#define __user
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 04/41] linux/types.h: remove unnecessary __bitwise__
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: ndesaulniers, nathan, mst, corbet, bhelgaas, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: Bjorn Helgaas <bhelgaas@google.com>
Subject: linux/types.h: remove unnecessary __bitwise__
There are no users of "__bitwise__" except the definition of "__bitwise".
Remove __bitwise__ and define __bitwise directly.
This is a follow-up to 05de97003c77 ("linux/types.h: enable endian checks
for all sparse builds").
[akpm@linux-foundation.org: change the tools/include/linux/types.h definition also]
Link: https://lkml.kernel.org/r/20220310220927.245704-2-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/uapi/linux/types.h | 5 ++---
tools/include/linux/types.h | 5 ++---
2 files changed, 4 insertions(+), 6 deletions(-)
--- a/include/uapi/linux/types.h~linux-typesh-remove-unnecessary-__bitwise__
+++ a/include/uapi/linux/types.h
@@ -20,11 +20,10 @@
*/
#ifdef __CHECKER__
-#define __bitwise__ __attribute__((bitwise))
+#define __bitwise __attribute__((bitwise))
#else
-#define __bitwise__
+#define __bitwise
#endif
-#define __bitwise __bitwise__
typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
--- a/tools/include/linux/types.h~linux-typesh-remove-unnecessary-__bitwise__
+++ a/tools/include/linux/types.h
@@ -43,11 +43,10 @@ typedef __u8 u8;
typedef __s8 s8;
#ifdef __CHECKER__
-#define __bitwise__ __attribute__((bitwise))
+#define __bitwise __attribute__((bitwise))
#else
-#define __bitwise__
+#define __bitwise
#endif
-#define __bitwise __bitwise__
#define __force
#define __user
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 05/41] Documentation/sparse: add hints about __CHECKER__
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: ndesaulniers, nathan, mst, corbet, bhelgaas, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: Bjorn Helgaas <bhelgaas@google.com>
Subject: Documentation/sparse: add hints about __CHECKER__
Several attributes depend on __CHECKER__, but previously there was no clue
in the tree about when __CHECKER__ might be defined. Add hints at the
most common places (__kernel, __user, __iomem, __bitwise) and in the
sparse documentation.
Link: https://lkml.kernel.org/r/20220310220927.245704-3-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: "Michael S . Tsirkin" <mst@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/dev-tools/sparse.rst | 2 ++
include/linux/compiler_types.h | 1 +
include/uapi/linux/types.h | 1 +
3 files changed, 4 insertions(+)
--- a/Documentation/dev-tools/sparse.rst~documentation-sparse-add-hints-about-__checker__
+++ a/Documentation/dev-tools/sparse.rst
@@ -100,3 +100,5 @@ have already built it.
The optional make variable CF can be used to pass arguments to sparse. The
build system passes -Wbitwise to sparse automatically.
+
+Note that sparse defines the __CHECKER__ preprocessor symbol.
--- a/include/linux/compiler_types.h~documentation-sparse-add-hints-about-__checker__
+++ a/include/linux/compiler_types.h
@@ -4,6 +4,7 @@
#ifndef __ASSEMBLY__
+/* sparse defines __CHECKER__; see Documentation/dev-tools/sparse.rst */
#ifdef __CHECKER__
/* address spaces */
# define __kernel __attribute__((address_space(0)))
--- a/include/uapi/linux/types.h~documentation-sparse-add-hints-about-__checker__
+++ a/include/uapi/linux/types.h
@@ -19,6 +19,7 @@
* any application/library that wants linux/types.h.
*/
+/* sparse defines __CHECKER__; see Documentation/dev-tools/sparse.rst */
#ifdef __CHECKER__
#define __bitwise __attribute__((bitwise))
#else
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 05/41] Documentation/sparse: add hints about __CHECKER__
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: ndesaulniers, nathan, mst, corbet, bhelgaas, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: Bjorn Helgaas <bhelgaas@google.com>
Subject: Documentation/sparse: add hints about __CHECKER__
Several attributes depend on __CHECKER__, but previously there was no clue
in the tree about when __CHECKER__ might be defined. Add hints at the
most common places (__kernel, __user, __iomem, __bitwise) and in the
sparse documentation.
Link: https://lkml.kernel.org/r/20220310220927.245704-3-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: "Michael S . Tsirkin" <mst@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/dev-tools/sparse.rst | 2 ++
include/linux/compiler_types.h | 1 +
include/uapi/linux/types.h | 1 +
3 files changed, 4 insertions(+)
--- a/Documentation/dev-tools/sparse.rst~documentation-sparse-add-hints-about-__checker__
+++ a/Documentation/dev-tools/sparse.rst
@@ -100,3 +100,5 @@ have already built it.
The optional make variable CF can be used to pass arguments to sparse. The
build system passes -Wbitwise to sparse automatically.
+
+Note that sparse defines the __CHECKER__ preprocessor symbol.
--- a/include/linux/compiler_types.h~documentation-sparse-add-hints-about-__checker__
+++ a/include/linux/compiler_types.h
@@ -4,6 +4,7 @@
#ifndef __ASSEMBLY__
+/* sparse defines __CHECKER__; see Documentation/dev-tools/sparse.rst */
#ifdef __CHECKER__
/* address spaces */
# define __kernel __attribute__((address_space(0)))
--- a/include/uapi/linux/types.h~documentation-sparse-add-hints-about-__checker__
+++ a/include/uapi/linux/types.h
@@ -19,6 +19,7 @@
* any application/library that wants linux/types.h.
*/
+/* sparse defines __CHECKER__; see Documentation/dev-tools/sparse.rst */
#ifdef __CHECKER__
#define __bitwise __attribute__((bitwise))
#else
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 06/41] kernel/ksysfs.c: use helper macro __ATTR_RW
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: gregkh, linmiaohe, akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Miaohe Lin <linmiaohe@huawei.com>
Subject: kernel/ksysfs.c: use helper macro __ATTR_RW
Use helper macro __ATTR_RW to define kobj_attribute to make code more
clear. Minor readability improvement.
Link: https://lkml.kernel.org/r/20220222112034.48298-1-linmiaohe@huawei.com
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/ksysfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/kernel/ksysfs.c~kernel-ksysfsc-use-helper-macro-__attr_rw
+++ a/kernel/ksysfs.c
@@ -24,8 +24,7 @@
static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
#define KERNEL_ATTR_RW(_name) \
-static struct kobj_attribute _name##_attr = \
- __ATTR(_name, 0644, _name##_show, _name##_store)
+static struct kobj_attribute _name##_attr = __ATTR_RW(_name)
/* current uevent sequence number */
static ssize_t uevent_seqnum_show(struct kobject *kobj,
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 06/41] kernel/ksysfs.c: use helper macro __ATTR_RW
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: gregkh, linmiaohe, akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Miaohe Lin <linmiaohe@huawei.com>
Subject: kernel/ksysfs.c: use helper macro __ATTR_RW
Use helper macro __ATTR_RW to define kobj_attribute to make code more
clear. Minor readability improvement.
Link: https://lkml.kernel.org/r/20220222112034.48298-1-linmiaohe@huawei.com
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/ksysfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/kernel/ksysfs.c~kernel-ksysfsc-use-helper-macro-__attr_rw
+++ a/kernel/ksysfs.c
@@ -24,8 +24,7 @@
static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
#define KERNEL_ATTR_RW(_name) \
-static struct kobj_attribute _name##_attr = \
- __ATTR(_name, 0644, _name##_show, _name##_store)
+static struct kobj_attribute _name##_attr = __ATTR_RW(_name)
/* current uevent sequence number */
static ssize_t uevent_seqnum_show(struct kobject *kobj,
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 07/41] Kconfig.debug: make DEBUG_INFO selectable from a choice
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: penguin-kernel, ndesaulniers, nathan, masahiroy, arnd, keescook,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Kees Cook <keescook@chromium.org>
Subject: Kconfig.debug: make DEBUG_INFO selectable from a choice
Currently it's not possible to enable DEBUG_INFO for an all*config build,
since it is marked as "depends on !COMPILE_TEST". This generally makes
sense because a debug build of an all*config target ends up taking much
longer and the output is much larger. Having this be "default off" makes
sense. However, there are cases where enabling DEBUG_INFO for such builds
is useful for doing treewide A/B comparisons of build options, etc.
Make DEBUG_INFO selectable from any of the DWARF version choice options,
with DEBUG_INFO_NONE being the default for COMPILE_TEST. The mutually
exclusive relationship between DWARF5 and BTF must be inverted, but the
result remains the same. Additionally moves DEBUG_KERNEL and DEBUG_MISC
up to the top of the menu because they were enabling features _above_ it,
making it weird to navigate menuconfig.
[keescook@chromium.org: make DEBUG_INFO always default=n]
Link: https://lkml.kernel.org/r/20220128214131.580131-1-keescook@chromium.org
Link: https://lore.kernel.org/lkml/YfRY6+CaQxX7O8vF@dev-arch.archlinux-ax161
Link: https://lkml.kernel.org/r/20220125075126.891825-1-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/Kconfig.debug | 139 +++++++++++++++++++++++---------------------
1 file changed, 74 insertions(+), 65 deletions(-)
--- a/lib/Kconfig.debug~kconfigdebug-make-debug_info-selectable-from-a-choice
+++ a/lib/Kconfig.debug
@@ -208,20 +208,87 @@ config DEBUG_BUGVERBOSE
endmenu # "printk and dmesg options"
+config DEBUG_KERNEL
+ bool "Kernel debugging"
+ help
+ Say Y here if you are developing drivers or trying to debug and
+ identify kernel problems.
+
+config DEBUG_MISC
+ bool "Miscellaneous debug code"
+ default DEBUG_KERNEL
+ depends on DEBUG_KERNEL
+ help
+ Say Y here if you need to enable miscellaneous debug code that should
+ be under a more specific debug option but isn't.
+
menu "Compile-time checks and compiler options"
config DEBUG_INFO
- bool "Compile the kernel with debug info"
- depends on DEBUG_KERNEL && !COMPILE_TEST
+ bool
help
- If you say Y here the resulting kernel image will include
- debugging info resulting in a larger kernel image.
+ A kernel debug info option other than "None" has been selected
+ in the "Debug information" choice below, indicating that debug
+ information will be generated for build targets.
+
+choice
+ prompt "Debug information"
+ depends on DEBUG_KERNEL
+ help
+ Selecting something other than "None" results in a kernel image
+ that will include debugging info resulting in a larger kernel image.
This adds debug symbols to the kernel and modules (gcc -g), and
is needed if you intend to use kernel crashdump or binary object
tools like crash, kgdb, LKCD, gdb, etc on the kernel.
- Say Y here only if you plan to debug the kernel.
- If unsure, say N.
+ Choose which version of DWARF debug info to emit. If unsure,
+ select "Toolchain default".
+
+config DEBUG_INFO_NONE
+ bool "Disable debug information"
+ help
+ Do not build the kernel with debugging information, which will
+ result in a faster and smaller build.
+
+config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
+ bool "Rely on the toolchain's implicit default DWARF version"
+ select DEBUG_INFO
+ help
+ The implicit default version of DWARF debug info produced by a
+ toolchain changes over time.
+
+ This can break consumers of the debug info that haven't upgraded to
+ support newer revisions, and prevent testing newer versions, but
+ those should be less common scenarios.
+
+config DEBUG_INFO_DWARF4
+ bool "Generate DWARF Version 4 debuginfo"
+ select DEBUG_INFO
+ help
+ Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
+
+ If you have consumers of DWARF debug info that are not ready for
+ newer revisions of DWARF, you may wish to choose this or have your
+ config select this.
+
+config DEBUG_INFO_DWARF5
+ bool "Generate DWARF Version 5 debuginfo"
+ select DEBUG_INFO
+ depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502)))
+ help
+ Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc
+ 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
+ draft features until 7.0), and gdb 8.0+.
+
+ Changes to the structure of debug info in Version 5 allow for around
+ 15-18% savings in resulting image and debug info section sizes as
+ compared to DWARF Version 4. DWARF Version 5 standardizes previous
+ extensions such as accelerators for symbol indexing and the format
+ for fission (.dwo/.dwp) files. Users may not want to select this
+ config if they rely on tooling that has not yet been updated to
+ support DWARF Version 5.
+
+endchoice # "Debug information"
if DEBUG_INFO
@@ -267,56 +334,12 @@ config DEBUG_INFO_SPLIT
to know about the .dwo files and include them.
Incompatible with older versions of ccache.
-choice
- prompt "DWARF version"
- help
- Which version of DWARF debug info to emit.
-
-config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
- bool "Rely on the toolchain's implicit default DWARF version"
- help
- The implicit default version of DWARF debug info produced by a
- toolchain changes over time.
-
- This can break consumers of the debug info that haven't upgraded to
- support newer revisions, and prevent testing newer versions, but
- those should be less common scenarios.
-
- If unsure, say Y.
-
-config DEBUG_INFO_DWARF4
- bool "Generate DWARF Version 4 debuginfo"
- help
- Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
-
- If you have consumers of DWARF debug info that are not ready for
- newer revisions of DWARF, you may wish to choose this or have your
- config select this.
-
-config DEBUG_INFO_DWARF5
- bool "Generate DWARF Version 5 debuginfo"
- depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502)))
- depends on !DEBUG_INFO_BTF
- help
- Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc
- 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
- draft features until 7.0), and gdb 8.0+.
-
- Changes to the structure of debug info in Version 5 allow for around
- 15-18% savings in resulting image and debug info section sizes as
- compared to DWARF Version 4. DWARF Version 5 standardizes previous
- extensions such as accelerators for symbol indexing and the format
- for fission (.dwo/.dwp) files. Users may not want to select this
- config if they rely on tooling that has not yet been updated to
- support DWARF Version 5.
-
-endchoice # "DWARF version"
-
config DEBUG_INFO_BTF
bool "Generate BTF typeinfo"
depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
depends on BPF_SYSCALL
+ depends on !DEBUG_INFO_DWARF5
help
Generate deduplicated BTF type information from DWARF debug info.
Turning this on expects presence of pahole tool, which will convert
@@ -585,20 +608,6 @@ source "lib/Kconfig.kcsan"
endmenu
-config DEBUG_KERNEL
- bool "Kernel debugging"
- help
- Say Y here if you are developing drivers or trying to debug and
- identify kernel problems.
-
-config DEBUG_MISC
- bool "Miscellaneous debug code"
- default DEBUG_KERNEL
- depends on DEBUG_KERNEL
- help
- Say Y here if you need to enable miscellaneous debug code that should
- be under a more specific debug option but isn't.
-
menu "Networking Debugging"
source "net/Kconfig.debug"
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 07/41] Kconfig.debug: make DEBUG_INFO selectable from a choice
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: penguin-kernel, ndesaulniers, nathan, masahiroy, arnd, keescook,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Kees Cook <keescook@chromium.org>
Subject: Kconfig.debug: make DEBUG_INFO selectable from a choice
Currently it's not possible to enable DEBUG_INFO for an all*config build,
since it is marked as "depends on !COMPILE_TEST". This generally makes
sense because a debug build of an all*config target ends up taking much
longer and the output is much larger. Having this be "default off" makes
sense. However, there are cases where enabling DEBUG_INFO for such builds
is useful for doing treewide A/B comparisons of build options, etc.
Make DEBUG_INFO selectable from any of the DWARF version choice options,
with DEBUG_INFO_NONE being the default for COMPILE_TEST. The mutually
exclusive relationship between DWARF5 and BTF must be inverted, but the
result remains the same. Additionally moves DEBUG_KERNEL and DEBUG_MISC
up to the top of the menu because they were enabling features _above_ it,
making it weird to navigate menuconfig.
[keescook@chromium.org: make DEBUG_INFO always default=n]
Link: https://lkml.kernel.org/r/20220128214131.580131-1-keescook@chromium.org
Link: https://lore.kernel.org/lkml/YfRY6+CaQxX7O8vF@dev-arch.archlinux-ax161
Link: https://lkml.kernel.org/r/20220125075126.891825-1-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/Kconfig.debug | 139 +++++++++++++++++++++++---------------------
1 file changed, 74 insertions(+), 65 deletions(-)
--- a/lib/Kconfig.debug~kconfigdebug-make-debug_info-selectable-from-a-choice
+++ a/lib/Kconfig.debug
@@ -208,20 +208,87 @@ config DEBUG_BUGVERBOSE
endmenu # "printk and dmesg options"
+config DEBUG_KERNEL
+ bool "Kernel debugging"
+ help
+ Say Y here if you are developing drivers or trying to debug and
+ identify kernel problems.
+
+config DEBUG_MISC
+ bool "Miscellaneous debug code"
+ default DEBUG_KERNEL
+ depends on DEBUG_KERNEL
+ help
+ Say Y here if you need to enable miscellaneous debug code that should
+ be under a more specific debug option but isn't.
+
menu "Compile-time checks and compiler options"
config DEBUG_INFO
- bool "Compile the kernel with debug info"
- depends on DEBUG_KERNEL && !COMPILE_TEST
+ bool
help
- If you say Y here the resulting kernel image will include
- debugging info resulting in a larger kernel image.
+ A kernel debug info option other than "None" has been selected
+ in the "Debug information" choice below, indicating that debug
+ information will be generated for build targets.
+
+choice
+ prompt "Debug information"
+ depends on DEBUG_KERNEL
+ help
+ Selecting something other than "None" results in a kernel image
+ that will include debugging info resulting in a larger kernel image.
This adds debug symbols to the kernel and modules (gcc -g), and
is needed if you intend to use kernel crashdump or binary object
tools like crash, kgdb, LKCD, gdb, etc on the kernel.
- Say Y here only if you plan to debug the kernel.
- If unsure, say N.
+ Choose which version of DWARF debug info to emit. If unsure,
+ select "Toolchain default".
+
+config DEBUG_INFO_NONE
+ bool "Disable debug information"
+ help
+ Do not build the kernel with debugging information, which will
+ result in a faster and smaller build.
+
+config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
+ bool "Rely on the toolchain's implicit default DWARF version"
+ select DEBUG_INFO
+ help
+ The implicit default version of DWARF debug info produced by a
+ toolchain changes over time.
+
+ This can break consumers of the debug info that haven't upgraded to
+ support newer revisions, and prevent testing newer versions, but
+ those should be less common scenarios.
+
+config DEBUG_INFO_DWARF4
+ bool "Generate DWARF Version 4 debuginfo"
+ select DEBUG_INFO
+ help
+ Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
+
+ If you have consumers of DWARF debug info that are not ready for
+ newer revisions of DWARF, you may wish to choose this or have your
+ config select this.
+
+config DEBUG_INFO_DWARF5
+ bool "Generate DWARF Version 5 debuginfo"
+ select DEBUG_INFO
+ depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502)))
+ help
+ Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc
+ 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
+ draft features until 7.0), and gdb 8.0+.
+
+ Changes to the structure of debug info in Version 5 allow for around
+ 15-18% savings in resulting image and debug info section sizes as
+ compared to DWARF Version 4. DWARF Version 5 standardizes previous
+ extensions such as accelerators for symbol indexing and the format
+ for fission (.dwo/.dwp) files. Users may not want to select this
+ config if they rely on tooling that has not yet been updated to
+ support DWARF Version 5.
+
+endchoice # "Debug information"
if DEBUG_INFO
@@ -267,56 +334,12 @@ config DEBUG_INFO_SPLIT
to know about the .dwo files and include them.
Incompatible with older versions of ccache.
-choice
- prompt "DWARF version"
- help
- Which version of DWARF debug info to emit.
-
-config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
- bool "Rely on the toolchain's implicit default DWARF version"
- help
- The implicit default version of DWARF debug info produced by a
- toolchain changes over time.
-
- This can break consumers of the debug info that haven't upgraded to
- support newer revisions, and prevent testing newer versions, but
- those should be less common scenarios.
-
- If unsure, say Y.
-
-config DEBUG_INFO_DWARF4
- bool "Generate DWARF Version 4 debuginfo"
- help
- Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
-
- If you have consumers of DWARF debug info that are not ready for
- newer revisions of DWARF, you may wish to choose this or have your
- config select this.
-
-config DEBUG_INFO_DWARF5
- bool "Generate DWARF Version 5 debuginfo"
- depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502)))
- depends on !DEBUG_INFO_BTF
- help
- Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc
- 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
- draft features until 7.0), and gdb 8.0+.
-
- Changes to the structure of debug info in Version 5 allow for around
- 15-18% savings in resulting image and debug info section sizes as
- compared to DWARF Version 4. DWARF Version 5 standardizes previous
- extensions such as accelerators for symbol indexing and the format
- for fission (.dwo/.dwp) files. Users may not want to select this
- config if they rely on tooling that has not yet been updated to
- support DWARF Version 5.
-
-endchoice # "DWARF version"
-
config DEBUG_INFO_BTF
bool "Generate BTF typeinfo"
depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
depends on BPF_SYSCALL
+ depends on !DEBUG_INFO_DWARF5
help
Generate deduplicated BTF type information from DWARF debug info.
Turning this on expects presence of pahole tool, which will convert
@@ -585,20 +608,6 @@ source "lib/Kconfig.kcsan"
endmenu
-config DEBUG_KERNEL
- bool "Kernel debugging"
- help
- Say Y here if you are developing drivers or trying to debug and
- identify kernel problems.
-
-config DEBUG_MISC
- bool "Miscellaneous debug code"
- default DEBUG_KERNEL
- depends on DEBUG_KERNEL
- help
- Say Y here if you need to enable miscellaneous debug code that should
- be under a more specific debug option but isn't.
-
menu "Networking Debugging"
source "net/Kconfig.debug"
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 08/41] include: drop pointless __compiler_offsetof indirection
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: ojeda, ndesaulniers, nathan, keescook, linux, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: include: drop pointless __compiler_offsetof indirection
(1) compiler_types.h is unconditionally included via an -include flag
(see scripts/Makefile.lib), and it defines __compiler_offsetof
unconditionally. So testing for definedness of __compiler_offsetof is
mostly pointless.
(2) Every relevant compiler provides __builtin_offsetof (even sparse
has had that for 14 years), and if for whatever reason one would end
up picking up the poor man's fallback definition (C file compiler with
completely custom CFLAGS?), newer clang versions won't treat the
result as an Integer Constant Expression, so if used in place where
such is required (static initializer or static_assert), one would get
errors like
t.c:11:16: error: static_assert expression is not an integral constant expression
t.c:11:16: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
t.c:4:33: note: expanded from macro 'offsetof'
#define offsetof(TYPE, MEMBER) ((size_t)&((TYPE *)0)->MEMBER)
So just define offsetof unconditionally and directly in terms of
__builtin_offsetof.
Link: https://lkml.kernel.org/r/20220202102147.326672-1-linux@rasmusvillemoes.dk
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/compiler_types.h | 2 --
include/linux/stddef.h | 6 +-----
2 files changed, 1 insertion(+), 7 deletions(-)
--- a/include/linux/compiler_types.h~include-drop-pointless-__compiler_offsetof-indirection
+++ a/include/linux/compiler_types.h
@@ -138,8 +138,6 @@ struct ftrace_likely_data {
*/
#define __naked __attribute__((__naked__)) notrace
-#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
-
/*
* Prefer gnu_inline, so that extern inline functions do not emit an
* externally visible function. This makes extern inline behave as per gnu89
--- a/include/linux/stddef.h~include-drop-pointless-__compiler_offsetof-indirection
+++ a/include/linux/stddef.h
@@ -13,11 +13,7 @@ enum {
};
#undef offsetof
-#ifdef __compiler_offsetof
-#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
-#else
-#define offsetof(TYPE, MEMBER) ((size_t)&((TYPE *)0)->MEMBER)
-#endif
+#define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER)
/**
* sizeof_field() - Report the size of a struct field in bytes
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 08/41] include: drop pointless __compiler_offsetof indirection
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: ojeda, ndesaulniers, nathan, keescook, linux, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: include: drop pointless __compiler_offsetof indirection
(1) compiler_types.h is unconditionally included via an -include flag
(see scripts/Makefile.lib), and it defines __compiler_offsetof
unconditionally. So testing for definedness of __compiler_offsetof is
mostly pointless.
(2) Every relevant compiler provides __builtin_offsetof (even sparse
has had that for 14 years), and if for whatever reason one would end
up picking up the poor man's fallback definition (C file compiler with
completely custom CFLAGS?), newer clang versions won't treat the
result as an Integer Constant Expression, so if used in place where
such is required (static initializer or static_assert), one would get
errors like
t.c:11:16: error: static_assert expression is not an integral constant expression
t.c:11:16: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
t.c:4:33: note: expanded from macro 'offsetof'
#define offsetof(TYPE, MEMBER) ((size_t)&((TYPE *)0)->MEMBER)
So just define offsetof unconditionally and directly in terms of
__builtin_offsetof.
Link: https://lkml.kernel.org/r/20220202102147.326672-1-linux@rasmusvillemoes.dk
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/compiler_types.h | 2 --
include/linux/stddef.h | 6 +-----
2 files changed, 1 insertion(+), 7 deletions(-)
--- a/include/linux/compiler_types.h~include-drop-pointless-__compiler_offsetof-indirection
+++ a/include/linux/compiler_types.h
@@ -138,8 +138,6 @@ struct ftrace_likely_data {
*/
#define __naked __attribute__((__naked__)) notrace
-#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
-
/*
* Prefer gnu_inline, so that extern inline functions do not emit an
* externally visible function. This makes extern inline behave as per gnu89
--- a/include/linux/stddef.h~include-drop-pointless-__compiler_offsetof-indirection
+++ a/include/linux/stddef.h
@@ -13,11 +13,7 @@ enum {
};
#undef offsetof
-#ifdef __compiler_offsetof
-#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
-#else
-#define offsetof(TYPE, MEMBER) ((size_t)&((TYPE *)0)->MEMBER)
-#endif
+#define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER)
/**
* sizeof_field() - Report the size of a struct field in bytes
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 09/41] ilog2: force inlining of __ilog2_u32() and __ilog2_u64()
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: christophe.leroy, akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Christophe Leroy <christophe.leroy@csgroup.eu>
Subject: ilog2: force inlining of __ilog2_u32() and __ilog2_u64()
Building a kernel with CONFIG_CC_OPTIMISE_FOR_SIZE leads to __ilog2_u32()
being duplicated 50 times and __ilog2_u64() 3 times in vmlinux on a tiny
powerpc32 config.
__ilog2_u32() being 2 instructions it is not worth being kept out of line,
so force inlining. Allthough the u64 version is a bit bigger, there is
still a small benefit in keeping it inlined. On a 64 bits config there's
a real benefit.
With this change the size of vmlinux text is reduced by 1 kbytes, which is
approx 50% more than the size of the removed functions.
Before the patch there is for instance:
c00d2a94 <__ilog2_u32>:
c00d2a94: 7c 63 00 34 cntlzw r3,r3
c00d2a98: 20 63 00 1f subfic r3,r3,31
c00d2a9c: 4e 80 00 20 blr
c00d36d8 <__order_base_2>:
c00d36d8: 28 03 00 01 cmplwi r3,1
c00d36dc: 40 81 00 2c ble c00d3708 <__order_base_2+0x30>
c00d36e0: 94 21 ff f0 stwu r1,-16(r1)
c00d36e4: 7c 08 02 a6 mflr r0
c00d36e8: 38 63 ff ff addi r3,r3,-1
c00d36ec: 90 01 00 14 stw r0,20(r1)
c00d36f0: 4b ff f3 a5 bl c00d2a94 <__ilog2_u32>
c00d36f4: 80 01 00 14 lwz r0,20(r1)
c00d36f8: 38 63 00 01 addi r3,r3,1
c00d36fc: 7c 08 03 a6 mtlr r0
c00d3700: 38 21 00 10 addi r1,r1,16
c00d3704: 4e 80 00 20 blr
c00d3708: 38 60 00 00 li r3,0
c00d370c: 4e 80 00 20 blr
With the patch it has become:
c00d356c <__order_base_2>:
c00d356c: 28 03 00 01 cmplwi r3,1
c00d3570: 40 81 00 14 ble c00d3584 <__order_base_2+0x18>
c00d3574: 38 63 ff ff addi r3,r3,-1
c00d3578: 7c 63 00 34 cntlzw r3,r3
c00d357c: 20 63 00 20 subfic r3,r3,32
c00d3580: 4e 80 00 20 blr
c00d3584: 38 60 00 00 li r3,0
c00d3588: 4e 80 00 20 blr
No more need for __order_base_2() to setup a stack frame and
save/restore caller address. And the following 'add 1' is
merged in the subtract.
Another typical use of it:
c080ff28 <hugepagesz_setup>:
...
c080fff8: 7f c3 f3 78 mr r3,r30
c080fffc: 4b 8f 81 f1 bl c01081ec <__ilog2_u32>
c0810000: 38 63 ff f2 addi r3,r3,-14
...
Becomes
c080ff1c <hugepagesz_setup>:
...
c080ffec: 7f c3 00 34 cntlzw r3,r30
c080fff0: 20 63 00 11 subfic r3,r3,17
...
Here no need to move r30 argument to r3 then substract 14 to result. Just
work on r30 and merge the 'sub 14' with the 'sub from 31'.
Link: https://lkml.kernel.org/r/803a2ac3d923ebcfd0dd40f5886b05cae7bb0aba.1644243860.git.christophe.leroy@csgroup.eu
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/log2.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/log2.h~ilog2-force-inlining-of-__ilog2_u32-and-__ilog2_u64
+++ a/include/linux/log2.h
@@ -18,7 +18,7 @@
* - the arch is not required to handle n==0 if implementing the fallback
*/
#ifndef CONFIG_ARCH_HAS_ILOG2_U32
-static inline __attribute__((const))
+static __always_inline __attribute__((const))
int __ilog2_u32(u32 n)
{
return fls(n) - 1;
@@ -26,7 +26,7 @@ int __ilog2_u32(u32 n)
#endif
#ifndef CONFIG_ARCH_HAS_ILOG2_U64
-static inline __attribute__((const))
+static __always_inline __attribute__((const))
int __ilog2_u64(u64 n)
{
return fls64(n) - 1;
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 09/41] ilog2: force inlining of __ilog2_u32() and __ilog2_u64()
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: christophe.leroy, akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Christophe Leroy <christophe.leroy@csgroup.eu>
Subject: ilog2: force inlining of __ilog2_u32() and __ilog2_u64()
Building a kernel with CONFIG_CC_OPTIMISE_FOR_SIZE leads to __ilog2_u32()
being duplicated 50 times and __ilog2_u64() 3 times in vmlinux on a tiny
powerpc32 config.
__ilog2_u32() being 2 instructions it is not worth being kept out of line,
so force inlining. Allthough the u64 version is a bit bigger, there is
still a small benefit in keeping it inlined. On a 64 bits config there's
a real benefit.
With this change the size of vmlinux text is reduced by 1 kbytes, which is
approx 50% more than the size of the removed functions.
Before the patch there is for instance:
c00d2a94 <__ilog2_u32>:
c00d2a94: 7c 63 00 34 cntlzw r3,r3
c00d2a98: 20 63 00 1f subfic r3,r3,31
c00d2a9c: 4e 80 00 20 blr
c00d36d8 <__order_base_2>:
c00d36d8: 28 03 00 01 cmplwi r3,1
c00d36dc: 40 81 00 2c ble c00d3708 <__order_base_2+0x30>
c00d36e0: 94 21 ff f0 stwu r1,-16(r1)
c00d36e4: 7c 08 02 a6 mflr r0
c00d36e8: 38 63 ff ff addi r3,r3,-1
c00d36ec: 90 01 00 14 stw r0,20(r1)
c00d36f0: 4b ff f3 a5 bl c00d2a94 <__ilog2_u32>
c00d36f4: 80 01 00 14 lwz r0,20(r1)
c00d36f8: 38 63 00 01 addi r3,r3,1
c00d36fc: 7c 08 03 a6 mtlr r0
c00d3700: 38 21 00 10 addi r1,r1,16
c00d3704: 4e 80 00 20 blr
c00d3708: 38 60 00 00 li r3,0
c00d370c: 4e 80 00 20 blr
With the patch it has become:
c00d356c <__order_base_2>:
c00d356c: 28 03 00 01 cmplwi r3,1
c00d3570: 40 81 00 14 ble c00d3584 <__order_base_2+0x18>
c00d3574: 38 63 ff ff addi r3,r3,-1
c00d3578: 7c 63 00 34 cntlzw r3,r3
c00d357c: 20 63 00 20 subfic r3,r3,32
c00d3580: 4e 80 00 20 blr
c00d3584: 38 60 00 00 li r3,0
c00d3588: 4e 80 00 20 blr
No more need for __order_base_2() to setup a stack frame and
save/restore caller address. And the following 'add 1' is
merged in the subtract.
Another typical use of it:
c080ff28 <hugepagesz_setup>:
...
c080fff8: 7f c3 f3 78 mr r3,r30
c080fffc: 4b 8f 81 f1 bl c01081ec <__ilog2_u32>
c0810000: 38 63 ff f2 addi r3,r3,-14
...
Becomes
c080ff1c <hugepagesz_setup>:
...
c080ffec: 7f c3 00 34 cntlzw r3,r30
c080fff0: 20 63 00 11 subfic r3,r3,17
...
Here no need to move r30 argument to r3 then substract 14 to result. Just
work on r30 and merge the 'sub 14' with the 'sub from 31'.
Link: https://lkml.kernel.org/r/803a2ac3d923ebcfd0dd40f5886b05cae7bb0aba.1644243860.git.christophe.leroy@csgroup.eu
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/log2.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/log2.h~ilog2-force-inlining-of-__ilog2_u32-and-__ilog2_u64
+++ a/include/linux/log2.h
@@ -18,7 +18,7 @@
* - the arch is not required to handle n==0 if implementing the fallback
*/
#ifndef CONFIG_ARCH_HAS_ILOG2_U32
-static inline __attribute__((const))
+static __always_inline __attribute__((const))
int __ilog2_u32(u32 n)
{
return fls(n) - 1;
@@ -26,7 +26,7 @@ int __ilog2_u32(u32 n)
#endif
#ifndef CONFIG_ARCH_HAS_ILOG2_U64
-static inline __attribute__((const))
+static __always_inline __attribute__((const))
int __ilog2_u64(u64 n)
{
return fls64(n) - 1;
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 10/41] bitfield: add explicit inclusions to the example
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: peterz, jsd, andriy.shevchenko, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: bitfield: add explicit inclusions to the example
It's not obvious that bitfield.h doesn't guarantee the bits.h inclusion
and the example in the former is confusing. Some developers think that
it's okay to just include bitfield.h to get it working. Change example to
explicitly include necessary headers in order to avoid confusion.
Link: https://lkml.kernel.org/r/20220207123341.47533-1-andriy.shevchenko@linux.intel.com
Fixes: 3e9b3112ec74 ("add basic register-field manipulation macros")
Depends-on: 8bd9cb51daac ("locking/atomics, asm-generic: Move some macros from <linux/bitops.h> to a new <linux/bits.h> file")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reported-by: Jan Dąbroś <jsd@semihalf.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/bitfield.h | 3 +++
1 file changed, 3 insertions(+)
--- a/include/linux/bitfield.h~bitfield-add-explicit-inclusions-to-the-example
+++ a/include/linux/bitfield.h
@@ -19,6 +19,9 @@
*
* Example:
*
+ * #include <linux/bitfield.h>
+ * #include <linux/bits.h>
+ *
* #define REG_FIELD_A GENMASK(6, 0)
* #define REG_FIELD_B BIT(7)
* #define REG_FIELD_C GENMASK(15, 8)
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 10/41] bitfield: add explicit inclusions to the example
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: peterz, jsd, andriy.shevchenko, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: bitfield: add explicit inclusions to the example
It's not obvious that bitfield.h doesn't guarantee the bits.h inclusion
and the example in the former is confusing. Some developers think that
it's okay to just include bitfield.h to get it working. Change example to
explicitly include necessary headers in order to avoid confusion.
Link: https://lkml.kernel.org/r/20220207123341.47533-1-andriy.shevchenko@linux.intel.com
Fixes: 3e9b3112ec74 ("add basic register-field manipulation macros")
Depends-on: 8bd9cb51daac ("locking/atomics, asm-generic: Move some macros from <linux/bitops.h> to a new <linux/bits.h> file")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reported-by: Jan Dąbroś <jsd@semihalf.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/bitfield.h | 3 +++
1 file changed, 3 insertions(+)
--- a/include/linux/bitfield.h~bitfield-add-explicit-inclusions-to-the-example
+++ a/include/linux/bitfield.h
@@ -19,6 +19,9 @@
*
* Example:
*
+ * #include <linux/bitfield.h>
+ * #include <linux/bits.h>
+ *
* #define REG_FIELD_A GENMASK(6, 0)
* #define REG_FIELD_B BIT(7)
* #define REG_FIELD_C GENMASK(15, 8)
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 11/41] lib/Kconfig.debug: add ARCH dependency for FUNCTION_ALIGN option
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: lkp, guoren, feng.tang, akpm, patches, linux-mm, mm-commits,
torvalds, akpm
From: Feng Tang <feng.tang@intel.com>
Subject: lib/Kconfig.debug: add ARCH dependency for FUNCTION_ALIGN option
0Day robots reported there is compiling issue for 'csky' ARCH
when CONFIG_DEBUG_FORCE_DATA_SECTION_ALIGNED is enabled [1]:
All errors (new ones prefixed by >>):
{standard input}: Assembler messages:
>> {standard input}:2277: Error: pcrel offset for branch to .LS000B too far (0x3c)
Which was discussed in [2]. And as there is no solution for csky yet, add
some dependency for this config to limit it to several ARCHs which have no
compiling issue so far.
[1]. https://lore.kernel.org/lkml/202202271612.W32UJAj2-lkp@intel.com/
[2]. https://www.spinics.net/lists/linux-kbuild/msg30298.html
Link: https://lkml.kernel.org/r/20220304021100.GN4548@shbuild999.sh.intel.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Feng Tang <feng.tang@intel.com>
Cc: Guo Ren <guoren@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/Kconfig.debug | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/lib/Kconfig.debug~lib-kconfigdebug-add-arch-dependency-for-function_align-option
+++ a/lib/Kconfig.debug
@@ -439,7 +439,8 @@ config SECTION_MISMATCH_WARN_ONLY
If unsure, say Y.
config DEBUG_FORCE_FUNCTION_ALIGN_64B
- bool "Force all function address 64B aligned" if EXPERT
+ bool "Force all function address 64B aligned"
+ depends on EXPERT && (X86_64 || ARM64 || PPC32 || PPC64 || ARC)
help
There are cases that a commit from one domain changes the function
address alignment of other domains, and cause magic performance
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 11/41] lib/Kconfig.debug: add ARCH dependency for FUNCTION_ALIGN option
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: lkp, guoren, feng.tang, akpm, patches, linux-mm, mm-commits,
torvalds, akpm
From: Feng Tang <feng.tang@intel.com>
Subject: lib/Kconfig.debug: add ARCH dependency for FUNCTION_ALIGN option
0Day robots reported there is compiling issue for 'csky' ARCH
when CONFIG_DEBUG_FORCE_DATA_SECTION_ALIGNED is enabled [1]:
All errors (new ones prefixed by >>):
{standard input}: Assembler messages:
>> {standard input}:2277: Error: pcrel offset for branch to .LS000B too far (0x3c)
Which was discussed in [2]. And as there is no solution for csky yet, add
some dependency for this config to limit it to several ARCHs which have no
compiling issue so far.
[1]. https://lore.kernel.org/lkml/202202271612.W32UJAj2-lkp@intel.com/
[2]. https://www.spinics.net/lists/linux-kbuild/msg30298.html
Link: https://lkml.kernel.org/r/20220304021100.GN4548@shbuild999.sh.intel.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Feng Tang <feng.tang@intel.com>
Cc: Guo Ren <guoren@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/Kconfig.debug | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/lib/Kconfig.debug~lib-kconfigdebug-add-arch-dependency-for-function_align-option
+++ a/lib/Kconfig.debug
@@ -439,7 +439,8 @@ config SECTION_MISMATCH_WARN_ONLY
If unsure, say Y.
config DEBUG_FORCE_FUNCTION_ALIGN_64B
- bool "Force all function address 64B aligned" if EXPERT
+ bool "Force all function address 64B aligned"
+ depends on EXPERT && (X86_64 || ARM64 || PPC32 || PPC64 || ARC)
help
There are cases that a commit from one domain changes the function
address alignment of other domains, and cause magic performance
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 12/41] lib: bitmap: fix many kernel-doc warnings
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: yury.norov, tiantao6, mike.travis, linux, gregkh,
andriy.shevchenko, rdunlap, akpm, patches, linux-mm, mm-commits,
torvalds, akpm
From: Randy Dunlap <rdunlap@infradead.org>
Subject: lib: bitmap: fix many kernel-doc warnings
Fix kernel-doc warings in lib/bitmap.c:
../lib/bitmap.c:498: warning: Function parameter or member 'buf' not described in 'bitmap_print_to_buf'
../lib/bitmap.c:498: warning: Function parameter or member 'maskp' not described in 'bitmap_print_to_buf'
../lib/bitmap.c:498: warning: Function parameter or member 'nmaskbits' not described in 'bitmap_print_to_buf'
../lib/bitmap.c:498: warning: Function parameter or member 'off' not described in 'bitmap_print_to_buf'
../lib/bitmap.c:498: warning: Function parameter or member 'count' not described in 'bitmap_print_to_buf'
../lib/bitmap.c:561: warning: contents before sections
../lib/bitmap.c:606: warning: Function parameter or member 'buf' not described in 'bitmap_print_list_to_buf'
../lib/bitmap.c:606: warning: Function parameter or member 'maskp' not described in 'bitmap_print_list_to_buf'
../lib/bitmap.c:606: warning: Function parameter or member 'nmaskbits' not described in 'bitmap_print_list_to_buf'
../lib/bitmap.c:606: warning: Function parameter or member 'off' not described in 'bitmap_print_list_to_buf'
../lib/bitmap.c:606: warning: Function parameter or member 'count' not described in 'bitmap_print_list_to_buf'
../lib/bitmap.c:819: warning: missing initial short description on line:
* bitmap_parselist_user()
This still leaves 15 warnings for function return values not described,
similar to this one:
bitmap.c:890: warning: No description found for return value of 'bitmap_parse'
Link: https://lkml.kernel.org/r/20220306065823.5153-1-rdunlap@infradead.org
Fixes: 1fae562983ca ("cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list")
Fixes: 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Tian Tao <tiantao6@hisilicon.com>
Cc: Mike Travis <mike.travis@hpe.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/bitmap.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
--- a/lib/bitmap.c~lib-bitmap-fix-many-kernel-doc-warnings
+++ a/lib/bitmap.c
@@ -492,6 +492,11 @@ EXPORT_SYMBOL(bitmap_print_to_pagebuf);
* @list: indicates whether the bitmap must be list
* true: print in decimal list format
* false: print in hexadecimal bitmask format
+ * @buf: buffer into which string is placed
+ * @maskp: pointer to bitmap to convert
+ * @nmaskbits: size of bitmap, in bits
+ * @off: in the string from which we are copying, We copy to @buf
+ * @count: the maximum number of bytes to print
*/
static int bitmap_print_to_buf(bool list, char *buf, const unsigned long *maskp,
int nmaskbits, loff_t off, size_t count)
@@ -512,6 +517,11 @@ static int bitmap_print_to_buf(bool list
/**
* bitmap_print_bitmask_to_buf - convert bitmap to hex bitmask format ASCII string
+ * @buf: buffer into which string is placed
+ * @maskp: pointer to bitmap to convert
+ * @nmaskbits: size of bitmap, in bits
+ * @off: in the string from which we are copying, We copy to @buf
+ * @count: the maximum number of bytes to print
*
* The bitmap_print_to_pagebuf() is used indirectly via its cpumap wrapper
* cpumap_print_to_pagebuf() or directly by drivers to export hexadecimal
@@ -553,12 +563,6 @@ static int bitmap_print_to_buf(bool list
* move to use bin_attribute. In result, we have to pass the corresponding
* parameters such as off, count from bin_attribute show entry to this API.
*
- * @buf: buffer into which string is placed
- * @maskp: pointer to bitmap to convert
- * @nmaskbits: size of bitmap, in bits
- * @off: in the string from which we are copying, We copy to @buf
- * @count: the maximum number of bytes to print
- *
* The role of cpumap_print_bitmask_to_buf() and cpumap_print_list_to_buf()
* is similar with cpumap_print_to_pagebuf(), the difference is that
* bitmap_print_to_pagebuf() mainly serves sysfs attribute with the assumption
@@ -597,6 +601,11 @@ EXPORT_SYMBOL(bitmap_print_bitmask_to_bu
/**
* bitmap_print_list_to_buf - convert bitmap to decimal list format ASCII string
+ * @buf: buffer into which string is placed
+ * @maskp: pointer to bitmap to convert
+ * @nmaskbits: size of bitmap, in bits
+ * @off: in the string from which we are copying, We copy to @buf
+ * @count: the maximum number of bytes to print
*
* Everything is same with the above bitmap_print_bitmask_to_buf() except
* the print format.
@@ -807,7 +816,8 @@ EXPORT_SYMBOL(bitmap_parselist);
/**
- * bitmap_parselist_user()
+ * bitmap_parselist_user() - convert user buffer's list format ASCII
+ * string to bitmap
*
* @ubuf: pointer to user buffer containing string.
* @ulen: buffer size in bytes. If string is smaller than this
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 12/41] lib: bitmap: fix many kernel-doc warnings
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: yury.norov, tiantao6, mike.travis, linux, gregkh,
andriy.shevchenko, rdunlap, akpm, patches, linux-mm, mm-commits,
torvalds, akpm
From: Randy Dunlap <rdunlap@infradead.org>
Subject: lib: bitmap: fix many kernel-doc warnings
Fix kernel-doc warings in lib/bitmap.c:
../lib/bitmap.c:498: warning: Function parameter or member 'buf' not described in 'bitmap_print_to_buf'
../lib/bitmap.c:498: warning: Function parameter or member 'maskp' not described in 'bitmap_print_to_buf'
../lib/bitmap.c:498: warning: Function parameter or member 'nmaskbits' not described in 'bitmap_print_to_buf'
../lib/bitmap.c:498: warning: Function parameter or member 'off' not described in 'bitmap_print_to_buf'
../lib/bitmap.c:498: warning: Function parameter or member 'count' not described in 'bitmap_print_to_buf'
../lib/bitmap.c:561: warning: contents before sections
../lib/bitmap.c:606: warning: Function parameter or member 'buf' not described in 'bitmap_print_list_to_buf'
../lib/bitmap.c:606: warning: Function parameter or member 'maskp' not described in 'bitmap_print_list_to_buf'
../lib/bitmap.c:606: warning: Function parameter or member 'nmaskbits' not described in 'bitmap_print_list_to_buf'
../lib/bitmap.c:606: warning: Function parameter or member 'off' not described in 'bitmap_print_list_to_buf'
../lib/bitmap.c:606: warning: Function parameter or member 'count' not described in 'bitmap_print_list_to_buf'
../lib/bitmap.c:819: warning: missing initial short description on line:
* bitmap_parselist_user()
This still leaves 15 warnings for function return values not described,
similar to this one:
bitmap.c:890: warning: No description found for return value of 'bitmap_parse'
Link: https://lkml.kernel.org/r/20220306065823.5153-1-rdunlap@infradead.org
Fixes: 1fae562983ca ("cpumask: introduce cpumap_print_list/bitmask_to_buf to support large bitmask and list")
Fixes: 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Tian Tao <tiantao6@hisilicon.com>
Cc: Mike Travis <mike.travis@hpe.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/bitmap.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
--- a/lib/bitmap.c~lib-bitmap-fix-many-kernel-doc-warnings
+++ a/lib/bitmap.c
@@ -492,6 +492,11 @@ EXPORT_SYMBOL(bitmap_print_to_pagebuf);
* @list: indicates whether the bitmap must be list
* true: print in decimal list format
* false: print in hexadecimal bitmask format
+ * @buf: buffer into which string is placed
+ * @maskp: pointer to bitmap to convert
+ * @nmaskbits: size of bitmap, in bits
+ * @off: in the string from which we are copying, We copy to @buf
+ * @count: the maximum number of bytes to print
*/
static int bitmap_print_to_buf(bool list, char *buf, const unsigned long *maskp,
int nmaskbits, loff_t off, size_t count)
@@ -512,6 +517,11 @@ static int bitmap_print_to_buf(bool list
/**
* bitmap_print_bitmask_to_buf - convert bitmap to hex bitmask format ASCII string
+ * @buf: buffer into which string is placed
+ * @maskp: pointer to bitmap to convert
+ * @nmaskbits: size of bitmap, in bits
+ * @off: in the string from which we are copying, We copy to @buf
+ * @count: the maximum number of bytes to print
*
* The bitmap_print_to_pagebuf() is used indirectly via its cpumap wrapper
* cpumap_print_to_pagebuf() or directly by drivers to export hexadecimal
@@ -553,12 +563,6 @@ static int bitmap_print_to_buf(bool list
* move to use bin_attribute. In result, we have to pass the corresponding
* parameters such as off, count from bin_attribute show entry to this API.
*
- * @buf: buffer into which string is placed
- * @maskp: pointer to bitmap to convert
- * @nmaskbits: size of bitmap, in bits
- * @off: in the string from which we are copying, We copy to @buf
- * @count: the maximum number of bytes to print
- *
* The role of cpumap_print_bitmask_to_buf() and cpumap_print_list_to_buf()
* is similar with cpumap_print_to_pagebuf(), the difference is that
* bitmap_print_to_pagebuf() mainly serves sysfs attribute with the assumption
@@ -597,6 +601,11 @@ EXPORT_SYMBOL(bitmap_print_bitmask_to_bu
/**
* bitmap_print_list_to_buf - convert bitmap to decimal list format ASCII string
+ * @buf: buffer into which string is placed
+ * @maskp: pointer to bitmap to convert
+ * @nmaskbits: size of bitmap, in bits
+ * @off: in the string from which we are copying, We copy to @buf
+ * @count: the maximum number of bytes to print
*
* Everything is same with the above bitmap_print_bitmask_to_buf() except
* the print format.
@@ -807,7 +816,8 @@ EXPORT_SYMBOL(bitmap_parselist);
/**
- * bitmap_parselist_user()
+ * bitmap_parselist_user() - convert user buffer's list format ASCII
+ * string to bitmap
*
* @ubuf: pointer to user buffer containing string.
* @ulen: buffer size in bytes. If string is smaller than this
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 13/41] checkpatch: prefer MODULE_LICENSE("GPL") over MODULE_LICENSE("GPL v2")
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: lukas.bulwahn, dwaipayanray1, joe, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Joe Perches <joe@perches.com>
Subject: checkpatch: prefer MODULE_LICENSE("GPL") over MODULE_LICENSE("GPL v2")
There is no effective difference.
Given the large number of uses of "GPL v2", emit this message only for
patches as a trivial treeside sed could be done one day.
Ref: commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity")
Link: https://lkml.kernel.org/r/20220128185924.80137-1-joe@perches.com
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Dwaipayan Ray <dwaipayanray1@gmail.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/checkpatch.pl | 7 +++++++
1 file changed, 7 insertions(+)
--- a/scripts/checkpatch.pl~checkpatch-prefer-module_licensegpl-over-module_licensegpl-v2
+++ a/scripts/checkpatch.pl
@@ -7418,6 +7418,13 @@ sub process {
WARN("MODULE_LICENSE",
"unknown module license " . $extracted_string . "\n" . $herecurr);
}
+ if (!$file && $extracted_string eq '"GPL v2"') {
+ if (WARN("MODULE_LICENSE",
+ "Prefer \"GPL\" over \"GPL v2\" - see commit bf7fbeeae6db (\"module: Cure the MODULE_LICENSE \"GPL\" vs. \"GPL v2\" bogosity\")\n" . $herecurr) &&
+ $fix) {
+ $fixed[$fixlinenr] =~ s/\bMODULE_LICENSE\s*\(\s*"GPL v2"\s*\)/MODULE_LICENSE("GPL")/;
+ }
+ }
}
# check for sysctl duplicate constants
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 13/41] checkpatch: prefer MODULE_LICENSE("GPL") over MODULE_LICENSE("GPL v2")
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: lukas.bulwahn, dwaipayanray1, joe, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Joe Perches <joe@perches.com>
Subject: checkpatch: prefer MODULE_LICENSE("GPL") over MODULE_LICENSE("GPL v2")
There is no effective difference.
Given the large number of uses of "GPL v2", emit this message only for
patches as a trivial treeside sed could be done one day.
Ref: commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity")
Link: https://lkml.kernel.org/r/20220128185924.80137-1-joe@perches.com
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Dwaipayan Ray <dwaipayanray1@gmail.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/checkpatch.pl | 7 +++++++
1 file changed, 7 insertions(+)
--- a/scripts/checkpatch.pl~checkpatch-prefer-module_licensegpl-over-module_licensegpl-v2
+++ a/scripts/checkpatch.pl
@@ -7418,6 +7418,13 @@ sub process {
WARN("MODULE_LICENSE",
"unknown module license " . $extracted_string . "\n" . $herecurr);
}
+ if (!$file && $extracted_string eq '"GPL v2"') {
+ if (WARN("MODULE_LICENSE",
+ "Prefer \"GPL\" over \"GPL v2\" - see commit bf7fbeeae6db (\"module: Cure the MODULE_LICENSE \"GPL\" vs. \"GPL v2\" bogosity\")\n" . $herecurr) &&
+ $fix) {
+ $fixed[$fixlinenr] =~ s/\bMODULE_LICENSE\s*\(\s*"GPL v2"\s*\)/MODULE_LICENSE("GPL")/;
+ }
+ }
}
# check for sysctl duplicate constants
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 14/41] checkpatch: add --fix option for some TRAILING_STATEMENTS
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:05 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: lukas.bulwahn, dwaipayanray1, joe, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Joe Perches <joe@perches.com>
Subject: checkpatch: add --fix option for some TRAILING_STATEMENTS
Single line code like:
if (foo) bar;
should generally be written:
if (foo)
bar;
Add a --fix test to do so.
This fix is not done when an ASSIGN_IN_IF in the same line exists.
Link: https://lkml.kernel.org/r/20220128185924.80137-2-joe@perches.com
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Dwaipayan Ray <dwaipayanray1@gmail.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/checkpatch.pl | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
--- a/scripts/checkpatch.pl~checkpatch-add-fix-option-for-some-trailing_statements
+++ a/scripts/checkpatch.pl
@@ -5551,6 +5551,7 @@ sub process {
defined($stat) && defined($cond) &&
$line =~ /\b(?:if|while|for)\s*\(/ && $line !~ /^.\s*#/) {
my ($s, $c) = ($stat, $cond);
+ my $fixed_assign_in_if = 0;
if ($c =~ /\bif\s*\(.*[^<>!=]=[^=].*/s) {
if (ERROR("ASSIGN_IN_IF",
@@ -5575,6 +5576,7 @@ sub process {
$newline .= ')';
$newline .= " {" if (defined($brace));
fix_insert_line($fixlinenr + 1, $newline);
+ $fixed_assign_in_if = 1;
}
}
}
@@ -5598,8 +5600,20 @@ sub process {
$stat_real = "[...]\n$stat_real";
}
- ERROR("TRAILING_STATEMENTS",
- "trailing statements should be on next line\n" . $herecurr . $stat_real);
+ if (ERROR("TRAILING_STATEMENTS",
+ "trailing statements should be on next line\n" . $herecurr . $stat_real) &&
+ !$fixed_assign_in_if &&
+ $cond_lines == 0 &&
+ $fix && $perl_version_ok &&
+ $fixed[$fixlinenr] =~ /^\+(\s*)((?:if|while|for)\s*$balanced_parens)\s*(.*)$/) {
+ my $indent = $1;
+ my $test = $2;
+ my $rest = rtrim($4);
+ if ($rest =~ /;$/) {
+ $fixed[$fixlinenr] = "\+$indent$test";
+ fix_insert_line($fixlinenr + 1, "$indent\t$rest");
+ }
+ }
}
}
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 14/41] checkpatch: add --fix option for some TRAILING_STATEMENTS
@ 2022-03-23 23:05 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:05 UTC (permalink / raw)
To: lukas.bulwahn, dwaipayanray1, joe, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Joe Perches <joe@perches.com>
Subject: checkpatch: add --fix option for some TRAILING_STATEMENTS
Single line code like:
if (foo) bar;
should generally be written:
if (foo)
bar;
Add a --fix test to do so.
This fix is not done when an ASSIGN_IN_IF in the same line exists.
Link: https://lkml.kernel.org/r/20220128185924.80137-2-joe@perches.com
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Dwaipayan Ray <dwaipayanray1@gmail.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/checkpatch.pl | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
--- a/scripts/checkpatch.pl~checkpatch-add-fix-option-for-some-trailing_statements
+++ a/scripts/checkpatch.pl
@@ -5551,6 +5551,7 @@ sub process {
defined($stat) && defined($cond) &&
$line =~ /\b(?:if|while|for)\s*\(/ && $line !~ /^.\s*#/) {
my ($s, $c) = ($stat, $cond);
+ my $fixed_assign_in_if = 0;
if ($c =~ /\bif\s*\(.*[^<>!=]=[^=].*/s) {
if (ERROR("ASSIGN_IN_IF",
@@ -5575,6 +5576,7 @@ sub process {
$newline .= ')';
$newline .= " {" if (defined($brace));
fix_insert_line($fixlinenr + 1, $newline);
+ $fixed_assign_in_if = 1;
}
}
}
@@ -5598,8 +5600,20 @@ sub process {
$stat_real = "[...]\n$stat_real";
}
- ERROR("TRAILING_STATEMENTS",
- "trailing statements should be on next line\n" . $herecurr . $stat_real);
+ if (ERROR("TRAILING_STATEMENTS",
+ "trailing statements should be on next line\n" . $herecurr . $stat_real) &&
+ !$fixed_assign_in_if &&
+ $cond_lines == 0 &&
+ $fix && $perl_version_ok &&
+ $fixed[$fixlinenr] =~ /^\+(\s*)((?:if|while|for)\s*$balanced_parens)\s*(.*)$/) {
+ my $indent = $1;
+ my $test = $2;
+ my $rest = rtrim($4);
+ if ($rest =~ /;$/) {
+ $fixed[$fixlinenr] = "\+$indent$test";
+ fix_insert_line($fixlinenr + 1, "$indent\t$rest");
+ }
+ }
}
}
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 15/41] checkpatch: add early_param exception to blank line after struct/function test
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: lukas.bulwahn, dwaipayanray1, joe, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Joe Perches <joe@perches.com>
Subject: checkpatch: add early_param exception to blank line after struct/function test
Add early_param as another exception to the blank line preferred after
function/struct/union declaration or definition test.
Link: https://lkml.kernel.org/r/3bd6ada59f411a7685d7e64eeb670540d4bfdcde.camel@perches.com
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Dwaipayan Ray <dwaipayanray1@gmail.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/scripts/checkpatch.pl~checkpatch-add-early_param-exception-to-blank-line-after-struct-function-test
+++ a/scripts/checkpatch.pl
@@ -3926,7 +3926,7 @@ sub process {
if ($prevline =~ /^[\+ ]};?\s*$/ &&
$line =~ /^\+/ &&
!($line =~ /^\+\s*$/ ||
- $line =~ /^\+\s*EXPORT_SYMBOL/ ||
+ $line =~ /^\+\s*(?:EXPORT_SYMBOL|early_param)/ ||
$line =~ /^\+\s*MODULE_/i ||
$line =~ /^\+\s*\#\s*(?:end|elif|else)/ ||
$line =~ /^\+[a-z_]*init/ ||
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 15/41] checkpatch: add early_param exception to blank line after struct/function test
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: lukas.bulwahn, dwaipayanray1, joe, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Joe Perches <joe@perches.com>
Subject: checkpatch: add early_param exception to blank line after struct/function test
Add early_param as another exception to the blank line preferred after
function/struct/union declaration or definition test.
Link: https://lkml.kernel.org/r/3bd6ada59f411a7685d7e64eeb670540d4bfdcde.camel@perches.com
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Dwaipayan Ray <dwaipayanray1@gmail.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/scripts/checkpatch.pl~checkpatch-add-early_param-exception-to-blank-line-after-struct-function-test
+++ a/scripts/checkpatch.pl
@@ -3926,7 +3926,7 @@ sub process {
if ($prevline =~ /^[\+ ]};?\s*$/ &&
$line =~ /^\+/ &&
!($line =~ /^\+\s*$/ ||
- $line =~ /^\+\s*EXPORT_SYMBOL/ ||
+ $line =~ /^\+\s*(?:EXPORT_SYMBOL|early_param)/ ||
$line =~ /^\+\s*MODULE_/i ||
$line =~ /^\+\s*\#\s*(?:end|elif|else)/ ||
$line =~ /^\+[a-z_]*init/ ||
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 16/41] checkpatch: use python3 to find codespell dictionary
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: peter.ujfalusi, joe, sagarmp, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Sagar Patel <sagarmp@cs.unc.edu>
Subject: checkpatch: use python3 to find codespell dictionary
Commit 0ee3e7b8893e ("checkpatch: get default codespell dictionary path
from package location") introduced the ability to search for the codespell
dictionary rather than hardcoding its path.
codespell requires Python 3.6 or above, but on some systems, the python
executable is a Python 2.7 interpreter. In this case, searching for the
dictionary fails, subsequently making codespell fail:
No codespell typos will be found - file '/usr/share/codespell/dictionary.txt': No such file or directory
So, use python3 to remove ambiguity.
In addition, when searching for dictionary.txt, do not check if the
codespell executable exists since,
- checkpatch.pl only uses dictionary.txt, not the codespell
executable.
- codespell can be installed via a Python package manager, in which
case the codespell executable may not be present in a typical $PATH,
but a dictionary does exist.
Link: https://lkml.kernel.org/r/20220309180048.147672-1-sagarmp@cs.unc.edu
Signed-off-by: Sagar Patel <sagarmp@cs.unc.edu>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/checkpatch.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/scripts/checkpatch.pl~checkpatch-use-python3-to-find-codespell-dictionary
+++ a/scripts/checkpatch.pl
@@ -334,7 +334,7 @@ if ($user_codespellfile) {
} elsif (!(-f $codespellfile)) {
# If /usr/share/codespell/dictionary.txt is not present, try to find it
# under codespell's install directory: <codespell_root>/data/dictionary.txt
- if (($codespell || $help) && which("codespell") ne "" && which("python") ne "") {
+ if (($codespell || $help) && which("python3") ne "") {
my $python_codespell_dict = << "EOF";
import os.path as op
@@ -344,7 +344,7 @@ codespell_file = op.join(codespell_dir,
print(codespell_file, end='')
EOF
- my $codespell_dict = `python -c "$python_codespell_dict" 2> /dev/null`;
+ my $codespell_dict = `python3 -c "$python_codespell_dict" 2> /dev/null`;
$codespellfile = $codespell_dict if (-f $codespell_dict);
}
}
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 16/41] checkpatch: use python3 to find codespell dictionary
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: peter.ujfalusi, joe, sagarmp, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Sagar Patel <sagarmp@cs.unc.edu>
Subject: checkpatch: use python3 to find codespell dictionary
Commit 0ee3e7b8893e ("checkpatch: get default codespell dictionary path
from package location") introduced the ability to search for the codespell
dictionary rather than hardcoding its path.
codespell requires Python 3.6 or above, but on some systems, the python
executable is a Python 2.7 interpreter. In this case, searching for the
dictionary fails, subsequently making codespell fail:
No codespell typos will be found - file '/usr/share/codespell/dictionary.txt': No such file or directory
So, use python3 to remove ambiguity.
In addition, when searching for dictionary.txt, do not check if the
codespell executable exists since,
- checkpatch.pl only uses dictionary.txt, not the codespell
executable.
- codespell can be installed via a Python package manager, in which
case the codespell executable may not be present in a typical $PATH,
but a dictionary does exist.
Link: https://lkml.kernel.org/r/20220309180048.147672-1-sagarmp@cs.unc.edu
Signed-off-by: Sagar Patel <sagarmp@cs.unc.edu>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/checkpatch.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/scripts/checkpatch.pl~checkpatch-use-python3-to-find-codespell-dictionary
+++ a/scripts/checkpatch.pl
@@ -334,7 +334,7 @@ if ($user_codespellfile) {
} elsif (!(-f $codespellfile)) {
# If /usr/share/codespell/dictionary.txt is not present, try to find it
# under codespell's install directory: <codespell_root>/data/dictionary.txt
- if (($codespell || $help) && which("codespell") ne "" && which("python") ne "") {
+ if (($codespell || $help) && which("python3") ne "") {
my $python_codespell_dict = << "EOF";
import os.path as op
@@ -344,7 +344,7 @@ codespell_file = op.join(codespell_dir,
print(codespell_file, end='')
EOF
- my $codespell_dict = `python -c "$python_codespell_dict" 2> /dev/null`;
+ my $codespell_dict = `python3 -c "$python_codespell_dict" 2> /dev/null`;
$codespellfile = $codespell_dict if (-f $codespell_dict);
}
}
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 17/41] init: use ktime_us_delta() to make initcall_debug log more precise
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: yj.chiang, wangkefeng.wang, vbabka, valentin.schneider, rostedt,
peterz, mhiramat, matthias.bgg, linux, keescook, ahalaney,
mark-pk.tsai, akpm, patches, linux-mm, mm-commits, torvalds,
akpm
From: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Subject: init: use ktime_us_delta() to make initcall_debug log more precise
Use ktime_us_delta() to make the initcall_debug log more precise than
right shifting the result of ktime_to_ns() by 10 bits.
Link: https://lkml.kernel.org/r/20220209053350.15771-1-mark-pk.tsai@mediatek.com
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Kees Cook <keescook@chromium.org>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: YJ Chiang <yj.chiang@mediatek.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
init/main.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/init/main.c~init-use-ktime_us_delta-to-make-initcall_debug-log-more-precise
+++ a/init/main.c
@@ -1246,15 +1246,11 @@ trace_initcall_start_cb(void *data, init
static __init_or_module void
trace_initcall_finish_cb(void *data, initcall_t fn, int ret)
{
- ktime_t *calltime = (ktime_t *)data;
- ktime_t delta, rettime;
- unsigned long long duration;
+ ktime_t rettime, *calltime = (ktime_t *)data;
rettime = ktime_get();
- delta = ktime_sub(rettime, *calltime);
- duration = (unsigned long long) ktime_to_ns(delta) >> 10;
printk(KERN_DEBUG "initcall %pS returned %d after %lld usecs\n",
- fn, ret, duration);
+ fn, ret, (unsigned long long)ktime_us_delta(rettime, *calltime));
}
static ktime_t initcall_calltime;
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 17/41] init: use ktime_us_delta() to make initcall_debug log more precise
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: yj.chiang, wangkefeng.wang, vbabka, valentin.schneider, rostedt,
peterz, mhiramat, matthias.bgg, linux, keescook, ahalaney,
mark-pk.tsai, akpm, patches, linux-mm, mm-commits, torvalds,
akpm
From: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Subject: init: use ktime_us_delta() to make initcall_debug log more precise
Use ktime_us_delta() to make the initcall_debug log more precise than
right shifting the result of ktime_to_ns() by 10 bits.
Link: https://lkml.kernel.org/r/20220209053350.15771-1-mark-pk.tsai@mediatek.com
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Kees Cook <keescook@chromium.org>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: YJ Chiang <yj.chiang@mediatek.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
init/main.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/init/main.c~init-use-ktime_us_delta-to-make-initcall_debug-log-more-precise
+++ a/init/main.c
@@ -1246,15 +1246,11 @@ trace_initcall_start_cb(void *data, init
static __init_or_module void
trace_initcall_finish_cb(void *data, initcall_t fn, int ret)
{
- ktime_t *calltime = (ktime_t *)data;
- ktime_t delta, rettime;
- unsigned long long duration;
+ ktime_t rettime, *calltime = (ktime_t *)data;
rettime = ktime_get();
- delta = ktime_sub(rettime, *calltime);
- duration = (unsigned long long) ktime_to_ns(delta) >> 10;
printk(KERN_DEBUG "initcall %pS returned %d after %lld usecs\n",
- fn, ret, duration);
+ fn, ret, (unsigned long long)ktime_us_delta(rettime, *calltime));
}
static ktime_t initcall_calltime;
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 18/41] init.h: improve __setup and early_param documentation
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: mingo, i.zhbanov, gregkh, rdunlap, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Randy Dunlap <rdunlap@infradead.org>
Subject: init.h: improve __setup and early_param documentation
Igor noted in [1] that there are quite a few __setup() handling functions
that return incorrect values. Doing this can be harmless, but it can also
cause strings to be added to init's argument or environment list,
polluting them.
Since __setup() handling and return values are not documented, first add
documentation for that. Also add more documentation for early_param()
handling and return values.
For __setup() functions, returning 0 (not handled) has questionable
value if it is just a malformed option value, as in
rodata=junk
since returning 0 would just cause "rodata=junk" to be added to init's
environment unnecessarily:
Run /sbin/init as init process
with arguments:
/sbin/init
with environment:
HOME=/
TERM=linux
splash=native
rodata=junk
Also, there are no recommendations on whether to print a warning when an
unknown parameter value is seen. I am not addressing that here.
[1] lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Link: https://lkml.kernel.org/r/20220221050852.1147-1-rdunlap@infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Igor Zhbanov <i.zhbanov@omprussia.ru>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/init.h | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/include/linux/init.h~inith-improve-__setup-and-early_param-documentation
+++ a/include/linux/init.h
@@ -320,12 +320,19 @@ struct obs_kernel_param {
__aligned(__alignof__(struct obs_kernel_param)) \
= { __setup_str_##unique_id, fn, early }
+/*
+ * NOTE: __setup functions return values:
+ * @fn returns 1 (or non-zero) if the option argument is "handled"
+ * and returns 0 if the option argument is "not handled".
+ */
#define __setup(str, fn) \
__setup_param(str, fn, fn, 0)
/*
- * NOTE: fn is as per module_param, not __setup!
- * Emits warning if fn returns non-zero.
+ * NOTE: @fn is as per module_param, not __setup!
+ * I.e., @fn returns 0 for no error or non-zero for error
+ * (possibly @fn returns a -errno value, but it does not matter).
+ * Emits warning if @fn returns non-zero.
*/
#define early_param(str, fn) \
__setup_param(str, fn, fn, 1)
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 18/41] init.h: improve __setup and early_param documentation
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: mingo, i.zhbanov, gregkh, rdunlap, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Randy Dunlap <rdunlap@infradead.org>
Subject: init.h: improve __setup and early_param documentation
Igor noted in [1] that there are quite a few __setup() handling functions
that return incorrect values. Doing this can be harmless, but it can also
cause strings to be added to init's argument or environment list,
polluting them.
Since __setup() handling and return values are not documented, first add
documentation for that. Also add more documentation for early_param()
handling and return values.
For __setup() functions, returning 0 (not handled) has questionable
value if it is just a malformed option value, as in
rodata=junk
since returning 0 would just cause "rodata=junk" to be added to init's
environment unnecessarily:
Run /sbin/init as init process
with arguments:
/sbin/init
with environment:
HOME=/
TERM=linux
splash=native
rodata=junk
Also, there are no recommendations on whether to print a warning when an
unknown parameter value is seen. I am not addressing that here.
[1] lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Link: https://lkml.kernel.org/r/20220221050852.1147-1-rdunlap@infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Igor Zhbanov <i.zhbanov@omprussia.ru>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/init.h | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/include/linux/init.h~inith-improve-__setup-and-early_param-documentation
+++ a/include/linux/init.h
@@ -320,12 +320,19 @@ struct obs_kernel_param {
__aligned(__alignof__(struct obs_kernel_param)) \
= { __setup_str_##unique_id, fn, early }
+/*
+ * NOTE: __setup functions return values:
+ * @fn returns 1 (or non-zero) if the option argument is "handled"
+ * and returns 0 if the option argument is "not handled".
+ */
#define __setup(str, fn) \
__setup_param(str, fn, fn, 0)
/*
- * NOTE: fn is as per module_param, not __setup!
- * Emits warning if fn returns non-zero.
+ * NOTE: @fn is as per module_param, not __setup!
+ * I.e., @fn returns 0 for no error or non-zero for error
+ * (possibly @fn returns a -errno value, but it does not matter).
+ * Emits warning if @fn returns non-zero.
*/
#define early_param(str, fn) \
__setup_param(str, fn, fn, 1)
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 19/41] init/main.c: return 1 from handled __setup() functions
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: mingo, i.zhbanov, gregkh, rdunlap, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Randy Dunlap <rdunlap@infradead.org>
Subject: init/main.c: return 1 from handled __setup() functions
initcall_blacklist() should return 1 to indicate that it handled its
cmdline arguments.
set_debug_rodata() should return 1 to indicate that it handled its cmdline
arguments. Print a warning if the option string is invalid.
This prevents these strings from being added to the 'init' program's
environment as they are not init arguments/parameters.
Link: https://lkml.kernel.org/r/20220221050901.23985-1-rdunlap@infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Igor Zhbanov <i.zhbanov@omprussia.ru>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
init/main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/init/main.c~init-mainc-return-1-from-handled-__setup-functions
+++ a/init/main.c
@@ -1190,7 +1190,7 @@ static int __init initcall_blacklist(cha
}
} while (str_entry);
- return 0;
+ return 1;
}
static bool __init_or_module initcall_blacklisted(initcall_t fn)
@@ -1448,7 +1448,9 @@ static noinline void __init kernel_init_
bool rodata_enabled __ro_after_init = true;
static int __init set_debug_rodata(char *str)
{
- return strtobool(str, &rodata_enabled);
+ if (strtobool(str, &rodata_enabled))
+ pr_warn("Invalid option string for rodata: '%s'\n", str);
+ return 1;
}
__setup("rodata=", set_debug_rodata);
#endif
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 19/41] init/main.c: return 1 from handled __setup() functions
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: mingo, i.zhbanov, gregkh, rdunlap, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Randy Dunlap <rdunlap@infradead.org>
Subject: init/main.c: return 1 from handled __setup() functions
initcall_blacklist() should return 1 to indicate that it handled its
cmdline arguments.
set_debug_rodata() should return 1 to indicate that it handled its cmdline
arguments. Print a warning if the option string is invalid.
This prevents these strings from being added to the 'init' program's
environment as they are not init arguments/parameters.
Link: https://lkml.kernel.org/r/20220221050901.23985-1-rdunlap@infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Igor Zhbanov <i.zhbanov@omprussia.ru>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
init/main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/init/main.c~init-mainc-return-1-from-handled-__setup-functions
+++ a/init/main.c
@@ -1190,7 +1190,7 @@ static int __init initcall_blacklist(cha
}
} while (str_entry);
- return 0;
+ return 1;
}
static bool __init_or_module initcall_blacklisted(initcall_t fn)
@@ -1448,7 +1448,9 @@ static noinline void __init kernel_init_
bool rodata_enabled __ro_after_init = true;
static int __init set_debug_rodata(char *str)
{
- return strtobool(str, &rodata_enabled);
+ if (strtobool(str, &rodata_enabled))
+ pr_warn("Invalid option string for rodata: '%s'\n", str);
+ return 1;
}
__setup("rodata=", set_debug_rodata);
#endif
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 20/41] fs/pipe: use kvcalloc to allocate a pipe_buffer array
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: viro, 0x7f454c46, avagin, akpm, patches, linux-mm, mm-commits,
torvalds, akpm
From: Andrei Vagin <avagin@gmail.com>
Subject: fs/pipe: use kvcalloc to allocate a pipe_buffer array
Right now, kcalloc is used to allocate a pipe_buffer array. The size of
the pipe_buffer struct is 40 bytes. kcalloc allows allocating reliably
chunks with sizes less or equal to PAGE_ALLOC_COSTLY_ORDER (3). It means
that the maximum pipe size is 3.2MB in this case.
In CRIU, we use pipes to dump processes memory. CRIU freezes a target
process, injects a parasite code into it and then this code splices memory
into pipes. If a maximum pipe size is small, we need to do many
iterations or create many pipes.
kvcalloc attempt to allocate physically contiguous memory, but upon
failure, fall back to non-contiguous (vmalloc) allocation and so it isn't
limited by PAGE_ALLOC_COSTLY_ORDER.
The maximum pipe size for non-root users is limited by the
/proc/sys/fs/pipe-max-size sysctl that is 1MB by default, so only the root
user will be able to trigger vmalloc allocations.
Link: https://lkml.kernel.org/r/20220104171058.22580-1-avagin@gmail.com
Signed-off-by: Andrei Vagin <avagin@gmail.com>
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/pipe.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/fs/pipe.c~fs-pipe-use-kvcalloc-to-allocate-a-pipe_buffer-array
+++ a/fs/pipe.c
@@ -804,7 +804,7 @@ struct pipe_inode_info *alloc_pipe_info(
if (too_many_pipe_buffers_hard(user_bufs) && pipe_is_unprivileged_user())
goto out_revert_acct;
- pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
+ pipe->bufs = kvcalloc(pipe_bufs, sizeof(struct pipe_buffer),
GFP_KERNEL_ACCOUNT);
if (pipe->bufs) {
@@ -849,7 +849,7 @@ void free_pipe_info(struct pipe_inode_in
#endif
if (pipe->tmp_page)
__free_page(pipe->tmp_page);
- kfree(pipe->bufs);
+ kvfree(pipe->bufs);
kfree(pipe);
}
@@ -1264,8 +1264,7 @@ int pipe_resize_ring(struct pipe_inode_i
if (nr_slots < n)
return -EBUSY;
- bufs = kcalloc(nr_slots, sizeof(*bufs),
- GFP_KERNEL_ACCOUNT | __GFP_NOWARN);
+ bufs = kvcalloc(nr_slots, sizeof(*bufs), GFP_KERNEL_ACCOUNT);
if (unlikely(!bufs))
return -ENOMEM;
@@ -1292,7 +1291,7 @@ int pipe_resize_ring(struct pipe_inode_i
head = n;
tail = 0;
- kfree(pipe->bufs);
+ kvfree(pipe->bufs);
pipe->bufs = bufs;
pipe->ring_size = nr_slots;
if (pipe->max_usage > nr_slots)
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 20/41] fs/pipe: use kvcalloc to allocate a pipe_buffer array
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: viro, 0x7f454c46, avagin, akpm, patches, linux-mm, mm-commits,
torvalds, akpm
From: Andrei Vagin <avagin@gmail.com>
Subject: fs/pipe: use kvcalloc to allocate a pipe_buffer array
Right now, kcalloc is used to allocate a pipe_buffer array. The size of
the pipe_buffer struct is 40 bytes. kcalloc allows allocating reliably
chunks with sizes less or equal to PAGE_ALLOC_COSTLY_ORDER (3). It means
that the maximum pipe size is 3.2MB in this case.
In CRIU, we use pipes to dump processes memory. CRIU freezes a target
process, injects a parasite code into it and then this code splices memory
into pipes. If a maximum pipe size is small, we need to do many
iterations or create many pipes.
kvcalloc attempt to allocate physically contiguous memory, but upon
failure, fall back to non-contiguous (vmalloc) allocation and so it isn't
limited by PAGE_ALLOC_COSTLY_ORDER.
The maximum pipe size for non-root users is limited by the
/proc/sys/fs/pipe-max-size sysctl that is 1MB by default, so only the root
user will be able to trigger vmalloc allocations.
Link: https://lkml.kernel.org/r/20220104171058.22580-1-avagin@gmail.com
Signed-off-by: Andrei Vagin <avagin@gmail.com>
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/pipe.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/fs/pipe.c~fs-pipe-use-kvcalloc-to-allocate-a-pipe_buffer-array
+++ a/fs/pipe.c
@@ -804,7 +804,7 @@ struct pipe_inode_info *alloc_pipe_info(
if (too_many_pipe_buffers_hard(user_bufs) && pipe_is_unprivileged_user())
goto out_revert_acct;
- pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
+ pipe->bufs = kvcalloc(pipe_bufs, sizeof(struct pipe_buffer),
GFP_KERNEL_ACCOUNT);
if (pipe->bufs) {
@@ -849,7 +849,7 @@ void free_pipe_info(struct pipe_inode_in
#endif
if (pipe->tmp_page)
__free_page(pipe->tmp_page);
- kfree(pipe->bufs);
+ kvfree(pipe->bufs);
kfree(pipe);
}
@@ -1264,8 +1264,7 @@ int pipe_resize_ring(struct pipe_inode_i
if (nr_slots < n)
return -EBUSY;
- bufs = kcalloc(nr_slots, sizeof(*bufs),
- GFP_KERNEL_ACCOUNT | __GFP_NOWARN);
+ bufs = kvcalloc(nr_slots, sizeof(*bufs), GFP_KERNEL_ACCOUNT);
if (unlikely(!bufs))
return -ENOMEM;
@@ -1292,7 +1291,7 @@ int pipe_resize_ring(struct pipe_inode_i
head = n;
tail = 0;
- kfree(pipe->bufs);
+ kvfree(pipe->bufs);
pipe->bufs = bufs;
pipe->ring_size = nr_slots;
if (pipe->max_usage > nr_slots)
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 21/41] fs/pipe.c: local vars have to match types of proper pipe_inode_info fields
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: christian.brauner, 0x7f454c46, avagin, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Andrei Vagin <avagin@gmail.com>
Subject: fs/pipe.c: local vars have to match types of proper pipe_inode_info fields
head, tail, ring_size are declared as unsigned int, so all local variables
that operate with these fields have to be unsigned to avoid signed integer
overflow.
Right now, it isn't an issue because the maximum pipe size is limited by
1U<<31.
Link: https://lkml.kernel.org/r/20220106171946.36128-1-avagin@gmail.com
Signed-off-by: Andrei Vagin <avagin@gmail.com>
Suggested-by: Dmitry Safonov <0x7f454c46@gmail.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/pipe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/pipe.c~fs-pipe-local-vars-has-to-match-types-of-proper-pipe_inode_info-fields
+++ a/fs/pipe.c
@@ -607,7 +607,7 @@ out:
static long pipe_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
struct pipe_inode_info *pipe = filp->private_data;
- int count, head, tail, mask;
+ unsigned int count, head, tail, mask;
switch (cmd) {
case FIONREAD:
@@ -829,7 +829,7 @@ out_free_uid:
void free_pipe_info(struct pipe_inode_info *pipe)
{
- int i;
+ unsigned int i;
#ifdef CONFIG_WATCH_QUEUE
if (pipe->watch_queue)
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 21/41] fs/pipe.c: local vars have to match types of proper pipe_inode_info fields
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: christian.brauner, 0x7f454c46, avagin, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Andrei Vagin <avagin@gmail.com>
Subject: fs/pipe.c: local vars have to match types of proper pipe_inode_info fields
head, tail, ring_size are declared as unsigned int, so all local variables
that operate with these fields have to be unsigned to avoid signed integer
overflow.
Right now, it isn't an issue because the maximum pipe size is limited by
1U<<31.
Link: https://lkml.kernel.org/r/20220106171946.36128-1-avagin@gmail.com
Signed-off-by: Andrei Vagin <avagin@gmail.com>
Suggested-by: Dmitry Safonov <0x7f454c46@gmail.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/pipe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/pipe.c~fs-pipe-local-vars-has-to-match-types-of-proper-pipe_inode_info-fields
+++ a/fs/pipe.c
@@ -607,7 +607,7 @@ out:
static long pipe_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
struct pipe_inode_info *pipe = filp->private_data;
- int count, head, tail, mask;
+ unsigned int count, head, tail, mask;
switch (cmd) {
case FIONREAD:
@@ -829,7 +829,7 @@ out_free_uid:
void free_pipe_info(struct pipe_inode_info *pipe)
{
- int i;
+ unsigned int i;
#ifdef CONFIG_WATCH_QUEUE
if (pipe->watch_queue)
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 22/41] minix: fix bug when opening a file with O_DIRECT
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: jack, colin.king, christian.brauner, qhjin.dev, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: Qinghua Jin <qhjin.dev@gmail.com>
Subject: minix: fix bug when opening a file with O_DIRECT
Testcase:
1. create a minix file system and mount it
2. open a file on the file system with O_RDWR|O_CREAT|O_TRUNC|O_DIRECT
3. open fails with -EINVAL but leaves an empty file behind. All other
open() failures don't leave the failed open files behind.
It is hard to check the direct_IO op before creating the inode. Just as
ext4 and btrfs do, this patch will resolve the issue by allowing to create
the file with O_DIRECT but returning error when writing the file.
Link: https://lkml.kernel.org/r/20220107133626.413379-1-qhjin.dev@gmail.com
Signed-off-by: Qinghua Jin <qhjin.dev@gmail.com>
Reported-by: Colin Ian King <colin.king@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/minix/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/minix/inode.c~minix-fix-bug-when-opening-a-file-with-o_direct
+++ a/fs/minix/inode.c
@@ -447,7 +447,8 @@ static const struct address_space_operat
.writepage = minix_writepage,
.write_begin = minix_write_begin,
.write_end = generic_write_end,
- .bmap = minix_bmap
+ .bmap = minix_bmap,
+ .direct_IO = noop_direct_IO
};
static const struct inode_operations minix_symlink_inode_operations = {
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 22/41] minix: fix bug when opening a file with O_DIRECT
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: jack, colin.king, christian.brauner, qhjin.dev, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: Qinghua Jin <qhjin.dev@gmail.com>
Subject: minix: fix bug when opening a file with O_DIRECT
Testcase:
1. create a minix file system and mount it
2. open a file on the file system with O_RDWR|O_CREAT|O_TRUNC|O_DIRECT
3. open fails with -EINVAL but leaves an empty file behind. All other
open() failures don't leave the failed open files behind.
It is hard to check the direct_IO op before creating the inode. Just as
ext4 and btrfs do, this patch will resolve the issue by allowing to create
the file with O_DIRECT but returning error when writing the file.
Link: https://lkml.kernel.org/r/20220107133626.413379-1-qhjin.dev@gmail.com
Signed-off-by: Qinghua Jin <qhjin.dev@gmail.com>
Reported-by: Colin Ian King <colin.king@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/minix/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/minix/inode.c~minix-fix-bug-when-opening-a-file-with-o_direct
+++ a/fs/minix/inode.c
@@ -447,7 +447,8 @@ static const struct address_space_operat
.writepage = minix_writepage,
.write_begin = minix_write_begin,
.write_end = generic_write_end,
- .bmap = minix_bmap
+ .bmap = minix_bmap,
+ .direct_IO = noop_direct_IO
};
static const struct inode_operations minix_symlink_inode_operations = {
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 23/41] fat: use pointer to simple type in put_user()
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: schwab, hirofumi, David.Laight, deller, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Helge Deller <deller@gmx.de>
Subject: fat: use pointer to simple type in put_user()
The put_user(val,ptr) macro wants a pointer to a simple type, but in
fat_ioctl_filldir() the d_name field references an "array of chars". Be
more accurate and explicitly give the pointer to the first character of
the d_name[] array.
I noticed that issue while trying to optimize the parisc put_user() macro
and used an intermediate variable to store the pointer. In that case I
got this error:
In file included from include/linux/uaccess.h:11,
from include/linux/compat.h:17,
from fs/fat/dir.c:18:
fs/fat/dir.c: In function `fat_ioctl_filldir':
fs/fat/dir.c:725:33: error: invalid initializer
725 | if (put_user(0, d2->d_name) || \
| ^~
include/asm/uaccess.h:152:33: note: in definition of macro `__put_user'
152 | __typeof__(ptr) __ptr = ptr; \
| ^~~
fs/fat/dir.c:759:1: note: in expansion of macro `FAT_IOCTL_FILLDIR_FUNC'
759 | FAT_IOCTL_FILLDIR_FUNC(fat_ioctl_filldir, __fat_dirent)
Andreas Schwab <schwab@linux-m68k.org> suggested to use
__typeof__(&*(ptr)) __ptr = ptr;
instead. This works, but nevertheless it's probably reasonable to
fix the original caller too.
Link: https://lkml.kernel.org/r/Ygo+A9MREmC1H3kr@p100
Signed-off-by: Helge Deller <deller@gmx.de>
Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: David Laight <David.Laight@aculab.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/fat/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/fat/dir.c~fat-use-pointer-to-simple-type-in-put_user
+++ a/fs/fat/dir.c
@@ -722,7 +722,7 @@ static int func(struct dir_context *ctx,
if (name_len >= sizeof(d1->d_name)) \
name_len = sizeof(d1->d_name) - 1; \
\
- if (put_user(0, d2->d_name) || \
+ if (put_user(0, &d2->d_name[0]) || \
put_user(0, &d2->d_reclen) || \
copy_to_user(d1->d_name, name, name_len) || \
put_user(0, d1->d_name + name_len) || \
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 23/41] fat: use pointer to simple type in put_user()
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: schwab, hirofumi, David.Laight, deller, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Helge Deller <deller@gmx.de>
Subject: fat: use pointer to simple type in put_user()
The put_user(val,ptr) macro wants a pointer to a simple type, but in
fat_ioctl_filldir() the d_name field references an "array of chars". Be
more accurate and explicitly give the pointer to the first character of
the d_name[] array.
I noticed that issue while trying to optimize the parisc put_user() macro
and used an intermediate variable to store the pointer. In that case I
got this error:
In file included from include/linux/uaccess.h:11,
from include/linux/compat.h:17,
from fs/fat/dir.c:18:
fs/fat/dir.c: In function `fat_ioctl_filldir':
fs/fat/dir.c:725:33: error: invalid initializer
725 | if (put_user(0, d2->d_name) || \
| ^~
include/asm/uaccess.h:152:33: note: in definition of macro `__put_user'
152 | __typeof__(ptr) __ptr = ptr; \
| ^~~
fs/fat/dir.c:759:1: note: in expansion of macro `FAT_IOCTL_FILLDIR_FUNC'
759 | FAT_IOCTL_FILLDIR_FUNC(fat_ioctl_filldir, __fat_dirent)
Andreas Schwab <schwab@linux-m68k.org> suggested to use
__typeof__(&*(ptr)) __ptr = ptr;
instead. This works, but nevertheless it's probably reasonable to
fix the original caller too.
Link: https://lkml.kernel.org/r/Ygo+A9MREmC1H3kr@p100
Signed-off-by: Helge Deller <deller@gmx.de>
Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: David Laight <David.Laight@aculab.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/fat/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/fat/dir.c~fat-use-pointer-to-simple-type-in-put_user
+++ a/fs/fat/dir.c
@@ -722,7 +722,7 @@ static int func(struct dir_context *ctx,
if (name_len >= sizeof(d1->d_name)) \
name_len = sizeof(d1->d_name) - 1; \
\
- if (put_user(0, d2->d_name) || \
+ if (put_user(0, &d2->d_name[0]) || \
put_user(0, &d2->d_reclen) || \
copy_to_user(d1->d_name, name, name_len) || \
put_user(0, d1->d_name + name_len) || \
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 24/41] cgroup: use irqsave in cgroup_rstat_flush_locked().
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: tj, tglx, lizefan.x, hannes, bigeasy, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: cgroup: use irqsave in cgroup_rstat_flush_locked().
All callers of cgroup_rstat_flush_locked() acquire cgroup_rstat_lock
either with spin_lock_irq() or spin_lock_irqsave().
cgroup_rstat_flush_locked() itself acquires cgroup_rstat_cpu_lock which is
a raw_spin_lock. This lock is also acquired in cgroup_rstat_updated() in
IRQ context and therefore requires _irqsave() locking suffix in
cgroup_rstat_flush_locked().
Since there is no difference between spin_lock_t and raw_spin_lock_t on
!RT lockdep does not complain here. On RT lockdep complains because the
interrupts were not disabled here and a deadlock is possible.
Acquire the raw_spin_lock_t with disabled interrupts.
Link: https://lkml.kernel.org/r/20220301122143.1521823-2-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Zefan Li <lizefan.x@bytedance.com>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: cgroup: add a comment to cgroup_rstat_flush_locked().
Add a comment why spin_lock_irq() -> raw_spin_lock_irqsave() is needed.
Link: https://lkml.kernel.org/r/Yh+DOK73hfVV5ThX@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Zefan Li <lizefan.x@bytedance.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/cgroup/rstat.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/kernel/cgroup/rstat.c~cgroup-use-irqsave-in-cgroup_rstat_flush_locked
+++ a/kernel/cgroup/rstat.c
@@ -153,8 +153,17 @@ static void cgroup_rstat_flush_locked(st
raw_spinlock_t *cpu_lock = per_cpu_ptr(&cgroup_rstat_cpu_lock,
cpu);
struct cgroup *pos = NULL;
+ unsigned long flags;
- raw_spin_lock(cpu_lock);
+ /*
+ * The _irqsave() is needed because cgroup_rstat_lock is
+ * spinlock_t which is a sleeping lock on PREEMPT_RT. Acquiring
+ * this lock with the _irq() suffix only disables interrupts on
+ * a non-PREEMPT_RT kernel. The raw_spinlock_t below disables
+ * interrupts on both configurations. The _irqsave() ensures
+ * that interrupts are always disabled and later restored.
+ */
+ raw_spin_lock_irqsave(cpu_lock, flags);
while ((pos = cgroup_rstat_cpu_pop_updated(pos, cgrp, cpu))) {
struct cgroup_subsys_state *css;
@@ -166,7 +175,7 @@ static void cgroup_rstat_flush_locked(st
css->ss->css_rstat_flush(css, cpu);
rcu_read_unlock();
}
- raw_spin_unlock(cpu_lock);
+ raw_spin_unlock_irqrestore(cpu_lock, flags);
/* if @may_sleep, play nice and yield if necessary */
if (may_sleep && (need_resched() ||
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 24/41] cgroup: use irqsave in cgroup_rstat_flush_locked().
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: tj, tglx, lizefan.x, hannes, bigeasy, akpm, patches, linux-mm,
mm-commits, torvalds, akpm
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: cgroup: use irqsave in cgroup_rstat_flush_locked().
All callers of cgroup_rstat_flush_locked() acquire cgroup_rstat_lock
either with spin_lock_irq() or spin_lock_irqsave().
cgroup_rstat_flush_locked() itself acquires cgroup_rstat_cpu_lock which is
a raw_spin_lock. This lock is also acquired in cgroup_rstat_updated() in
IRQ context and therefore requires _irqsave() locking suffix in
cgroup_rstat_flush_locked().
Since there is no difference between spin_lock_t and raw_spin_lock_t on
!RT lockdep does not complain here. On RT lockdep complains because the
interrupts were not disabled here and a deadlock is possible.
Acquire the raw_spin_lock_t with disabled interrupts.
Link: https://lkml.kernel.org/r/20220301122143.1521823-2-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Zefan Li <lizefan.x@bytedance.com>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: cgroup: add a comment to cgroup_rstat_flush_locked().
Add a comment why spin_lock_irq() -> raw_spin_lock_irqsave() is needed.
Link: https://lkml.kernel.org/r/Yh+DOK73hfVV5ThX@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Zefan Li <lizefan.x@bytedance.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/cgroup/rstat.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/kernel/cgroup/rstat.c~cgroup-use-irqsave-in-cgroup_rstat_flush_locked
+++ a/kernel/cgroup/rstat.c
@@ -153,8 +153,17 @@ static void cgroup_rstat_flush_locked(st
raw_spinlock_t *cpu_lock = per_cpu_ptr(&cgroup_rstat_cpu_lock,
cpu);
struct cgroup *pos = NULL;
+ unsigned long flags;
- raw_spin_lock(cpu_lock);
+ /*
+ * The _irqsave() is needed because cgroup_rstat_lock is
+ * spinlock_t which is a sleeping lock on PREEMPT_RT. Acquiring
+ * this lock with the _irq() suffix only disables interrupts on
+ * a non-PREEMPT_RT kernel. The raw_spinlock_t below disables
+ * interrupts on both configurations. The _irqsave() ensures
+ * that interrupts are always disabled and later restored.
+ */
+ raw_spin_lock_irqsave(cpu_lock, flags);
while ((pos = cgroup_rstat_cpu_pop_updated(pos, cgrp, cpu))) {
struct cgroup_subsys_state *css;
@@ -166,7 +175,7 @@ static void cgroup_rstat_flush_locked(st
css->ss->css_rstat_flush(css, cpu);
rcu_read_unlock();
}
- raw_spin_unlock(cpu_lock);
+ raw_spin_unlock_irqrestore(cpu_lock, flags);
/* if @may_sleep, play nice and yield if necessary */
if (may_sleep && (need_resched() ||
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 25/41] kexec: make crashk_res, crashk_low_res and crash_notes symbols always visible
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: will, tglx, rmk+kernel, paul.walmsley, palmer, palmer, mingo,
linux, hpa, ebiederm, dave.hansen, catalin.marinas, bp, bhe, aou,
alex, jszhang, akpm, patches, linux-mm, mm-commits, torvalds,
akpm
From: Jisheng Zhang <jszhang@kernel.org>
Subject: kexec: make crashk_res, crashk_low_res and crash_notes symbols always visible
Patch series "kexec: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef", v2.
Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE" by a
check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code and
increase compile coverage.
I only modified x86, arm, arm64 and riscv, other architectures such as sh,
powerpc and s390 are better to be kept kexec code as-is so they are not
touched.
This patch (of 5):
Make the forward declarations of crashk_res, crashk_low_res and
crash_notes always visible. Code referring to these symbols can then just
check for IS_ENABLED(CONFIG_KEXEC_CORE), instead of requiring conditional
compilation using an #ifdef, thus preparing to increase compile coverage
and simplify the code.
Link: https://lkml.kernel.org/r/20211206160514.2000-1-jszhang@kernel.org
Link: https://lkml.kernel.org/r/20211206160514.2000-2-jszhang@kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/kexec.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/include/linux/kexec.h~kexec-make-crashk_res-crashk_low_res-and-crash_notes-symbols-always-visible
+++ a/include/linux/kexec.h
@@ -20,6 +20,12 @@
#include <uapi/linux/kexec.h>
+/* Location of a reserved region to hold the crash kernel.
+ */
+extern struct resource crashk_res;
+extern struct resource crashk_low_res;
+extern note_buf_t __percpu *crash_notes;
+
#ifdef CONFIG_KEXEC_CORE
#include <linux/list.h>
#include <linux/compat.h>
@@ -350,12 +356,6 @@ extern int kexec_load_disabled;
#define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
KEXEC_FILE_NO_INITRAMFS)
-/* Location of a reserved region to hold the crash kernel.
- */
-extern struct resource crashk_res;
-extern struct resource crashk_low_res;
-extern note_buf_t __percpu *crash_notes;
-
/* flag to track if kexec reboot is in progress */
extern bool kexec_in_progress;
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 25/41] kexec: make crashk_res, crashk_low_res and crash_notes symbols always visible
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: will, tglx, rmk+kernel, paul.walmsley, palmer, palmer, mingo,
linux, hpa, ebiederm, dave.hansen, catalin.marinas, bp, bhe, aou,
alex, jszhang, akpm, patches, linux-mm, mm-commits, torvalds,
akpm
From: Jisheng Zhang <jszhang@kernel.org>
Subject: kexec: make crashk_res, crashk_low_res and crash_notes symbols always visible
Patch series "kexec: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef", v2.
Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE" by a
check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code and
increase compile coverage.
I only modified x86, arm, arm64 and riscv, other architectures such as sh,
powerpc and s390 are better to be kept kexec code as-is so they are not
touched.
This patch (of 5):
Make the forward declarations of crashk_res, crashk_low_res and
crash_notes always visible. Code referring to these symbols can then just
check for IS_ENABLED(CONFIG_KEXEC_CORE), instead of requiring conditional
compilation using an #ifdef, thus preparing to increase compile coverage
and simplify the code.
Link: https://lkml.kernel.org/r/20211206160514.2000-1-jszhang@kernel.org
Link: https://lkml.kernel.org/r/20211206160514.2000-2-jszhang@kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/kexec.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/include/linux/kexec.h~kexec-make-crashk_res-crashk_low_res-and-crash_notes-symbols-always-visible
+++ a/include/linux/kexec.h
@@ -20,6 +20,12 @@
#include <uapi/linux/kexec.h>
+/* Location of a reserved region to hold the crash kernel.
+ */
+extern struct resource crashk_res;
+extern struct resource crashk_low_res;
+extern note_buf_t __percpu *crash_notes;
+
#ifdef CONFIG_KEXEC_CORE
#include <linux/list.h>
#include <linux/compat.h>
@@ -350,12 +356,6 @@ extern int kexec_load_disabled;
#define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
KEXEC_FILE_NO_INITRAMFS)
-/* Location of a reserved region to hold the crash kernel.
- */
-extern struct resource crashk_res;
-extern struct resource crashk_low_res;
-extern note_buf_t __percpu *crash_notes;
-
/* flag to track if kexec reboot is in progress */
extern bool kexec_in_progress;
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 26/41] riscv: mm: init: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: will, tglx, rmk+kernel, paul.walmsley, palmer, palmer, mingo,
linux, hpa, ebiederm, dave.hansen, catalin.marinas, bp, bhe, aou,
alex, jszhang, akpm, patches, linux-mm, mm-commits, torvalds,
akpm
From: Jisheng Zhang <jszhang@kernel.org>
Subject: riscv: mm: init: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE" by a
check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code and
increase compile coverage.
Link: https://lkml.kernel.org/r/20211206160514.2000-3-jszhang@kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
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: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/riscv/mm/init.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/arch/riscv/mm/init.c~riscv-mm-init-use-is_enabledconfig_kexec_core-instead-of-ifdef
+++ a/arch/riscv/mm/init.c
@@ -957,7 +957,6 @@ static inline void setup_vm_final(void)
}
#endif /* CONFIG_MMU */
-#ifdef CONFIG_KEXEC_CORE
/*
* reserve_crashkernel() - reserves memory for crash kernel
*
@@ -974,6 +973,8 @@ static void __init reserve_crashkernel(v
int ret = 0;
+ if (!IS_ENABLED(CONFIG_KEXEC_CORE))
+ return;
/*
* Don't reserve a region for a crash kernel on a crash kernel
* since it doesn't make much sense and we have limited memory
@@ -1023,7 +1024,6 @@ static void __init reserve_crashkernel(v
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
}
-#endif /* CONFIG_KEXEC_CORE */
void __init paging_init(void)
{
@@ -1037,9 +1037,7 @@ void __init misc_mem_init(void)
arch_numa_init();
sparse_init();
zone_sizes_init();
-#ifdef CONFIG_KEXEC_CORE
reserve_crashkernel();
-#endif
memblock_dump_all();
}
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 26/41] riscv: mm: init: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: will, tglx, rmk+kernel, paul.walmsley, palmer, palmer, mingo,
linux, hpa, ebiederm, dave.hansen, catalin.marinas, bp, bhe, aou,
alex, jszhang, akpm, patches, linux-mm, mm-commits, torvalds,
akpm
From: Jisheng Zhang <jszhang@kernel.org>
Subject: riscv: mm: init: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE" by a
check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code and
increase compile coverage.
Link: https://lkml.kernel.org/r/20211206160514.2000-3-jszhang@kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
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: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/riscv/mm/init.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/arch/riscv/mm/init.c~riscv-mm-init-use-is_enabledconfig_kexec_core-instead-of-ifdef
+++ a/arch/riscv/mm/init.c
@@ -957,7 +957,6 @@ static inline void setup_vm_final(void)
}
#endif /* CONFIG_MMU */
-#ifdef CONFIG_KEXEC_CORE
/*
* reserve_crashkernel() - reserves memory for crash kernel
*
@@ -974,6 +973,8 @@ static void __init reserve_crashkernel(v
int ret = 0;
+ if (!IS_ENABLED(CONFIG_KEXEC_CORE))
+ return;
/*
* Don't reserve a region for a crash kernel on a crash kernel
* since it doesn't make much sense and we have limited memory
@@ -1023,7 +1024,6 @@ static void __init reserve_crashkernel(v
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
}
-#endif /* CONFIG_KEXEC_CORE */
void __init paging_init(void)
{
@@ -1037,9 +1037,7 @@ void __init misc_mem_init(void)
arch_numa_init();
sparse_init();
zone_sizes_init();
-#ifdef CONFIG_KEXEC_CORE
reserve_crashkernel();
-#endif
memblock_dump_all();
}
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 27/41] x86/setup: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: will, tglx, rmk+kernel, paul.walmsley, palmer, palmer, mingo,
linux, hpa, ebiederm, dave.hansen, catalin.marinas, bp, bhe, aou,
alex, jszhang, akpm, patches, linux-mm, mm-commits, torvalds,
akpm
From: Jisheng Zhang <jszhang@kernel.org>
Subject: x86/setup: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE" by a
check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code and
increase compile coverage.
Link: https://lkml.kernel.org/r/20211206160514.2000-4-jszhang@kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
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: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/kernel/setup.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
--- a/arch/x86/kernel/setup.c~x86-setup-use-is_enabledconfig_kexec_core-instead-of-ifdef
+++ a/arch/x86/kernel/setup.c
@@ -411,8 +411,6 @@ static void __init memblock_x86_reserve_
* --------- Crashkernel reservation ------------------------------
*/
-#ifdef CONFIG_KEXEC_CORE
-
/* 16M alignment for crash kernel regions */
#define CRASH_ALIGN SZ_16M
@@ -490,6 +488,9 @@ static void __init reserve_crashkernel(v
bool high = false;
int ret;
+ if (!IS_ENABLED(CONFIG_KEXEC_CORE))
+ return;
+
total_mem = memblock_phys_mem_size();
/* crashkernel=XM */
@@ -555,11 +556,6 @@ static void __init reserve_crashkernel(v
crashk_res.end = crash_base + crash_size - 1;
insert_resource(&iomem_resource, &crashk_res);
}
-#else
-static void __init reserve_crashkernel(void)
-{
-}
-#endif
static struct resource standard_io_resources[] = {
{ .name = "dma1", .start = 0x00, .end = 0x1f,
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 27/41] x86/setup: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: will, tglx, rmk+kernel, paul.walmsley, palmer, palmer, mingo,
linux, hpa, ebiederm, dave.hansen, catalin.marinas, bp, bhe, aou,
alex, jszhang, akpm, patches, linux-mm, mm-commits, torvalds,
akpm
From: Jisheng Zhang <jszhang@kernel.org>
Subject: x86/setup: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE" by a
check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code and
increase compile coverage.
Link: https://lkml.kernel.org/r/20211206160514.2000-4-jszhang@kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
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: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/kernel/setup.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
--- a/arch/x86/kernel/setup.c~x86-setup-use-is_enabledconfig_kexec_core-instead-of-ifdef
+++ a/arch/x86/kernel/setup.c
@@ -411,8 +411,6 @@ static void __init memblock_x86_reserve_
* --------- Crashkernel reservation ------------------------------
*/
-#ifdef CONFIG_KEXEC_CORE
-
/* 16M alignment for crash kernel regions */
#define CRASH_ALIGN SZ_16M
@@ -490,6 +488,9 @@ static void __init reserve_crashkernel(v
bool high = false;
int ret;
+ if (!IS_ENABLED(CONFIG_KEXEC_CORE))
+ return;
+
total_mem = memblock_phys_mem_size();
/* crashkernel=XM */
@@ -555,11 +556,6 @@ static void __init reserve_crashkernel(v
crashk_res.end = crash_base + crash_size - 1;
insert_resource(&iomem_resource, &crashk_res);
}
-#else
-static void __init reserve_crashkernel(void)
-{
-}
-#endif
static struct resource standard_io_resources[] = {
{ .name = "dma1", .start = 0x00, .end = 0x1f,
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 28/41] arm64: mm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: will, tglx, rmk+kernel, paul.walmsley, palmer, palmer, mingo,
linux, hpa, ebiederm, dave.hansen, catalin.marinas, bp, bhe, aou,
alex, jszhang, akpm, patches, linux-mm, mm-commits, torvalds,
akpm
From: Jisheng Zhang <jszhang@kernel.org>
Subject: arm64: mm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE" by a
check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code and
increase compile coverage.
Link: https://lkml.kernel.org/r/20211206160514.2000-5-jszhang@kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Borislav Petkov <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: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/arm64/mm/init.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/arch/arm64/mm/init.c~arm64-mm-use-is_enabledconfig_kexec_core-instead-of-ifdef
+++ a/arch/arm64/mm/init.c
@@ -64,7 +64,6 @@ EXPORT_SYMBOL(memstart_addr);
*/
phys_addr_t arm64_dma_phys_limit __ro_after_init;
-#ifdef CONFIG_KEXEC_CORE
/*
* reserve_crashkernel() - reserves memory for crash kernel
*
@@ -78,6 +77,9 @@ static void __init reserve_crashkernel(v
unsigned long long crash_max = arm64_dma_phys_limit;
int ret;
+ if (!IS_ENABLED(CONFIG_KEXEC_CORE))
+ return;
+
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
&crash_size, &crash_base);
/* no crashkernel= or invalid value specified */
@@ -110,11 +112,6 @@ static void __init reserve_crashkernel(v
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
}
-#else
-static void __init reserve_crashkernel(void)
-{
-}
-#endif /* CONFIG_KEXEC_CORE */
/*
* Return the maximum physical address for a zone accessible by the given bits
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 28/41] arm64: mm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: will, tglx, rmk+kernel, paul.walmsley, palmer, palmer, mingo,
linux, hpa, ebiederm, dave.hansen, catalin.marinas, bp, bhe, aou,
alex, jszhang, akpm, patches, linux-mm, mm-commits, torvalds,
akpm
From: Jisheng Zhang <jszhang@kernel.org>
Subject: arm64: mm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE" by a
check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code and
increase compile coverage.
Link: https://lkml.kernel.org/r/20211206160514.2000-5-jszhang@kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Borislav Petkov <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: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/arm64/mm/init.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/arch/arm64/mm/init.c~arm64-mm-use-is_enabledconfig_kexec_core-instead-of-ifdef
+++ a/arch/arm64/mm/init.c
@@ -64,7 +64,6 @@ EXPORT_SYMBOL(memstart_addr);
*/
phys_addr_t arm64_dma_phys_limit __ro_after_init;
-#ifdef CONFIG_KEXEC_CORE
/*
* reserve_crashkernel() - reserves memory for crash kernel
*
@@ -78,6 +77,9 @@ static void __init reserve_crashkernel(v
unsigned long long crash_max = arm64_dma_phys_limit;
int ret;
+ if (!IS_ENABLED(CONFIG_KEXEC_CORE))
+ return;
+
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
&crash_size, &crash_base);
/* no crashkernel= or invalid value specified */
@@ -110,11 +112,6 @@ static void __init reserve_crashkernel(v
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
}
-#else
-static void __init reserve_crashkernel(void)
-{
-}
-#endif /* CONFIG_KEXEC_CORE */
/*
* Return the maximum physical address for a zone accessible by the given bits
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 29/41] docs: kdump: update description about sysfs file system support
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: ryabinin.a.a, lixuefeng, elver, corbet, bhe, yangtiezhu, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: docs: kdump: update description about sysfs file system support
Patch series "Update doc and fix some issues about kdump", v2.
This patch (of 5):
After commit 6a108a14fa35 ("kconfig: rename CONFIG_EMBEDDED to
CONFIG_EXPERT"), "Configure standard kernel features (for small systems)"
is not exist, we should use "Configure standard kernel features (expert
users)" now.
Link: https://lkml.kernel.org/r/1644324666-15947-1-git-send-email-yangtiezhu@loongson.cn
Link: https://lkml.kernel.org/r/1644324666-15947-2-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Marco Elver <elver@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/kdump/kdump.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/Documentation/admin-guide/kdump/kdump.rst~docs-kdump-update-description-about-sysfs-file-system-support
+++ a/Documentation/admin-guide/kdump/kdump.rst
@@ -146,9 +146,9 @@ System kernel config options
CONFIG_SYSFS=y
Note that "sysfs file system support" might not appear in the "Pseudo
- filesystems" menu if "Configure standard kernel features (for small
- systems)" is not enabled in "General Setup." In this case, check the
- .config file itself to ensure that sysfs is turned on, as follows::
+ filesystems" menu if "Configure standard kernel features (expert users)"
+ is not enabled in "General Setup." In this case, check the .config file
+ itself to ensure that sysfs is turned on, as follows::
grep 'CONFIG_SYSFS' .config
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 29/41] docs: kdump: update description about sysfs file system support
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: ryabinin.a.a, lixuefeng, elver, corbet, bhe, yangtiezhu, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: docs: kdump: update description about sysfs file system support
Patch series "Update doc and fix some issues about kdump", v2.
This patch (of 5):
After commit 6a108a14fa35 ("kconfig: rename CONFIG_EMBEDDED to
CONFIG_EXPERT"), "Configure standard kernel features (for small systems)"
is not exist, we should use "Configure standard kernel features (expert
users)" now.
Link: https://lkml.kernel.org/r/1644324666-15947-1-git-send-email-yangtiezhu@loongson.cn
Link: https://lkml.kernel.org/r/1644324666-15947-2-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Marco Elver <elver@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/kdump/kdump.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/Documentation/admin-guide/kdump/kdump.rst~docs-kdump-update-description-about-sysfs-file-system-support
+++ a/Documentation/admin-guide/kdump/kdump.rst
@@ -146,9 +146,9 @@ System kernel config options
CONFIG_SYSFS=y
Note that "sysfs file system support" might not appear in the "Pseudo
- filesystems" menu if "Configure standard kernel features (for small
- systems)" is not enabled in "General Setup." In this case, check the
- .config file itself to ensure that sysfs is turned on, as follows::
+ filesystems" menu if "Configure standard kernel features (expert users)"
+ is not enabled in "General Setup." In this case, check the .config file
+ itself to ensure that sysfs is turned on, as follows::
grep 'CONFIG_SYSFS' .config
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 30/41] docs: kdump: add scp example to write out the dump file
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: ryabinin.a.a, lixuefeng, elver, corbet, bhe, yangtiezhu, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: docs: kdump: add scp example to write out the dump file
Except cp and makedumpfile, add scp example to write out the dump file.
Link: https://lkml.kernel.org/r/1644324666-15947-3-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Marco Elver <elver@google.com>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/kdump/kdump.rst | 4 ++++
1 file changed, 4 insertions(+)
--- a/Documentation/admin-guide/kdump/kdump.rst~docs-kdump-add-scp-example-to-write-out-the-dump-file
+++ a/Documentation/admin-guide/kdump/kdump.rst
@@ -533,6 +533,10 @@ the following command::
cp /proc/vmcore <dump-file>
+or use scp to write out the dump file between hosts on a network, e.g::
+
+ scp /proc/vmcore remote_username@remote_ip:<dump-file>
+
You can also use makedumpfile utility to write out the dump file
with specified options to filter out unwanted contents, e.g::
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 30/41] docs: kdump: add scp example to write out the dump file
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: ryabinin.a.a, lixuefeng, elver, corbet, bhe, yangtiezhu, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: docs: kdump: add scp example to write out the dump file
Except cp and makedumpfile, add scp example to write out the dump file.
Link: https://lkml.kernel.org/r/1644324666-15947-3-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Marco Elver <elver@google.com>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/kdump/kdump.rst | 4 ++++
1 file changed, 4 insertions(+)
--- a/Documentation/admin-guide/kdump/kdump.rst~docs-kdump-add-scp-example-to-write-out-the-dump-file
+++ a/Documentation/admin-guide/kdump/kdump.rst
@@ -533,6 +533,10 @@ the following command::
cp /proc/vmcore <dump-file>
+or use scp to write out the dump file between hosts on a network, e.g::
+
+ scp /proc/vmcore remote_username@remote_ip:<dump-file>
+
You can also use makedumpfile utility to write out the dump file
with specified options to filter out unwanted contents, e.g::
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 31/41] panic: unset panic_on_warn inside panic()
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: ryabinin.a.a, lixuefeng, elver, corbet, bhe, yangtiezhu, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: panic: unset panic_on_warn inside panic()
In the current code, the following three places need to unset
panic_on_warn before calling panic() to avoid recursive panics:
kernel/kcsan/report.c: print_report()
kernel/sched/core.c: __schedule_bug()
mm/kfence/report.c: kfence_report_error()
In order to avoid copy-pasting "panic_on_warn = 0" all over the places, it
is better to move it inside panic() and then remove it from the other
places.
Link: https://lkml.kernel.org/r/1644324666-15947-4-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/panic.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/kernel/panic.c~panic-unset-panic_on_warn-inside-panic
+++ a/kernel/panic.c
@@ -185,6 +185,16 @@ void panic(const char *fmt, ...)
int old_cpu, this_cpu;
bool _crash_kexec_post_notifiers = crash_kexec_post_notifiers;
+ if (panic_on_warn) {
+ /*
+ * This thread may hit another WARN() in the panic path.
+ * Resetting this prevents additional WARN() from panicking the
+ * system on this thread. Other threads are blocked by the
+ * panic_mutex in panic().
+ */
+ panic_on_warn = 0;
+ }
+
/*
* Disable local interrupts. This will prevent panic_smp_self_stop
* from deadlocking the first cpu that invokes the panic, since
@@ -576,16 +586,8 @@ void __warn(const char *file, int line,
if (regs)
show_regs(regs);
- if (panic_on_warn) {
- /*
- * This thread may hit another WARN() in the panic path.
- * Resetting this prevents additional WARN() from panicking the
- * system on this thread. Other threads are blocked by the
- * panic_mutex in panic().
- */
- panic_on_warn = 0;
+ if (panic_on_warn)
panic("panic_on_warn set ...\n");
- }
if (!regs)
dump_stack();
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 31/41] panic: unset panic_on_warn inside panic()
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: ryabinin.a.a, lixuefeng, elver, corbet, bhe, yangtiezhu, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: panic: unset panic_on_warn inside panic()
In the current code, the following three places need to unset
panic_on_warn before calling panic() to avoid recursive panics:
kernel/kcsan/report.c: print_report()
kernel/sched/core.c: __schedule_bug()
mm/kfence/report.c: kfence_report_error()
In order to avoid copy-pasting "panic_on_warn = 0" all over the places, it
is better to move it inside panic() and then remove it from the other
places.
Link: https://lkml.kernel.org/r/1644324666-15947-4-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/panic.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/kernel/panic.c~panic-unset-panic_on_warn-inside-panic
+++ a/kernel/panic.c
@@ -185,6 +185,16 @@ void panic(const char *fmt, ...)
int old_cpu, this_cpu;
bool _crash_kexec_post_notifiers = crash_kexec_post_notifiers;
+ if (panic_on_warn) {
+ /*
+ * This thread may hit another WARN() in the panic path.
+ * Resetting this prevents additional WARN() from panicking the
+ * system on this thread. Other threads are blocked by the
+ * panic_mutex in panic().
+ */
+ panic_on_warn = 0;
+ }
+
/*
* Disable local interrupts. This will prevent panic_smp_self_stop
* from deadlocking the first cpu that invokes the panic, since
@@ -576,16 +586,8 @@ void __warn(const char *file, int line,
if (regs)
show_regs(regs);
- if (panic_on_warn) {
- /*
- * This thread may hit another WARN() in the panic path.
- * Resetting this prevents additional WARN() from panicking the
- * system on this thread. Other threads are blocked by the
- * panic_mutex in panic().
- */
- panic_on_warn = 0;
+ if (panic_on_warn)
panic("panic_on_warn set ...\n");
- }
if (!regs)
dump_stack();
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 32/41] ubsan: no need to unset panic_on_warn in ubsan_epilogue()
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: ryabinin.a.a, lixuefeng, elver, corbet, bhe, yangtiezhu, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: ubsan: no need to unset panic_on_warn in ubsan_epilogue()
panic_on_warn is unset inside panic(), so no need to unset it before
calling panic() in ubsan_epilogue().
Link: https://lkml.kernel.org/r/1644324666-15947-5-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/ubsan.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
--- a/lib/ubsan.c~ubsan-no-need-to-unset-panic_on_warn-in-ubsan_epilogue
+++ a/lib/ubsan.c
@@ -154,16 +154,8 @@ static void ubsan_epilogue(void)
current->in_ubsan--;
- if (panic_on_warn) {
- /*
- * This thread may hit another WARN() in the panic path.
- * Resetting this prevents additional WARN() from panicking the
- * system on this thread. Other threads are blocked by the
- * panic_mutex in panic().
- */
- panic_on_warn = 0;
+ if (panic_on_warn)
panic("panic_on_warn set ...\n");
- }
}
void __ubsan_handle_divrem_overflow(void *_data, void *lhs, void *rhs)
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 32/41] ubsan: no need to unset panic_on_warn in ubsan_epilogue()
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: ryabinin.a.a, lixuefeng, elver, corbet, bhe, yangtiezhu, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: ubsan: no need to unset panic_on_warn in ubsan_epilogue()
panic_on_warn is unset inside panic(), so no need to unset it before
calling panic() in ubsan_epilogue().
Link: https://lkml.kernel.org/r/1644324666-15947-5-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/ubsan.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
--- a/lib/ubsan.c~ubsan-no-need-to-unset-panic_on_warn-in-ubsan_epilogue
+++ a/lib/ubsan.c
@@ -154,16 +154,8 @@ static void ubsan_epilogue(void)
current->in_ubsan--;
- if (panic_on_warn) {
- /*
- * This thread may hit another WARN() in the panic path.
- * Resetting this prevents additional WARN() from panicking the
- * system on this thread. Other threads are blocked by the
- * panic_mutex in panic().
- */
- panic_on_warn = 0;
+ if (panic_on_warn)
panic("panic_on_warn set ...\n");
- }
}
void __ubsan_handle_divrem_overflow(void *_data, void *lhs, void *rhs)
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 33/41] kasan: no need to unset panic_on_warn in end_report()
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:06 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: ryabinin.a.a, lixuefeng, elver, corbet, bhe, yangtiezhu, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: kasan: no need to unset panic_on_warn in end_report()
panic_on_warn is unset inside panic(), so no need to unset it before
calling panic() in end_report().
Link: https://lkml.kernel.org/r/1644324666-15947-6-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/kasan/report.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
--- a/mm/kasan/report.c~kasan-no-need-to-unset-panic_on_warn-in-end_report
+++ a/mm/kasan/report.c
@@ -117,16 +117,8 @@ static void end_report(unsigned long *fl
pr_err("==================================================================\n");
add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
spin_unlock_irqrestore(&report_lock, *flags);
- if (panic_on_warn && !test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags)) {
- /*
- * This thread may hit another WARN() in the panic path.
- * Resetting this prevents additional WARN() from panicking the
- * system on this thread. Other threads are blocked by the
- * panic_mutex in panic().
- */
- panic_on_warn = 0;
+ if (panic_on_warn && !test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags))
panic("panic_on_warn set ...\n");
- }
if (kasan_arg_fault == KASAN_ARG_FAULT_PANIC)
panic("kasan.fault=panic set ...\n");
kasan_enable_current();
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 33/41] kasan: no need to unset panic_on_warn in end_report()
@ 2022-03-23 23:06 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:06 UTC (permalink / raw)
To: ryabinin.a.a, lixuefeng, elver, corbet, bhe, yangtiezhu, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: Tiezhu Yang <yangtiezhu@loongson.cn>
Subject: kasan: no need to unset panic_on_warn in end_report()
panic_on_warn is unset inside panic(), so no need to unset it before
calling panic() in end_report().
Link: https://lkml.kernel.org/r/1644324666-15947-6-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/kasan/report.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
--- a/mm/kasan/report.c~kasan-no-need-to-unset-panic_on_warn-in-end_report
+++ a/mm/kasan/report.c
@@ -117,16 +117,8 @@ static void end_report(unsigned long *fl
pr_err("==================================================================\n");
add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
spin_unlock_irqrestore(&report_lock, *flags);
- if (panic_on_warn && !test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags)) {
- /*
- * This thread may hit another WARN() in the panic path.
- * Resetting this prevents additional WARN() from panicking the
- * system on this thread. Other threads are blocked by the
- * panic_mutex in panic().
- */
- panic_on_warn = 0;
+ if (panic_on_warn && !test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags))
panic("panic_on_warn set ...\n");
- }
if (kasan_arg_fault == KASAN_ARG_FAULT_PANIC)
panic("kasan.fault=panic set ...\n");
kasan_enable_current();
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 34/41] taskstats: remove unneeded dead assignment
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:07 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: trix, ndesaulniers, natechancellor, bsingharora, lukas.bulwahn,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Subject: taskstats: remove unneeded dead assignment
make clang-analyzer on x86_64 defconfig caught my attention with:
kernel/taskstats.c:120:2: warning: Value stored to 'rc' is never read \
[clang-analyzer-deadcode.DeadStores]
rc = 0;
^
Commit d94a041519f3 ("taskstats: free skb, avoid returns in
send_cpu_listeners") made send_cpu_listeners() not return a value and
hence, the rc variable remained only to be used within the loop where
it is always assigned before read and it does not need any other
initialisation.
So, simply remove this unneeded dead initializing assignment.
As compilers will detect this unneeded assignment and optimize this anyway,
the resulting object code is identical before and after this change.
No functional change. No change to object code.
[akpm@linux-foundation.org: reduce scope of `rc']
Link: https://lkml.kernel.org/r/20220307093942.21310-1-lukas.bulwahn@gmail.com
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Tom Rix <trix@redhat.com>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/taskstats.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/kernel/taskstats.c~taskstats-remove-unneeded-dead-assignment
+++ a/kernel/taskstats.c
@@ -113,13 +113,14 @@ static void send_cpu_listeners(struct sk
struct listener *s, *tmp;
struct sk_buff *skb_next, *skb_cur = skb;
void *reply = genlmsg_data(genlhdr);
- int rc, delcount = 0;
+ int delcount = 0;
genlmsg_end(skb, reply);
- rc = 0;
down_read(&listeners->sem);
list_for_each_entry(s, &listeners->list, list) {
+ int rc;
+
skb_next = NULL;
if (!list_is_last(&s->list, &listeners->list)) {
skb_next = skb_clone(skb_cur, GFP_KERNEL);
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 34/41] taskstats: remove unneeded dead assignment
@ 2022-03-23 23:07 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: trix, ndesaulniers, natechancellor, bsingharora, lukas.bulwahn,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Subject: taskstats: remove unneeded dead assignment
make clang-analyzer on x86_64 defconfig caught my attention with:
kernel/taskstats.c:120:2: warning: Value stored to 'rc' is never read \
[clang-analyzer-deadcode.DeadStores]
rc = 0;
^
Commit d94a041519f3 ("taskstats: free skb, avoid returns in
send_cpu_listeners") made send_cpu_listeners() not return a value and
hence, the rc variable remained only to be used within the loop where
it is always assigned before read and it does not need any other
initialisation.
So, simply remove this unneeded dead initializing assignment.
As compilers will detect this unneeded assignment and optimize this anyway,
the resulting object code is identical before and after this change.
No functional change. No change to object code.
[akpm@linux-foundation.org: reduce scope of `rc']
Link: https://lkml.kernel.org/r/20220307093942.21310-1-lukas.bulwahn@gmail.com
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Tom Rix <trix@redhat.com>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/taskstats.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/kernel/taskstats.c~taskstats-remove-unneeded-dead-assignment
+++ a/kernel/taskstats.c
@@ -113,13 +113,14 @@ static void send_cpu_listeners(struct sk
struct listener *s, *tmp;
struct sk_buff *skb_next, *skb_cur = skb;
void *reply = genlmsg_data(genlhdr);
- int rc, delcount = 0;
+ int delcount = 0;
genlmsg_end(skb, reply);
- rc = 0;
down_read(&listeners->sem);
list_for_each_entry(s, &listeners->list, list) {
+ int rc;
+
skb_next = NULL;
if (!list_is_last(&s->list, &listeners->list)) {
skb_next = skb_clone(skb_cur, GFP_KERNEL);
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 35/41] docs: sysctl/kernel: add missing bit to panic_print
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:07 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: yzaikin, siglesias, mcgrof, keescook, feng.tang, gpiccoli, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Subject: docs: sysctl/kernel: add missing bit to panic_print
Patch series "Some improvements on panic_print".
This is a mix of a documentation fix with some additions to the
"panic_print" syscall / parameter. The goal here is being able to collect
all CPUs backtraces during a panic event and also to enable "panic_print"
in a kdump event - details of the reasoning and design choices in the
patches.
This patch (of 3):
Commit de6da1e8bcf0 ("panic: add an option to replay all the printk
message in buffer") added a new bit to the sysctl/kernel parameter
"panic_print", but the documentation was added only in
kernel-parameters.txt, not in the sysctl guide.
Fix it here by adding bit 5 to sysctl admin-guide documentation.
[rdunlap@infradead.org: fix table format warning]
Link: https://lkml.kernel.org/r/20220109055635.6999-1-rdunlap@infradead.org
Link: https://lkml.kernel.org/r/20211109202848.610874-1-gpiccoli@igalia.com
Link: https://lkml.kernel.org/r/20211109202848.610874-2-gpiccoli@igalia.com
Fixes: de6da1e8bcf0 ("panic: add an option to replay all the printk message in buffer")
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Reviewed-by: Feng Tang <feng.tang@intel.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Iurii Zaikin <yzaikin@google.com>
Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/sysctl/kernel.rst | 1 +
1 file changed, 1 insertion(+)
--- a/Documentation/admin-guide/sysctl/kernel.rst~docs-sysctl-kernel-add-missing-bit-to-panic_print
+++ a/Documentation/admin-guide/sysctl/kernel.rst
@@ -806,6 +806,7 @@ bit 1 print system memory info
bit 2 print timer info
bit 3 print locks info if ``CONFIG_LOCKDEP`` is on
bit 4 print ftrace buffer
+bit 5 print all printk messages in buffer
===== ============================================
So for example to print tasks and memory info on panic, user can::
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 35/41] docs: sysctl/kernel: add missing bit to panic_print
@ 2022-03-23 23:07 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: yzaikin, siglesias, mcgrof, keescook, feng.tang, gpiccoli, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Subject: docs: sysctl/kernel: add missing bit to panic_print
Patch series "Some improvements on panic_print".
This is a mix of a documentation fix with some additions to the
"panic_print" syscall / parameter. The goal here is being able to collect
all CPUs backtraces during a panic event and also to enable "panic_print"
in a kdump event - details of the reasoning and design choices in the
patches.
This patch (of 3):
Commit de6da1e8bcf0 ("panic: add an option to replay all the printk
message in buffer") added a new bit to the sysctl/kernel parameter
"panic_print", but the documentation was added only in
kernel-parameters.txt, not in the sysctl guide.
Fix it here by adding bit 5 to sysctl admin-guide documentation.
[rdunlap@infradead.org: fix table format warning]
Link: https://lkml.kernel.org/r/20220109055635.6999-1-rdunlap@infradead.org
Link: https://lkml.kernel.org/r/20211109202848.610874-1-gpiccoli@igalia.com
Link: https://lkml.kernel.org/r/20211109202848.610874-2-gpiccoli@igalia.com
Fixes: de6da1e8bcf0 ("panic: add an option to replay all the printk message in buffer")
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Reviewed-by: Feng Tang <feng.tang@intel.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Iurii Zaikin <yzaikin@google.com>
Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/sysctl/kernel.rst | 1 +
1 file changed, 1 insertion(+)
--- a/Documentation/admin-guide/sysctl/kernel.rst~docs-sysctl-kernel-add-missing-bit-to-panic_print
+++ a/Documentation/admin-guide/sysctl/kernel.rst
@@ -806,6 +806,7 @@ bit 1 print system memory info
bit 2 print timer info
bit 3 print locks info if ``CONFIG_LOCKDEP`` is on
bit 4 print ftrace buffer
+bit 5 print all printk messages in buffer
===== ============================================
So for example to print tasks and memory info on panic, user can::
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 36/41] panic: add option to dump all CPUs backtraces in panic_print
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:07 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: yzaikin, siglesias, mcgrof, keescook, feng.tang, gpiccoli, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Subject: panic: add option to dump all CPUs backtraces in panic_print
Currently the "panic_print" parameter/sysctl allows some interesting debug
information to be printed during a panic event. This is useful for
example in cases the user cannot kdump due to resource limits, or if the
user collects panic logs in a serial output (or pstore) and prefers a fast
reboot instead of a kdump.
Happens that currently there's no way to see all CPUs backtraces in a
panic using "panic_print" on architectures that support that. We do have
"oops_all_cpu_backtrace" sysctl, but although partially overlapping in the
functionality, they are orthogonal in nature: "panic_print" is a panic
tuning (and we have panics without oopses, like direct calls to panic() or
maybe other paths that don't go through oops_enter() function), and the
original purpose of "oops_all_cpu_backtrace" is to provide more
information on oopses for cases in which the users desire to continue
running the kernel even after an oops, i.e., used in non-panic scenarios.
So, we hereby introduce an additional bit for "panic_print" to allow
dumping the CPUs backtraces during a panic event.
Link: https://lkml.kernel.org/r/20211109202848.610874-3-gpiccoli@igalia.com
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Reviewed-by: Feng Tang <feng.tang@intel.com>
Cc: Iurii Zaikin <yzaikin@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/kernel-parameters.txt | 1 +
Documentation/admin-guide/sysctl/kernel.rst | 1 +
kernel/panic.c | 4 ++++
3 files changed, 6 insertions(+)
--- a/Documentation/admin-guide/kernel-parameters.txt~panic-add-option-to-dump-all-cpus-backtraces-in-panic_print
+++ a/Documentation/admin-guide/kernel-parameters.txt
@@ -3726,6 +3726,7 @@
bit 3: print locks info if CONFIG_LOCKDEP is on
bit 4: print ftrace buffer
bit 5: print all printk messages in buffer
+ bit 6: print all CPUs backtrace (if available in the arch)
panic_on_taint= Bitmask for conditionally calling panic() in add_taint()
Format: <hex>[,nousertaint]
--- a/Documentation/admin-guide/sysctl/kernel.rst~panic-add-option-to-dump-all-cpus-backtraces-in-panic_print
+++ a/Documentation/admin-guide/sysctl/kernel.rst
@@ -807,6 +807,7 @@ bit 2 print timer info
bit 3 print locks info if ``CONFIG_LOCKDEP`` is on
bit 4 print ftrace buffer
bit 5 print all printk messages in buffer
+bit 6 print all CPUs backtrace (if available in the arch)
===== ============================================
So for example to print tasks and memory info on panic, user can::
--- a/kernel/panic.c~panic-add-option-to-dump-all-cpus-backtraces-in-panic_print
+++ a/kernel/panic.c
@@ -66,6 +66,7 @@ EXPORT_SYMBOL_GPL(panic_timeout);
#define PANIC_PRINT_LOCK_INFO 0x00000008
#define PANIC_PRINT_FTRACE_INFO 0x00000010
#define PANIC_PRINT_ALL_PRINTK_MSG 0x00000020
+#define PANIC_PRINT_ALL_CPU_BT 0x00000040
unsigned long panic_print;
ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
@@ -152,6 +153,9 @@ static void panic_print_sys_info(void)
if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
console_flush_on_panic(CONSOLE_REPLAY_ALL);
+ if (panic_print & PANIC_PRINT_ALL_CPU_BT)
+ trigger_all_cpu_backtrace();
+
if (panic_print & PANIC_PRINT_TASK_INFO)
show_state();
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 36/41] panic: add option to dump all CPUs backtraces in panic_print
@ 2022-03-23 23:07 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: yzaikin, siglesias, mcgrof, keescook, feng.tang, gpiccoli, akpm,
patches, linux-mm, mm-commits, torvalds, akpm
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Subject: panic: add option to dump all CPUs backtraces in panic_print
Currently the "panic_print" parameter/sysctl allows some interesting debug
information to be printed during a panic event. This is useful for
example in cases the user cannot kdump due to resource limits, or if the
user collects panic logs in a serial output (or pstore) and prefers a fast
reboot instead of a kdump.
Happens that currently there's no way to see all CPUs backtraces in a
panic using "panic_print" on architectures that support that. We do have
"oops_all_cpu_backtrace" sysctl, but although partially overlapping in the
functionality, they are orthogonal in nature: "panic_print" is a panic
tuning (and we have panics without oopses, like direct calls to panic() or
maybe other paths that don't go through oops_enter() function), and the
original purpose of "oops_all_cpu_backtrace" is to provide more
information on oopses for cases in which the users desire to continue
running the kernel even after an oops, i.e., used in non-panic scenarios.
So, we hereby introduce an additional bit for "panic_print" to allow
dumping the CPUs backtraces during a panic event.
Link: https://lkml.kernel.org/r/20211109202848.610874-3-gpiccoli@igalia.com
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Reviewed-by: Feng Tang <feng.tang@intel.com>
Cc: Iurii Zaikin <yzaikin@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/kernel-parameters.txt | 1 +
Documentation/admin-guide/sysctl/kernel.rst | 1 +
kernel/panic.c | 4 ++++
3 files changed, 6 insertions(+)
--- a/Documentation/admin-guide/kernel-parameters.txt~panic-add-option-to-dump-all-cpus-backtraces-in-panic_print
+++ a/Documentation/admin-guide/kernel-parameters.txt
@@ -3726,6 +3726,7 @@
bit 3: print locks info if CONFIG_LOCKDEP is on
bit 4: print ftrace buffer
bit 5: print all printk messages in buffer
+ bit 6: print all CPUs backtrace (if available in the arch)
panic_on_taint= Bitmask for conditionally calling panic() in add_taint()
Format: <hex>[,nousertaint]
--- a/Documentation/admin-guide/sysctl/kernel.rst~panic-add-option-to-dump-all-cpus-backtraces-in-panic_print
+++ a/Documentation/admin-guide/sysctl/kernel.rst
@@ -807,6 +807,7 @@ bit 2 print timer info
bit 3 print locks info if ``CONFIG_LOCKDEP`` is on
bit 4 print ftrace buffer
bit 5 print all printk messages in buffer
+bit 6 print all CPUs backtrace (if available in the arch)
===== ============================================
So for example to print tasks and memory info on panic, user can::
--- a/kernel/panic.c~panic-add-option-to-dump-all-cpus-backtraces-in-panic_print
+++ a/kernel/panic.c
@@ -66,6 +66,7 @@ EXPORT_SYMBOL_GPL(panic_timeout);
#define PANIC_PRINT_LOCK_INFO 0x00000008
#define PANIC_PRINT_FTRACE_INFO 0x00000010
#define PANIC_PRINT_ALL_PRINTK_MSG 0x00000020
+#define PANIC_PRINT_ALL_CPU_BT 0x00000040
unsigned long panic_print;
ATOMIC_NOTIFIER_HEAD(panic_notifier_list);
@@ -152,6 +153,9 @@ static void panic_print_sys_info(void)
if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
console_flush_on_panic(CONSOLE_REPLAY_ALL);
+ if (panic_print & PANIC_PRINT_ALL_CPU_BT)
+ trigger_all_cpu_backtrace();
+
if (panic_print & PANIC_PRINT_TASK_INFO)
show_state();
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 37/41] panic: move panic_print before kmsg dumpers
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:07 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: senozhatsky, pmladek, feng.tang, bhe, gpiccoli, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Subject: panic: move panic_print before kmsg dumpers
The panic_print setting allows users to collect more information in a
panic event, like memory stats, tasks, CPUs backtraces, etc. This is an
interesting debug mechanism, but currently the print event happens *after*
kmsg_dump(), meaning that pstore, for example, cannot collect a dmesg with
the panic_print extra information.
This patch changes that in 2 steps:
(a) The panic_print setting allows to replay the existing kernel log
buffer to the console (bit 5), besides the extra information dump.
This functionality makes sense only at the end of the panic()
function. So, we hereby allow to distinguish the two situations by a
new boolean parameter in the function panic_print_sys_info().
(b) With the above change, we can safely call panic_print_sys_info()
before kmsg_dump(), allowing to dump the extra information when using
pstore or other kmsg dumpers.
The additional messages from panic_print could overwrite the oldest
messages when the buffer is full. The only reasonable solution is to use
a large enough log buffer, hence we added an advice into the kernel
parameters documentation about that.
Link: https://lkml.kernel.org/r/20220214141308.841525-1-gpiccoli@igalia.com
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Acked-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Feng Tang <feng.tang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++++
kernel/panic.c | 13 +++++++++----
2 files changed, 13 insertions(+), 4 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt~panic-move-panic_print-before-kmsg-dumpers
+++ a/Documentation/admin-guide/kernel-parameters.txt
@@ -3727,6 +3727,10 @@
bit 4: print ftrace buffer
bit 5: print all printk messages in buffer
bit 6: print all CPUs backtrace (if available in the arch)
+ *Be aware* that this option may print a _lot_ of lines,
+ so there are risks of losing older messages in the log.
+ Use this option carefully, maybe worth to setup a
+ bigger log buffer with "log_buf_len" along with this.
panic_on_taint= Bitmask for conditionally calling panic() in add_taint()
Format: <hex>[,nousertaint]
--- a/kernel/panic.c~panic-move-panic_print-before-kmsg-dumpers
+++ a/kernel/panic.c
@@ -148,10 +148,13 @@ void nmi_panic(struct pt_regs *regs, con
}
EXPORT_SYMBOL(nmi_panic);
-static void panic_print_sys_info(void)
+static void panic_print_sys_info(bool console_flush)
{
- if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
- console_flush_on_panic(CONSOLE_REPLAY_ALL);
+ if (console_flush) {
+ if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
+ console_flush_on_panic(CONSOLE_REPLAY_ALL);
+ return;
+ }
if (panic_print & PANIC_PRINT_ALL_CPU_BT)
trigger_all_cpu_backtrace();
@@ -286,6 +289,8 @@ void panic(const char *fmt, ...)
*/
atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
+ panic_print_sys_info(false);
+
kmsg_dump(KMSG_DUMP_PANIC);
/*
@@ -316,7 +321,7 @@ void panic(const char *fmt, ...)
debug_locks_off();
console_flush_on_panic(CONSOLE_FLUSH_PENDING);
- panic_print_sys_info();
+ panic_print_sys_info(true);
if (!panic_blink)
panic_blink = no_blink;
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 37/41] panic: move panic_print before kmsg dumpers
@ 2022-03-23 23:07 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: senozhatsky, pmladek, feng.tang, bhe, gpiccoli, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Subject: panic: move panic_print before kmsg dumpers
The panic_print setting allows users to collect more information in a
panic event, like memory stats, tasks, CPUs backtraces, etc. This is an
interesting debug mechanism, but currently the print event happens *after*
kmsg_dump(), meaning that pstore, for example, cannot collect a dmesg with
the panic_print extra information.
This patch changes that in 2 steps:
(a) The panic_print setting allows to replay the existing kernel log
buffer to the console (bit 5), besides the extra information dump.
This functionality makes sense only at the end of the panic()
function. So, we hereby allow to distinguish the two situations by a
new boolean parameter in the function panic_print_sys_info().
(b) With the above change, we can safely call panic_print_sys_info()
before kmsg_dump(), allowing to dump the extra information when using
pstore or other kmsg dumpers.
The additional messages from panic_print could overwrite the oldest
messages when the buffer is full. The only reasonable solution is to use
a large enough log buffer, hence we added an advice into the kernel
parameters documentation about that.
Link: https://lkml.kernel.org/r/20220214141308.841525-1-gpiccoli@igalia.com
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Acked-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Feng Tang <feng.tang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++++
kernel/panic.c | 13 +++++++++----
2 files changed, 13 insertions(+), 4 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt~panic-move-panic_print-before-kmsg-dumpers
+++ a/Documentation/admin-guide/kernel-parameters.txt
@@ -3727,6 +3727,10 @@
bit 4: print ftrace buffer
bit 5: print all printk messages in buffer
bit 6: print all CPUs backtrace (if available in the arch)
+ *Be aware* that this option may print a _lot_ of lines,
+ so there are risks of losing older messages in the log.
+ Use this option carefully, maybe worth to setup a
+ bigger log buffer with "log_buf_len" along with this.
panic_on_taint= Bitmask for conditionally calling panic() in add_taint()
Format: <hex>[,nousertaint]
--- a/kernel/panic.c~panic-move-panic_print-before-kmsg-dumpers
+++ a/kernel/panic.c
@@ -148,10 +148,13 @@ void nmi_panic(struct pt_regs *regs, con
}
EXPORT_SYMBOL(nmi_panic);
-static void panic_print_sys_info(void)
+static void panic_print_sys_info(bool console_flush)
{
- if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
- console_flush_on_panic(CONSOLE_REPLAY_ALL);
+ if (console_flush) {
+ if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
+ console_flush_on_panic(CONSOLE_REPLAY_ALL);
+ return;
+ }
if (panic_print & PANIC_PRINT_ALL_CPU_BT)
trigger_all_cpu_backtrace();
@@ -286,6 +289,8 @@ void panic(const char *fmt, ...)
*/
atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
+ panic_print_sys_info(false);
+
kmsg_dump(KMSG_DUMP_PANIC);
/*
@@ -316,7 +321,7 @@ void panic(const char *fmt, ...)
debug_locks_off();
console_flush_on_panic(CONSOLE_FLUSH_PENDING);
- panic_print_sys_info();
+ panic_print_sys_info(true);
if (!panic_blink)
panic_blink = no_blink;
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 38/41] kcov: split ioctl handling into locked and unlocked parts
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:07 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: tarasmadan, glider, elver, dvyukov, bigeasy, andreyknvl, nogikh,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Aleksandr Nogikh <nogikh@google.com>
Subject: kcov: split ioctl handling into locked and unlocked parts
Patch series "kcov: improve mmap processing", v3.
Subsequent mmaps of the same kcov descriptor currently do not update the
virtual memory of the task and yet return 0 (success). This is
counter-intuitive and may lead to unexpected memory access errors.
Also, this unnecessarily limits the functionality of kcov to only the
simplest usage scenarios. Kcov instances are effectively forever attached
to their first address spaces and it becomes impossible to e.g. reuse the
same kcov handle in forked child processes without mmapping the memory
first. This is exactly what we tried to do in syzkaller and inadvertently
came upon this behavior.
This patch series addresses the problem described above.
This patch (of 3):
Currently all ioctls are de facto processed under a spinlock in order to
serialise them. This, however, prohibits the use of vmalloc and other
memory management functions in the implementations of those ioctls,
unnecessary complicating any further changes to the code.
Let all ioctls first be processed inside the kcov_ioctl() function which
should execute the ones that are not compatible with spinlock and then
pass control to kcov_ioctl_locked() for all other ones.
KCOV_REMOTE_ENABLE is processed both in kcov_ioctl() and
kcov_ioctl_locked() as the steps are easily separable.
Although it is still compatible with a spinlock, move KCOV_INIT_TRACE
handling to kcov_ioctl(), so that the changes from the next commit are
easier to follow.
Link: https://lkml.kernel.org/r/20220117153634.150357-1-nogikh@google.com
Link: https://lkml.kernel.org/r/20220117153634.150357-2-nogikh@google.com
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Marco Elver <elver@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Taras Madan <tarasmadan@google.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/kcov.c | 68 ++++++++++++++++++++++++++----------------------
1 file changed, 37 insertions(+), 31 deletions(-)
--- a/kernel/kcov.c~kcov-split-ioctl-handling-into-locked-and-unlocked-parts
+++ a/kernel/kcov.c
@@ -564,31 +564,12 @@ static int kcov_ioctl_locked(struct kcov
unsigned long arg)
{
struct task_struct *t;
- unsigned long size, unused;
+ unsigned long flags, unused;
int mode, i;
struct kcov_remote_arg *remote_arg;
struct kcov_remote *remote;
- unsigned long flags;
switch (cmd) {
- case KCOV_INIT_TRACE:
- /*
- * Enable kcov in trace mode and setup buffer size.
- * Must happen before anything else.
- */
- if (kcov->mode != KCOV_MODE_DISABLED)
- return -EBUSY;
- /*
- * Size must be at least 2 to hold current position and one PC.
- * Later we allocate size * sizeof(unsigned long) memory,
- * that must not overflow.
- */
- size = arg;
- if (size < 2 || size > INT_MAX / sizeof(unsigned long))
- return -EINVAL;
- kcov->size = size;
- kcov->mode = KCOV_MODE_INIT;
- return 0;
case KCOV_ENABLE:
/*
* Enable coverage for the current task.
@@ -692,9 +673,32 @@ static long kcov_ioctl(struct file *file
struct kcov_remote_arg *remote_arg = NULL;
unsigned int remote_num_handles;
unsigned long remote_arg_size;
- unsigned long flags;
+ unsigned long size, flags;
- if (cmd == KCOV_REMOTE_ENABLE) {
+ kcov = filep->private_data;
+ switch (cmd) {
+ case KCOV_INIT_TRACE:
+ /*
+ * Enable kcov in trace mode and setup buffer size.
+ * Must happen before anything else.
+ *
+ * First check the size argument - it must be at least 2
+ * to hold the current position and one PC. Later we allocate
+ * size * sizeof(unsigned long) memory, that must not overflow.
+ */
+ size = arg;
+ if (size < 2 || size > INT_MAX / sizeof(unsigned long))
+ return -EINVAL;
+ spin_lock_irqsave(&kcov->lock, flags);
+ if (kcov->mode != KCOV_MODE_DISABLED) {
+ spin_unlock_irqrestore(&kcov->lock, flags);
+ return -EBUSY;
+ }
+ kcov->size = size;
+ kcov->mode = KCOV_MODE_INIT;
+ spin_unlock_irqrestore(&kcov->lock, flags);
+ return 0;
+ case KCOV_REMOTE_ENABLE:
if (get_user(remote_num_handles, (unsigned __user *)(arg +
offsetof(struct kcov_remote_arg, num_handles))))
return -EFAULT;
@@ -710,16 +714,18 @@ static long kcov_ioctl(struct file *file
return -EINVAL;
}
arg = (unsigned long)remote_arg;
+ fallthrough;
+ default:
+ /*
+ * All other commands can be normally executed under a spin lock, so we
+ * obtain and release it here in order to simplify kcov_ioctl_locked().
+ */
+ spin_lock_irqsave(&kcov->lock, flags);
+ res = kcov_ioctl_locked(kcov, cmd, arg);
+ spin_unlock_irqrestore(&kcov->lock, flags);
+ kfree(remote_arg);
+ return res;
}
-
- kcov = filep->private_data;
- spin_lock_irqsave(&kcov->lock, flags);
- res = kcov_ioctl_locked(kcov, cmd, arg);
- spin_unlock_irqrestore(&kcov->lock, flags);
-
- kfree(remote_arg);
-
- return res;
}
static const struct file_operations kcov_fops = {
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 38/41] kcov: split ioctl handling into locked and unlocked parts
@ 2022-03-23 23:07 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: tarasmadan, glider, elver, dvyukov, bigeasy, andreyknvl, nogikh,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Aleksandr Nogikh <nogikh@google.com>
Subject: kcov: split ioctl handling into locked and unlocked parts
Patch series "kcov: improve mmap processing", v3.
Subsequent mmaps of the same kcov descriptor currently do not update the
virtual memory of the task and yet return 0 (success). This is
counter-intuitive and may lead to unexpected memory access errors.
Also, this unnecessarily limits the functionality of kcov to only the
simplest usage scenarios. Kcov instances are effectively forever attached
to their first address spaces and it becomes impossible to e.g. reuse the
same kcov handle in forked child processes without mmapping the memory
first. This is exactly what we tried to do in syzkaller and inadvertently
came upon this behavior.
This patch series addresses the problem described above.
This patch (of 3):
Currently all ioctls are de facto processed under a spinlock in order to
serialise them. This, however, prohibits the use of vmalloc and other
memory management functions in the implementations of those ioctls,
unnecessary complicating any further changes to the code.
Let all ioctls first be processed inside the kcov_ioctl() function which
should execute the ones that are not compatible with spinlock and then
pass control to kcov_ioctl_locked() for all other ones.
KCOV_REMOTE_ENABLE is processed both in kcov_ioctl() and
kcov_ioctl_locked() as the steps are easily separable.
Although it is still compatible with a spinlock, move KCOV_INIT_TRACE
handling to kcov_ioctl(), so that the changes from the next commit are
easier to follow.
Link: https://lkml.kernel.org/r/20220117153634.150357-1-nogikh@google.com
Link: https://lkml.kernel.org/r/20220117153634.150357-2-nogikh@google.com
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Marco Elver <elver@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Taras Madan <tarasmadan@google.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/kcov.c | 68 ++++++++++++++++++++++++++----------------------
1 file changed, 37 insertions(+), 31 deletions(-)
--- a/kernel/kcov.c~kcov-split-ioctl-handling-into-locked-and-unlocked-parts
+++ a/kernel/kcov.c
@@ -564,31 +564,12 @@ static int kcov_ioctl_locked(struct kcov
unsigned long arg)
{
struct task_struct *t;
- unsigned long size, unused;
+ unsigned long flags, unused;
int mode, i;
struct kcov_remote_arg *remote_arg;
struct kcov_remote *remote;
- unsigned long flags;
switch (cmd) {
- case KCOV_INIT_TRACE:
- /*
- * Enable kcov in trace mode and setup buffer size.
- * Must happen before anything else.
- */
- if (kcov->mode != KCOV_MODE_DISABLED)
- return -EBUSY;
- /*
- * Size must be at least 2 to hold current position and one PC.
- * Later we allocate size * sizeof(unsigned long) memory,
- * that must not overflow.
- */
- size = arg;
- if (size < 2 || size > INT_MAX / sizeof(unsigned long))
- return -EINVAL;
- kcov->size = size;
- kcov->mode = KCOV_MODE_INIT;
- return 0;
case KCOV_ENABLE:
/*
* Enable coverage for the current task.
@@ -692,9 +673,32 @@ static long kcov_ioctl(struct file *file
struct kcov_remote_arg *remote_arg = NULL;
unsigned int remote_num_handles;
unsigned long remote_arg_size;
- unsigned long flags;
+ unsigned long size, flags;
- if (cmd == KCOV_REMOTE_ENABLE) {
+ kcov = filep->private_data;
+ switch (cmd) {
+ case KCOV_INIT_TRACE:
+ /*
+ * Enable kcov in trace mode and setup buffer size.
+ * Must happen before anything else.
+ *
+ * First check the size argument - it must be at least 2
+ * to hold the current position and one PC. Later we allocate
+ * size * sizeof(unsigned long) memory, that must not overflow.
+ */
+ size = arg;
+ if (size < 2 || size > INT_MAX / sizeof(unsigned long))
+ return -EINVAL;
+ spin_lock_irqsave(&kcov->lock, flags);
+ if (kcov->mode != KCOV_MODE_DISABLED) {
+ spin_unlock_irqrestore(&kcov->lock, flags);
+ return -EBUSY;
+ }
+ kcov->size = size;
+ kcov->mode = KCOV_MODE_INIT;
+ spin_unlock_irqrestore(&kcov->lock, flags);
+ return 0;
+ case KCOV_REMOTE_ENABLE:
if (get_user(remote_num_handles, (unsigned __user *)(arg +
offsetof(struct kcov_remote_arg, num_handles))))
return -EFAULT;
@@ -710,16 +714,18 @@ static long kcov_ioctl(struct file *file
return -EINVAL;
}
arg = (unsigned long)remote_arg;
+ fallthrough;
+ default:
+ /*
+ * All other commands can be normally executed under a spin lock, so we
+ * obtain and release it here in order to simplify kcov_ioctl_locked().
+ */
+ spin_lock_irqsave(&kcov->lock, flags);
+ res = kcov_ioctl_locked(kcov, cmd, arg);
+ spin_unlock_irqrestore(&kcov->lock, flags);
+ kfree(remote_arg);
+ return res;
}
-
- kcov = filep->private_data;
- spin_lock_irqsave(&kcov->lock, flags);
- res = kcov_ioctl_locked(kcov, cmd, arg);
- spin_unlock_irqrestore(&kcov->lock, flags);
-
- kfree(remote_arg);
-
- return res;
}
static const struct file_operations kcov_fops = {
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 39/41] kcov: properly handle subsequent mmap calls
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:07 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: tarasmadan, glider, elver, dvyukov, bigeasy, andreyknvl, nogikh,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Aleksandr Nogikh <nogikh@google.com>
Subject: kcov: properly handle subsequent mmap calls
Allocate the kcov buffer during KCOV_MODE_INIT in order to untie mmapping
of a kcov instance and the actual coverage collection process. Modify
kcov_mmap, so that it can be reliably used any number of times once
KCOV_MODE_INIT has succeeded.
These changes to the user-facing interface of the tool only weaken the
preconditions, so all existing user space code should remain compatible
with the new version.
Link: https://lkml.kernel.org/r/20220117153634.150357-3-nogikh@google.com
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Taras Madan <tarasmadan@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/kcov.c | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)
--- a/kernel/kcov.c~kcov-properly-handle-subsequent-mmap-calls
+++ a/kernel/kcov.c
@@ -459,37 +459,28 @@ void kcov_task_exit(struct task_struct *
static int kcov_mmap(struct file *filep, struct vm_area_struct *vma)
{
int res = 0;
- void *area;
struct kcov *kcov = vma->vm_file->private_data;
unsigned long size, off;
struct page *page;
unsigned long flags;
- area = vmalloc_user(vma->vm_end - vma->vm_start);
- if (!area)
- return -ENOMEM;
-
spin_lock_irqsave(&kcov->lock, flags);
size = kcov->size * sizeof(unsigned long);
- if (kcov->mode != KCOV_MODE_INIT || vma->vm_pgoff != 0 ||
+ if (kcov->area == NULL || vma->vm_pgoff != 0 ||
vma->vm_end - vma->vm_start != size) {
res = -EINVAL;
goto exit;
}
- if (!kcov->area) {
- kcov->area = area;
- vma->vm_flags |= VM_DONTEXPAND;
- spin_unlock_irqrestore(&kcov->lock, flags);
- for (off = 0; off < size; off += PAGE_SIZE) {
- page = vmalloc_to_page(kcov->area + off);
- if (vm_insert_page(vma, vma->vm_start + off, page))
- WARN_ONCE(1, "vm_insert_page() failed");
- }
- return 0;
+ spin_unlock_irqrestore(&kcov->lock, flags);
+ vma->vm_flags |= VM_DONTEXPAND;
+ for (off = 0; off < size; off += PAGE_SIZE) {
+ page = vmalloc_to_page(kcov->area + off);
+ if (vm_insert_page(vma, vma->vm_start + off, page))
+ WARN_ONCE(1, "vm_insert_page() failed");
}
+ return 0;
exit:
spin_unlock_irqrestore(&kcov->lock, flags);
- vfree(area);
return res;
}
@@ -674,6 +665,7 @@ static long kcov_ioctl(struct file *file
unsigned int remote_num_handles;
unsigned long remote_arg_size;
unsigned long size, flags;
+ void *area;
kcov = filep->private_data;
switch (cmd) {
@@ -683,17 +675,21 @@ static long kcov_ioctl(struct file *file
* Must happen before anything else.
*
* First check the size argument - it must be at least 2
- * to hold the current position and one PC. Later we allocate
- * size * sizeof(unsigned long) memory, that must not overflow.
+ * to hold the current position and one PC.
*/
size = arg;
if (size < 2 || size > INT_MAX / sizeof(unsigned long))
return -EINVAL;
+ area = vmalloc_user(size * sizeof(unsigned long));
+ if (area == NULL)
+ return -ENOMEM;
spin_lock_irqsave(&kcov->lock, flags);
if (kcov->mode != KCOV_MODE_DISABLED) {
spin_unlock_irqrestore(&kcov->lock, flags);
+ vfree(area);
return -EBUSY;
}
+ kcov->area = area;
kcov->size = size;
kcov->mode = KCOV_MODE_INIT;
spin_unlock_irqrestore(&kcov->lock, flags);
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 39/41] kcov: properly handle subsequent mmap calls
@ 2022-03-23 23:07 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: tarasmadan, glider, elver, dvyukov, bigeasy, andreyknvl, nogikh,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Aleksandr Nogikh <nogikh@google.com>
Subject: kcov: properly handle subsequent mmap calls
Allocate the kcov buffer during KCOV_MODE_INIT in order to untie mmapping
of a kcov instance and the actual coverage collection process. Modify
kcov_mmap, so that it can be reliably used any number of times once
KCOV_MODE_INIT has succeeded.
These changes to the user-facing interface of the tool only weaken the
preconditions, so all existing user space code should remain compatible
with the new version.
Link: https://lkml.kernel.org/r/20220117153634.150357-3-nogikh@google.com
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Taras Madan <tarasmadan@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/kcov.c | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)
--- a/kernel/kcov.c~kcov-properly-handle-subsequent-mmap-calls
+++ a/kernel/kcov.c
@@ -459,37 +459,28 @@ void kcov_task_exit(struct task_struct *
static int kcov_mmap(struct file *filep, struct vm_area_struct *vma)
{
int res = 0;
- void *area;
struct kcov *kcov = vma->vm_file->private_data;
unsigned long size, off;
struct page *page;
unsigned long flags;
- area = vmalloc_user(vma->vm_end - vma->vm_start);
- if (!area)
- return -ENOMEM;
-
spin_lock_irqsave(&kcov->lock, flags);
size = kcov->size * sizeof(unsigned long);
- if (kcov->mode != KCOV_MODE_INIT || vma->vm_pgoff != 0 ||
+ if (kcov->area == NULL || vma->vm_pgoff != 0 ||
vma->vm_end - vma->vm_start != size) {
res = -EINVAL;
goto exit;
}
- if (!kcov->area) {
- kcov->area = area;
- vma->vm_flags |= VM_DONTEXPAND;
- spin_unlock_irqrestore(&kcov->lock, flags);
- for (off = 0; off < size; off += PAGE_SIZE) {
- page = vmalloc_to_page(kcov->area + off);
- if (vm_insert_page(vma, vma->vm_start + off, page))
- WARN_ONCE(1, "vm_insert_page() failed");
- }
- return 0;
+ spin_unlock_irqrestore(&kcov->lock, flags);
+ vma->vm_flags |= VM_DONTEXPAND;
+ for (off = 0; off < size; off += PAGE_SIZE) {
+ page = vmalloc_to_page(kcov->area + off);
+ if (vm_insert_page(vma, vma->vm_start + off, page))
+ WARN_ONCE(1, "vm_insert_page() failed");
}
+ return 0;
exit:
spin_unlock_irqrestore(&kcov->lock, flags);
- vfree(area);
return res;
}
@@ -674,6 +665,7 @@ static long kcov_ioctl(struct file *file
unsigned int remote_num_handles;
unsigned long remote_arg_size;
unsigned long size, flags;
+ void *area;
kcov = filep->private_data;
switch (cmd) {
@@ -683,17 +675,21 @@ static long kcov_ioctl(struct file *file
* Must happen before anything else.
*
* First check the size argument - it must be at least 2
- * to hold the current position and one PC. Later we allocate
- * size * sizeof(unsigned long) memory, that must not overflow.
+ * to hold the current position and one PC.
*/
size = arg;
if (size < 2 || size > INT_MAX / sizeof(unsigned long))
return -EINVAL;
+ area = vmalloc_user(size * sizeof(unsigned long));
+ if (area == NULL)
+ return -ENOMEM;
spin_lock_irqsave(&kcov->lock, flags);
if (kcov->mode != KCOV_MODE_DISABLED) {
spin_unlock_irqrestore(&kcov->lock, flags);
+ vfree(area);
return -EBUSY;
}
+ kcov->area = area;
kcov->size = size;
kcov->mode = KCOV_MODE_INIT;
spin_unlock_irqrestore(&kcov->lock, flags);
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 40/41] kernel/resource: fix kfree() of bootmem memory again
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:07 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: david, dan.j.williams, apopple, linmiaohe, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: Miaohe Lin <linmiaohe@huawei.com>
Subject: kernel/resource: fix kfree() of bootmem memory again
Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem
memory"), we could get a resource allocated during boot via
alloc_resource(). And it's required to release the resource using
free_resource(). Howerver, many people use kfree directly which will
result in kernel BUG. In order to fix this without fixing every call
site, just leak a couple of bytes in such corner case.
Link: https://lkml.kernel.org/r/20220217083619.19305-1-linmiaohe@huawei.com
Fixes: ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Suggested-by: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Alistair Popple <apopple@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/resource.c | 41 ++++++++---------------------------------
1 file changed, 8 insertions(+), 33 deletions(-)
--- a/kernel/resource.c~kernel-resource-fix-kfree-of-bootmem-memory-again
+++ a/kernel/resource.c
@@ -56,14 +56,6 @@ struct resource_constraint {
static DEFINE_RWLOCK(resource_lock);
-/*
- * For memory hotplug, there is no way to free resource entries allocated
- * by boot mem after the system is up. So for reusing the resource entry
- * we need to remember the resource.
- */
-static struct resource *bootmem_resource_free;
-static DEFINE_SPINLOCK(bootmem_resource_lock);
-
static struct resource *next_resource(struct resource *p)
{
if (p->child)
@@ -160,36 +152,19 @@ __initcall(ioresources_init);
static void free_resource(struct resource *res)
{
- if (!res)
- return;
-
- if (!PageSlab(virt_to_head_page(res))) {
- spin_lock(&bootmem_resource_lock);
- res->sibling = bootmem_resource_free;
- bootmem_resource_free = res;
- spin_unlock(&bootmem_resource_lock);
- } else {
+ /**
+ * If the resource was allocated using memblock early during boot
+ * we'll leak it here: we can only return full pages back to the
+ * buddy and trying to be smart and reusing them eventually in
+ * alloc_resource() overcomplicates resource handling.
+ */
+ if (res && PageSlab(virt_to_head_page(res)))
kfree(res);
- }
}
static struct resource *alloc_resource(gfp_t flags)
{
- struct resource *res = NULL;
-
- spin_lock(&bootmem_resource_lock);
- if (bootmem_resource_free) {
- res = bootmem_resource_free;
- bootmem_resource_free = res->sibling;
- }
- spin_unlock(&bootmem_resource_lock);
-
- if (res)
- memset(res, 0, sizeof(struct resource));
- else
- res = kzalloc(sizeof(struct resource), flags);
-
- return res;
+ return kzalloc(sizeof(struct resource), flags);
}
/* Return the conflict entry if you can't request it */
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 40/41] kernel/resource: fix kfree() of bootmem memory again
@ 2022-03-23 23:07 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: david, dan.j.williams, apopple, linmiaohe, akpm, patches,
linux-mm, mm-commits, torvalds, akpm
From: Miaohe Lin <linmiaohe@huawei.com>
Subject: kernel/resource: fix kfree() of bootmem memory again
Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem
memory"), we could get a resource allocated during boot via
alloc_resource(). And it's required to release the resource using
free_resource(). Howerver, many people use kfree directly which will
result in kernel BUG. In order to fix this without fixing every call
site, just leak a couple of bytes in such corner case.
Link: https://lkml.kernel.org/r/20220217083619.19305-1-linmiaohe@huawei.com
Fixes: ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Suggested-by: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Alistair Popple <apopple@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/resource.c | 41 ++++++++---------------------------------
1 file changed, 8 insertions(+), 33 deletions(-)
--- a/kernel/resource.c~kernel-resource-fix-kfree-of-bootmem-memory-again
+++ a/kernel/resource.c
@@ -56,14 +56,6 @@ struct resource_constraint {
static DEFINE_RWLOCK(resource_lock);
-/*
- * For memory hotplug, there is no way to free resource entries allocated
- * by boot mem after the system is up. So for reusing the resource entry
- * we need to remember the resource.
- */
-static struct resource *bootmem_resource_free;
-static DEFINE_SPINLOCK(bootmem_resource_lock);
-
static struct resource *next_resource(struct resource *p)
{
if (p->child)
@@ -160,36 +152,19 @@ __initcall(ioresources_init);
static void free_resource(struct resource *res)
{
- if (!res)
- return;
-
- if (!PageSlab(virt_to_head_page(res))) {
- spin_lock(&bootmem_resource_lock);
- res->sibling = bootmem_resource_free;
- bootmem_resource_free = res;
- spin_unlock(&bootmem_resource_lock);
- } else {
+ /**
+ * If the resource was allocated using memblock early during boot
+ * we'll leak it here: we can only return full pages back to the
+ * buddy and trying to be smart and reusing them eventually in
+ * alloc_resource() overcomplicates resource handling.
+ */
+ if (res && PageSlab(virt_to_head_page(res)))
kfree(res);
- }
}
static struct resource *alloc_resource(gfp_t flags)
{
- struct resource *res = NULL;
-
- spin_lock(&bootmem_resource_lock);
- if (bootmem_resource_free) {
- res = bootmem_resource_free;
- bootmem_resource_free = res->sibling;
- }
- spin_unlock(&bootmem_resource_lock);
-
- if (res)
- memset(res, 0, sizeof(struct resource));
- else
- res = kzalloc(sizeof(struct resource), flags);
-
- return res;
+ return kzalloc(sizeof(struct resource), flags);
}
/* Return the conflict entry if you can't request it */
_
^ permalink raw reply [flat|nested] 83+ messages in thread
* [patch 41/41] Revert "ubsan, kcsan: Don't combine sanitizer with kcov on clang"
2022-03-23 23:04 incoming Andrew Morton
@ 2022-03-23 23:07 ` Andrew Morton
2022-03-23 23:05 ` Andrew Morton
` (39 subsequent siblings)
40 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: ndesaulniers, nathan, keescook, glider, dvyukov, arnd, elver,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Marco Elver <elver@google.com>
Subject: Revert "ubsan, kcsan: Don't combine sanitizer with kcov on clang"
This reverts commit ea91a1d45d19469001a4955583187b0d75915759.
Since df05c0e9496c ("Documentation: Raise the minimum supported version
of LLVM to 11.0.0") the minimum Clang version is now 11.0, which fixed
the UBSAN/KCSAN vs. KCOV incompatibilities.
Link: https://bugs.llvm.org/show_bug.cgi?id=45831
Link: https://lkml.kernel.org/r/YaodyZzu0MTCJcvO@elver.google.com
Link: https://lkml.kernel.org/r/20220128105631.509772-1-elver@google.com
Signed-off-by: Marco Elver <elver@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/Kconfig.kcsan | 11 -----------
lib/Kconfig.ubsan | 12 ------------
2 files changed, 23 deletions(-)
--- a/lib/Kconfig.kcsan~revert-ubsan-kcsan-dont-combine-sanitizer-with-kcov-on-clang
+++ a/lib/Kconfig.kcsan
@@ -10,21 +10,10 @@ config HAVE_KCSAN_COMPILER
For the list of compilers that support KCSAN, please see
<file:Documentation/dev-tools/kcsan.rst>.
-config KCSAN_KCOV_BROKEN
- def_bool KCOV && CC_HAS_SANCOV_TRACE_PC
- depends on CC_IS_CLANG
- depends on !$(cc-option,-Werror=unused-command-line-argument -fsanitize=thread -fsanitize-coverage=trace-pc)
- help
- Some versions of clang support either KCSAN and KCOV but not the
- combination of the two.
- See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status
- in newer releases.
-
menuconfig KCSAN
bool "KCSAN: dynamic data race detector"
depends on HAVE_ARCH_KCSAN && HAVE_KCSAN_COMPILER
depends on DEBUG_KERNEL && !KASAN
- depends on !KCSAN_KCOV_BROKEN
select STACKTRACE
help
The Kernel Concurrency Sanitizer (KCSAN) is a dynamic
--- a/lib/Kconfig.ubsan~revert-ubsan-kcsan-dont-combine-sanitizer-with-kcov-on-clang
+++ a/lib/Kconfig.ubsan
@@ -27,16 +27,6 @@ config UBSAN_TRAP
the system. For some system builders this is an acceptable
trade-off.
-config UBSAN_KCOV_BROKEN
- def_bool KCOV && CC_HAS_SANCOV_TRACE_PC
- depends on CC_IS_CLANG
- depends on !$(cc-option,-Werror=unused-command-line-argument -fsanitize=bounds -fsanitize-coverage=trace-pc)
- help
- Some versions of clang support either UBSAN or KCOV but not the
- combination of the two.
- See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status
- in newer releases.
-
config CC_HAS_UBSAN_BOUNDS
def_bool $(cc-option,-fsanitize=bounds)
@@ -46,7 +36,6 @@ config CC_HAS_UBSAN_ARRAY_BOUNDS
config UBSAN_BOUNDS
bool "Perform array index bounds checking"
default UBSAN
- depends on !UBSAN_KCOV_BROKEN
depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS
help
This option enables detection of directly indexed out of bounds
@@ -72,7 +61,6 @@ config UBSAN_ARRAY_BOUNDS
config UBSAN_LOCAL_BOUNDS
bool "Perform array local bounds checking"
depends on UBSAN_TRAP
- depends on !UBSAN_KCOV_BROKEN
depends on $(cc-option,-fsanitize=local-bounds)
help
This option enables -fsanitize=local-bounds which traps when an
_
^ permalink raw reply [flat|nested] 83+ messages in thread* [patch 41/41] Revert "ubsan, kcsan: Don't combine sanitizer with kcov on clang"
@ 2022-03-23 23:07 ` Andrew Morton
0 siblings, 0 replies; 83+ messages in thread
From: Andrew Morton @ 2022-03-23 23:07 UTC (permalink / raw)
To: ndesaulniers, nathan, keescook, glider, dvyukov, arnd, elver,
akpm, patches, linux-mm, mm-commits, torvalds, akpm
From: Marco Elver <elver@google.com>
Subject: Revert "ubsan, kcsan: Don't combine sanitizer with kcov on clang"
This reverts commit ea91a1d45d19469001a4955583187b0d75915759.
Since df05c0e9496c ("Documentation: Raise the minimum supported version
of LLVM to 11.0.0") the minimum Clang version is now 11.0, which fixed
the UBSAN/KCSAN vs. KCOV incompatibilities.
Link: https://bugs.llvm.org/show_bug.cgi?id=45831
Link: https://lkml.kernel.org/r/YaodyZzu0MTCJcvO@elver.google.com
Link: https://lkml.kernel.org/r/20220128105631.509772-1-elver@google.com
Signed-off-by: Marco Elver <elver@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/Kconfig.kcsan | 11 -----------
lib/Kconfig.ubsan | 12 ------------
2 files changed, 23 deletions(-)
--- a/lib/Kconfig.kcsan~revert-ubsan-kcsan-dont-combine-sanitizer-with-kcov-on-clang
+++ a/lib/Kconfig.kcsan
@@ -10,21 +10,10 @@ config HAVE_KCSAN_COMPILER
For the list of compilers that support KCSAN, please see
<file:Documentation/dev-tools/kcsan.rst>.
-config KCSAN_KCOV_BROKEN
- def_bool KCOV && CC_HAS_SANCOV_TRACE_PC
- depends on CC_IS_CLANG
- depends on !$(cc-option,-Werror=unused-command-line-argument -fsanitize=thread -fsanitize-coverage=trace-pc)
- help
- Some versions of clang support either KCSAN and KCOV but not the
- combination of the two.
- See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status
- in newer releases.
-
menuconfig KCSAN
bool "KCSAN: dynamic data race detector"
depends on HAVE_ARCH_KCSAN && HAVE_KCSAN_COMPILER
depends on DEBUG_KERNEL && !KASAN
- depends on !KCSAN_KCOV_BROKEN
select STACKTRACE
help
The Kernel Concurrency Sanitizer (KCSAN) is a dynamic
--- a/lib/Kconfig.ubsan~revert-ubsan-kcsan-dont-combine-sanitizer-with-kcov-on-clang
+++ a/lib/Kconfig.ubsan
@@ -27,16 +27,6 @@ config UBSAN_TRAP
the system. For some system builders this is an acceptable
trade-off.
-config UBSAN_KCOV_BROKEN
- def_bool KCOV && CC_HAS_SANCOV_TRACE_PC
- depends on CC_IS_CLANG
- depends on !$(cc-option,-Werror=unused-command-line-argument -fsanitize=bounds -fsanitize-coverage=trace-pc)
- help
- Some versions of clang support either UBSAN or KCOV but not the
- combination of the two.
- See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status
- in newer releases.
-
config CC_HAS_UBSAN_BOUNDS
def_bool $(cc-option,-fsanitize=bounds)
@@ -46,7 +36,6 @@ config CC_HAS_UBSAN_ARRAY_BOUNDS
config UBSAN_BOUNDS
bool "Perform array index bounds checking"
default UBSAN
- depends on !UBSAN_KCOV_BROKEN
depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS
help
This option enables detection of directly indexed out of bounds
@@ -72,7 +61,6 @@ config UBSAN_ARRAY_BOUNDS
config UBSAN_LOCAL_BOUNDS
bool "Perform array local bounds checking"
depends on UBSAN_TRAP
- depends on !UBSAN_KCOV_BROKEN
depends on $(cc-option,-fsanitize=local-bounds)
help
This option enables -fsanitize=local-bounds which traps when an
_
^ permalink raw reply [flat|nested] 83+ messages in thread