aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-11-21Merge tag 'kvmarm-5.5' of ↵Paolo Bonzini55-276/+1016
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm updates for Linux 5.5: - Allow non-ISV data aborts to be reported to userspace - Allow injection of data aborts from userspace - Expose stolen time to guests - GICv4 performance improvements - vgic ITS emulation fixes - Simplify FWB handling - Enable halt pool counters - Make the emulated timer PREEMPT_RT compliant Conflicts: include/uapi/linux/kvm.h
2019-11-21drm/i915/fbdev: Restore physical addresses for fb_mmap()Chris Wilson1-4/+5
fbdev uses the physical address of our framebuffer for its fb_mmap() routine. While we need to adapt this address for the new io BAR, we have to fix v5.4 first! The simplest fix is to restore the smem back to v5.3 and we will then probably have to implement our fbops->fb_mmap() callback to handle local memory. Reported-by: Neil MacLeod <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256 Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base") Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Maarten Lankhorst <[email protected]> Tested-by: Neil MacLeod <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit abc5520704ab438099fe352636b30b05c1253bea) Signed-off-by: Joonas Lahtinen <[email protected]> (cherry picked from commit 9faf5fa4d3dad3b0c0fa6e67689c144981a11c27) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-11-21Bluetooth: btbcm: Add entry for BCM4335A0 UART bluetoothMohammad Rasim2-0/+2
This patch adds the device ID for the BCM4335A0 module (part of the AMPAK AP6335 WIFI/Bluetooth combo) hciconfig output: ``` hci1: Type: Primary Bus: UART BD Address: 43:35:B0:07:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:5079 acl:0 sco:0 events:567 errors:0 TX bytes:69065 acl:0 sco:0 commands:567 errors:0 Features: 0xbf 0xfe 0xcf 0xff 0xdf 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'alarm' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x161 LMP Version: 4.0 (0x6) Subversion: 0x4106 Manufacturer: Broadcom Corporation (15) ``` Signed-off-by: Mohammad Rasim <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-11-21dt-bindings: net: Add compatible for BCM4335A0 bluetoothMohammad Rasim1-0/+1
Available in the Ampak AP6335 WiFi/Bluetooth combo Signed-off-by: Mohammad Rasim <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-11-21rackmeter: Use vtime aware kcpustat accessorFrederic Weisbecker1-3/+4
Now that we have a vtime safe kcpustat accessor, use it to fetch CPUTIME_NICE and fix frozen kcpustat values on nohz_full CPUs. Reported-by: Yauheni Kaliuta <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Wanpeng Li <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-11-21leds: Use all-in-one vtime aware kcpustat accessorFrederic Weisbecker1-5/+9
We can now safely read user kcpustat fields on nohz_full CPUs. Use the appropriate accessor. [ mingo: Fixed build failure. ] Reported-by: Yauheni Kaliuta <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Jacek Anaszewski <[email protected]> (maintainer:LED SUBSYSTEM) Cc: Pavel Machek <[email protected]> (maintainer:LED SUBSYSTEM) Cc: Dan Murphy <[email protected]> (reviewer:LED SUBSYSTEM) Cc: Peter Zijlstra <[email protected]> Cc: Wanpeng Li <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-11-21pcmcia: Use dev_get_drvdata where possibleChuhong Yuan1-2/+1
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <[email protected]> Signed-off-by: Dominik Brodowski <[email protected]>
2019-11-21pcmcia: clean an indentation issues, remove extraneous spacesColin Ian King1-18/+16
Trivial fix to clean up indentation issues, remove spaces Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Dominik Brodowski <[email protected]>
2019-11-21perf/core: Make the mlock accounting simple againAlexander Shishkin1-7/+1
Commit: d44248a41337 ("perf/core: Rework memory accounting in perf_mmap()") does a lot of things to the mlock accounting arithmetics, while the only thing that actually needed to happen is subtracting the part that is charged to the mm from the part that is charged to the user, so that the former isn't charged twice. Signed-off-by: Alexander Shishkin <[email protected]> Acked-by: Song Liu <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Wanpeng Li <[email protected]> Cc: Yauheni Kaliuta <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-11-21cpufreq: Use vtime aware kcpustat accessors for user timeFrederic Weisbecker2-10/+13
We can now safely read user and guest kcpustat fields on nohz_full CPUs. Use the appropriate accessors. Reported-by: Yauheni Kaliuta <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Viresh Kumar <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Wanpeng Li <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-11-21procfs: Use all-in-one vtime aware kcpustat accessorFrederic Weisbecker1-25/+31
Now that we can read also user and guest time safely under vtime, use the relevant accessor to fix frozen kcpustat values on nohz_full CPUs. Reported-by: Yauheni Kaliuta <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Al Viro <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Wanpeng Li <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-11-21sched/vtime: Bring up complete kcpustat accessorFrederic Weisbecker2-20/+123
Many callsites want to fetch the values of system, user, user_nice, guest or guest_nice kcpustat fields altogether or at least a pair of these. In that case calling kcpustat_field() for each requested field brings unecessary overhead when we could fetch all of them in a row. So provide kcpustat_cpu_fetch() that fetches the whole kcpustat array in a vtime safe way under the same RCU and seqcount block. Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Wanpeng Li <[email protected]> Cc: Yauheni Kaliuta <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-11-21sched/cputime: Support other fields on kcpustat_field()Frederic Weisbecker1-11/+43
Provide support for user, nice, guest and guest_nice fields through kcpustat_field(). Whether we account the delta to a nice or not nice field is decided on top of the nice value snapshot taken at the time we call kcpustat_field(). If the nice value of the task has been changed since the last vtime update, we may have inacurrate distribution of the nice VS unnice cputime. However this is considered as a minor issue compared to the proper fix that would involve interrupting the target on nice updates, which is undesired on nohz_full CPUs. Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Wanpeng Li <[email protected]> Cc: Yauheni Kaliuta <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-11-20net: sfp: soft status and control supportRussell King2-20/+94
Add support for the soft status and control register, which allows TX_FAULT and RX_LOS to be monitored and TX_DISABLE to be set. We make use of this when the board does not support GPIOs for these signals. Signed-off-by: Russell King <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20Merge branch 'sfp-quirks'David S. Miller1-0/+79
Russell King says: ==================== Add rudimentary SFP module quirk support The SFP module EEPROM describes the capabilities of the module, but doesn't describe the host interface. We have a certain amount of guess-work to work out how to configure the host - which works most of the time. However, there are some (such as GPON) modules which are able to support different host interfaces, such as 1000BASE-X and 2500BASE-X. The module will switch between each mode until it achieves link with the host. There is no defined way to describe this in the SFP EEPROM, so we can only recognise the module and handle it appropriately. This series adds the necessary recognition of the modules using a quirk system, and tweaks the support mask to allow them to link with the host at 2500BASE-X, thereby allowing the user to achieve full line rate. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-11-20net: sfp: add some quirks for GPON modulesRussell King1-0/+25
Marc Micalizzi reports that Huawei MA5671A and Alcatel/Lucent G-010S-P modules are capable of 2500base-X, but incorrectly report their capabilities in the EEPROM. It seems rather common that GPON modules mis-report. Let's fix these modules by adding some quirks. Signed-off-by: Russell King <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20net: sfp: add support for module quirksRussell King1-0/+54
Add support for applying module quirks to the list of supported ethtool link modes. Signed-off-by: Russell King <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20tcp: warn if offset reach the maxlen limit when using snprintfHangbin Liu3-0/+13
snprintf returns the number of chars that would be written, not number of chars that were actually written. As such, 'offs' may get larger than 'tbl.maxlen', causing the 'tbl.maxlen - offs' being < 0, and since the parameter is size_t, it would overflow. Since using scnprintf may hide the limit error, while the buffer is still enough now, let's just add a WARN_ON_ONCE in case it reach the limit in future. v2: Use WARN_ON_ONCE as Jiri and Eric suggested. Suggested-by: Jiri Benc <[email protected]> Signed-off-by: Hangbin Liu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20ip_gre: Make none-tun-dst gre tunnel store tunnel info as metadat_dst in recvwenxu1-1/+5
Currently collect_md gre tunnel will store the tunnel info(metadata_dst) to skb_dst. And now the non-tun-dst gre tunnel already can add tunnel header through lwtunnel. When received a arp_request on the non-tun-dst gre tunnel. The packet of arp response will send through the non-tun-dst tunnel without tunnel info which will lead the arp response packet to be dropped. If the non-tun-dst gre tunnel also store the tunnel info as metadata_dst, The arp response packet will set the releted tunnel info in the iptunnel_metadata_reply. The following is the test script: ip netns add cl ip l add dev vethc type veth peer name eth0 netns cl ifconfig vethc 172.168.0.7/24 up ip l add dev tun1000 type gretap key 1000 ip link add user1000 type vrf table 1 ip l set user1000 up ip l set dev tun1000 master user1000 ifconfig tun1000 10.0.1.1/24 up ip netns exec cl ifconfig eth0 172.168.0.17/24 up ip netns exec cl ip l add dev tun type gretap local 172.168.0.17 remote 172.168.0.7 key 1000 ip netns exec cl ifconfig tun 10.0.1.7/24 up ip r r 10.0.1.7 encap ip id 1000 dst 172.168.0.17 key dev tun1000 table 1 With this patch ip netns exec cl ping 10.0.1.1 can success Signed-off-by: wenxu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20net-sysfs: fix netdev_queue_add_kobject() breakageEric Dumazet1-0/+1
kobject_put() should only be called in error path. Fixes: b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject") Signed-off-by: Eric Dumazet <[email protected]> Cc: Jouni Hogander <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-21KVM: PPC: Book3S HV: XIVE: Fix potential page leak on error pathGreg Kurz1-6/+7
We need to check the host page size is big enough to accomodate the EQ. Let's do this before taking a reference on the EQ page to avoid a potential leak if the check fails. Cc: [email protected] # v5.2 Fixes: 13ce3297c576 ("KVM: PPC: Book3S HV: XIVE: Add controls for the EQ configuration") Signed-off-by: Greg Kurz <[email protected]> Reviewed-by: Cédric Le Goater <[email protected]> Signed-off-by: Paul Mackerras <[email protected]>
2019-11-21KVM: PPC: Book3S HV: XIVE: Free previous EQ page when setting up a new oneGreg Kurz1-9/+22
The EQ page is allocated by the guest and then passed to the hypervisor with the H_INT_SET_QUEUE_CONFIG hcall. A reference is taken on the page before handing it over to the HW. This reference is dropped either when the guest issues the H_INT_RESET hcall or when the KVM device is released. But, the guest can legitimately call H_INT_SET_QUEUE_CONFIG several times, either to reset the EQ (vCPU hot unplug) or to set a new EQ (guest reboot). In both cases the existing EQ page reference is leaked because we simply overwrite it in the XIVE queue structure without calling put_page(). This is especially visible when the guest memory is backed with huge pages: start a VM up to the guest userspace, either reboot it or unplug a vCPU, quit QEMU. The leak is observed by comparing the value of HugePages_Free in /proc/meminfo before and after the VM is run. Ideally we'd want the XIVE code to handle the EQ page de-allocation at the platform level. This isn't the case right now because the various XIVE drivers have different allocation needs. It could maybe worth introducing hooks for this purpose instead of exposing XIVE internals to the drivers, but this is certainly a huge work to be done later. In the meantime, for easier backport, fix both vCPU unplug and guest reboot leaks by introducing a wrapper around xive_native_configure_queue() that does the necessary cleanup. Reported-by: Satheesh Rajendran <[email protected]> Cc: [email protected] # v5.2 Fixes: 13ce3297c576 ("KVM: PPC: Book3S HV: XIVE: Add controls for the EQ configuration") Signed-off-by: Cédric Le Goater <[email protected]> Signed-off-by: Greg Kurz <[email protected]> Tested-by: Lijun Pan <[email protected]> Signed-off-by: Paul Mackerras <[email protected]>
2019-11-21Merge tag 'drm-fixes-5.4-2019-11-20' of ↵Dave Airlie7-14/+42
git://people.freedesktop.org/~agd5f/linux into drm-fixes drm-fixes-5.4-2019-11-20: amdgpu: - Remove experimental flag for navi14 - Fix confusing power message failures on older VI parts - Hang fix for gfxoff when using the read register interface - Two stability regression fixes for Raven Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-11-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller120-1078/+4952
Daniel Borkmann says: ==================== pull-request: bpf-next 2019-11-20 The following pull-request contains BPF updates for your *net-next* tree. We've added 81 non-merge commits during the last 17 day(s) which contain a total of 120 files changed, 4958 insertions(+), 1081 deletions(-). There are 3 trivial conflicts, resolve it by always taking the chunk from 196e8ca74886c433: <<<<<<< HEAD ======= void *bpf_map_area_mmapable_alloc(u64 size, int numa_node); >>>>>>> 196e8ca74886c433dcfc64a809707074b936aaf5 <<<<<<< HEAD void *bpf_map_area_alloc(u64 size, int numa_node) ======= static void *__bpf_map_area_alloc(u64 size, int numa_node, bool mmapable) >>>>>>> 196e8ca74886c433dcfc64a809707074b936aaf5 <<<<<<< HEAD if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) { ======= /* kmalloc()'ed memory can't be mmap()'ed */ if (!mmapable && size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) { >>>>>>> 196e8ca74886c433dcfc64a809707074b936aaf5 The main changes are: 1) Addition of BPF trampoline which works as a bridge between kernel functions, BPF programs and other BPF programs along with two new use cases: i) fentry/fexit BPF programs for tracing with practically zero overhead to call into BPF (as opposed to k[ret]probes) and ii) attachment of the former to networking related programs to see input/output of networking programs (covering xdpdump use case), from Alexei Starovoitov. 2) BPF array map mmap support and use in libbpf for global data maps; also a big batch of libbpf improvements, among others, support for reading bitfields in a relocatable manner (via libbpf's CO-RE helper API), from Andrii Nakryiko. 3) Extend s390x JIT with usage of relative long jumps and loads in order to lift the current 64/512k size limits on JITed BPF programs there, from Ilya Leoshkevich. 4) Add BPF audit support and emit messages upon successful prog load and unload in order to have a timeline of events, from Daniel Borkmann and Jiri Olsa. 5) Extension to libbpf and xdpsock sample programs to demo the shared umem mode (XDP_SHARED_UMEM) as well as RX-only and TX-only sockets, from Magnus Karlsson. 6) Several follow-up bug fixes for libbpf's auto-pinning code and a new API call named bpf_get_link_xdp_info() for retrieving the full set of prog IDs attached to XDP, from Toke Høiland-Jørgensen. 7) Add BTF support for array of int, array of struct and multidimensional arrays and enable it for skb->cb[] access in kfree_skb test, from Martin KaFai Lau. 8) Fix AF_XDP by using the correct number of channels from ethtool, from Luigi Rizzo. 9) Two fixes for BPF selftest to get rid of a hang in test_tc_tunnel and to avoid xdping to be run as standalone, from Jiri Benc. 10) Various BPF selftest fixes when run with latest LLVM trunk, from Yonghong Song. 11) Fix a memory leak in BPF fentry test run data, from Colin Ian King. 12) Various smaller misc cleanups and improvements mostly all over BPF selftests and samples, from Daniel T. Lee, Andre Guedes, Anders Roxell, Mao Wenan, Yue Haibing. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-11-20Revert "drm/amd/display: enable S/G for RAVEN chip"Alex Deucher2-2/+2
This reverts commit 1c4259159132ae4ceaf7c6db37a6cf76417f73d9. S/G display is not stable with the IOMMU enabled on some platforms. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523 Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-11-20drm/amdgpu: disable gfxoff on original ravenAlex Deucher1-2/+7
There are still combinations of sbios and firmware that are not stable. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=204689 Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-11-20drm/amdgpu: disable gfxoff when using register read interfaceAlex Deucher1-1/+5
When gfxoff is enabled, accessing gfx registers via MMIO can lead to a hang. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205497 Acked-by: Xiaojie Yuan <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-11-20drm/amd/powerplay: correct fine grained dpm force level settingEvan Quan1-0/+6
For fine grained dpm, there is only two levels supported. However to reflect correctly the current clock frequency, there is an intermediate level faked. Thus on forcing level setting, we need to treat level 2 correctly as level 1. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Kevin Wang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-20drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICsEvan Quan1-5/+18
Otherwise, the error message prompted will confuse user. Signed-off-by: Evan Quan <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-11-20drm/amdgpu: remove experimental flag for Navi14Alex Deucher1-4/+4
5.4 and newer works fine with navi14. Reviewed-by: Xiaojie Yuan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-20block,bfq: Skip tracing hooks if possibleDmitry Monakhov1-0/+4
In most cases blk_tracing is not active, but bfq_log_bfqq macro generate pid_str unconditionally, which result in significant overhead. ## Test modprobe null_blk echo bfq > /sys/block/nullb0/queue/scheduler fio --name=t --ioengine=libaio --direct=1 --filename=/dev/nullb0 \ --runtime=30 --time_based=1 --rw=write --iodepth=128 --bs=4k # Results | | baseline | w/ patch | gain | | iops | 113.19K | 126.42K | +11% | Acked-by: Paolo Valente <[email protected]> Signed-off-by: Dmitry Monakhov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-11-20x86/ioperm: Fix use of deprecated config optionAlexander Duyck1-2/+1
The commit 111e7b15cf10 ("x86/ioperm: Extend IOPL config to control ioperm() as well") replaced X86_IOPL_EMULATION with X86_IOPL_IOPERM. However it appears that there was at least one spot missed as tss_update_io_bitmap() still had a reference to it contained in the code. The result of this is that it exposed a NULL pointer dereference as seen below with a linux-next next-20191120 kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 1542 Comm: ovs-vswitchd Tainted: G W 5.4.0-rc8-next-20191120 #125 RIP: 0010:tss_update_io_bitmap+0x4e/0x180 Code: 10 31 c0 65 48 03 1d 69 54 5d 6d 65 48 8b 04 25 40 8c 01 00 48 8b 10 \ f7 c2 00 00 40 00 0f 84 8c 00 00 00 4c 8b a0 c0 22 00 00 <49> 8b 04 \ 24 48 39 43 68 74 2e 8b 53 70 41 39 54 24 0c 48 8d 7b 78 RSP: 0018:ffffb8888a0ebf08 EFLAGS: 00010006 RAX: ffff8a429811a680 RBX: ffff8a4c3f946000 RCX: 0000000000000011 RDX: 0000000000400080 RSI: 0000000000400080 RDI: 0000000000000000 RBP: ffffb8888a0ebf30 R08: 00007ffffb5d7ce0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f68a9635c40(0000) GS:ffff8a4c3f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000103572a001 CR4: 00000000001606e0 Call Trace: ? syscall_slow_exit_work+0x39/0xdb do_syscall_64+0x1a5/0x200 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f68a7aff797 Fixes: 111e7b15cf10 ("x86/ioperm: Extend IOPL config to control ioperm() as well") Signed-off-by: Alexander Duyck <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Rik van Riel <[email protected]> Cc: x86-ml <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-11-20Revert "dm crypt: use WQ_HIGHPRI for the IO and crypt workqueues"Mike Snitzer1-6/+3
This reverts commit a1b89132dc4f61071bdeaab92ea958e0953380a1. Revert required hand-patching due to subsequent changes that were applied since commit a1b89132dc4f61071bdeaab92ea958e0953380a1. Requires: ed0302e83098d ("dm crypt: make workqueue names device-specific") Cc: [email protected] Bug: https://bugzilla.kernel.org/show_bug.cgi?id=199857 Reported-by: Vito Caputo <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2019-11-20bpf: Switch bpf_map_{area_alloc,area_mmapable_alloc}() to u64 sizeDaniel Borkmann2-7/+10
Given we recently extended the original bpf_map_area_alloc() helper in commit fc9702273e2e ("bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY"), we need to apply the same logic as in ff1c08e1f74b ("bpf: Change size to u64 for bpf_map_{area_alloc, charge_init}()"). To avoid conflicts, extend it for bpf-next. Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2019-11-20bpf: Emit audit messages upon successful prog load and unloadDaniel Borkmann4-1/+36
Allow for audit messages to be emitted upon BPF program load and unload for having a timeline of events. The load itself is in syscall context, so additional info about the process initiating the BPF prog creation can be logged and later directly correlated to the unload event. The only info really needed from BPF side is the globally unique prog ID where then audit user space tooling can query / dump all info needed about the specific BPF program right upon load event and enrich the record, thus these changes needed here can be kept small and non-intrusive to the core. Raw example output: # auditctl -D # auditctl -a always,exit -F arch=x86_64 -S bpf # ausearch --start recent -m 1334 [...] ---- time->Wed Nov 20 12:45:51 2019 type=PROCTITLE msg=audit(1574271951.590:8974): proctitle="./test_verifier" type=SYSCALL msg=audit(1574271951.590:8974): arch=c000003e syscall=321 success=yes exit=14 a0=5 a1=7ffe2d923e80 a2=78 a3=0 items=0 ppid=742 pid=949 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="test_verifier" exe="/root/bpf-next/tools/testing/selftests/bpf/test_verifier" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=UNKNOWN[1334] msg=audit(1574271951.590:8974): auid=0 uid=0 gid=0 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=949 comm="test_verifier" exe="/root/bpf-next/tools/testing/selftests/bpf/test_verifier" prog-id=3260 event=LOAD ---- time->Wed Nov 20 12:45:51 2019 type=UNKNOWN[1334] msg=audit(1574271951.590:8975): prog-id=3260 event=UNLOAD ---- [...] Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2019-11-20Merge tag 'mlx5-fixes-2019-11-20' of ↵David S. Miller12-56/+67
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== Mellanox, mlx5 fixes 2019-11-20 This series introduces some fixes to mlx5 driver. Please pull and let me know if there is any problem. For -stable v4.9: ('net/mlx5e: Fix set vf link state error flow') For -stable v4.14 ('net/mlxfw: Verify FSM error code translation doesn't exceed array size') For -stable v4.19 ('net/mlx5: Fix auto group size calculation') For -stable v5.3 ('net/mlx5e: Fix error flow cleanup in mlx5e_tc_tun_create_header_ipv4/6') ('net/mlx5e: Do not use non-EXT link modes in EXT mode') ('net/mlx5: Update the list of the PCI supported devices') ==================== Signed-off-by: David S. Miller <[email protected]>
2019-11-20Merge branch 'r8169-smaller-improvements-to-firmware-handling'David S. Miller1-7/+12
Heiner Kallweit says: ==================== r8169: smaller improvements to firmware handling This series includes few smaller improvements to firmware handling. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-11-20r8169: add check for PHY_MDIO_CHG to rtl_nic_fw_data_okHeiner Kallweit1-5/+10
Only values 0 and 1 are currently defined as parameters for PHY_MDIO_CHG. Instead of silently ignoring unknown values and misinterpreting the firmware code let's explicitly check. Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20r8169: use macro FIELD_SIZEOF in definition of FW_OPCODE_SIZEHeiner Kallweit1-1/+1
Using macro FIELD_SIZEOF makes this define easier understandable. Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20r8169: change mdelay to msleep in rtl_fw_write_firmwareHeiner Kallweit1-1/+1
We're not in atomic context here, therefore switch to msleep. Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20r8152: Re-order napi_disable in rtl8152_closePrashant Malani1-1/+1
Both rtl_work_func_t() and rtl8152_close() call napi_disable(). Since the two calls aren't protected by a lock, if the close function starts executing before the work function, we can get into a situation where the napi_disable() function is called twice in succession (first by rtl8152_close(), then by set_carrier()). In such a situation, the second call would loop indefinitely, since rtl8152_close() doesn't call napi_enable() to clear the NAPI_STATE_SCHED bit. The rtl8152_close() function in turn issues a cancel_delayed_work_sync(), and so it would wait indefinitely for the rtl_work_func_t() to complete. Since rtl8152_close() is called by a process holding rtnl_lock() which is requested by other processes, this eventually leads to a system deadlock and crash. Re-order the napi_disable() call to occur after the work function disabling and urb cancellation calls are issued. Change-Id: I6ef0b703fc214998a037a68f722f784e1d07815e Reported-by: http://crbug.com/1017928 Signed-off-by: Prashant Malani <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20Merge branch 'qca_spi-fixes'David S. Miller2-6/+6
Stefan Wahren says: ==================== net: qca_spi: Fix receive and reset issues This small patch series fixes two major issues in the SPI driver for the QCA700x. It has been tested on a Charge Control C 300 (NXP i.MX6ULL + 2x QCA7000). ==================== Signed-off-by: David S. Miller <[email protected]>
2019-11-20net: qca_spi: Move reset_count to struct qcaspiStefan Wahren2-5/+5
The reset counter is specific for every QCA700x chip. So move this into the private driver struct. Otherwise we get unpredictable reset behavior in setups with multiple QCA700x chips. Fixes: 291ab06ecf67 (net: qualcomm: new Ethernet over SPI driver for QCA7000) Signed-off-by: Stefan Wahren <[email protected]> Signed-off-by: Stefan Wahren <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20net: qca_spi: fix receive buffer size checkMichael Heimpold1-1/+1
When receiving many or larger packets, e.g. when doing a file download, it was observed that the read buffer size register reports up to 4 bytes more than the current define allows in the check. If this is the case, then no data transfer is initiated to receive the packets (and thus to empty the buffer) which results in a stall of the interface. These 4 bytes are a hardware generated frame length which is prepended to the actual frame, thus we have to respect it during our check. Fixes: 026b907d58c4 ("net: qca_spi: Add available buffer space verification") Signed-off-by: Michael Heimpold <[email protected]> Signed-off-by: Stefan Wahren <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20net: ipconfig: Wait for deferred device probesThomas Bogendoerfer1-0/+3
If network device drives are using deferred probing, it was possible that waiting for devices to show up in ipconfig was already over, when the device eventually showed up. By calling wait_for_device_probe() we now make sure deferred probing is done before checking for available devices. Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20vsock/vmci: make vmci_vsock_cb_host_called staticMao Wenan1-1/+1
When using make C=2 drivers/misc/vmw_vmci/vmci_driver.o to compile, below warning can be seen: drivers/misc/vmw_vmci/vmci_driver.c:33:6: warning: symbol 'vmci_vsock_cb_host_called' was not declared. Should it be static? This patch make symbol vmci_vsock_cb_host_called static. Fixes: b1bba80a4376 ("vsock/vmci: register vmci_transport only when VMCI guest/host are active") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Mao Wenan <[email protected]> Reported-by: kbuild test robot <[email protected]> Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20Merge branch 'ibmvnic-regression'David S. Miller1-3/+8
Juliet Kim says: ==================== Support both XIVE and XICS modes in ibmvnic This series aims to support both XICS and XIVE with avoiding a regression in behavior when a system runs in XICS mode. Patch 1 reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab (“net/ibmvnic: Fix EOI when running in XIVE mode.”) Patch 2 Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode ==================== Signed-off-by: David S. Miller <[email protected]>
2019-11-20net/ibmvnic: Ignore H_FUNCTION return from H_EOI to tolerate XIVE modeJuliet Kim1-1/+4
Reversion of commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab (“net/ibmvnic: Fix EOI when running in XIVE mode.”) leaves us calling H_EOI even in XIVE mode. That will fail with H_FUNCTION because H_EOI is not supported in that mode. That failure is harmless. Ignore it so we can use common code for both XICS and XIVE. Signed-off-by: Juliet Kim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20Revert "net/ibmvnic: Fix EOI when running in XIVE mode"Juliet Kim1-3/+5
This reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab (“net/ibmvnic: Fix EOI when running in XIVE mode.”) since that has the unintended effect of changing the interrupt priority and emits warning when running in legacy XICS mode. Signed-off-by: Juliet Kim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-20Merge branch 'page_pool-DMA-sync'David S. Miller3-17/+67
Lorenzo Bianconi says: ==================== add DMA-sync-for-device capability to page_pool API Introduce the possibility to sync DMA memory for device in the page_pool API. This feature allows to sync proper DMA size and not always full buffer (dma_sync_single_for_device can be very costly). Please note DMA-sync-for-CPU is still device driver responsibility. Relying on page_pool DMA sync mvneta driver improves XDP_DROP pps of about 170Kpps: - XDP_DROP DMA sync managed by mvneta driver: ~420Kpps - XDP_DROP DMA sync managed by page_pool API: ~585Kpps Do not change naming convention for the moment since the changes will hit other drivers as well. I will address it in another series. Changes since v4: - do not allow the driver to set max_len to 0 - convert PP_FLAG_DMA_MAP/PP_FLAG_DMA_SYNC_DEV to BIT() macro Changes since v3: - move dma_sync_for_device before putting the page in ptr_ring in __page_pool_recycle_into_ring since ptr_ring can be consumed concurrently. Simplify the code moving dma_sync_for_device before running __page_pool_recycle_direct/__page_pool_recycle_into_ring Changes since v2: - rely on PP_FLAG_DMA_SYNC_DEV flag instead of dma_sync Changes since v1: - rename sync in dma_sync - set dma_sync_size to 0xFFFFFFFF in page_pool_recycle_direct and page_pool_put_page routines - Improve documentation ==================== Acked-by: Ilias Apalodimas <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.