aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-05-28btrfs: correct zstd workspace manager lock to use spin_lock_bh()Dennis Zhou1-10/+10
The btrfs zstd workspace manager uses a background timer to reclaim not recently used workspaces. I used spin_lock() from this context which should have been caught with lockdep, but was not. This deadlock was reported in bugzilla. The fix is to switch the zstd wsm lock to use spin_lock_bh() from the softirq context. This happened quite relibably on ppc64, unlike on other architectures. [ 313.402874] ================================ [ 313.402875] WARNING: inconsistent lock state [ 313.402879] 5.1.0-rc7 #1 Not tainted [ 313.402880] -------------------------------- [ 313.402882] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 313.402885] swapper/5/0 [HC0[0]:SC1[1]:HE1:SE0] takes: [ 313.402888] 0000000080d1120c (&(&wsm.lock)->rlock){+.?.}, at: .zstd_reclaim_timer_fn+0x40/0x230 [ 313.402895] {SOFTIRQ-ON-W} state was registered at: [ 313.402899] .lock_acquire+0xd0/0x240 [ 313.402903] ._raw_spin_lock+0x34/0x60 [ 313.402906] .zstd_get_workspace+0xd0/0x360 [ 313.402908] .end_compressed_bio_read+0x3b8/0x540 [ 313.402911] .bio_endio+0x174/0x2c0 [ 313.402914] .end_workqueue_fn+0x4c/0x70 [ 313.402917] .normal_work_helper+0x138/0x7e0 [ 313.402920] .process_one_work+0x324/0x790 [ 313.402922] .worker_thread+0x68/0x570 [ 313.402925] .kthread+0x19c/0x1b0 [ 313.402928] .ret_from_kernel_thread+0x58/0x78 [ 313.402930] irq event stamp: 2629216 [ 313.402933] hardirqs last enabled at (2629216): [<c0000000009da738>] ._raw_spin_unlock_irq+0x38/0x60 [ 313.402936] hardirqs last disabled at (2629215): [<c0000000009da4c4>] ._raw_spin_lock_irq+0x24/0x70 [ 313.402939] softirqs last enabled at (2629212): [<c0000000000af9fc>] .irq_enter+0x8c/0xd0 [ 313.402942] softirqs last disabled at (2629213): [<c0000000000afb58>] .irq_exit+0x118/0x170 [ 313.402944] other info that might help us debug this: [ 313.402945] Possible unsafe locking scenario: [ 313.402947] CPU0 [ 313.402948] ---- [ 313.402949] lock(&(&wsm.lock)->rlock); [ 313.402951] <Interrupt> [ 313.402952] lock(&(&wsm.lock)->rlock); [ 313.402954] *** DEADLOCK *** [ 313.402957] 1 lock held by swapper/5/0: [ 313.402958] #0: 000000004b612042 ((&wsm.timer)){+.-.}, at: .call_timer_fn+0x0/0x3c0 [ 313.402963] stack backtrace: [ 313.402967] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.1.0-rc7 #1 [ 313.402968] Call Trace: [ 313.402972] [c0000007fa262e70] [c0000000009b3294] .dump_stack+0xe0/0x15c (unreliable) [ 313.402975] [c0000007fa262f10] [c000000000125548] .print_usage_bug+0x348/0x390 [ 313.402978] [c0000007fa262fd0] [c000000000125cb4] .mark_lock+0x724/0x930 [ 313.402981] [c0000007fa263080] [c000000000126c20] .__lock_acquire+0xc90/0x16a0 [ 313.402984] [c0000007fa2631b0] [c000000000128040] .lock_acquire+0xd0/0x240 [ 313.402987] [c0000007fa263280] [c0000000009da2b4] ._raw_spin_lock+0x34/0x60 [ 313.402990] [c0000007fa263300] [c00000000054b0b0] .zstd_reclaim_timer_fn+0x40/0x230 [ 313.402993] [c0000007fa2633d0] [c000000000158b38] .call_timer_fn+0xc8/0x3c0 [ 313.402996] [c0000007fa2634a0] [c000000000158f74] .expire_timers+0x144/0x260 [ 313.402999] [c0000007fa263550] [c000000000159178] .run_timer_softirq+0xe8/0x230 [ 313.403002] [c0000007fa263680] [c0000000009db288] .__do_softirq+0x188/0x5d4 [ 313.403004] [c0000007fa263790] [c0000000000afb58] .irq_exit+0x118/0x170 [ 313.403008] [c0000007fa263800] [c000000000028d88] .timer_interrupt+0x158/0x430 [ 313.403012] [c0000007fa2638b0] [c0000000000091d4] decrementer_common+0x134/0x140 [ 313.403017] --- interrupt: 901 at replay_interrupt_return+0x0/0x4 LR = .arch_local_irq_restore.part.0+0x68/0x80 [ 313.403020] [c0000007fa263bb0] [c00000000001a3ac] .arch_local_irq_restore.part.0+0x2c/0x80 (unreliable) [ 313.403024] [c0000007fa263c30] [c0000000007bbbcc] .cpuidle_enter_state+0xec/0x670 [ 313.403027] [c0000007fa263d00] [c0000000000f5130] .call_cpuidle+0x40/0x90 [ 313.403031] [c0000007fa263d70] [c0000000000f554c] .do_idle+0x2dc/0x3a0 [ 313.403034] [c0000007fa263e30] [c0000000000f59ac] .cpu_startup_entry+0x2c/0x30 [ 313.403037] [c0000007fa263ea0] [c000000000045674] .start_secondary+0x644/0x650 [ 313.403041] [c0000007fa263f90] [c00000000000ad5c] start_secondary_prolog+0x10/0x14 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203517 Fixes: 3f93aef535c8 ("btrfs: add zstd compression level support") CC: [email protected] # 5.1+ Signed-off-by: Dennis Zhou <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2019-05-28btrfs: Ensure replaced device doesn't have pending chunk allocationNikolay Borisov1-10/+25
Recent FITRIM work, namely bbbf7243d62d ("btrfs: combine device update operations during transaction commit") combined the way certain operations are recoded in a transaction. As a result an ASSERT was added in dev_replace_finish to ensure the new code works correctly. Unfortunately I got reports that it's possible to trigger the assert, meaning that during a device replace it's possible to have an unfinished chunk allocation on the source device. This is supposed to be prevented by the fact that a transaction is committed before finishing the replace oepration and alter acquiring the chunk mutex. This is not sufficient since by the time the transaction is committed and the chunk mutex acquired it's possible to allocate a chunk depending on the workload being executed on the replaced device. This bug has been present ever since device replace was introduced but there was never code which checks for it. The correct way to fix is to ensure that there is no pending device modification operation when the chunk mutex is acquire and if there is repeat transaction commit. Unfortunately it's not possible to just exclude the source device from btrfs_fs_devices::dev_alloc_list since this causes ENOSPC to be hit in transaction commit. Fixing that in another way would need to add special cases to handle the last writes and forbid new ones. The looped transaction fix is more obvious, and can be easily backported. The runtime of dev-replace is long so there's no noticeable delay caused by that. Reported-by: David Sterba <[email protected]> Fixes: 391cd9df81ac ("Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace") CC: [email protected] # 4.4+ Signed-off-by: Nikolay Borisov <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2019-05-28Merge tag 'pinctrl-v5.2-2' of ↵Linus Torvalds2-36/+11
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "The commits that stand out are the Intel fixes that arrived during the merge window and I got relayed by pull request from Andy. Apart from that a minor Kconfig noise. - Interrupt clearing fix for the Intel pin controllers affecting touchpads on some laptops. - Compile Kconfig fix for the STMFX expander pin controller" * tag 'pinctrl-v5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: stmfx: Fix compile issue when CONFIG_OF_GPIO is not defined pinctrl: intel: Clear interrupt status in mask/unmask callback pinctrl: intel: Use GENMASK() consistently
2019-05-28Merge tag 'gpio-v5.2-2' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fix from Linus Walleij: "Fix a build error in gpio-adp5588" * tag 'gpio-v5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: fix gpio-adp5588 build errors
2019-05-28ia64: fix build errors by exporting paddr_to_nid()Randy Dunlap1-0/+1
Fix build errors on ia64 when DISCONTIGMEM=y and NUMA=y by exporting paddr_to_nid(). Fixes these build errors: ERROR: "paddr_to_nid" [sound/core/snd-pcm.ko] undefined! ERROR: "paddr_to_nid" [net/sunrpc/sunrpc.ko] undefined! ERROR: "paddr_to_nid" [fs/cifs/cifs.ko] undefined! ERROR: "paddr_to_nid" [drivers/video/fbdev/core/fb.ko] undefined! ERROR: "paddr_to_nid" [drivers/usb/mon/usbmon.ko] undefined! ERROR: "paddr_to_nid" [drivers/usb/core/usbcore.ko] undefined! ERROR: "paddr_to_nid" [drivers/md/raid1.ko] undefined! ERROR: "paddr_to_nid" [drivers/md/dm-mod.ko] undefined! ERROR: "paddr_to_nid" [drivers/md/dm-crypt.ko] undefined! ERROR: "paddr_to_nid" [drivers/md/dm-bufio.ko] undefined! ERROR: "paddr_to_nid" [drivers/ide/ide-core.ko] undefined! ERROR: "paddr_to_nid" [drivers/ide/ide-cd_mod.ko] undefined! ERROR: "paddr_to_nid" [drivers/gpu/drm/drm.ko] undefined! ERROR: "paddr_to_nid" [drivers/char/agp/agpgart.ko] undefined! ERROR: "paddr_to_nid" [drivers/block/nbd.ko] undefined! ERROR: "paddr_to_nid" [drivers/block/loop.ko] undefined! ERROR: "paddr_to_nid" [drivers/block/brd.ko] undefined! ERROR: "paddr_to_nid" [crypto/ccm.ko] undefined! Reported-by: kbuild test robot <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Cc: Tony Luck <[email protected]> Cc: Fenghua Yu <[email protected]> Cc: [email protected] Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-05-28arm64/module: revert to unsigned interpretation of ABS16/32 relocationsArd Biesheuvel1-8/+30
Commit 1cf24a2cc3fd ("arm64/module: deal with ambiguity in PRELxx relocation ranges") updated the overflow checking logic in the relocation handling code to ensure that PREL16/32 relocations don't overflow signed quantities. However, the same code path is used for absolute relocations, where the interpretation is the opposite: the only current use case for absolute relocations operating on non-native word size quantities is the CRC32 handling in the CONFIG_MODVERSIONS code, and these CRCs are unsigned 32-bit quantities, which are now being rejected by the module loader if bit 31 happens to be set. So let's use different ranges for quanties subject to absolute vs. relative relocations: - ABS16/32 relocations should be in the range [0, Uxx_MAX) - PREL16/32 relocations should be in the range [Sxx_MIN, Sxx_MAX) - otherwise, print an error since no other 16 or 32 bit wide data relocations are currently supported. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-28KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_IDThomas Huth6-2/+13
KVM_CAP_MAX_VCPU_ID is currently always reporting KVM_MAX_VCPU_ID on all architectures. However, on s390x, the amount of usable CPUs is determined during runtime - it is depending on the features of the machine the code is running on. Since we are using the vcpu_id as an index into the SCA structures that are defined by the hardware (see e.g. the sca_add_vcpu() function), it is not only the amount of CPUs that is limited by the hard- ware, but also the range of IDs that we can use. Thus KVM_CAP_MAX_VCPU_ID must be determined during runtime on s390x, too. So the handling of KVM_CAP_MAX_VCPU_ID has to be moved from the common code into the architecture specific code, and on s390x we have to return the same value here as for KVM_CAP_MAX_VCPUS. This problem has been discovered with the kvm_create_max_vcpus selftest. With this change applied, the selftest now passes on s390x, too. Reviewed-by: Andrew Jones <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Signed-off-by: Thomas Huth <[email protected]> Message-Id: <[email protected]> Cc: [email protected] Signed-off-by: Christian Borntraeger <[email protected]>
2019-05-28kvm: fix compile on s390 part 2Christian Borntraeger1-0/+2
We also need to fence the memunmap part. Fixes: e45adf665a53 ("KVM: Introduce a new guest mapping API") Fixes: d30b214d1d0a (kvm: fix compilation on s390) Cc: Michal Kubecek <[email protected]> Cc: KarimAllah Ahmed <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]>
2019-05-28tools headers UAPI: Sync kvm.h headers with the kernel sourcesArnaldo Carvalho de Melo4-3/+105
dd53f6102c30 ("Merge tag 'kvmarm-for-v5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD") 59c5c58c5b93 ("Merge tag 'kvm-ppc-next-5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc into HEAD") d7547c55cbe7 ("KVM: Introduce KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2") 6520ca64cde7 ("KVM: PPC: Book3S HV: XIVE: Add a mapping for the source ESB pages") 39e9af3de5ca ("KVM: PPC: Book3S HV: XIVE: Add a TIMA mapping") e4945b9da52b ("KVM: PPC: Book3S HV: XIVE: Add get/set accessors for the VP XIVE state") e6714bd1671d ("KVM: PPC: Book3S HV: XIVE: Add a control to dirty the XIVE EQ pages") 7b46b6169ab8 ("KVM: PPC: Book3S HV: XIVE: Add a control to sync the sources") 5ca806474859 ("KVM: PPC: Book3S HV: XIVE: Add a global reset control") 13ce3297c576 ("KVM: PPC: Book3S HV: XIVE: Add controls for the EQ configuration") e8676ce50e22 ("KVM: PPC: Book3S HV: XIVE: Add a control to configure a source") 4131f83c3d64 ("KVM: PPC: Book3S HV: XIVE: add a control to initialize a source") eacc56bb9de3 ("KVM: PPC: Book3S HV: XIVE: Introduce a new capability KVM_CAP_PPC_IRQ_XIVE") 90c73795afa2 ("KVM: PPC: Book3S HV: Add a new KVM device for the XIVE native exploitation mode") 4f45b90e1c03 ("KVM: s390: add deflate conversion facilty to cpu model") a243c16d18be ("KVM: arm64: Add capability to advertise ptrauth for guest") a22fa321d13b ("KVM: arm64: Add userspace flag to enable pointer authentication") 4bd774e57b29 ("KVM: arm64/sve: Simplify KVM_REG_ARM64_SVE_VLS array sizing") 8ae6efdde451 ("KVM: arm64/sve: Clean up UAPI register ID definitions") 173aec2d5a9f ("KVM: s390: add enhanced sort facilty to cpu model") 555f3d03e7fb ("KVM: arm64: Add a capability to advertise SVE support") 9033bba4b535 ("KVM: arm64/sve: Add pseudo-register for the guest's vector lengths") 7dd32a0d0103 ("KVM: arm/arm64: Add KVM_ARM_VCPU_FINALIZE ioctl") e1c9c98345b3 ("KVM: arm64/sve: Add SVE support to register access ioctl interface") 2b953ea34812 ("KVM: Allow 2048-bit register access via ioctl interface") None entails changes in tooling, the closest to that were some new arch specific ioctls, that are still not handled by the tools/perf/trace/beauty/ library, that needs to create per-arch tables to convert ioctl cmd->string (and back). From a quick look the arch specific kvm-stat.c files at: $ ls -1 tools/perf/arch/*/util/kvm-stat.c tools/perf/arch/powerpc/util/kvm-stat.c tools/perf/arch/s390/util/kvm-stat.c tools/perf/arch/x86/util/kvm-stat.c $ Are not affected. This silences these perf building warnings: Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from latest version at 'include/uapi/linux/kvm.h' diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h Warning: Kernel ABI header at 'tools/arch/powerpc/include/uapi/asm/kvm.h' differs from latest version at 'arch/powerpc/include/uapi/asm/kvm.h' diff -u tools/arch/powerpc/include/uapi/asm/kvm.h arch/powerpc/include/uapi/asm/kvm.h Warning: Kernel ABI header at 'tools/arch/s390/include/uapi/asm/kvm.h' differs from latest version at 'arch/s390/include/uapi/asm/kvm.h' diff -u tools/arch/s390/include/uapi/asm/kvm.h arch/s390/include/uapi/asm/kvm.h Warning: Kernel ABI header at 'tools/arch/arm64/include/uapi/asm/kvm.h' differs from latest version at 'arch/arm64/include/uapi/asm/kvm.h' diff -u tools/arch/arm64/include/uapi/asm/kvm.h arch/arm64/include/uapi/asm/kvm.h Cc: Adrian Hunter <[email protected]> Cc: Amit Daniel Kachhap <[email protected]> Cc: Brendan Gregg <[email protected]> Cc: Cédric Le Goater <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Dave Martin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Luis Cláudio Gonçalves <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Peter Xu <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28perf record: Fix s390 missing module symbol and warning for non-root usersThomas Richter1-3/+6
Command 'perf record' and 'perf report' on a system without kernel debuginfo packages uses /proc/kallsyms and /proc/modules to find addresses for kernel and module symbols. On x86 this works for root and non-root users. On s390, when invoked as non-root user, many of the following warnings are shown and module symbols are missing: proc/{kallsyms,modules} inconsistency while looking for "[sha1_s390]" module! Command 'perf record' creates a list of module start addresses by parsing the output of /proc/modules and creates a PERF_RECORD_MMAP record for the kernel and each module. The following function call sequence is executed: machine__create_kernel_maps machine__create_module modules__parse machine__create_module --> for each line in /proc/modules arch__fix_module_text_start Function arch__fix_module_text_start() is s390 specific. It opens file /sys/module/<name>/sections/.text to extract the module's .text section start address. On s390 the module loader prepends a header before the first section, whereas on x86 the module's text section address is identical the the module's load address. However module section files are root readable only. For non-root the read operation fails and machine__create_module() returns an error. Command perf record does not generate any PERF_RECORD_MMAP record for loaded modules. Later command perf report complains about missing module maps. To fix this function arch__fix_module_text_start() always returns success. For root users there is no change, for non-root users the module's load address is used as module's text start address (the prepended header then counts as part of the text section). This enable non-root users to use module symbols and avoid the warning when perf report is executed. Output before: [tmricht@m83lp54 perf]$ ./perf report -D | fgrep MMAP 0 0x168 [0x50]: PERF_RECORD_MMAP ... x [kernel.kallsyms]_text Output after: [tmricht@m83lp54 perf]$ ./perf report -D | fgrep MMAP 0 0x168 [0x50]: PERF_RECORD_MMAP ... x [kernel.kallsyms]_text 0 0x1b8 [0x98]: PERF_RECORD_MMAP ... x /lib/modules/.../autofs4.ko.xz 0 0x250 [0xa8]: PERF_RECORD_MMAP ... x /lib/modules/.../sha_common.ko.xz 0 0x2f8 [0x98]: PERF_RECORD_MMAP ... x /lib/modules/.../des_generic.ko.xz Signed-off-by: Thomas Richter <[email protected]> Reviewed-by: Hendrik Brueckner <[email protected]> Cc: Heiko Carstens <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28perf machine: Read also the end of the kernelJiri Olsa1-9/+18
We mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading _etext symbol if it's present to get precise kernel map end. Signed-off-by: Jiri Olsa <[email protected]> Acked-by: Song Liu <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stanislav Fomichev <[email protected]> Cc: Thomas Richter <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28perf test vmlinux-kallsyms: Ignore aliases to _etext when searching on kallsymsArnaldo Carvalho de Melo1-1/+8
No need to search for aliases for the symbol that marks the end of the kernel text segment, the following patch will make such symbols not to be found when searching in the kallsyms maps causing this test to fail. So as a prep patch to avoid breaking bisection, ignore such symbols. Tested-by: Jiri Olsa <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Song Liu <[email protected]> Cc: Stanislav Fomichev <[email protected]> Cc: Thomas Richter <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28perf session: Add missing swap ops for namespace eventsNamhyung Kim1-0/+21
In case it's recorded in a different arch. Signed-off-by: Namhyung Kim <[email protected]> Cc: Hari Bathini <[email protected]> <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Krister Johansen <[email protected]> Fixes: f3b3614a284d ("perf tools: Add PERF_RECORD_NAMESPACES to include namespaces related info") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28perf namespace: Protect reading thread's namespaceNamhyung Kim1-2/+13
It seems that the current code lacks holding the namespace lock in thread__namespaces(). Otherwise it can see inconsistent results. Signed-off-by: Namhyung Kim <[email protected]> Cc: Hari Bathini <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Krister Johansen <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28tools headers UAPI: Sync drm/drm.h with the kernelArnaldo Carvalho de Melo1-0/+37
To pick up the changes in these csets: 060cebb20cdb ("drm: introduce a capability flag for syncobj timeline support") 50d1ebef79ef ("drm/syncobj: add timeline signal ioctl for syncobj v5") ea569910cbab ("drm/syncobj: add transition iotcls between binary and timeline v2") 27b575a9aa2f ("drm/syncobj: add timeline payload query ioctl v6") 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8") 783195ec1cad ("drm/syncobj: disable the timeline UAPI for now v2") 48197bc564c7 ("drm: add syncobj timeline support v9") Which automagically results in the following new ioctls being recognized by the 'perf trace' ioctl cmd arg beautifier: $ tools/perf/trace/beauty/drm_ioctl.sh > /tmp/before $ cp include/uapi/drm/drm.h tools/include/uapi/drm/drm.h $ tools/perf/trace/beauty/drm_ioctl.sh > /tmp/after $ diff -u /tmp/before /tmp/after --- /tmp/before 2019-05-22 10:25:31.443151182 -0300 +++ /tmp/after 2019-05-22 10:25:46.449354819 -0300 @@ -103,6 +103,10 @@ [0xC7] = "MODE_LIST_LESSEES", [0xC8] = "MODE_GET_LEASE", [0xC9] = "MODE_REVOKE_LEASE", + [0xCA] = "SYNCOBJ_TIMELINE_WAIT", + [0xCB] = "SYNCOBJ_QUERY", + [0xCC] = "SYNCOBJ_TRANSFER", + [0xCD] = "SYNCOBJ_TIMELINE_SIGNAL", [DRM_COMMAND_BASE + 0x00] = "I915_INIT", [DRM_COMMAND_BASE + 0x01] = "I915_FLUSH", [DRM_COMMAND_BASE + 0x02] = "I915_FLIP", $ I.e. the strace like raw_tracepoint:sys_enter handler in 'perf trace' will get the cmd integer value and map it to the string. At some point it should be possible to translate from string to integer and use to filter using expressions such as: # perf trace -e ioctl/cmd==DRM_IOCTL_SYNCOBJ*/ Or some more suitable syntax to express that only these ioctls when acting on DRM fds should be shown. Acked-by: Lionel Landwerlin <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Brendan Gregg <[email protected]> Cc: Christian König <[email protected]> Cc: Chunming Zhou <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Luis Cláudio Gonçalves <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28s390/crypto: fix gcm-aes-s390 selftest failuresHarald Freudenberger1-41/+107
The current kernel uses improved crypto selftests. These tests showed that the current implementation of gcm-aes-s390 is not able to deal with chunks of output buffers which are not a multiple of 16 bytes. This patch introduces a rework of the gcm aes s390 scatter walk handling which now is able to handle any input and output scatter list chunk sizes correctly. Code has been verified by the crypto selftests, the tcrypt kernel module and additional tests ran via the af_alg interface. Cc: <[email protected]> Reported-by: Julian Wiedmann <[email protected]> Reviewed-by: Patrick Steuer <[email protected]> Signed-off-by: Harald Freudenberger <[email protected]> Signed-off-by: Heiko Carstens <[email protected]>
2019-05-28s390/zcrypt: Fix wrong dispatching for control domain CPRBsHarald Freudenberger4-9/+41
The zcrypt device driver does not handle CPRBs which address a control domain correctly. This fix introduces a workaround: The domain field of the request CPRB is checked if there is a valid domain value in there. If this is true and the value is a control only domain (a domain which is enabled in the crypto config ADM mask but disabled in the AQM mask) the CPRB is forwarded to the default usage domain. If there is no default domain, the request is rejected with an ENODEV. This fix is important for maintaining crypto adapters. For example one LPAR can use a crypto adapter domain ('Control and Usage') but another LPAR needs to be able to maintain this adapter domain ('Control'). Scenarios like this did not work properly and the patch enables this. Signed-off-by: Harald Freudenberger <[email protected]> Signed-off-by: Heiko Carstens <[email protected]>
2019-05-28s390/pci: fix assignment of bus resourcesSebastian Ott1-1/+4
Adjust bus resources depending on the usage of MIO instructions. Fixes: 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions") Signed-off-by: Sebastian Ott <[email protected]> Signed-off-by: Heiko Carstens <[email protected]>
2019-05-28s390/pci: fix struct definition for set PCI functionSebastian Ott2-13/+18
Recent firmware will store PCI MIO information also when enabling MIO instructions via set PCI function. We do not use this information but currently calling enable MIO will fail because of insufficient response block length. Fix this by putting a struct mio_info at the end of the affected response block struct. Fixes: 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions") Signed-off-by: Sebastian Ott <[email protected]> Signed-off-by: Heiko Carstens <[email protected]>
2019-05-28s390: mark __cpacf_check_opcode() and cpacf_query_func() as __always_inlineMasahiro Yamada1-2/+2
Commit e60fb8bf68d4 ("s390/cpacf: mark scpacf_query() as __always_inline") was not enough to make sure to meet the 'i' (immediate) constraint for the asm operands. With CONFIG_OPTIMIZE_INLINING enabled, Laura Abbott reported error with gcc 9.1.1: In file included from arch/s390/crypto/prng.c:29: ./arch/s390/include/asm/cpacf.h: In function 'cpacf_query_func': ./arch/s390/include/asm/cpacf.h:170:2: warning: asm operand 3 probably doesn't match constraints 170 | asm volatile( | ^~~ ./arch/s390/include/asm/cpacf.h:170:2: error: impossible constraint in 'asm' Add more __always_inline to force inlining. Fixes: 9012d011660e ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING") Reported-by: Laura Abbott <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]> Signed-off-by: Heiko Carstens <[email protected]>
2019-05-28s390: add unreachable() to dump_fault_info() to fix -Wmaybe-uninitializedMasahiro Yamada1-1/+3
When CONFIG_OPTIMIZE_INLINING is enabled for s390, I see this warning: arch/s390/mm/fault.c:127:15: warning: 'asce' may be used uninitialized in this function [-Wmaybe-uninitialized] switch (asce & _ASCE_TYPE_MASK) { arch/s390/mm/fault.c:177:16: note: 'asce' was declared here unsigned long asce; ^~~~ If get_fault_type() is not inlined, the compiler cannot deduce that all the possible paths in the 'switch' statement are covered. Of course, we could mark get_fault_type() as __always_inline to get back the original behavior, but I do not think it sensible to force inlining just for the purpose of suppressing the warning. Since this is just a matter of warning, I want to keep as much room for compiler optimization as possible. I added unreachable() to teach the compiler that the 'default' label is unreachable. I got rid of the 'inline' marker. Even without the 'inline' hint, the compiler inlines functions based on its inlining heuristic. Fixes: 9012d011660e ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]> Signed-off-by: Heiko Carstens <[email protected]>
2019-05-28tools headers UAPI: Sync drm/i915_drm.h with the kernelArnaldo Carvalho de Melo1-73/+181
To pick up the changes from: d1172ab3d443 ("drm/i915: Introduce struct class_instance for engines across the uAPI") 96fd2c6633b0 ("drm/i915: Drop new chunks of context creation ABI (for now)") ea593dbba4c8 ("drm/i915: Allow contexts to share a single timeline across all engines") b91715417244 ("drm/i915: Extend CONTEXT_CREATE to set parameters upon construction") e0695db7298e ("drm/i915: Create/destroy VM (ppGTT) for use with contexts") 9d1305ef80b9 ("drm/i915: Introduce the i915_user_extension_method") c8b502422bfe ("drm/i915: Remove last traces of exec-id (GEM_BUSY)") d90c06d57027 ("drm/i915: Fix I915_EXEC_RING_MASK") e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+") be03564bd7b6 ("drm/i915: Include reminders about leaving no holes in uAPI enums") ba4fda620a5f ("drm/i915: Optionally disable automatic recovery after a GPU reset") We still don't take into account the _IOC_SIZE() to differentiate ioctl cmds, so more work is needed to support the extension mechanism that is being used here so that we can differentiate DRM_IOCTL_I915_GEM_CONTEXT_CREATE from the newly introduced DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT cmd. This silences this perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/drm/i915_drm.h' differs from latest version at 'include/uapi/drm/i915_drm.h' diff -u tools/include/uapi/drm/i915_drm.h include/uapi/drm/i915_drm.h Cc: Adrian Hunter <[email protected]> Cc: Brendan Gregg <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Luis Cláudio Gonçalves <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Chris Wilson <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28tools headers UAPI: Sync linux/fs.h with the kernelArnaldo Carvalho de Melo1-0/+3
To pick up the changes in: c553ea4fdf27 ("fs/sync.c: sync_file_range(2) may use WB_SYNC_ALL writeback") That should be used to beautify the 'sync_file_range' syscall 'flags' arg. This silences this perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/fs.h' differs from latest version at 'include/uapi/linux/fs.h' diff -u tools/include/uapi/linux/fs.h include/uapi/linux/fs.h Cc: Adrian Hunter <[email protected]> Cc: Amir Goldstein <[email protected]> Cc: Brendan Gregg <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Luis Cláudio Gonçalves <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28tools headers UAPI: Sync linux/sched.h with the kernelArnaldo Carvalho de Melo1-0/+1
To pick up the change in: b3e583825266 ("clone: add CLONE_PIDFD") This requires changes in the 'perf trace' beautification routines for the 'clone' syscall args, which is done in a followup patch. This silences the following perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/sched.h' differs from latest version at 'include/uapi/linux/sched.h' diff -u tools/include/uapi/linux/sched.h include/uapi/linux/sched.h Cc: Adrian Hunter <[email protected]> Cc: Brendan Gregg <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Luis Cláudio Gonçalves <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28tools arch x86: Sync asm/cpufeatures.h with the with the kernelArnaldo Carvalho de Melo1-0/+3
To pick up the changes in: ed5194c2732c ("x86/speculation/mds: Add basic bug infrastructure for MDS") e261f209c366 ("x86/speculation/mds: Add BUG_MSBDS_ONLY") That don't affect anything in tools/. This silences this perf build warning: Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h' differs from latest version at 'arch/x86/include/asm/cpufeatures.h' diff -u tools/arch/x86/include/asm/cpufeatures.h arch/x86/include/asm/cpufeatures.h Cc: Adrian Hunter <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Brendan Gregg <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Luis Cláudio Gonçalves <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28tools include UAPI: Update copy of files related to new fspick, fsmount, ↵Arnaldo Carvalho de Melo4-1/+83
fsconfig, fsopen, move_mount and open_tree syscalls Copy the headers changed by these csets: d8076bdb56af ("uapi: Wire up the mount API syscalls on non-x86 arches [ver #2]") 9c8ad7a2ff0b ("uapi, x86: Fix the syscall numbering of the mount API syscalls [ver #2]") cf3cba4a429b ("vfs: syscall: Add fspick() to select a superblock for reconfiguration") 93766fbd2696 ("vfs: syscall: Add fsmount() to create a mount for a superblock") ecdab150fddb ("vfs: syscall: Add fsconfig() for configuring and managing a context") 24dcb3d90a1f ("vfs: syscall: Add fsopen() to prepare for superblock creation") 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around") a07b20004793 ("vfs: syscall: Add open_tree(2) to reference or clone a mount") We need to create tables for all the flags argument in the new syscalls, in followup patches. This silences these perf build warnings: Warning: Kernel ABI header at 'tools/include/uapi/linux/mount.h' differs from latest version at 'include/uapi/linux/mount.h' diff -u tools/include/uapi/linux/mount.h include/uapi/linux/mount.h Warning: Kernel ABI header at 'tools/perf/arch/x86/entry/syscalls/syscall_64.tbl' differs from latest version at 'arch/x86/entry/syscalls/syscall_64.tbl' diff -u tools/perf/arch/x86/entry/syscalls/syscall_64.tbl arch/x86/entry/syscalls/syscall_64.tbl Warning: Kernel ABI header at 'tools/include/uapi/asm-generic/unistd.h' differs from latest version at 'include/uapi/asm-generic/unistd.h' diff -u tools/include/uapi/asm-generic/unistd.h include/uapi/asm-generic/unistd.h Cc: Adrian Hunter <[email protected]> Cc: Al Viro <[email protected]> Cc: David Howells <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Luis Cláudio Gonçalves <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Wang Nan <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28perf arm64: Fix mksyscalltbl when system kernel headers are ahead of the kernelVitaly Chikunov1-1/+1
When a host system has kernel headers that are newer than a compiling kernel, mksyscalltbl fails with errors such as: <stdin>: In function 'main': <stdin>:271:44: error: '__NR_kexec_file_load' undeclared (first use in this function) <stdin>:271:44: note: each undeclared identifier is reported only once for each function it appears in <stdin>:272:46: error: '__NR_pidfd_send_signal' undeclared (first use in this function) <stdin>:273:43: error: '__NR_io_uring_setup' undeclared (first use in this function) <stdin>:274:43: error: '__NR_io_uring_enter' undeclared (first use in this function) <stdin>:275:46: error: '__NR_io_uring_register' undeclared (first use in this function) tools/perf/arch/arm64/entry/syscalls//mksyscalltbl: line 48: /tmp/create-table-xvUQdD: Permission denied mksyscalltbl is compiled with default host includes, but run with compiling kernel tree includes, causing some syscall numbers to being undeclared. Committer testing: Before this patch, in my cross build environment, no build problems, but these new syscalls were not in the syscalls.c generated from the unistd.h file, which is a bug, this patch fixes it: perfbuilder@6e20056ed532:/git/perf$ tail /tmp/build/perf/arch/arm64/include/generated/asm/syscalls.c [292] = "io_pgetevents", [293] = "rseq", [294] = "kexec_file_load", [424] = "pidfd_send_signal", [425] = "io_uring_setup", [426] = "io_uring_enter", [427] = "io_uring_register", [428] = "syscalls", }; perfbuilder@6e20056ed532:/git/perf$ strings /tmp/build/perf/perf | egrep '^(io_uring_|pidfd_|kexec_file)' kexec_file_load pidfd_send_signal io_uring_setup io_uring_enter io_uring_register perfbuilder@6e20056ed532:/git/perf$ $ Well, there is that last "syscalls" thing, but that looks like some other bug. Signed-off-by: Vitaly Chikunov <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Tested-by: Michael Petlan <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Hendrik Brueckner <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kim Phillips <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Ravi Bangoria <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28perf data: Fix 'strncat may truncate' build failure with recent gccShawn Landden1-1/+1
This strncat() is safe because the buffer was allocated with zalloc(), however gcc doesn't know that. Since the string always has 4 non-null bytes, just use memcpy() here. CC /home/shawn/linux/tools/perf/util/data-convert-bt.o In file included from /usr/include/string.h:494, from /home/shawn/linux/tools/lib/traceevent/event-parse.h:27, from util/data-convert-bt.c:22: In function ‘strncat’, inlined from ‘string_set_value’ at util/data-convert-bt.c:274:4: /usr/include/powerpc64le-linux-gnu/bits/string_fortified.h:136:10: error: ‘__builtin_strncat’ output may be truncated copying 4 bytes from a string of length 4 [-Werror=stringop-truncation] 136 | return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Shawn Landden <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Wang Nan <[email protected]> LPU-Reference: [email protected] Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2019-05-28arm64: Fix the arm64_personality() syscall wrapper redirectionCatalin Marinas1-1/+1
Following commit 4378a7d4be30 ("arm64: implement syscall wrappers"), the syscall function names gained the '__arm64_' prefix. Ensure that we have the correct #define for redirecting a default syscall through a wrapper. Fixes: 4378a7d4be30 ("arm64: implement syscall wrappers") Cc: <[email protected]> # 4.19.x- Acked-by: Mark Rutland <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-28ALSA: line6: Assure canceling delayed work at disconnectionTakashi Iwai3-12/+19
The current code performs the cancel of a delayed work at the late stage of disconnection procedure, which may lead to the access to the already cleared state. This patch assures to call cancel_delayed_work_sync() at the beginning of the disconnection procedure for avoiding that race. The delayed work object is now assigned in the common line6 object instead of its derivative, so that we can call cancel_delayed_work_sync(). Along with the change, the startup function is called via the new callback instead. This will make it easier to port other LINE6 drivers to use the delayed work for startup in later patches. Reported-by: [email protected] Fixes: 7f84ff68be05 ("ALSA: line6: toneport: Fix broken usage of timer for delayed execution") Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-05-28configfs: Fix use-after-free when accessing sd->s_dentrySahitya Tummala1-8/+6
In the vfs_statx() context, during path lookup, the dentry gets added to sd->s_dentry via configfs_attach_attr(). In the end, vfs_statx() kills the dentry by calling path_put(), which invokes configfs_d_iput(). Ideally, this dentry must be removed from sd->s_dentry but it doesn't if the sd->s_count >= 3. As a result, sd->s_dentry is holding reference to a stale dentry pointer whose memory is already freed up. This results in use-after-free issue, when this stale sd->s_dentry is accessed later in configfs_readdir() path. This issue can be easily reproduced, by running the LTP test case - sh fs_racer_file_list.sh /config (https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh) Fixes: 76ae281f6307 ('configfs: fix race between dentry put and lookup') Signed-off-by: Sahitya Tummala <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2019-05-28ALSA: hda - Force polling mode on CNL for fixing codec communicationBard Liao1-2/+3
We observed the same issue as reported by commit a8d7bde23e7130686b7662 ("ALSA: hda - Force polling mode on CFL for fixing codec communication") We don't have a better solution. So apply the same workaround to CNL. Signed-off-by: Bard Liao <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-05-27i2c: synquacer: fix synquacer_i2c_doxfer() return valueMasahisa Kojima1-1/+1
master_xfer should return the number of messages successfully processed. Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller") Cc: <[email protected]> # v4.19+ Signed-off-by: Okamoto Satoru <[email protected]> Signed-off-by: Masahisa Kojima <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2019-05-27i2c: mlxcpld: Fix wrong initialization order in probeVadim Pasternak1-1/+1
Fix wrong order in probing routine initialization - field `base_addr' is used before it's initialized. Move assignment of 'priv->base_addr` to the beginning, prior the call to mlxcpld_i2c_read_comm(). Wrong order caused the first read of capability register to be executed at wrong offset 0x0 instead of 0x2000. By chance it was a "good garbage" at 0x0 offset. Fixes: 313ce648b5a4 ("i2c: mlxcpld: Add support for extended transaction length for i2c-mlxcpld") Signed-off-by: Vadim Pasternak <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2019-05-27i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwrYingjoe Chen1-0/+1
If I2C_M_RECV_LEN check failed, msgs[i].buf allocated by memdup_user will not be freed. Pump index up so it will be freed. Fixes: 838bfa6049fb ("i2c-dev: Add support for I2C_M_RECV_LEN") Signed-off-by: Yingjoe Chen <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2019-05-27Merge branch 'aquantia-fixes'David S. Miller2-47/+68
Igor Russkikh says: ==================== net: aquantia: various fixes May, 2019 Here is a set of various bug fixes found on recent verification stage. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-05-27net: aquantia: tcp checksum 0xffff being handled incorrectlyNikita Danilov1-2/+1
Thats a known quirk in windows tcp stack it can produce 0xffff checksum. Thats incorrect but it is. Atlantic HW with LRO enabled handles that incorrectly and changes csum to 0xfffe - but indicates that csum is invalid. This causes driver to pass packet to linux networking stack with CSUM_NONE, stack eventually drops the packet. There is a quirk in atlantic HW to enable correct processing of 0xffff incorrect csum. Enable it. The visible bug is that windows link partner with software generated csums caused TCP connection to be unstable since all packets that csum value are dropped. Reported-by: Dmitry Bezrukov <[email protected]> Signed-off-by: Nikita Danilov <[email protected]> Signed-off-by: Igor Russkikh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-27net: aquantia: fix LRO with FCS errorDmitry Bogdanov1-29/+32
Driver stops producing skbs on ring if a packet with FCS error was coalesced into LRO session. Ring gets hang forever. Thats a logical error in driver processing descriptors: When rx_stat indicates MAC Error, next pointer and eop flags are not filled. This confuses driver so it waits for descriptor 0 to be filled by HW. Solution is fill next pointer and eop flag even for packets with FCS error. Fixes: bab6de8fd180b ("net: ethernet: aquantia: Atlantic A0 and B0 specific functions.") Signed-off-by: Igor Russkikh <[email protected]> Signed-off-by: Dmitry Bogdanov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-27net: aquantia: check rx csum for all packets in LRO sessionDmitry Bogdanov1-13/+31
Atlantic hardware does not aggregate nor breaks LRO sessions with bad csum packets. This means driver should take care of that. If in LRO session there is a non-first descriptor with invalid checksum (L2/L3/L4), the driver must account this information in csum application logic. Fixes: 018423e90bee8 ("net: ethernet: aquantia: Add ring support code") Signed-off-by: Igor Russkikh <[email protected]> Signed-off-by: Dmitry Bogdanov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-27net: aquantia: tx clean budget logic errorIgor Russkikh1-3/+4
In case no other traffic happening on the ring, full tx cleanup may not be completed. That may cause socket buffer to overflow and tx traffic to stuck until next activity on the ring happens. This is due to logic error in budget variable decrementor. Variable is compared with zero, and then post decremented, causing it to become MAX_INT. Solution is remove decrementor from the `for` statement and rewrite it in a clear way. Fixes: b647d3980948e ("net: aquantia: Add tx clean budget and valid budget handling logic") Signed-off-by: Igor Russkikh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-27drm/etnaviv: lock MMU while dumping coreLucas Stach1-0/+5
The devcoredump needs to operate on a stable state of the MMU while it is writing the MMU state to the coredump. The missing lock allowed both the userspace submit, as well as the GPU job finish paths to mutate the MMU state while a coredump is under way. Fixes: a8c21a5451d8 (drm/etnaviv: add initial etnaviv DRM driver) Reported-by: David Jander <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Tested-by: David Jander <[email protected]> Reviewed-by: Philipp Zabel <[email protected]>
2019-05-27block: Don't revalidate bdev of hidden gendiskJan Kara1-9/+16
When hidden gendisk is revalidated, there's no point in revalidating associated block device as there's none. We would thus just create new bdev inode, report "detected capacity change from 0 to XXX" message and evict the bdev inode again. Avoid this pointless dance and confusing message in the kernel log. Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-27loop: Don't change loop device under exclusive openerJan Kara1-1/+17
Loop module allows calling LOOP_SET_FD while there are other openers of the loop device. Even exclusive ones. This can lead to weird consequences such as kernel deadlocks like: mount_bdev() lo_ioctl() udf_fill_super() udf_load_vrs() sb_set_blocksize() - sets desired block size B udf_tread() sb_bread() __bread_gfp(bdev, block, B) loop_set_fd() set_blocksize() - now __getblk_slow() indefinitely loops because B != bdev block size Fix the problem by disallowing LOOP_SET_FD ioctl when there are exclusive openers of a loop device. [Deliberately chosen not to CC stable as a user with priviledges to trigger this race has other means of taking the system down and this has a potential of breaking some weird userspace setup] Reported-and-tested-by: [email protected] Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-27drm/imx: ipuv3-plane: fix atomic update status query for non-plus i.MX6QPhilipp Zabel2-6/+8
The current buffer check halves the frame rate on non-plus i.MX6Q, as the IDMAC current buffer pointer is not yet updated when ipu_plane_atomic_update_pending is called from the EOF irq handler. Fixes: 70e8a0c71e9 ("drm/imx: ipuv3-plane: add function to query atomic update status") Tested-by: Marco Felsch <[email protected]> Signed-off-by: Philipp Zabel <[email protected]> Cc: [email protected]
2019-05-27drm/qxl: drop WARN_ONCE()Gerd Hoffmann1-1/+0
There is no good reason to flood the kernel log with a WARN stacktrace just because someone tried to mmap a prime buffer. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-27Merge tag 'intel-pinctrl-v5.2-2' of ↵Linus Walleij1-35/+10
git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into fixes intel-pinctrl for v5.2-2 Fix a laggish ELAN touchpad responsiveness due to an odd interrupt masking. The following is an automated git shortlog grouped by driver: intel: - Clear interrupt status in mask/unmask callback - Use GENMASK() consistently
2019-05-27PCI: PM: Avoid possible suspend-to-idle issueRafael J. Wysocki2-1/+17
If a PCI driver leaves the device handled by it in D0 and calls pci_save_state() on the device in its ->suspend() or ->suspend_late() callback, it can expect the device to stay in D0 over the whole s2idle cycle. However, that may not be the case if there is a spurious wakeup while the system is suspended, because in that case pci_pm_suspend_noirq() will run again after pci_pm_resume_noirq() which calls pci_restore_state(), via pci_pm_default_resume_early(), so state_saved is cleared and the second iteration of pci_pm_suspend_noirq() will invoke pci_prepare_to_sleep() which may change the power state of the device. To avoid that, add a new internal flag, skip_bus_pm, that will be set by pci_pm_suspend_noirq() when it runs for the first time during the given system suspend-resume cycle if the state of the device has been saved already and the device is still in D0. Setting that flag will cause the next iterations of pci_pm_suspend_noirq() to set state_saved for pci_pm_resume_noirq(), so that it always restores the device state from the originally saved data, and avoid calling pci_prepare_to_sleep() for the device. Fixes: 33e4f80ee69b ("ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle") Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Keith Busch <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2019-05-27ACPI: PM: Call pm_set_suspend_via_firmware() during hibernationRafael J. Wysocki3-18/+27
On systems with ACPI platform firmware the last stage of hibernation is analogous to system suspend to S3 (suspend-to-RAM), so it should be handled analogously. In particular, pm_suspend_via_firmware() should return 'true' in that stage to let the callers of it know that control will be passed to the platform firmware going forward, so pm_set_suspend_via_firmware() needs to be called then in analogy with acpi_suspend_begin(). However, the platform hibernation ->begin() callback is invoked during the "freeze" transition (before creating a snapshot image of system memory) as well as during the "hibernate" transition which is the last stage of it and pm_set_suspend_via_firmware() should be invoked by that callback in the latter stage only. In order to implement that redefine the hibernation ->begin() callback to take a pm_message_t argument to indicate which stage of hibernation is taking place and rework acpi_hibernation_begin() and acpi_hibernation_begin_old() to take it into account as needed. Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-05-27ACPI/PCI: PM: Add missing wakeup.flags.valid checksRafael J. Wysocki2-3/+4
Both acpi_pci_need_resume() and acpi_dev_needs_resume() check if the current ACPI wakeup configuration of the device matches what is expected as far as system wakeup from sleep states is concerned, as reflected by the device_may_wakeup() return value for the device. However, they only should do that if wakeup.flags.valid is set for the device's ACPI companion, because otherwise the wakeup.prepare_count value for it is meaningless. Add the missing wakeup.flags.valid checks to these functions. Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2019-05-26net: tulip: de4x5: Drop redundant MODULE_DEVICE_TABLE()Kees Cook1-1/+0
Building with Clang reports the redundant use of MODULE_DEVICE_TABLE(): drivers/net/ethernet/dec/tulip/de4x5.c:2110:1: error: redefinition of '__mod_eisa__de4x5_eisa_ids_device_table' MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids); ^ ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE' extern typeof(name) __mod_##type##__##name##_device_table \ ^ <scratch space>:90:1: note: expanded from here __mod_eisa__de4x5_eisa_ids_device_table ^ drivers/net/ethernet/dec/tulip/de4x5.c:2100:1: note: previous definition is here MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids); ^ ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE' extern typeof(name) __mod_##type##__##name##_device_table \ ^ <scratch space>:85:1: note: expanded from here __mod_eisa__de4x5_eisa_ids_device_table ^ This drops the one further from the table definition to match the common use of MODULE_DEVICE_TABLE(). Fixes: 07563c711fbc ("EISA bus MODALIAS attributes support") Signed-off-by: Kees Cook <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.