- 04 Nov, 2018 40 commits
-
-
Daniel Mack authored
[ Upstream commit 4f666675 ] When powering down a SDIO connected card during suspend, make sure to call into the generic lbs_suspend() function before pulling the plug. This will make sure the card is successfully deregistered from the system to avoid communication to the card starving out. Fixes: 7444a809 ("libertas: fix suspend and resume for SDIO connected cards") Signed-off-by:
Daniel Mack <daniel@zonque.org> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Acked-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Masahiro Yamada authored
[ Upstream commit 56869d45 ] The rule of mainmenu_stmt does not have debug print of zconf_lineno(), but if it had, it would print a wrong line number for the same reason as commit b2d00d7c ("kconfig: fix line numbers for if-entries in menu tree"). The mainmenu_stmt does not need to eat following empty lines because they are reduced to common_stmt. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 81a8b079 ] The newly added suspend/resume functions cause a build warning when CONFIG_PM is disabled: drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:324:12: error: 'stmmac_pci_resume' defined but not used [-Werror=unused-function] drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:306:12: error: 'stmmac_pci_suspend' defined but not used [-Werror=unused-function] Mark them as __maybe_unused so gcc can drop them silently. Fixes: b7d0f08e ("net: stmmac: Fix WoL for PCI-based setups") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 571d0563 ] The first argument to WARN_ONCE() is a condition. Fixes: 5800dc5c ("x86/paravirt: Fix spectre-v2 mitigations for paravirt guests") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Juergen Gross <jgross@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Alok Kataria <akataria@vmware.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: virtualization@lists.linux-foundation.org Cc: kernel-janitors@vger.kernel.org Link: https://lkml.kernel.org/r/20180919103553.GD9238@mwandaSigned-off-by:
-
Florian Fainelli authored
[ Upstream commit 3bcd4772 ] If CONFIG_GPIOLIB is disabled, gpiod_put() becomes a stub that produces a warning, this helped identify that we could be attempting to release a NULL pl->link_gpio GPIO descriptor, so guard against that. Fixes: daab3349 ("net: phy: phylink: Release link GPIO") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Qu Wenruo authored
[ Upstream commit 6f7de19e ] Commit ff3d27a0 ("btrfs: qgroup: Finish rescan when hit the last leaf of extent tree") added a new exit for rescan finish. However after finishing quota rescan, we set fs_info->qgroup_rescan_progress to (u64)-1 before we exit through the original exit path. While we missed that assignment of (u64)-1 in the new exit path. The end result is, the quota status item doesn't have the same value. (-1 vs the last bytenr + 1) Although it doesn't affect quota accounting, it's still better to keep the original behavior. Reported-by:
Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> Fixes: ff3d27a0 ("btrfs: qgroup: Finish rescan when hit the last leaf of extent tree") Signed-off-by:
Qu Wenruo <wqu@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Martin K. Petersen authored
[ Upstream commit 597d7400 ] The USB storage glue sets the try_rc_10_first flag in an attempt to avoid wedging poorly implemented legacy USB devices. If the device capacity is too large to be expressed in the provided response buffer field of READ CAPACITY(10), a well-behaved device will set the reported capacity to 0xFFFFFFFF. We will then attempt to issue a READ CAPACITY(16) to obtain the real capacity. Since this part of the discovery logic is not covered by the first_scan flag, a warning will be printed a couple of times times per revalidate attempt if we upgrade from READ CAPACITY(10) to READ CAPACITY(16). Remember that we have successfully issued READ CAPACITY(16) so we can take the fast path on subsequent revalidate attempts. Reported-by:
Menion <menion@gmail.com> Reviewed-by:
Laurence Oberman <loberman@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Brian King authored
[ Upstream commit 09dd15e0 ] Following an RSCN, ibmvfc will issue an ADISC to determine if the underlying target has changed, comparing the SCSI ID, WWPN, and WWNN to determine how to handle the rport in discovery. However, the comparison of the WWPN and WWNN was performing a memcmp between a big endian field against a CPU endian field, which resulted in the wrong answer on LE systems. This was observed as unexpected errors getting logged at boot time as targets were getting relogins when not needed. Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
-
Michael Neuling authored
[ Upstream commit 9c2ddfe5 ] This test the ptrace hw breakpoints via PTRACE_SET_DEBUGREG and PPC_PTRACE_SETHWDEBUG. This test was use to find the bugs fixed by these recent commits: 4f7c06e2 powerpc/ptrace: Fix setting 512B aligned breakpoints with PTRACE_SET_DEBUGREG cd6ef7ee powerpc/ptrace: Fix enforcement of DAWR constraints Signed-off-by:
Michael Neuling <mikey@neuling.org> [mpe: Add SPDX tag, clang format it] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Phil Reid authored
[ Upstream commit 92397a6c ] linux/iio/buffer-dma.h was not updated to when length was changed to unsigned int. Fixes: c043ec1c ("iio:buffer: make length types match kfifo types") Signed-off-by:
Phil Reid <preid@electromag.com.au> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Govindarajulu Varadarajan authored
[ Upstream commit 56f77227 ] In failure path, we overwrite err to what vnic_rq_disable() returns. In case it returns 0, enic_open() returns success in case of error. Reported-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Fixes: e8588e26 ("enic: enable rq before updating rq descriptors") Signed-off-by:
Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by:
-
Phil Elwell authored
[ Upstream commit 47b99865 ] Commit 92571a1a ("lan78xx: Connect phy early") moves the PHY initialisation into lan78xx_probe, but lan78xx_open subsequently calls lan78xx_reset. As well as forcing a second round of link negotiation, this reset frequently prevents the phy interrupt from being generated (even though the link is up), rendering the interface unusable. Fix this issue by removing the lan78xx_reset call from lan78xx_open. Fixes: 92571a1a ("lan78xx: Connect phy early") Signed-off-by:
Phil Elwell <phil@raspberrypi.org> Signed-off-by:
-
Paul Burton authored
[ Upstream commit 906d441f ] Some versions of GCC for the MIPS architecture suffer from a bug which can lead to instructions from beyond an unreachable statement being incorrectly reordered into earlier branch delay slots if the unreachable statement is the only content of a case in a switch statement. This can lead to seemingly random behaviour, such as invalid memory accesses from incorrectly reordered loads or stores, and link failures on microMIPS builds. See this potential GCC fix for details: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html Runtime problems resulting from this bug were initially observed using a maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape SDK 2015.06-05 toolchain), with the result being an address exception taken after log messages about the L1 caches (during probe of the L2 cache): Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff] VPE topology {2,2} total 4 Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes <AdEL exception here> This is early enough that the kernel exception vectors are not in use, so any further output depends upon the bootloader. This is reproducible in QEMU where no further output occurs - ie. the system hangs here. Given the nature of the bug it may potentially be hit with differing symptoms. The bug is known to affect GCC versions as recent as 7.3, and it is unclear whether GCC 8 fixed it or just happens not to encounter the bug in the testcase found at the link above due to differing optimizations. This bug can be worked around by placing a volatile asm statement, which GCC is prevented from reordering past, prior to the __builtin_unreachable call. That was actually done already for other reasons by commit 173a3efd ("bug.h: work around GCC PR82365 in BUG()"), but creates problems for microMIPS builds due to the lack of a .insn directive. The microMIPS ISA allows for interlinking with regular MIPS32 code by repurposing bit 0 of the program counter as an ISA mode bit. To switch modes one changes the value of this bit in the PC. However typical branch instructions encode their offsets as multiples of 2-byte instruction halfwords, which means they cannot change ISA mode - this must be done using either an indirect branch (a jump-register in MIPS terminology) or a dedicated jalx instruction. In order to ensure that regular branches don't attempt to target code in a different ISA which they can't actually switch to, the linker will check that branch targets are code in the same ISA as the branch. Unfortunately our empty asm volatile statements don't qualify as code, and the link for microMIPS builds fails with errors such as: arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA mode arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA mode Resolve this by adding a .insn directive within the asm statement which declares that what comes next is code. This may or may not be true, since we don't really know what comes next, but as this code is in an unreachable path anyway that doesn't matter since we won't execute it. We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in order to have this included by linux/compiler_types.h after linux/compiler-gcc.h. This will result in asm/compiler.h being included in all C compilations via the -include linux/compiler_types.h argument in c_flags, which should be harmless. Signed-off-by:
Paul Burton <paul.burton@mips.com> Fixes: 173a3efd ("bug.h: work around GCC PR82365 in BUG()") Patchwork: https://patchwork.linux-mips.org/patch/20270/ Cc: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: linux-mips@linux-mips.org Signed-off-by:
-
John Keeping authored
[ Upstream commit e988867f ] Following up the device tree fixed in commits e78c6371 ("ARM: dts: rockchip: Fix DWMMC clocks") and ca9eee95 ("arm64: dts: rockchip: Fix DWMMC clocks", 2018-02-15), avoid confusion by using the correct property name in the debug output if clocks are not found. Signed-off-by:
John Keeping <john@metanate.com> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
-
Jason Gunthorpe authored
[ Upstream commit 43cbd64b ] usnic has a modified version of the core codes' ib_umem_get() and related, and the copy misses many of the bug fixes done over the years: Commit bc3e53f6 ("mm: distinguish between mlocked and pinned pages") Commit 87773dd5 ("IB: ib_umem_release() should decrement mm->pinned_vm from ib_umem_get") Commit 8494057a ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") Commit 8abaae62 ("IB/core: disallow registering 0-sized memory region") Commit 66578b0b ("IB/core: don't disallow registering region starting at 0x0") Commit 53376fed ("RDMA/core: not to set page dirty bit if it's already set.") Commit 8e907ed4 ("IB/umem: Use the correct mm during ib_umem_release") Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Ross Lagerwall authored
[ Upstream commit cb257783 ] Fixes: f599c64f ("xen-netfront: Fix race between device setup and open") Reported-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by:
-
Ross Lagerwall authored
[ Upstream commit 45c8184c ] Update the features after calling register_netdev() otherwise the device features are not set up correctly and it not possible to change the MTU of the device. After this change, the features reported by ethtool match the device's features before the commit which introduced the issue and it is possible to change the device's MTU. Fixes: f599c64f ("xen-netfront: Fix race between device setup and open") Reported-by:
Liam Shepherd <liam@dancer.es> Signed-off-by:
-
Winkler, Tomas authored
[ Upstream commit 1fbad302 ] In crb_map_io() function, __crb_request_locality() is called prior to crb_cmd_ready(), but if one of the consecutive function fails the flow bails out instead of trying to relinquish locality. This patch adds goto jump to __crb_relinquish_locality() on the error path. Fixes: 888d867d (tpm: cmd_ready command can be issued only after granting locality) Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Tested-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by:
-
John Fastabend authored
[ Upstream commit ba6b8de4 ] Relying on map_release hook to decrement the reference counts when a map is removed only works if the map is not being pinned. In the pinned case the ref is decremented immediately and the BPF programs released. After this BPF programs may not be in-use which is not what the user would expect. This patch moves the release logic into bpf_map_put_uref() and brings sockmap in-line with how a similar case is handled in prog array maps. Fixes: 3d9e9526 ("bpf: sockmap, fix leaking maps with attached but not detached progs") Signed-off-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Nayna Jain authored
[ Upstream commit 92980756 ] Commit e2fb992d ("tpm: add retry logic") introduced a new loop to handle the TPM2_RC_RETRY error. The loop retries the command after sleeping for the specified time, which is incremented exponentially in every iteration. Unfortunately, the loop doubles the time before sleeping, causing the initial sleep to be doubled. This patch fixes the initial sleep time. Fixes: commit e2fb992d ("tpm: add retry logic") Signed-off-by:
Nayna Jain <nayna@linux.vnet.ibm.com> Reviewed-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Tested-by:
-
David S. Miller authored
[ Upstream commit cfb61b5e ] pmdp_invalidate() was changed to update the pmd atomically (to not lose dirty/access bits) and return the original pmd value. However, in doing so, we lost a lot of the essential work that set_pmd_at() does, namely to update hugepage mapping counts and queuing up the batched TLB flush entry. Thus we were not flushing entries out of the TLB when making such PMD changes. Fix this by abstracting the accounting work of set_pmd_at() out into a separate function, and call it from pmdp_establish(). Fixes: a8e654f0 ("sparc64: update pmdp_invalidate() to return old pmd value") Signed-off-by:
-
KarimAllah Ahmed authored
[ Upstream commit ddd6f0e9 ] ... to avoid having a stale value when handling an EPT misconfig for MMIO regions. MMIO regions that are not passed-through to the guest are handled through EPT misconfigs. The first time a certain MMIO page is touched it causes an EPT violation, then KVM marks the EPT entry to cause an EPT misconfig instead. Any subsequent accesses to the entry will generate an EPT misconfig. Things gets slightly complicated with nested guest handling for MMIO regions that are not passed through from L0 (i.e. emulated by L0 user-space). An EPT violation for one of these MMIO regions from L2, exits to L0 hypervisor. L0 would then look at the EPT12 mapping for L1 hypervisor and realize it is not present (or not sufficient to serve the request). Then L0 injects an EPT violation to L1. L1 would then update its EPT mappings. The EXIT_QUALIFICATION value for L1 would come from exit_qualification variable in "struct vcpu". The problem is that this variable is only updated on EPT violation and not on EPT misconfig. So if an EPT violation because of a read happened first, then an EPT misconfig because of a write happened afterwards. The L0 hypervisor will still contain exit_qualification value from the previous read instead of the write and end up injecting an EPT violation to the L1 hypervisor with an out of date EXIT_QUALIFICATION. The EPT violation that is injected from L0 to L1 needs to have the correct EXIT_QUALIFICATION specially for the access bits because the individual access bits for MMIO EPTs are updated only on actual access of this specific type. So for the example above, the L1 hypervisor will keep updating only the read bit in the EPT then resume the L2 guest. The L2 guest would end up causing another exit where the L0 *again* will inject another EPT violation to L1 hypervisor with *again* an out of date exit_qualification which indicates a read and not a write. Then this ping-pong just keeps happening without making any forward progress. The behavior of mapping MMIO regions changed in: commit a340b3e2 ("kvm: Map PFN-type memory regions as writable (if possible)") ... where an EPT violation for a read would also fixup the write bits to avoid another EPT violation which by acciddent would fix the bug mentioned above. This commit fixes this situation and ensures that the access bits for the exit_qualifcation is up to date. That ensures that even L1 hypervisor running with a KVM version before the commit mentioned above would still work. ( The description above assumes EPT to be available and used by L1 hypervisor + the L1 hypervisor is passing through the MMIO region to the L2 guest while this MMIO region is emulated by the L0 user-space ). Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: x86@kernel.org Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
KarimAllah Ahmed <karahmed@amazon.de> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
[ Upstream commit 52fda36d ] Function bpf_fill_maxinsns11 is designed to not be able to be JITed on x86_64. So, it fails when CONFIG_BPF_JIT_ALWAYS_ON=y, and commit 09584b40 ("bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y") makes sure that failure is detected on that case. However, it does not fail on other architectures, which have a different JIT compiler design. So, test_bpf has started to fail to load on those. After this fix, test_bpf loads fine on both x86_64 and ppc64el. Fixes: 09584b40 ("bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y") Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Reviewed-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 3995bbf5 ] On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1): fs/cifs/inode.c: In function ‘simple_hashstr’: fs/cifs/inode.c:713: warning: integer constant is too large for ‘long’ type Fixes: 7ea884c7 ("smb3: Fix root directory when server returns inode number of zero") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> Signed-off-by:
-
James Chapman authored
[ Upstream commit 900631ee ] If L2TP_ATTR_OFFSET is set to a non-zero value in L2TPv3 tunnels, it results in L2TPv3 packets being transmitted which might not be compliant with the L2TPv3 RFC. This patch has l2tp ignore the offset setting and send all packets with no offset. In more detail: L2TPv2 supports a variable offset from the L2TPv2 header to the payload. The offset value is indicated by an optional field in the L2TP header. Our L2TP implementation already detects the presence of the optional offset and skips that many bytes when handling data received packets. All transmitted packets are always transmitted with no offset. L2TPv3 has no optional offset field in the L2TPv3 packet header. Instead, L2TPv3 defines optional fields in a "Layer-2 Specific Sublayer". At the time when the original L2TP code was written, there was talk at IETF of offset being implemented in a new Layer-2 Specific Sublayer. A L2TP_ATTR_OFFSET netlink attribute was added so that this offset could be configured and the intention was to allow it to be also used to set the tx offset for L2TPv2. However, no L2TPv3 offset was ever specified and the L2TP_ATTR_OFFSET parameter was forgotten about. Setting L2TP_ATTR_OFFSET results in L2TPv3 packets being transmitted with the specified number of bytes padding between L2TPv3 header and payload. This is not compliant with L2TPv3 RFC3931. This change removes the configurable offset altogether while retaining L2TP_ATTR_OFFSET for backwards compatibility. Any L2TP_ATTR_OFFSET value is ignored. Signed-off-by:
James Chapman <jchapman@katalix.com> Signed-off-by:
-
Marcel Ziswiler authored
[ Upstream commit 4c9a27a6 ] Since commit f8f8f1d0 ("clk: Don't touch hardware when reparenting during registration") ULPI has been broken on Tegra20 leading to the following error message during boot: [ 1.974698] ulpi_phy_power_on: ulpi write failed [ 1.979384] tegra-ehci c5004000.usb: Failed to power on the phy [ 1.985434] tegra-ehci: probe of c5004000.usb failed with error -110 Debugging through the changes and finally also consulting the TRM revealed that rather than the CDEV2 clock off OSC requiring such pin muxing actually the PLL_P_OUT4 clock is in use. It looks like so far it just worked by chance of that one having been enabled which Stephen's commit now changed when reparenting sclk away from pll_p_out4 leaving that one disabled. Fix this by properly assigning the PLL_P_OUT4 clock as the ULPI PHY clock. Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by:
Dmitry Osipenko <digetx@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Noa Osherovich authored
[ Upstream commit e7b169f3 ] During QP creation, the mlx5 driver translates the QP type to an internal value which is passed on to FW. There was no check to make sure that the translated value is valid, and -EINVAL was coerced into the mailbox command. Current firmware refuses this as an invalid QP type, but future/past firmware may do something else. Fixes: 09a7d9ec ('{net,IB}/mlx5: QP/XRCD commands via mlx5 ifc') Reviewed-by:
Ilya Lesokhin <ilyal@mellanox.com> Signed-off-by:
Noa Osherovich <noaos@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
-
Stefan Agner authored
[ Upstream commit 0f0e8de3 ] In order to make sure compiler flag detection for ARM works correctly the no-integrated-as flags need to be set before including the arch specific Makefile. Fixes: cfe17c9b ("kbuild: move cc-option and cc-disable-warning after incl. arch Makefile") Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Ben Hutchings authored
[ Upstream commit 3a9910d7 ] qla2x00_tmf_sp_done() now deletes the timer that will run qla2x00_tmf_iocb_timeout(), but doesn't check whether the timer already expired. Check the return value from del_timer() to avoid calling complete() a second time. Fixes: 4440e46d ("[SCSI] qla2xxx: Add IOCB Abort command asynchronous ...") Fixes: 1514839b ("scsi: qla2xxx: Fix NULL pointer crash due to active ...") Signed-off-by:
Himanshu Madhani <himanshu.madhani@cavium.com> Signed-off-by:
-
Shay Agroskin authored
[ Upstream commit e279d634 ] Removed an error message received when configuring ETS total bandwidth to be zero. Our hardware doesn't support such configuration, so we shall reject it in the driver. Nevertheless, we removed the error message in order to eliminate error messages caused by old userspace tools who try to pass such configuration. Fixes: ff089191 ("net/mlx5e: Fix ETS BW check") Signed-off-by:
Shay Agroskin <shayag@mellanox.com> Reviewed-by:
Huy Nguyen <huyn@mellanox.com> Reviewed-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Kevin Hao authored
[ Upstream commit 5df7af85 ] For some phy devices, even though they don't support the MMD extended register access, it does have some side effect if we are trying to read/write the MMD registers via indirect method. So introduce general dummy stubs for MMD register access which these devices can use to avoid such side effect. Fixes: b6b5e8a6 ("gianfar: Disable EEE autoneg by default") Signed-off-by:
Kevin Hao <haokexin@gmail.com> Signed-off-by:
-
Kevin Hao authored
[ Upstream commit 0231b1a0 ] The Ethernet on mpc8315erdb is broken since commit b6b5e8a6 ("gianfar: Disable EEE autoneg by default"). The reason is that even though the rtl8211b doesn't support the MMD extended registers access, it does return some random values if we trying to access the MMD register via indirect method. This makes it seem that the EEE is supported by this phy device. And the subsequent writing to the MMD registers does cause the phy malfunction. So use the dummy stubs for the MMD register access to fix this issue. Fixes: b6b5e8a6 ("gianfar: Disable EEE autoneg by default") Signed-off-by:
-
Milan Broz authored
[ Upstream commit e16b4f99 ] Since crypto API commit 9fa68f62 ("crypto: hash - prevent using keyed hashes without setting key") dm-integrity cannot use keyed algorithms without the key being set. The dm-integrity recognizes this too late (during use of HMAC), so it allows creation and formatting of superblock, but the device is in fact unusable. Fix it by detecting the key requirement in integrity table constructor. Signed-off-by:
Milan Broz <gmazyland@gmail.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Corentin Labbe authored
[ Upstream commit c1e150ce ] When CONFIG_NUMA is not set, the build fails with: arch/powerpc/platforms/pseries/hotplug-cpu.c:335:4: error: déclaration implicite de la fonction « update_numa_cpu_lookup_table » So we have to add update_numa_cpu_lookup_table() as an empty function when CONFIG_NUMA is not set. Fixes: 1d9a0907 ("powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove") Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Signed-off-by:
-
Israel Rukshin authored
[ Upstream commit 6082d9c9 ] 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: 2572cf57 ("mlx5: fix mlx5_get_vector_affinity to start from completion vector 0") Fixes: 05e0cc84 ("net/mlx5: Fix get vector affinity helper function") Signed-off-by:
Israel Rukshin <israelr@mellanox.com> Reviewed-by:
Max Gurtovoy <maxg@mellanox.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Julian Wiedmann authored
[ Upstream commit 686c97ee ] Make sure to check both return code fields before(!) processing the command response. Otherwise we risk operating on invalid data. This matches an earlier fix for SETASSPARMS commands, see commit ad3cbf61 ("s390/qeth: fix error handling in checksum cmd callback"). Signed-off-by:
Julian Wiedmann <jwi@linux.vnet.ibm.com> Signed-off-by:
-
Doug Ledford authored
[ Upstream commit 6b9f8970 ] If the allocation of elem fails, it is not sufficient to simply check for NULL and return. We need to also put our reference on the pool or else we will leave the pool with a permanent ref count and we will never be able to free it. Fixes: 4831ca9e ("IB/rxe: check for allocation failure on elem") Suggested-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Alex Vesker authored
[ Upstream commit 1f80bd6a ] The locking order of vlan_rwsem (LOCK A) and then rtnl (LOCK B), contradicts other flows such as ipoib_open possibly causing a deadlock. To prevent this deadlock heavy flush is called with RTNL locked and only then tries to acquire vlan_rwsem. This deadlock is possible only when there are child interfaces. [ 140.941758] ====================================================== [ 140.946276] WARNING: possible circular locking dependency detected [ 140.950950] 4.15.0-rc1+ #9 Tainted: G O [ 140.954797] ------------------------------------------------------ [ 140.959424] kworker/u32:1/146 is trying to acquire lock: [ 140.963450] (rtnl_mutex){+.+.}, at: [<ffffffffc083516a>] __ipoib_ib_dev_flush+0x2da/0x4e0 [ib_ipoib] [ 140.970006] but task is already holding lock: [ 140.975141] (&priv->vlan_rwsem){++++}, at: [<ffffffffc0834ee1>] __ipoib_ib_dev_flush+0x51/0x4e0 [ib_ipoib] [ 140.982105] which lock already depends on the new lock. [ 140.990023] the existing dependency chain (in reverse order) is: [ 140.998650] -> #1 (&priv->vlan_rwsem){++++}: [ 141.005276] down_read+0x4d/0xb0 [ 141.009560] ipoib_open+0xad/0x120 [ib_ipoib] [ 141.014400] __dev_open+0xcb/0x140 [ 141.017919] __dev_change_flags+0x1a4/0x1e0 [ 141.022133] dev_change_flags+0x23/0x60 [ 141.025695] devinet_ioctl+0x704/0x7d0 [ 141.029156] sock_do_ioctl+0x20/0x50 [ 141.032526] sock_ioctl+0x221/0x300 [ 141.036079] do_vfs_ioctl+0xa6/0x6d0 [ 141.039656] SyS_ioctl+0x74/0x80 [ 141.042811] entry_SYSCALL_64_fastpath+0x1f/0x96 [ 141.046891] -> #0 (rtnl_mutex){+.+.}: [ 141.051701] lock_acquire+0xd4/0x220 [ 141.055212] __mutex_lock+0x88/0x970 [ 141.058631] __ipoib_ib_dev_flush+0x2da/0x4e0 [ib_ipoib] [ 141.063160] __ipoib_ib_dev_flush+0x71/0x4e0 [ib_ipoib] [ 141.067648] process_one_work+0x1f5/0x610 [ 141.071429] worker_thread+0x4a/0x3f0 [ 141.074890] kthread+0x141/0x180 [ 141.078085] ret_from_fork+0x24/0x30 [ 141.081559] other info that might help us debug this: [ 141.088967] Possible unsafe locking scenario: [ 141.094280] CPU0 CPU1 [ 141.097953] ---- ---- [ 141.101640] lock(&priv->vlan_rwsem); [ 141.104771] lock(rtnl_mutex); [ 141.109207] lock(&priv->vlan_rwsem); [ 141.114032] lock(rtnl_mutex); [ 141.116800] *** DEADLOCK *** Fixes: b4b678b0 ("IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop") Signed-off-by:
Alex Vesker <valex@mellanox.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit d1853975 ] As reported by Meelis Roos, my previous patch causes an incorrect calculation of the timeout, through an undefined signed integer overflow: [ 12.228155] UBSAN: Undefined behaviour in drivers/scsi/aacraid/commsup.c:2514:49 [ 12.228229] signed integer overflow: [ 12.228283] 964297611 * 250 cannot be represented in type 'long int' The problem is that doing a multiplication with HZ first and then dividing by USEC_PER_SEC worked correctly for 32-bit microseconds, but not for 32-bit nanoseconds, which would require up to 41 bits. This reworks the calculation to first convert the nanoseconds into jiffies, which should give us the same result as before and not overflow. Unfortunately I did not understand the exact intention of the algorithm, in particular the part where we add half a second, so it's possible that there is still a preexisting problem in this function. I added a comment that this would be handled more nicely using usleep_range(), which generally works better for waking up at a particular time than the current schedule_timeout() based implementation. I did not feel comfortable trying to implement that without being sure what the intent is here though. Fixes: 820f1886 ("scsi: aacraid: use timespec64 instead of timeval") Tested-by:
Meelis Roos <mroos@linux.ee> Signed-off-by:
-
Shuah Khan authored
[ Upstream commit 5468099c ] Commit 2f2d0088 ("usbip: prevent vhci_hcd driver from leaking a socket pointer address") in the /sys/devices/platform/vhci_hcd/status. Fix the header and field alignment to reflect the changes and make it easier to read. Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
