aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-07-29scripts/gdb: ensure the absolute path is generated on initial sourceAaron Tomlin1-1/+1
Post 'make scripts_gdb' a symbolic link to scripts/gdb/vmlinux-gdb.py is created. Currently 'os.path.dirname(__file__)' does not generate the absolute path to scripts/gdb resulting in the following: (gdb) source vmlinux-gdb.py Traceback (most recent call last): File "scripts/gdb/vmlinux-gdb.py", line 25, in <module> import linux.utils ModuleNotFoundError: No module named 'linux' This patch ensures that the absolute path to scripts/gdb in relation to the given file is generated so each module can be located accordingly. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Aaron Tomlin <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Cc: Jan Kiszka <[email protected]> Cc: Kieran Bingham <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29MAINTAINERS: kunit: add David Gow as a maintainer of KUnitBrendan Higgins1-0/+1
David has been a de facto maintainer of KUnit for a long time now. Formalize this in the MAINTAINERS file. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Brendan Higgins <[email protected]> Reviewed-by: David Gow <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Daniel Latypov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29mailmap: add linux.dev alias for Brendan HigginsBrendan Higgins1-0/+1
Because of my new work remote setup at Google, I can no longer use command line tools with my google.com email address, for this reason I got a linux.dev account. So update the mailmap to show the new alias I will be using. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Brendan Higgins <[email protected]> Reviewed-by: David Gow <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Daniel Latypov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29mailmap: update Kirill's emailKirill Tkhai1-1/+1
I disconnected from both Virtuozzo and OpenVZ, so this updates my email to point to my own. I haven't used @openvz address for patches, so let's rewrite the line instead of to add a new one. CC all previous addresses. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kirill Tkhai <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29profile: setup_profiling_timer() is moslty not implementedBen Dooks16-92/+6
The setup_profiling_timer() is mostly un-implemented by many architectures. In many places it isn't guarded by CONFIG_PROFILE which is needed for it to be used. Make it a weak symbol in kernel/profile.c and remove the 'return -EINVAL' implementations from the kenrel. There are a couple of architectures which do return 0 from the setup_profiling_timer() function but they don't seem to do anything else with it. To keep the /proc compatibility for now, leave these for a future update or removal. On ARM, this fixes the following sparse warning: arch/arm/kernel/smp.c:793:5: warning: symbol 'setup_profiling_timer' was not declared. Should it be static? Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ben Dooks <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29ocfs2: fix a typo in a commentChristophe JAILLET1-1/+1
s/heartbaet/heartbeat Link: https://lkml.kernel.org/r/4d4a6786e8ad522bfad6d2401b7f6634f8af0e5d.1658436259.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29ocfs2: use the bitmap API to simplify codeChristophe JAILLET1-2/+2
Use bitmap_zero() instead of hand-writing it. It is less verbose. While at it, add an explicit #include <linux/bitmap.h>. Link: https://lkml.kernel.org/r/86d2a027c319db12055c98f00c65f7d01e703722.1658436259.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29ocfs2: remove some useless functionsChristophe JAILLET1-19/+2
Patch series "ocfs2: A few clean_ups", v2. __ocfs2_node_map_set_bit() and __ocfs2_node_map_clear_bit() are just wrapper around set_bit() and clear_bit(). The leading __ also makes think that these functions are non-atomic just like __set_bit() and __clear_bit(). So, just remove these wrappers and call set_bit() and clear_bit() directly. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/bd1429c84ec7d174c96dbb67a2b42b1b456d9394.1658436259.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29lib/mpi: fix typo 'the the' in commentSlark Xiao1-1/+1
Replace 'the the' with 'the' in the comment. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Slark Xiao <[email protected]> Cc: Hongbo Li <[email protected]> Cc: Herbert Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29proc: add some (hopefully) insightful commentsAlexey Dobriyan4-5/+27
* /proc/${pid}/net status * removing PDE vs last close stuff (again!) * random small stuff Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29bdi: remove enum wb_congested_stateXiu Jianfeng1-7/+0
enum wb_congested_state and the member 'congested' in bdi_writeback are useless since commit a88f2096d5a2 ("remove congestion tracking framework"), so remove it. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Xiu Jianfeng <[email protected]> Reviewed-by: Jan Kara <[email protected]> Cc: NeilBrown <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29kernel/hung_task: fix address space of proc_dohung_task_timeout_secsBen Dooks1-1/+1
The proc_dohung_task_timeout_secs() function is incorrectly marked as having a __user buffer as argument 3. However this is not the case and it is casing multiple sparse warnings. Fix the following warnings by removing __user from the argument: kernel/hung_task.c:237:52: warning: incorrect type in argument 3 (different address spaces) kernel/hung_task.c:237:52: expected void * kernel/hung_task.c:237:52: got void [noderef] __user *buffer kernel/hung_task.c:287:35: warning: incorrect type in initializer (incompatible argument 3 (different address spaces)) kernel/hung_task.c:287:35: expected int ( [usertype] *proc_handler )( ... ) kernel/hung_task.c:287:35: got int ( * )( ... ) kernel/hung_task.c:295:35: warning: incorrect type in initializer (incompatible argument 3 (different address spaces)) kernel/hung_task.c:295:35: expected int ( [usertype] *proc_handler )( ... ) kernel/hung_task.c:295:35: got int ( * )( ... ) Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ben Dooks <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29lib/lzo/lzo1x_compress.c: replace ternary operator with min() and min_t()Jiangshan Yi1-4/+2
Fix the following coccicheck warning: lib/lzo/lzo1x_compress.c:54: WARNING opportunity for min(). lib/lzo/lzo1x_compress.c:329: WARNING opportunity for min(). min() and min_t() macro is defined in include/linux/minmax.h. It avoids multiple evaluations of the arguments when non-constant and performs strict type-checking. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jiangshan Yi <[email protected]> Tested-by: Dave Rodgman <[email protected]> Cc: Jonathan Corbet <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29squashfs: support reading fragments in readahead callPhillip Lougher1-3/+44
Add a function which can be used to read fragments in the readahead call. This function is necessary because filesystems built with the -tailends (or -always-use-fragments) option may have fragments present which cannot be currently handled. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Phillip Lougher <[email protected]> Signed-off-by: Hsin-Yi Wang <[email protected]> Cc: Hou Tao <[email protected]> Cc: kernel test robot <[email protected]> Cc: Marek Szyprowski <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Miao Xie <[email protected]> Cc: Xiongwei Song <[email protected]> Cc: Zhang Yi <[email protected]> Cc: Zheng Liang <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29squashfs: implement readaheadHsin-Yi Wang1-1/+91
Implement readahead callback for squashfs. It will read datablocks which cover pages in readahead request. For a few cases it will not mark page as uptodate, including: - file end is 0. - zero filled blocks. - current batch of pages isn't in the same datablock. - decompressor error. Otherwise pages will be marked as uptodate. The unhandled pages will be updated by readpage later. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Hsin-Yi Wang <[email protected]> Suggested-by: Matthew Wilcox <[email protected]> Reported-by: Matthew Wilcox <[email protected]> Reported-by: Phillip Lougher <[email protected]> Reported-by: Xiongwei Song <[email protected]> Reported-by: Andrew Morton <[email protected]> Cc: Hou Tao <[email protected]> Cc: kernel test robot <[email protected]> Cc: Marek Szyprowski <[email protected]> Cc: Miao Xie <[email protected]> Cc: Zhang Yi <[email protected]> Cc: Zheng Liang <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29squashfs: always build "file direct" version of page actorPhillip Lougher2-48/+2
Squashfs_readahead uses the "file direct" version of the page actor, and so build it unconditionally. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Phillip Lougher <[email protected]> Signed-off-by: Hsin-Yi Wang <[email protected]> Reported-by: kernel test robot <[email protected]> Cc: Hou Tao <[email protected]> Cc: Marek Szyprowski <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Miao Xie <[email protected]> Cc: Xiongwei Song <[email protected]> Cc: Zhang Yi <[email protected]> Cc: Zheng Liang <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-29Revert "squashfs: provide backing_dev_info in order to disable read-ahead"Hsin-Yi Wang1-33/+0
Patch series "Implement readahead for squashfs", v7. Commit 9eec1d897139("squashfs: provide backing_dev_info in order to disable read-ahead") mitigates the performance drop issue for squashfs by closing readahead for it. This series implements readahead callback for squashfs. This patch (of 4): This reverts 9eec1d897139e5 ("squashfs: provide backing_dev_info in order to disable read-ahead"). Revert closing the readahead to squashfs since the readahead callback for squashfs is implemented. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Hsin-Yi Wang <[email protected]> Suggested-by: Xiongwei Song <[email protected]> Cc: Phillip Lougher <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Marek Szyprowski <[email protected]> Cc: Zheng Liang <[email protected]> Cc: Zhang Yi <[email protected]> Cc: Hou Tao <[email protected]> Cc: Miao Xie <[email protected]> Cc: kernel test robot <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17fs/ocfs2: Fix spelling typo in commentJiangshan Yi1-1/+1
Fix spelling typo in comment. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jiangshan Yi <[email protected]> Reported-by: k2ci <[email protected]> Acked-by: Joseph Qi <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17ia64: old_rr4 added under CONFIG_HUGETLB_PAGESouptick Joarder (HPE)1-1/+4
kernel test robot throws below warning -> arch/ia64/include/asm/mmu_context.h: In function 'reload_context': arch/ia64/include/asm/mmu_context.h:127:48: warning: variable 'old_rr4' set but not used [-Wunused-but-set-variable] 127 | unsigned long rr0, rr1, rr2, rr3, rr4, old_rr4; Add it under CONFIG_HUGETLB_PAGE Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Souptick Joarder (HPE) <[email protected]> Reported-by: kernel test robot <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17proc: fix test for "vsyscall=xonly" boot optionAlexey Dobriyan1-7/+68
Booting with vsyscall=xonly results in the following vsyscall VMA: ffffffffff600000-ffffffffff601000 --xp ... [vsyscall] Test does read from fixed vsyscall address to determine if kernel supports vsyscall page but it doesn't work because, well, vsyscall page is execute only. Fix test by trying to execute from the first byte of the page which contains gettimeofday() stub. This should work because vsyscall entry points have stable addresses by design. Alexey, avoiding parsing .config, /proc/config.gz and /proc/cmdline at all costs. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Alexey Dobriyan <[email protected]> Cc: Shuah Khan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17proc: fix a dentry lock race between release_task and lookupZhihao Cheng1-8/+38
Commit 7bc3e6e55acf06 ("proc: Use a list of inodes to flush from proc") moved proc_flush_task() behind __exit_signal(). Then, process systemd can take long period high cpu usage during releasing task in following concurrent processes: systemd ps kernel_waitid stat(/proc/tgid) do_wait filename_lookup wait_consider_task lookup_fast release_task __exit_signal __unhash_process detach_pid __change_pid // remove task->pid_links d_revalidate -> pid_revalidate // 0 d_invalidate(/proc/tgid) shrink_dcache_parent(/proc/tgid) d_walk(/proc/tgid) spin_lock_nested(/proc/tgid/fd) // iterating opened fd proc_flush_pid | d_invalidate (/proc/tgid/fd) | shrink_dcache_parent(/proc/tgid/fd) | shrink_dentry_list(subdirs) ↓ shrink_lock_dentry(/proc/tgid/fd) --> race on dentry lock Function d_invalidate() will remove dentry from hash firstly, but why does proc_flush_pid() process dentry '/proc/tgid/fd' before dentry '/proc/tgid'? That's because proc_pid_make_inode() adds proc inode in reverse order by invoking hlist_add_head_rcu(). But proc should not add any inodes under '/proc/tgid' except '/proc/tgid/task/pid', fix it by adding inode into 'pid->inodes' only if the inode is /proc/tgid or /proc/tgid/task/pid. Performance regression: Create 200 tasks, each task open one file for 50,000 times. Kill all tasks when opened files exceed 10,000,000 (cat /proc/sys/fs/file-nr). Before fix: $ time killall -wq aa real 4m40.946s # During this period, we can see 'ps' and 'systemd' taking high cpu usage. After fix: $ time killall -wq aa real 1m20.732s # During this period, we can see 'systemd' taking high cpu usage. Link: https://lkml.kernel.org/r/[email protected] Fixes: 7bc3e6e55acf06 ("proc: Use a list of inodes to flush from proc") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216054 Signed-off-by: Zhihao Cheng <[email protected]> Signed-off-by: Zhang Yi <[email protected]> Suggested-by: Brian Foster <[email protected]> Reviewed-by: Brian Foster <[email protected]> Cc: Al Viro <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Eric Biederman <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Baoquan He <[email protected]> Cc: Kalesh Singh <[email protected]> Cc: Yu Kuai <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17autofs: remove unused ino field inodeIan Kent1-2/+0
Remove the unused inode field of the autofs dentry info structure. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ian Kent <[email protected]> Cc: Al Viro <[email protected]> Cc: David Howells <[email protected]> Cc: Miklos Szeredi <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17autofs: add comment about autofs_mountpoint_changed()Ian Kent1-3/+20
The function autofs_mountpoint_changed() is unusual, add a comment about two cases for which it is needed. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ian Kent <[email protected]> Cc: Al Viro <[email protected]> Cc: David Howells <[email protected]> Cc: Miklos Szeredi <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17autofs: use dentry info count instead of simple_empty()Ian Kent3-11/+14
The dentry info. field count is used to check if a dentry is in use during expire. But, to be used for this the count field must account for the presence of child dentries in a directory dentry. Therefore it can also be used to check for an empty directory dentry which can be done without having to to take an additional lock or account for the presence of a readdir cursor dentry as is done by simple_empty(). Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ian Kent <[email protected]> Cc: Al Viro <[email protected]> Cc: David Howells <[email protected]> Cc: Miklos Szeredi <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17autofs: make dentry info count consistentIan Kent2-4/+1
If an autofs dentry is a mount root directory there's no ->mkdir() call to set its count to one. To make the dentry info count consistent for all autofs dentries set count to one when the dentry info struct is allocated. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ian Kent <[email protected]> Cc: Al Viro <[email protected]> Cc: David Howells <[email protected]> Cc: Miklos Szeredi <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17autofs: use inode permission method for write accessIan Kent1-41/+22
Patch series "autofs: misc patches". This series contains several patches that resulted mostly from comments made by Al Viro (quite a long time ago now). This patch (of 5): Eliminate some code duplication from mkdir/rmdir/symlink/unlink methods by using the inode operation .permission(). Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ian Kent <[email protected]> Cc: Al Viro <[email protected]> Cc: David Howells <[email protected]> Cc: Miklos Szeredi <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17lib: devres: use numa aware allocationMark-PK Tsai1-5/+10
Allocate device resource from local node memory when the numa locality of the device is specified. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Mark-PK Tsai <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: YJ Chiang <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Zhen Lei <[email protected]> Cc: Jacob Keller <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17lib/smp_processor_id: fix imbalanced instrumentation_end() callTetsuo Handa1-1/+1
Currently instrumentation_end() won't be called if printk_ratelimit() returned false. Link: https://lkml.kernel.org/r/[email protected] Fixes: 126f21f0e8d46e2c ("lib/smp_processor_id: Move it into noinstr section") Signed-off-by: Tetsuo Handa <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Alexandre Chartre <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17cpumask: update cpumask_next_wrap() signatureSander Vanheule1-1/+1
The extern specifier is not needed for this declaration, so drop it. The function also depends only on the input parameters, and has no side effects, so it can be marked __pure like other functions in cpumask.h. Link: https://lkml.kernel.org/r/72ab755695b74bb5fbaa756ae4c0edd708d172f1.1656777646.git.sander@svanheule.net Signed-off-by: Sander Vanheule <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Marco Elver <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Valentin Schneider <[email protected]> Cc: Yury Norov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17lib/test: introduce cpumask KUnit test suiteSander Vanheule3-0/+148
Add a basic suite of tests for cpumask, providing some tests for empty and completely filled cpumasks. Link: https://lkml.kernel.org/r/c96980ec35c3bd23f17c3374bf42c22971545e85.1656777646.git.sander@svanheule.net Signed-off-by: Sander Vanheule <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Suggested-by: Yury Norov <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Marco Elver <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Valentin Schneider <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17cpumask: Fix invalid uniprocessor mask assumptionSander Vanheule3-82/+22
On uniprocessor builds, any CPU mask is assumed to contain exactly one CPU (cpu0). This assumption ignores the existence of empty masks, resulting in incorrect behaviour. cpumask_first_zero(), cpumask_next_zero(), and for_each_cpu_not() don't provide behaviour matching the assumption that a UP mask is always "1", and instead provide behaviour matching the empty mask. Drop the incorrectly optimised code and use the generic implementations in all cases. Link: https://lkml.kernel.org/r/86bf3f005abba2d92120ddd0809235cab4f759a6.1656777646.git.sander@svanheule.net Signed-off-by: Sander Vanheule <[email protected]> Suggested-by: Yury Norov <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Marco Elver <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Valentin Schneider <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17cpumask: add UP optimised for_each_*_cpu versionsSander Vanheule1-0/+7
On uniprocessor builds, the following loops will always run over a mask that contains one enabled CPU (cpu0): - for_each_possible_cpu - for_each_online_cpu - for_each_present_cpu Provide uniprocessor-specific macros for these loops, that always run exactly once. Link: https://lkml.kernel.org/r/3a92869b902a075b97be5d1452c9c6badbbff0df.1656777646.git.sander@svanheule.net Signed-off-by: Sander Vanheule <[email protected]> Acked-by: Yury Norov <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Marco Elver <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Valentin Schneider <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17x86/cacheinfo: move shared cache map definitionsSander Vanheule2-4/+6
Patch series "cpumask: Fix invalid uniprocessor assumptions", v4. On uniprocessor builds, it is currently assumed that any cpumask will contain the single CPU: cpu0. This assumption is used to provide optimised implementations. The current assumption also appears to be wrong, by ignoring the fact that users can provide empty cpumasks. This can result in bugs as explained in [1] - for_each_cpu() will run one iteration of the loop even when passed an empty cpumask. This series introduces some basic tests, and updates the optimisations for uniprocessor builds. The x86 patch was written after the kernel test robot [2] ran into a failed build. I have tried to list the files potentially affected by the changes to cpumask.h, in an attempt to find any other cases that fail on !SMP. I've gone through some of the files manually, and ran a few cross builds, but nothing else popped up. I (build) checked about half of the potientally affected files, but I do not have the resources to do them all. I hope we can fix other issues if/when they pop up later. [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/[email protected]/ This patch (of 5): The maps to keep track of shared caches between CPUs on SMP systems are declared in asm/smp.h, among them specifically cpu_llc_shared_map. These maps are externally defined in cpu/smpboot.c. The latter is only compiled on CONFIG_SMP=y, which means the declared extern symbols from asm/smp.h do not have a corresponding definition on uniprocessor builds. The inline cpu_llc_shared_mask() function from asm/smp.h refers to the map declaration mentioned above. This function is referenced in cacheinfo.c inside for_each_cpu() loop macros, to provide cpumask for the loop. On uniprocessor builds, the symbol for the cpu_llc_shared_map does not exist. However, the current implementation of for_each_cpu() also (wrongly) ignores the provided mask. By sheer luck, the compiler thus optimises out this unused reference to cpu_llc_shared_map, and the linker therefore does not require the cpu_llc_shared_mask to actually exist on uniprocessor builds. Only on SMP bulids does smpboot.o exist to provide the required symbols. To no longer rely on compiler optimisations for successful uniprocessor builds, move the definitions of cpu_llc_shared_map and cpu_l2c_shared_map from smpboot.c to cacheinfo.c. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/e8167ddb570f56744a3dc12c2149a660a324d969.1656777646.git.sander@svanheule.net Signed-off-by: Sander Vanheule <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Marco Elver <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Valentin Schneider <[email protected]> Cc: Yury Norov <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17scripts/bloat-o-meter: add -p argumentNikolay Borisov1-1/+6
When doing cross platform development on a machine sometimes it might be useful to invoke bloat-o-meter for files which haven't been build with the native toolchain. In cases when the host nm doesn't support the target one then a toolchain-specific nm could be used. Add this ability by adding the -p allowing invocations as: ./scripts/bloat-o-meter -p riscv64-unknown-linux-gnu- file1.o file2.o Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Nikolay Borisov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17scripts/bloat-o-meter: switch argument parsing to using argparseNikolay Borisov1-19/+21
This will facilitate further extension to the arguments the script takes. As an added benefit it also produces saner usage output, where mutual exclusivity of the c|d|t parameters is clearly visible: ./scripts/bloat-o-meter -h usage: bloat-o-meter [-h] [-c | -d | -t] file1 file2 Simple script used to compare the symbol sizes of 2 object files positional arguments: file1 First file to compare file2 Second file to compare optional arguments: -h, --help show this help message and exit -c categorize output based on symbol type -d Show delta of Data Section -t Show delta of text Section Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Nikolay Borisov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17epoll: autoremove wakers even more aggressivelyBenjamin Segall1-0/+22
If a process is killed or otherwise exits while having active network connections and many threads waiting on epoll_wait, the threads will all be woken immediately, but not removed from ep->wq. Then when network traffic scans ep->wq in wake_up, every wakeup attempt will fail, and will not remove the entries from the list. This means that the cost of the wakeup attempt is far higher than usual, does not decrease, and this also competes with the dying threads trying to actually make progress and remove themselves from the wq. Handle this by removing visited epoll wq entries unconditionally, rather than only when the wakeup succeeds - the structure of ep_poll means that the only potential loss is the timed_out->eavail heuristic, which now can race and result in a redundant ep_send_events attempt. (But only when incoming data and a timeout actually race, not on every timeout) Shakeel added: : We are seeing this issue in production with real workloads and it has : caused hard lockups. Particularly network heavy workloads with a lot : of threads in epoll_wait() can easily trigger this issue if they get : killed (oom-killed in our case). Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ben Segall <[email protected]> Tested-by: Shakeel Butt <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Roman Penyaev <[email protected]> Cc: Jason Baron <[email protected]> Cc: Khazhismel Kumykov <[email protected]> Cc: Heiher <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17ipc/mqueue: remove unnecessary (void*) conversionYu Zhe1-1/+1
Remove unnecessary void* type casting. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Yu Zhe <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17kdump: round up the total memory size to 128M for crashkernel reservationTao Liu1-2/+12
The total memory size we get in kernel is usually slightly less than the actual memory size because BIOS/firmware will reserve some memory region. So it won't export all memory as usable. E.g, on my x86_64 kvm guest with 1G memory, the total_mem value shows: UEFI boot with ovmf: 0x3faef000 Legacy boot kvm guest: 0x3ff7ec00 When specifying crashkernel=1G-2G:128M, if we have a 1G memory machine, we get total size 1023M from firmware. Then it will not fall into 1G-2G, thus no memory reserved. User will never know this, it is hard to let user know the exact total value in kernel. One way is to use dmi/smbios to get physical memory size, but it's not reliable as well. According to Prarit hardware vendors sometimes screw this up. Thus round up total size to 128M to work around this problem. This patch is a resend of [1] and rebased onto v5.19-rc2, and the original credit goes to Dave Young. [1]: http://lists.infradead.org/pipermail/kexec/2018-April/020568.html Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Tao Liu <[email protected]> Acked-by: Baoquan He <[email protected]> Cc: Dave Young <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17proc: delete unused <linux/uaccess.h> includesAlexey Dobriyan8-14/+0
Those aren't necessary after seq files won. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17vmcoreinfo: include kallsyms symbolsStephen Brennan1-0/+14
The internal kallsyms tables contain information which could be quite useful to a debugging tool in the absence of other debuginfo. If kallsyms is enabled, then a debugging tool could parse it and use it as a fallback symbol table. Combined with BTF data, live & post-mortem debuggers can support basic operations without needing a large DWARF debuginfo file available. As many as five symbols are necessary to properly parse kallsyms names and addresses. Add these to the vmcoreinfo note. CONFIG_KALLSYMS_ABSOLUTE_PERCPU does impact the computation of symbol addresses. However, a debugger can infer this configuration value by comparing the address of _stext in the vmcoreinfo with the address computed via kallsyms. So there's no need to include information about this config value in the vmcoreinfo note. To verify that we're still well below the maximum of 4096 bytes, I created a script[1] to compute a rough upper bound on the possible size of vmcoreinfo. On v5.18-rc7, the script reports 3106 bytes, and with this patch, the maximum become 3370 bytes. [1]: https://github.com/brenns10/kernel_stuff/blob/master/vmcoreinfosize/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Stephen Brennan <[email protected]> Acked-by: Baoquan He <[email protected]> Cc: Bixuan Cui <[email protected]> Cc: Dave Young <[email protected]> Cc: David Vernet <[email protected]> Cc: "Eric W. Biederman" <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kees Cook <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Sami Tolvanen <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: Vivek Goyal <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17kallsyms: move declarations to internal headerStephen Brennan2-22/+31
Patch series "Expose kallsyms data in vmcoreinfo note". The kernel can be configured to contain a lot of introspection or debugging information built-in, such as ORC for unwinding stack traces, BTF for type information, and of course kallsyms. Debuggers could use this information to navigate a core dump or live system, but they need to be able to find it. This patch series adds the necessary symbols into vmcoreinfo, which would allow a debugger to find and interpret the kallsyms table. Using the kallsyms data, the debugger can then lookup any symbol, allowing it to find ORC, BTF, or any other useful data. This would allow a live kernel, or core dump, to be debugged without any DWARF debuginfo. This is useful for many cases: the debuginfo may not have been generated, or you may not want to deploy the large files everywhere you need them. I've demonstrated a proof of concept for this at LSF/MM+BPF during a lighting talk. Using a work-in-progress branch of the drgn debugger, and an extended set of BTF generated by a patched version of dwarves, I've been able to open a core dump without any DWARF info and do basic tasks such as enumerating slab caches, block devices, tasks, and doing backtraces. I hope this series can be a first step toward a new possibility of "DWARFless debugging". Related discussion around the BTF side of this: https://lore.kernel.org/bpf/[email protected]/T/#u Some work-in-progress branches using this feature: https://github.com/brenns10/dwarves/tree/remove_percpu_restriction_1 https://github.com/brenns10/drgn/tree/kallsyms_plus_btf This patch (of 2): To include kallsyms data in the vmcoreinfo note, we must make the symbol declarations visible outside of kallsyms.c. Move these to a new internal header file. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Stephen Brennan <[email protected]> Acked-by: Baoquan He <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Dave Young <[email protected]> Cc: Kees Cook <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: Bixuan Cui <[email protected]> Cc: David Vernet <[email protected]> Cc: Vivek Goyal <[email protected]> Cc: Sami Tolvanen <[email protected]> Cc: "Eric W. Biederman" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17lib/ts_bm.c: remove redundant store to variable consumed after additionColin Ian King1-1/+1
There is no need to store the result of the addition back to variable consumed after the addition. The store is redundant, replace += with just + Cleans up clang scan build warning: lib/ts_bm.c:83:11: warning: Although the value stored to 'consumed' is used in the enclosing expression, the value is never actually read from 'consumed' [deadcode.DeadStores] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17lib/scatterlist: use matched parameter type when calling __sg_free_table()wuchi1-2/+2
commit 4635873c561a ("scsi: lib/sg_pool.c: improve APIs for allocating sg pool") changeed @(bool)skip_first_chunk of __sg_free_table() to @(unsigned int)nents_first_chunk, so use unsigend int type instead of bool type (false -> 0) when calling the function in sg_free_append_table() and sg_free_table(). Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: wuchi <[email protected]> Reviewed-by: Ming Lei <[email protected]> Cc: Maor Gottlieb <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17lib: make LZ4_decompress_safe_forceExtDict() staticTiezhu Yang1-3/+3
LZ4_decompress_safe_forceExtDict() is only used in lib/lz4/lz4_decompress.c, make it static to fix the build warning about "no previous prototype" [1]. [1] https://lore.kernel.org/lkml/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Tiezhu Yang <[email protected]> Reported-by: kernel test robot <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17lib/radix-tree: remove unused argument of insert_entrieswuchi1-2/+2
insert_entries() doesn't use the 'bool replace' argument, and the function is only used locally, remove the argument. The historical context of the unused argument is as follow: 2: commit <3a08cd52c37c79> (radix tree: Remove multiorder support) Remove the code related to macro CONFIG_RADIX_TREE_MULTIORDER to convert to the xArray. Without the macro, there is no need to retain the argument. 1: commit <175542f575723e> (radix-tree: add radix_tree_join) Add insert_entries(..., bool replace) function, depending on the macro CONFIG_RADIX_TREE_MULTIORDER definition, the implementation is different. Notice that the implementation without the macro doesn't use the argument. [Matthew Wilcox: add historical context for argument] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: wuchi <[email protected]> Cc: Matthew Wilcox <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17kfifo: fix kfifo_to_user() return typeDan Carpenter1-1/+1
The kfifo_to_user() macro is supposed to return zero for success or negative error codes. Unfortunately, there is a signedness bug so it returns unsigned int. This only affects callers which try to save the result in ssize_t and as far as I can see the only place which does that is line6_hwdep_read(). TL;DR: s/_uint/_int/. Link: https://lkml.kernel.org/r/YrVL3OJVLlNhIMFs@kili Fixes: 144ecf310eb5 ("kfifo: fix kfifo_alloc() to return a signed int value") Signed-off-by: Dan Carpenter <[email protected]> Cc: Stefani Seibold <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17compiler-gcc.h: remove ancient workaround for gcc PR 58670Uros Bizjak1-11/+0
The workaround for 'asm goto' miscompilation introduces a compiler barrier quirk that inhibits many useful compiler optimizations. For example, __try_cmpxchg_user compiles to: 11375: 41 8b 4d 00 mov 0x0(%r13),%ecx 11379: 41 8b 02 mov (%r10),%eax 1137c: f0 0f b1 0a lock cmpxchg %ecx,(%rdx) 11380: 0f 94 c2 sete %dl 11383: 84 d2 test %dl,%dl 11385: 75 c4 jne 1134b <...> 11387: 41 89 02 mov %eax,(%r10) where the barrier inhibits flags propagation from asm when compiled with gcc-12. When the mentioned quirk is removed, the following code is generated: 11553: 41 8b 4d 00 mov 0x0(%r13),%ecx 11557: 41 8b 02 mov (%r10),%eax 1155a: f0 0f b1 0a lock cmpxchg %ecx,(%rdx) 1155e: 74 c9 je 11529 <...> 11560: 41 89 02 mov %eax,(%r10) The refered compiler bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 was fixed for gcc-4.8.2. Current minimum required version of GCC is version 5.1 which has the above 'asm goto' miscompilation fixed, so remove the workaround. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Uros Bizjak <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17lib/error-inject: traverse list with mutexwuchi1-3/+9
Traversing list without mutex in get_injectable_error_type will race with the following code: list_del_init(&ent->list) kfree(ent) in module_unload_ei_list. So fix that. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: wuchi <[email protected]> Cc: Masami Hiramatsu (Google) <[email protected]> Cc: Martin KaFai Lau <[email protected]> Cc: Song Liu <[email protected]> Cc: Yonghong Song <[email protected]> Cc: John Fastabend <[email protected]> Cc: KP Singh <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17lib/stackdepot: replace CONFIG_STACK_HASH_ORDER with automatic sizingVlastimil Babka2-19/+49
As Linus explained [1], setting the stackdepot hash table size as a config option is suboptimal, especially as stackdepot becomes a dependency of less "expert" subsystems than initially (e.g. DRM, networking, SLUB_DEBUG): : (a) it introduces a new compile-time question that isn't sane to ask : a regular user, but is now exposed to regular users. : (b) this by default uses 1MB of memory for a feature that didn't in : the past, so now if you have small machines you need to make sure you : make a special kernel config for them. Ideally we would employ rhashtable for fully automatic resizing, which should be feasible for many of the new users, but problematic for the original users with restricted context that call __stack_depot_save() with can_alloc == false, i.e. KASAN. However we can easily remove the config option and scale the hash table automatically with system memory. The STACK_HASH_MASK constant becomes stack_hash_mask variable and is used only in one mask operation, so the overhead should be negligible to none. For early allocation we can employ the existing alloc_large_system_hash() function and perform similar scaling for the late allocation. The existing limits of the config option (between 4k and 1M buckets) are preserved, and scaling factor is set to one bucket per 16kB memory so on 64bit the max 1M buckets (8MB memory) is achieved with 16GB system, while a 1GB system will use 512kB. Because KASAN is reported to need the maximum number of buckets even with smaller amounts of memory [2], set it as such when kasan_enabled(). If needed, the automatic scaling could be complemented with a boot-time kernel parameter, but it feels pointless to add it without a specific use case. [1] https://lore.kernel.org/all/CAHk-=wjC5nS+fnf6EzRD9yQRJApAhxx7gRB87ZV+pAWo9oVrTg@mail.gmail.com/ [2] https://lore.kernel.org/all/CACT4Y+Y4GZfXOru2z5tFPzFdaSUd+GFc6KVL=bsa0+1m197cQQ@mail.gmail.com/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Vlastimil Babka <[email protected]> Reported-by: Linus Torvalds <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Marco Elver <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-07-17net, lib/once: remove {net_}get_random_once_wait macrowuchi2-4/+0
DO_ONCE(func, ...) will call func with spinlock which acquired by spin_lock_irqsave in __do_once_start. But the get_random_once_wait will sleep in get_random_bytes_wait -> wait_for_random_bytes. Fortunately, there is no place to use {net_}get_random_once_wait, so we could remove them simply. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: wuchi <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Cc: David S. Miller <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Paolo Abeni <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.