summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-11-12devlink: Allow large formatted message of binary outputAya Levin
Devlink supports pair output of name and value. When the value is binary, it must be presented in an array. If the length of the binary value exceeds fmsg limitation, break the value into chunks internally. Signed-off-by: Aya Levin <ayal@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12net: sfp: fix sfp_bus_add_upstream() warningRussell King
When building with SFP disabled, the stub for sfp_bus_add_upstream() missed "inline". Add it. Fixes: 727b3668b730 ("net: sfp: rework upstream interface") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12cxgb4: make function 'cxgb4_mqprio_free_hw_resources' staticzhengbin
Fix sparse warnings: drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c:242:6: warning: symbol 'cxgb4_mqprio_free_hw_resources' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 2d0cb84dd973 ("cxgb4: add ETHOFLD hardware queue support") Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12Merge branch 'atlantic-static'David S. Miller
zhengbin says: ==================== net: atlantic: make some symbol & function static v1->v2: add Fixes tag ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12net: atlantic: make function 'aq_ethtool_get_priv_flags', ↵zhengbin
'aq_ethtool_set_priv_flags' static Fix sparse warnings: drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c:706:5: warning: symbol 'aq_ethtool_get_priv_flags' was not declared. Should it be static? drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c:713:5: warning: symbol 'aq_ethtool_set_priv_flags' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: ea4b4d7fc106 ("net: atlantic: loopback tests via private flags") Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12net: atlantic: make symbol 'aq_pm_ops' staticzhengbin
Fix sparse warnings: drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c:426:25: warning: symbol 'aq_pm_ops' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 8aaa112a57c1 ("net: atlantic: refactoring pm logic") Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12Merge branch 'mlxsw-Add-extended-ACK-for-EMADs'David S. Miller
Ido Schimmel says: ==================== mlxsw: Add extended ACK for EMADs Shalom says: Ethernet Management Datagrams (EMADs) are Ethernet packets sent between the driver and device's firmware. They are used to pass various configurations to the device, but also to get events (e.g., port up) from it. After the Ethernet header, these packets are built in a TLV format. Up until now, whenever the driver issued an erroneous register access it only got an error code indicating a bad parameter was used. This patch set adds a new TLV (string TLV) that can be used by the firmware to encode a 128 character string describing the error. The new TLV is allocated by the driver and set to zeros. In case of error, the driver will check the length of the string in the response and report it using devlink hwerr tracepoint. Example: $ perf record -a -q -e devlink:devlink_hwerr & $ pkill -2 perf $ perf script -F trace:event,trace | grep hwerr devlink:devlink_hwerr: bus_name=pci dev_name=0000:03:00.0 driver_name=mlxsw_spectrum err=7 (tid=9913892d00001593,reg_id=8018(rauhtd)) bad parameter (inside er_rauhtd_write_query(), num_rec=32 is over the maximum number of records supported) Patch #1 parses the offsets of the different TLVs in incoming EMADs and stores them in the skb's control block. This makes it easier to later add new TLVs. Patches #2-#3 remove deprecated TLVs and add string TLV definition. Patches #4-#7 gradually add support for the new string TLV. v2: * Use existing devlink hwerr tracepoint to report the error string, instead of printing it to kernel log ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12mlxsw: spectrum: Enable EMAD string TLVShalom Toledo
Make sure to enable EMAD string TLV only after using the required firmware version. Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12mlxsw: core: Add support for using EMAD string TLVShalom Toledo
In case the firmware had an error while processing EMADs, it can send back an ASCII string with the reason using EMAD string TLV. This patch adds the support for using EMAD string TLV. In case of an error, reports the reason using devlink hwerr tracepoint. Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12mlxsw: core: Extend EMAD information reported to devlink hwerrShalom Toledo
Extend EMAD information reported to devlink hwerr tracepoint with transaction id and reg id (both, hex and string). Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12mlxsw: core: Add support for EMAD string TLV parsingShalom Toledo
During parsing of incoming EMADs, fill the string TLV's offset when it is used. Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12mlxsw: core: Add EMAD string TLVShalom Toledo
Add EMAD string TLV, an ASCII string the driver can receive from the firmware in case of an error. Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12mlxsw: emad: Remove deprecated EMAD TLVsShalom Toledo
Remove deprecated EMAD TLVs. Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12mlxsw: core: Parse TLVs' offsets of incoming EMADsShalom Toledo
Until now the code assumes a fixed structure which makes it difficult to support EMADs with and without new TLVs. Make it more generic by parsing the TLVs when the EMADs are received and store the offset to the different TLVs in the control block. Using these offsets to extract information from the EMADs without relying on a specific structure. Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12Merge branch 'x86-pti-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 TSX Async Abort and iTLB Multihit mitigations from Thomas Gleixner: "The performance deterioration departement is not proud at all of presenting the seventh installment of speculation mitigations and hardware misfeature workarounds: 1) TSX Async Abort (TAA) - 'The Annoying Affair' TAA is a hardware vulnerability that allows unprivileged speculative access to data which is available in various CPU internal buffers by using asynchronous aborts within an Intel TSX transactional region. The mitigation depends on a microcode update providing a new MSR which allows to disable TSX in the CPU. CPUs which have no microcode update can be mitigated by disabling TSX in the BIOS if the BIOS provides a tunable. Newer CPUs will have a bit set which indicates that the CPU is not vulnerable, but the MSR to disable TSX will be available nevertheless as it is an architected MSR. That means the kernel provides the ability to disable TSX on the kernel command line, which is useful as TSX is a truly useful mechanism to accelerate side channel attacks of all sorts. 2) iITLB Multihit (NX) - 'No eXcuses' iTLB Multihit is an erratum where some Intel processors may incur a machine check error, possibly resulting in an unrecoverable CPU lockup, when an instruction fetch hits multiple entries in the instruction TLB. This can occur when the page size is changed along with either the physical address or cache type. A malicious guest running on a virtualized system can exploit this erratum to perform a denial of service attack. The workaround is that KVM marks huge pages in the extended page tables as not executable (NX). If the guest attempts to execute in such a page, the page is broken down into 4k pages which are marked executable. The workaround comes with a mechanism to recover these shattered huge pages over time. Both issues come with full documentation in the hardware vulnerabilities section of the Linux kernel user's and administrator's guide. Thanks to all patch authors and reviewers who had the extraordinary priviledge to be exposed to this nuisance. Special thanks to Borislav Petkov for polishing the final TAA patch set and to Paolo Bonzini for shepherding the KVM iTLB workarounds and providing also the backports to stable kernels for those!" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/speculation/taa: Fix printing of TAA_MSG_SMT on IBRS_ALL CPUs Documentation: Add ITLB_MULTIHIT documentation kvm: x86: mmu: Recovery of shattered NX large pages kvm: Add helper function for creating VM worker threads kvm: mmu: ITLB_MULTIHIT mitigation cpu/speculation: Uninline and export CPU mitigations helpers x86/cpu: Add Tremont to the cpu vulnerability whitelist x86/bugs: Add ITLB_MULTIHIT bug infrastructure x86/tsx: Add config options to set tsx=on|off|auto x86/speculation/taa: Add documentation for TSX Async Abort x86/tsx: Add "auto" option to the tsx= cmdline parameter kvm/x86: Export MDS_NO=0 to guests when TSX is enabled x86/speculation/taa: Add sysfs reporting for TSX Async Abort x86/speculation/taa: Add mitigation for TSX Async Abort x86/cpu: Add a "tsx=" cmdline option with TSX disabled by default x86/cpu: Add a helper function x86_read_arch_cap_msr() x86/msr: Add the IA32_TSX_CTRL MSR
2019-11-12net: ethernet: ti: Add dependency for TI_DAVINCI_EMACMao Wenan
If TI_DAVINCI_EMAC=y and GENERIC_ALLOCATOR is not set, below erros can be seen: drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_desc_pool_destroy.isra.14': davinci_cpdma.c:(.text+0x359): undefined reference to `gen_pool_size' davinci_cpdma.c:(.text+0x365): undefined reference to `gen_pool_avail' davinci_cpdma.c:(.text+0x373): undefined reference to `gen_pool_avail' davinci_cpdma.c:(.text+0x37f): undefined reference to `gen_pool_size' drivers/net/ethernet/ti/davinci_cpdma.o: In function `__cpdma_chan_free': davinci_cpdma.c:(.text+0x4a2): undefined reference to `gen_pool_free_owner' drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_chan_submit_si': davinci_cpdma.c:(.text+0x66c): undefined reference to `gen_pool_alloc_algo_owner' davinci_cpdma.c:(.text+0x805): undefined reference to `gen_pool_free_owner' drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_ctlr_create': davinci_cpdma.c:(.text+0xabd): undefined reference to `devm_gen_pool_create' davinci_cpdma.c:(.text+0xb79): undefined reference to `gen_pool_add_owner' drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_check_free_tx_desc': davinci_cpdma.c:(.text+0x16c6): undefined reference to `gen_pool_avail' This patch mades TI_DAVINCI_EMAC select GENERIC_ALLOCATOR. Fixes: 99f629718272 ("net: ethernet: ti: cpsw: drop TI_DAVINCI_CPDMA config option") Signed-off-by: Mao Wenan <maowenan@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-12x86/quirks: Disable HPET on Intel Coffe Lake platformsKai-Heng Feng
Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered PC10, which in consequence marks TSC as unstable because HPET is used as watchdog clocksource for TSC. Harry Pan tried to work around it in the clocksource watchdog code [1] thereby creating a circular dependency between HPET and TSC. This also ignores the fact, that HPET is not only unsuitable as watchdog clocksource on these systems, it becomes unusable in general. Disable HPET on affected platforms. Suggested-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203183 Link: https://lore.kernel.org/lkml/20190516090651.1396-1-harry.pan@intel.com/ [1] Link: https://lkml.kernel.org/r/20191016103816.30650-1-kai.heng.feng@canonical.com
2019-11-12block: check bi_size overflow before mergeJunichi Nomura
__bio_try_merge_page() may merge a page to bio without bio_full() check and cause bi_size overflow. The overflow typically ends up with sd_init_command() warning on zero segment request with call trace like this: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1986 at drivers/scsi/scsi_lib.c:1025 scsi_init_io+0x156/0x180 CPU: 2 PID: 1986 Comm: kworker/2:1H Kdump: loaded Not tainted 5.4.0-rc7 #1 Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:scsi_init_io+0x156/0x180 RSP: 0018:ffffa11487663bf0 EFLAGS: 00010246 RAX: 00000000002be0a0 RBX: ffff8e6e9ff30118 RCX: 0000000000000000 RDX: 00000000ffffffe1 RSI: 0000000000000000 RDI: ffff8e6e9ff30118 RBP: ffffa11487663c18 R08: ffffa11487663d28 R09: ffff8e6e9ff30150 R10: 0000000000000001 R11: 0000000000000000 R12: ffff8e6e9ff30000 R13: 0000000000000001 R14: ffff8e74a1cf1800 R15: ffff8e6e9ff30000 FS: 0000000000000000(0000) GS:ffff8e6ea7680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff18cf0fe8 CR3: 0000000659f0a001 CR4: 00000000001606e0 Call Trace: sd_init_command+0x326/0xb40 [sd_mod] scsi_queue_rq+0x502/0xaa0 ? blk_mq_get_driver_tag+0xe7/0x120 blk_mq_dispatch_rq_list+0x256/0x5a0 ? elv_rb_del+0x24/0x30 ? deadline_remove_request+0x7b/0xc0 blk_mq_do_dispatch_sched+0xa3/0x140 blk_mq_sched_dispatch_requests+0xfb/0x170 __blk_mq_run_hw_queue+0x81/0x130 blk_mq_run_work_fn+0x1b/0x20 process_one_work+0x179/0x390 worker_thread+0x4f/0x3e0 kthread+0x105/0x140 ? max_active_store+0x80/0x80 ? kthread_bind+0x20/0x20 ret_from_fork+0x35/0x40 ---[ end trace f9036abf5af4a4d3 ]--- blk_update_request: I/O error, dev sdd, sector 2875552 op 0x1:(WRITE) flags 0x0 phys_seg 0 prio class 0 XFS (sdd1): writeback error on sector 2875552 __bio_try_merge_page() should check the overflow before actually doing merge. Fixes: 07173c3ec276c ("block: enable multipage bvecs") Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-11-12gpio: bd70528: Use correct unit for debounce timesThierry Reding
The debounce time passed to gpiod_set_debounce() is specified in microseconds, so make sure to use the correct unit when computing the register values, which denote delays in milliseconds. Signed-off-by: Thierry Reding <treding@nvidia.com> Cc: <stable@vger.kernel.org> Fixes: 18bc64b3aebf ("gpio: Initial support for ROHM bd70528 GPIO block") [Bartosz: fixed a typo in commit message] Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2019-11-12gpio: max77620: Fixup debounce delaysThierry Reding
When converting milliseconds to microseconds in commit fffa6af94894 ("gpio: max77620: Use correct unit for debounce times") some ~1 ms gaps were introduced between the various ranges supported by the controller. Fix this by changing the start of each range to the value immediately following the end of the previous range. This way a debounce time of, say 8250 us will translate into 16 ms instead of returning an -EINVAL error. Typically the debounce delay is only ever set through device tree and specified in milliseconds, so we can never really hit this issue because debounce times are always a multiple of 1000 us. The only notable exception for this is drivers/mmc/host/mmc-spi.c where the CD GPIO is requested, which passes a 1 us debounce time. According to a comment preceeding that code this should actually be 1 ms (i.e. 1000 us). Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Pavel Machek <pavel@denx.de> Cc: <stable@vger.kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2019-11-12KVM: MMU: Do not treat ZONE_DEVICE pages as being reservedSean Christopherson
Explicitly exempt ZONE_DEVICE pages from kvm_is_reserved_pfn() and instead manually handle ZONE_DEVICE on a case-by-case basis. For things like page refcounts, KVM needs to treat ZONE_DEVICE pages like normal pages, e.g. put pages grabbed via gup(). But for flows such as setting A/D bits or shifting refcounts for transparent huge pages, KVM needs to to avoid processing ZONE_DEVICE pages as the flows in question lack the underlying machinery for proper handling of ZONE_DEVICE pages. This fixes a hang reported by Adam Borowski[*] in dev_pagemap_cleanup() when running a KVM guest backed with /dev/dax memory, as KVM straight up doesn't put any references to ZONE_DEVICE pages acquired by gup(). Note, Dan Williams proposed an alternative solution of doing put_page() on ZONE_DEVICE pages immediately after gup() in order to simplify the auditing needed to ensure is_zone_device_page() is called if and only if the backing device is pinned (via gup()). But that approach would break kvm_vcpu_{un}map() as KVM requires the page to be pinned from map() 'til unmap() when accessing guest memory, unlike KVM's secondary MMU, which coordinates with mmu_notifier invalidations to avoid creating stale page references, i.e. doesn't rely on pages being pinned. [*] http://lkml.kernel.org/r/20190919115547.GA17963@angband.pl Reported-by: Adam Borowski <kilobyte@angband.pl> Analyzed-by: David Hildenbrand <david@redhat.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Cc: stable@vger.kernel.org Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-12KVM: VMX: Introduce pi_is_pir_empty() helperJoao Martins
Streamline the PID.PIR check and change its call sites to use the newly added helper. Suggested-by: Liran Alon <liran.alon@oracle.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-12KVM: VMX: Do not change PID.NDST when loading a blocked vCPUJoao Martins
When vCPU enters block phase, pi_pre_block() inserts vCPU to a per pCPU linked list of all vCPUs that are blocked on this pCPU. Afterwards, it changes PID.NV to POSTED_INTR_WAKEUP_VECTOR which its handler (wakeup_handler()) is responsible to kick (unblock) any vCPU on that linked list that now has pending posted interrupts. While vCPU is blocked (in kvm_vcpu_block()), it may be preempted which will cause vmx_vcpu_pi_put() to set PID.SN. If later the vCPU will be scheduled to run on a different pCPU, vmx_vcpu_pi_load() will clear PID.SN but will also *overwrite PID.NDST to this different pCPU*. Instead of keeping it with original pCPU which vCPU had entered block phase on. This results in an issue because when a posted interrupt is delivered, as the wakeup_handler() will be executed and fail to find blocked vCPU on its per pCPU linked list of all vCPUs that are blocked on this pCPU. Which is due to the vCPU being placed on a *different* per pCPU linked list i.e. the original pCPU in which it entered block phase. The regression is introduced by commit c112b5f50232 ("KVM: x86: Recompute PID.ON when clearing PID.SN"). Therefore, partially revert it and reintroduce the condition in vmx_vcpu_pi_load() responsible for avoiding changing PID.NDST when loading a blocked vCPU. Fixes: c112b5f50232 ("KVM: x86: Recompute PID.ON when clearing PID.SN") Tested-by: Nathan Ni <nathan.ni@oracle.com> Co-developed-by: Liran Alon <liran.alon@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-12KVM: VMX: Consider PID.PIR to determine if vCPU has pending interruptsJoao Martins
Commit 17e433b54393 ("KVM: Fix leak vCPU's VMCS value into other pCPU") introduced vmx_dy_apicv_has_pending_interrupt() in order to determine if a vCPU have a pending posted interrupt. This routine is used by kvm_vcpu_on_spin() when searching for a a new runnable vCPU to schedule on pCPU instead of a vCPU doing busy loop. vmx_dy_apicv_has_pending_interrupt() determines if a vCPU has a pending posted interrupt solely based on PID.ON. However, when a vCPU is preempted, vmx_vcpu_pi_put() sets PID.SN which cause raised posted interrupts to only set bit in PID.PIR without setting PID.ON (and without sending notification vector), as depicted in VT-d manual section 5.2.3 "Interrupt-Posting Hardware Operation". Therefore, checking PID.ON is insufficient to determine if a vCPU has pending posted interrupts and instead we should also check if there is some bit set on PID.PIR if PID.SN=1. Fixes: 17e433b54393 ("KVM: Fix leak vCPU's VMCS value into other pCPU") Reviewed-by: Jagannathan Raman <jag.raman@oracle.com> Co-developed-by: Liran Alon <liran.alon@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-12KVM: VMX: Fix comment to specify PID.ON instead of PIR.ONLiran Alon
The Outstanding Notification (ON) bit is part of the Posted Interrupt Descriptor (PID) as opposed to the Posted Interrupts Register (PIR). The latter is a bitmap for pending vectors. Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-12KVM: X86: Fix initialization of MSR listsChenyi Qiang
The three MSR lists(msrs_to_save[], emulated_msrs[] and msr_based_features[]) are global arrays of kvm.ko, which are adjusted (copy supported MSRs forward to override the unsupported MSRs) when insmod kvm-{intel,amd}.ko, but it doesn't reset these three arrays to their initial value when rmmod kvm-{intel,amd}.ko. Thus, at the next installation, kvm-{intel,amd}.ko will do operations on the modified arrays with some MSRs lost and some MSRs duplicated. So define three constant arrays to hold the initial MSR lists and initialize msrs_to_save[], emulated_msrs[] and msr_based_features[] based on the constant arrays. Cc: stable@vger.kernel.org Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> [Remove now useless conditionals. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-12xfrm: release device reference for invalid stateXiaodong Xu
An ESP packet could be decrypted in async mode if the input handler for this packet returns -EINPROGRESS in xfrm_input(). At this moment the device reference in skb is held. Later xfrm_input() will be invoked again to resume the processing. If the transform state is still valid it would continue to release the device reference and there won't be a problem; however if the transform state is not valid when async resumption happens, the packet will be dropped while the device reference is still being held. When the device is deleted for some reason and the reference to this device is not properly released, the kernel will keep logging like: unregister_netdevice: waiting for ppp2 to become free. Usage count = 1 The issue is observed when running IPsec traffic over a PPPoE device based on a bridge interface. By terminating the PPPoE connection on the server end for multiple times, the PPPoE device on the client side will eventually get stuck on the above warning message. This patch will check the async mode first and continue to release device reference in async resumption, before it is dropped due to invalid state. v2: Do not assign address family from outer_mode in the transform if the state is invalid v3: Release device reference in the error path instead of jumping to resume Fixes: 4ce3dbe397d7b ("xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)") Signed-off-by: Xiaodong Xu <stid.smth@gmail.com> Reported-by: Bo Chen <chenborfc@163.com> Tested-by: Bo Chen <chenborfc@163.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2019-11-12io_uring: make timeout sequence == 0 mean no sequenceJens Axboe
Currently we make sequence == 0 be the same as sequence == 1, but that's not super useful if the intent is really to have a timeout that's just a pure timeout. If the user passes in sqe->off == 0, then don't apply any sequence logic to the request, let it purely be driven by the timeout specified. Reported-by: 李通洲 <carter.li@eoitek.com> Reviewed-by: 李通洲 <carter.li@eoitek.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-11-12ntp/y2038: Remove incorrect time_t truncationArnd Bergmann
A cast to 'time_t' was accidentally left in place during the conversion of __do_adjtimex() to 64-bit timestamps, so the resulting value is incorrectly truncated. Remove the cast so the 64-bit time gets propagated correctly. Fixes: ead25417f82e ("timex: use __kernel_timex internally") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20191108203435.112759-2-arnd@arndb.de
2019-11-11Merge branch 'stmmac-next'David S. Miller
Jose Abreu says: ==================== net: stmmac: Improvements for -next Misc improvements for stmmac. Patch 1/6, fixes a sparse warning that was introduced in recent commit in -next. Patch 2/6, adds the Split Header support which is also available in XGMAC cores and now in GMAC4+ with this patch. Patch 3/6, adds the C45 support for MDIO transactions when using XGMAC cores. Patch 4/6, removes the speed dependency on CBS callbacks so that it can be used in XGMAC cores. Patch 5/6, reworks the over-engineered stmmac_rx() function so that its easier to read. Patch 6/6, implements the UDP Segmentation Offload feature in GMAC4+ cores. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: stmmac: Implement UDP Segmentation OffloadJose Abreu
Implement the UDP Segmentation Offload feature in stmmac. This is only available in GMAC4+ cores. Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: stmmac: Rework stmmac_rx()Jose Abreu
This looks over-engineered. Let's use some helpers to get the buffer length and hereby simplify the stmmac_rx() function. No performance drop was seen with the new implementation. Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: stmmac: tc: Remove the speed dependencyJose Abreu
XGMAC3 supports full CBS features with speeds that can go up to 10G so we can now remove the maximum speed check of CBS. Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: stmmac: xgmac: Add C45 PHY support in the MDIO callbacksJose Abreu
Add the support for C45 PHYs in the MDIO callbacks for XGMAC. This was tested using Synopsys DesignWare XPCS. v2: - Pull out the readl_poll_timeout() calls into common code (Andrew) Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: stmmac: gmac4+: Add Split Header supportJose Abreu
GMAC4+ cores also support the Split Header feature. Add the support for Split Header feature in the RX path following the same implementation logic that XGMAC followed. Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: stmmac: Fix sparse warningJose Abreu
The VID is converted to le16 so the variable must be __le16 type. Reported-by: kbuild test robot <lkp@intel.com> Fixes: c7ab0b8088d7 ("net: stmmac: Fallback to VLAN Perfect filtering if HASH is not available") Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11cxgb4: remove redundant assignment to hdr_lenColin Ian King
Variable hdr_len is being assigned a value that is never read. The assignment is redundant and hence can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11tipc: fix update of the uninitialized variable errColin Ian King
Variable err is not uninitialized and hence can potentially contain any garbage value. This may cause an error when logical or'ing the return values from the calls to functions crypto_aead_setauthsize or crypto_aead_setkey. Fix this by setting err to the return of crypto_aead_setauthsize rather than or'ing in the return into the uninitialized variable Addresses-Coverity: ("Uninitialized scalar variable") Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11Documentation: networking: dpaa_eth: adjust sysfs pathsMadalin Bucur
The sysfs paths changed, updating to the current ones. Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11Documentation: networking: dpaa_eth: adjust buffer pool infoMadalin Bucur
Recent changes in the dpaa_eth driver reduced the number of buffer pools per interface from three to one. Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11mdio_bus: Fix PTR_ERR applied after initialization to constantYueHaibing
Fix coccinelle warning: ./drivers/net/phy/mdio_bus.c:67:5-12: ERROR: PTR_ERR applied after initialization to constant on line 62 ./drivers/net/phy/mdio_bus.c:68:5-12: ERROR: PTR_ERR applied after initialization to constant on line 62 Fix this by using IS_ERR before PTR_ERR Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 71dd6c0dff51 ("net: phy: add support for reset-controller") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11samples/bpf: adjust Makefile and README.rstJesper Dangaard Brouer
Side effect of some kbuild changes resulted in breaking the documented way to build samples/bpf/. This patch change the samples/bpf/Makefile to work again, when invoking make from the subdir samples/bpf/. Also update the documentation in README.rst, to reflect the new way to build. Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11NFC: nxp-nci: Fix NULL pointer dereference after I2C communication errorStephan Gerhold
I2C communication errors (-EREMOTEIO) during the IRQ handler of nxp-nci result in a NULL pointer dereference at the moment: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 355 Comm: irq/137-nxp-nci Not tainted 5.4.0-rc6 #1 RIP: 0010:skb_queue_tail+0x25/0x50 Call Trace: nci_recv_frame+0x36/0x90 [nci] nxp_nci_i2c_irq_thread_fn+0xd1/0x285 [nxp_nci_i2c] ? preempt_count_add+0x68/0xa0 ? irq_forced_thread_fn+0x80/0x80 irq_thread_fn+0x20/0x60 irq_thread+0xee/0x180 ? wake_threads_waitq+0x30/0x30 kthread+0xfb/0x130 ? irq_thread_check_affinity+0xd0/0xd0 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x40 Afterward the kernel must be rebooted to work properly again. This happens because it attempts to call nci_recv_frame() with skb == NULL. However, unlike nxp_nci_fw_recv_frame(), nci_recv_frame() does not have any NULL checks for skb, causing the NULL pointer dereference. Change the code to call only nxp_nci_fw_recv_frame() in case of an error. Make sure to log it so it is obvious that a communication error occurred. The error above then becomes: nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121 nci: __nci_request: wait_for_completion_interruptible_timeout failed 0 nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121 Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11mlxsw: core: Enable devlink reload only on probeJiri Pirko
Call devlink enable only during probe time and avoid deadlock during reload. Reported-by: Shalom Toledo <shalomt@mellanox.com> Fixes: a0c76345e3d3 ("devlink: disallow reload operation during device cleanup") Signed-off-by: Jiri Pirko <jiri@mellanox.com> Tested-by: Shalom Toledo <shalomt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11mlxsw: core: Enable devlink reload only on probeJiri Pirko
Call devlink enable only during probe time and avoid deadlock during reload. Reported-by: Shalom Toledo <shalomt@mellanox.com> Fixes: 5a508a254bed ("devlink: disallow reload operation during device cleanup") Signed-off-by: Jiri Pirko <jiri@mellanox.com> Tested-by: Shalom Toledo <shalomt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11r8169: add support for RTL8117Heiner Kallweit
Add support for chip version RTL8117. Settings have been copied from Realtek's r8168 driver, there however chip ID 54a belongs to a chip version called RTL8168FP. It was confirmed that RTL8117 works with Realtek's driver, so both chip versions seem to be the same or at least compatible. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11Merge Intel Gen8/Gen9 graphics fixes from Jon Bloomfield.Linus Torvalds
This fixes two different classes of bugs in the Intel graphics hardware: MMIO register read hang: "On Intels Gen8 and Gen9 Graphics hardware, a read of specific graphics MMIO registers when the product is in certain low power states causes a system hang. There are two potential triggers for DoS: a) H/W corruption of the RC6 save/restore vector b) Hard hang within the MIPI hardware This prevents the DoS in two areas of the hardware: 1) Detect corruption of RC6 address on exit from low-power state, and if we find it corrupted, disable RC6 and RPM 2) Permanently lower the MIPI MMIO timeout" Blitter command streamer unrestricted memory accesses: "On Intels Gen9 Graphics hardware the Blitter Command Streamer (BCS) allows writing to Memory Mapped Input Output (MMIO) that should be blocked. With modifications of page tables, this can lead to privilege escalation. This exposure is limited to the Guest Physical Address space and does not allow for access outside of the graphics virtual machine. This series establishes a software parser into the Blitter command stream to scan for, and prevent, reads or writes to MMIO's that should not be accessible to non-privileged contexts. Much of the command parser infrastructure has existed for some time, and is used on Ivybridge/Haswell/Valleyview derived products to allow the use of features normally blocked by hardware. In this legacy context, the command parser is employed to allow normally unprivileged submissions to be run with elevated privileges in order to grant access to a limited set of extra capabilities. In this mode the parser is optional; In the event that the parser finds any construct that it cannot properly validate (e.g. nested command buffers), it simply aborts the scan and submits the buffer in non-privileged mode. For Gen9 Graphics, this series makes the parser mandatory for all Blitter submissions. The incoming user buffer is first copied to a kernel owned buffer, and parsed. If all checks are successful the kernel owned buffer is mapped READ-ONLY and submitted on behalf of the user. If any checks fail, or the parser is unable to complete the scan (nested buffers), it is forcibly rejected. The successfully scanned buffer is executed with NORMAL user privileges (key difference from legacy usage). Modern usermode does not use the Blitter on later hardware, having switched over to using the 3D engine instead for performance reasons. There are however some legacy usermode apps that rely on Blitter, notably the SNA X-Server. There are no known usermode applications that require nested command buffers on the Blitter, so the forcible rejection of such buffers in this patch series is considered an acceptable limitation" * Intel graphics fixes in emailed bundle from Jon Bloomfield <jon.bloomfield@intel.com>: drm/i915/cmdparser: Fix jump whitelist clearing drm/i915/gen8+: Add RC6 CTX corruption WA drm/i915: Lower RM timeout to avoid DSI hard hangs drm/i915/cmdparser: Ignore Length operands during command matching drm/i915/cmdparser: Add support for backward jumps drm/i915/cmdparser: Use explicit goto for error paths drm/i915: Add gen9 BCS cmdparsing drm/i915: Allow parsing of unsized batches drm/i915: Support ro ppgtt mapped cmdparser shadow buffers drm/i915: Add support for mandatory cmdparsing drm/i915: Remove Master tables from cmdparser drm/i915: Disable Secure Batches for gen6+ drm/i915: Rename gen7 cmdparser tables
2019-11-11Merge branch 'sfp-Allow-slow-to-initialise-GPON-modules-to-work'David S. Miller
Russell King says: ==================== sfp: Allow slow to initialise GPON modules to work Some GPON modules take longer than the SFF MSA specified time to initialise and respond to transactions on the I2C bus for either both 0x50 and 0x51, or 0x51 bus addresses. Technically these modules are non-compliant with the SFP Multi-Source Agreement, they have been around for some time, so are difficult to just ignore. Most of the patch series is restructuring the code to make it more readable, and split various things into separate functions. We split the three state machines into three separate functions, and re-arrange them to start probing the module as soon as a module has been detected (without waiting for the network device.) We try to read the module's EEPROM, retrying quickly for the first second, and then once every five seconds for about a minute until we have read the EEPROM. So that the kernel isn't entirely silent, we print a message indicating that we're waiting for the module to respond after the first second, or when all retries have expired. Once the module ID has been read, we kick off a delayed work queue which attempts to register the hwmon, retrying for up to a minute if the monitoring parameters are unreadable; this allows us to proceed with module initialisation independently of the hwmon state. With high-power modules, we wait for the netdev to be attached before switching the module power mode, and retry this in a similar way to before until we have successfully read and written the EEPROM at 0x51. We also move the handling of the TX_DISABLE signal entirely to the main state machine, and avoid probing any on-board PHY while TX_FAULT is set. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: allow modules with slow diagnostics to probeRussell King
When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: allow sfp to probe slow to initialise GPON modulesRussell King
Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-23 11:32:48 +0000