aboutsummaryrefslogtreecommitdiffstats
path: root/usr (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2020-04-11arch: nios2: Enable the common clk subsystem on Nios2Dragos Bogdan2-0/+9
This patch adds support for common clock framework on Nios2. Clock framework is commonly used in many drivers, and this patch makes it available for the entire architecture, not just on a per-driver basis. Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com> Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
2020-04-10Documentation: android: binderfs: add 'stats' mount optionRandy Dunlap1-0/+6
Add documentation of the binderfs 'stats' mount option. Description taken from the commit message. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Link: https://lore.kernel.org/r/baa0aa81-007d-af46-16a5-91fead0bd1b9@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-04-10block: fix busy device checking in blk_drop_partitions againChristoph Hellwig1-1/+1
The previous fix had an off by one in the bd_openers checking, counting the callers blkdev_get. Fixes: d3ef5536274f ("block: fix busy device checking in blk_drop_partitions") Reported-by: Qian Cai <cai@lca.pw> Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Qian Cai <cai@lca.pw> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-04-09io_uring: punt final io_ring_ctx wait-and-free to workqueueJens Axboe1-2/+16
We can't reliably wait in io_ring_ctx_wait_and_kill(), since the task_works list isn't ordered (in fact it's LIFO ordered). We could either fix this with a separate task_works list for io_uring work, or just punt the wait-and-free to async context. This ensures that task_work that comes in while we're shutting down is processed correctly. If we don't go async, we could have work past the fput() work for the ring that depends on work that won't be executed until after we're done with the wait-and-free. But as this operation is blocking, it'll never get a chance to run. This was reproduced with hundreds of thousands of sockets running memcached, haven't been able to reproduce this synthetically. Reported-by: Dan Melnic <dmm@fb.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-04-10drm/ttm: Temporarily disable the huge_fault() callbackThomas Hellstrom (VMware)1-63/+0
With amdgpu and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, there are errors like: BUG: non-zero pgtables_bytes on freeing mm and: BUG: Bad rss-counter state with TTM transparent huge-pages. Until we've figured out what other TTM drivers do differently compared to vmwgfx, disable the huge_fault() callback, eliminating transhuge page-table entries. Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Thomas Hellstrom (VMware) <thomas_os@shipmail.org> Reported-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200409164925.11912-1-thomas_os@shipmail.org
2020-04-09smb3: change noisy error message to FYISteve French1-1/+1
The noisy posix error message in readdir was supposed to be an FYI (not enabled by default) CIFS VFS: XXX dev 66306, reparse 0, mode 755 Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Aurelien Aptel <aaptel@suse.com>
2020-04-09proc: Use a dedicated lock in struct pidEric W. Biederman3-5/+7
syzbot wrote: > ======================================================== > WARNING: possible irq lock inversion dependency detected > 5.6.0-syzkaller #0 Not tainted > -------------------------------------------------------- > swapper/1/0 just changed the state of lock: > ffffffff898090d8 (tasklist_lock){.+.?}-{2:2}, at: send_sigurg+0x9f/0x320 fs/fcntl.c:840 > but this lock took another, SOFTIRQ-unsafe lock in the past: > (&pid->wait_pidfd){+.+.}-{2:2} > > > and interrupts could create inverse lock ordering between them. > > > other info that might help us debug this: > Possible interrupt unsafe locking scenario: > > CPU0 CPU1 > ---- ---- > lock(&pid->wait_pidfd); > local_irq_disable(); > lock(tasklist_lock); > lock(&pid->wait_pidfd); > <Interrupt> > lock(tasklist_lock); > > *** DEADLOCK *** > > 4 locks held by swapper/1/0: The problem is that because wait_pidfd.lock is taken under the tasklist lock. It must always be taken with irqs disabled as tasklist_lock can be taken from interrupt context and if wait_pidfd.lock was already taken this would create a lock order inversion. Oleg suggested just disabling irqs where I have added extra calls to wait_pidfd.lock. That should be safe and I think the code will eventually do that. It was rightly pointed out by Christian that sharing the wait_pidfd.lock was a premature optimization. It is also true that my pre-merge window testing was insufficient. So remove the premature optimization and give struct pid a dedicated lock of it's own for struct pid things. I have verified that lockdep sees all 3 paths where we take the new pid->lock and lockdep does not complain. It is my current day dream that one day pid->lock can be used to guard the task lists as well and then the tasklist_lock won't need to be held to deliver signals. That will require taking pid->lock with irqs disabled. Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Link: https://lore.kernel.org/lkml/00000000000011d66805a25cd73f@google.com/ Cc: Oleg Nesterov <oleg@redhat.com> Cc: Christian Brauner <christian.brauner@ubuntu.com> Reported-by: syzbot+343f75cdeea091340956@syzkaller.appspotmail.com Reported-by: syzbot+832aabf700bc3ec920b9@syzkaller.appspotmail.com Reported-by: syzbot+f675f964019f884dbd0f@syzkaller.appspotmail.com Reported-by: syzbot+a9fb1457d720a55d6dc5@syzkaller.appspotmail.com Fixes: 7bc3e6e55acf ("proc: Use a list of inodes to flush from proc") Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2020-04-09io_uring: fix fs cleanup on cqe overflowPavel Begunkov1-1/+1
If completion queue overflow occurs, __io_cqring_fill_event() will update req->cflags, which is in a union with req->work and happens to be aliased to req->work.fs. Following io_free_req() -> io_req_work_drop_env() may get a bunch of different problems (miscount fs->users, segfault, etc) on cleaning @fs. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-04-09ahci: Add Intel Comet Lake PCH RAID PCI IDJian-Hong Pan1-0/+1
Intel Comet Lake should use the default LPM policy for mobile chipsets. So, add the PCI ID to the driver list of supported devices. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-04-09x86/xen: fix booting 32-bit pv guestJuergen Gross1-1/+1
Commit 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable") introduced a regression for booting 32 bit Xen PV guests: the address of the initial stack needs to be a virtual one. Fixes: 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable") Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20200409070001.16675-1-jgross@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2020-04-09drm/bridge: analogix_dp: Split bind() into probe() and real bind()Marek Szyprowski4-42/+61
Analogix_dp driver acquires all its resources in the ->bind() callback, what is a bit against the component driver based approach, where the driver initialization is split into a probe(), where all resources are gathered, and a bind(), where all objects are created and a compound driver is initialized. Extract all the resource related operations to analogix_dp_probe() and analogix_dp_remove(), then call them before/after registration of the device components from the main Exynos DP and Rockchip DP drivers. Also move the plat_data initialization to the probe() to make it available for the analogix_dp_probe() function. This fixes the multiple calls to the bind() of the DRM compound driver when the DP PHY driver is not yet loaded/probed: [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 14400000.fimd (ops fimd_component_ops [exynosdrm]) exynos-drm exynos-drm: bound 14450000.mixer (ops mixer_component_ops [exynosdrm]) exynos-dp 145b0000.dp-controller: no DP phy configured exynos-drm exynos-drm: failed to bind 145b0000.dp-controller (ops exynos_dp_ops [exynosdrm]): -517 exynos-drm exynos-drm: master bind failed: -517 ... [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 14400000.fimd (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 14450000.mixer (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 145b0000.dp-controller (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 14530000.hdmi (ops hdmi_enable [exynosdrm]) [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Console: switching to colour frame buffer device 170x48 exynos-drm exynos-drm: fb0: exynosdrmfb frame buffer device [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1 ... Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310103427.26048-1-m.szyprowski@samsung.com (cherry picked from commit 83a196773b8bc6702f49df1eddc848180e350340) Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2020-04-09drm/legacy: Fix type for drm_local_map.offsetChris Wilson1-1/+1
drm_local_map.offset is not only used for resource_size_t but also dma_addr_t which may be of different sizes. Reported-by: Nathan Chancellor <natechancellor@gmail.com> Fixes: 8e4ff9b56957 ("drm: Remove the dma_alloc_coherent wrapper for internal usage") Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@gmail.com> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200402215926.30714-1-chris@chris-wilson.co.uk
2020-04-08drm/amdgpu/display: fix warning when compiling without debugfsAlex Deucher1-1/+1
fixes unused variable warning. Reported-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Mikita Lipski <mikita.lipski@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-08drm/amdgpu: unify fw_write_wait for new gfx9 asicsAaron Liu1-0/+2
Make the fw_write_wait default case true since presumably all new gfx9 asics will have updated firmware. That is using unique WAIT_REG_MEM packet with opration=1. Signed-off-by: Aaron Liu <aaron.liu@amd.com> Tested-by: Aaron Liu <aaron.liu@amd.com> Tested-by: Yuxian Dai <Yuxian.Dai@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-04-08drm/amd/powerplay: error out on forcing clock setting not supportedEvan Quan1-1/+46
For Arcturus, forcing clock to some specific level is not supported with 54.18 and onwards SMU firmware. As according to firmware team, they adopt new gfx dpm tuned parameters which can cover all the use case in a much smooth way. Thus setting through driver interface is not needed and maybe do a disservice. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-08drm/amdgpu: fix gfx hang during suspend with video playback (v2)Prike Liang1-2/+3
The system will be hang up during S3 suspend because of SMU is pending for GC not respose the register CP_HQD_ACTIVE access request.This issue root cause of accessing the GC register under enter GFX CGGPG and can be fixed by disable GFX CGPG before perform suspend. v2: Use disable the GFX CGPG instead of RLC safe mode guard. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Tested-by: Mengbing Wang <Mengbing.Wang@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-04-08dma-debug: fix displaying of dma allocation typeGrygorii Strashko1-3/+6
The commit 2e05ea5cdc1a ("dma-mapping: implement dma_map_single_attrs using dma_map_page_attrs") removed "dma_debug_page" enum, but missed to update type2name string table. This causes incorrect displaying of dma allocation type. Fix it by removing "page" string from type2name string table and switch to use named initializers. Before (dma_alloc_coherent()): k3-ringacc 4b800000.ringacc: scather-gather idx 2208 P=d1140000 N=d114 D=d1140000 L=40 DMA_BIDIRECTIONAL dma map error check not applicable k3-ringacc 4b800000.ringacc: scather-gather idx 2216 P=d1150000 N=d115 D=d1150000 L=40 DMA_BIDIRECTIONAL dma map error check not applicable After: k3-ringacc 4b800000.ringacc: coherent idx 2208 P=d1140000 N=d114 D=d1140000 L=40 DMA_BIDIRECTIONAL dma map error check not applicable k3-ringacc 4b800000.ringacc: coherent idx 2216 P=d1150000 N=d115 D=d1150000 L=40 DMA_BIDIRECTIONAL dma map error check not applicable Fixes: 2e05ea5cdc1a ("dma-mapping: implement dma_map_single_attrs using dma_map_page_attrs") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-04-08dma-direct: fix data truncation in dma_direct_get_required_mask()Kishon Vijay Abraham I1-1/+2
The upper 32-bit physical address gets truncated inadvertently when dma_direct_get_required_mask() invokes phys_to_dma_direct(). This results in dma_addressing_limited() return incorrect value when used in platforms with LPAE enabled. Fix it here by explicitly type casting 'max_pfn' to phys_addr_t in order to prevent overflow of intermediate value while evaluating '(max_pfn - 1) << PAGE_SHIFT'. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-04-09kbuild: support LLVM=1 to switch the default tools to Clang/LLVMMasahiro Yamada4-8/+40
As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy. Provide a single switch LLVM=1 to use Clang and LLVM tools instead of GCC and Binutils. You can pass it from the command line or as an environment variable. Please note LLVM=1 does not turn on the integrated assembler. You need to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the integrated assembler, I think we can make it default. We discussed what we need, and we agreed to go with a simple boolean flag that switches both target and host tools: https://lkml.org/lkml/2020/3/28/494 https://lkml.org/lkml/2020/4/3/43 Some items discussed, but not adopted: - LLVM_DIR When multiple versions of LLVM are installed, I just thought supporting LLVM_DIR=/path/to/my/llvm/bin/ might be useful. CC = $(LLVM_DIR)clang LD = $(LLVM_DIR)ld.lld ... However, we can handle this by modifying PATH. So, we decided to not do this. - LLVM_SUFFIX Some distributions (e.g. Debian) package specific versions of LLVM with naming conventions that use the version as a suffix. CC = clang$(LLVM_SUFFIX) LD = ld.lld(LLVM_SUFFIX) ... will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc., but the suffixed versions in /usr/bin/ are symlinks to binaries in /usr/lib/llvm-#/bin/, so this can also be handled by PATH. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2020-04-09kbuild: replace AS=clang with LLVM_IAS=1Masahiro Yamada2-2/+5
The 'AS' variable is unused for building the kernel. Only the remaining usage is to turn on the integrated assembler. A boolean flag is a better fit for this purpose. AS=clang was added for experts. So, I replaced it with LLVM_IAS=1, breaking the backward compatibility. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2020-04-08arm64: armv8_deprecated: Fix undef_hook mask for thumb setendFredrik Strupe1-1/+1
For thumb instructions, call_undef_hook() in traps.c first reads a u16, and if the u16 indicates a T32 instruction (u16 >= 0xe800), a second u16 is read, which then makes up the the lower half-word of a T32 instruction. For T16 instructions, the second u16 is not read, which makes the resulting u32 opcode always have the upper half set to 0. However, having the upper half of instr_mask in the undef_hook set to 0 masks out the upper half of all thumb instructions - both T16 and T32. This results in trapped T32 instructions with the lower half-word equal to the T16 encoding of setend (b650) being matched, even though the upper half-word is not 0000 and thus indicates a T32 opcode. An example of such a T32 instruction is eaa0b650, which should raise a SIGILL since T32 instructions with an eaa prefix are unallocated as per Arm ARM, but instead works as a SETEND because the second half-word is set to b650. This patch fixes the issue by extending instr_mask to include the upper u32 half, which will still match T16 instructions where the upper half is 0, but not T32 instructions. Fixes: 2d888f48e056 ("arm64: Emulate SETEND for AArch32 tasks") Cc: <stable@vger.kernel.org> # 4.0.x- Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Fredrik Strupe <fredrik@strupe.net> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-04-08orangefs: clarify build steps for test server in orangefs.txtMike Marshall1-15/+19
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
2020-04-08mm/gup: Let __get_user_pages_locked() return -EINTR for fatal signalHillf Danton1-1/+4
__get_user_pages_locked() will return 0 instead of -EINTR after commit 4426e945df588 ("mm/gup: allow VM_FAULT_RETRY for multiple times") which added extra code to allow gup detect fatal signal faster. Restore the original -EINTR behavior. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: 4426e945df58 ("mm/gup: allow VM_FAULT_RETRY for multiple times") Reported-by: syzbot+3be1a33f04dc782e9fd5@syzkaller.appspotmail.com Signed-off-by: Hillf Danton <hdanton@sina.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-08io_uring: don't read user-shared sqe flags twicePavel Begunkov1-12/+8
Don't re-read userspace-shared sqe->flags, it can be exploited. sqe->flags are copied into req->flags in io_submit_sqe(), check them there instead. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-04-08io_uring: remove req init from io_get_req()Pavel Begunkov1-26/+27
io_get_req() do two different things: io_kiocb allocation and initialisation. Move init part out of it and rename into io_alloc_req(). It's simpler this way and also have better data locality. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-04-08io_uring: alloc req only after getting sqePavel Begunkov1-15/+9
As io_get_sqe() split into 2 stage get/consume, get an sqe before allocating io_kiocb, so no free_req*() for a failure case is needed, and inline back __io_req_do_free(), which has only 1 user. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-04-08io_uring: simplify io_get_sqringPavel Begunkov1-18/+22
Make io_get_sqring() care only about sqes themselves, not initialising the io_kiocb. Also, split it into get + consume, that will be helpful in the future. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-04-08io_uring: do not always copy iovec in io_req_map_rw()Xiaoguang Wang1-2/+3
In io_read_prep() or io_write_prep(), io_req_map_rw() takes struct io_async_rw's fast_iov as argument to call io_import_iovec(), and if io_import_iovec() uses struct io_async_rw's fast_iov as valid iovec array, later indeed io_req_map_rw() does not need to do the memcpy operation, because they are same pointers. Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-04-08io_uring: ensure openat sets O_LARGEFILE if neededJens Axboe1-0/+2
OPENAT2 correctly sets O_LARGEFILE if it has to, but that escaped the OPENAT opcode. Dmitry reports that his test case that compares openat() and IORING_OP_OPENAT sees failures on large files: *** sync openat openat succeeded sync write at offset 0 write succeeded sync write at offset 4294967296 write succeeded *** sync openat openat succeeded io_uring write at offset 0 write succeeded io_uring write at offset 4294967296 write succeeded *** io_uring openat openat succeeded sync write at offset 0 write succeeded sync write at offset 4294967296 write failed: File too large *** io_uring openat openat succeeded io_uring write at offset 0 write succeeded io_uring write at offset 4294967296 write failed: File too large Ensure we set O_LARGEFILE, if force_o_largefile() is true. Cc: stable@vger.kernel.org # v5.6 Fixes: 15b71abe7b52 ("io_uring: add support for IORING_OP_OPENAT") Reported-by: Dmitry Kadashev <dkadashev@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-04-09kbuild: add dummy toolchains to enable all cc-option etc. in KconfigMasahiro Yamada4-0/+123
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG options your compiler does not support. This works well if you configure and build the kernel on the same host machine. It is inconvenient if you prepare the .config that is carried to a different build environment (typically this happens when you package the kernel for distros) because using a different compiler potentially produces different CONFIG options than the real build environment. So, you probably want to make as many options visible as possible. In other words, you need to create a super-set of CONFIG options that cover any build environment. If some of the CONFIG options turned out to be unsupported on the build machine, they are automatically disabled by the nature of Kconfig. However, it is not feasible to get a full-featured compiler for every arch. This issue was discussed here: https://lkml.org/lkml/2019/12/9/620 Other than distros, savedefconfig is also a problem. Some arch sub-systems periodically resync defconfig files. If you use a less-capable compiler for savedefconfig, options that do not meet 'depends on $(cc-option,...)' will be forcibly disabled. So, 'make defconfig && make savedefconfig' may silently change the behavior. This commit adds a set of dummy toolchains that pretend to support any feature. Most of compiler features are tested by cc-option, which simply checks the exit code of $(CC). The dummy tools are shell scripts that always exit with 0. So, $(cc-option, ...) is evaluated as 'y'. There are more complicated checks such as: scripts/gcc-x86_{32,64}-has-stack-protector.sh scripts/gcc-plugin.sh scripts/tools-support-relr.sh scripts/dummy-tools/gcc passes all checks. From the top directory of the source tree, you can do: $ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Philipp Rudo <prudo@linux.ibm.com> Tested-by: Jeremy Cline <jcline@redhat.com>
2020-04-09kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=yMasahiro Yamada2-18/+6
Kbuild supports not only obj-y but also lib-y to list objects linked to vmlinux. The difference between them is that all the objects from obj-y are forcibly linked to vmlinux, whereas the objects from lib-y are linked as needed; if there is no user of a lib-y object, it is not linked. lib-y is intended to list utility functions that may be called from all over the place (and may be unused at all), but it is a problem for EXPORT_SYMBOL(). Even if there is no call-site in the vmlinux, we need to keep exported symbols for the use from loadable modules. Commit 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably") worked around it by linking a dummy object, lib-ksyms.o, which contains references to all the symbols exported from lib.a in that directory. It uses the linker script command, EXTERN. Unfortunately, the meaning of EXTERN of ld.lld is different from that of ld.bfd. Therefore, this does not work with LD=ld.lld (CBL issue #515). Anyway, the build rule of lib-ksyms.o is somewhat tricky. So, I want to get rid of it. At first, I was thinking of accumulating lib-y objects into obj-y (or even replacing lib-y with obj-y entirely), but the lib-y syntax is used beyond the ordinary use in lib/ and arch/*/lib/. Examples: - drivers/firmware/efi/libstub/Makefile builds lib.a, which is linked into vmlinux in the own way (arm64), or linked to the decompressor (arm, x86). - arch/alpha/lib/Makefile builds lib.a which is linked not only to vmlinux, but also to bootloaders in arch/alpha/boot/Makefile. - arch/xtensa/boot/lib/Makefile builds lib.a for use from arch/xtensa/boot/boot-redboot/Makefile. One more thing, adding everything to obj-y would increase the vmlinux size of allnoconfig (or tinyconfig). For less impact, I tweaked the destination of lib.a at the top Makefile; when CONFIG_MODULES=y, lib.a goes to KBUILD_VMLINUX_OBJS, which is forcibly linked to vmlinux, otherwise lib.a goes to KBUILD_VMLINUX_LIBS as before. The size impact for normal usecases is quite small since at lease one symbol in every lib-y object is eventually called by someone. In case you are intrested, here are the figures. x86_64_defconfig: text data bss dec hex filename 19566602 5422072 1589328 26578002 1958c52 vmlinux.before 19566932 5422104 1589328 26578364 1958dbc vmlinux.after The case with the biggest impact is allnoconfig + CONFIG_MODULES=y. ARCH=x86 allnoconfig + CONFIG_MODULES=y: text data bss dec hex filename 1175162 254740 1220608 2650510 28718e vmlinux.before 1177974 254836 1220608 2653418 287cea vmlinux.after Hopefully this is still not a big deal. The per-file trimming with the static library is not so effective after all. If fine-grained optimization is desired, some architectures support CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which trims dead code per-symbol basis. When LTO is supported in mainline, even better optimization will be possible. Link: https://github.com/ClangBuiltLinux/linux/issues/515 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reported-by: kbuild test robot <lkp@intel.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2020-04-09MIPS: fw: arc: add __weak to prom_meminit and prom_free_prom_memoryMasahiro Yamada1-2/+2
As far as I understood, prom_meminit() in arch/mips/fw/arc/memory.c is overridden by the one in arch/mips/sgi-ip32/ip32-memory.c if CONFIG_SGI_IP32 is enabled. The use of EXPORT_SYMBOL in static libraries potentially causes a problem for the llvm linker [1]. So, I want to forcibly link lib-y objects to vmlinux when CONFIG_MODULES=y. As a groundwork, we must fix multiple definitions that have previously been hidden by lib-y. The prom_cleanup() in this file is already marked as __weak (because it is overridden by the one in arch/mips/sgi-ip22/ip22-mc.c). I think it should be OK to do the same for these two. [1]: https://github.com/ClangBuiltLinux/linux/issues/515 Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-By: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-04-09kbuild: remove -I$(srctree)/tools/include from scripts/MakefileMasahiro Yamada1-4/+0
I do not like to add an extra include path for every tool with no good reason. This should be specified per file. This line was added by commit 6520fe5564ac ("x86, realmode: 16-bit real-mode code support for relocs tool"), which did not touch anything else in scripts/. I see no reason to add this. Also, remove the comment about kallsyms because we do not have any for the rest of programs. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09kbuild: do not pass $(KBUILD_CFLAGS) to scripts/mkcompile_hMasahiro Yamada1-1/+1
scripts/mkcompile_h uses $(CC) only for getting the version string. I suspected there was a specific reason why the additional flags were needed, and dug the commit history. This code dates back to at least 2002 [1], but I could not get any more clue. Just get rid of it. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=29f3df7eba8ddf91a55183f9967f76fbcc3ab742 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org>
2020-04-09Documentation/llvm: fix the name of llvm-sizeFangrui Song1-1/+1
The tool is called llvm-size, not llvm-objsize. Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/ Clang/LLVM") Signed-off-by: Fangrui Song <maskray@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09kbuild: mkcompile_h: Include $LD version in /proc/versionKees Cook2-2/+6
When doing Clang builds of the kernel, it is possible to link with either ld.bfd (binutils) or ld.lld (LLVM), but it is not possible to discover this from a running kernel. Add the "$LD -v" output to /proc/version. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Fangrui Song <maskray@google.com> Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09kconfig: qconf: Fix a few alignment issuesMauro Carvalho Chehab1-6/+7
There are a few items with wrong alignments. Solve them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09kconfig: qconf: remove some old bogus TODOsMauro Carvalho Chehab1-2/+1
The items described on those TODOs are already solved. So, remove the comments. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09kconfig: qconf: fix support for the split view modeMauro Carvalho Chehab2-7/+28
At least on my tests (building against Qt5.13), it seems to me that, since Kernel 3.14, the split view mode is broken. Maybe it was not a top priority during the conversion time. Anyway, this patch changes the logic in order to properly support the split view mode and the single view mode. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09kconfig: qconf: fix the content of the main widgetMauro Carvalho Chehab1-6/+17
The port to Qt5 tried to preserve the same way as it used to work with Qt3 and Qt4. However, at least with newer versions of Qt5 (5.13), this doesn't work properly. Change the schema by adding a vertical layout, in order for it to start working properly again. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09kconfig: qconf: Change title for the item windowMauro Carvalho Chehab1-1/+9
Both main config window and the item window have "Option" name. That sounds weird, and makes harder to debug issues of a window appearing at the wrong place. So, change the title to reflect the contents of each window. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09kconfig: qconf: clean deprecated warningsMauro Carvalho Chehab1-4/+4
The recommended way to initialize a null string is with QString(). This is there at least since Qt5.5, with is when qconf was ported to Qt5. Fix those warnings: scripts/kconfig/qconf.cc: In member function ‘void ConfigItem::updateMenu()’: scripts/kconfig/qconf.cc:158:31: warning: ‘QString::null’ is deprecated: use QString() [-Wdeprecated-declarations] 158 | setText(noColIdx, QString::null); | ^~~~ In file included from /usr/include/qt5/QtCore/qobject.h:47, from /usr/include/qt5/QtWidgets/qwidget.h:45, from /usr/include/qt5/QtWidgets/qmainwindow.h:44, from /usr/include/qt5/QtWidgets/QMainWindow:1, from scripts/kconfig/qconf.cc:9: Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09gcc-plugins: drop support for GCC <= 4.7Masahiro Yamada7-103/+14
Nobody was opposed to raising minimum GCC version to 4.8 [1] So, we will drop GCC <= 4.7 support sooner or later. We always use C++ compiler for building plugins for GCC >= 4.8. This commit drops the plugin support for GCC <= 4.7 a bit earlier, which allows us to dump lots of code. [1] https://lkml.org/lkml/2020/1/23/545 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Kees Cook <keescook@chromium.org>
2020-04-09kbuild: Enable -Wtautological-compareNathan Chancellor2-2/+1
Currently, we disable -Wtautological-compare, which in turn disables a bunch of more specific tautological comparison warnings that are useful for the kernel such as -Wtautological-bitwise-compare. See clang's documentation below for the other warnings that are suppressed by -Wtautological-compare. Now that all of the major/noisy warnings have been fixed, enable -Wtautological-compare so that more issues can be caught at build time by various continuous integration setups. -Wtautological-constant-out-of-range-compare is kept disabled under a normal build but visible at W=1 because there are places in the kernel where a constant or variable size can change based on the kernel configuration. These are not fixed in a clean/concise way and the ones I have audited so far appear to be harmless. It is not a subgroup but rather just one warning so we do not lose out on much coverage by default. Link: https://github.com/ClangBuiltLinux/linux/issues/488 Link: http://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html#wtautological-compare Link: https://bugs.llvm.org/show_bug.cgi?id=42666 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09x86: update AS_* macros to binutils >=2.23, supporting ADX and AVX2Jason A. Donenfeld21-90/+15
Now that the kernel specifies binutils 2.23 as the minimum version, we can remove ifdefs for AVX2 and ADX throughout. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-089p: document short read behaviour with O_NONBLOCKDominique Martinet1-0/+10
Regular files opened with O_NONBLOCK allow read to return after a single round-trip with the server instead of trying to fill buffer. Add a few lines in 9p documentation to describe that. Link: http://lkml.kernel.org/r/1586193572-1375-1-git-send-email-asmadeus@codewreck.org Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
2020-04-09crypto: x86 - clean up poly1305-x86_64-cryptogams.S by 'make clean'Masahiro Yamada1-2/+0
poly1305-x86_64-cryptogams.S is a generated file, so it should be cleaned up by 'make clean'. Assigning it to the variable 'targets' teaches Kbuild that it is a generated file. However, this line is not evaluated when cleaning because scripts/Makefile.clean does not include include/config/auto.conf. Remove the ifneq-conditional, so this file is correctly cleaned up. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Ingo Molnar <mingo@kernel.org>
2020-04-09Documentation/changes: Raise minimum supported binutils version to 2.23Borislav Petkov1-2/+2
The currently minimum-supported binutils version 2.21 has the problem of promoting symbols which are defined outside of a section into absolute. According to Arvind: binutils-2.21 and -2.22. An x86-64 defconfig will fail with Invalid absolute R_X86_64_32S relocation: _etext and after fixing that one, with Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve Those two versions of binutils have a bug when it comes to handling symbols defined outside of a section and binutils 2.23 has the proper fix, see: https://sourceware.org/legacy-ml/binutils/2012-06/msg00155.html Therefore, up to the fixed version directly, skipping the broken ones. Currently shipping distros already have the fixed binutils version so there should be no breakage resulting from this. For more details about the whole thing, see the thread in Link. Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200110202349.1881840-1-nivedita@alum.mit.edu Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09crypto: curve25519 - do not pollute dispatcher based on assemblerJason A. Donenfeld1-4/+2
Since we're doing a static inline dispatch here, we normally branch based on whether or not there's an arch implementation. That would have been fine in general, except the crypto Makefile prior used to turn things off -- despite the Kconfig -- resulting in us needing to also hard code various assembler things into the dispatcher too. The horror! Now that the assembler config options are done by Kconfig, we can get rid of the inconsistency. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-04-09crypto: x86 - rework configuration based on KconfigJason A. Donenfeld2-91/+69
Now that assembler capabilities are probed inside of Kconfig, we can set up proper Kconfig-based dependencies. We also take this opportunity to reorder the Makefile, so that items are grouped logically by primitive. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>