aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-08-12mm/hugetlb: make hugetlb migration callback CMA awareJoonsoo Kim3-9/+10
new_non_cma_page() in gup.c requires to allocate the new page that is not on the CMA area. new_non_cma_page() implements it by using allocation scope APIs. However, there is a work-around for hugetlb. Normal hugetlb page allocation API for migration is alloc_huge_page_nodemask(). It consists of two steps. First is dequeing from the pool. Second is, if there is no available page on the queue, allocating by using the page allocator. new_non_cma_page() can't use this API since first step (deque) isn't aware of scope API to exclude CMA area. So, new_non_cma_page() exports hugetlb internal function for the second step, alloc_migrate_huge_page(), to global scope and uses it directly. This is suboptimal since hugetlb pages on the queue cannot be utilized. This patch tries to fix this situation by making the deque function on hugetlb CMA aware. In the deque function, CMA memory is skipped if PF_MEMALLOC_NOCMA flag is found. Signed-off-by: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Mike Kravetz <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: "Aneesh Kumar K . V" <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Roman Gushchin <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12mm/gup: restrict CMA region by using allocation scope APIJoonsoo Kim2-9/+10
We have well defined scope API to exclude CMA region. Use it rather than manipulating gfp_mask manually. With this change, we can now restore __GFP_MOVABLE for gfp_mask like as usual migration target allocation. It would result in that the ZONE_MOVABLE is also searched by page allocator. For hugetlb, gfp_mask is redefined since it has a regular allocation mask filter for migration target. __GPF_NOWARN is added to hugetlb gfp_mask filter since a new user for gfp_mask filter, gup, want to be silent when allocation fails. Note that this can be considered as a fix for the commit 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region"). However, "Fixes" tag isn't added here since it is just suboptimal but it doesn't cause any problem. Suggested-by: Michal Hocko <[email protected]> Signed-off-by: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: "Aneesh Kumar K . V" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12mm/page_alloc: remove a wrapper for alloc_migration_target()Joonsoo Kim2-12/+6
There is a well-defined standard migration target callback. Use it directly. Signed-off-by: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Roman Gushchin <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12mm/mempolicy: use a standard migration target allocation callbackJoonsoo Kim3-28/+12
There is a well-defined migration target allocation callback. Use it. Signed-off-by: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Roman Gushchin <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12mm/migrate: introduce a standard migration target allocation functionJoonsoo Kim7-22/+61
There are some similar functions for migration target allocation. Since there is no fundamental difference, it's better to keep just one rather than keeping all variants. This patch implements base migration target allocation function. In the following patches, variants will be converted to use this function. Changes should be mechanical, but, unfortunately, there are some differences. First, some callers' nodemask is assgined to NULL since NULL nodemask will be considered as all available nodes, that is, &node_states[N_MEMORY]. Second, for hugetlb page allocation, gfp_mask is redefined as regular hugetlb allocation gfp_mask plus __GFP_THISNODE if user provided gfp_mask has it. This is because future caller of this function requires to set this node constaint. Lastly, if provided nodeid is NUMA_NO_NODE, nodeid is set up to the node where migration source lives. It helps to remove simple wrappers for setting up the nodeid. Note that PageHighmem() call in previous function is changed to open-code "is_highmem_idx()" since it provides more readability. [[email protected]: tweak patch title, per Vlastimil] [[email protected]: fix typo in comment] Signed-off-by: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Roman Gushchin <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12mm/migrate: clear __GFP_RECLAIM to make the migration callback consistent ↵Joonsoo Kim1-0/+5
with regular THP allocations new_page_nodemask is a migration callback and it tries to use a common gfp flags for the target page allocation whether it is a base page or a THP. The later only adds GFP_TRANSHUGE to the given mask. This results in the allocation being slightly more aggressive than necessary because the resulting gfp mask will contain also __GFP_RECLAIM_KSWAPD. THP allocations usually exclude this flag to reduce over eager background reclaim during a high THP allocation load which has been seen during large mmaps initialization. There is no indication that this is a problem for migration as well but theoretically the same might happen when migrating large mappings to a different node. Make the migration callback consistent with regular THP allocations. [[email protected]: fix comment typo, per Vlastimil] Signed-off-by: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Roman Gushchin <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12mm/hugetlb: unify migration callbacksJoonsoo Kim4-49/+33
There is no difference between two migration callback functions, alloc_huge_page_node() and alloc_huge_page_nodemask(), except __GFP_THISNODE handling. It's redundant to have two almost similar functions in order to handle this flag. So, this patch tries to remove one by introducing a new argument, gfp_mask, to alloc_huge_page_nodemask(). After introducing gfp_mask argument, it's caller's job to provide correct gfp_mask. So, every callsites for alloc_huge_page_nodemask() are changed to provide gfp_mask. Note that it's safe to remove a node id check in alloc_huge_page_node() since there is no caller passing NUMA_NO_NODE as a node id. Signed-off-by: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Mike Kravetz <[email protected]> Reviewed-by: Vlastimil Babka <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Roman Gushchin <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12mm/migrate: move migration helper from .h to .cJoonsoo Kim2-28/+34
It's not performance sensitive function. Move it to .c. This is a preparation step for future change. Signed-off-by: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Vlastimil Babka <[email protected]> Acked-by: Mike Kravetz <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Roman Gushchin <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12mm/page_isolation: prefer the node of the source pageJoonsoo Kim1-1/+3
Patch series "clean-up the migration target allocation functions", v5. This patch (of 9): For locality, it's better to migrate the page to the same node rather than the node of the current caller's cpu. Signed-off-by: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Vlastimil Babka <[email protected]> Acked-by: Roman Gushchin <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Naoya Horiguchi <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12ipc/shm.c: remove the superfluous breakLiao Pingfang1-1/+0
Remove the superfuous break, as there is a 'return' before it. Signed-off-by: Liao Pingfang <[email protected]> Signed-off-by: Yi Wang <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12ipc: uninline functionsAlexey Dobriyan2-4/+2
Two functions are only called via function pointers, don't bother inlining them. Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Manfred Spraul <[email protected]> Cc: Davidlohr Bueso <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12scripts/gdb: fix python 3.8 SyntaxWarningNick Desaulniers1-2/+2
Fixes the observed warnings: scripts/gdb/linux/rbtree.py:20: SyntaxWarning: "is" with a literal. Did you mean "=="? if node is 0: scripts/gdb/linux/rbtree.py:36: SyntaxWarning: "is" with a literal. Did you mean "=="? if node is 0: It looks like this is a new warning added in Python 3.8. I've only seen this once after adding the add-auto-load-safe-path rule to my ~/.gdbinit for a new tree. Fixes: commit 449ca0c95ea2 ("scripts/gdb: add rb tree iterating utilities") Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Cc: Jan Kiszka <[email protected]> Cc: Kieran Bingham <[email protected]> Cc: Aymeric Agon-Rambosson <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Link: https://adamj.eu/tech/2020/01/21/why-does-python-3-8-syntaxwarning-for-is-literal/ Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12kcov: make some symbols staticWei Yongjun1-3/+3
Fix sparse build warnings: kernel/kcov.c:99:1: warning: symbol '__pcpu_scope_kcov_percpu_data' was not declared. Should it be static? kernel/kcov.c:778:6: warning: symbol 'kcov_remote_softirq_start' was not declared. Should it be static? kernel/kcov.c:795:6: warning: symbol 'kcov_remote_softirq_stop' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Konovalov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12kcov: unconditionally add -fno-stack-protector to compiler optionsMarco Elver1-1/+1
Unconditionally add -fno-stack-protector to KCOV's compiler options, as all supported compilers support the option. This saves a compiler invocation to determine if the option is supported. Because Clang does not support -fno-conserve-stack, and -fno-stack-protector was wrapped in the same cc-option, we were missing -fno-stack-protector with Clang. Unconditionally adding this option fixes this for Clang. Suggested-by: Nick Desaulniers <[email protected]> Signed-off-by: Marco Elver <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Andrey Konovalov <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12panic: make print_oops_end_marker() staticYue Hu2-2/+1
Since print_oops_end_marker() is not used externally, also remove it in kernel.h at the same time. Signed-off-by: Yue Hu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Kees Cook <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12lib/Kconfig.debug: fix typo in the help text of CONFIG_PANIC_TIMEOUTTiezhu Yang1-1/+1
There exists duplicated "the" in the help text of CONFIG_PANIC_TIMEOUT, Remove it. Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Xuefeng Li <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12kernel/panic.c: make oops_may_print() return boolTiezhu Yang2-2/+2
The return value of oops_may_print() is true or false, so change its type to reflect that. Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Xuefeng Li <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12rapidio/rio_mport_cdev: use array_size() helper in copy_{from,to}_user()Gustavo A. R. Silva1-2/+2
Use array_size() helper instead of the open-coded version in copy_{from,to}_user(). These sorts of multiplication factors need to be wrapped in array_size(). This issue was found with the help of Coccinelle and, audited and fixed manually. Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Matt Porter <[email protected]> Cc: Alexandre Bounine <[email protected]> Link: http://lkml.kernel.org/r/20200616183050.GA31840@embeddedor Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83 Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12drivers/rapidio/rio-scan.c: use struct_size() helperGustavo A. R. Silva1-5/+3
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. Also, while there, use the preferred form for passing a size of a struct. The alternative form where struct name is spelled out hurts readability and introduces an opportunity for a bug when the pointer variable type is changed but the corresponding sizeof that is passed as argument is not. This issue was found with the help of Coccinelle and, audited and fixed manually. Addresses KSPP ID: https://github.com/KSPP/linux/issues/83 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Matt Porter <[email protected]> Cc: Alexandre Bounine <[email protected]> Link: http://lkml.kernel.org/r/20200619170445.GA22641@embeddedor Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12drivers/rapidio/devices/rio_mport_cdev.c: use struct_size() helperGustavo A. R. Silva1-2/+1
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This issue was found with the help of Coccinelle and, audited and fixed manually. Addresses KSPP ID: https://github.com/KSPP/linux/issues/83 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Matt Porter <[email protected]> Cc: Alexandre Bounine <[email protected]> Link: http://lkml.kernel.org/r/20200619170843.GA24923@embeddedor Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12kdump: append kernel build-id string to VMCOREINFOVijay Balakrishna2-0/+56
Make kernel GNU build-id available in VMCOREINFO. Having build-id in VMCOREINFO facilitates presenting appropriate kernel namelist image with debug information file to kernel crash dump analysis tools. Currently VMCOREINFO lacks uniquely identifiable key for crash analysis automation. Regarding if this patch is necessary or matching of linux_banner and OSRELEASE in VMCOREINFO employed by crash(8) meets the need -- IMO, build-id approach more foolproof, in most instances it is a cryptographic hash generated using internal code/ELF bits unlike kernel version string upon which linux_banner is based that is external to the code. I feel each is intended for a different purpose. Also OSRELEASE is not suitable when two different kernel builds from same version with different features enabled. Currently for most linux (and non-linux) systems build-id can be extracted using standard methods for file types such as user mode crash dumps, shared libraries, loadable kernel modules etc., This is an exception for linux kernel dump. Having build-id in VMCOREINFO brings some uniformity for automation tools. Tyler said: : I think this is a nice improvement over today's linux_banner approach for : correlating vmlinux to a kernel dump. : : The elf notes parsing in this patch lines up with what is described in in : the "Notes (Nhdr)" section of the elf(5) man page. : : BUILD_ID_MAX is sufficient to hold a sha1 build-id, which is the default : build-id type today in GNU ld(2). It is also sufficient to hold the : "fast" build-id, which is the default build-id type today in LLVM lld(2). Signed-off-by: Vijay Balakrishna <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Tyler Hicks <[email protected]> Acked-by: Baoquan He <[email protected]> Cc: Dave Young <[email protected]> Cc: Vivek Goyal <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12exec: move path_noexec() check earlierKees Cook2-8/+8
The path_noexec() check, like the regular file check, was happening too late, letting LSMs see impossible execve()s. Check it earlier as well in may_open() and collect the redundant fs/exec.c path_noexec() test under the same robustness comment as the S_ISREG() check. My notes on the call path, and related arguments, checks, etc: do_open_execat() struct open_flags open_exec_flags = { .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, .acc_mode = MAY_EXEC, ... do_filp_open(dfd, filename, open_flags) path_openat(nameidata, open_flags, flags) file = alloc_empty_file(open_flags, current_cred()); do_open(nameidata, file, open_flags) may_open(path, acc_mode, open_flag) /* new location of MAY_EXEC vs path_noexec() test */ inode_permission(inode, MAY_OPEN | acc_mode) security_inode_permission(inode, acc_mode) vfs_open(path, file) do_dentry_open(file, path->dentry->d_inode, open) security_file_open(f) open() /* old location of path_noexec() test */ Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Aleksa Sarai <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Eric Biggers <[email protected]> Cc: Tetsuo Handa <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12exec: move S_ISREG() check earlierKees Cook3-10/+16
The execve(2)/uselib(2) syscalls have always rejected non-regular files. Recently, it was noticed that a deadlock was introduced when trying to execute pipes, as the S_ISREG() test was happening too late. This was fixed in commit 73601ea5b7b1 ("fs/open.c: allow opening only regular files during execve()"), but it was added after inode_permission() had already run, which meant LSMs could see bogus attempts to execute non-regular files. Move the test into the other inode type checks (which already look for other pathological conditions[1]). Since there is no need to use FMODE_EXEC while we still have access to "acc_mode", also switch the test to MAY_EXEC. Also include a comment with the redundant S_ISREG() checks at the end of execve(2)/uselib(2) to note that they are present to avoid any mistakes. My notes on the call path, and related arguments, checks, etc: do_open_execat() struct open_flags open_exec_flags = { .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, .acc_mode = MAY_EXEC, ... do_filp_open(dfd, filename, open_flags) path_openat(nameidata, open_flags, flags) file = alloc_empty_file(open_flags, current_cred()); do_open(nameidata, file, open_flags) may_open(path, acc_mode, open_flag) /* new location of MAY_EXEC vs S_ISREG() test */ inode_permission(inode, MAY_OPEN | acc_mode) security_inode_permission(inode, acc_mode) vfs_open(path, file) do_dentry_open(file, path->dentry->d_inode, open) /* old location of FMODE_EXEC vs S_ISREG() test */ security_file_open(f) open() [1] https://lore.kernel.org/lkml/202006041910.9EF0C602@keescook/ Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Aleksa Sarai <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Eric Biggers <[email protected]> Cc: Tetsuo Handa <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12exec: change uselib(2) IS_SREG() failure to EACCESKees Cook1-2/+1
Patch series "Relocate execve() sanity checks", v2. While looking at the code paths for the proposed O_MAYEXEC flag, I saw some things that looked like they should be fixed up. exec: Change uselib(2) IS_SREG() failure to EACCES This just regularizes the return code on uselib(2). exec: Move S_ISREG() check earlier This moves the S_ISREG() check even earlier than it was already. exec: Move path_noexec() check earlier This adds the path_noexec() check to the same place as the S_ISREG() check. This patch (of 3): Change uselib(2)' S_ISREG() error return to EACCES instead of EINVAL so the behavior matches execve(2), and the seemingly documented value. The "not a regular file" failure mode of execve(2) is explicitly documented[1], but it is not mentioned in uselib(2)[2] which does, however, say that open(2) and mmap(2) errors may apply. The documentation for open(2) does not include a "not a regular file" error[3], but mmap(2) does[4], and it is EACCES. [1] http://man7.org/linux/man-pages/man2/execve.2.html#ERRORS [2] http://man7.org/linux/man-pages/man2/uselib.2.html#ERRORS [3] http://man7.org/linux/man-pages/man2/open.2.html#ERRORS [4] http://man7.org/linux/man-pages/man2/mmap.2.html#ERRORS Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Christian Brauner <[email protected]> Cc: Aleksa Sarai <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Eric Biggers <[email protected]> Cc: Tetsuo Handa <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12coredump: add %f for executable filenameLepton Wu2-5/+15
The document reads "%e" should be "executable filename" while actually it could be changed by things like pr_ctl PR_SET_NAME. People who uses "%e" in core_pattern get surprised when they find out they get thread name instead of executable filename. This is either a bug of document or a bug of code. Since the behavior of "%e" is there for long time, it could bring another surprise for users if we "fix" the code. So we just "fix" the document. And more, for users who really need the "executable filename" in core_pattern, we introduce a new "%f" for the real executable filename. We already have "%E" for executable path in kernel, so just reuse most of its code for the new added "%f" format. Signed-off-by: Lepton Wu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12test_kmod: avoid potential double free in trigger_config_run_type()Tiezhu Yang1-1/+1
Reset the member "test_fs" of the test configuration after a call of the function "kfree_const" to a null pointer so that a double memory release will not be performed. Fixes: d9c6a72d6fa2 ("kmod: add test driver to stress test the module loader") Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Luis Chamberlain <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Al Viro <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Chuck Lever <[email protected]> Cc: David Howells <[email protected]> Cc: David S. Miller <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: James Morris <[email protected]> Cc: Jarkko Sakkinen <[email protected]> Cc: J. Bruce Fields <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Kees Cook <[email protected]> Cc: Lars Ellenberg <[email protected]> Cc: Nikolay Aleksandrov <[email protected]> Cc: Philipp Reisner <[email protected]> Cc: Roopa Prabhu <[email protected]> Cc: "Serge E. Hallyn" <[email protected]> Cc: Sergei Trofimovich <[email protected]> Cc: Sergey Kvachonok <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Tony Vroon <[email protected]> Cc: Christoph Hellwig <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12kmod: remove redundant "be an" in the commentTiezhu Yang1-3/+2
There exists redundant "be an" in the comment, remove it. Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Luis Chamberlain <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Al Viro <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Chuck Lever <[email protected]> Cc: David Howells <[email protected]> Cc: David S. Miller <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: James Morris <[email protected]> Cc: Jarkko Sakkinen <[email protected]> Cc: J. Bruce Fields <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Kees Cook <[email protected]> Cc: Lars Ellenberg <[email protected]> Cc: Nikolay Aleksandrov <[email protected]> Cc: Philipp Reisner <[email protected]> Cc: Roopa Prabhu <[email protected]> Cc: "Serge E. Hallyn" <[email protected]> Cc: Sergei Trofimovich <[email protected]> Cc: Sergey Kvachonok <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Tony Vroon <[email protected]> Cc: Christoph Hellwig <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12selftests: kmod: use variable NAME in kmod_test_0001()Tiezhu Yang1-2/+2
Patch series "kmod/umh: a few fixes". Tiezhu Yang had sent out a patch set with a slew of kmod selftest fixes, and one patch which modified kmod to return 254 when a module was not found. This opened up pandora's box about why that was being used for and low and behold its because when UMH_WAIT_PROC is used we call a kernel_wait4() call but have never unwrapped the error code. The commit log for that fix details the rationale for the approach taken. I'd appreciate some review on that, in particular nfs folks as it seems a case was never really hit before. This patch (of 5): Use the variable NAME instead of "\000" directly in kmod_test_0001(). Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Luis Chamberlain <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Al Viro <[email protected]> Cc: Philipp Reisner <[email protected]> Cc: Lars Ellenberg <[email protected]> Cc: Jens Axboe <[email protected]> Cc: J. Bruce Fields <[email protected]> Cc: Chuck Lever <[email protected]> Cc: Roopa Prabhu <[email protected]> Cc: Nikolay Aleksandrov <[email protected]> Cc: David S. Miller <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: David Howells <[email protected]> Cc: Jarkko Sakkinen <[email protected]> Cc: James Morris <[email protected]> Cc: "Serge E. Hallyn" <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Sergei Trofimovich <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Kees Cook <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Sergey Kvachonok <[email protected]> Cc: Tony Vroon <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Christoph Hellwig <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12fs/signalfd.c: fix inconsistent return codes for signalfd4Helge Deller1-4/+6
The kernel signalfd4() syscall returns different error codes when called either in compat or native mode. This behaviour makes correct emulation in qemu and testing programs like LTP more complicated. Fix the code to always return -in both modes- EFAULT for unaccessible user memory, and EINVAL when called with an invalid signal mask. Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Laurent Vivier <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12fat: fix fat_ra_init() for data clusters == 0OGAWA Hirofumi1-0/+3
If data clusters == 0, fat_ra_init() calls the ->ent_blocknr() for the cluster beyond ->max_clusters. This checks the limit before initialization to suppress the warning. Reported-by: [email protected] Signed-off-by: OGAWA Hirofumi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12VFAT/FAT/MSDOS FILESYSTEM: replace HTTP links with HTTPS onesAlexander A. Klimov1-1/+1
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `xmlns`: For each link, `http://[^# ]*(?:\w|/)`: If neither `gnu\.org/license`, nor `mozilla\.org/MPL`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: OGAWA Hirofumi <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12fatfs: switch write_lock to read_lock in fat_ioctl_get_attributesYubo Feng1-2/+2
There is no need to hold write_lock in fat_ioctl_get_attributes. write_lock may make an impact on concurrency of fat_ioctl_get_attributes. Signed-off-by: Yubo Feng <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: OGAWA Hirofumi <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12fs/ufs: avoid potential u32 multiplication overflowColin Ian King1-1/+1
The 64 bit ino is being compared to the product of two u32 values, however, the multiplication is being performed using a 32 bit multiply so there is a potential of an overflow. To be fully safe, cast uspi->s_ncg to a u64 to ensure a 64 bit multiplication occurs to avoid any chance of overflow. Fixes: f3e2a520f5fb ("ufs: NFS support") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Evgeniy Dushistov <[email protected]> Cc: Alexey Dobriyan <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Addresses-Coverity: ("Unintentional integer overflow") Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12nilfs2: use a more common logging styleJoe Perches20-251/+239
Add macros for nilfs_<level>(sb, fmt, ...) and convert the uses of 'nilfs_msg(sb, KERN_<LEVEL>, ...)' to 'nilfs_<level>(sb, ...)' so nilfs2 uses a logging style more like the typical kernel logging style. Miscellanea: o Realign arguments for these uses Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12nilfs2: convert __nilfs_msg to integrate the level and formatJoe Perches2-10/+15
Reduce object size a bit by removing the KERN_<LEVEL> as a separate argument and adding it to the format string. Reduce overall object size by about ~.5% (x86-64 defconfig w/ nilfs2) old: $ size -t fs/nilfs2/built-in.a | tail -1 191738 8676 44 200458 30f0a (TOTALS) new: $ size -t fs/nilfs2/built-in.a | tail -1 190971 8676 44 199691 30c0b (TOTALS) Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12nilfs2: only call unlock_new_inode() if I_NEWEric Biggers1-1/+2
Patch series "nilfs2 updates". This patch (of 3): unlock_new_inode() is only meant to be called after a new inode has already been inserted into the hash table. But nilfs_new_inode() can call it even before it has inserted the inode, triggering the WARNING in unlock_new_inode(). Fix this by only calling unlock_new_inode() if the inode has the I_NEW flag set, indicating that it's in the table. Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12fs/minix: remove expected error message in block_to_path()Eric Biggers2-12/+12
When truncating a file to a size within the last allowed logical block, block_to_path() is called with the *next* block. This exceeds the limit, causing the "block %ld too big" error message to be printed. This case isn't actually an error; there are just no more blocks past that point. So, remove this error message. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Qiujun Huang <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12fs/minix: fix block limit check for V1 filesystemsEric Biggers1-1/+1
The minix filesystem reads its maximum file size from its on-disk superblock. This value isn't necessarily a multiple of the block size. When it's not, the V1 block mapping code doesn't allow mapping the last possible block. Commit 6ed6a722f9ab ("minixfs: fix block limit check") fixed this in the V2 mapping code. Fix it in the V1 mapping code too. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Qiujun Huang <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12fs/minix: set s_maxbytes correctlyEric Biggers4-9/+9
The minix filesystem leaves super_block::s_maxbytes at MAX_NON_LFS rather than setting it to the actual filesystem-specific limit. This is broken because it means userspace doesn't see the standard behavior like getting EFBIG and SIGXFSZ when exceeding the maximum file size. Fix this by setting s_maxbytes correctly. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Qiujun Huang <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12fs/minix: reject too-large maximum file sizeEric Biggers1-2/+20
If the minix filesystem tries to map a very large logical block number to its on-disk location, block_to_path() can return offsets that are too large, causing out-of-bounds memory accesses when accessing indirect index blocks. This should be prevented by the check against the maximum file size, but this doesn't work because the maximum file size is read directly from the on-disk superblock and isn't validated itself. Fix this by validating the maximum file size at mount time. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: [email protected] Reported-by: [email protected] Reported-by: [email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Qiujun Huang <[email protected]> Cc: <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12fs/minix: don't allow getting deleted inodesEric Biggers1-0/+14
If an inode has no links, we need to mark it bad rather than allowing it to be accessed. This avoids WARNINGs in inc_nlink() and drop_nlink() when doing directory operations on a fuzzed filesystem. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: [email protected] Reported-by: [email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Qiujun Huang <[email protected]> Cc: <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12fs/minix: check return value of sb_getblk()Eric Biggers1-1/+7
Patch series "fs/minix: fix syzbot bugs and set s_maxbytes". This series fixes all syzbot bugs in the minix filesystem: KASAN: null-ptr-deref Write in get_block KASAN: use-after-free Write in get_block KASAN: use-after-free Read in get_block WARNING in inc_nlink KMSAN: uninit-value in get_block WARNING in drop_nlink It also fixes the minix filesystem to set s_maxbytes correctly, so that userspace sees the correct behavior when exceeding the max file size. This patch (of 6): sb_getblk() can fail, so check its return value. This fixes a NULL pointer dereference. Originally from Qiujun Huang. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: [email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Qiujun Huang <[email protected]> Cc: Alexander Viro <[email protected]> Cc: <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12autofs: fix doubled wordRandy Dunlap1-1/+1
Change doubled word "is" to "it is". Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Ian Kent <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12checkpatch: remove missing switch/case break testJoe Perches1-25/+0
This test doesn't work well and newer compilers are much better at emitting this warning. Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Cambda Zhu <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12checkpatch: add test for repeated wordsJoe Perches1-0/+38
Try to avoid adding repeated words either on the same line or consecutive comment lines in a block e.g.: duplicated word in comment block /* * this is a comment block where the last word of the previous * previous line is also the first word of the next line */ and simple duplication /* test this this again */ Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Inspired-by: Randy Dunlap <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12checkpatch: fix CONST_STRUCT when const_structs.checkpatch is missingQuentin Monnet1-9/+12
Checkpatch reports warnings when some specific structs are not declared as const in the code. The list of structs to consider was initially defined in the checkpatch.pl script itself, but it was later moved to an external file (scripts/const_structs.checkpatch), in commit bf1fa1dae68e ("checkpatch: externalize the structs that should be const"). This introduced two minor issues: - When file scripts/const_structs.checkpatch is not present (for example, if checkpatch is run outside of the kernel directory with the "--no-tree" option), a warning is printed to stderr to tell the user that "No structs that should be const will be found". This is fair, but the warning is printed unconditionally, even if the option "--ignore CONST_STRUCT" is passed. In the latter case, we explicitly ask checkpatch to skip this check, so no warning should be printed. - When scripts/const_structs.checkpatch is missing, or even when trying to silence the warning by adding an empty file, $const_structs is set to "", and the regex used for finding structs that should be const, "$line =~ /struct\s+($const_structs)(?!\s*\{)/)", matches all structs found in the code, thus reporting a number of false positives. Let's fix the first item by skipping scripts/const_structs.checkpatch processing if "CONST_STRUCT" checks are ignored, and the second one by skipping the test if $const_structs is not defined. Since we modify the read_words() function a little bit, update the checks for $typedefsfile/$typeOtherTypedefs as well. Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Joe Perches <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12checkpatch: add --fix option for ASSIGN_IN_IFJoe Perches1-2/+24
Add a --fix option for 2 types of single-line assignment in if statements if ((foo = bar(...)) < BAZ) { expands to: foo = bar(..); if (foo < BAZ) { and if ((foo = bar(...)) { expands to: foo = bar(...); if (foo) { if statements with assignments spanning multiple lines are not converted with the --fix option. if statements with additional logic are also not converted. e.g.: if ((foo = bar(...)) & BAZ == BAZ) { Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Julia Lawall <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12checkpatch: add test for possible misuse of IS_ENABLED() without CONFIG_Joe Perches1-0/+6
IS_ENABLED is almost always used with CONFIG_<FOO> defines. Add a test to verify that the #define being tested starts with CONFIG_. Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12lib/test_bits.c: add tests of GENMASKRikard Falkeborn3-0/+87
Add tests of GENMASK and GENMASK_ULL. A few test cases that should fail compilation are provided under #ifdef TEST_GENMASK_FAILURES [[email protected]: add MODULE_LICENSE()] Link: http://lkml.kernel.org/r/[email protected] [[email protected]: make some functions static] Link: http://lkml.kernel.org/r/[email protected] Suggested-by: Andy Shevchenko <[email protected]> Signed-off-by: Rikard Falkeborn <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: William Breathitt Gray <[email protected]> Cc: Emil Velikov <[email protected]> Cc: Syed Nayyar Waris <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Walleij <[email protected]> Cc: Masahiro Yamada <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12kstrto*: do not describe simple_strto*() as obsolete/replacedKars Mulder2-10/+6
The documentation of the kstrto*() functions describes kstrto*() as "replacements" of the "obsolete" simple_strto*() functions. Both of these terms are inaccurate: they're not replacements because they have different behaviour, and the simple_strto*() are not obsolete because there are cases where they have benefits over kstrto*(). Remove usage of the terms "replacement" and "obsolete" in reference to simple_strto*(), and instead use the term "preferred over". Fixes: 4c925d6031f71 ("kstrto*: add documentation") Fixes: 885e68e8b7b13 ("kernel.h: update comment about simple_strto<foo>() functions") Signed-off-by: Kars Mulder <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Eldad Zack <[email protected]> Cc: Miguel Ojeda <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Mans Rullgard <[email protected]> Cc: Petr Mladek <[email protected]> Link: http://lkml.kernel.org/r/29b9-5f234c80-13-4e3aa200@244003027 Signed-off-by: Linus Torvalds <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.