Joerg Roedel [Fri, 27 Mar 2020 10:33:27 +0000 (11:33 +0100)]
Merge branches 'iommu/fixes', 'arm/qcom', 'arm/omap', 'arm/smmu', 'x86/amd', 'x86/vt-d', 'virtio' and 'core' into next
Joerg Roedel [Thu, 26 Mar 2020 15:08:41 +0000 (16:08 +0100)]
iommu: Move fwspec->iommu_priv to struct dev_iommu
Move the pointer for iommu private data from struct iommu_fwspec to
struct dev_iommu.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Tested-by: Will Deacon <will@kernel.org> # arm-smmu
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-17-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:40 +0000 (16:08 +0100)]
iommu/virtio: Use accessor functions for iommu private data
Make use of dev_iommu_priv_set/get() functions.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-16-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:39 +0000 (16:08 +0100)]
iommu/qcom: Use accessor functions for iommu private data
Make use of dev_iommu_priv_set/get() functions.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20200326150841.10083-15-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:38 +0000 (16:08 +0100)]
iommu/mediatek: Use accessor functions for iommu private data
Make use of dev_iommu_priv_set/get() functions.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-14-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:37 +0000 (16:08 +0100)]
iommu/renesas: Use accessor functions for iommu private data
Make use of dev_iommu_priv_set/get() functions.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-13-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:36 +0000 (16:08 +0100)]
iommu/arm-smmu: Use accessor functions for iommu private data
Make use of dev_iommu_priv_set/get() functions and simplify the code
where possible with this change.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Tested-by: Will Deacon <will@kernel.org> # arm-smmu
Link: https://lore.kernel.org/r/20200326150841.10083-12-joro@8bytes.org
Robin Murphy [Thu, 26 Mar 2020 15:08:35 +0000 (16:08 +0100)]
iommu/arm-smmu: Refactor master_cfg/fwspec usage
In preparation for restructuring iommu_fwspec, refactor the way we
access the arm_smmu_master_cfg private data to be less dependent on
the current layout.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20200326150841.10083-11-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:34 +0000 (16:08 +0100)]
iommu/arm-smmu-v3: Use accessor functions for iommu private data
Make use of dev_iommu_priv_set/get() functions in the code.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Tested-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-10-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:33 +0000 (16:08 +0100)]
iommu: Introduce accessors for iommu private data
Add dev_iommu_priv_get/set() functions to access per-device iommu
private data. This makes it easier to move the pointer to a different
location.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Tested-by: Will Deacon <will@kernel.org> # arm-smmu
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-9-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:32 +0000 (16:08 +0100)]
iommu/arm-smmu: Fix uninitilized variable warning
Some unrelated changes in the iommu code caused a new warning to
appear in the arm-smmu driver:
CC drivers/iommu/arm-smmu.o
drivers/iommu/arm-smmu.c: In function 'arm_smmu_add_device':
drivers/iommu/arm-smmu.c:1441:2: warning: 'smmu' may be used uninitialized in this function [-Wmaybe-uninitialized]
arm_smmu_rpm_put(smmu);
^~~~~~~~~~~~~~~~~~~~~~
The warning is a false positive, but initialize the variable to NULL
to get rid of it.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Tested-by: Will Deacon <will@kernel.org> # arm-smmu
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-8-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:31 +0000 (16:08 +0100)]
iommu: Move iommu_fwspec to struct dev_iommu
Move the iommu_fwspec pointer in struct device into struct dev_iommu.
This is a step in the effort to reduce the iommu related pointers in
struct device to one.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Tested-by: Will Deacon <will@kernel.org> # arm-smmu
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200326150841.10083-7-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:30 +0000 (16:08 +0100)]
iommu: Rename struct iommu_param to dev_iommu
The term dev_iommu aligns better with other existing structures and
their accessor functions.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Tested-by: Will Deacon <will@kernel.org> # arm-smmu
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200326150841.10083-6-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:29 +0000 (16:08 +0100)]
iommu/tegra-gart: Remove direct access of dev->iommu_fwspec
Use the accessor functions instead of directly dereferencing
dev->iommu_fwspec.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-5-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:28 +0000 (16:08 +0100)]
drm/msm/mdp5: Remove direct access of dev->iommu_fwspec
Use the accessor functions instead of directly dereferencing
dev->iommu_fwspec.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-4-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:27 +0000 (16:08 +0100)]
ACPI/IORT: Remove direct access of dev->iommu_fwspec
Use the accessor functions instead of directly dereferencing
dev->iommu_fwspec.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Tested-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-3-joro@8bytes.org
Joerg Roedel [Thu, 26 Mar 2020 15:08:26 +0000 (16:08 +0100)]
iommu: Define dev_iommu_fwspec_get() for !CONFIG_IOMMU_API
There are users outside of the IOMMU code that need to call that
function. Define it for !CONFIG_IOMMU_API too so that compilation does
not break.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326150841.10083-2-joro@8bytes.org
Jean-Philippe Brucker [Thu, 26 Mar 2020 09:35:58 +0000 (10:35 +0100)]
iommu/virtio: Reject IOMMU page granule larger than PAGE_SIZE
We don't currently support IOMMUs with a page granule larger than the
system page size. The IOVA allocator has a BUG_ON() in this case, and
VFIO has a WARN_ON().
Removing these obstacles ranges doesn't seem possible without major
changes to the DMA API and VFIO. Some callers of iommu_map(), for
example, want to map multiple page-aligned regions adjacent to each
others for scatter-gather purposes. Even in simple DMA API uses, a call
to dma_map_page() would let the endpoint access neighbouring memory. And
VFIO users cannot ensure that their virtual address buffer is physically
contiguous at the IOMMU granule.
Rather than triggering the IOVA BUG_ON() on mismatched page sizes, abort
the vdomain finalise() with an error message. We could simply abort the
viommu probe(), but an upcoming extension to virtio-iommu will allow
setting different page masks for each endpoint.
Reported-by: Bharat Bhushan <bbhushan2@marvell.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Bharat Bhushan <bbhushan2@marvell.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/20200326093558.2641019-4-jean-philippe@linaro.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Jean-Philippe Brucker [Thu, 26 Mar 2020 09:35:57 +0000 (10:35 +0100)]
iommu/virtio: Fix freeing of incomplete domains
Calling viommu_domain_free() on a domain that hasn't been finalised (not
attached to any device, for example) can currently cause an Oops,
because we attempt to call ida_free() on ID 0, which may either be
unallocated or used by another domain.
Only initialise the vdomain->viommu pointer, which denotes a finalised
domain, at the end of a successful viommu_domain_finalise().
Fixes:
edcd69ab9a32 ("iommu: Add virtio-iommu driver")
Reported-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/20200326093558.2641019-3-jean-philippe@linaro.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Jean-Philippe Brucker [Thu, 26 Mar 2020 09:35:56 +0000 (10:35 +0100)]
iommu/virtio: Fix sparse warning
We copied the virtio_iommu_config from the virtio-iommu specification,
which declares the fields using little-endian annotations (for example
le32). Unfortunately this causes sparse to warn about comparison between
little- and cpu-endian, because of the typecheck() in virtio_cread():
drivers/iommu/virtio-iommu.c:1024:9: sparse: sparse: incompatible types in comparison expression (different base types):
drivers/iommu/virtio-iommu.c:1024:9: sparse: restricted __le64 *
drivers/iommu/virtio-iommu.c:1024:9: sparse: unsigned long long *
drivers/iommu/virtio-iommu.c:1036:9: sparse: sparse: incompatible types in comparison expression (different base types):
drivers/iommu/virtio-iommu.c:1036:9: sparse: restricted __le64 *
drivers/iommu/virtio-iommu.c:1036:9: sparse: unsigned long long *
drivers/iommu/virtio-iommu.c:1040:9: sparse: sparse: incompatible types in comparison expression (different base types):
drivers/iommu/virtio-iommu.c:1040:9: sparse: restricted __le64 *
drivers/iommu/virtio-iommu.c:1040:9: sparse: unsigned long long *
drivers/iommu/virtio-iommu.c:1044:9: sparse: sparse: incompatible types in comparison expression (different base types):
drivers/iommu/virtio-iommu.c:1044:9: sparse: restricted __le32 *
drivers/iommu/virtio-iommu.c:1044:9: sparse: unsigned int *
drivers/iommu/virtio-iommu.c:1048:9: sparse: sparse: incompatible types in comparison expression (different base types):
drivers/iommu/virtio-iommu.c:1048:9: sparse: restricted __le32 *
drivers/iommu/virtio-iommu.c:1048:9: sparse: unsigned int *
drivers/iommu/virtio-iommu.c:1052:9: sparse: sparse: incompatible types in comparison expression (different base types):
drivers/iommu/virtio-iommu.c:1052:9: sparse: restricted __le32 *
drivers/iommu/virtio-iommu.c:1052:9: sparse: unsigned int *
Although virtio_cread() does convert virtio-endian (in our case
little-endian) to cpu-endian, the typecheck() needs the two arguments to
have the same endianness. Do as UAPI headers of other virtio devices do,
and remove the endian annotation from the device config.
Even though we change the UAPI this shouldn't cause any regression since
QEMU, the existing implementation of virtio-iommu that uses this header,
already removes the annotations when importing headers.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200326093558.2641019-2-jean-philippe@linaro.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Jacob Pan [Fri, 20 Mar 2020 04:32:31 +0000 (21:32 -0700)]
iommu/vt-d: Add build dependency on IOASID
IOASID code is needed by VT-d scalable mode for PASID allocation.
Add explicit dependency such that IOASID is built-in whenever Intel
IOMMU is enabled.
Otherwise, aux domain code will fail when IOMMU is built-in and IOASID
is compiled as a module.
Fixes:
59a623374dc38 ("iommu/vt-d: Replace Intel specific PASID allocator with IOASID")
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Jacob Pan [Fri, 20 Mar 2020 04:32:30 +0000 (21:32 -0700)]
iommu/vt-d: Fix mm reference leak
Move canonical address check before mmget_not_zero() to avoid mm
reference leak.
Fixes:
9d8c3af31607 ("iommu/vt-d: IOMMU Page Request needs to check if address is canonical.")
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Linus Torvalds [Mon, 23 Mar 2020 01:31:56 +0000 (18:31 -0700)]
Linux 5.6-rc7
Linus Torvalds [Sun, 22 Mar 2020 18:35:33 +0000 (11:35 -0700)]
Merge tag 'for-5.6-rc6-tag' of git://git./linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
"Two fixes.
The first is a regression: when dropping some incompat bits the
conditions were reversed. The other is a fix for rename whiteout
potentially leaving stack memory linked to a list"
* tag 'for-5.6-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: fix removal of raid[56|1c34} incompat flags after removing block group
btrfs: fix log context list corruption after rename whiteout error
Linus Torvalds [Sun, 22 Mar 2020 17:46:50 +0000 (10:46 -0700)]
Merge branch 'akpm' (patches from Andrew)
Merge misc fixes from Andrew Morton:
"10 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
x86/mm: split vmalloc_sync_all()
mm, slub: prevent kmalloc_node crashes and memory leaks
mm/mmu_notifier: silence PROVE_RCU_LIST warnings
epoll: fix possible lost wakeup on epoll_ctl() path
mm: do not allow MADV_PAGEOUT for CoW pages
mm, memcg: throttle allocators based on ancestral memory.high
mm, memcg: fix corruption on 64-bit divisor in memory.high throttling
page-flags: fix a crash at SetPageError(THP_SWAP)
mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
memcg: fix NULL pointer dereference in __mem_cgroup_usage_unregister_event
Joerg Roedel [Sun, 22 Mar 2020 01:22:41 +0000 (18:22 -0700)]
x86/mm: split vmalloc_sync_all()
Commit
3f8fd02b1bf1 ("mm/vmalloc: Sync unmappings in
__purge_vmap_area_lazy()") introduced a call to vmalloc_sync_all() in
the vunmap() code-path. While this change was necessary to maintain
correctness on x86-32-pae kernels, it also adds additional cycles for
architectures that don't need it.
Specifically on x86-64 with CONFIG_VMAP_STACK=y some people reported
severe performance regressions in micro-benchmarks because it now also
calls the x86-64 implementation of vmalloc_sync_all() on vunmap(). But
the vmalloc_sync_all() implementation on x86-64 is only needed for newly
created mappings.
To avoid the unnecessary work on x86-64 and to gain the performance
back, split up vmalloc_sync_all() into two functions:
* vmalloc_sync_mappings(), and
* vmalloc_sync_unmappings()
Most call-sites to vmalloc_sync_all() only care about new mappings being
synchronized. The only exception is the new call-site added in the
above mentioned commit.
Shile Zhang directed us to a report of an 80% regression in reaim
throughput.
Fixes:
3f8fd02b1bf1 ("mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()")
Reported-by: kernel test robot <oliver.sang@intel.com>
Reported-by: Shile Zhang <shile.zhang@linux.alibaba.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Borislav Petkov <bp@suse.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [GHES]
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20191009124418.8286-1-joro@8bytes.org
Link: https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/4D3JPPHBNOSPFK2KEPC6KGKS6J25AIDB/
Link: http://lkml.kernel.org/r/20191113095530.228959-1-shile.zhang@linux.alibaba.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Vlastimil Babka [Sun, 22 Mar 2020 01:22:37 +0000 (18:22 -0700)]
mm, slub: prevent kmalloc_node crashes and memory leaks
Sachin reports [1] a crash in SLUB __slab_alloc():
BUG: Kernel NULL pointer dereference on read at 0x000073b0
Faulting instruction address: 0xc0000000003d55f4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 19 PID: 1 Comm: systemd Not tainted 5.6.0-rc2-next-
20200218-autotest #1
NIP:
c0000000003d55f4 LR:
c0000000003d5b94 CTR:
0000000000000000
REGS:
c0000008b37836d0 TRAP: 0300 Not tainted (5.6.0-rc2-next-
20200218-autotest)
MSR:
8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR:
24004844 XER:
00000000
CFAR:
c00000000000dec4 DAR:
00000000000073b0 DSISR:
40000000 IRQMASK: 1
GPR00:
c0000000003d5b94 c0000008b3783960 c00000000155d400 c0000008b301f500
GPR04:
0000000000000dc0 0000000000000002 c0000000003443d8 c0000008bb398620
GPR08:
00000008ba2f0000 0000000000000001 0000000000000000 0000000000000000
GPR12:
0000000024004844 c00000001ec52a00 0000000000000000 0000000000000000
GPR16:
c0000008a1b20048 c000000001595898 c000000001750c18 0000000000000002
GPR20:
c000000001750c28 c000000001624470 0000000fffffffe0 5deadbeef0000122
GPR24:
0000000000000001 0000000000000dc0 0000000000000002 c0000000003443d8
GPR28:
c0000008b301f500 c0000008bb398620 0000000000000000 c00c000002287180
NIP ___slab_alloc+0x1f4/0x760
LR __slab_alloc+0x34/0x60
Call Trace:
___slab_alloc+0x334/0x760 (unreliable)
__slab_alloc+0x34/0x60
__kmalloc_node+0x110/0x490
kvmalloc_node+0x58/0x110
mem_cgroup_css_online+0x108/0x270
online_css+0x48/0xd0
cgroup_apply_control_enable+0x2ec/0x4d0
cgroup_mkdir+0x228/0x5f0
kernfs_iop_mkdir+0x90/0xf0
vfs_mkdir+0x110/0x230
do_mkdirat+0xb0/0x1a0
system_call+0x5c/0x68
This is a PowerPC platform with following NUMA topology:
available: 2 nodes (0-1)
node 0 cpus:
node 0 size: 0 MB
node 0 free: 0 MB
node 1 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 35247 MB
node 1 free: 30907 MB
node distances:
node 0 1
0: 10 40
1: 40 10
possible numa nodes: 0-31
This only happens with a mmotm patch "mm/memcontrol.c: allocate
shrinker_map on appropriate NUMA node" [2] which effectively calls
kmalloc_node for each possible node. SLUB however only allocates
kmem_cache_node on online N_NORMAL_MEMORY nodes, and relies on
node_to_mem_node to return such valid node for other nodes since commit
a561ce00b09e ("slub: fall back to node_to_mem_node() node if allocating
on memoryless node"). This is however not true in this configuration
where the _node_numa_mem_ array is not initialized for nodes 0 and 2-31,
thus it contains zeroes and get_partial() ends up accessing
non-allocated kmem_cache_node.
A related issue was reported by Bharata (originally by Ramachandran) [3]
where a similar PowerPC configuration, but with mainline kernel without
patch [2] ends up allocating large amounts of pages by kmalloc-1k
kmalloc-512. This seems to have the same underlying issue with
node_to_mem_node() not behaving as expected, and might probably also
lead to an infinite loop with CONFIG_SLUB_CPU_PARTIAL [4].
This patch should fix both issues by not relying on node_to_mem_node()
anymore and instead simply falling back to NUMA_NO_NODE, when
kmalloc_node(node) is attempted for a node that's not online, or has no
usable memory. The "usable memory" condition is also changed from
node_present_pages() to N_NORMAL_MEMORY node state, as that is exactly
the condition that SLUB uses to allocate kmem_cache_node structures.
The check in get_partial() is removed completely, as the checks in
___slab_alloc() are now sufficient to prevent get_partial() being
reached with an invalid node.
[1] https://lore.kernel.org/linux-next/
3381CD91-AB3D-4773-BA04-
E7A072A63968@linux.vnet.ibm.com/
[2] https://lore.kernel.org/linux-mm/
fff0e636-4c36-ed10-281c-
8cdb0687c839@virtuozzo.com/
[3] https://lore.kernel.org/linux-mm/
20200317092624.GB22538@in.ibm.com/
[4] https://lore.kernel.org/linux-mm/
088b5996-faae-8a56-ef9c-
5b567125ae54@suse.cz/
Fixes:
a561ce00b09e ("slub: fall back to node_to_mem_node() node if allocating on memoryless node")
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Reported-by: PUVICHAKRAVARTHY RAMACHANDRAN <puvichakravarthy@in.ibm.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Tested-by: Bharata B Rao <bharata@linux.ibm.com>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Christopher Lameter <cl@linux.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200320115533.9604-1-vbabka@suse.cz
Debugged-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Qian Cai [Sun, 22 Mar 2020 01:22:34 +0000 (18:22 -0700)]
mm/mmu_notifier: silence PROVE_RCU_LIST warnings
It is safe to traverse mm->notifier_subscriptions->list either under
SRCU read lock or mm->notifier_subscriptions->lock using
hlist_for_each_entry_rcu(). Silence the PROVE_RCU_LIST false positives,
for example,
WARNING: suspicious RCU usage
-----------------------------
mm/mmu_notifier.c:484 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by libvirtd/802:
#0:
ffff9321e3f58148 (&mm->mmap_sem#2){++++}, at: do_mprotect_pkey+0xe1/0x3e0
#1:
ffffffff91ae6160 (mmu_notifier_invalidate_range_start){+.+.}, at: change_p4d_range+0x5fa/0x800
#2:
ffffffff91ae6e08 (srcu){....}, at: __mmu_notifier_invalidate_range_start+0x178/0x460
stack backtrace:
CPU: 7 PID: 802 Comm: libvirtd Tainted: G I 5.6.0-rc6-next-
20200317+ #2
Hardware name: HP ProLiant BL460c Gen8, BIOS I31 11/02/2014
Call Trace:
dump_stack+0xa4/0xfe
lockdep_rcu_suspicious+0xeb/0xf5
__mmu_notifier_invalidate_range_start+0x3ff/0x460
change_p4d_range+0x746/0x800
change_protection+0x1df/0x300
mprotect_fixup+0x245/0x3e0
do_mprotect_pkey+0x23b/0x3e0
__x64_sys_mprotect+0x51/0x70
do_syscall_64+0x91/0xae8
entry_SYSCALL_64_after_hwframe+0x49/0xb3
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Link: http://lkml.kernel.org/r/20200317175640.2047-1-cai@lca.pw
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Roman Penyaev [Sun, 22 Mar 2020 01:22:30 +0000 (18:22 -0700)]
epoll: fix possible lost wakeup on epoll_ctl() path
This fixes possible lost wakeup introduced by commit
a218cc491420.
Originally modifications to ep->wq were serialized by ep->wq.lock, but
in commit
a218cc491420 ("epoll: use rwlock in order to reduce
ep_poll_callback() contention") a new rw lock was introduced in order to
relax fd event path, i.e. callers of ep_poll_callback() function.
After the change ep_modify and ep_insert (both are called on epoll_ctl()
path) were switched to ep->lock, but ep_poll (epoll_wait) was using
ep->wq.lock on wqueue list modification.
The bug doesn't lead to any wqueue list corruptions, because wake up
path and list modifications were serialized by ep->wq.lock internally,
but actual waitqueue_active() check prior wake_up() call can be
reordered with modifications of ep ready list, thus wake up can be lost.
And yes, can be healed by explicit smp_mb():
list_add_tail(&epi->rdlink, &ep->rdllist);
smp_mb();
if (waitqueue_active(&ep->wq))
wake_up(&ep->wp);
But let's make it simple, thus current patch replaces ep->wq.lock with
the ep->lock for wqueue modifications, thus wake up path always observes
activeness of the wqueue correcty.
Fixes:
a218cc491420 ("epoll: use rwlock in order to reduce ep_poll_callback() contention")
Reported-by: Max Neunhoeffer <max@arangodb.com>
Signed-off-by: Roman Penyaev <rpenyaev@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Max Neunhoeffer <max@arangodb.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Christopher Kohlhoff <chris.kohlhoff@clearpool.io>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jes Sorensen <jes.sorensen@gmail.com>
Cc: <stable@vger.kernel.org> [5.1+]
Link: http://lkml.kernel.org/r/20200214170211.561524-1-rpenyaev@suse.de
References: https://bugzilla.kernel.org/show_bug.cgi?id=205933
Bisected-by: Max Neunhoeffer <max@arangodb.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Michal Hocko [Sun, 22 Mar 2020 01:22:26 +0000 (18:22 -0700)]
mm: do not allow MADV_PAGEOUT for CoW pages
Jann has brought up a very interesting point [1]. While shared pages
are excluded from MADV_PAGEOUT normally, CoW pages can be easily
reclaimed that way. This can lead to all sorts of hard to debug
problems. E.g. performance problems outlined by Daniel [2].
There are runtime environments where there is a substantial memory
shared among security domains via CoW memory and a easy to reclaim way
of that memory, which MADV_{COLD,PAGEOUT} offers, can lead to either
performance degradation in for the parent process which might be more
privileged or even open side channel attacks.
The feasibility of the latter is not really clear to me TBH but there is
no real reason for exposure at this stage. It seems there is no real
use case to depend on reclaiming CoW memory via madvise at this stage so
it is much easier to simply disallow it and this is what this patch
does. Put it simply MADV_{PAGEOUT,COLD} can operate only on the
exclusively owned memory which is a straightforward semantic.
[1] http://lkml.kernel.org/r/CAG48ez0G3JkMq61gUmyQAaCq=_TwHbi1XKzWRooxZkv08PQKuw@mail.gmail.com
[2] http://lkml.kernel.org/r/CAKOZueua_v8jHCpmEtTB6f3i9e2YnmX4mqdYVWhV4E=Z-n+zRQ@mail.gmail.com
Fixes:
9c276cc65a58 ("mm: introduce MADV_COLD")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Daniel Colascione <dancol@google.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: "Joel Fernandes (Google)" <joel@joelfernandes.org>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200312082248.GS23944@dhcp22.suse.cz
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Chris Down [Sun, 22 Mar 2020 01:22:23 +0000 (18:22 -0700)]
mm, memcg: throttle allocators based on ancestral memory.high
Prior to this commit, we only directly check the affected cgroup's
memory.high against its usage. However, it's possible that we are being
reclaimed as a result of hitting an ancestor memory.high and should be
penalised based on that, instead.
This patch changes memory.high overage throttling to use the largest
overage in its ancestors when considering how many penalty jiffies to
charge. This makes sure that we penalise poorly behaving cgroups in the
same way regardless of at what level of the hierarchy memory.high was
breached.
Fixes:
0e4b01df8659 ("mm, memcg: throttle allocators when failing reclaim over memory.high")
Reported-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Cc: Roman Gushchin <guro@fb.com>
Cc: <stable@vger.kernel.org> [5.4.x+]
Link: http://lkml.kernel.org/r/8cd132f84bd7e16cdb8fde3378cdbf05ba00d387.1584036142.git.chris@chrisdown.name
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Chris Down [Sun, 22 Mar 2020 01:22:20 +0000 (18:22 -0700)]
mm, memcg: fix corruption on 64-bit divisor in memory.high throttling
Commit
0e4b01df8659 had a bunch of fixups to use the right division
method. However, it seems that after all that it still wasn't right --
div_u64 takes a 32-bit divisor.
The headroom is still large (2^32 pages), so on mundane systems you
won't hit this, but this should definitely be fixed.
Fixes:
0e4b01df8659 ("mm, memcg: throttle allocators when failing reclaim over memory.high")
Reported-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Cc: <stable@vger.kernel.org> [5.4.x+]
Link: http://lkml.kernel.org/r/80780887060514967d414b3cd91f9a316a16ab98.1584036142.git.chris@chrisdown.name
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Qian Cai [Sun, 22 Mar 2020 01:22:17 +0000 (18:22 -0700)]
page-flags: fix a crash at SetPageError(THP_SWAP)
Commit
bd4c82c22c36 ("mm, THP, swap: delay splitting THP after swapped
out") supported writing THP to a swap device but forgot to upgrade an
older commit
df8c94d13c7e ("page-flags: define behavior of FS/IO-related
flags on compound pages") which could trigger a crash during THP
swapping out with DEBUG_VM_PGFLAGS=y,
kernel BUG at include/linux/page-flags.h:317!
page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page))
page:
fffff3b2ec3a8000 refcount:512 mapcount:0 mapping:
000000009eb0338c index:0x7f6e58200 head:
fffff3b2ec3a8000 order:9 compound_mapcount:0 compound_pincount:0
anon flags: 0x45fffe0000d8454(uptodate|lru|workingset|owner_priv_1|writeback|head|reclaim|swapbacked)
end_swap_bio_write()
SetPageError(page)
VM_BUG_ON_PAGE(1 && PageCompound(page))
<IRQ>
bio_endio+0x297/0x560
dec_pending+0x218/0x430 [dm_mod]
clone_endio+0xe4/0x2c0 [dm_mod]
bio_endio+0x297/0x560
blk_update_request+0x201/0x920
scsi_end_request+0x6b/0x4b0
scsi_io_completion+0x509/0x7e0
scsi_finish_command+0x1ed/0x2a0
scsi_softirq_done+0x1c9/0x1d0
__blk_mqnterrupt+0xf/0x20
</IRQ>
Fix by checking PF_NO_TAIL in those places instead.
Fixes:
bd4c82c22c36 ("mm, THP, swap: delay splitting THP after swapped out")
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Acked-by: "Huang, Ying" <ying.huang@intel.com>
Acked-by: Rafael Aquini <aquini@redhat.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200310235846.1319-1-cai@lca.pw
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Baoquan He [Sun, 22 Mar 2020 01:22:13 +0000 (18:22 -0700)]
mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
In section_deactivate(), pfn_to_page() doesn't work any more after
ms->section_mem_map is resetting to NULL in SPARSEMEM|!VMEMMAP case. It
causes a hot remove failure:
kernel BUG at mm/page_alloc.c:4806!
invalid opcode: 0000 [#1] SMP PTI
CPU: 3 PID: 8 Comm: kworker/u16:0 Tainted: G W 5.5.0-next-
20200205+ #340
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
Workqueue: kacpi_hotplug acpi_hotplug_work_fn
RIP: 0010:free_pages+0x85/0xa0
Call Trace:
__remove_pages+0x99/0xc0
arch_remove_memory+0x23/0x4d
try_remove_memory+0xc8/0x130
__remove_memory+0xa/0x11
acpi_memory_device_remove+0x72/0x100
acpi_bus_trim+0x55/0x90
acpi_device_hotplug+0x2eb/0x3d0
acpi_hotplug_work_fn+0x1a/0x30
process_one_work+0x1a7/0x370
worker_thread+0x30/0x380
kthread+0x112/0x130
ret_from_fork+0x35/0x40
Let's move the ->section_mem_map resetting after
depopulate_section_memmap() to fix it.
[akpm@linux-foundation.org: remove unneeded initialization, per David]
Fixes:
ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug")
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200307084229.28251-2-bhe@redhat.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Chunguang Xu [Sun, 22 Mar 2020 01:22:10 +0000 (18:22 -0700)]
memcg: fix NULL pointer dereference in __mem_cgroup_usage_unregister_event
An eventfd monitors multiple memory thresholds of the cgroup, closes them,
the kernel deletes all events related to this eventfd. Before all events
are deleted, another eventfd monitors the memory threshold of this cgroup,
leading to a crash:
BUG: kernel NULL pointer dereference, address:
0000000000000004
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD
800000033058e067 P4D
800000033058e067 PUD
3355ce067 PMD 0
Oops: 0002 [#1] SMP PTI
CPU: 2 PID: 14012 Comm: kworker/2:6 Kdump: loaded Not tainted 5.6.0-rc4 #3
Hardware name: LENOVO 20AWS01K00/20AWS01K00, BIOS GLET70WW (2.24 ) 05/21/2014
Workqueue: events memcg_event_remove
RIP: 0010:__mem_cgroup_usage_unregister_event+0xb3/0x190
RSP: 0018:
ffffb47e01c4fe18 EFLAGS:
00010202
RAX:
0000000000000001 RBX:
ffff8bb223a8a000 RCX:
0000000000000001
RDX:
0000000000000001 RSI:
ffff8bb22fb83540 RDI:
0000000000000001
RBP:
ffffb47e01c4fe48 R08:
0000000000000000 R09:
0000000000000010
R10:
000000000000000c R11:
071c71c71c71c71c R12:
ffff8bb226aba880
R13:
ffff8bb223a8a480 R14:
0000000000000000 R15:
0000000000000000
FS:Â
0000000000000000(0000) GS:
ffff8bb242680000(0000) knlGS:
0000000000000000
CS:Â 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000004 CR3:
000000032c29c003 CR4:
00000000001606e0
Call Trace:
memcg_event_remove+0x32/0x90
process_one_work+0x172/0x380
worker_thread+0x49/0x3f0
kthread+0xf8/0x130
ret_from_fork+0x35/0x40
CR2:
0000000000000004
We can reproduce this problem in the following ways:
1. We create a new cgroup subdirectory and a new eventfd, and then we
monitor multiple memory thresholds of the cgroup through this eventfd.
2. closing this eventfd, and __mem_cgroup_usage_unregister_event ()
will be called multiple times to delete all events related to this
eventfd.
The first time __mem_cgroup_usage_unregister_event() is called, the
kernel will clear all items related to this eventfd in thresholds->
primary.
Since there is currently only one eventfd, thresholds-> primary becomes
empty, so the kernel will set thresholds-> primary and hresholds-> spare
to NULL. If at this time, the user creates a new eventfd and monitor
the memory threshold of this cgroup, kernel will re-initialize
thresholds-> primary.
Then when __mem_cgroup_usage_unregister_event () is called for the
second time, because thresholds-> primary is not empty, the system will
access thresholds-> spare, but thresholds-> spare is NULL, which will
trigger a crash.
In general, the longer it takes to delete all events related to this
eventfd, the easier it is to trigger this problem.
The solution is to check whether the thresholds associated with the
eventfd has been cleared when deleting the event. If so, we do nothing.
[akpm@linux-foundation.org: fix comment, per Kirill]
Fixes:
907860ed381a ("cgroups: make cftype.unregister_event() void-returning")
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/077a6f67-aefa-4591-efec-f2f3af2b0b02@gmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sat, 21 Mar 2020 19:08:26 +0000 (12:08 -0700)]
Merge tag 'block-5.6-
20200320' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"Just two NVMe fabrics fixes that should go into 5.6"
* tag 'block-5.6-
20200320' of git://git.kernel.dk/linux-block:
nvmet-tcp: set MSG_MORE only if we actually have more to send
nvme-rdma: Avoid double freeing of async event data
Linus Torvalds [Sat, 21 Mar 2020 18:54:47 +0000 (11:54 -0700)]
Merge tag 'io_uring-5.6-
20200320' of git://git.kernel.dk/linux-block
Pull io_uring fixes from Jens Axboe:
"Two different fixes in here:
- Fix for a potential NULL pointer deref for links with async or
drain marked (Pavel)
- Fix for not properly checking RLIMIT_NOFILE for async punted
operations.
This affects openat/openat2, which were added this cycle, and
accept4. I did a full audit of other cases where we might check
current->signal->rlim[] and found only RLIMIT_FSIZE for buffered
writes and fallocate. That one is fixed and queued for 5.7 and
marked stable"
* tag 'io_uring-5.6-
20200320' of git://git.kernel.dk/linux-block:
io_uring: make sure accept honor rlimit nofile
io_uring: make sure openat/openat2 honor rlimit nofile
io_uring: NULL-deref for IOSQE_{ASYNC,DRAIN}
Linus Torvalds [Sat, 21 Mar 2020 18:50:36 +0000 (11:50 -0700)]
Merge branch 'turbostat' of git://git./linux/kernel/git/lenb/linux
Pull turbostat updates from Len Brown:
"Update to turbostat v20.03.20.
These patches unlock the full turbostat features for some new
machines, plus a couple other minor tweaks"
* 'turbostat' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
tools/power turbostat: update version
tools/power turbostat: Print cpuidle information
tools/power turbostat: Fix 32-bit capabilities warning
tools/power turbostat: Fix missing SYS_LPI counter on some Chromebooks
tools/power turbostat: Support Elkhart Lake
tools/power turbostat: Support Jasper Lake
tools/power turbostat: Support Ice Lake server
tools/power turbostat: Support Tiger Lake
tools/power turbostat: Fix gcc build warnings
tools/power turbostat: Support Cometlake
Linus Torvalds [Sat, 21 Mar 2020 15:51:45 +0000 (08:51 -0700)]
Merge tag 'powerpc-5.6-5' of git://git./linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
"Two fixes for bugs introduced this cycle:
- fix a crash when shutting down a KVM PR guest (our original style
of KVM which doesn't use hypervisor mode)
- fix for the recently added 32-bit KASAN_VMALLOC support
Thanks to: Christophe Leroy, Greg Kurz, Sean Christopherson"
* tag 'powerpc-5.6-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
KVM: PPC: Fix kernel crash with PR KVM
powerpc/kasan: Fix shadow memory protection with CONFIG_KASAN_VMALLOC
Len Brown [Mon, 18 Nov 2019 02:18:31 +0000 (21:18 -0500)]
tools/power turbostat: update version
A stitch in time saves nine.
Signed-off-by: Len Brown <len.brown@intel.com>
Len Brown [Sat, 21 Mar 2020 04:47:47 +0000 (00:47 -0400)]
tools/power turbostat: Print cpuidle information
Print cpuidle driver and governor.
Originally-by: Antti Laakso <antti.laakso@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Jens Axboe [Sat, 21 Mar 2020 01:14:16 +0000 (19:14 -0600)]
Merge branch 'nvme-5.6-rc6' of git://git.infradead.org/nvme into block-5.6
Pull NVMe fixes from Keith:
"Two late nvme fabrics fixes for 5.6: a double free with the rdma
transport, and a regression fix for tcp; please pull."
* 'nvme-5.6-rc6' of git://git.infradead.org/nvme:
nvmet-tcp: set MSG_MORE only if we actually have more to send
nvme-rdma: Avoid double freeing of async event data
Filipe Manana [Fri, 20 Mar 2020 18:43:48 +0000 (18:43 +0000)]
btrfs: fix removal of raid[56|1c34} incompat flags after removing block group
We are incorrectly dropping the raid56 and raid1c34 incompat flags when
there are still raid56 and raid1c34 block groups, not when we do not any
of those anymore. The logic just got unintentionally broken after adding
the support for the raid1c34 modes.
Fix this by clear the flags only if we do not have block groups with the
respective profiles.
Fixes:
9c907446dce3 ("btrfs: drop incompat bit for raid1c34 after last block group is gone")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Sagi Grimberg [Thu, 12 Mar 2020 23:06:38 +0000 (16:06 -0700)]
nvmet-tcp: set MSG_MORE only if we actually have more to send
When we send PDU data, we want to optimize the tcp stack
operation if we have more data to send. So when we set MSG_MORE
when:
- We have more fragments coming in the batch, or
- We have a more data to send in this PDU
- We don't have a data digest trailer
- We optimize with the SUCCESS flag and omit the NVMe completion
(used if sq_head pointer update is disabled)
This addresses a regression in QD=1 with SUCCESS flag optimization
as we unconditionally set MSG_MORE when we didn't actually have
more data to send.
Fixes:
70583295388a ("nvmet-tcp: implement C2HData SUCCESS optimization")
Reported-by: Mark Wunderlich <mark.wunderlich@intel.com>
Tested-by: Mark Wunderlich <mark.wunderlich@intel.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Linus Torvalds [Fri, 20 Mar 2020 16:28:25 +0000 (09:28 -0700)]
Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
- Fix panic() when it occurs during secondary CPU startup
- Fix "kpti=off" when KASLR is enabled
- Fix howler in compat syscall table for vDSO clock_getres() fallback
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: compat: Fix syscall number of compat_clock_getres
arm64: kpti: Fix "kpti=off" when KASLR is enabled
arm64: smp: fix crash_smp_send_stop() behaviour
arm64: smp: fix smp_send_stop() behaviour
Linus Torvalds [Fri, 20 Mar 2020 16:24:22 +0000 (09:24 -0700)]
Merge tag 'char-misc-5.6-rc7' of git://git./linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are some small different driver fixes for 5.6-rc7:
- binderfs fix, yet again
- slimbus new device id added
- hwtracing bugfixes for reported issues and a new device id
All of these have been in linux-next with no reported issues"
* tag 'char-misc-5.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
intel_th: pci: Add Elkhart Lake CPU support
intel_th: Fix user-visible error codes
intel_th: msu: Fix the unexpected state warning
stm class: sys-t: Fix the use of time_after()
slimbus: ngd: add v2.1.0 compatible
binderfs: use refcount for binder control devices too
Linus Torvalds [Fri, 20 Mar 2020 16:20:38 +0000 (09:20 -0700)]
Merge tag 'staging-5.6-rc7' of git://git./linux/kernel/git/gregkh/staging
Pull staging/IIO fixes from Greg KH:
"Here are a number of small staging and IIO driver fixes for 5.6-rc7
Nothing major here, just resolutions for some reported problems:
- iio bugfixes for a number of different drivers
- greybus loopback_test fixes
- wfx driver fixes
All of these have been in linux-next with no reported issues"
* tag 'staging-5.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: rtl8188eu: Add device id for MERCUSYS MW150US v2
staging: greybus: loopback_test: fix potential path truncations
staging: greybus: loopback_test: fix potential path truncation
staging: greybus: loopback_test: fix poll-mask build breakage
staging: wfx: fix RCU usage between hif_join() and ieee80211_bss_get_ie()
staging: wfx: fix RCU usage in wfx_join_finalize()
staging: wfx: make warning about pending frame less scary
staging: wfx: fix lines ending with a comma instead of a semicolon
staging: wfx: fix warning about freeing in-use mutex during device unregister
staging/speakup: fix get_word non-space look-ahead
iio: ping: set pa_laser_ping_cfg in of_ping_match
iio: chemical: sps30: fix missing triggered buffer dependency
iio: st_sensors: remap SMO8840 to LIS2DH12
iio: light: vcnl4000: update sampling periods for vcnl4040
iio: light: vcnl4000: update sampling periods for vcnl4200
iio: accel: adxl372: Set iio_chan BE
iio: magnetometer: ak8974: Fix negative raw values in sysfs
iio: trigger: stm32-timer: disable master mode when stopping
iio: adc: stm32-dfsdm: fix sleep in atomic context
iio: adc: at91-sama5d2_adc: fix differential channels in triggered mode
Linus Torvalds [Fri, 20 Mar 2020 16:16:35 +0000 (09:16 -0700)]
Merge tag 'usb-5.6-rc7' of git://git./linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB fixes for 5.6-rc7. And there's a thunderbolt
driver fix thrown in for good measure as well.
These fixes are:
- new device ids for usb-serial drivers
- thunderbolt error code fix
- xhci driver fixes
- typec fixes
- cdc-acm driver fixes
- chipidea driver fix
- more USB quirks added for devices that need them.
All of these have been in linux-next with no reported issues"
* tag 'usb-5.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: cdc-acm: fix rounding error in TIOCSSERIAL
USB: cdc-acm: fix close_delay and closing_wait units in TIOCSSERIAL
usb: quirks: add NO_LPM quirk for RTL8153 based ethernet adapters
usb: chipidea: udc: fix sleeping function called from invalid context
USB: serial: pl2303: add device-id for HP LD381
USB: serial: option: add ME910G1 ECM composition 0x110b
usb: host: xhci-plat: add a shutdown
usb: typec: ucsi: displayport: Fix a potential race during registration
usb: typec: ucsi: displayport: Fix NULL pointer dereference
USB: Disable LPM on WD19's Realtek Hub
usb: xhci: apply XHCI_SUSPEND_DELAY to AMD XHCI controller 1022:145c
xhci: Do not open code __print_symbolic() in xhci trace events
thunderbolt: Fix error code in tb_port_is_width_supported()
Linus Torvalds [Fri, 20 Mar 2020 16:13:35 +0000 (09:13 -0700)]
Merge tag 'tty-5.6-rc7' of git://git./linux/kernel/git/gregkh/tty
Pull tty fixes from Greg KH:
"Here are three small tty_io bugfixes for reported issues that Eric has
resolved for 5.6-rc7
All of these have been in linux-next with no reported issues"
* tag 'tty-5.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: fix compat TIOCGSERIAL checking wrong function ptr
tty: fix compat TIOCGSERIAL leaking uninitialized memory
tty: drop outdated comments about release_tty() locking
Linus Torvalds [Fri, 20 Mar 2020 16:10:29 +0000 (09:10 -0700)]
Merge tag 'sound-5.6-rc7' of git://git./linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A few fixes covering the issues reported by syzkaller, a couple of
fixes for the MIDI decoding bug, and a few usual HD-audio quirks.
Some of them are about ALSA core stuff, but they are small fixes just
for corner cases, and nothing thrilling"
* tag 'sound-5.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda/realtek - Enable the headset of Acer N50-600 with ALC662
ALSA: hda/realtek - Enable headset mic of Acer X2660G with ALC662
ALSA: seq: oss: Fix running status after receiving sysex
ALSA: seq: virmidi: Fix running status after receiving sysex
ALSA: pcm: oss: Remove WARNING from snd_pcm_plug_alloc() checks
ALSA: hda/realtek: Fix pop noise on ALC225
ALSA: line6: Fix endless MIDI read loop
ALSA: pcm: oss: Avoid plugin buffer overflow
Linus Torvalds [Fri, 20 Mar 2020 16:03:54 +0000 (09:03 -0700)]
Merge tag 'drm-fixes-2020-03-20' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Hope you are well hiding out above the garage. A few amdgpu changes
but nothing too major. I've had a wisdom tooth out this week so
haven't been to on top of things, but all seems good.
core:
- fix lease warning
i915:
- Track active elements during dequeue
- Fix failure to handle all MCR ranges
- Revert unnecessary workaround
amdgpu:
- Pageflip fix
- VCN clockgating fixes
- GPR debugfs fix for umr
- GPU reset fix
- eDP fix for MBP
- DCN2.x fix
dw-hdmi:
- fix AVI frame colorimetry
komeda:
- fix compiler warning
bochs:
- downgrade a binding failure to a warning"
* tag 'drm-fixes-2020-03-20' of git://anongit.freedesktop.org/drm/drm:
drm/amd/display: Fix pageflip event race condition for DCN.
drm/amdgpu: fix typo for vcn2.5/jpeg2.5 idle check
drm/amdgpu: fix typo for vcn2/jpeg2 idle check
drm/amdgpu: fix typo for vcn1 idle check
drm/lease: fix WARNING in idr_destroy
drm/i915: Handle all MCR ranges
Revert "drm/i915/tgl: Add extra hdc flush workaround"
drm/i915/execlists: Track active elements during dequeue
drm/bochs: downgrade pci_request_region failure from error to warning
drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017
drm/amdgpu: add fbdev suspend/resume on gpu reset
drm/amd/amdgpu: Fix GPR read from debugfs (v2)
drm/amd/display: fix typos for dcn20_funcs and dcn21_funcs struct
drm/komeda: mark PM functions as __maybe_unused
drm/bridge: dw-hdmi: fix AVI frame colorimetry
Joerg Roedel [Fri, 20 Mar 2020 16:03:21 +0000 (17:03 +0100)]
Merge tag 'arm-smmu-updates' of git://git./linux/kernel/git/will/linux into arm/smmu
Arm SMMU updates for 5.7
- Support for the TLB range invalidation command in SMMUv3.2
- Introduction of command batching helpers...
- ... which are then used to batch up CD and ATC invalidation
- Support for PCI PASID, along with necessary PCI symbol exports
- MAINTAINERS update to include DT binding docs
Jens Axboe [Fri, 20 Mar 2020 02:16:56 +0000 (20:16 -0600)]
io_uring: make sure accept honor rlimit nofile
Just like commit
4022e7af86be, this fixes the fact that
IORING_OP_ACCEPT ends up using get_unused_fd_flags(), which checks
current->signal->rlim[] for limits.
Add an extra argument to __sys_accept4_file() that allows us to pass
in the proper nofile limit, and grab it at request prep time.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Jens Axboe [Fri, 20 Mar 2020 01:23:18 +0000 (19:23 -0600)]
io_uring: make sure openat/openat2 honor rlimit nofile
Dmitry reports that a test case shows that io_uring isn't honoring a
modified rlimit nofile setting. get_unused_fd_flags() checks the task
signal->rlimi[] for the limits. As this isn't easily inheritable,
provide a __get_unused_fd_flags() that takes the value instead. Then we
can grab it when the request is prepared (from the original task), and
pass that in when we do the async part part of the open.
Reported-by: Dmitry Kadashev <dkadashev@gmail.com>
Tested-by: Dmitry Kadashev <dkadashev@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Len Brown [Fri, 20 Mar 2020 03:24:17 +0000 (23:24 -0400)]
tools/power turbostat: Fix 32-bit capabilities warning
warning: `turbostat' uses 32-bit capabilities (legacy support in use)
Signed-off-by: Len Brown <len.brown@intel.com>
Len Brown [Thu, 19 Mar 2020 22:26:05 +0000 (18:26 -0400)]
tools/power turbostat: Fix missing SYS_LPI counter on some Chromebooks
Some Chromebook BIOS' do not export an ACPI LPIT, which is how
Linux finds the residency counter for CPU and SYSTEM low power states,
that is exports in /sys/devices/system/cpu/cpuidle/*residency_us
When these sysfs attributes are missing, check the debugfs attrubte
from the pmc_core driver, which accesses the same counter value.
Signed-off-by: Len Brown <len.brown@intel.com>
Chen Yu [Wed, 18 Mar 2020 10:55:48 +0000 (18:55 +0800)]
tools/power turbostat: Support Elkhart Lake
From a turbostat point of view the Tremont-based Elkhart Lake
is very similar to Goldmont, reuse the code of Goldmont.
Elkhart Lake does not support 'group turbo limit counter'
nor C3, adjust the code accordingly.
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Chen Yu [Tue, 14 Jan 2020 04:09:45 +0000 (12:09 +0800)]
tools/power turbostat: Support Jasper Lake
Jasper Lake, like Elkhart Lake, uses a Tremont CPU.
So reuse the code.
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Chen Yu [Tue, 14 Jan 2020 04:06:49 +0000 (12:06 +0800)]
tools/power turbostat: Support Ice Lake server
From a turbostat point of view, Ice Lake server looks like Sky Lake server.
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Chen Yu [Tue, 14 Jan 2020 04:04:55 +0000 (12:04 +0800)]
tools/power turbostat: Support Tiger Lake
From a turbostat point of view, Tiger Lake looks like Ice Lake.
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Len Brown [Thu, 19 Mar 2020 22:33:12 +0000 (18:33 -0400)]
tools/power turbostat: Fix gcc build warnings
Warning: ‘__builtin_strncpy’ specified bound 20 equals destination size
[-Wstringop-truncation]
reduce param to strncpy, to guarantee that a null byte is always copied
into destination buffer.
Signed-off-by: Len Brown <len.brown@intel.com>
Chen Yu [Thu, 31 Oct 2019 13:14:22 +0000 (21:14 +0800)]
tools/power turbostat: Support Cometlake
From a turbostat point of view, Cometlake is like Kabylake.
Suggested-by: Rui Zhang <rui.zhang@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Dave Airlie [Fri, 20 Mar 2020 02:51:34 +0000 (12:51 +1000)]
Merge tag 'drm-intel-fixes-2020-03-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
drm/i915 fixes for v5.6-rc7:
- Track active elements during dequeue
- Fix failure to handle all MCR ranges
- Revert unnecessary workaround
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/877dzgepvu.fsf@intel.com
Dave Airlie [Fri, 20 Mar 2020 02:48:10 +0000 (12:48 +1000)]
Merge tag 'amd-drm-fixes-5.6-2020-03-19' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
amd-drm-fixes-5.6-2020-03-19:
amdgpu:
- Pageflip fix
- VCN clockgating fixes
- GPR debugfs fix for umr
- GPU reset fix
- eDP fix for MBP
- DCN2.x fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200319204054.1036478-1-alexander.deucher@amd.com
Greg Kurz [Wed, 18 Mar 2020 17:43:30 +0000 (18:43 +0100)]
KVM: PPC: Fix kernel crash with PR KVM
With PR KVM, shutting down a VM causes the host kernel to crash:
[ 314.219284] BUG: Unable to handle kernel data access on read at 0xc00800000176c638
[ 314.219299] Faulting instruction address: 0xc008000000d4ddb0
cpu 0x0: Vector: 300 (Data Access) at [
c00000036da077a0]
pc:
c008000000d4ddb0: kvmppc_mmu_pte_flush_all+0x68/0xd0 [kvm_pr]
lr:
c008000000d4dd94: kvmppc_mmu_pte_flush_all+0x4c/0xd0 [kvm_pr]
sp:
c00000036da07a30
msr:
900000010280b033
dar:
c00800000176c638
dsisr:
40000000
current = 0xc00000036d4c0000
paca = 0xc000000001a00000 irqmask: 0x03 irq_happened: 0x01
pid = 1992, comm = qemu-system-ppc
Linux version 5.6.0-master-gku+ (greg@palmb) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #17 SMP Wed Mar 18 13:49:29 CET 2020
enter ? for help
[
c00000036da07ab0]
c008000000d4fbe0 kvmppc_mmu_destroy_pr+0x28/0x60 [kvm_pr]
[
c00000036da07ae0]
c0080000009eab8c kvmppc_mmu_destroy+0x34/0x50 [kvm]
[
c00000036da07b00]
c0080000009e50c0 kvm_arch_vcpu_destroy+0x108/0x140 [kvm]
[
c00000036da07b30]
c0080000009d1b50 kvm_vcpu_destroy+0x28/0x80 [kvm]
[
c00000036da07b60]
c0080000009e4434 kvm_arch_destroy_vm+0xbc/0x190 [kvm]
[
c00000036da07ba0]
c0080000009d9c2c kvm_put_kvm+0x1d4/0x3f0 [kvm]
[
c00000036da07c00]
c0080000009da760 kvm_vm_release+0x38/0x60 [kvm]
[
c00000036da07c30]
c000000000420be0 __fput+0xe0/0x310
[
c00000036da07c90]
c0000000001747a0 task_work_run+0x150/0x1c0
[
c00000036da07cf0]
c00000000014896c do_exit+0x44c/0xd00
[
c00000036da07dc0]
c0000000001492f4 do_group_exit+0x64/0xd0
[
c00000036da07e00]
c000000000149384 sys_exit_group+0x24/0x30
[
c00000036da07e20]
c00000000000b9d0 system_call+0x5c/0x68
This is caused by a use-after-free in kvmppc_mmu_pte_flush_all()
which dereferences vcpu->arch.book3s which was previously freed by
kvmppc_core_vcpu_free_pr(). This happens because kvmppc_mmu_destroy()
is called after kvmppc_core_vcpu_free() since commit
ff030fdf5573
("KVM: PPC: Move kvm_vcpu_init() invocation to common code").
The kvmppc_mmu_destroy() helper calls one of the following depending
on the KVM backend:
- kvmppc_mmu_destroy_hv() which does nothing (Book3s HV)
- kvmppc_mmu_destroy_pr() which undoes the effects of
kvmppc_mmu_init() (Book3s PR 32-bit)
- kvmppc_mmu_destroy_pr() which undoes the effects of
kvmppc_mmu_init() (Book3s PR 64-bit)
- kvmppc_mmu_destroy_e500() which does nothing (BookE e500/e500mc)
It turns out that this is only relevant to PR KVM actually. And both
32 and 64 backends need vcpu->arch.book3s to be valid when calling
kvmppc_mmu_destroy_pr(). So instead of calling kvmppc_mmu_destroy()
from kvm_arch_vcpu_destroy(), call kvmppc_mmu_destroy_pr() at the
beginning of kvmppc_core_vcpu_free_pr(). This is consistent with
kvmppc_mmu_init() being the last call in kvmppc_core_vcpu_create_pr().
For the same reason, if kvmppc_core_vcpu_create_pr() returns an
error then this means that kvmppc_mmu_init() was either not called
or failed, in which case kvmppc_mmu_destroy() should not be called.
Drop the line in the error path of kvm_arch_vcpu_create().
Fixes:
ff030fdf5573 ("KVM: PPC: Move kvm_vcpu_init() invocation to common code")
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/158455341029.178873.15248663726399374882.stgit@bahia.lan
Mario Kleiner [Mon, 2 Mar 2020 06:17:32 +0000 (07:17 +0100)]
drm/amd/display: Fix pageflip event race condition for DCN.
Commit '
16f17eda8bad ("drm/amd/display: Send vblank and user
events at vsartup for DCN")' introduces a new way of pageflip
completion handling for DCN, and some trouble.
The current implementation introduces a race condition, which
can cause pageflip completion events to be sent out one vblank
too early, thereby confusing userspace and causing flicker:
prepare_flip_isr():
1. Pageflip programming takes the ddev->event_lock.
2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED
3. Releases ddev->event_lock.
--> Deadline for surface address regs double-buffering passes on
target pipe.
4. dc_commit_updates_for_stream() MMIO programs the new pageflip
into hw, but too late for current vblank.
=> pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete
in current vblank due to missing the double-buffering deadline
by a tiny bit.
5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires,
dm_dcn_crtc_high_irq() gets called.
6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the
pageflip has been completed/will complete in this vblank and
sends out pageflip completion event to userspace and resets
pflip_status = AMDGPU_FLIP_NONE.
=> Flip completion event sent out one vblank too early.
This behaviour has been observed during my testing with measurement
hardware a couple of time.
The commit message says that the extra flip event code was added to
dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events
in case the pflip irq doesn't fire, because the "DCH HUBP" component
is clock gated and doesn't fire pflip irqs in that state. Also that
this clock gating may happen if no planes are active. This suggests
that the problem addressed by that commit can't happen if planes
are active.
The proposed solution is therefore to only execute the extra pflip
completion code iff the count of active planes is zero and otherwise
leave pflip completion handling to the pflip irq handler, for a
more race-free experience.
Note that i don't know if this fixes the problem the original commit
tried to address, as i don't know what the test scenario was. It
does fix the observed too early pageflip events though and points
out the problem introduced.
Fixes:
16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup for DCN")
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Linus Torvalds [Thu, 19 Mar 2020 19:45:14 +0000 (12:45 -0700)]
Merge tag 'mmc-v5.6-rc6' of git://git./linux/kernel/git/ulfh/mmc
Pull MMC fixes from Ulf Hansson:
- rtsx_pci: Fix support for some various speed modes
- sdhci-of-at91: Fix support for GPIO card detect on SAMA5D2
- sdhci-cadence: Fix support for DDR52 speed mode for eMMC on UniPhier
- sdhci-acpi: Fix broken WP support on Acer Aspire Switch 10
- sdhci-acpi: Workaround FW bug for suspend on Lenovo Miix 320
* tag 'mmc-v5.6-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: rtsx_pci: Fix support for speed-modes that relies on tuning
mmc: sdhci-of-at91: fix cd-gpios for SAMA5D2
mmc: sdhci-cadence: set SDHCI_QUIRK2_PRESET_VALUE_BROKEN for UniPhier
mmc: sdhci-acpi: Disable write protect detection on Acer Aspire Switch 10 (SW5-012)
mmc: sdhci-acpi: Switch signal voltage back to 3.3V on suspend on external microSD on Lenovo Miix 320
Vincenzo Frascino [Thu, 19 Mar 2020 14:11:38 +0000 (14:11 +0000)]
arm64: compat: Fix syscall number of compat_clock_getres
The syscall number of compat_clock_getres was erroneously set to 247
(__NR_io_cancel!) instead of 264. This causes the vDSO fallback of
clock_getres() to land on the wrong syscall for compat tasks.
Fix the numbering.
Cc: <stable@vger.kernel.org>
Fixes:
53c489e1dfeb6 ("arm64: compat: Add missing syscall numbers")
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Linus Torvalds [Thu, 19 Mar 2020 17:19:11 +0000 (10:19 -0700)]
Merge tag '5.6-rc6-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs fixes from Steve French:
"Three small smb3 fixes, two for stable"
* tag '5.6-rc6-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
CIFS: fiemap: do not return EINVAL if get nothing
CIFS: Increment num_remote_opens stats counter even in case of smb2_query_dir_first
cifs: potential unintitliazed error code in cifs_getattr()
Linus Torvalds [Thu, 19 Mar 2020 16:57:48 +0000 (09:57 -0700)]
Merge tag 'kbuild-fixes-v5.6-3' of git://git./linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- fix __uint128_t capability test in Kconfig when GCC that defaults to
32-bit is used to build the 64-bit kernel
- suppress new noisy Clang warnings -Wpointer-to-enum-cast
- move the namespace field in Module.symvers for the backward
compatibility reason for the depmod tool
- use available compression for initramdisk when INTRAMFS_SOURCE is
defined, which was the original behavior
- fix modpost to handle correct large section numbers when it refers to
modversion CRCs and module namespaces
- fix comments and documents
* tag 'kbuild-fixes-v5.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
scripts/kallsyms: fix wrong kallsyms_relative_base
modpost: Get proper section index by get_secindex() instead of st_shndx
initramfs: restore default compression behavior
modpost: move the namespace field in Module.symvers last
kbuild: Disable -Wpointer-to-enum-cast
kbuild: doc: fix references to other documents
int128: fix __uint128_t compiler test in Kconfig
kconfig: introduce m32-flag and m64-flag
kbuild: Fix inconsistent comment
Corentin Labbe [Wed, 18 Mar 2020 15:26:49 +0000 (15:26 +0000)]
rtc: max8907: add missing select REGMAP_IRQ
I have hit the following build error:
armv7a-hardfloat-linux-gnueabi-ld: drivers/rtc/rtc-max8907.o: in function `max8907_rtc_probe':
rtc-max8907.c:(.text+0x400): undefined reference to `regmap_irq_get_virq'
max8907 should select REGMAP_IRQ
Fixes:
94c01ab6d7544 ("rtc: add MAX8907 RTC driver")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Mikhail Petrov [Wed, 11 Mar 2020 20:37:09 +0000 (23:37 +0300)]
scripts/kallsyms: fix wrong kallsyms_relative_base
There is the code in the read_symbol function in 'scripts/kallsyms.c':
if (is_ignored_symbol(name, type))
return NULL;
/* Ignore most absolute/undefined (?) symbols. */
if (strcmp(name, "_text") == 0)
_text = addr;
But the is_ignored_symbol function returns true for name="_text" and
type='A'. So the next condition is not executed and the _text variable
is always zero.
It makes the wrong kallsyms_relative_base symbol as a result of the code
(CONFIG_KALLSYMS_BASE_RELATIVE is defined):
if (base_relative) {
output_label("kallsyms_relative_base");
output_address(relative_base);
printf("\n");
}
Because the output_address function uses the _text variable.
So the kallsyms_lookup function and all related functions in the kernel
do not work properly. For example, the stack trace in oops:
Call Trace:
[
aa095e58] [
809feab8] kobj_ns_ops_tbl+0x7ff09ac8/0x7ff1c1c4 (unreliable)
[
aa095e98] [
80002b64] kobj_ns_ops_tbl+0x7f50db74/0x80000010
[
aa095ef8] [
809c3d24] kobj_ns_ops_tbl+0x7feced34/0x7ff1c1c4
[
aa095f28] [
80002ed0] kobj_ns_ops_tbl+0x7f50dee0/0x80000010
[
aa095f38] [
8000f238] kobj_ns_ops_tbl+0x7f51a248/0x80000010
The right stack trace:
Call Trace:
[
aa095e58] [
809feab8] module_vdu_video_init+0x2fc/0x3bc (unreliable)
[
aa095e98] [
80002b64] do_one_initcall+0x40/0x1f0
[
aa095ef8] [
809c3d24] kernel_init_freeable+0x164/0x1d8
[
aa095f28] [
80002ed0] kernel_init+0x14/0x124
[
aa095f38] [
8000f238] ret_from_kernel_thread+0x14/0x1c
[masahiroy@kernel.org:
This issue happens on binutils <= 2.22
The following commit fixed it:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=
d2667025dd30611514810c28bee9709e4623012a
The symbol type of _text is 'T' on binutils >= 2.23
The minimal supported binutils version for the kernel build is 2.21
]
Signed-off-by: Mikhail Petrov <Mikhail.Petrov@mir.dev>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Qian Cai [Tue, 17 Mar 2020 15:03:26 +0000 (11:03 -0400)]
iommu/vt-d: Silence RCU-list debugging warning in dmar_find_atsr()
dmar_find_atsr() calls list_for_each_entry_rcu() outside of an RCU read
side critical section but with dmar_global_lock held. Silence this
false positive.
drivers/iommu/intel-iommu.c:4504 RCU-list traversed in non-reader section!!
1 lock held by swapper/0/1:
#0:
ffffffff9755bee8 (dmar_global_lock){+.+.}, at: intel_iommu_init+0x1a6/0xe19
Call Trace:
dump_stack+0xa4/0xfe
lockdep_rcu_suspicious+0xeb/0xf5
dmar_find_atsr+0x1ab/0x1c0
dmar_parse_one_atsr+0x64/0x220
dmar_walk_remapping_entries+0x130/0x380
dmar_table_init+0x166/0x243
intel_iommu_init+0x1ab/0xe19
pci_iommu_init+0x1a/0x44
do_one_initcall+0xae/0x4d0
kernel_init_freeable+0x412/0x4c5
kernel_init+0x19/0x193
Signed-off-by: Qian Cai <cai@lca.pw>
Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Jacob Pan [Tue, 17 Mar 2020 01:10:18 +0000 (09:10 +0800)]
iommu/vt-d: Fix page request descriptor size
Intel VT-d might support PRS (Page Reqest Support) when it's
running in the scalable mode. Each page request descriptor
occupies 32 bytes and is 32-bytes aligned. The page request
descriptor offset mask should be 32-bytes aligned.
Fixes:
5b438f4ba315d ("iommu/vt-d: Support page request in scalable mode")
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Will Deacon [Wed, 18 Mar 2020 20:38:29 +0000 (20:38 +0000)]
arm64: kpti: Fix "kpti=off" when KASLR is enabled
Enabling KASLR forces the use of non-global page-table entries for kernel
mappings, as this is a decision that we have to make very early on before
mapping the kernel proper. When used in conjunction with the "kpti=off"
command-line option, it is possible to use non-global kernel mappings but
with the kpti trampoline disabled.
Since commit
09e3c22a86f6 ("arm64: Use a variable to store non-global
mappings decision"), arm64_kernel_unmapped_at_el0() reflects only the use of
non-global mappings and does not take into account whether the kpti
trampoline is enabled. This breaks context switching of the TPIDRRO_EL0
register for 64-bit tasks, where the clearing of the register is deferred to
the ret-to-user code, but it also breaks the ARM SPE PMU driver which
helpfully recommends passing "kpti=off" on the command line!
Report whether or not KPTI is actually enabled in
arm64_kernel_unmapped_at_el0() and check the 'arm64_use_ng_mappings' global
variable directly when determining the protection flags for kernel mappings.
Cc: Mark Brown <broonie@kernel.org>
Reported-by: Hongbo Yao <yaohongbo@huawei.com>
Tested-by: Hongbo Yao <yaohongbo@huawei.com>
Fixes:
09e3c22a86f6 ("arm64: Use a variable to store non-global mappings decision")
Signed-off-by: Will Deacon <will@kernel.org>
Dave Airlie [Thu, 19 Mar 2020 01:47:41 +0000 (11:47 +1000)]
Merge tag 'drm-misc-fixes-2020-03-18-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
- drm/lease: fix WARNING in idr_destroy
- Fix AVI frame colorimetry in the dw-hdmi bridge.
- Fix compiler warning in komeda by annotating functions as __maybe_unused.
- Downgrade bochs pci_request_region failure from error to warning to
workaround firmware fb.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7654ac39-deb8-c9ca-9fd5-ef77b2636380@linux.intel.com
James Zhu [Wed, 18 Mar 2020 21:12:12 +0000 (17:12 -0400)]
drm/amdgpu: fix typo for vcn2.5/jpeg2.5 idle check
fix typo for vcn2.5/jpeg2.5 idle check
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
James Zhu [Wed, 18 Mar 2020 21:10:56 +0000 (17:10 -0400)]
drm/amdgpu: fix typo for vcn2/jpeg2 idle check
fix typo for vcn2/jpeg2 idle check
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
James Zhu [Wed, 18 Mar 2020 21:09:05 +0000 (17:09 -0400)]
drm/amdgpu: fix typo for vcn1 idle check
fix typo for vcn1 idle check
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rob Herring [Mon, 24 Feb 2020 22:31:29 +0000 (16:31 -0600)]
iommu/arm-smmu-v3: Add SMMUv3.2 range invalidation support
Arm SMMUv3.2 adds support for TLB range invalidate operations.
Support for range invalidate is determined by the RIL bit in the IDR3
register.
The range invalidate is in units of the leaf page size and operates on
1-32 chunks of a power of 2 multiple pages. First, we determine from the
size what power of 2 multiple we can use. Then we calculate how many
chunks (1-31) of the power of 2 size for the range on the iteration. On
each iteration, we move up in size by at least 5 bits.
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Rob Herring [Mon, 24 Feb 2020 16:58:46 +0000 (17:58 +0100)]
iommu/arm-smmu-v3: Batch ATC invalidation commands
Similar to commit
2af2e72b18b4 ("iommu/arm-smmu-v3: Defer TLB
invalidation until ->iotlb_sync()"), build up a list of ATC invalidation
commands and submit them all at once to the command queue instead of
one-by-one.
As there is only one caller of arm_smmu_atc_inv_master() left, we can
simplify it and avoid passing in struct arm_smmu_cmdq_ent.
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Jean-Philippe Brucker [Mon, 24 Feb 2020 16:58:45 +0000 (17:58 +0100)]
iommu/arm-smmu-v3: Batch context descriptor invalidation
Rather than publishing one command at a time when invalidating a context
descriptor, batch the commands for all SIDs in the domain.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Jean-Philippe Brucker [Mon, 24 Feb 2020 16:58:44 +0000 (17:58 +0100)]
iommu/arm-smmu-v3: Add command queue batching helpers
As more functions will implement command queue batching, add two helpers
to simplify building a command list.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Jean-Philippe Brucker [Mon, 24 Feb 2020 16:58:43 +0000 (17:58 +0100)]
iommu/arm-smmu-v3: Write level-1 descriptors atomically
Use WRITE_ONCE() to make sure that the SMMU doesn't read incomplete
stream table descriptors. Refer to the comment about 64-bit accesses,
and add the comment to the equivalent context descriptor code.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Jean-Philippe Brucker [Mon, 24 Feb 2020 16:58:42 +0000 (17:58 +0100)]
iommu/arm-smmu-v3: Add support for PCI PASID
Enable PASID for PCI devices that support it. Initialize PASID early in
add_device() because it must be enabled before ATS.
Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Jean-Philippe Brucker [Mon, 24 Feb 2020 16:58:41 +0000 (17:58 +0100)]
PCI/ATS: Export symbols of PASID functions
The Arm SMMUv3 driver uses pci_{enable,disable}_pasid() and related
functions. Export them to allow the driver to be built as a module.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Linus Torvalds [Wed, 18 Mar 2020 11:52:21 +0000 (07:52 -0400)]
locks: reinstate locks_delete_block optimization
There is measurable performance impact in some synthetic tests due to
commit
6d390e4b5d48 (locks: fix a potential use-after-free problem when
wakeup a waiter). Fix the race condition instead by clearing the
fl_blocker pointer after the wake_up, using explicit acquire/release
semantics.
This does mean that we can no longer use the clearing of fl_blocker as
the wait condition, so switch the waiters over to checking whether the
fl_blocked_member list_head is empty.
Reviewed-by: yangerkun <yangerkun@huawei.com>
Reviewed-by: NeilBrown <neilb@suse.de>
Fixes:
6d390e4b5d48 (locks: fix a potential use-after-free problem when wakeup a waiter)
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Xiao Yang [Wed, 18 Mar 2020 10:34:16 +0000 (18:34 +0800)]
modpost: Get proper section index by get_secindex() instead of st_shndx
(uint16_t) st_shndx is limited to 65535(i.e. SHN_XINDEX) so sym_get_data() gets
wrong section index by st_shndx if requested symbol contains extended section
index that is more than 65535. In this case, we need to get proper section index
by .symtab_shndx section.
Module.symvers generated by building kernel with "-ffunction-sections -fdata-sections"
shows the issue.
Fixes:
56067812d5b0 ("kbuild: modversions: add infrastructure for emitting relative CRCs")
Fixes:
e84f9fbbece1 ("modpost: refactor namespace_from_kstrtabns() to not hard-code section name")
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Linus Torvalds [Tue, 17 Mar 2020 18:04:09 +0000 (11:04 -0700)]
mm: slub: be more careful about the double cmpxchg of freelist
This is just a cleanup addition to Jann's fix to properly update the
transaction ID for the slub slowpath in commit
fd4d9c7d0c71 ("mm: slub:
add missing TID bump..").
The transaction ID is what protects us against any concurrent accesses,
but we should really also make sure to make the 'freelist' comparison
itself always use the same freelist value that we then used as the new
next free pointer.
Jann points out that if we do all of this carefully, we could skip the
transaction ID update for all the paths that only remove entries from
the lists, and only update the TID when adding entries (to avoid the ABA
issue with cmpxchg and list handling re-adding a previously seen value).
But this patch just does the "make sure to cmpxchg the same value we
used" rather than then try to be clever.
Acked-by: Jann Horn <jannh@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jann Horn [Tue, 17 Mar 2020 00:28:45 +0000 (01:28 +0100)]
mm: slub: add missing TID bump in kmem_cache_alloc_bulk()
When kmem_cache_alloc_bulk() attempts to allocate N objects from a percpu
freelist of length M, and N > M > 0, it will first remove the M elements
from the percpu freelist, then call ___slab_alloc() to allocate the next
element and repopulate the percpu freelist. ___slab_alloc() can re-enable
IRQs via allocate_slab(), so the TID must be bumped before ___slab_alloc()
to properly commit the freelist head change.
Fix it by unconditionally bumping c->tid when entering the slowpath.
Cc: stable@vger.kernel.org
Fixes:
ebe909e0fdb3 ("slub: improve bulk alloc strategy")
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Qiujun Huang [Wed, 18 Mar 2020 07:53:50 +0000 (15:53 +0800)]
drm/lease: fix WARNING in idr_destroy
drm_lease_create takes ownership of leases. And leases will be released
by drm_master_put.
drm_master_put
->drm_master_destroy
->idr_destroy
So we needn't call idr_destroy again.
Reported-and-tested-by: syzbot+05835159fe322770fe3d@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1584518030-4173-1-git-send-email-hqjagain@gmail.com
Eric Biggers [Mon, 24 Feb 2020 18:20:44 +0000 (10:20 -0800)]
tty: fix compat TIOCGSERIAL checking wrong function ptr
Commit
77654350306a ("take compat TIOC[SG]SERIAL treatment into
tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start
checking for the presence of the ->set_serial function pointer rather
than ->get_serial. This appears to be a copy-and-paste error, since
->get_serial is the function pointer that is called as well as the
pointer that is checked by the non-compat version of TIOCGSERIAL.
Fix this by checking the correct function pointer.
Fixes:
77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()")
Cc: <stable@vger.kernel.org> # v4.20+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200224182044.234553-3-ebiggers@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Mon, 24 Feb 2020 18:20:43 +0000 (10:20 -0800)]
tty: fix compat TIOCGSERIAL leaking uninitialized memory
Commit
77654350306a ("take compat TIOC[SG]SERIAL treatment into
tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start
copying a whole 'serial_struct32' to userspace rather than individual
fields, but failed to initialize all padding and fields -- namely the
hole after the 'iomem_reg_shift' field, and the 'reserved' field.
Fix this by initializing the struct to zero.
[v2: use sizeof, and convert the adjacent line for consistency.]
Reported-by: syzbot+8da9175e28eadcb203ce@syzkaller.appspotmail.com
Fixes:
77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()")
Cc: <stable@vger.kernel.org> # v4.20+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200224182044.234553-2-ebiggers@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Mon, 24 Feb 2020 07:33:59 +0000 (23:33 -0800)]
tty: drop outdated comments about release_tty() locking
The current version of the TTY code unlocks the tty_struct(s) before
release_tty() rather than after. Moreover, tty_unlock_pair() no longer
exists. Thus, remove the outdated comments regarding tty_unlock_pair().
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20200224073359.292795-1-ebiggers@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ricky Wu [Mon, 16 Mar 2020 02:52:32 +0000 (10:52 +0800)]
mmc: rtsx_pci: Fix support for speed-modes that relies on tuning
The TX/RX register should not be treated the same way to allow for better
support of tuning. Fix this by using a default initial value for TX.
Signed-off-by: Ricky Wu <ricky_wu@realtek.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200316025232.1167-1-ricky_wu@realtek.com
[Ulf: Updated changelog]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Shishkin [Tue, 17 Mar 2020 06:22:15 +0000 (08:22 +0200)]
intel_th: pci: Add Elkhart Lake CPU support
This adds support for the Trace Hub in Elkhart Lake CPU.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200317062215.15598-7-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Shishkin [Tue, 17 Mar 2020 06:22:14 +0000 (08:22 +0200)]
intel_th: Fix user-visible error codes
There are a few places in the driver that end up returning ENOTSUPP to
the user, replace those with EINVAL.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Fixes:
ba82664c134ef ("intel_th: Add Memory Storage Unit driver")
Cc: stable@vger.kernel.org # v4.4+
Link: https://lore.kernel.org/r/20200317062215.15598-6-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Shishkin [Tue, 17 Mar 2020 06:22:13 +0000 (08:22 +0200)]
intel_th: msu: Fix the unexpected state warning
The unexpected state warning should only warn on illegal state
transitions. Fix that.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Fixes:
615c164da0eb4 ("intel_th: msu: Introduce buffer interface")
Cc: stable@vger.kernel.org # v5.4+
Link: https://lore.kernel.org/r/20200317062215.15598-5-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Shishkin [Tue, 17 Mar 2020 06:22:11 +0000 (08:22 +0200)]
stm class: sys-t: Fix the use of time_after()
The operands of time_after() are in a wrong order in both instances in
the sys-t driver. Fix that.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Fixes:
39f10239df75 ("stm class: p_sys-t: Add support for CLOCKSYNC packets")
Fixes:
d69d5e83110f ("stm class: Add MIPI SyS-T protocol support")
Cc: stable@vger.kernel.org # v4.20+
Link: https://lore.kernel.org/r/20200317062215.15598-3-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 18 Mar 2020 10:20:42 +0000 (11:20 +0100)]
Merge tag 'iio-fixes-for-5.6a' of git://git./linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First set of IIO fixes in the 5.6 cycle.
* adxl372
- Fix marking of buffered values as big endian.
* ak8974
- Fix wrong handling of negative values when read from sysfs.
* at91-sama5d2
- Fix differential mode by ensuring configuration set correctly.
* ping
- Use the write sensor type for of_ping_match table.
* sps30
- Kconfig build dependency fix.
* st-sensors
- Fix a wrong identification of which part the SMO8840 ACPI ID indicates.
* stm32-dsfdm
- Fix a sleep in atomic issue by not using a trigger when it makes no sense.
* stm32-timer
- Make sure master mode is disabled when stopping.
* vcnl400
- Update some sampling periods based on new docs.
* tag 'iio-fixes-for-5.6a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio:
iio: ping: set pa_laser_ping_cfg in of_ping_match
iio: chemical: sps30: fix missing triggered buffer dependency
iio: st_sensors: remap SMO8840 to LIS2DH12
iio: light: vcnl4000: update sampling periods for vcnl4040
iio: light: vcnl4000: update sampling periods for vcnl4200
iio: accel: adxl372: Set iio_chan BE
iio: magnetometer: ak8974: Fix negative raw values in sysfs
iio: trigger: stm32-timer: disable master mode when stopping
iio: adc: stm32-dfsdm: fix sleep in atomic context
iio: adc: at91-sama5d2_adc: fix differential channels in triggered mode