aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-04-27cifs: smbd: depend on INFINIBAND_ADDR_TRANSGreg Thelen1-1/+1
CIFS_SMB_DIRECT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen <[email protected]> Cc: Tarick Bedeir <[email protected]> Reviewed-by: Long Li <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-04-27ib_srpt: depend on INFINIBAND_ADDR_TRANSGreg Thelen1-1/+1
INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen <[email protected]> Cc: Tarick Bedeir <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-04-27nvmet-rdma: depend on INFINIBAND_ADDR_TRANSGreg Thelen1-1/+1
NVME_TARGET_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen <[email protected]> Cc: Tarick Bedeir <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-04-27nvme: depend on INFINIBAND_ADDR_TRANSGreg Thelen1-1/+1
NVME_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen <[email protected]> Cc: Tarick Bedeir <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-04-27nfp: don't depend on eth_tbl being availableJakub Kicinski4-16/+23
For very very old generation of the management FW Ethernet port information table may theoretically not be available. This in turn will cause the nfp_port structures to not be allocated. Make sure we don't crash the kernel when there is no eth_tbl: RIP: 0010:nfp_net_pci_probe+0xf2/0xb40 [nfp] ... Call Trace: nfp_pci_probe+0x6de/0xab0 [nfp] local_pci_probe+0x47/0xa0 work_for_cpu_fn+0x1a/0x30 process_one_work+0x1de/0x3e0 Found while working with broken/development version of management FW. Fixes: a5950182c00e ("nfp: map mac_stats and vf_cfg BARs") Fixes: 93da7d9660ee ("nfp: provide nfp_port to of nfp_net_get_mac_addr()") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Dirk van der Merwe <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-04-27x86/entry/64/compat: Preserve r8-r11 in int $0x80Andy Lutomirski2-18/+25
32-bit user code that uses int $80 doesn't care about r8-r11. There is, however, some 64-bit user code that intentionally uses int $0x80 to invoke 32-bit system calls. From what I've seen, basically all such code assumes that r8-r15 are all preserved, but the kernel clobbers r8-r11. Since I doubt that there's any code that depends on int $0x80 zeroing r8-r11, change the kernel to preserve them. I suspect that very little user code is broken by the old clobber, since r8-r11 are only rarely allocated by gcc, and they're clobbered by function calls, so they only way we'd see a problem is if the same function that invokes int $0x80 also spills something important to one of these registers. The current behavior seems to date back to the historical commit "[PATCH] x86-64 merge for 2.6.4". Before that, all regs were preserved. I can't find any explanation of why this change was made. Update the test_syscall_vdso_32 testcase as well to verify the new behavior, and it strengthens the test to make sure that the kernel doesn't accidentally permute r8..r15. Suggested-by: Denys Vlasenko <[email protected]> Signed-off-by: Andy Lutomirski <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Dominik Brodowski <[email protected]> Link: https://lkml.kernel.org/r/d4c4d9985fbe64f8c9e19291886453914b48caee.1523975710.git.luto@kernel.org
2018-04-27x86/ipc: Fix x32 version of shmid64_ds and msqid64_dsArnd Bergmann2-0/+73
A bugfix broke the x32 shmid64_ds and msqid64_ds data structure layout (as seen from user space) a few years ago: Originally, __BITS_PER_LONG was defined as 64 on x32, so we did not have padding after the 64-bit __kernel_time_t fields, After __BITS_PER_LONG got changed to 32, applications would observe extra padding. In other parts of the uapi headers we seem to have a mix of those expecting either 32 or 64 on x32 applications, so we can't easily revert the path that broke these two structures. Instead, this patch decouples x32 from the other architectures and moves it back into arch specific headers, partially reverting the even older commit 73a2d096fdf2 ("x86: remove all now-duplicate header files"). It's not clear whether this ever made any difference, since at least glibc carries its own (correct) copy of both of these header files, so possibly no application has ever observed the definitions here. Based on a suggestion from H.J. Lu, I tried out the tool from https://github.com/hjl-tools/linux-header to find other such bugs, which pointed out the same bug in statfs(), which also has a separate (correct) copy in glibc. Fixes: f4b4aae18288 ("x86/headers/uapi: Fix __BITS_PER_LONG value for x32 builds") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: "H . J . Lu" <[email protected]> Cc: Jeffrey Walton <[email protected]> Cc: [email protected] Cc: "H. Peter Anvin" <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-04-27x86/setup: Do not reserve a crash kernel region if booted on Xen PVPetr Tesarik1-0/+6
Xen PV domains cannot shut down and start a crash kernel. Instead, the crashing kernel makes a SCHEDOP_shutdown hypercall with the reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in arch/x86/xen/enlighten_pv.c. A crash kernel reservation is merely a waste of RAM in this case. It may also confuse users of kexec_load(2) and/or kexec_file_load(2). When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH, respectively, these syscalls return success, which is technically correct, but the crash kexec image will never be actually used. Signed-off-by: Petr Tesarik <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Cc: Tom Lendacky <[email protected]> Cc: Dou Liyang <[email protected]> Cc: Mikulas Patocka <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] Cc: Boris Ostrovsky <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Jean Delvare <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-04-27tipc: fix bug in function tipc_nl_node_dump_monitorJon Maloy1-1/+1
Commit 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor summary") intended to fix a problem with user tool looping when max number of bearers are enabled. Unfortunately, the wrong version of the commit was posted, so the problem was not solved at all. This commit adds the missing part. Fixes: 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor summary") Signed-off-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-04-27RDMA/mlx5: Properly check return value of mlx5_get_uars_pageLeon Romanovsky1-3/+1
Starting from commit 72f36be06138 ("net/mlx5: Fix mlx5_get_uars_page to return error code") the mlx5_get_uars_page() call returns error in case of failure, but it was mistakenly overlooked in the merge commit. Fixes: e7996a9a77fc ("Merge tag v4.15 of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git") Reported-by: Alaa Hleihel <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-04-27IB/mlx5: Fix represent correct netdevice in dual port RoCEParav Pandit1-1/+1
In commit bcf87f1dbbec ("IB/mlx5: Listen to netdev register/unresiter events in switchdev mode") incorrectly mapped primary device's netdevice to 2nd port netdevice. It always represented primary port's netdevice for 2nd port netdevice when ib representors were not used. This results into failing to process CM request arriving on 2nd port due to incorrect mapping of netdevice. This fix corrects it by considering the right mdev. Cc: <[email protected]> # 4.16 Fixes: bcf87f1dbbec ("IB/mlx5: Listen to netdev register/unresiter events in switchdev mode") Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Parav Pandit <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-04-27IB/mlx5: Use unlimited rate when static rate is not supportedDanit Goldberg1-9/+9
Before the change, if the user passed a static rate value different than zero and the FW doesn't support static rate, it would end up configuring rate of 2.5 GBps. Fix this by using rate 0; unlimited, in cases where FW doesn't support static rate configuration. Cc: <[email protected]> # 3.10 Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Reviewed-by: Majd Dibbiny <[email protected]> Signed-off-by: Danit Goldberg <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-04-27RDMA/mlx5: Protect from shift operand overflowLeon Romanovsky1-0/+4
Ensure that user didn't supply values too large that can cause overflow. UBSAN: Undefined behaviour in drivers/infiniband/hw/mlx5/qp.c:263:23 shift exponent -2147483648 is negative CPU: 0 PID: 292 Comm: syzkaller612609 Not tainted 4.16.0-rc1+ #131 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0xde/0x164 ubsan_epilogue+0xe/0x81 set_rq_size+0x7c2/0xa90 create_qp_common+0xc18/0x43c0 mlx5_ib_create_qp+0x379/0x1ca0 create_qp.isra.5+0xc94/0x2260 ib_uverbs_create_qp+0x21b/0x2a0 ib_uverbs_write+0xc2c/0x1010 vfs_write+0x1b0/0x550 SyS_write+0xc7/0x1a0 do_syscall_64+0x1aa/0x740 entry_SYSCALL_64_after_hwframe+0x26/0x9b RIP: 0033:0x433569 RSP: 002b:00007ffc6e62f448 EFLAGS: 00000217 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004002f8 RCX: 0000000000433569 RDX: 0000000000000070 RSI: 00000000200042c0 RDI: 0000000000000003 RBP: 00000000006d5018 R08: 00000000004002f8 R09: 00000000004002f8 R10: 00000000004002f8 R11: 0000000000000217 R12: 0000000000000000 R13: 000000000040c9f0 R14: 000000000040ca80 R15: 0000000000000006 Cc: <[email protected]> # 3.10 Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Cc: syzkaller <[email protected]> Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-04-27RDMA/mlx5: Fix multiple NULL-ptr deref errors in rereg_mr flowLeon Romanovsky1-9/+23
Failure in rereg MR releases UMEM but leaves the MR to be destroyed by the user. As a result the following scenario may happen: "create MR -> rereg MR with failure -> call to rereg MR again" and hit "NULL-ptr deref or user memory access" errors. Ensure that rereg MR is only performed on a non-dead MR. Cc: syzkaller <[email protected]> Cc: <[email protected]> # 4.5 Fixes: 395a8e4c32ea ("IB/mlx5: Refactoring register MR code") Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Doug Ledford <[email protected]>
2018-04-27errseq: Always report a writeback error onceMatthew Wilcox1-14/+9
The errseq_t infrastructure assumes that errors which occurred before the file descriptor was opened are of no interest to the application. This turns out to be a regression for some applications, notably Postgres. Before errseq_t, a writeback error would be reported exactly once (as long as the inode remained in memory), so Postgres could open a file, call fsync() and find out whether there had been a writeback error on that file from another process. This patch changes the errseq infrastructure to report errors to all file descriptors which are opened after the error occurred, but before it was reported to any file descriptor. This restores the user-visible behaviour. Cc: [email protected] Fixes: 5660e13d2fd6 ("fs: new infrastructure for writeback error handling and reporting") Signed-off-by: Matthew Wilcox <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Jeff Layton <[email protected]>
2018-04-27i2c: sprd: Fix the i2c count issueBaolin Wang1-4/+2
We found the I2C controller count register is unreliable sometimes, that will cause I2C to lose data. Thus we can read the data count from 'i2c_dev->count' instead of the I2C controller count register. Signed-off-by: Baolin Wang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-04-27i2c: sprd: Prevent i2c accesses after suspend is calledBaolin Wang1-0/+16
Add one flag to indicate if the i2c controller has been in suspend state, which can prevent i2c accesses after i2c controller is suspended following system suspend. Signed-off-by: Baolin Wang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-04-27i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()Alexander Popov1-1/+1
i2cdev_ioctl_rdwr() allocates i2c_msg.buf using memdup_user(), which returns ZERO_SIZE_PTR if i2c_msg.len is zero. Currently i2cdev_ioctl_rdwr() always dereferences the buf pointer in case of I2C_M_RD | I2C_M_RECV_LEN transfer. That causes a kernel oops in case of zero len. Let's check the len against zero before dereferencing buf pointer. This issue was triggered by syzkaller. Signed-off-by: Alexander Popov <[email protected]> Reviewed-by: Uwe Kleine-König <[email protected]> [wsa: use '< 1' instead of '!' for easier readability] Signed-off-by: Wolfram Sang <[email protected]>
2018-04-27KVM: arm/arm64: vgic: Fix source vcpu issues for GICv2 SGIMarc Zyngier6-61/+81
Now that we make sure we don't inject multiple instances of the same GICv2 SGI at the same time, we've made another bug more obvious: If we exit with an active SGI, we completely lose track of which vcpu it came from. On the next entry, we restore it with 0 as a source, and if that wasn't the right one, too bad. While this doesn't seem to trouble GIC-400, the architectural model gets offended and doesn't deactivate the interrupt on EOI. Another connected issue is that we will happilly make pending an interrupt from another vcpu, overriding the above zero with something that is just as inconsistent. Don't do that. The final issue is that we signal a maintenance interrupt when no pending interrupts are present in the LR. Assuming we've fixed the two issues above, we end-up in a situation where we keep exiting as soon as we've reached the active state, and not be able to inject the following pending. The fix comes in 3 parts: - GICv2 SGIs have their source vcpu saved if they are active on exit, and restored on entry - Multi-SGIs cannot go via the Pending+Active state, as this would corrupt the source field - Multi-SGIs are converted to using MI on EOI instead of NPIE Fixes: 16ca6a607d84bef0 ("KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid") Reported-by: Mark Rutland <[email protected]> Tested-by: Mark Rutland <[email protected]> Reviewed-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2018-04-27arm64: avoid instrumenting atomic_ll_sc.oMark Rutland1-0/+4
Our out-of-line atomics are built with a special calling convention, preventing pointless stack spilling, and allowing us to patch call sites with ARMv8.1 atomic instructions. Instrumentation inserted by the compiler may result in calls to functions not following this special calling convention, resulting in registers being unexpectedly clobbered, and various problems resulting from this. For example, if a kernel is built with KCOV and ARM64_LSE_ATOMICS, the compiler inserts calls to __sanitizer_cov_trace_pc in the prologues of the atomic functions. This has been observed to result in spurious cmpxchg failures, leading to a hang early on in the boot process. This patch avoids such issues by preventing instrumentation of our out-of-line atomics. Signed-off-by: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2018-04-27Merge tag 'arm-soc/for-4.17/devicetree-arm64-fixes' of ↵Arnd Bergmann1-40/+40
https://github.com/Broadcom/stblinux into fixes Pull "Broadcom devicetree-arm64 fixes for 4.17" from Florian Fainelli: This pull request contains Broadcom ARM64-based SoCs Device Tree fixes for 4.17, please pull the following: - Srinath fixes the register base address of all SATA controllers on Stingray * tag 'arm-soc/for-4.17/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux: arm64: dts: correct SATA addresses for Stingray
2018-04-27usb: gadget: composite Allow for larger configuration descriptorsJoel Pepper1-1/+1
The composite framework allows us to create gadgets composed from many different functions, which need to fit into a single configuration descriptor. Some functions (like uvc) can produce configuration descriptors upwards of 2500 bytes on their own. This patch increases the limit from 1024 bytes to 4096. Signed-off-by: Joel Pepper <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
2018-04-27powerpc/kvm/booke: Fix altivec related build breakLaurentiu Tudor1-0/+7
Add missing "altivec unavailable" interrupt injection helper thus fixing the linker error below: arch/powerpc/kvm/emulate_loadstore.o: In function `kvmppc_check_altivec_disabled': arch/powerpc/kvm/emulate_loadstore.c: undefined reference to `.kvmppc_core_queue_vec_unavail' Fixes: 09f984961c137c4b ("KVM: PPC: Book3S: Add MMIO emulation for VMX instructions") Signed-off-by: Laurentiu Tudor <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2018-04-27powerpc: Fix deadlock with multiple calls to smp_send_stopNicholas Piggin1-16/+39
smp_send_stop can lock up the IPI path for any subsequent calls, because the receiving CPUs spin in their handler function. This started becoming a problem with the addition of an smp_send_stop call in the reboot path, because panics can reboot after doing their own smp_send_stop. The NMI IPI variant was fixed with ac61c11566 ("powerpc: Fix smp_send_stop NMI IPI handling"), which leaves the smp_call_function variant. This is fixed by having smp_send_stop only ever do the smp_call_function once. This is a bit less robust than the NMI IPI fix, because any other call to smp_call_function after smp_send_stop could deadlock, but that has always been the case, and it was not been a problem before. Fixes: f2748bdfe1573 ("powerpc/powernv: Always stop secondaries before reboot/shutdown") Reported-by: Abdul Haleem <[email protected]> Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2018-04-27cpufreq: powernv: Fix hardlockup due to synchronous smp_call in timer interruptShilpasri G Bhat1-3/+11
gpstate_timer_handler() uses synchronous smp_call to set the pstate on the requested core. This causes the below hard lockup: smp_call_function_single+0x110/0x180 (unreliable) smp_call_function_any+0x180/0x250 gpstate_timer_handler+0x1e8/0x580 call_timer_fn+0x50/0x1c0 expire_timers+0x138/0x1f0 run_timer_softirq+0x1e8/0x270 __do_softirq+0x158/0x3e4 irq_exit+0xe8/0x120 timer_interrupt+0x9c/0xe0 decrementer_common+0x114/0x120 -- interrupt: 901 at doorbell_global_ipi+0x34/0x50 LR = arch_send_call_function_ipi_mask+0x120/0x130 arch_send_call_function_ipi_mask+0x4c/0x130 smp_call_function_many+0x340/0x450 pmdp_invalidate+0x98/0xe0 change_huge_pmd+0xe0/0x270 change_protection_range+0xb88/0xe40 mprotect_fixup+0x140/0x340 SyS_mprotect+0x1b4/0x350 system_call+0x58/0x6c One way to avoid this is removing the smp-call. We can ensure that the timer always runs on one of the policy-cpus. If the timer gets migrated to a cpu outside the policy then re-queue it back on the policy->cpus. This way we can get rid of the smp-call which was being used to set the pstate on the policy->cpus. Fixes: 7bc54b652f13 ("timers, cpufreq/powernv: Initialize the gpstate timer as pinned") Cc: [email protected] # v4.8+ Reported-by: Nicholas Piggin <[email protected]> Reported-by: Pridhiviraj Paidipeddi <[email protected]> Signed-off-by: Shilpasri G Bhat <[email protected]> Acked-by: Nicholas Piggin <[email protected]> Acked-by: Viresh Kumar <[email protected]> Acked-by: Vaidyanathan Srinivasan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2018-04-27Merge tag 'drm-intel-fixes-2018-04-26' of ↵Dave Airlie4-11/+22
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix for black screen issues (FDO #104158 and #104425) - A correction for wrongly applied display W/A - Fixes for HDA codec interop issue (no audio) and too eager HW timeouts * tag 'drm-intel-fixes-2018-04-26' of git://anongit.freedesktop.org/drm/drm-intel: drm/i915/fbdev: Enable late fbdev initial configuration drm/i915: Use ktime on wait_for drm/i915: Enable display WA#1183 from its correct spot drm/i915/audio: set minimum CD clock to twice the BCLK
2018-04-26tracing: Add field modifier parsing hist error for hist triggersTom Zanussi1-0/+1
If the user specifies an invalid field modifier for a hist trigger, the current code correctly flags that as an error, but doesn't tell the user what happened. Fix this by invoking hist_err() with an appropriate message when invalid modifiers are specified. Before: # echo 'hist:keys=pid:ts0=common_timestamp.junkusecs' >> /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger -su: echo: write error: Invalid argument # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/hist After: # echo 'hist:keys=pid:ts0=common_timestamp.junkusecs' >> /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger -su: echo: write error: Invalid argument # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/hist ERROR: Invalid field modifier: junkusecs Last command: keys=pid:ts0=common_timestamp.junkusecs Link: http://lkml.kernel.org/r/b043c59fa79acd06a5f14a1d44dee9e5a3cd1248.1524790601.git.tom.zanussi@linux.intel.com Signed-off-by: Tom Zanussi <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-26tracing: Add field parsing hist error for hist triggersTom Zanussi1-0/+1
If the user specifies a nonexistent field for a hist trigger, the current code correctly flags that as an error, but doesn't tell the user what happened. Fix this by invoking hist_err() with an appropriate message when nonexistent fields are specified. Before: # echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger -su: echo: write error: Invalid argument # cat /sys/kernel/debug/tracing/events/sched/sched_switch/hist After: # echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger -su: echo: write error: Invalid argument # cat /sys/kernel/debug/tracing/events/sched/sched_switch/hist ERROR: Couldn't find field: pid Last command: keys=pid:ts0=common_timestamp.usecs Link: http://lkml.kernel.org/r/fdc8746969d16906120f162b99dd71c741e0b62c.1524790601.git.tom.zanussi@linux.intel.com Signed-off-by: Tom Zanussi <[email protected]> Reported-by: Masami Hiramatsu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-26tracing: Restore proper field flag printing when displaying triggersTom Zanussi1-0/+10
The flag-printing code used when displaying hist triggers somehow got dropped during refactoring of the inter-event patchset. This restores it. Below are a couple examples - in the first case, .usecs wasn't being displayed properly for common_timestamps and the second illustrates the same for other flags such as .execname. Before: # echo 'hist:key=common_pid.execname:val=count:sort=count' > /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger hist:keys=common_pid:vals=hitcount,count:sort=count:size=2048 [active] # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="cyclictest"' >> /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger hist:keys=pid:vals=hitcount:ts0=common_timestamp:sort=hitcount:size=2048:clock=global if comm=="cyclictest" [active] After: # echo 'hist:key=common_pid.execname:val=count:sort=count' > /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger hist:keys=common_pid.execname:vals=hitcount,count:sort=count:size=2048 [active] # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="cyclictest"' >> /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger hist:keys=pid:vals=hitcount:ts0=common_timestamp.usecs:sort=hitcount:size=2048:clock=global if comm=="cyclictest" [active] Link: http://lkml.kernel.org/r/492bab42ff21806600af98a8ea901af10efbee0c.1524790601.git.tom.zanussi@linux.intel.com Signed-off-by: Tom Zanussi <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-26Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds3-86/+89
Pull virtio fixups from Michael Tsirkin: - Latest header update will break QEMU (if it's rebuilt with the new header) - and it seems that the code there is so fragile that any change in this header will break it. Add a better interface so users do not need to change their code every time that header changes. - Fix virtio console for spec compliance. * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: virtio_console: reset on out of memory virtio_console: move removal code virtio_console: drop custom control queue cleanup virtio_console: free buffers after reset virtio: add ability to iterate over vqs virtio_console: don't tie bufs to a vq virtio_balloon: add array of stat names
2018-04-26Merge tag 'hwmon-for-linus-v4.17-rc3' of ↵Linus Torvalds3-6/+20
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - Add support for new Ryzen chips to k10temp driver ... making Phoronix happy - Fix inconsistent chip access in nct6683 driver - Handle absence of few types of sensors in scmi driver * tag 'hwmon-for-linus-v4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (k10temp) Add support for AMD Ryzen w/ Vega graphics hwmon: (k10temp) Add temperature offset for Ryzen 2700X hwmon: (nct6683) Enable EC access if disabled at boot hwmon: (scmi) handle absence of few types of sensors
2018-04-26Merge tag 'pci-v4.17-fixes-1' of ↵Linus Torvalds3-26/+33
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: - fix Aardvark MRRS setting (Evan Wang) - clarify "bandwidth available" link status message (Jakub Kicinski) - update Kirin GPIO name to fix probe failure (Loic Poulain) - fix Aardvark IRQ usage (Victor Gu) - fix Aardvark config accessor issues (Victor Gu) * tag 'pci-v4.17-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: Add "PCIe" to pcie_print_link_status() messages PCI: kirin: Fix reset gpio name PCI: aardvark: Fix PCIe Max Read Request Size setting PCI: aardvark: Use ISR1 instead of ISR0 interrupt in legacy irq mode PCI: aardvark: Set PIO_ADDR_LS correctly in advk_pcie_rd_conf() PCI: aardvark: Fix logic in advk_pcie_{rd,wr}_conf()
2018-04-26Merge tag 'trace-v4.17-rc1' of ↵Linus Torvalds7-12/+73
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fixes from Steven Rostedt: - Add workqueue forward declaration (for new work, but a nice clean up) - seftest fixes for the new histogram code - Print output fix for hwlat tracer - Fix missing system call events - due to change in x86 syscall naming - Fix kprobe address being used by perf being hashed * tag 'trace-v4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Fix missing tab for hwlat_detector print format selftests: ftrace: Add a testcase for multiple actions on trigger selftests: ftrace: Fix trigger extended error testcase kprobes: Fix random address output of blacklist file tracing: Fix kernel crash while using empty filter with perf tracing/x86: Update syscall trace events to handle new prefixed syscall func names tracing: Add missing forward declaration
2018-04-26bpf: fix uninitialized variable in bpf toolsJohn Fastabend1-2/+5
Here the variable cont is used as the saved_pointer for a call to strtok_r(). It is safe to use the value uninitialized in this context however and the later reference is only ever used if the strtok_r is successful. But, 'gcc-5' at least doesn't have all this knowledge so initialize cont to NULL. Additionally, do the natural NULL check before accessing just for completness. The warning is the following: ./bpf/tools/bpf/bpf_dbg.c: In function ‘cmd_load’: ./bpf/tools/bpf/bpf_dbg.c:1077:13: warning: ‘cont’ may be used uninitialized in this function [-Wmaybe-uninitialized] } else if (matches(subcmd, "pcap") == 0) { Fixes: fd981e3c321a "filter: bpf_dbg: add minimal bpf debugger" Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2018-04-26net/mlx5: Properly deal with flow counters when deleting rulesChris Mi1-1/+2
When deleting a flow counter, the modify mask should be the action and the flow counter. Otherwise the flow counter is not deleted and we'll get a firmware warning when deleting the remaining destinations on the same FTE. It only happens in the presence of flow counter and multiple vport destinations. If there is only one vport destination, there is no need to update the FTE when deleting the only vport destination, we just delete the FTE. Fixes: ae05831424ed ("net/mlx5: Add option to add fwd rule with counter") Signed-off-by: Chris Mi <[email protected]> Signed-off-by: Jianbo Liu <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-04-26net/mlx5e: Fix traffic between VF and representorShahar Klein1-2/+3
After the cited commit, WQE RQ size is calculated based on sw_mtu but it was not set for representors. This commit fixes that. Fixes: 472a1e44b349 ("net/mlx5e: Save MTU in channels params") Signed-off-by: Shahar Klein <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-04-26net/mlx5: Avoid cleaning flow steering table twice during error flowTalat Batheesh1-9/+14
When we fail to initialize the RX root namespace, we need to clean only that and not the entire flow steering. Currently the code may try to clean the flow steering twice on error witch leads to null pointer deference. Make sure we clean correctly. Fixes: fba53f7b5719 ("net/mlx5: Introduce mlx5_flow_steering structure") Signed-off-by: Talat Batheesh <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-04-26net/mlx5e: TX, Use correct counter in dma_map error flowTariq Toukan1-10/+10
In case of a dma_mapping_error, do not use wi->num_dma as a parameter for dma unmap function because it's yet to be set, and holds an out-of-date value. Use actual value (local variable num_dma) instead. Fixes: 34802a42b352 ("net/mlx5e: Do not modify the TX SKB") Fixes: e586b3b0baee ("net/mlx5: Ethernet Datapath files") Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-04-26net/mlx5: Fix mlx5_get_vector_affinity functionIsrael Rukshin2-10/+4
Adding the vector offset when calling to mlx5_vector2eqn() is wrong. This is because mlx5_vector2eqn() checks if EQ index is equal to vector number and the fact that the internal completion vectors that mlx5 allocates don't get an EQ index. The second problem here is that using effective_affinity_mask gives the same CPU for different vectors. This leads to unmapped queues when calling it from blk_mq_rdma_map_queues(). This doesn't happen when using affinity_hint mask. Fixes: 2572cf57d75a ("mlx5: fix mlx5_get_vector_affinity to start from completion vector 0") Fixes: 05e0cc84e00c ("net/mlx5: Fix get vector affinity helper function") Signed-off-by: Israel Rukshin <[email protected]> Reviewed-by: Max Gurtovoy <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]>
2018-04-26net/mlx5e: DCBNL fix min inline header size for dscpHuy Nguyen1-3/+5
When the trust state is set to dscp and the netdev is down, the inline header size is not updated. When netdev is up, the inline header size stays at L2 instead of IP. Fix this issue by updating the private parameter when the netdev is in down so that when netdev is up, it picks up the right header size. Fixes: fbcb127e89ba ("net/mlx5e: Support DSCP trust state ...") Signed-off-by: Huy Nguyen <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-04-26net/mlx5e: Allow offloading ipv4 header re-write for icmpJianbo Liu1-1/+2
For ICMPv4, the checksum is calculated from the ICMP headers and data. Since the ICMPv4 checksum doesn't cover the IP header, we can allow to do L3 header re-write for this protocol. Fixes: bdd66ac0aeed ('net/mlx5e: Disallow TC offloading of unsupported match/action combinations') Signed-off-by: Jianbo Liu <[email protected]> Reviewed-by: Or Gerlitz <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-04-26x86/cpu/intel: Add missing TLB cpuid values[email protected]1-0/+3
Make kernel print the correct number of TLB entries on Intel Xeon Phi 7210 (and others) Before: [ 0.320005] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 After: [ 0.320005] Last level dTLB entries: 4KB 256, 2MB 128, 4MB 128, 1GB 16 The entries do exist in the official Intel SMD but the type column there is incorrect (states "Cache" where it should read "TLB"), but the entries for the values 0x6B, 0x6C and 0x6D are correctly described as 'Data TLB'. Signed-off-by: Jacek Tomaka <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-04-26tracing: initcall: Ordered comparison of function pointersRishabh Bhatnagar1-3/+11
Using initcall_t in the __field macro generates the following warning with clang version 6.0: include/trace/events/initcall.h:34:3: warning: ordered comparison of function pointers ('initcall_t' (aka 'int (*)(void)') and 'initcall_t') __field macro expands to __field_ext macro which does is_signed_type check on the type argument. Since initcall_t is defined as a function pointer, using it as the type in the __field macro, leads to an ordered comparison of function pointer warning, inside the check. Using __field_struct macro avoids the issue. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Rishabh Bhatnagar <[email protected]> [ Added comment to why we are using field_struct() ] Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-26tracing: Remove igrab() iput() call from uprobes.cSong Liu1-4/+3
Caller of uprobe_register is required to keep the inode and containing mount point referenced. There was misuse of igrab() in uprobes.c and trace_uprobe.c. This is because igrab() will not prevent umount of the containing mount point. To fix this, we added path to struct trace_uprobe, which keeps the inode and containing mount reference. For uprobes.c, it is not necessary to call igrab() in uprobe_register(), as the caller is required to keep the inode reference. The igrab() is removed and comments on this requirement is added to uprobe_register(). Link: http://lkml.kernel.org/r/CAELBmZB2XX=qEOLAdvGG4cPx4GEntcSnWQquJLUK1ongRj35cA@mail.gmail.com Link: http://lkml.kernel.org/r/[email protected] Cc: Ingo Molnar <[email protected]> Cc: Howard McLauchlan <[email protected]> Cc: Josef Bacik <[email protected]> Cc: Srikar Dronamraju <[email protected]> Acked-by: Miklos Szeredi <[email protected]> Signed-off-by: Song Liu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-26tracing: Fix bad use of igrab in trace_uprobe.cSong Liu1-21/+14
As Miklos reported and suggested: This pattern repeats two times in trace_uprobe.c and in kernel/events/core.c as well: ret = kern_path(filename, LOOKUP_FOLLOW, &path); if (ret) goto fail_address_parse; inode = igrab(d_inode(path.dentry)); path_put(&path); And it's wrong. You can only hold a reference to the inode if you have an active ref to the superblock as well (which is normally through path.mnt) or holding s_umount. This way unmounting the containing filesystem while the tracepoint is active will give you the "VFS: Busy inodes after unmount..." message and a crash when the inode is finally put. Solution: store path instead of inode. This patch fixes two instances in trace_uprobe.c. struct path is added to struct trace_uprobe to keep the inode and containing mount point referenced. Link: http://lkml.kernel.org/r/[email protected] Fixes: f3f096cfedf8 ("tracing: Provide trace events interface for uprobes") Fixes: 33ea4b24277b ("perf/core: Implement the 'perf_uprobe' PMU") Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Howard McLauchlan <[email protected]> Cc: Josef Bacik <[email protected]> Cc: Srikar Dronamraju <[email protected]> Acked-by: Miklos Szeredi <[email protected]> Reported-by: Miklos Szeredi <[email protected]> Signed-off-by: Song Liu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-04-26Merge tag 'acpi-4.17-rc3' of ↵Linus Torvalds4-14/+98
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These are two watchdog-related fixes, fix for a backlight regression from the 4.16 cycle that unfortunately was propagated to -stable and a button module modification to prevent graphics driver modules from failing to load due to unmet dependencies if ACPI is disabled from the kernel command line. Specifics: - Change the ACPI subsystem initialization ordering to initialize the WDAT watchodg before reserving PNP motherboard resources so as to allow the watchdog to allocate its resources before the PNP code gets to them and prevents it from working correctly (Mika Westerberg). - Add a quirk for Lenovo Z50-70 to use the iTCO watchdog instead of the WDAT one which conflicts with the RTC on that platform (Mika Westerberg). - Avoid breaking backlight handling on Dell XPS 13 2013 model by allowing laptops to use the ACPI backlight by default even if they are Windows 8-ready in principle (Hans de Goede)" * tag 'acpi-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / video: Only default only_lcd to true on Win8-ready _desktops_ ACPI / button: make module loadable when booted in non-ACPI mode ACPI / watchdog: Prefer iTCO_wdt on Lenovo Z50-70 ACPI / scan: Initialize watchdog before PNP
2018-04-26Merge tag 'pm-4.17-rc3' of ↵Linus Torvalds4-334/+17
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These are a Low Power S0 Idle quirk, a hibernation handling fix for the PCI bus type and a brcmstb-avs-cpufreq driver fixup removing development debug code from it. Specifics: - Blacklist the Low Power S0 Idle _DSM on ThinkPad X1 Tablet(2016) where it causes issues and make it use ACPI S3 which works instead of the non-working suspend-to-idle by default (Chen Yu). - Fix the handling of hibernation in the PCI core for devices with the DPM_FLAG_SMART_SUSPEND flag set to fix a regression affecting intel-lpss I2C devices (Mika Westerberg). - Drop development debug code from the brcmstb-avs-cpufreq driver (Markus Mayer)" * tag 'pm-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: brcmstb-avs-cpufreq: remove development debug support PCI / PM: Do not clear state_saved in pci_pm_freeze() when smart suspend is set ACPI / PM: Blacklist Low Power S0 Idle _DSM for ThinkPad X1 Tablet(2016)
2018-04-26Merge tag 'random_for_linus_stable' of ↵Linus Torvalds1-6/+42
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random Pull /dev/random fixes from Ted Ts'o: "Fix a regression on NUMA kernels and suppress excess unseeded entropy pool warnings" * tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random: random: rate limit unseeded randomness warnings random: fix possible sleeping allocation from irq context
2018-04-26Merge branch 'for-linus' of ↵Linus Torvalds8-18/+62
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "A couple of bug fixes: - correct some CPU-MF counter names for z13 and z14 - correct locking in the vfio-ccw fsm_io_helper function - provide arch_uretprobe_is_alive to avoid sigsegv with uretprobes - fix a corner case with CPU-MF sampling in regard to execve - fix expoline code revert for loadable modules - update chpid descriptor for resource accessibility events - fix dasd I/O errors due to outdated device alias infomation" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: correct module section names for expoline code revert vfio: ccw: process ssch with interrupts disabled s390: update sampling tag after task pid change s390/cpum_cf: rename IBM z13/z14 counter names s390/dasd: fix IO error for newly defined devices s390/uprobes: implement arch_uretprobe_is_alive() s390/cio: update chpid descriptor after resource accessibility event
2018-04-26Merge tag 'usb-serial-4.17-rc3' of ↵Greg Kroah-Hartman4-1/+11
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for v4.17-rc3 Here are a few device ids for -rc3, including a new "simple driver". All have been in linux-next with no reported issues. Signed-off-by: Johan Hovold <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.