aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-01-29CIFS: Do not consider -ENODATA as stat failure for readsPavel Shilovsky1-1/+1
When doing reads beyound the end of a file the server returns error STATUS_END_OF_FILE error which is mapped to -ENODATA. Currently we report it as a failure which confuses read stats. Change it to not consider -ENODATA as failure for stat purposes. Signed-off-by: Pavel Shilovsky <[email protected]> Signed-off-by: Steve French <[email protected]> CC: Stable <[email protected]>
2019-01-29CIFS: Do not count -ENODATA as failure for query directoryPavel Shilovsky1-2/+2
Signed-off-by: Pavel Shilovsky <[email protected]> Signed-off-by: Steve French <[email protected]> CC: Stable <[email protected]>
2019-01-29CIFS: Fix trace command logging for SMB2 reads and writesPavel Shilovsky1-16/+30
Currently we log success once we send an async IO request to the server. Instead we need to analyse a response and then log success or failure for a particular command. Also fix argument list for read logging. Cc: <[email protected]> # 4.18 Signed-off-by: Pavel Shilovsky <[email protected]> Signed-off-by: Steve French <[email protected]>
2019-01-29CIFS: Fix possible oops and memory leaks in async IOPavel Shilovsky1-3/+8
Allocation of a page array for non-cached IO was separated from allocation of rdata and wdata structures and this introduced memory leaks and a possible null pointer dereference. This patch fixes these problems. Cc: <[email protected]> Signed-off-by: Pavel Shilovsky <[email protected]> Signed-off-by: Steve French <[email protected]>
2019-01-29cifs: limit amount of data we request for xattrs to CIFSMaxBufSizeRonnie Sahlberg2-3/+16
minus the various headers and blobs that will be part of the reply. or else we might trigger a session reconnect. Signed-off-by: Ronnie Sahlberg <[email protected]> Signed-off-by: Steve French <[email protected]> Reviewed-by: Pavel Shilovsky <[email protected]>
2019-01-29cifs: fix computation for MAX_SMB2_HDR_SIZERonnie Sahlberg1-2/+2
The size of the fixed part of the create response is 88 bytes not 56. Signed-off-by: Ronnie Sahlberg <[email protected]> Signed-off-by: Steve French <[email protected]> Reviewed-by: Pavel Shilovsky <[email protected]>
2019-01-29NFS: Fix up return value on fatal errors in nfs_page_async_flush()Trond Myklebust1-4/+5
Ensure that we return the fatal error value that caused us to exit nfs_page_async_flush(). Fixes: c373fff7bd25 ("NFSv4: Don't special case "launder"") Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected] # v4.12+ Reviewed-by: Benjamin Coddington <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2019-01-29x86/speculation: Remove redundant arch_smt_update() invocationZhenzhong Duan1-4/+1
With commit a74cfffb03b7 ("x86/speculation: Rework SMT state change"), arch_smt_update() is invoked from each individual CPU hotplug function. Therefore the extra arch_smt_update() call in the sysfs SMT control is redundant. Fixes: a74cfffb03b7 ("x86/speculation: Rework SMT state change") Signed-off-by: Zhenzhong Duan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/e2e064f2-e8ef-42ca-bf4f-76b612964752@default
2019-01-29x86/fault: Fix sign-extend unintended sign extensionColin Ian King1-1/+1
show_ldttss() shifts desc.base2 by 24 bit, but base2 is 8 bits of a bitfield in a u16. Due to the really great idea of integer promotion in C99 base2 is promoted to an int, because that's the standard defined behaviour when all values which can be represented by base2 fit into an int. Now if bit 7 is set in desc.base2 the result of the shift left by 24 makes the resulting integer negative and the following conversion to unsigned long legitmately sign extends first causing the upper bits 32 bits to be set in the result. Fix this by casting desc.base2 to unsigned long before the shift. Detected by CoverityScan, CID#1475635 ("Unintended sign extension") [ tglx: Reworded the changelog a bit as I actually had to lookup the standard (again) to decode the original one. ] Fixes: a1a371c468f7 ("x86/fault: Decode page fault OOPSes better") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: "H . Peter Anvin" <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2019-01-29x86/boot/compressed/64: Set EFER.LME=1 in 32-bit trampoline before returning ↵Wei Huang2-1/+9
to long mode In some old AMD KVM implementation, guest's EFER.LME bit is cleared by KVM when the hypervsior detects that the guest sets CR0.PG to 0. This causes the guest OS to reboot when it tries to return from 32-bit trampoline code because the CPU is in incorrect state: CR4.PAE=1, CR0.PG=1, CS.L=1, but EFER.LME=0. As a precaution, set EFER.LME=1 as part of long mode activation procedure. This extra step won't cause any harm when Linux is booted on a bare-metal machine. Signed-off-by: Wei Huang <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2019-01-29IB/uverbs: Fix OOPs in uverbs_user_mmap_disassociateYishai Hadas1-5/+13
The vma->vm_mm can become impossible to get before rdma_umap_close() is called, in this case we must not try to get an mm that is already undergoing process exit. In this case there is no need to wait for anything as the VMA will be destroyed by another thread soon and is already effectively 'unreachable' by userspace. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 800000012bc50067 P4D 800000012bc50067 PUD 129db5067 PMD 0 Oops: 0000 [#1] SMP PTI CPU: 1 PID: 2050 Comm: bash Tainted: G W OE 4.20.0-rc6+ #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__rb_erase_color+0xb9/0x280 Code: 84 17 01 00 00 48 3b 68 10 0f 84 15 01 00 00 48 89 58 08 48 89 de 48 89 ef 4c 89 e3 e8 90 84 22 00 e9 60 ff ff ff 48 8b 5d 10 <f6> 03 01 0f 84 9c 00 00 00 48 8b 43 10 48 85 c0 74 09 f6 00 01 0f RSP: 0018:ffffbecfc090bab8 EFLAGS: 00010246 RAX: ffff97616346cf30 RBX: 0000000000000000 RCX: 0000000000000101 RDX: 0000000000000000 RSI: ffff97623b6ca828 RDI: ffff97621ef10828 RBP: ffff97621ef10828 R08: ffff97621ef10828 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff97623b6ca838 R13: ffffffffbb3fef50 R14: ffff97623b6ca828 R15: 0000000000000000 FS: 00007f7a5c31d740(0000) GS:ffff97623bb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000011255a000 CR4: 00000000000006e0 Call Trace: unlink_file_vma+0x3b/0x50 free_pgtables+0xa1/0x110 exit_mmap+0xca/0x1a0 ? mlx5_ib_dealloc_pd+0x28/0x30 [mlx5_ib] mmput+0x54/0x140 uverbs_user_mmap_disassociate+0xcc/0x160 [ib_uverbs] uverbs_destroy_ufile_hw+0xf7/0x120 [ib_uverbs] ib_uverbs_remove_one+0xea/0x240 [ib_uverbs] ib_unregister_device+0xfb/0x200 [ib_core] mlx5_ib_remove+0x51/0xe0 [mlx5_ib] mlx5_remove_device+0xc1/0xd0 [mlx5_core] mlx5_unregister_device+0x3d/0xb0 [mlx5_core] remove_one+0x2a/0x90 [mlx5_core] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x16d/0x240 unbind_store+0xb2/0x100 kernfs_fop_write+0x102/0x180 __vfs_write+0x36/0x1a0 ? __alloc_fd+0xa9/0x170 ? set_close_on_exec+0x49/0x70 vfs_write+0xad/0x1a0 ksys_write+0x52/0xc0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Cc: <[email protected]> # 4.19 Fixes: 5f9794dc94f5 ("RDMA/ucontext: Add a core API for mmaping driver IO memory") Signed-off-by: Yishai Hadas <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2019-01-29debugfs: return error values, not NULLGreg Kroah-Hartman1-17/+22
When an error happens, debugfs should return an error pointer value, not NULL. This will prevent the totally theoretical error where a debugfs call fails due to lack of memory, returning NULL, and that dentry value is then passed to another debugfs call, which would end up succeeding, creating a file at the root of the debugfs tree, but would then be impossible to remove (because you can not remove the directory NULL). So, to make everyone happy, always return errors, this makes the users of debugfs much simpler (they do not have to ever check the return value), and everyone can rest easy. Reported-by: Gary R Hook <[email protected]> Reported-by: Heiko Carstens <[email protected]> Reported-by: Masami Hiramatsu <[email protected]> Reported-by: Michal Hocko <[email protected]> Reported-by: Sebastian Andrzej Siewior <[email protected]> Reported-by: Ulf Hansson <[email protected]> Reviewed-by: Masami Hiramatsu <[email protected]> Reviewed-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-01-29MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds buildsPaul Burton1-2/+2
When generating vdso-o32.lds & vdso-n32.lds for use with programs running as compat ABIs under 64b kernels, we previously haven't included the compiler flags that are supposedly common to all ABIs - ie. those in the ccflags-vdso variable. This is problematic in cases where we need to provide the -m%-float flag in order to ensure that we don't attempt to use a floating point ABI that's incompatible with the target CPU & ABI. For example a toolchain using current gcc trunk configured --with-fp-32=xx fails to build a 64r6el_defconfig kernel with the following error: cc1: error: '-march=mips1' requires '-mfp32' make[2]: *** [arch/mips/vdso/Makefile:135: arch/mips/vdso/vdso-o32.lds] Error 1 Include $(ccflags-vdso) for the compat VDSO .lds builds, just as it is included for the native VDSO .lds & when compiling objects for the compat VDSOs. This ensures we consistently provide the -msoft-float flag amongst others, avoiding the problem by ensuring we're agnostic to the toolchain defaults. Signed-off-by: Paul Burton <[email protected]> Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Cc: [email protected] Cc: Kevin Hilman <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Maciej W . Rozycki <[email protected]> Cc: [email protected] # v4.4+
2019-01-29MIPS: VDSO: Use same -m%-float cflag as the kernel properPaul Burton1-0/+1
The MIPS VDSO build currently doesn't provide the -msoft-float flag to the compiler as the kernel proper does. This results in an attempt to use the compiler's default floating point configuration, which can be problematic in cases where this is incompatible with the target CPU's -march= flag. For example decstation_defconfig fails to build using toolchains in which gcc was configured --with-fp-32=xx with the following error: LDS arch/mips/vdso/vdso.lds cc1: error: '-march=r3000' requires '-mfp32' make[2]: *** [scripts/Makefile.build:379: arch/mips/vdso/vdso.lds] Error 1 The kernel proper avoids this error because we build with the -msoft-float compiler flag, rather than using the compiler's default. Pass this flag through to the VDSO build so that it too becomes agnostic to the toolchain's floating point configuration. Note that this is filtered out from KBUILD_CFLAGS rather than simply always using -msoft-float such that if we switch the kernel to use -mno-float in the future the VDSO will automatically inherit the change. The VDSO doesn't actually include any floating point code, and its .MIPS.abiflags section is already manually generated to specify that it's compatible with any floating point ABI. As such this change should have no effect on the resulting VDSO, apart from fixing the build failure for affected toolchains. Signed-off-by: Paul Burton <[email protected]> Reported-by: Kevin Hilman <[email protected]> Reported-by: Guenter Roeck <[email protected]> Tested-by: Kevin Hilman <[email protected]> References: https://lore.kernel.org/linux-mips/[email protected]/ References: https://kernelci.org/build/id/5c4e4ae059b5142a249ad004/logs/ Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Cc: Maciej W. Rozycki <[email protected]> Cc: [email protected] Cc: [email protected] # v4.4+
2019-01-29MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabledAaro Koskinen1-5/+5
Don't set octeon_dma_bar_type if PCI is disabled. This avoids creation of the MSI irqchip later on, and saves a bit of memory. Signed-off-by: Aaro Koskinen <[email protected]> Signed-off-by: Paul Burton <[email protected]> Fixes: a214720cbf50 ("Disable MSI also when pcie-octeon.pcie_disable on") Cc: [email protected] # v3.3+ Cc: [email protected]
2019-01-29MAINTAINERS: Add entry for XDP (eXpress Data Path)Jesper Dangaard Brouer1-0/+18
Add multiple people as maintainers for XDP, sorted alphabetically. XDP is also tied to driver level support and code, but we cannot add all drivers to the list. Instead K: and N: match on 'xdp' in hope to catch some of those changes in drivers. Signed-off-by: Jesper Dangaard Brouer <[email protected]> Acked-by: John Fastabend <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Acked-by: David S. Miller <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-29net: set default network namespace in init_dummy_netdev()Josh Elsasser1-0/+3
Assign a default net namespace to netdevs created by init_dummy_netdev(). Fixes a NULL pointer dereference caused by busy-polling a socket bound to an iwlwifi wireless device, which bumps the per-net BUSYPOLLRXPACKETS stat if napi_poll() received packets: BUG: unable to handle kernel NULL pointer dereference at 0000000000000190 IP: napi_busy_loop+0xd6/0x200 Call Trace: sock_poll+0x5e/0x80 do_sys_poll+0x324/0x5a0 SyS_poll+0x6c/0xf0 do_syscall_64+0x6b/0x1f0 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Fixes: 7db6b048da3b ("net: Commonize busy polling code to focus on napi_id instead of socket") Signed-off-by: Josh Elsasser <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-29net: b44: replace dev_kfree_skb_xxx by dev_consume_skb_xxx for drop profilesYang Wei1-2/+2
The skb should be freed by dev_consume_skb_any() in b44_start_xmit() when bounce_skb is used. The skb is be replaced by bounce_skb, so the original skb should be consumed(not drop). dev_consume_skb_irq() should be called in b44_tx() when skb xmit done. It makes drop profiles(dropwatch, perf) more friendly. Signed-off-by: Yang Wei <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-29net: caif: call dev_consume_skb_any when skb xmit doneYang Wei1-4/+1
The skb shouled be consumed when xmit done, it makes drop profiles (dropwatch, perf) more friendly. dev_kfree_skb_irq()/kfree_skb() shouled be replaced by dev_consume_skb_any(), it makes code cleaner. Signed-off-by: Yang Wei <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-29net: 8139cp: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profilesYang Wei1-1/+1
dev_consume_skb_irq() should be called in cp_tx() when skb xmit done. It makes drop profiles(dropwatch, perf) more friendly. Signed-off-by: Yang Wei <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-29net: macb: Apply RXUBR workaround only to versions with errataHarini Katakam2-11/+20
The interrupt handler contains a workaround for RX hang applicable to Zynq and AT91RM9200 only. Subsequent versions do not need this workaround. This workaround unnecessarily resets RX whenever RX used bit read is observed, which can be often under heavy traffic. There is no other action performed on RX UBR interrupt. Hence introduce a CAPS mask; enable this interrupt and workaround only on affected versions. Signed-off-by: Harini Katakam <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-29drm/amd/powerplay: Fix missing break in switchGustavo A. R. Silva1-0/+1
Add missing break statement in order to prevent the code from falling through to the default case. The resoning for this is that pclk_vol_table is an automatic variable. So, it makes no sense to update it just before falling through to the default case and return -EINVAL. This bug was found thanks to the ongoing efforts to enabling -Wimplicit-fallthrough. Fixes: cd70f3d6e3fa ("drm/amd/powerplay: PP/DAL interface changes for dynamic clock switch") Cc: [email protected] Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-01-29drm/radeon: check if device is root before getting pci speed capsAlex Deucher2-4/+6
Check if the device is root rather before attempting to see what speeds the pcie port supports. Fixes a crash with pci passthrough in a VM. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109366 Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-01-29drm/amdgpu: Add missing power attribute to APU checkAlex Deucher1-1/+2
Add missing power_average to visible check for power attributes for APUs. Was missed before. Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-01-29irqchip/mmp: Only touch the PJ4 IRQ & FIQ bits on enable/disableLubomir Rintel1-1/+5
Resetting bit 4 disables the interrupt delivery to the "secure processor" core. This breaks the keyboard on a OLPC XO 1.75 laptop, where the firmware running on the "secure processor" bit-bangs the PS/2 protocol over the GPIO lines. It is not clear what the rest of the bits are and Marvell was unhelpful when asked for documentation. Aside from the SP bit, there are probably priority bits. Leaving the unknown bits as the firmware set them up seems to be a wiser course of action compared to just turning them off. Signed-off-by: Lubomir Rintel <[email protected]> Acked-by: Pavel Machek <[email protected]> [maz: fixed-up subject and commit message] Signed-off-by: Marc Zyngier <[email protected]>
2019-01-29irqchip/gic-v3-its: Gracefully fail on LPI exhaustionMarc Zyngier1-0/+3
In the unlikely event that we cannot find any available LPI in the system, we should gracefully return an error instead of carrying on with no LPI allocated at all. Fixes: 38dd7c494cf6 ("irqchip/gic-v3-its: Drop chunk allocation compatibility") Signed-off-by: Marc Zyngier <[email protected]>
2019-01-29irqchip/gic-v3-its: Plug allocation race for devices sharing a DevIDMarc Zyngier1-5/+27
On systems or VMs where multiple devices share a single DevID (because they sit behind a PCI bridge, or because the HW is broken in funky ways), we reuse the save its_device structure in order to reflect this. It turns out that there is a distinct lack of locking when looking up the its_device, and two device being probed concurrently can result in double allocations. That's obviously not nice. A solution for this is to have a per-ITS mutex that serializes device allocation. A similar issue exists on the freeing side, which can run concurrently with the allocation. On top of now taking the appropriate lock, we also make sure that a shared device is never freed, as we have no way to currently track the life cycle of such object. Reported-by: Zheng Xiang <[email protected]> Tested-by: Zheng Xiang <[email protected]> Cc: [email protected] Signed-off-by: Marc Zyngier <[email protected]>
2019-01-29x86/cpu: Add Atom Tremont (Jacobsville)Kan Liang1-1/+2
Add the Atom Tremont model number to the Intel family list. [ Tony: Also update comment at head of file to say "_X" suffix is also used for microserver parts. ] Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Qiuxu Zhuo <[email protected]> Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Aristeu Rozanski <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: linux-edac <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Megha Dey <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Qiuxu Zhuo <[email protected]> Cc: Rajneesh Bhardwaj <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: x86-ml <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-01-29ALSA: hda/realtek - Fixed hp_pin no valueKailang Yang1-33/+45
Fix hp_pin always no value. [More notes on the changes: The hp_pin value that is referred in alc294_hp_init() is always zero at the moment the function gets called, hence this is actually useless as in the current code. And, this kind of init sequence should be called from the codec init callback, instead of the parser function. So, the first fix in this patch to move the call call into its own init_hook. OTOH, this function is needed to be called only once after the boot, and it'd take too long for invoking at each resume (where the init callback gets called). So we add a new flag and invoke this only once as an additional fix. The one case is still not covered, though: S4 resume. But this change itself won't lead to any regression in that regard, so we leave S4 issue as is for now and fix it later. -- tiwai ] Fixes: bde1a7459623 ("ALSA: hda/realtek - Fixed headphone issue for ALC700") Signed-off-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2019-01-29Merge branch 'md-fixes' of https://github.com/liu-song-6/linux into for-linusJens Axboe2-13/+28
Pull MD fix from Song. * 'md-fixes' of https://github.com/liu-song-6/linux: md/raid5: fix 'out of memory' during raid cache recovery
2019-01-29drm/vmwgfx: unwind spaghetti code in vmw_dma_select_modeChristoph Hellwig1-19/+6
Just use a simple if/else chain to select the DMA mode. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Signed-off-by: Thomas Hellstrom <[email protected]>
2019-01-29drm/vmwgfx: fix the check when to use dma_alloc_coherentChristoph Hellwig1-7/+4
Since Linux 4.21 we merged the swiotlb ops into the DMA direct ops, so they would always have a the sync_single methods. But late in the cicle we also removed the direct ops entirely, so we'd see NULL DMA ops. Switch vmw_dma_select_mode to only detect swiotlb presence using swiotlb_nr_tbl() instead. Fixes: 55897af630 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code") Fixes: 356da6d0cd ("dma-mapping: bypass indirect calls for dma-direct") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Signed-off-by: Thomas Hellstrom <[email protected]>
2019-01-29drm/vmwgfx: remove CONFIG_INTEL_IOMMU ifdefs v2Christoph Hellwig1-17/+4
intel_iommu_enabled is defined as always false for !CONFIG_INTEL_IOMMU, so remove the ifdefs around it. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Signed-off-by: Thomas Hellstrom <[email protected]>
2019-01-29drm/vmwgfx: remove CONFIG_X86 ifdefsChristoph Hellwig1-6/+0
The driver depends on CONFIG_X86 so these are dead code. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Signed-off-by: Thomas Hellstrom <[email protected]>
2019-01-29HID: debug: fix the ring buffer implementationVladis Dronov2-78/+51
Ring buffer implementation in hid_debug_event() and hid_debug_events_read() is strange allowing lost or corrupted data. After commit 717adfdaf147 ("HID: debug: check length before copy_to_user()") it is possible to enter an infinite loop in hid_debug_events_read() by providing 0 as count, this locks up a system. Fix this by rewriting the ring buffer implementation with kfifo and simplify the code. This fixes CVE-2019-3819. v2: fix an execution logic and add a comment v3: use __set_current_state() instead of set_current_state() Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187 Cc: [email protected] # v4.18+ Fixes: cd667ce24796 ("HID: use debugfs for events/reports dumping") Fixes: 717adfdaf147 ("HID: debug: check length before copy_to_user()") Signed-off-by: Vladis Dronov <[email protected]> Reviewed-by: Oleg Nesterov <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]>
2019-01-29platform/x86: Fix unmet dependency warning for SAMSUNG_Q10Sinan Kaya1-0/+1
Add BACKLIGHT_LCD_SUPPORT for SAMSUNG_Q10 to fix the warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE. SAMSUNG_Q10 selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE depends on BACKLIGHT_LCD_SUPPORT. Copy BACKLIGHT_LCD_SUPPORT dependency into SAMSUNG_Q10 to fix: WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n] Selected by [y]: - SAMSUNG_Q10 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y] Signed-off-by: Sinan Kaya <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-01-29platform/x86: Fix unmet dependency warning for ACPI_CMPCSinan Kaya1-0/+1
Add BACKLIGHT_LCD_SUPPORT for ACPI_CMPC to fix the warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE. ACPI_CMPC selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE depends on BACKLIGHT_LCD_SUPPORT. Copy BACKLIGHT_LCD_SUPPORT dependency into ACPI_CMPC to fix WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n] Selected by [y]: - ACPI_CMPC [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y] && INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n) Signed-off-by: Sinan Kaya <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-01-29mfd: Fix unmet dependency warning for MFD_TPS68470Sinan Kaya1-1/+1
After commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") dependencies on CONFIG_PCI that previously were satisfied implicitly through dependencies on CONFIG_ACPI have to be specified directly. WARNING: unmet direct dependencies detected for I2C_DESIGNWARE_PLATFORM Depends on [n]: I2C [=y] && HAS_IOMEM [=y] && (ACPI [=y] && COMMON_CLK [=n] || !ACPI [=y]) Selected by [y]: - MFD_TPS68470 [=y] && HAS_IOMEM [=y] && ACPI [=y] && I2C [=y]=y MFD_TPS68470 is an ACPI only device and selects I2C_DESIGNWARE_PLATFORM. I2C_DESIGNWARE_PLATFORM does not have any configuration today for ACPI support without CONFIG_PCI set. For sake of a quick fix this introduces a new mandatory dependency to the driver which may survive without it. Otherwise we need to revisit the driver architecture to address this properly. Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set") Signed-off-by: Sinan Kaya <[email protected]> Acked-by: Lee Jones <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-01-28net: ti: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profilesYang Wei1-1/+1
dev_consume_skb_irq() should be called in cpmac_end_xmit() when xmit done. It makes drop profiles more friendly. Signed-off-by: Yang Wei <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-28net: apple: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profilesYang Wei1-1/+1
dev_consume_skb_irq() should be called in bmac_txdma_intr() when xmit done. It makes drop profiles more friendly. Signed-off-by: Yang Wei <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-28net: amd8111e: replace dev_kfree_skb_irq by dev_consume_skb_irqYang Wei1-1/+1
dev_consume_skb_irq() should be called in amd8111e_tx() when xmit done. It makes drop profiles more friendly. Signed-off-by: Yang Wei <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-28net: alteon: replace dev_kfree_skb_irq by dev_consume_skb_irqYang Wei1-1/+1
dev_consume_skb_irq() should be called in ace_tx_int() when xmit done. It makes drop profiles more friendly. Signed-off-by: Yang Wei <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-28net: tls: Fix deadlock in free_resources txDave Watson1-0/+2
If there are outstanding async tx requests (when crypto returns EINPROGRESS), there is a potential deadlock: the tx work acquires the lock, while we cancel_delayed_work_sync() while holding the lock. Drop the lock while waiting for the work to complete. Fixes: a42055e8d2c30 ("Add support for async encryption of records...") Signed-off-by: Dave Watson <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-28net: tls: Save iv in tls_rec for async crypto requestsDave Watson2-1/+5
aead_request_set_crypt takes an iv pointer, and we change the iv soon after setting it. Some async crypto algorithms don't save the iv, so we need to save it in the tls_rec for async requests. Found by hardcoding x64 aesni to use async crypto manager (to test the async codepath), however I don't think this combination can happen in the wild. Presumably other hardware offloads will need this fix, but there have been no user reports. Fixes: a42055e8d2c30 ("Add support for async encryption of records...") Signed-off-by: Dave Watson <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-28vhost: fix OOB in get_rx_bufs()Jason Wang5-7/+11
After batched used ring updating was introduced in commit e2b3b35eb989 ("vhost_net: batch used ring update in rx"). We tend to batch heads in vq->heads for more than one packet. But the quota passed to get_rx_bufs() was not correctly limited, which can result a OOB write in vq->heads. headcount = get_rx_bufs(vq, vq->heads + nvq->done_idx, vhost_len, &in, vq_log, &log, likely(mergeable) ? UIO_MAXIOV : 1); UIO_MAXIOV was still used which is wrong since we could have batched used in vq->heads, this will cause OOB if the next buffer needs more than 960 (1024 (UIO_MAXIOV) - 64 (VHOST_NET_BATCH)) heads after we've batched 64 (VHOST_NET_BATCH) heads: Acked-by: Stefan Hajnoczi <[email protected]> ============================================================================= BUG kmalloc-8k (Tainted: G B ): Redzone overwritten ----------------------------------------------------------------------------- INFO: 0x00000000fd93b7a2-0x00000000f0713384. First byte 0xa9 instead of 0xcc INFO: Allocated in alloc_pd+0x22/0x60 age=3933677 cpu=2 pid=2674 kmem_cache_alloc_trace+0xbb/0x140 alloc_pd+0x22/0x60 gen8_ppgtt_create+0x11d/0x5f0 i915_ppgtt_create+0x16/0x80 i915_gem_create_context+0x248/0x390 i915_gem_context_create_ioctl+0x4b/0xe0 drm_ioctl_kernel+0xa5/0xf0 drm_ioctl+0x2ed/0x3a0 do_vfs_ioctl+0x9f/0x620 ksys_ioctl+0x6b/0x80 __x64_sys_ioctl+0x11/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 INFO: Slab 0x00000000d13e87af objects=3 used=3 fp=0x (null) flags=0x200000000010201 INFO: Object 0x0000000003278802 @offset=17064 fp=0x00000000e2e6652b Fixing this by allocating UIO_MAXIOV + VHOST_NET_BATCH iovs for vhost-net. This is done through set the limitation through vhost_dev_init(), then set_owner can allocate the number of iov in a per device manner. This fixes CVE-2018-16880. Fixes: e2b3b35eb989 ("vhost_net: batch used ring update in rx") Signed-off-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-01-29scsi: 53c700: pass correct "dev" to dma_alloc_attrs()Dan Carpenter1-1/+1
The "hostdata->dev" pointer is NULL here. We set "hostdata->dev = dev;" later in the function and we also use "hostdata->dev" when we call dma_free_attrs() in NCR_700_release(). This bug predates git version control. Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-01-29scsi: bnx2fc: Fix error handling in probe()Dan Carpenter1-2/+2
There are two issues here. First if cmgr->hba is not set early enough then it leads to a NULL dereference. Second if we don't completely initialize cmgr->io_bdt_pool[] then we end up dereferencing uninitialized pointers. Fixes: 853e2bd2103a ("[SCSI] bnx2fc: Broadcom FCoE offload driver") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-01-29scsi: scsi_debug: fix write_same with virtual_gb problemDouglas Gilbert1-20/+21
The WRITE SAME(10) and (16) implementations didn't take account of the buffer wrap required when the virtual_gb parameter is greater than 0. Fix that and rename the fake_store() function to lba2fake_store() to lessen confusion with the global fake_storep pointer. Bump version date. Signed-off-by: Douglas Gilbert <[email protected]> Reported-by: Bart Van Assche <[email protected]> Tested by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-01-29scsi: libfc: free skb when receiving invalid flogi respMing Lu1-3/+3
The issue to be fixed in this commit is when libfc found it received a invalid FLOGI response from FC switch, it would return without freeing the fc frame, which is just the skb data. This would cause memory leak if FC switch keeps sending invalid FLOGI responses. This fix is just to make it execute `fc_frame_free(fp)` before returning from function `fc_lport_flogi_resp`. Signed-off-by: Ming Lu <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-01-29scsi: zfcp: fix sysfs block queue limit output for max_segment_sizeSteffen Maier2-1/+2
Since v2.6.35 commit 683229845f17 ("[SCSI] zfcp: Report scatter-gather limits to SCSI and block layer"), zfcp set dma_parms.max_segment_size == PAGE_SIZE (but without using the setter dma_set_max_seg_size()) and scsi_host_template.dma_boundary == PAGE_SIZE - 1. v5.0-rc1 commit 50c2e9107f17 ("scsi: introduce a max_segment_size host_template parameters") introduced a new field scsi_host_template.max_segment_size. If an LLDD such as zfcp does not set it, scsi_host_alloc() uses BLK_MAX_SEGMENT_SIZE = 65536 for Scsi_Host.max_segment_size. __scsi_init_queue() announced the minimum of Scsi_Host.max_segment_size and dma_parms.max_segment_size to the block layer. For zfcp: min(65536, 4096) == 4096 which was still good. v5.0 commit a8cf59a6692c ("scsi: communicate max segment size to the DMA mapping code") announces Scsi_Host.max_segment_size to the block layer and overwrites dma_parms.max_segment_size with Scsi_Host.max_segment_size. For zfcp dma_parms.max_segment_size == Scsi_Host.max_segment_size == 65536 which is also reflected in block queue limits. $ cd /sys/bus/ccw/drivers/zfcp $ cd 0.0.3c40/host5/rport-5:0-4/target5:0:4/5:0:4:10/block/sdi/queue $ cat max_segment_size 65536 Zfcp I/O still works because dma_boundary implicitly still keeps the effective max segment size <= PAGE_SIZE. However, dma_boundary does not seem visible to user space, but max_segment_size is visible and shows a misleading wrong value. Fix it and inherit the stable tag of a8cf59a6692c. Devices on our bus ccw support DMA but no DMA mapping. Of multiple device types on the ccw bus, only zfcp needs dma_parms for SCSI limits. So, leave dma_parms setup in zfcp and do not move it to the bus. Signed-off-by: Steffen Maier <[email protected]> Fixes: 50c2e9107f ("scsi: introduce a max_segment_size host_template parameters") Signed-off-by: Martin K. Petersen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.