Skip to main content

Browse the archive

swh:1:snp:173f8deb0c56c557784b4fd217e7608ac6197844
sort by:
Revision Author Date Message Commit Date
822b768 Linus Torvalds 09 December 2018, 18:24:29 UTC Merge tag 'tty-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty driver fixes from Greg KH: "Here are three small tty driver fixes for 4.20-rc6 Nothing major, just some bug fixes for reported issues. Full details are in the shortlog. All of these have been in linux-next for a while with no reported issues" * tag 'tty-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var() tty: serial: 8250_mtk: always resume the device in probe. tty: do not set TTY_IO_ERROR flag if console port 09 December 2018, 18:24:29 UTC
50a5528 Linus Torvalds 09 December 2018, 18:18:24 UTC Merge tag 'usb-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here are some small USB fixes for 4.20-rc6 The "largest" here are some xhci fixes for reported issues. Also here is a USB core fix, some quirk additions, and a usb-serial fix which required the export of one of the tty layer's functions to prevent code duplication. The tty maintainer agreed with this change. All of these have been in linux-next with no reported issues" * tag 'usb-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: xhci: Prevent U1/U2 link pm states if exit latency is too long xhci: workaround CSS timeout on AMD SNPS 3.0 xHC USB: check usb_get_extra_descriptor for proper size USB: serial: console: fix reported terminal settings usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device USB: Fix invalid-free bug in port_over_current_notify() usb: appledisplay: Add 27" Apple Cinema Display 09 December 2018, 18:18:24 UTC
bc4caf1 Linus Torvalds 09 December 2018, 18:15:13 UTC Merge tag '4.20-rc5-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6 Pull cifs fixes from Steve French: "Three small fixes: a fix for smb3 direct i/o, a fix for CIFS DFS for stable and a minor cifs Kconfig fix" * tag '4.20-rc5-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6: CIFS: Avoid returning EBUSY to upper layer VFS cifs: Fix separator when building path from dentry cifs: In Kconfig CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs) 09 December 2018, 18:15:13 UTC
fa82dcb Linus Torvalds 09 December 2018, 17:54:04 UTC Merge tag 'dax-fixes-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull dax fixes from Dan Williams: "The last of the known regression fixes and fallout from the Xarray conversion of the filesystem-dax implementation. On the path to debugging why the dax memory-failure injection test started failing after the Xarray conversion a couple more fixes for the dax_lock_mapping_entry(), now called dax_lock_page(), surfaced. Those plus the bug that started the hunt are now addressed. These patches have appeared in a -next release with no issues reported. Note the touches to mm/memory-failure.c are just the conversion to the new function signature for dax_lock_page(). Summary: - Fix the Xarray conversion of fsdax to properly handle dax_lock_mapping_entry() in the presense of pmd entries - Fix inode destruction racing a new lock request" * tag 'dax-fixes-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: dax: Fix unlock mismatch with updated API dax: Don't access a freed inode dax: Check page->mapping isn't NULL 09 December 2018, 17:54:04 UTC
bd799eb Linus Torvalds 09 December 2018, 17:46:54 UTC Merge tag 'libnvdimm-fixes-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull libnvdimm fixes from Dan Williams: "A regression fix for the Address Range Scrub implementation, yes another one, and support for platforms that misalign persistent memory relative to the Linux memory hotplug section constraint. Longer term, support for sub-section memory hotplug would alleviate alignment waste, but until then this hack allows a 'struct page' memmap to be established for these misaligned memory regions. These have all appeared in a -next release, and thanks to Patrick for reporting and testing the alignment padding fix. Summary: - Unless and until the core mm handles memory hotplug units smaller than a section (128M), persistent memory namespaces must be padded to section alignment. The libnvdimm core already handled section collision with "System RAM", but some configurations overlap independent "Persistent Memory" ranges within a section, so additional padding injection is added for that case. - The recent reworks of the ARS (address range scrub) state machine to reduce the number of state flags inadvertantly missed a conversion of acpi_nfit_ars_rescan() call sites. Fix the regression whereby user-requested ARS results in a "short" scrub rather than a "long" scrub. - Fixup the unit tests to handle / test the 128M section alignment of mocked test resources. * tag 'libnvdimm-fixes-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: acpi/nfit: Fix user-initiated ARS to be "ARS-long" rather than "ARS-short" libnvdimm, pfn: Pad pfn namespaces relative to other regions tools/testing/nvdimm: Align test resources to 128M 09 December 2018, 17:46:54 UTC
9ef3463 Oliver O'Halloran 06 December 2018, 15:17:14 UTC powerpc/mm: Fallback to RAM if the altmap is unusable The "altmap" is used to provide a pool of memory that is reserved for the vmemmap backing of hot-plugged memory. This is useful when adding large amount of ZONE_DEVICE memory to a system with a limited amount of normal memory. On ppc64 we use huge pages to map the vmemmap which requires the backing storage to be contigious and aligned to the hugepage size. The altmap implementation allows for the altmap provider to reserve a few PFNs at the start of the range for it's own uses and when this occurs the first chunk of the altmap is not usable for hugepage mappings. On hash there is no sane way to fall back to a normal sized page mapping so we fail the allocation. This results in memory hotplug failing with ENOMEM when the new range doesn't fall into an existing vmemmap block. This patch handles this case by falling back to using system memory rather than failing if we cannot allocate from the altmap. This fallback should only ever be used for the first vmemmap block so it should not cause excess memory consumption. Fixes: 7b73d978a5d0 ("mm: pass the vmem_altmap to vmemmap_populate") Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 09 December 2018, 10:33:21 UTC
43001c5 Oliver O'Halloran 06 December 2018, 15:17:13 UTC powerpc/papr_scm: Use ibm,unit-guid as the iset cookie The interleave set cookie is used to determine if a label stored in the metadata space should be applied to the current region. This is important in the case of NVDIMMs since the firmware may change the interleaving configuration of a DIMM which would invalidate the existing labels. In our case the hypervisor hides those details from us so we don't really care, but libnvdimm still requires the interleave set cookie to be non-zero. For our purposes we just need the set cookie to be unique and fixed for a given PAPR SCM region and using the unit-guid (really a UUID) is fine for this purpose. Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions") Signed-off-by: Oliver O'Halloran <oohall@gmail.com> [mpe: Use kernel types (u64)] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 09 December 2018, 10:32:51 UTC
b0d65a8 Oliver O'Halloran 06 December 2018, 15:17:12 UTC powerpc/papr_scm: Fix DIMM device registration race When a new nvdimm device is registered with libnvdimm via nvdimm_create() it is added as a device on the nvdimm bus. The probe function for the DIMM driver is potentially quite slow so actually registering and probing the device is done in an async domain rather than immediately after device creation. This can result in a race where the region device (created 2nd) is probed first and fails to activate at boot. To fix this we use the same approach as the ACPI/NFIT driver which is to check that all the DIMM devices registered successfully. LibNVDIMM provides the nvdimm_bus_count_dimms() function which synchronises with the async domain and verifies that the dimm was successfully registered with the bus. If either of these does not occur then we bail. Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions") Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 09 December 2018, 10:32:30 UTC
409dd7d Oliver O'Halloran 06 December 2018, 15:17:11 UTC powerpc/papr_scm: Remove endian conversions The return values of a h-call are returned in the CPU registers and written to the provided buffer by the plpar_hcall() wrapper. As a result the values written to memory are always in the native endian and should not be byte swapped. The inital implementation of the H-Call interface was done in qemu and the returned values were byte swapped unnecessarily in both the hypervisor and in the driver so this was only noticed when bringing up the PowerVM implementation. Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions") Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 09 December 2018, 10:32:30 UTC
683ec0e Oliver O'Halloran 06 December 2018, 15:17:10 UTC powerpc/papr_scm: Update DT properties The ibm,unit-sizes property was originally specified as an array of two u32s corresponding to the memory block size, and the number of blocks available in that region. A fairly last-minute change to the SCM DT specification was splitting that into two seperate u64 properties: ibm,block-sizes and ibm,number-of-blocks that convey the same information. No firmware / hypervisor that emitted the ibm,unit-size property ever appeared in the wild. Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions") Signed-off-by: Oliver O'Halloran <oohall@gmail.com> [mpe: Use kernel types (u32/u64)] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 09 December 2018, 10:32:16 UTC
fa9c98e Takashi Sakamoto 09 December 2018, 08:04:19 UTC ALSA: fireface: fix reference to wrong register for clock configuration In an initial commit, 'SYNC_STATUS' register is referred to get clock configuration, however this is wrong, according to my local note at hand for reverse-engineering about packet dump. It should be 'CLOCK_CONFIG' register. Actually, ff400_dump_clock_config() is correctly programmed. This commit fixes the bug. Cc: <stable@vger.kernel.org> # v4.12+ Fixes: 76fdb3a9e13a ('ALSA: fireface: add support for Fireface 400') Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> 09 December 2018, 08:37:44 UTC
6ba189c Hui Wang 09 December 2018, 01:16:43 UTC ALSA: hda/realtek - Fix the mute LED regresion on Lenovo X1 Carbon Users reported a mute LED regression on Lenovo X1 Carbon, the root cause is we applied the fixup of ALC285_FIXUP_LENOVO_HEADPHONE_NOISE to this machine, then the machine can't apply the fixup of ALC269_FIXUP_THINKPAD_ACPI anymore. To fix it, we chain two fixup together. Fixes: c4cfcf6f4297 ("ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops") Cc: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> 09 December 2018, 07:43:34 UTC
bd5122c Tarick Bedeir 07 December 2018, 08:30:26 UTC net/mlx4_core: Correctly set PFC param if global pause is turned off. rx_ppp and tx_ppp can be set between 0 and 255, so don't clamp to 1. Fixes: 6e8814ceb7e8 ("net/mlx4_en: Fix mixed PFC and Global pause user control requests") Signed-off-by: Tarick Bedeir <tarick@google.com> Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 09 December 2018, 05:26:36 UTC
6ec067e Linus Torvalds 09 December 2018, 01:45:20 UTC Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal Pull thermal SoC fixes from Eduardo Valentin: "Fixes for armada and broadcom thermal drivers" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal: thermal: broadcom: constify thermal_zone_of_device_ops structure thermal: armada: constify thermal_zone_of_device_ops structure thermal: bcm2835: Switch to SPDX identifier thermal: armada: fix legacy resource fixup thermal: armada: fix legacy validity test sense 09 December 2018, 01:45:20 UTC
8214bdf Linus Torvalds 08 December 2018, 19:44:04 UTC Merge tag 'asm-generic-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic Pull asm-generic fix from Arnd Bergmann: "Multiple people reported a bug I introduced in asm-generic/unistd.h in 4.20, this is the obvious bugfix to get glibc and others to correctly build again on new architectures that no longer provide the old fstatat64() family of system calls" * tag 'asm-generic-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: asm-generic: unistd.h: fixup broken macro include. 08 December 2018, 19:44:04 UTC
570c913 Linus Torvalds 08 December 2018, 19:33:26 UTC Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "A few clk driver fixes this time: - Introduce protected-clock DT binding to fix breakage on qcom sdm845-mtp boards where the qspi clks introduced this merge window cause the firmware on those boards to take down the system if we try to read the clk registers - Fix a couple off-by-one errors found by Dan Carpenter - Handle failure in zynq fixed factor clk driver to avoid using uninitialized data" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: zynqmp: Off by one in zynqmp_is_valid_clock() clk: mmp: Off by one in mmp_clk_add() clk: mvebu: Off by one bugs in cp110_of_clk_get() arm64: dts: qcom: sdm845-mtp: Mark protected gcc clocks clk: qcom: Support 'protected-clocks' property dt-bindings: clk: Introduce 'protected-clocks' property clk: zynqmp: handle fixed factor param query error 08 December 2018, 19:33:26 UTC
f896adc Linus Torvalds 08 December 2018, 19:25:02 UTC Merge tag 'xfs-4.20-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux Pull xfs fixes from Darrick Wong: "Here are hopefully the last set of fixes for 4.20. There's a fix for a longstanding statfs reporting problem with project quotas, a correction for page cache invalidation behaviors when fallocating near EOF, and a fix for a broken metadata verifier return code. Finally, the most important fix is to the pipe splicing code (aka the generic copy_file_range fallback) to avoid pointless short directio reads by only asking the filesystem for as much data as there are available pages in the pipe buffer. Our previous fix (simulated short directio reads because the number of pages didn't match the length of the read requested) caused subtle problems on overlayfs, so that part is reverted. Anyhow, this series passes fstests -g all on xfs and overlay+xfs, and has passed 17 billion fsx operations problem-free since I started testing Summary: - Fix broken project quota inode counts - Fix incorrect PAGE_MASK/PAGE_SIZE usage - Fix incorrect return value in btree verifier - Fix WARN_ON remap flags false positive - Fix splice read overflows" * tag 'xfs-4.20-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: iomap: partially revert 4721a601099 (simulated directio short read on EFAULT) splice: don't read more than available pipe space vfs: allow some remap flags to be passed to vfs_clone_file_range xfs: fix inverted return from xfs_btree_sblock_verify_crc xfs: fix PAGE_MASK usage in xfs_free_file_space fs/xfs: fix f_ffree value for statfs when project quota is set 08 December 2018, 19:25:02 UTC
356ff8a David Rientjes 07 December 2018, 22:50:16 UTC Revert "mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask" This reverts commit 89c83fb539f95491be80cdd5158e6f0ce329e317. This should have been done as part of 2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations"). The movement of the thp allocation policy from alloc_pages_vma() to alloc_hugepage_direct_gfpmask() was intended to only set __GFP_THISNODE for mempolicies that are not MPOL_BIND whereas the revert could set this regardless of mempolicy. While the check for MPOL_BIND between alloc_hugepage_direct_gfpmask() and alloc_pages_vma() was racy, that has since been removed since the revert. What is left is the possibility to use __GFP_THISNODE in policy_node() when it is unexpected because the special handling for hugepages in alloc_pages_vma() was removed as part of the consolidation. Secondly, prior to 89c83fb539f9, alloc_pages_vma() implemented a somewhat different policy for hugepage allocations, which were allocated through alloc_hugepage_vma(). For hugepage allocations, if the allocating process's node is in the set of allowed nodes, allocate with __GFP_THISNODE for that node (for MPOL_PREFERRED, use that node with __GFP_THISNODE instead). This was changed for shmem_alloc_hugepage() to allow fallback to other nodes in 89c83fb539f9 as it did for new_page() in mm/mempolicy.c which is functionally different behavior and removes the requirement to only allocate hugepages locally. So this commit does a full revert of 89c83fb539f9 instead of the partial revert that was done in 2f0799a0ffc0. The result is the same thp allocation policy for 4.20 that was in 4.19. Fixes: 89c83fb539f9 ("mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask") Fixes: 2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations") Signed-off-by: David Rientjes <rientjes@google.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Michal Hocko <mhocko@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 08 December 2018, 18:26:20 UTC
5b3279e Benjamin Herrenschmidt 07 December 2018, 04:05:04 UTC Revert "net/ibm/emac: wrong bit is used for STA control" This reverts commit 624ca9c33c8a853a4a589836e310d776620f4ab9. This commit is completely bogus. The STACR register has two formats, old and new, depending on the version of the IP block used. There's a pair of device-tree properties that can be used to specify the format used: has-inverted-stacr-oc has-new-stacr-staopc What this commit did was to change the bit definition used with the old parts to match the new parts. This of course breaks the driver on all the old ones. Instead, the author should have set the appropriate properties in the device-tree for the variant used on his board. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: David S. Miller <davem@davemloft.net> 08 December 2018, 06:37:27 UTC
8b78903 David S. Miller 08 December 2018, 00:24:40 UTC Merge branch 'skb-headroom-slab-out-of-bounds' Stefano Brivio says: ==================== Fix slab out-of-bounds on insufficient headroom for IPv6 packets Patch 1/2 fixes a slab out-of-bounds occurring with short SCTP packets over IPv4 over L2TP over IPv6 on a configuration with relatively low HEADER_MAX. Patch 2/2 makes sure we avoid writing before the allocated buffer in neigh_hh_output() in case the headroom is enough for the unaligned hardware header size, but not enough for the aligned one, and that we warn if we hit this condition. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 08 December 2018, 00:24:40 UTC
e6ac64d Stefano Brivio 06 December 2018, 18:30:37 UTC neighbour: Avoid writing before skb->head in neigh_hh_output() While skb_push() makes the kernel panic if the skb headroom is less than the unaligned hardware header size, it will proceed normally in case we copy more than that because of alignment, and we'll silently corrupt adjacent slabs. In the case fixed by the previous patch, "ipv6: Check available headroom in ip6_xmit() even without options", we end up in neigh_hh_output() with 14 bytes headroom, 14 bytes hardware header and write 16 bytes, starting 2 bytes before the allocated buffer. Always check we're not writing before skb->head and, if the headroom is not enough, warn and drop the packet. v2: - instead of panicking with BUG_ON(), WARN_ON_ONCE() and drop the packet (Eric Dumazet) - if we avoid the panic, though, we need to explicitly check the headroom before the memcpy(), otherwise we'll have corrupted slabs on a running kernel, after we warn - use __skb_push() instead of skb_push(), as the headroom check is already implemented here explicitly (Eric Dumazet) Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> 08 December 2018, 00:24:40 UTC
66033f4 Stefano Brivio 06 December 2018, 18:30:36 UTC ipv6: Check available headroom in ip6_xmit() even without options Even if we send an IPv6 packet without options, MAX_HEADER might not be enough to account for the additional headroom required by alignment of hardware headers. On a configuration without HYPERV_NET, WLAN, AX25, and with IPV6_TUNNEL, sending short SCTP packets over IPv4 over L2TP over IPv6, we start with 100 bytes of allocated headroom in sctp_packet_transmit(), end up with 54 bytes after l2tp_xmit_skb(), and 14 bytes in ip6_finish_output2(). Those would be enough to append our 14 bytes header, but we're going to align that to 16 bytes, and write 2 bytes out of the allocated slab in neigh_hh_output(). KASan says: [ 264.967848] ================================================================== [ 264.967861] BUG: KASAN: slab-out-of-bounds in ip6_finish_output2+0x1aec/0x1c70 [ 264.967866] Write of size 16 at addr 000000006af1c7fe by task netperf/6201 [ 264.967870] [ 264.967876] CPU: 0 PID: 6201 Comm: netperf Not tainted 4.20.0-rc4+ #1 [ 264.967881] Hardware name: IBM 2827 H43 400 (z/VM 6.4.0) [ 264.967887] Call Trace: [ 264.967896] ([<00000000001347d6>] show_stack+0x56/0xa0) [ 264.967903] [<00000000017e379c>] dump_stack+0x23c/0x290 [ 264.967912] [<00000000007bc594>] print_address_description+0xf4/0x290 [ 264.967919] [<00000000007bc8fc>] kasan_report+0x13c/0x240 [ 264.967927] [<000000000162f5e4>] ip6_finish_output2+0x1aec/0x1c70 [ 264.967935] [<000000000163f890>] ip6_finish_output+0x430/0x7f0 [ 264.967943] [<000000000163fe44>] ip6_output+0x1f4/0x580 [ 264.967953] [<000000000163882a>] ip6_xmit+0xfea/0x1ce8 [ 264.967963] [<00000000017396e2>] inet6_csk_xmit+0x282/0x3f8 [ 264.968033] [<000003ff805fb0ba>] l2tp_xmit_skb+0xe02/0x13e0 [l2tp_core] [ 264.968037] [<000003ff80631192>] l2tp_eth_dev_xmit+0xda/0x150 [l2tp_eth] [ 264.968041] [<0000000001220020>] dev_hard_start_xmit+0x268/0x928 [ 264.968069] [<0000000001330e8e>] sch_direct_xmit+0x7ae/0x1350 [ 264.968071] [<000000000122359c>] __dev_queue_xmit+0x2b7c/0x3478 [ 264.968075] [<00000000013d2862>] ip_finish_output2+0xce2/0x11a0 [ 264.968078] [<00000000013d9b14>] ip_finish_output+0x56c/0x8c8 [ 264.968081] [<00000000013ddd1e>] ip_output+0x226/0x4c0 [ 264.968083] [<00000000013dbd6c>] __ip_queue_xmit+0x894/0x1938 [ 264.968100] [<000003ff80bc3a5c>] sctp_packet_transmit+0x29d4/0x3648 [sctp] [ 264.968116] [<000003ff80b7bf68>] sctp_outq_flush_ctrl.constprop.5+0x8d0/0xe50 [sctp] [ 264.968131] [<000003ff80b7c716>] sctp_outq_flush+0x22e/0x7d8 [sctp] [ 264.968146] [<000003ff80b35c68>] sctp_cmd_interpreter.isra.16+0x530/0x6800 [sctp] [ 264.968161] [<000003ff80b3410a>] sctp_do_sm+0x222/0x648 [sctp] [ 264.968177] [<000003ff80bbddac>] sctp_primitive_ASSOCIATE+0xbc/0xf8 [sctp] [ 264.968192] [<000003ff80b93328>] __sctp_connect+0x830/0xc20 [sctp] [ 264.968208] [<000003ff80bb11ce>] sctp_inet_connect+0x2e6/0x378 [sctp] [ 264.968212] [<0000000001197942>] __sys_connect+0x21a/0x450 [ 264.968215] [<000000000119aff8>] sys_socketcall+0x3d0/0xb08 [ 264.968218] [<000000000184ea7a>] system_call+0x2a2/0x2c0 [...] Just like ip_finish_output2() does for IPv4, check that we have enough headroom in ip6_xmit(), and reallocate it if we don't. This issue is older than git history. Reported-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> 08 December 2018, 00:24:40 UTC
f9bfe4e Eric Dumazet 06 December 2018, 17:58:24 UTC tcp: lack of available data can also cause TSO defer tcp_tso_should_defer() can return true in three different cases : 1) We are cwnd-limited 2) We are rwnd-limited 3) We are application limited. Neal pointed out that my recent fix went too far, since it assumed that if we were not in 1) case, we must be rwnd-limited Fix this by properly populating the is_cwnd_limited and is_rwnd_limited booleans. After this change, we can finally move the silly check for FIN flag only for the application-limited case. The same move for EOR bit will be handled in net-next, since commit 1c09f7d073b1 ("tcp: do not try to defer skbs with eor mark (MSG_EOR)") is scheduled for linux-4.21 Tested by running 200 concurrent netperf -t TCP_RR -- -r 60000,100 and checking none of them was rwnd_limited in the chrono_stat output from "ss -ti" command. Fixes: 41727549de3e ("tcp: Do not underestimate rwnd_limited") Signed-off-by: Eric Dumazet <edumazet@google.com> Suggested-by: Neal Cardwell <ncardwell@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Reviewed-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> 08 December 2018, 00:18:22 UTC
5f17979 Linus Torvalds 07 December 2018, 22:34:10 UTC Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost Pull vhost/virtio fixes from Michael Tsirkin: "A couple of last-minute fixes" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vhost/vsock: fix use-after-free in network stack callers virtio/s390: fix race in ccw_io_helper() virtio/s390: avoid race on vcdev->config vhost/vsock: fix reset orphans race with close timeout 07 December 2018, 22:34:10 UTC
b8bf469 Linus Torvalds 07 December 2018, 22:18:49 UTC Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Avoid sending IPIs with interrupts disabled" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: hibernate: Avoid sending cross-calling with interrupts disabled 07 December 2018, 22:18:49 UTC
1cdc362 Linus Torvalds 07 December 2018, 21:13:07 UTC Merge tag 'gcc-plugins-v4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull gcc stackleak plugin fixes from Kees Cook: - Remove tracing for inserted stack depth marking function (Anders Roxell) - Move gcc-plugin pass location to avoid objtool warnings (Alexander Popov) * tag 'gcc-plugins-v4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass stackleak: Mark stackleak_track_stack() as notrace 07 December 2018, 21:13:07 UTC
52ab2ec Linus Torvalds 07 December 2018, 21:07:10 UTC Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: - Disable the new crypto stats interface as it's still being changed - Fix potential uses-after-free in cbc/cfb/pcbc. * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: user - Disable statistics interface crypto: do not free algorithm before using 07 December 2018, 21:07:10 UTC
d57f9da Damien Le Moal 30 November 2018, 06:31:48 UTC dm zoned: Fix target BIO completion handling struct bioctx includes the ref refcount_t to track the number of I/O fragments used to process a target BIO as well as ensure that the zone of the BIO is kept in the active state throughout the lifetime of the BIO. However, since decrementing of this reference count is done in the target .end_io method, the function bio_endio() must be called multiple times for read and write target BIOs, which causes problems with the value of the __bi_remaining struct bio field for chained BIOs (e.g. the clone BIO passed by dm core is large and splits into fragments by the block layer), resulting in incorrect values and inconsistencies with the BIO_CHAIN flag setting. This is turn triggers the BUG_ON() call: BUG_ON(atomic_read(&bio->__bi_remaining) <= 0); in bio_remaining_done() called from bio_endio(). Fix this ensuring that bio_endio() is called only once for any target BIO by always using internal clone BIOs for processing any read or write target BIO. This allows reference counting using the target BIO context counter to trigger the target BIO completion bio_endio() call once all data, metadata and other zone work triggered by the BIO complete. Overall, this simplifies the code too as the target .end_io becomes unnecessary and differences between read and write BIO issuing and completion processing disappear. Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> 07 December 2018, 21:04:31 UTC
89f5fa4 Mike Snitzer 03 December 2018, 21:47:21 UTC dm: call blk_queue_split() to impose device limits on bios Otherwise the incoming bios, of various types, won't be shaped based on the DM device's advertised limits. Depends-on: af67c31fba ("blk: remove bio_set arg from blk_queue_split()") Fixes: 744889b7cb ("block: don't deal with discard limit in blkdev_issue_discard()") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@redhat.com> 07 December 2018, 21:04:22 UTC
687cf44 Mike Snitzer 09 November 2018, 16:56:03 UTC dm cache metadata: verify cache has blocks in blocks_are_clean_separate_dirty() Otherwise dm_bitset_cursor_begin() return -ENODATA. Other calls to dm_bitset_cursor_begin() have similar negative checks. Fixes inability to create a cache in passthrough mode (even though doing so makes no sense). Fixes: 0d963b6e65 ("dm cache metadata: fix metadata2 format's blocks_are_clean_separate_dirty") Cc: stable@vger.kernel.org Reported-by: David Teigland <teigland@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> 07 December 2018, 21:04:09 UTC
7b24f6c Linus Torvalds 07 December 2018, 20:58:34 UTC Merge tag 'pci-v4.20-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: "Revert ASPM change that caused a regression" * tag 'pci-v4.20-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: Revert "PCI/ASPM: Do not initialize link state when aspm_disabled is set" 07 December 2018, 20:58:34 UTC
1b4e5ad Shmulik Ladkani 07 December 2018, 07:50:17 UTC ipv6: sr: properly initialize flowi6 prior passing to ip6_route_output In 'seg6_output', stack variable 'struct flowi6 fl6' was missing initialization. Fixes: 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels") Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> 07 December 2018, 20:22:39 UTC
0b43a29 Linus Torvalds 07 December 2018, 18:40:37 UTC Merge tag 'for-linus-20181207' of git://git.kernel.dk/linux-block Pull block fixes from Jens Axboe: "Let's try this again... We're finally happy with the DM livelock issue, and it's also passed overnight testing and the corruption regression test. The end result is much nicer now too, which is great. Outside of that fix, there's a pull request for NVMe with two small fixes, and a regression fix for BFQ from this merge window. The BFQ fix looks bigger than it is, it's 90% comment updates" * tag 'for-linus-20181207' of git://git.kernel.dk/linux-block: blk-mq: punt failed direct issue to dispatch list nvmet-rdma: fix response use after free nvme: validate controller state before rescheduling keep alive block, bfq: fix decrement of num_active_groups 07 December 2018, 18:40:37 UTC
52f842c Linus Torvalds 07 December 2018, 18:31:31 UTC Merge branch 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "A set of driver bugfixes for the I2C subsystem" * 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: uniphier-f: fix violation of tLOW requirement for Fast-mode i2c: uniphier: fix violation of tLOW requirement for Fast-mode i2c: uniphier-f: fill TX-FIFO only in IRQ handler for repeated START i2c: uniphier-f: fix timeout error after reading 8 bytes i2c: scmi: Fix probe error on devices with an empty SMB0001 ACPI device node i2c: axxia: properly handle master timeout i2c: rcar: check bus state before reinitializing i2c: nvidia-gpu: limit reads also for combined messages i2c: nvidia-gpu: adhere to I2C fault codes 07 December 2018, 18:31:31 UTC
c431b42 Linus Torvalds 07 December 2018, 17:58:34 UTC Merge tag 'dmaengine-fix-4.20-rc6' of git://git.infradead.org/users/vkoul/slave-dma Pull dmaengine fixes from Vinod Koul: "Another pull request for dmaengine. We got bunch of fixes early this week and all are tagged to stable. Hope this is last fix for this cycle: - Fix imx-sdma handling of channel terminations, this involves reverting two commits and implement async termination - Fix cppi dma channel deletion from pending list on stop - Fix FIFO size for dw controller in Intel Merrifield" * tag 'dmaengine-fix-4.20-rc6' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: dw: Fix FIFO size for Intel Merrifield dmaengine: cppi41: delete channel from pending list when stop channel dmaengine: imx-sdma: use GFP_NOWAIT for dma descriptor allocations dmaengine: imx-sdma: implement channel termination via worker Revert "dmaengine: imx-sdma: alloclate bd memory from dma pool" Revert "dmaengine: imx-sdma: Use GFP_NOWAIT for dma allocations" 07 December 2018, 17:58:34 UTC
ac3e233 Nick Desaulniers 06 December 2018, 19:12:31 UTC x86/vdso: Drop implicit common-page-size linker flag GNU linker's -z common-page-size's default value is based on the target architecture. arch/x86/entry/vdso/Makefile sets it to the architecture default, which is implicit and redundant. Drop it. Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu") Reported-by: Dmitry Golovin <dima@golovin.in> Reported-by: Bill Wendling <morbo@google.com> Suggested-by: Dmitry Golovin <dima@golovin.in> Suggested-by: Rui Ueyama <ruiu@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Andy Lutomirski <luto@kernel.org> Cc: Andi Kleen <andi@firstfloor.org> Cc: Fangrui Song <maskray@google.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulniers@google.com Link: https://bugs.llvm.org/show_bug.cgi?id=38774 Link: https://github.com/ClangBuiltLinux/linux/issues/31 07 December 2018, 17:57:38 UTC
153573d Alex Deucher 17 October 2018, 16:24:26 UTC drm/amdgpu: update smu firmware images for VI variants (v2) Some new variants require updated firmware. V2: add MODULE_FIRMWARE for new firmwares Reviewed-by: Huang Rui <ray.huang@amd.com> (v1) Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org 07 December 2018, 16:15:12 UTC
b4aecf7 Will Deacon 07 December 2018, 12:47:10 UTC arm64: hibernate: Avoid sending cross-calling with interrupts disabled Since commit 3b8c9f1cdfc50 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings"), a call to flush_icache_range() will use an IPI to cross-call other online CPUs so that any stale instructions are flushed from their pipelines. This triggers a WARN during the hibernation resume path, where flush_icache_range() is called with interrupts disabled and is therefore prone to deadlock: | Disabling non-boot CPUs ... | CPU1: shutdown | psci: CPU1 killed. | CPU2: shutdown | psci: CPU2 killed. | CPU3: shutdown | psci: CPU3 killed. | WARNING: CPU: 0 PID: 1 at ../kernel/smp.c:416 smp_call_function_many+0xd4/0x350 | Modules linked in: | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc4 #1 Since all secondary CPUs have been taken offline prior to invalidating the I-cache, there's actually no need for an IPI and we can simply call __flush_icache_range() instead. Cc: <stable@vger.kernel.org> Fixes: 3b8c9f1cdfc50 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings") Reported-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Tested-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Tested-by: James Morse <james.morse@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> 07 December 2018, 15:52:39 UTC
8b878ee Jens Axboe 07 December 2018, 15:40:13 UTC Merge branch 'nvme-4.20' of git://git.infradead.org/nvme into for-linus Pull NVMe fixes from Christoph. * 'nvme-4.20' of git://git.infradead.org/nvme: nvmet-rdma: fix response use after free nvme: validate controller state before rescheduling keep alive 07 December 2018, 15:40:13 UTC
c616cbe Jens Axboe 07 December 2018, 05:17:44 UTC blk-mq: punt failed direct issue to dispatch list After the direct dispatch corruption fix, we permanently disallow direct dispatch of non read/write requests. This works fine off the normal IO path, as they will be retried like any other failed direct dispatch request. But for the blk_insert_cloned_request() that only DM uses to bypass the bottom level scheduler, we always first attempt direct dispatch. For some types of requests, that's now a permanent failure, and no amount of retrying will make that succeed. This results in a livelock. Instead of making special cases for what we can direct issue, and now having to deal with DM solving the livelock while still retaining a BUSY condition feedback loop, always just add a request that has been through ->queue_rq() to the hardware queue dispatch list. These are safe to use as no merging can take place there. Additionally, if requests do have prepped data from drivers, we aren't dependent on them not sharing space in the request structure to safely add them to the IO scheduler lists. This basically reverts ffe81d45322c and is based on a patch from Ming, but with the list insert case covered as well. Fixes: ffe81d45322c ("blk-mq: fix corruption with direct issue") Cc: stable@vger.kernel.org Suggested-by: Ming Lei <ming.lei@redhat.com> Reported-by: Bart Van Assche <bvanassche@acm.org> Tested-by: Ming Lei <ming.lei@redhat.com> Acked-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> 07 December 2018, 15:16:11 UTC
d7dcdf9 Israel Rukshin 05 December 2018, 16:54:57 UTC nvmet-rdma: fix response use after free nvmet_rdma_release_rsp() may free the response before using it at error flow. Fixes: 8407879 ("nvmet-rdma: fix possible bogus dereference under heavy load") Signed-off-by: Israel Rukshin <israelr@mellanox.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Max Gurtovoy <maxg@mellanox.com> Signed-off-by: Christoph Hellwig <hch@lst.de> 07 December 2018, 15:11:11 UTC
86880d6 James Smart 28 November 2018, 01:04:44 UTC nvme: validate controller state before rescheduling keep alive Delete operations are seeing NULL pointer references in call_timer_fn. Tracking these back, the timer appears to be the keep alive timer. nvme_keep_alive_work() which is tied to the timer that is cancelled by nvme_stop_keep_alive(), simply starts the keep alive io but doesn't wait for it's completion. So nvme_stop_keep_alive() only stops a timer when it's pending. When a keep alive is in flight, there is no timer running and the nvme_stop_keep_alive() will have no affect on the keep alive io. Thus, if the io completes successfully, the keep alive timer will be rescheduled. In the failure case, delete is called, the controller state is changed, the nvme_stop_keep_alive() is called while the io is outstanding, and the delete path continues on. The keep alive happens to successfully complete before the delete paths mark it as aborted as part of the queue termination, so the timer is restarted. The delete paths then tear down the controller, and later on the timer code fires and the timer entry is now corrupt. Fix by validating the controller state before rescheduling the keep alive. Testing with the fix has confirmed the condition above was hit. Signed-off-by: James Smart <jsmart2021@gmail.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de> 07 December 2018, 15:11:11 UTC
ba7aeae Paolo Valente 06 December 2018, 18:18:18 UTC block, bfq: fix decrement of num_active_groups Since commit '2d29c9f89fcd ("block, bfq: improve asymmetric scenarios detection")', if there are process groups with I/O requests waiting for completion, then BFQ tags the scenario as 'asymmetric'. This detection is needed for preserving service guarantees (for details, see comments on the computation * of the variable asymmetric_scenario in the function bfq_better_to_idle). Unfortunately, commit '2d29c9f89fcd ("block, bfq: improve asymmetric scenarios detection")' contains an error exactly in the updating of the number of groups with I/O requests waiting for completion: if a group has more than one descendant process, then the above number of groups, which is renamed from num_active_groups to a more appropriate num_groups_with_pending_reqs by this commit, may happen to be wrongly decremented multiple times, namely every time one of the descendant processes gets all its pending I/O requests completed. A correct, complete solution should work as follows. Consider a group that is inactive, i.e., that has no descendant process with pending I/O inside BFQ queues. Then suppose that num_groups_with_pending_reqs is still accounting for this group, because the group still has some descendant process with some I/O request still in flight. num_groups_with_pending_reqs should be decremented when the in-flight request of the last descendant process is finally completed (assuming that nothing else has changed for the group in the meantime, in terms of composition of the group and active/inactive state of child groups and processes). To accomplish this, an additional pending-request counter must be added to entities, and must be updated correctly. To avoid this additional field and operations, this commit resorts to the following tradeoff between simplicity and accuracy: for an inactive group that is still counted in num_groups_with_pending_reqs, this commit decrements num_groups_with_pending_reqs when the first descendant process of the group remains with no request waiting for completion. This simplified scheme provides a fix to the unbalanced decrements introduced by 2d29c9f89fcd. Since this error was also caused by lack of comments on this non-trivial issue, this commit also adds related comments. Fixes: 2d29c9f89fcd ("block, bfq: improve asymmetric scenarios detection") Reported-by: Steven Barrett <steven@liquorix.net> Tested-by: Steven Barrett <steven@liquorix.net> Tested-by: Lucjan Lucjanov <lucjan.lucjanov@gmail.com> Reviewed-by: Federico Motta <federico@willer.it> Signed-off-by: Paolo Valente <paolo.valente@linaro.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> 07 December 2018, 14:40:07 UTC
c201e38 Peter Hutterer 05 December 2018, 23:03:36 UTC Input: restore EV_ABS ABS_RESERVED ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of ffe0e7cf290f5c9 when the high-resolution scrolling code was removed. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> 07 December 2018, 14:13:40 UTC
868613f Nic Soudée 06 December 2018, 16:59:25 UTC HID: quirks: fix RetroUSB.com devices SNES RetroPort and RetroPad register only 4 gamepad buttons when they should register all 8 buttons. This is described here: https://ask.fedoraproject.org/en/question/128102 This is happening because of: Commit 190d7f02ce8e ("HID: input: do not increment usages when duplicate is found") Here, I add the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE (created for backward compatibility with the change in 190d7f02ce8e) for the two products. Tested with both RetroPort and RetroPad. Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Nic Soudée <nsoudee@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> 07 December 2018, 13:12:34 UTC
dbde117 Greg Kroah-Hartman 07 December 2018, 13:05:28 UTC Merge tag 'gnss-4.20-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/gnss into char-misc-linus Johan writes: GNSS fixes for 4.20-rc6 Here's a fix for a broken activation retry loop in the sirf driver. Included are also two MAINTAINERS updates. All have been in linux-next with no reported issues. Signed-off-by: Johan Hovold <johan@kernel.org> * tag 'gnss-4.20-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/gnss: MAINTAINERS: exclude gnss from SIRFPRIMA2 regex matching MAINTAINERS: add gnss scm tree gnss: sirf: fix activation retry handling 07 December 2018, 13:05:28 UTC
478b676 Chen-Yu Tsai 04 December 2018, 09:04:57 UTC pinctrl: sunxi: a83t: Fix IRQ offset typo for PH11 Pin PH11 is used on various A83T board to detect a change in the OTG port's ID pin, as in when an OTG host cable is plugged in. The incorrect offset meant the gpiochip/irqchip was activating the wrong pin for interrupts. Fixes: 4730f33f0d82 ("pinctrl: sunxi: add allwinner A83T PIO controller support") Cc: <stable@vger.kernel.org> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 07 December 2018, 12:32:19 UTC
5961352 Oliver O'Halloran 06 December 2018, 15:17:09 UTC powerpc/papr_scm: Fix resource end address Fix an off-by-one error in the memory resource range. This resource is used to determine the address range of the memory to be hot-plugged as ZONE_DEVICE memory. The current end address results in the kernel attempting to map an additional memblock and the hypervisor may reject the mapping resulting in the entire hot-plug failing. Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions") Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 07 December 2018, 12:32:02 UTC
14ebfec Oliver O'Halloran 06 December 2018, 15:17:08 UTC powerpc/papr_scm: Use depend instead of select Making PAPR_SCM select LIBNVDIMM results in circular dependencies in Kconfig when another symbol depends on it. Fix this by replacing the select with a depends. Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions") Reported-by: Alastair D'Silva <alastair@d-silva.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 07 December 2018, 12:32:01 UTC
a6460b0 Sandipan Das 06 December 2018, 09:27:01 UTC powerpc/bpf: Fix broken uapi for BPF_PROG_TYPE_PERF_EVENT Now that there are different variants of pt_regs for userspace and kernel, the uapi for the BPF_PROG_TYPE_PERF_EVENT program type must be changed by exporting the user_pt_regs structure instead of the pt_regs structure that is in-kernel only. Fixes: 002af9391bfb ("powerpc: Split user/kernel definitions of struct pt_regs") Signed-off-by: Sandipan Das <sandipan@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 07 December 2018, 12:19:04 UTC
bde1a74 Kailang Yang 07 December 2018, 07:14:59 UTC ALSA: hda/realtek - Fixed headphone issue for ALC700 If it plugged headphone or headset into the jack, then do the reboot, it will have a chance to cause headphone no sound. It just need to run the headphone mode procedure after boot time. The issue will be fixed. It also suitable for ALC234 ALC274 and ALC294. Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> 07 December 2018, 09:18:52 UTC
6ac7929 Long Li 06 December 2018, 04:51:06 UTC CIFS: Avoid returning EBUSY to upper layer VFS EBUSY is not handled by VFS, and will be passed to user-mode. This is not correct as we need to wait for more credits. This patch also fixes a bug where rsize or wsize is used uninitialized when the call to server->ops->wait_mtu_credits() fails. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Long Li <longli@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> 07 December 2018, 06:59:23 UTC
e61efff Herbert Xu 07 December 2018, 05:56:08 UTC crypto: user - Disable statistics interface Since this user-space API is still undergoing significant changes, this patch disables it for the current merge window. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 07 December 2018, 05:56:08 UTC
d387ac1 Linus Torvalds 07 December 2018, 03:35:50 UTC Merge tag 'drm-fixes-2018-12-07' of git://anongit.freedesktop.org/drm/drm Pull drm fixes from Dave Airlie: "There's a bit more in here than I'd like, and I'm hoping things calm down when I'm out. msm: - a bunch of display fixes for the new DPU - a couple of command submission fixes omap: - some DSI fixes ast: - driver unload crash fix core: - fix the lease uevent so userspace can distinguish it amd: - fix a bpc regression - fix lru handling regression - fixed firmware support for new GPUs - power management fixes for vega20" * tag 'drm-fixes-2018-12-07' of git://anongit.freedesktop.org/drm/drm: (37 commits) drm/ast: Fix connector leak during driver unload drm/amdgpu/vcn: Update vcn.cur_state during suspend drm/amd/display: Fix overflow/truncation from strncpy. drm/amd/powerplay: improve OD code robustness drm/amdgpu: enlarge maximum waiting time of KIQ drm/fb-helper: Fix typo in parameter description drm/amd/powerplay: support SoftMin/Max setting for some specific DPM drm/amd/powerplay: issue pre-display settings for display change event drm/amd/powerplay: support new pptable upload on Vega20 drm/amdgpu/gmc8: always load MC firmware in the driver drm/amdgpu/gmc8: update MC firmware for polaris drm/amdgpu: update mc firmware image for polaris12 variants drm/msm: Fix error return checking drm/msm/dpu: Ignore alpha for XBGR8888 format drm/msm: dpu: Fix "WARNING: invalid free of devm_ allocated data" drm/msm/hdmi: Drop pointless static qualifier in msm_hdmi_bind() drm/msm: Move fence put to where failure occurs drm/msm: dpu: Don't set legacy plane->crtc pointer drm/msm/gpu: Don't map command buffers with nr_relocs equal to 0 drm/msm/hdmi: Enable HPD after HDMI IRQ is set up ... 07 December 2018, 03:35:50 UTC
7f80c73 Linus Torvalds 07 December 2018, 02:57:04 UTC Merge tag 'nfs-for-4.20-5' of git://git.linux-nfs.org/projects/trondmy/linux-nfs Pull NFS client bugfixes from Trond Myklebust: "This is mainly fallout from the updates to the SUNRPC code that is being triggered from less common combinations of NFS mount options. Highlights include: Stable fixes: - Fix a page leak when using RPCSEC_GSS/krb5p to encrypt data. Bugfixes: - Fix a regression that causes the RPC receive code to hang - Fix call_connect_status() so that it handles tasks that got transmitted while queued waiting for the socket lock. - Fix a memory leak in call_encode() - Fix several other connect races. - Fix receive code error handling. - Use the discard iterator rather than MSG_TRUNC for compatibility with AF_UNIX/AF_LOCAL sockets. - nfs: don't dirty kernel pages read by direct-io - pnfs/Flexfiles fix to enforce per-mirror stateid only for NFSv4 data servers" * tag 'nfs-for-4.20-5' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: SUNRPC: Don't force a redundant disconnection in xs_read_stream() SUNRPC: Fix up socket polling SUNRPC: Use the discard iterator rather than MSG_TRUNC SUNRPC: Treat EFAULT as a truncated message in xs_read_stream_request() SUNRPC: Fix up handling of the XDRBUF_SPARSE_PAGES flag SUNRPC: Fix RPC receive hangs SUNRPC: Fix a potential race in xprt_connect() SUNRPC: Fix a memory leak in call_encode() SUNRPC: Fix leak of krb5p encode pages SUNRPC: call_connect_status() must handle tasks that got transmitted nfs: don't dirty kernel pages read by direct-io flexfiles: enforce per-mirror stateid only for v4 DSes 07 December 2018, 02:57:04 UTC
b72f711 Linus Torvalds 07 December 2018, 00:45:36 UTC Merge branch 'spectre' of git://git.armlinux.org.uk/~rmk/linux-arm Pull ARM spectre fix from Russell King: "Exynos folk noticed that CPU hotplug wasn't working with their kernel configuration, and have tested this as fixing the problem" * 'spectre' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: ensure that processor vtables is not lost after boot 07 December 2018, 00:45:36 UTC
7e40b56 Linus Torvalds 07 December 2018, 00:39:44 UTC Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm Pull ARM fixes from Russell King: "Some small fixes that have been accumulated: - Chris Cole noticed that in a SMP environment, the DMA cache coherence handling can produce undesirable results in a corner case - Propagate that fix for ARMv7M as well - Fix a false positive with source fortification - Fix an uninitialised return that Nathan Jones spotted" * 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 8816/1: dma-mapping: fix potential uninitialized return ARM: 8815/1: V7M: align v7m_dma_inv_range() with v7 counterpart ARM: 8814/1: mm: improve/fix ARM v7_dma_inv_range() unaligned address handling ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE 07 December 2018, 00:39:44 UTC
ece27a3 Masahiro Yamada 06 December 2018, 03:55:28 UTC i2c: uniphier-f: fix violation of tLOW requirement for Fast-mode Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode, tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us. tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode: Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us Fast-mode: tLOW = 1.39 us, tHIGH = 1.11 us Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 06 December 2018, 22:14:59 UTC
8469636 Masahiro Yamada 06 December 2018, 03:55:27 UTC i2c: uniphier: fix violation of tLOW requirement for Fast-mode Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode, tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us. tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode: Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us Fast-mode: tLOW = 1.39 us, tHIGH = 1.11 us Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 06 December 2018, 22:14:59 UTC
cd8843f Masahiro Yamada 06 December 2018, 03:55:26 UTC i2c: uniphier-f: fill TX-FIFO only in IRQ handler for repeated START - For a repeated START condition, this controller starts data transfer immediately after the slave address is written to the TX-FIFO. - Once the TX-FIFO empty interrupt is asserted, the controller makes a pause even if additional data are written to the TX-FIFO. Given those circumstances, the data after a repeated START may not be transferred if the interrupt is asserted while the TX-FIFO is being filled up. A more reliable way is to append TX data only in the interrupt handler. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 06 December 2018, 22:14:59 UTC
c2a653d Masahiro Yamada 06 December 2018, 03:55:25 UTC i2c: uniphier-f: fix timeout error after reading 8 bytes I was totally screwed up in commit eaba68785c2d ("i2c: uniphier-f: fix race condition when IRQ is cleared"). Since that commit, if the number of read bytes is multiple of the FIFO size (8, 16, 24... bytes), the STOP condition could be issued twice, depending on the timing. If this happens, the controller will go wrong, resulting in the timeout error. It was more than 3 years ago when I wrote this driver, so my memory about this hardware was vague. Please let me correct the description in the commit log of eaba68785c2d. Clearing the IRQ status on exiting the IRQ handler is absolutely fine. This controller makes a pause while any IRQ status is asserted. If the IRQ status is cleared first, the hardware may start the next transaction before the IRQ handler finishes what it supposed to do. This partially reverts the bad commit with clear comments so that I will never repeat this mistake. I also investigated what is happening at the last moment of the read mode. The UNIPHIER_FI2C_INT_RF interrupt is asserted a bit earlier (by half a period of the clock cycle) than UNIPHIER_FI2C_INT_RB. I consulted a hardware engineer, and I got the following information: UNIPHIER_FI2C_INT_RF asserted at the falling edge of SCL at the 8th bit. UNIPHIER_FI2C_INT_RB asserted at the rising edge of SCL at the 9th (ACK) bit. In order to avoid calling uniphier_fi2c_stop() twice, check the latter interrupt. I also commented this because it is obscure hardware internal. Fixes: eaba68785c2d ("i2c: uniphier-f: fix race condition when IRQ is cleared") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 06 December 2018, 22:14:59 UTC
0544ee4 Hans de Goede 21 November 2018, 09:19:55 UTC i2c: scmi: Fix probe error on devices with an empty SMB0001 ACPI device node Some AMD based HP laptops have a SMB0001 ACPI device node which does not define any methods. This leads to the following error in dmesg: [ 5.222731] cmi: probe of SMB0001:00 failed with error -5 This commit makes acpi_smbus_cmi_add() return -ENODEV instead in this case silencing the error. In case of a failure of the i2c_add_adapter() call this commit now propagates the error from that call instead of -EIO. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 06 December 2018, 22:14:59 UTC
6c7f25c Adamski, Krzysztof (Nokia - PL/Wroclaw) 16 November 2018, 13:24:41 UTC i2c: axxia: properly handle master timeout According to Intel (R) Axxia TM Lionfish Communication Processor Peripheral Subsystem Hardware Reference Manual, the AXXIA I2C module have a programmable Master Wait Timer, which among others, checks the time between commands send in manual mode. When a timeout (25ms) passes, TSS bit is set in Master Interrupt Status register and a Stop command is issued by the hardware. The axxia_i2c_xfer(), does not properly handle this situation, however. For each message a separate axxia_i2c_xfer_msg() is called and this function incorrectly assumes that any interrupt might happen only when waiting for completion. This is mostly correct but there is one exception - a master timeout can trigger if enough time has passed between individual transfers. It will, by definition, happen between transfers when the interrupts are disabled by the code. If that happens, the hardware issues Stop command. The interrupt indicating timeout will not be triggered as soon as we enable them since the Master Interrupt Status is cleared when master mode is entered again (which happens before enabling irqs) meaning this error is lost and the transfer is continued even though the Stop was issued on the bus. The subsequent operations completes without error but a bogus value (0xFF in case of read) is read as the client device is confused because aborted transfer. No error is returned from master_xfer() making caller believe that a valid value was read. To fix the problem, the TSS bit (indicating timeout) in Master Interrupt Status register is checked before each transfer. If it is set, there was a timeout before this transfer and (as described above) the hardware already issued Stop command so the transaction should be aborted thus -ETIMEOUT is returned from the master_xfer() callback. In order to be sure no timeout was issued we can't just read the status just before starting new transaction as there will always be a small window of time (few CPU cycles at best) where this might still happen. For this reason we have to temporally disable the timer before checking for TSS bit. Disabling it will, however, clear the TSS bit so in order to preserve that information, we have to read it in ISR so we have to ensure that the TSS interrupt is not masked between transfers of one transaction. There is no need to call bus recovery or controller reinitialization if that happens so it's skipped. Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 06 December 2018, 22:14:53 UTC
cd9d1a2 David S. Miller 06 December 2018, 21:31:09 UTC Merge branch 'mlxsw-Various-fixes' Ido Schimmel says: ==================== mlxsw: Various fixes Patches #1 and #2 fix two VxLAN related issues. The first patch removes warnings that can currently be triggered from user space. Second patch avoids leaking a FID in an error path. Patch #3 fixes a too strict check that causes certain host routes not to be promoted to perform GRE decapsulation in hardware. Last patch avoids a use-after-free when deleting a VLAN device via an ioctl when it is enslaved to a bridge. I have a patchset for net-next that reworks this code and makes the driver more robust. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 06 December 2018, 21:31:09 UTC
993107f Ido Schimmel 06 December 2018, 17:44:53 UTC mlxsw: spectrum_switchdev: Fix VLAN device deletion via ioctl When deleting a VLAN device using an ioctl the netdev is unregistered before the VLAN filter is updated via ndo_vlan_rx_kill_vid(). It can lead to a use-after-free in mlxsw in case the VLAN device is deleted while being enslaved to a bridge. The reason for the above is that when mlxsw receives the CHANGEUPPER event, it wrongly assumes that the VLAN device is no longer its upper and thus destroys the internal representation of the bridge port despite the reference count being non-zero. Fix this by checking if the VLAN device is our upper using its real device. In net-next I'm going to remove this trick and instead make mlxsw completely agnostic to the order of the events. Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 06 December 2018, 21:31:09 UTC
da93d29 Nir Dotan 06 December 2018, 17:44:52 UTC mlxsw: spectrum_router: Relax GRE decap matching check GRE decap offload is configured when local routes prefix correspond to the local address of one of the offloaded GRE tunnels. The matching check was found to be too strict, such that for a flat GRE configuration, in which the overlay and underlay traffic share the same non-default VRF, decap flow was not offloaded. Relax the check for decap flow offloading. A match occurs if the local address of the tunnel matches the local route address while both share the same VRF table. Fixes: 4607f6d26950 ("mlxsw: spectrum_router: Support IPv4 underlay decap") Signed-off-by: Nir Dotan <nird@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 06 December 2018, 21:31:08 UTC
f58a83c Ido Schimmel 06 December 2018, 17:44:51 UTC mlxsw: spectrum_switchdev: Avoid leaking FID's reference count It should never be possible for a user to set a VNI on a FID in case one is already set. The driver therefore returns an error, but fails to drop the reference count taken earlier when calling mlxsw_sp_fid_8021d_lookup(). Drop the reference when this unlikely error is hit. Fixes: 1c30d1836aeb ("mlxsw: spectrum: Enable VxLAN enslavement to bridges") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 06 December 2018, 21:31:08 UTC
050fc01 Ido Schimmel 06 December 2018, 17:44:50 UTC mlxsw: spectrum_nve: Remove easily triggerable warnings It is possible to trigger a warning in mlxsw in case a flood entry which mlxsw is not aware of is deleted from the VxLAN device. This is because mlxsw expects to find a singly linked list where the flood entry is present in. Fix by removing these warnings for now. Will re-add them in the next release after we teach mlxsw to ask for a dump of FDB entries from the VxLAN device, once it is enslaved to a bridge mlxsw cares about. Fixes: 6e6030bd5412 ("mlxsw: spectrum_nve: Implement common NVE core") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> 06 December 2018, 21:31:08 UTC
834e772 Stefan Hajnoczi 05 November 2018, 10:35:47 UTC vhost/vsock: fix use-after-free in network stack callers If the network stack calls .send_pkt()/.cancel_pkt() during .release(), a struct vhost_vsock use-after-free is possible. This occurs because .release() does not wait for other CPUs to stop using struct vhost_vsock. Switch to an RCU-enabled hashtable (indexed by guest CID) so that .release() can wait for other CPUs by calling synchronize_rcu(). This also eliminates vhost_vsock_lock acquisition in the data path so it could have a positive effect on performance. This is CVE-2018-14625 "kernel: use-after-free Read in vhost_transport_send_pkt". Cc: stable@vger.kernel.org Reported-and-tested-by: syzbot+bd391451452fb0b93039@syzkaller.appspotmail.com Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com Reported-by: syzbot+d5a0a170c5069658b141@syzkaller.appspotmail.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> 06 December 2018, 19:28:38 UTC
78b1a52 Halil Pasic 26 September 2018, 16:48:30 UTC virtio/s390: fix race in ccw_io_helper() While ccw_io_helper() seems like intended to be exclusive in a sense that it is supposed to facilitate I/O for at most one thread at any given time, there is actually nothing ensuring that threads won't pile up at vcdev->wait_q. If they do, all threads get woken up and see the status that belongs to some other request than their own. This can lead to bugs. For an example see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432 This race normally does not cause any problems. The operations provided by struct virtio_config_ops are usually invoked in a well defined sequence, normally don't fail, and are normally used quite infrequent too. Yet, if some of the these operations are directly triggered via sysfs attributes, like in the case described by the referenced bug, userspace is given an opportunity to force races by increasing the frequency of the given operations. Let us fix the problem by ensuring, that for each device, we finish processing the previous request before starting with a new one. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reported-by: Colin Ian King <colin.king@canonical.com> Cc: stable@vger.kernel.org Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> 06 December 2018, 19:22:35 UTC
2448a29 Halil Pasic 26 September 2018, 16:48:29 UTC virtio/s390: avoid race on vcdev->config Currently we have a race on vcdev->config in virtio_ccw_get_config() and in virtio_ccw_set_config(). This normally does not cause problems, as these are usually infrequent operations. However, for some devices writing to/reading from the config space can be triggered through sysfs attributes. For these, userspace can force the race by increasing the frequency. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Cc: stable@vger.kernel.org Message-Id: <20180925121309.58524-2-pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> 06 December 2018, 19:22:34 UTC
c38f57d Stefan Hajnoczi 06 December 2018, 19:14:34 UTC vhost/vsock: fix reset orphans race with close timeout If a local process has closed a connected socket and hasn't received a RST packet yet, then the socket remains in the table until a timeout expires. When a vhost_vsock instance is released with the timeout still pending, the socket is never freed because vhost_vsock has already set the SOCK_DONE flag. Check if the close timer is pending and let it close the socket. This prevents the race which can leak sockets. Reported-by: Maximilian Riemensberger <riemensberger@cadami.net> Cc: Graham Whaley <graham.whaley@gmail.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> 06 December 2018, 19:22:34 UTC
abb8d6e Linus Torvalds 06 December 2018, 18:35:19 UTC Merge tag 'trace-v4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fix from Steven Rostedt: "This is a single commit that fixes a bug in uprobes SDT code due to a missing mutex protection" * tag 'trace-v4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: Uprobes: Fix kernel oops with delayed_uprobe_remove() 06 December 2018, 18:35:19 UTC
2acee31 Linus Torvalds 06 December 2018, 17:25:53 UTC Merge tag 'sound-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Still more incoming fixes than wished at this stage, but all look like small and reasonable fixes. In addition to the usual HD-audio and USB-audio quirks for various devices, two notable changes are included: - a fix for USB-audio UAF at probing a malformed descriptor - workarounds for PCM rwsem mutex starvation" * tag 'sound-4.20-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G ALSA: hda/realtek - Add support for Acer Aspire C24-860 headset mic ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880 ALSA: usb-audio: Fix UAF decrement if card has no live interfaces in card.c ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570 ALSA: pcm: Fix interval evaluation with openmin/max ALSA: hda: Add support for AMD Stoney Ridge ALSA: usb-audio: Add SMSL D1 to quirks for native DSD support ALSA: pcm: Fix starvation on down_write_nonblock() ALSA: pcm: Call snd_pcm_unlink() conditionally at closing 06 December 2018, 17:25:53 UTC
002f421 Linus Torvalds 06 December 2018, 17:23:34 UTC Merge tag 'csky-4.20-rc6' of github.com:c-sky/csky-linux Pull C-SKY fixes from Guo Ren: - bugfix for tlb_get_pgd() error - update MAINTAINERS file for C-SKY drivers * tag 'csky-4.20-rc6' of github.com:c-sky/csky-linux: csky: bugfix tlb_get_pgd error. MAINTAINERS: add maintainer for C-SKY drivers 06 December 2018, 17:23:34 UTC
ffe843b Andy Shevchenko 05 December 2018, 16:33:59 UTC dmaengine: dw: Fix FIFO size for Intel Merrifield Intel Merrifield has a reduced size of FIFO used in iDMA 32-bit controller, i.e. 512 bytes instead of 1024. Fix this by partitioning it as 64 bytes per channel. Note, in the future we might switch to 'fifo-size' property instead of hard coded value. Fixes: 199244d69458 ("dmaengine: dw: add support of iDMA 32-bit hardware") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org> 06 December 2018, 17:23:05 UTC
8fb2dfb Alexander Popov 06 December 2018, 15:13:07 UTC stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass Currently the 'stackleak_cleanup' pass deleting a CALL insn is executed after the 'reload' pass. That allows gcc to do some weird optimization in function prologues and epilogues, which are generated later [1]. Let's avoid that by registering the 'stackleak_cleanup' pass before the '*free_cfg' pass. It's the moment when the stack frame size is already final, function prologues and epilogues are generated, and the machine-dependent code transformations are not done. [1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2 Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Alexander Popov <alex.popov@linux.com> Signed-off-by: Kees Cook <keescook@chromium.org> 06 December 2018, 17:10:23 UTC
3caad34 Greg Kroah-Hartman 06 December 2018, 17:02:58 UTC Merge tag 'usb-serial-4.20-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fix for v4.20-rc6 Here's a fix for a reported USB-console regression in 4.18 which revealed a long-standing bug in the console implementation. The patch has been in linux-next over night with no reported issues. Signed-off-by: Johan Hovold <johan@kernel.org> * tag 'usb-serial-4.20-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: console: fix reported terminal settings 06 December 2018, 17:02:58 UTC
3a4d0c2 Russell King 06 December 2018, 16:36:38 UTC ARM: ensure that processor vtables is not lost after boot Marek Szyprowski reported problems with CPU hotplug in current kernels. This was tracked down to the processor vtables being located in an init section, and therefore discarded after kernel boot, despite being required after boot to properly initialise the non-boot CPUs. Arrange for these tables to end up in .rodata when required. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Krzysztof Kozlowski <krzk@kernel.org> Fixes: 383fb3ee8024 ("ARM: spectre-v2: per-CPU vtables to work around big.Little systems") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> 06 December 2018, 16:42:05 UTC
47f07f0 Yishai Hadas 05 December 2018, 13:50:21 UTC IB/mlx5: Block DEVX umem from the non applicable cases Blocks creating a DEVX UMEM with the non applicable access flags as of ODP, MW_BIND, etc. Specifically when an ODP flag is used below WARN call trace is issued. [ 2510.404131] RIP: 0010:__mlx5_ib_populate_pas+0x207/0x220 [mlx5_ib] ... [ 2510.404143] Call Trace: [ 2510.404150] ? __kmalloc_node+0x1b3/0x280 [ 2510.404156] ? _uverbs_alloc+0x63/0x90 [ib_uverbs] [ 2510.404158] ? _uverbs_alloc+0x63/0x90 [ib_uverbs] [ 2510.404162] mlx5_ib_populate_pas+0x53/0x60 [mlx5_ib] [ 2510.404167] mlx5_ib_handler_MLX5_IB_METHOD_DEVX_UMEM_REG+0x273/0x3f0 [mlx5_ib] Fixes: aeae94579caf ("IB/mlx5: Add DEVX support for memory registration") Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com> 06 December 2018, 16:38:14 UTC
63cea1f Johan Hovold 06 December 2018, 06:23:18 UTC MAINTAINERS: exclude gnss from SIRFPRIMA2 regex matching Exclude the gnss subsystem from SIRMPRIMA2 regex matching, which would otherwise match the unrelated gnss sirf driver. Cc: Barry Song <baohua@kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> 06 December 2018, 16:22:58 UTC
85280de Johan Hovold 06 December 2018, 06:23:17 UTC MAINTAINERS: add gnss scm tree Add SCM tree for the gnss subsystem. Signed-off-by: Johan Hovold <johan@kernel.org> 06 December 2018, 16:22:57 UTC
06fd9ab Johan Hovold 05 December 2018, 10:21:49 UTC gnss: sirf: fix activation retry handling Fix activation helper which would return -ETIMEDOUT even if the last retry attempt was successful. Also change the semantics of the retries variable so that it actually holds the number of retries (rather than tries). Fixes: d2efbbd18b1e ("gnss: add driver for sirfstar-based receivers") Cc: stable <stable@vger.kernel.org> # 4.19 Signed-off-by: Johan Hovold <johan@kernel.org> 06 December 2018, 16:22:23 UTC
b7d624a Guo Ren 06 December 2018, 02:07:40 UTC asm-generic: unistd.h: fixup broken macro include. The broken macros make the glibc compile error. If there is no __NR3264_fstat*, we should also removed related definitions. Reported-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Fixes: bf4b6a7d371e ("y2038: Remove stat64 family from default syscall set") [arnd: Both Marcin and Guo provided this patch to fix up my clearly broken commit, I applied the version with the better changelog.] Signed-off-by: Guo Ren <ren_guo@c-sky.com> Signed-off-by: Mao Han <han_mao@c-sky.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 06 December 2018, 15:57:47 UTC
a50480c Andrea Righi 06 December 2018, 09:56:48 UTC kprobes/x86: Blacklist non-attachable interrupt functions These interrupt functions are already non-attachable by kprobes. Blacklist them explicitly so that they can show up in /sys/kernel/debug/kprobes/blacklist and tools like BCC can use this additional information. Signed-off-by: Andrea Righi <righi.andrea@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: David S. Miller <davem@davemloft.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Yonghong Song <yhs@fb.com> Link: http://lkml.kernel.org/r/20181206095648.GA8249@Dell Signed-off-by: Ingo Molnar <mingo@kernel.org> 06 December 2018, 15:52:03 UTC
dada6a4 Macpaul Lin 17 October 2018, 15:08:38 UTC kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var() This patch is trying to fix KE issue due to "BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198" reported by Syzkaller scan." [26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198 [26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364 [26364:syz-executor0][name:report&] [26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0 [26364:syz-executor0]Call trace: [26364:syz-executor0][<ffffff9008095cf8>] dump_bacIctrace+Ox0/0x470 [26364:syz-executor0][<ffffff9008096de0>] show_stack+0x20/0x30 [26364:syz-executor0][<ffffff90089cc9c8>] dump_stack+Oxd8/0x128 [26364:syz-executor0][<ffffff90084edb38>] print_address_description +0x80/0x4a8 [26364:syz-executor0][<ffffff90084ee270>] kasan_report+Ox178/0x390 [26364:syz-executor0][<ffffff90084ee4a0>] _asan_report_loadi_noabort+Ox18/0x20 [26364:syz-executor0][<ffffff9008b092ac>] param_set_kgdboc_var+Ox194/0x198 [26364:syz-executor0][<ffffff900813af64>] param_attr_store+Ox14c/0x270 [26364:syz-executor0][<ffffff90081394c8>] module_attr_store+0x60/0x90 [26364:syz-executor0][<ffffff90086690c0>] sysfs_kl_write+Ox100/0x158 [26364:syz-executor0][<ffffff9008666d84>] kernfs_fop_write+0x27c/0x3a8 [26364:syz-executor0][<ffffff9008508264>] do_loop_readv_writev+0x114/0x1b0 [26364:syz-executor0][<ffffff9008509ac8>] do_readv_writev+0x4f8/0x5e0 [26364:syz-executor0][<ffffff9008509ce4>] vfs_writev+0x7c/Oxb8 [26364:syz-executor0][<ffffff900850ba64>] SyS_writev+Oxcc/0x208 [26364:syz-executor0][<ffffff90080883f0>] elO_svc_naked +0x24/0x28 [26364:syz-executor0][name:report&] [26364:syz-executor0][name:report&]The buggy address belongs to the variable: [26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40 [26364:syz-executor0][name:report&] [26364:syz-executor0][name:report&]Memory state around the buggy address: [26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa [26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa [26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 [26364:syz-executor0][name:report&] ^ [26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa [26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa [26364:syz-executor0][name:report&] [26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint [26364:syz-executor0]------------[cut here]------------ After checking the source code, we've found there might be an out-of-bounds access to "config[len - 1]" array when the variable "len" is zero. Signed-off-by: Macpaul Lin <macpaul@gmail.com> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 06 December 2018, 14:59:07 UTC
4f145cd Matthew Wilcox 29 November 2018, 21:04:35 UTC XArray tests: Check iterating over multiorder entries There was no bug here, but there was no test coverage for this scenario. Signed-off-by: Matthew Wilcox <willy@infradead.org> 06 December 2018, 14:25:33 UTC
b7677a1 Matthew Wilcox 05 November 2018, 18:19:54 UTC XArray tests: Handle larger indices more elegantly xa_mk_value() only handles values up to LONG_MAX. I successfully hid that inside xa_store_index() and xa_erase_index(), but it turned out I also needed it for testing xa_alloc() on 32-bit machines. So extract xa_mk_index() from the above two functions, and convert the non-constant users of xa_mk_value() to xa_mk_index(). Signed-off-by: Matthew Wilcox <willy@infradead.org> 06 December 2018, 14:25:15 UTC
55f3f7e Matthew Wilcox 26 November 2018, 21:08:43 UTC XArray: Add xa_cmpxchg_irq and xa_cmpxchg_bh These convenience wrappers match the other _irq and _bh wrappers we already have. It turns out I'd already open-coded xa_cmpxchg_irq() in the shmem code, so convert that. Signed-off-by: Matthew Wilcox <willy@infradead.org> 06 December 2018, 13:26:17 UTC
eff3860 Matthew Wilcox 06 December 2018, 13:19:13 UTC radix tree: Don't return retry entries from lookup Commit 66ee620f06f9 ("idr: Permit any valid kernel pointer to be stored") changed the radix tree lookup so that it stops when reaching the bottom of the tree. However, the condition was added in the wrong place, making it possible to return retry entries to the caller. Reorder the tests to check for the retry entry before checking whether we're at the bottom of the tree. The retry entry should never be found in the tree root, so it's safe to defer the check until the end of the loop. Add a regression test to the test-suite to be sure this doesn't come back. Fixes: 66ee620f06f9 ("idr: Permit any valid kernel pointer to be stored") Reported-by: Greg Kurz <groug@kaod.org> Signed-off-by: Matthew Wilcox <willy@infradead.org> 06 December 2018, 13:26:16 UTC
0472bf0 Mathias Nyman 05 December 2018, 12:22:39 UTC xhci: Prevent U1/U2 link pm states if exit latency is too long Don't allow USB3 U1 or U2 if the latency to wake up from the U-state reaches the service interval for a periodic endpoint. This is according to xhci 1.1 specification section 4.23.5.2 extra note: "Software shall ensure that a device is prevented from entering a U-state where its worst case exit latency approaches the ESIT." Allowing too long exit latencies for periodic endpoint confuses xHC internal scheduling, and new devices may fail to enumerate with a "Not enough bandwidth for new device state" error from the host. Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 06 December 2018, 12:00:10 UTC
a7d57ab Sandeep Singh 05 December 2018, 12:22:38 UTC xhci: workaround CSS timeout on AMD SNPS 3.0 xHC Occasionally AMD SNPS 3.0 xHC does not respond to CSS when set, also it does not flag anything on SRE and HCE to point the internal xHC errors on USBSTS register. This stalls the entire system wide suspend and there is no point in stalling just because of xHC CSS is not responding. To work around this problem, if the xHC does not flag anything on SRE and HCE, we can skip the CSS timeout and allow the system to continue the suspend. Once the system resume happens we can internally reset the controller using XHCI_RESET_ON_RESUME quirk Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Sandeep Singh <Sandeep.Singh@amd.com> cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Cc: <stable@vger.kernel.org> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 06 December 2018, 12:00:10 UTC
b704441 Alek Du 06 December 2018, 09:24:59 UTC mmc: sdhci: fix the timeout check window for clock and reset We observed some premature timeouts on a virtualization platform, the log is like this: case 1: [159525.255629] mmc1: Internal clock never stabilised. [159525.255818] mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== [159525.256049] mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00001002 ... [159525.257205] mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x0000fa03 From the clock control register dump, we are pretty sure the clock was stablized. case 2: [ 914.550127] mmc1: Reset 0x2 never completed. [ 914.550321] mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== [ 914.550608] mmc1: sdhci: Sys addr: 0x00000010 | Version: 0x00001002 After checking the sdhci code, we found the timeout check actually has a little window that the CPU can be scheduled out and when it comes back, the original time set or check is not valid. Fixes: 5a436cc0af62 ("mmc: sdhci: Optimize delay loops") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Alek Du <alek.du@intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 06 December 2018, 10:22:00 UTC
c988de2 Paulo Alcantara 15 November 2018, 14:20:52 UTC cifs: Fix separator when building path from dentry Make sure to use the CIFS_DIR_SEP(cifs_sb) as path separator for prefixpath too. Fixes a bug with smb1 UNIX extensions. Fixes: a6b5058fafdf ("fs/cifs: make share unaccessible at root level mountable") Signed-off-by: Paulo Alcantara <palcantara@suse.com> Reviewed-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org> 06 December 2018, 08:20:17 UTC
6e78530 Steve French 03 November 2018, 20:02:44 UTC cifs: In Kconfig CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs) Missing a dependency. Shouldn't show cifs posix extensions in Kconfig if CONFIG_CIFS_ALLOW_INSECURE_DIALECTS (ie SMB1 protocol) is disabled. Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> 06 December 2018, 08:20:14 UTC
f15096f Fabio Estevam 05 December 2018, 11:05:30 UTC ARM: dts: imx7d-nitrogen7: Fix the description of the Wifi clock According to bindings/regulator/fixed-regulator.txt the 'clocks' and 'clock-names' properties are not valid ones. In order to turn on the Wifi clock the correct location for describing the CLKO2 clock is via a mmc-pwrseq handle, so do it accordingly. Fixes: 56354959cfec ("ARM: dts: imx: add Boundary Devices Nitrogen7 board") Signed-off-by: Fabio Estevam <festevam@gmail.com> Acked-by: Troy Kisky <troy.kisky@boundarydevices.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> 06 December 2018, 07:38:28 UTC
e41b93a Michael Ellerman 03 December 2018, 08:55:55 UTC powerpc/boot: Fix build failures with -j 1 In commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper") we added a dependency to serial.c on autoconf.h: $(obj)/serial.c: $(obj)/autoconf.h This works when building in-tree (ie. with KBUILD_OUTPUT unset) because the obj tree is the src tree. But when building with eg. O=build and -j 1 the build fails: gcc ... -I../arch/powerpc/boot -c -o arch/powerpc/boot/serial.o arch/powerpc/boot/serial.c gcc: error: arch/powerpc/boot/serial.c: No such file or directory Why this is only happening with -j 1 is not clear, when building with -j greater than 1 somehow we decide to look for serial.c in the src tree (../), eg: gcc -I../arch/powerpc/boot -c -o arch/powerpc/boot/serial.o ../arch/powerpc/boot/serial.c Regardless we shouldn't be specifying a dependency on serial.c in the build tree, we want to add a dependency to the version in $(srctree) so fix the rule to say that. Fixes: 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper") Tested-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 06 December 2018, 05:10:15 UTC
ebaf39e Jiri Wiesner 05 December 2018, 15:55:29 UTC ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes The *_frag_reasm() functions are susceptible to miscalculating the byte count of packet fragments in case the truesize of a head buffer changes. The truesize member may be changed by the call to skb_unclone(), leaving the fragment memory limit counter unbalanced even if all fragments are processed. This miscalculation goes unnoticed as long as the network namespace which holds the counter is not destroyed. Should an attempt be made to destroy a network namespace that holds an unbalanced fragment memory limit counter the cleanup of the namespace never finishes. The thread handling the cleanup gets stuck in inet_frags_exit_net() waiting for the percpu counter to reach zero. The thread is usually in running state with a stacktrace similar to: PID: 1073 TASK: ffff880626711440 CPU: 1 COMMAND: "kworker/u48:4" #5 [ffff880621563d48] _raw_spin_lock at ffffffff815f5480 #6 [ffff880621563d48] inet_evict_bucket at ffffffff8158020b #7 [ffff880621563d80] inet_frags_exit_net at ffffffff8158051c #8 [ffff880621563db0] ops_exit_list at ffffffff814f5856 #9 [ffff880621563dd8] cleanup_net at ffffffff814f67c0 #10 [ffff880621563e38] process_one_work at ffffffff81096f14 It is not possible to create new network namespaces, and processes that call unshare() end up being stuck in uninterruptible sleep state waiting to acquire the net_mutex. The bug was observed in the IPv6 netfilter code by Per Sundstrom. I thank him for his analysis of the problem. The parts of this patch that apply to IPv4 and IPv6 fragment reassembly are preemptive measures. Signed-off-by: Jiri Wiesner <jwiesner@suse.com> Reported-by: Per Sundstrom <per.sundstrom@redqube.se> Acked-by: Peter Oskolkov <posk@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> 06 December 2018, 04:44:46 UTC
afd0a80 Jakub Audykowicz 04 December 2018, 19:27:41 UTC sctp: frag_point sanity check If for some reason an association's fragmentation point is zero, sctp_datamsg_from_user will try to endlessly try to divide a message into zero-sized chunks. This eventually causes kernel panic due to running out of memory. Although this situation is quite unlikely, it has occurred before as reported. I propose to add this simple last-ditch sanity check due to the severity of the potential consequences. Signed-off-by: Jakub Audykowicz <jakub.audykowicz@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> 06 December 2018, 04:37:52 UTC
e594a5e Sam Bobroff 03 December 2018, 00:53:21 UTC drm/ast: Fix connector leak during driver unload When unloading the ast driver, a warning message is printed by drm_mode_config_cleanup() because a reference is still held to one of the drm_connector structs. Correct this by calling drm_crtc_force_disable_all() in ast_fbdev_destroy(). Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/1e613f3c630c7bbc72e04a44b178259b9164d2f6.1543798395.git.sbobroff@linux.ibm.com 06 December 2018, 04:12:02 UTC
back to top