[PATCH 1/2] treewide: add "WITH Linux-syscall-note" to SPDX tag of uapi headers
UAPI headers licensed under GPL are supposed to have exception
"WITH Linux-syscall-note" so that they can be included into non-GPL
user space application code.
The exception note is missing in some UAPI headers.
Some of them slipped in by the treewide conversion commit b24413180f56
("License cleanup: add SPDX GPL-2.0 license identifier to files with
no license"). Just run:
$ git show --oneline b24413180f56 -- arch/x86/include/uapi/asm/
I believe they are not intentional, and should be fixed too.
This patch was generated by the following script:
git grep -l --not -e Linux-syscall-note --and -e SPDX-License-Identifier \
-- :arch/*/include/uapi/asm/*.h :include/uapi/ :^*/Kbuild |
while read file
do
sed -i -e 's/\(GPL-[^[:space:]]*\)/\1 WITH Linux-syscall-note/g' $file
done
After this patch is applied, there are 5 UAPI headers that do not contain
"WITH Linux-syscall-note". They are kept untouched since this exception
applies only to GPL variants.
$ git grep --not -e Linux-syscall-note --and -e SPDX-License-Identifier \
-- :arch/*/include/uapi/asm/*.h :include/uapi/ :^*/Kbuild
include/uapi/drm/panfrost_drm.h:/* SPDX-License-Identifier: MIT */
include/uapi/linux/batman_adv.h:/* SPDX-License-Identifier: MIT */
include/uapi/linux/qemu_fw_cfg.h:/* SPDX-License-Identifier: BSD-3-Clause */
include/uapi/linux/vbox_err.h:/* SPDX-License-Identifier: MIT */
include/uapi/linux/virtio_iommu.h:/* SPDX-License-Identifier: BSD-3-Clause */
Signed-off-by: Masahiro Yamada
---
arch/arm64/include/uapi/asm/bpf_perf_event.h | 2 +-
arch/csky/include/uapi/asm/byteorder.h | 2 +-
arch/csky/include/uapi/asm/cachectl.h | 2 +-
arch/csky/include/uapi/asm/perf_regs.h | 2 +-
arch/csky/include/uapi/asm/ptrace.h| 2 +-
arch/csky/include/uapi/asm/sigcontext.h| 2 +-
arch/csky/include/uapi/asm/unistd.h| 2 +-
arch/nds32/include/uapi/asm/auxvec.h | 2 +-
arch/nds32/include/uapi/asm/byteorder.h| 2 +-
arch/nds32/include/uapi/asm/cachectl.h | 2 +-
arch/nds32/include/uapi/asm/fp_udfiex_crtl.h | 2 +-
arch/nds32/include/uapi/asm/param.h| 2 +-
arch/nds32/include/uapi/asm/ptrace.h | 2 +-
arch/nds32/include/uapi/asm/sigcontext.h | 2 +-
arch/nds32/include/uapi/asm/unistd.h | 2 +-
arch/powerpc/include/uapi/asm/bpf_perf_event.h | 2 +-
arch/riscv/include/uapi/asm/auxvec.h | 2 +-
arch/riscv/include/uapi/asm/bitsperlong.h | 2 +-
arch/riscv/include/uapi/asm/byteorder.h| 2 +-
arch/riscv/include/uapi/asm/hwcap.h| 2 +-
arch/riscv/include/uapi/asm/ptrace.h | 2 +-
arch/riscv/include/uapi/asm/sigcontext.h | 2 +-
arch/riscv/include/uapi/asm/ucontext.h | 2 +-
arch/s390/include/uapi/asm/bpf_perf_event.h| 2 +-
arch/s390/include/uapi/asm/ipl.h | 2 +-
arch/sh/include/uapi/asm/setup.h | 2 +-
arch/sh/include/uapi/asm/types.h | 2 +-
arch/sparc/include/uapi/asm/oradax.h | 2 +-
arch/x86/include/uapi/asm/byteorder.h | 2 +-
arch/x86/include/uapi/asm/hwcap2.h | 2 +-
arch/x86/include/uapi/asm/sigcontext32.h | 2 +-
arch/x86/include/uapi/asm/types.h | 2 +-
include/uapi/linux/bpfilter.h | 2 +-
include/uapi/linux/ipmi_bmc.h | 2 +-
include/uapi/linux/isst_if.h | 2 +-
include/uapi/linux/netfilter/nf_synproxy.h | 2 +-
include/uapi/linux/psp-sev.h | 2 +-
include/uapi/linux/rxrpc.h | 2 +-
include/uapi/linux/usb/g_uvc.h | 2 +-
include/uapi/linux/vbox_vmmdev_types.h | 2 +-
include/uapi/linux/vboxguest.h | 2 +-
include/uapi/linux/virtio_pmem.h | 2 +-
include/uapi/linux/vmcore.h| 2 +-
include/uapi/linux/wmi.h | 2 +-
include/uapi/misc/fastrpc.h| 2 +-
include/uapi/rdma/rvt-abi.h| 2 +-
include/uapi/rdma/siw-abi.h| 2 +-
include/uapi/scsi/scsi_bsg_ufs.h | 2 +-
include/uapi/sound/skl-tplg-interface.h| 2 +-
49 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/arch/arm64/include/uapi/asm/bpf_perf_event.h
b/arch/arm64/include/uapi/asm/bpf_perf_event.h
index b551b741653d..5e1e648aeec4 100644
--- a/arch/arm64/include/uapi/asm/bpf_perf_event.h
+++ b/arch/arm64/include/uapi/asm/bpf_perf_event.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
#ifndef _UAPI__ASM_BPF_PERF_EVENT_H__
#define _UAPI__ASM_BPF_PERF_EVENT_H__
diff --git a/arch/csky/include/uapi/asm/byteorder.h
b/arch/csky/include/uapi/asm/byteorder.h
index b079ec715cdf..d150cd664873 100644
--- a/arch/csky/include/uapi/asm/byteorder.h
+++ b/arch/csky/include/uapi/asm/byteorder.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-
[PATCH 2/2] treewide: remove SPDX "WITH Linux-syscall-note" from kernel-space headers again
The "WITH Linux-syscall-note" exception exists for headers exported to
user space. It is strange to add it to non-exported headers.
Commit 687a3e4d8e61 ("treewide: remove SPDX "WITH Linux-syscall-note"
from kernel-space headers") did cleanups some months ago, but it looks
like we need to do this periodically.
This patch was generated by the following script:
git grep -l -e Linux-syscall-note \
-- :*.h :^arch/*/include/uapi/asm/*.h :^include/uapi/ :^tools |
while read file
do
sed -i -e 's/(\(GPL-[^[:space:]]*\) WITH Linux-syscall-note)/\1/g' \
-e 's/ WITH Linux-syscall-note//g' $file
done
I did not commit drivers/staging/android/uapi/ion.h
This is not currently exported, but somebody may plan to move it to
include/uapi/ when the time comes. I am not sure. Anyway, it will be
better to check the license inconsistency in drivers/staging/android/uapi/.
Signed-off-by: Masahiro Yamada
---
include/sound/sof/control.h | 2 +-
include/sound/sof/dai-intel.h | 2 +-
include/sound/sof/dai.h | 2 +-
include/sound/sof/header.h| 2 +-
include/sound/sof/info.h | 2 +-
include/sound/sof/pm.h| 2 +-
include/sound/sof/stream.h| 2 +-
include/sound/sof/topology.h | 2 +-
include/sound/sof/trace.h | 2 +-
include/sound/sof/xtensa.h| 2 +-
samples/vfio-mdev/mdpy-defs.h | 2 +-
11 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/sound/sof/control.h b/include/sound/sof/control.h
index bded69e696d4..6080ea0facd7 100644
--- a/include/sound/sof/control.h
+++ b/include/sound/sof/control.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR
BSD-3-Clause) */
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
/*
* This file is provided under a dual BSD/GPLv2 license. When using or
* redistributing this file, you may do so under either license.
diff --git a/include/sound/sof/dai-intel.h b/include/sound/sof/dai-intel.h
index 4bb8ee138ba7..65e4c20e567c 100644
--- a/include/sound/sof/dai-intel.h
+++ b/include/sound/sof/dai-intel.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR
BSD-3-Clause) */
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
/*
* This file is provided under a dual BSD/GPLv2 license. When using or
* redistributing this file, you may do so under either license.
diff --git a/include/sound/sof/dai.h b/include/sound/sof/dai.h
index 3d174e20aa53..5b8de1b1983c 100644
--- a/include/sound/sof/dai.h
+++ b/include/sound/sof/dai.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR
BSD-3-Clause) */
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
/*
* This file is provided under a dual BSD/GPLv2 license. When using or
* redistributing this file, you may do so under either license.
diff --git a/include/sound/sof/header.h b/include/sound/sof/header.h
index 12867bbd4372..10f00c08dbb7 100644
--- a/include/sound/sof/header.h
+++ b/include/sound/sof/header.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR
BSD-3-Clause) */
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
/*
* This file is provided under a dual BSD/GPLv2 license. When using or
* redistributing this file, you may do so under either license.
diff --git a/include/sound/sof/info.h b/include/sound/sof/info.h
index 16528d2b4a50..a9156b4a062c 100644
--- a/include/sound/sof/info.h
+++ b/include/sound/sof/info.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR
BSD-3-Clause) */
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
/*
* This file is provided under a dual BSD/GPLv2 license. When using or
* redistributing this file, you may do so under either license.
diff --git a/include/sound/sof/pm.h b/include/sound/sof/pm.h
index 8ae3ad45bdf7..003879401d63 100644
--- a/include/sound/sof/pm.h
+++ b/include/sound/sof/pm.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR
BSD-3-Clause) */
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
/*
* This file is provided under a dual BSD/GPLv2 license. When using or
* redistributing this file, you may do so under either license.
diff --git a/include/sound/sof/stream.h b/include/sound/sof/stream.h
index 643f175cb479..0b71b381b952 100644
--- a/include/sound/sof/stream.h
+++ b/include/sound/sof/stream.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR
BSD-3-Clause) */
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
/*
* This file is provided under a dual BSD/GPLv2 license. When using or
* redistributing this file, you may do so under either license.
diff --git a/include/sound/sof/topology.h b/include/sound/sof/topology.h
index 41dcabf89899..c47b36240920 100644
--- a/include/sound/sof/topology.h
+++ b/include/sound/sof/topology.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR
BSD-3-C
Re: [PATCH v12 1/5] can: m_can: Create a m_can platform framework
On Wed, Jul 24, 2019 at 10:36:02AM -0500, Dan Murphy wrote: > Hello > > On 7/24/19 1:47 AM, Greg KH wrote: > > On Tue, Jul 23, 2019 at 10:14:14AM -0500, Dan Murphy wrote: > > > Hello > > > > > > On 7/10/19 7:08 AM, Dan Murphy wrote: > > > > Hello > > > > > > > > On 6/17/19 10:09 AM, Dan Murphy wrote: > > > > > Marc > > > > > > > > > > On 6/10/19 11:35 AM, Dan Murphy wrote: > > > > > > Bump > > > > > > > > > > > > On 6/6/19 8:16 AM, Dan Murphy wrote: > > > > > > > Marc > > > > > > > > > > > > > > Bump > > > > > > > > > > > > > > On 5/31/19 6:51 AM, Dan Murphy wrote: > > > > > > > > Marc > > > > > > > > > > > > > > > > On 5/15/19 3:54 PM, Dan Murphy wrote: > > > > > > > > > Marc > > > > > > > > > > > > > > > > > > On 5/9/19 11:11 AM, Dan Murphy wrote: > > > > > > > > > > Create a m_can platform framework that peripheral > > > > > > > > > > devices can register to and use common code and register > > > > > > > > > > sets. > > > > > > > > > > The peripheral devices may provide read/write and > > > > > > > > > > configuration > > > > > > > > > > support of the IP. > > > > > > > > > > > > > > > > > > > > Acked-by: Wolfgang Grandegger > > > > > > > > > > Signed-off-by: Dan Murphy > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > v12 - Update the m_can_read/write functions to > > > > > > > > > > create a backtrace if the callback > > > > > > > > > > pointer is NULL. - > > > > > > > > > > https://lore.kernel.org/patchwork/patch/1052302/ > > > > > > > > > > > > > > > > > > > Is this able to be merged now? > > > > > > > > ping > > > > > Wondering if there is anything else we need to do? > > > > > > > > > > The part has officially shipped and we had hoped to have driver > > > > > support in Linux as part of the announcement. > > > > > > > > > Is this being sent in a PR for 5.3? > > > > > > > > Dan > > > > > > > Adding Greg to this thread as I have no idea what is going on with this. > > Why me? What am I supposed to do here? I see no patches at all to do > > anything with :( > > I am not sure who to email. The maintainer seems to be on hiatus or super > busy with other work. Who is the maintainer? > So I added you to see if you know how to handle this. Wolfgang Acked it but > he said Marc needs to pull Then work with them, again, what can I do if I can't even see the patches here? > it in. We have quite a few users of this patchset. I have been hosting the > patchset in a different tree. > > These users keep pinging us for upstream status and all we can do is point > them to the > > LKML to show we are continuing to pursue inclusion. > > https://lore.kernel.org/patchwork/project/lkml/list/?series=393454 Looks sane, work with the proper developers, good luck! greg k-h
Re: [HELP REQUESTED from the community] Was: Staging status of speakup
On Thu, Jul 25, 2019 at 08:11:04AM +0200, Willem van der Walt wrote: > Hi, > I have added a few things inline in Greg's message, mainly regarding the > bleeps and cursor_time. This is a great start, can someone turn this into the correct format that we need for Documentation/ABI/ ? thanks, greg k-h
Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved
On Wed, Jul 24, 2019 at 10:20:34PM +0200, Thomas Gleixner wrote: > On Wed, 24 Jul 2019, Thomas Gleixner wrote: > > > On Wed, 24 Jul 2019, Greg KH wrote: > > > On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote: > > > > > Gotta love old tool-chains :( > > > > > > > > Oh yes. /me does archaeology to find a VM with old stuff > > > > > > I can provide a binary if you can't find anything. > > > > Found GNU ld (GNU Binutils for Debian) 2.25 and after fiddling with > > LD_PRELOAD it builds without failure. > > > > ld.gold from that binutils version dies with a segfault on various files ... > > Then tried that old ld.bfd with GCC8 and that causes ld.bfd to segfault on > every other file. > > Copied that config to the clang build directory and it causes the same > explosions with ld.bfd. > > What a time waste... > > > Ugh, sorry about this. I can't seem to track it down either, and at this point am just going to punt and let the Android build people try to figure it out as it is their custom build system that is failing at the moment, only for x86, and if this single patch is reverted, it starts working again. voodo... thanks, greg k-h
Re: [PATCH 5.2 038/413] signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig
On Wed, Jul 24, 2019 at 03:49:32PM -0500, Steve French wrote: > Note that this patch causes a regression (removing cifs module fails, > due to unmount leaking a thread with this change). > > We are testing a workaround to cifs.ko which would be needed if this > patch were to be backported. I've now dropped this from all of the stable queues. If you all figure this out, please let us know and we will be glad to queue this up, along with the fix. thanks, greg k-h
Re: [PATCH net] net: hns: fix LED configuration for marvell phy
On 2019/7/25 12:28, Andrew Lunn wrote: > On Thu, Jul 25, 2019 at 11:00:08AM +0800, liuyonglong wrote: >>> Revert "net: hns: fix LED configuration for marvell phy" >>> This reverts commit f4e5f775db5a4631300dccd0de5eafb50a77c131. >>> >>> Andrew Lunn says this should be handled another way. >>> >>> Signed-off-by: David S. Miller >> >> >> Hi Andrew: >> >> I see this patch have been reverted, can you tell me the better way to do >> this? >> Thanks very much! > > Please take a look at the work Matthias Kaehlcke is doing. It has not > got too far yet, but when it is complete, it should define a generic > way to configure PHY LEDs. > > Andrew > Hi Andrew https://lore.kernel.org/patchwork/patch/1097185/ You are discussing about the DT configuration, is Matthias Kaehlcke's work also provide a generic way to configure PHY LEDS using ACPI?
[RFC] mm/debug: Add tests for architecture exported page table helpers
This series adds a test validation for architecture exported page table helpers. Patch in the series add basic transformation tests at various level of the page table. This test was originally suggested by Catalin during arm64 THP migration RFC discussion earlier. Going forward it can include more specific tests with respect to various generic MM functions like THP, HugeTLB etc and platform specific tests. https://lore.kernel.org/linux-mm/20190628102003.ga56...@arrakis.emea.arm.com/ Issues: Does not build on arm64 as a module and fails with following errors. This is primarily caused by set_pgd() called from pgd_clear() and pgd_populate(). ERROR: "set_swapper_pgd" [lib/test_arch_pgtable.ko] undefined! ERROR: "swapper_pg_dir" [lib/test_arch_pgtable.ko] undefined! These symbols need to be visible for driver usage or will have to disable loadable module option for this test on arm64 platform. Testing: Build and boot tested on arm64 and x86 platforms. While arm64 clears all these tests, following errors were reported on x86. 1. WARN_ON(pud_bad(pud)) in pud_populate_tests() 2. WARN_ON(p4d_bad(p4d)) in p4d_populate_tests() I would really appreciate if folks can help validate this test in other platforms and report back problems if any. Suggestions, comments and inputs welcome. Thank you. Cc: Andrew Morton Cc: Michal Hocko Cc: Catalin Marinas Cc: Mark Rutland Cc: Mark Brown Cc: Steven Price Cc: Ard Biesheuvel Cc: Masahiro Yamada Cc: Kees Cook Cc: Tetsuo Handa Cc: Matthew Wilcox Cc: Sri Krishna chowdary Cc: Dave Hansen Cc: linux-arm-ker...@lists.infradead.org Cc: x...@kernel.org Cc: linux-kernel@vger.kernel.org Anshuman Khandual (1): mm/pgtable/debug: Add test validating architecture page table helpers lib/Kconfig.debug | 14 +++ lib/Makefile| 1 + lib/test_arch_pgtable.c | 290 3 files changed, 305 insertions(+) create mode 100644 lib/test_arch_pgtable.c -- 2.7.4
[RFC] mm/pgtable/debug: Add test validating architecture page table helpers
This adds a test module which will validate architecture page table helpers
and accessors regarding compliance with generic MM semantics expectations.
This will help various architectures in validating changes to the existing
page table helpers or addition of new ones.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Mark Rutland
Cc: Mark Brown
Cc: Steven Price
Cc: Ard Biesheuvel
Cc: Masahiro Yamada
Cc: Kees Cook
Cc: Tetsuo Handa
Cc: Matthew Wilcox
Cc: Sri Krishna chowdary
Cc: Dave Hansen
Cc: linux-arm-ker...@lists.infradead.org
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
lib/Kconfig.debug | 14 +++
lib/Makefile| 1 +
lib/test_arch_pgtable.c | 290
3 files changed, 305 insertions(+)
create mode 100644 lib/test_arch_pgtable.c
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 5960e29..a27fe8d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1719,6 +1719,20 @@ config TEST_SORT
If unsure, say N.
+config TEST_ARCH_PGTABLE
+ tristate "Test arch page table helpers for semantics compliance"
+ depends on MMU
+ depends on DEBUG_KERNEL || m
+ help
+ This options provides a kernel module which can be used to test
+ architecture page table helper functions on various platform in
+ verifing if they comply with expected generic MM semantics. This
+ will help architectures code in making sure that any changes or
+ new additions of these helpers will still conform to generic MM
+ expeted semantics.
+
+ If unsure, say N.
+
config KPROBES_SANITY_TEST
bool "Kprobes sanity tests"
depends on DEBUG_KERNEL
diff --git a/lib/Makefile b/lib/Makefile
index 095601c..0806d61 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_TEST_VMALLOC) += test_vmalloc.o
obj-$(CONFIG_TEST_OVERFLOW) += test_overflow.o
obj-$(CONFIG_TEST_RHASHTABLE) += test_rhashtable.o
obj-$(CONFIG_TEST_SORT) += test_sort.o
+obj-$(CONFIG_TEST_ARCH_PGTABLE) += test_arch_pgtable.o
obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o
obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o
obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
diff --git a/lib/test_arch_pgtable.c b/lib/test_arch_pgtable.c
new file mode 100644
index 000..1396664
--- /dev/null
+++ b/lib/test_arch_pgtable.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * This kernel module validates architecture page table helpers &
+ * accessors and helps in verifying their continued compliance with
+ * generic MM semantics.
+ *
+ * Copyright (C) 2019 ARM Ltd.
+ *
+ * Author: Anshuman Khandual
+ */
+#define pr_fmt(fmt) "test_arch_pgtable: %s " fmt, __func__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Basic operations
+ *
+ * mkold(entry)= An old and not an young entry
+ * mkyoung(entry) = An young and not an old entry
+ * mkdirty(entry) = A dirty and not a clean entry
+ * mkclean(entry) = A clean and not a dirty entry
+ * mkwrite(entry) = An write and not an write protected entry
+ * wrprotect(entry)= An write protected and not an write entry
+ * pxx_bad(entry) = A mapped and non-table entry
+ * pxx_same(entry1, entry2)= Both entries hold the exact same value
+ */
+#define VMA_TEST_FLAGS (VM_READ|VM_WRITE|VM_EXEC)
+
+static struct vm_area_struct vma;
+static struct mm_struct mm;
+static struct page *page;
+static pgprot_t prot;
+static unsigned long pfn, addr;
+
+static void pte_basic_tests(void)
+{
+ pte_t pte;
+
+ pte = mk_pte(page, prot);
+ WARN_ON(!pte_same(pte, pte));
+ WARN_ON(!pte_young(pte_mkyoung(pte)));
+ WARN_ON(!pte_dirty(pte_mkdirty(pte)));
+ WARN_ON(!pte_write(pte_mkwrite(pte)));
+ WARN_ON(pte_young(pte_mkold(pte)));
+ WARN_ON(pte_dirty(pte_mkclean(pte)));
+ WARN_ON(pte_write(pte_wrprotect(pte)));
+}
+
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE
+static void pmd_basic_tests(void)
+{
+ pmd_t pmd;
+
+ pmd = mk_pmd(page, prot);
+ WARN_ON(!pmd_same(pmd, pmd));
+ WARN_ON(!pmd_young(pmd_mkyoung(pmd)));
+ WARN_ON(!pmd_dirty(pmd_mkdirty(pmd)));
+ WARN_ON(!pmd_write(pmd_mkwrite(pmd)));
+ WARN_ON(pmd_young(pmd_mkold(pmd)));
+ WARN_ON(pmd_dirty(pmd_mkclean(pmd)));
+ WARN_ON(pmd_write(pmd_wrprotect(pmd)));
+ /*
+* A huge page does not point to next level page table
+* entry. Hence this must qualify as pmd_bad().
+*/
+ WARN_ON(!pmd_bad(pmd_mkhuge(pmd)));
+}
+#else
+static void pmd_basic_tests(void) { }
+#endif
+
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+static void pud_basic_tests(void)
+{
+ pud_t pud;
+
+
[PATCH] extcon: max77843: Add IRQ_ONESHOT mask
Do not fire irq again until thread done
This issue was found by code inspection
Coccicheck irqf_oneshot.cocci
Signed-off-by: Vasyl Gomonovych
---
drivers/extcon/extcon-max77843.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-max77843.c b/drivers/extcon/extcon-max77843.c
index a343a6ef3506..42b14c333b1c 100644
--- a/drivers/extcon/extcon-max77843.c
+++ b/drivers/extcon/extcon-max77843.c
@@ -905,7 +905,8 @@ static int max77843_muic_probe(struct platform_device *pdev)
muic_irq->virq = virq;
ret = devm_request_threaded_irq(&pdev->dev, virq, NULL,
- max77843_muic_irq_handler, IRQF_NO_SUSPEND,
+ max77843_muic_irq_handler,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
muic_irq->name, info);
if (ret) {
dev_err(&pdev->dev,
--
2.17.1
[PATCH 1/1] dt-bindings: power/supply/sbs_sbs-battery: Addition of force_load binding Add device tree binding documentation for addition of force_load boolean value to allow loading a battery during b
Signed-off-by: Richard Tresidder
---
Notes:
Add device tree binding documentation for addition of force_load
boolean value to allow loading a battery during boot even if not
present at that time.
Accompanying patch to drivers/power/supply/sbs-battery.c submitted to
linux...@vger.kernel.org
Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
index 4e78e51..187d7bb 100644
--- a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
@@ -15,7 +15,8 @@ Optional properties :
after an external change notification.
- sbs,battery-detect-gpios : The gpio which signals battery detection and
a flag specifying its polarity.
-
+ - sbs,force-load : Allow loading of a hot-pluggable battery when there is no
+ GPIO detect available and the module is statically built.
Example:
battery@b {
@@ -24,4 +25,5 @@ Example:
sbs,i2c-retry-count = <2>;
sbs,poll-retry-count = <10>;
sbs,battery-detect-gpios = <&gpio-controller 122 1>;
+ sbs,force-load;
}
--
1.8.3.1
Re: [PATCH 1/1] x86/boot: clear some fields explicitly
On 7/24/19 7:12 PM, h...@zytor.com wrote: On July 24, 2019 4:15:28 PM PDT, john.hubb...@gmail.com wrote: From: John Hubbard ... + boot_params->ext_ramdisk_image = 0; + boot_params->ext_ramdisk_size = 0; + boot_params->ext_cmd_line_ptr = 0; + + memset(&boot_params->_pad4, 0, sizeof(boot_params->_pad4)); memset(&boot_params->_pad7[0], 0, (char *)&boot_params->edd_mbr_sig_buffer[0] - (char *)&boot_params->_pad7[0]); The problem with this is that it will break silently when changes are made to this structure. So, that is a NAK from me. Understood. It occurs to me, though, that it would be trivial to just add build time assertions to check a few struct member offset values, and fail out if they changed. That would give us everything: warnings-free builds, and no silent failures. Thoughts? thanks, -- John Hubbard NVIDIA
Re: [PATCH 11/12] staging: media: cedrus: Fix misuse of GENMASK macro
On 7/24/19 7:09 PM, Joe Perches wrote: > On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote: >> Arguments are supposed to be ordered high then low. >> >> Signed-off-by: Joe Perches >> --- >> drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h >> b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h >> index 3e9931416e45..ddd29788d685 100644 >> --- a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h >> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h >> @@ -110,7 +110,7 @@ >> #define VE_DEC_MPEG_MBADDR (VE_ENGINE_DEC_MPEG + 0x10) >> >> #define VE_DEC_MPEG_MBADDR_X(w) (((w) << 8) & >> GENMASK(15, 8)) >> -#define VE_DEC_MPEG_MBADDR_Y(h) (((h) << 0) & >> GENMASK(0, 7)) >> +#define VE_DEC_MPEG_MBADDR_Y(h) (((h) << 0) & >> GENMASK(7, 0)) >> >> #define VE_DEC_MPEG_CTRL(VE_ENGINE_DEC_MPEG + 0x14) > > Greg? ping? > > It's actually me and I'm about to pick this one up and make a PR for Mauro. Regards, Hans
Re: [PATCH 1/2] /proc/kpageflags: prevent an integer overflow in stable_page_flags()
On Thu, Jul 25, 2019 at 02:31:16AM +, Toshiki Fukasawa wrote: > stable_page_flags() returns kpageflags info in u64, but it uses > "1 << KPF_*" internally which is considered as int. This type mismatch > causes no visible problem now, but it will if you set bit 32 or more as > done in a subsequent patch. So use BIT_ULL in order to avoid future > overflow issues. > - return 1 << KPF_NOPAGE; > + return BIT_ULL(KPF_NOPAGE); This won't happen until bit 31 is used and all the flags are within int currently and stable(!), so the problem doesn't exist for them. Overflow implies some page flags are 64-bit only, which hopefully won't happen.
[PATCH] extcon: max8997: Use irq mask IRQF_ONESHOT
Do not fire irq again until thread done
This issue was found by code inspection
Coccicheck irqf_oneshot.cocci
Signed-off-by: Vasyl Gomonovych
---
drivers/extcon/extcon-max8997.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index 172e116ac1ce..c347365242d2 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -660,7 +660,7 @@ static int max8997_muic_probe(struct platform_device *pdev)
ret = request_threaded_irq(virq, NULL,
max8997_muic_irq_handler,
- IRQF_NO_SUSPEND,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
muic_irq->name, info);
if (ret) {
dev_err(&pdev->dev,
--
2.17.1
[PATCH] extcon: max14577: Add irq mask IRQ_ONESHOT
Do not fire irq again until thread done
This issue was found by code inspection
Coccicheck irqf_oneshot.cocci
Signed-off-by: Vasyl Gomonovych
---
drivers/extcon/extcon-max14577.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 32f663436e6e..97c021512ffc 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -698,7 +698,7 @@ static int max14577_muic_probe(struct platform_device *pdev)
ret = devm_request_threaded_irq(&pdev->dev, virq, NULL,
max14577_muic_irq_handler,
- IRQF_NO_SUSPEND,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
muic_irq->name, info);
if (ret) {
dev_err(&pdev->dev,
--
2.17.1
[tip:core/urgent] objtool: Improve UACCESS coverage
Commit-ID: 882a0db9d143e5e8dac54b96e83135bccd1f68d1
Gitweb: https://git.kernel.org/tip/882a0db9d143e5e8dac54b96e83135bccd1f68d1
Author: Peter Zijlstra
AuthorDate: Wed, 24 Jul 2019 17:47:26 -0500
Committer: Thomas Gleixner
CommitDate: Thu, 25 Jul 2019 08:36:39 +0200
objtool: Improve UACCESS coverage
A clang build reported an (obvious) double CLAC while a GCC build did not;
it turns out that objtool only re-visits instructions if the first visit
was with AC=0. If OTOH the first visit was with AC=1, it completely ignores
any subsequent visit, even when it has AC=0.
Fix this by using a visited mask instead of a boolean, and (explicitly)
mark the AC state.
$ ./objtool check -b --no-fp --retpoline --uaccess
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
.altinstr_replacement+0x22: redundant UACCESS disable
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
eb_copy_relocations.isra.34()+0xea: (alt)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
.altinstr_replacement+0x: (branch)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
eb_copy_relocations.isra.34()+0xd9: (alt)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
eb_copy_relocations.isra.34()+0xb2: (branch)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
eb_copy_relocations.isra.34()+0x39: (branch)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
eb_copy_relocations.isra.34()+0x0: <=== (func)
Reported-by: Josh Poimboeuf
Reported-by: Thomas Gleixner
Reported-by: Sedat Dilek
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Josh Poimboeuf
Signed-off-by: Thomas Gleixner
Tested-by: Nathan Chancellor
Tested-by: Nick Desaulniers
Tested-by: Sedat Dilek
Link: https://github.com/ClangBuiltLinux/linux/issues/617
Link:
https://lkml.kernel.org/r/5359166aad2d53f3145cd442d83d0e5115e0cd17.1564007838.git.jpoim...@redhat.com
---
tools/objtool/check.c | 7 ---
tools/objtool/check.h | 3 ++-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 5f26620f13f5..176f2f084060 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1946,6 +1946,7 @@ static int validate_branch(struct objtool_file *file,
struct symbol *func,
struct alternative *alt;
struct instruction *insn, *next_insn;
struct section *sec;
+ u8 visited;
int ret;
insn = first;
@@ -1972,12 +1973,12 @@ static int validate_branch(struct objtool_file *file,
struct symbol *func,
return 1;
}
+ visited = 1 << state.uaccess;
if (insn->visited) {
if (!insn->hint && !insn_state_match(insn, &state))
return 1;
- /* If we were here with AC=0, but now have AC=1, go
again */
- if (insn->state.uaccess || !state.uaccess)
+ if (insn->visited & visited)
return 0;
}
@@ -2024,7 +2025,7 @@ static int validate_branch(struct objtool_file *file,
struct symbol *func,
} else
insn->state = state;
- insn->visited = true;
+ insn->visited |= visited;
if (!insn->ignore_alts) {
bool skip_orig = false;
diff --git a/tools/objtool/check.h b/tools/objtool/check.h
index b881fafcf55d..6d875ca6fce0 100644
--- a/tools/objtool/check.h
+++ b/tools/objtool/check.h
@@ -33,8 +33,9 @@ struct instruction {
unsigned int len;
enum insn_type type;
unsigned long immediate;
- bool alt_group, visited, dead_end, ignore, hint, save, restore,
ignore_alts;
+ bool alt_group, dead_end, ignore, hint, save, restore, ignore_alts;
bool retpoline_safe;
+ u8 visited;
struct symbol *call_dest;
struct instruction *jump_dest;
struct instruction *first_jump_src;
[PATCH] extcon: max77693: Add extra IRQF_ONESHOT
Do not fire irq again until thread done
This issue was found by code inspection
Coccicheck irqf_oneshot.cocci
Signed-off-by: Vasyl Gomonovych
---
drivers/extcon/extcon-max77693.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 32fc5a66ffa9..68e42cd87e98 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1142,7 +1142,7 @@ static int max77693_muic_probe(struct platform_device
*pdev)
ret = devm_request_threaded_irq(&pdev->dev, virq, NULL,
max77693_muic_irq_handler,
- IRQF_NO_SUSPEND,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT,
muic_irq->name, info);
if (ret) {
dev_err(&pdev->dev,
--
2.17.1
[PATCH] iio: adc: sc27xx: Change to polling mode to read data
From: Freeman Liu
On Spreadtrum platform, the headphone will read one ADC channel multiple
times to identify the headphone type, and the headphone identification is
sensitive of the ADC reading time. And we found it will take longer time
to reading ADC data by using interrupt mode comparing with the polling
mode, thus we should change to polling mode to improve the efficiency
of reading data, which can identify the headphone type successfully.
Signed-off-by: Freeman Liu
Signed-off-by: Baolin Wang
---
drivers/iio/adc/sc27xx_adc.c | 81 ++
1 file changed, 27 insertions(+), 54 deletions(-)
diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
index f7f7a189..ea864290 100644
--- a/drivers/iio/adc/sc27xx_adc.c
+++ b/drivers/iio/adc/sc27xx_adc.c
@@ -3,7 +3,6 @@
#include
#include
-#include
#include
#include
#include
@@ -46,14 +45,18 @@
/* Bits definitions for SC27XX_ADC_INT_CLR registers */
#define SC27XX_ADC_IRQ_CLR BIT(0)
+/* Bits definitions for SC27XX_ADC_INT_RAW registers */
+#define SC27XX_ADC_IRQ_RAW BIT(0)
+
/* Mask definition for SC27XX_ADC_DATA register */
#define SC27XX_ADC_DATA_MASK GENMASK(11, 0)
/* Timeout (ms) for the trylock of hardware spinlocks */
#define SC27XX_ADC_HWLOCK_TIMEOUT 5000
-/* Timeout (ms) for ADC data conversion according to ADC datasheet */
-#define SC27XX_ADC_RDY_TIMEOUT 100
+/* Timeout (us) for ADC data conversion according to ADC datasheet */
+#define SC27XX_ADC_RDY_TIMEOUT 100
+#define SC27XX_ADC_POLL_RAW_STATUS 500
/* Maximum ADC channel number */
#define SC27XX_ADC_CHANNEL_MAX 32
@@ -72,10 +75,8 @@ struct sc27xx_adc_data {
* subsystems which will access the unique ADC controller.
*/
struct hwspinlock *hwlock;
- struct completion completion;
int channel_scale[SC27XX_ADC_CHANNEL_MAX];
u32 base;
- int value;
int irq;
};
@@ -188,9 +189,7 @@ static int sc27xx_adc_read(struct sc27xx_adc_data *data,
int channel,
int scale, int *val)
{
int ret;
- u32 tmp;
-
- reinit_completion(&data->completion);
+ u32 tmp, value, status;
ret = hwspin_lock_timeout_raw(data->hwlock, SC27XX_ADC_HWLOCK_TIMEOUT);
if (ret) {
@@ -203,6 +202,11 @@ static int sc27xx_adc_read(struct sc27xx_adc_data *data,
int channel,
if (ret)
goto unlock_adc;
+ ret = regmap_update_bits(data->regmap, data->base + SC27XX_ADC_INT_CLR,
+SC27XX_ADC_IRQ_CLR, SC27XX_ADC_IRQ_CLR);
+ if (ret)
+ goto disable_adc;
+
/* Configure the channel id and scale */
tmp = (scale << SC27XX_ADC_SCALE_SHIFT) & SC27XX_ADC_SCALE_MASK;
tmp |= channel & SC27XX_ADC_CHN_ID_MASK;
@@ -226,15 +230,22 @@ static int sc27xx_adc_read(struct sc27xx_adc_data *data,
int channel,
if (ret)
goto disable_adc;
- ret = wait_for_completion_timeout(&data->completion,
- msecs_to_jiffies(SC27XX_ADC_RDY_TIMEOUT));
- if (!ret) {
- dev_err(data->dev, "read ADC data timeout\n");
- ret = -ETIMEDOUT;
- } else {
- ret = 0;
+ ret = regmap_read_poll_timeout(data->regmap,
+ data->base + SC27XX_ADC_INT_RAW,
+ status, (status & SC27XX_ADC_IRQ_RAW),
+ SC27XX_ADC_POLL_RAW_STATUS,
+ SC27XX_ADC_RDY_TIMEOUT);
+ if (ret) {
+ dev_err(data->dev, "read adc timeout, status = 0x%x\n", status);
+ goto disable_adc;
}
+ ret = regmap_read(data->regmap, data->base + SC27XX_ADC_DATA, &value);
+ if (ret)
+ goto disable_adc;
+
+ value &= SC27XX_ADC_DATA_MASK;
+
disable_adc:
regmap_update_bits(data->regmap, data->base + SC27XX_ADC_CTL,
SC27XX_ADC_EN, 0);
@@ -242,32 +253,11 @@ static int sc27xx_adc_read(struct sc27xx_adc_data *data,
int channel,
hwspin_unlock_raw(data->hwlock);
if (!ret)
- *val = data->value;
+ *val = value;
return ret;
}
-static irqreturn_t sc27xx_adc_isr(int irq, void *dev_id)
-{
- struct sc27xx_adc_data *data = dev_id;
- int ret;
-
- ret = regmap_update_bits(data->regmap, data->base + SC27XX_ADC_INT_CLR,
-SC27XX_ADC_IRQ_CLR, SC27XX_ADC_IRQ_CLR);
- if (ret)
- return IRQ_RETVAL(ret);
-
- ret = regmap_read(data->regmap, data->base + SC27XX_ADC_DATA,
- &data->value);
- if (ret)
- return IRQ_RETVAL(ret);
-
- data->value &= SC27XX_ADC_DATA_MASK;
- complete(&data->completion);
-
- return IRQ_HANDLED;
-}
-
static vo
Re: [BUG] Linux 5.3-rc1: timer problem on x86-64 (Pentium D)
Rui,
On Thu, 25 Jul 2019, Rui Salvaterra wrote:
> Looks like we have a winner. Actually, I did a full bisection between
> 5.2 and 5.3-rc1. Full log follows:
>
> git bisect start
> # good: [0ecfebd2b52404ae0c54a878c872bb93363ada36] Linux 5.2
> git bisect good 0ecfebd2b52404ae0c54a878c872bb93363ada36
>
> # first bad commit: [3222daf970f30133cc4c639cbecdc29c4ae91b2b]
> x86/hpet: Separate counter check out of clocksource register code
>
> I haven't tried reverting this commit and recompiling (it's already
'Revert' on top of Linus tree below.
> past 1:00 here, need to sleep), but I'll try it tomorrow, if required.
> Note that on this machine (i945G) the HPET is disabled at boot and is
> forcefully enabled by the kernel…
> [0.147527] pci :00:1f.0: Force enabled HPET at 0xfed0
Ok.
> … and the commit message reads…
>
> "The init code checks whether the HPET counter works late in the init
> function when the clocksource is registered. That should happen right
> with the other sanity checks."
>
> … maybe now the check is happening a bit too early…?
The only reason I can think of is that the HPET on that machine has a weird
register state (it's not advertised by the BIOS ... )
But that does not explain the boot failure completely. If the HPET is not
available then the kernel should automatically do the right thing and fall
back to something else.
Can you please provide the output of:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
and
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
from a successful boot with 5.2 and 5.3 head with the 'fix' applied?
Then boot these kernels with 'hpet=disable' on the command line and see
whether they come up. If so please provide the same output.
The dmesg output of each boot would be useful as well.
Thanks,
tglx
8<
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -827,10 +827,6 @@ int __init hpet_enable(void)
if (!hpet_cfg_working())
goto out_nohpet;
- /* Validate that the counter is counting */
- if (!hpet_counting())
- goto out_nohpet;
-
/*
* Read the period and check for a sane value:
*/
@@ -896,6 +892,14 @@ int __init hpet_enable(void)
}
hpet_print_config();
+ /*
+* Validate that the counter is counting. This needs to be done
+* after sanitizing the config registers to properly deal with
+* force enabled HPETs.
+*/
+ if (!hpet_counting())
+ goto out_nohpet;
+
clocksource_register_hz(&clocksource_hpet, (u32)hpet_freq);
if (id & HPET_ID_LEGSUP) {
[PATCH] kprobes: Allow kprobes coexist with livepatch
Allow kprobes which do not modify regs->ip, coexist with livepatch
by dropping FTRACE_OPS_FL_IPMODIFY from ftrace_ops.
User who wants to modify regs->ip (e.g. function fault injection)
must set a dummy post_handler to its kprobes when registering.
However, if such regs->ip modifying kprobes is set on a function,
that function can not be livepatched.
Signed-off-by: Masami Hiramatsu
---
kernel/kprobes.c | 56 +++---
1 file changed, 40 insertions(+), 16 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 9873fc627d61..29065380dad0 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -961,9 +961,16 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
#ifdef CONFIG_KPROBES_ON_FTRACE
static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
+ .func = kprobe_ftrace_handler,
+ .flags = FTRACE_OPS_FL_SAVE_REGS,
+};
+
+static struct ftrace_ops kprobe_ipmodify_ops __read_mostly = {
.func = kprobe_ftrace_handler,
.flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
};
+
+static int kprobe_ipmodify_enabled;
static int kprobe_ftrace_enabled;
/* Must ensure p->addr is really on ftrace */
@@ -976,58 +983,75 @@ static int prepare_kprobe(struct kprobe *p)
}
/* Caller must lock kprobe_mutex */
-static int arm_kprobe_ftrace(struct kprobe *p)
+static int __arm_kprobe_ftrace(struct kprobe *p, struct ftrace_ops *ops,
+ int *cnt)
{
int ret = 0;
- ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
- (unsigned long)p->addr, 0, 0);
+ ret = ftrace_set_filter_ip(ops, (unsigned long)p->addr, 0, 0);
if (ret) {
pr_debug("Failed to arm kprobe-ftrace at %pS (%d)\n",
p->addr, ret);
return ret;
}
- if (kprobe_ftrace_enabled == 0) {
- ret = register_ftrace_function(&kprobe_ftrace_ops);
+ if (*cnt == 0) {
+ ret = register_ftrace_function(ops);
if (ret) {
pr_debug("Failed to init kprobe-ftrace (%d)\n", ret);
goto err_ftrace;
}
}
- kprobe_ftrace_enabled++;
+ (*cnt)++;
return ret;
err_ftrace:
/*
-* Note: Since kprobe_ftrace_ops has IPMODIFY set, and ftrace requires a
-* non-empty filter_hash for IPMODIFY ops, we're safe from an accidental
-* empty filter_hash which would undesirably trace all functions.
+* At this point, sinec ops is not registered, we should be sefe from
+* registering empty filter.
*/
- ftrace_set_filter_ip(&kprobe_ftrace_ops, (unsigned long)p->addr, 1, 0);
+ ftrace_set_filter_ip(ops, (unsigned long)p->addr, 1, 0);
return ret;
}
+static int arm_kprobe_ftrace(struct kprobe *p)
+{
+ bool ipmodify = (p->post_handler != NULL);
+
+ return __arm_kprobe_ftrace(p,
+ ipmodify ? &kprobe_ipmodify_ops : &kprobe_ftrace_ops,
+ ipmodify ? &kprobe_ipmodify_enabled : &kprobe_ftrace_enabled);
+}
+
/* Caller must lock kprobe_mutex */
-static int disarm_kprobe_ftrace(struct kprobe *p)
+static int __disarm_kprobe_ftrace(struct kprobe *p, struct ftrace_ops *ops,
+ int *cnt)
{
int ret = 0;
- if (kprobe_ftrace_enabled == 1) {
- ret = unregister_ftrace_function(&kprobe_ftrace_ops);
+ if (*cnt == 1) {
+ ret = unregister_ftrace_function(ops);
if (WARN(ret < 0, "Failed to unregister kprobe-ftrace (%d)\n",
ret))
return ret;
}
- kprobe_ftrace_enabled--;
+ (*cnt)--;
- ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
- (unsigned long)p->addr, 1, 0);
+ ret = ftrace_set_filter_ip(ops, (unsigned long)p->addr, 1, 0);
WARN_ONCE(ret < 0, "Failed to disarm kprobe-ftrace at %pS (%d)\n",
p->addr, ret);
return ret;
}
+
+static int disarm_kprobe_ftrace(struct kprobe *p)
+{
+ bool ipmodify = (p->post_handler != NULL);
+
+ return __disarm_kprobe_ftrace(p,
+ ipmodify ? &kprobe_ipmodify_ops : &kprobe_ftrace_ops,
+ ipmodify ? &kprobe_ipmodify_enabled : &kprobe_ftrace_enabled);
+}
#else /* !CONFIG_KPROBES_ON_FTRACE */
#define prepare_kprobe(p) arch_prepare_kprobe(p)
#define arm_kprobe_ftrace(p) (-ENODEV)
Re: [PATCH 2/2] DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again
Hi Rob, > Am 24.07.2019 um 21:42 schrieb Rob Herring : > > On Mon, Jul 08, 2019 at 04:46:05PM +0200, H. Nikolaus Schaller wrote: >> commit 6953c57ab172 "gpio: of: Handle SPI chipselect legacy bindings" >> >> did introduce logic to centrally handle the legacy spi-cs-high property >> in combination with cs-gpios. This assumes that the polarity >> of the CS has to be inverted if spi-cs-high is missing, even >> and especially if non-legacy GPIO_ACTIVE_HIGH is specified. >> >> The DTS for the GTA04 was orginally introduced under the assumption >> that there is no need for spi-cs-high if the gpio is defined with >> proper polarity GPIO_ACTIVE_HIGH. > > Given that spi-cs-high is called legacy, that would imply that DT's > should not have to use spi-cs-high. Yes. > >> This was not a problem until gpiolib changed the interpretation of >> GPIO_ACTIVE_HIGH and missing spi-cs-high. > > Then we should fix gpiolib... I tried to convince Linus that this is the right way but he convinced me that a fix that handles all cases does not exist. There seem to be embedded devices with older DTB (potentially in ROM) which provide a plain 0 value for a gpios definition. And either with or without spi-cs-high. Since "0" is the same as "GPIO_ACTIVE_HIGH", the absence of spi-cs-high was and must be interpreted as active low for these devices. This leads to the inversion logic in code. AFAIR it boils down to the question if gpiolib and the bindings should still support such legacy devices with out-of tree DTB, but force in-tree DTS to add the legacy spi-cs-high property. Or if we should fix the 2 or 3 cases of in-tree legacy cases and potentially break out-of tree DTBs. IMHO it is more general to keep the out-of-tree DTBs working and "fix" what we can control (in-tree DTS). > >> The effect is that the missing spi-cs-high is now interpreted as CS being >> low (despite GPIO_ACTIVE_HIGH) which turns off the SPI interface when the >> panel is to be programmed by the panel driver. >> >> Therefore, we have to add the redundant and legacy spi-cs-high property >> to properly pass through the legacy handler. >> >> Since this is nowhere documented in the bindings, we add some words of >> WARNING. >> >> Cc: sta...@vger.kernel.org >> Signed-off-by: H. Nikolaus Schaller >> --- >> Documentation/devicetree/bindings/spi/spi-bus.txt | 6 ++ >> arch/arm/boot/dts/omap3-gta04.dtsi| 1 + >> 2 files changed, 7 insertions(+) BR, Nikolaus
Re: [PATCH v6] driver core: Fix use-after-free and double free on glue directory
On 7/24/19 9:30 PM, Muchun Song wrote:
> There is a race condition between removing glue directory and adding a new
> device under the glue directory. It can be reproduced in following test:
>
> path 1: Add the child device under glue dir
> device_add()
> get_device_parent()
> mutex_lock(&gdp_mutex);
>
> /*find parent from glue_dirs.list*/
> list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
> if (k->parent == parent_kobj) {
> kobj = kobject_get(k);
> break;
> }
>
> mutex_unlock(&gdp_mutex);
>
>
> kobject_add()
> kobject_add_internal()
> create_dir()
> sysfs_create_dir_ns()
> if (kobj->parent)
> parent = kobj->parent->sd;
>
> kernfs_create_dir_ns(parent)
> kernfs_new_node()
> kernfs_get(parent)
>
> /* link in */
> rc = kernfs_add_one(kn);
> if (!rc)
> return kn;
>
> kernfs_put(kn)
>
> repeat:
> kmem_cache_free(kn)
> kn = parent;
>
> if (kn) {
> if (atomic_dec_and_test(&kn->count))
> goto repeat;
> }
>
>
> path2: Remove last child device under glue dir
> device_del()
> cleanup_glue_dir()
> mutex_lock(&gdp_mutex);
> if (!kobject_has_children(glue_dir))
> kobject_del(glue_dir);
> kobject_put(glue_dir);
> mutex_unlock(&gdp_mutex);
>
> Before path2 remove last child device under glue dir, If path1 add a new
> device under glue dir, the glue_dir kobject reference count will be
> increase to 2 via kobject_get(k) in get_device_parent(). And path1 has
> been called kernfs_new_node(), but not call kernfs_get(parent).
> Meanwhile, path2 call kobject_del(glue_dir) beacause 0 is returned by
> kobject_has_children(). This result in glue_dir->sd is freed and it's
> reference count will be 0. Then path1 call kernfs_get(parent) will trigger
> a warning in kernfs_get()(WARN_ON(!atomic_read(&kn->count))) and increase
> it's reference count to 1. Because glue_dir->sd is freed by path2, the next
> call kernfs_add_one() by path1 will fail(This is also use-after-free)
> and call atomic_dec_and_test() to decrease reference count. Because the
> reference count is decremented to 0, it will also call kmem_cache_free()
> to free glue_dir->sd again. This will result in double free.
>
> In order to avoid this happening, we also should make sure that kernfs_node
> for glue_dir is released in path2 only when refcount for glue_dir kobj is
> 1 to fix this race.
>
> The following calltrace is captured in kernel 4.14 with the following patch
> applied:
>
> commit 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")
>
> --
> [3.633703] WARNING: CPU: 4 PID: 513 at .../fs/kernfs/dir.c:494
> Here is WARN_ON(!atomic_read(&kn->count) in kernfs_get().
>
> [3.633986] Call trace:
> [3.633991] kernfs_create_dir_ns+0xa8/0xb0
> [3.633994] sysfs_create_dir_ns+0x54/0xe8
> [3.634001] kobject_add_internal+0x22c/0x3f0
> [3.634005] kobject_add+0xe4/0x118
> [3.634011] device_add+0x200/0x870
> [3.634017] _request_firmware+0x958/0xc38
> [3.634020] request_firmware_into_buf+0x4c/0x70
>
> [3.634064] kernel BUG at .../mm/slub.c:294!
> Here is BUG_ON(object == fp) in set_freepointer().
>
> [3.634346] Call trace:
> [3.634351] kmem_cache_free+0x504/0x6b8
> [3.634355] kernfs_put+0x14c/0x1d8
> [3.634359] kernfs_create_dir_ns+0x88/0xb0
> [3.634362] sysfs_create_dir_ns+0x54/0xe8
> [3.634366] kobject_add_internal+0x22c/0x3f0
> [3.634370] kobject_add+0xe4/0x118
> [3.634374] device_add+0x200/0x870
> [3.634378] _request_firmware+0x958/0xc38
> [3.634381] request_firmware_into_buf+0x4c/0x70
> --
>
> Fixes: 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")
>
> Signed-off-by: Muchun Song
> Reviewed-by: Mukesh Ojha
> ---
>
> Change in v6:
>1. Remove hardcoding "1 "
> Change in v5:
>1. Revert to the v1 fix.
>2. Add some comment to explain why we need do this in
> cleanup_glue_dir().
> Change in v4:
>1. Add some kerneldoc comment.
>2. Remove unlock_if_glue_dir().
>3. Rename get_device_parent_locked_if_glue_dir(
Re: [PATCH REBASE v4 11/14] mips: Adjust brk randomization offset to fit generic version
On 7/24/19 7:58 AM, Alexandre Ghiti wrote: This commit simply bumps up to 32MB and 1GB the random offset of brk, compared to 8MB and 256MB, for 32bit and 64bit respectively. Suggested-by: Kees Cook Signed-off-by: Alexandre Ghiti Reviewed-by: Kees Cook --- arch/mips/mm/mmap.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c index a7e84b2e71d7..faa5aa615389 100644 --- a/arch/mips/mm/mmap.c +++ b/arch/mips/mm/mmap.c @@ -16,6 +16,7 @@ #include #include #include +#include unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */ EXPORT_SYMBOL(shm_align_mask); @@ -189,11 +190,11 @@ static inline unsigned long brk_rnd(void) unsigned long rnd = get_random_long(); rnd = rnd << PAGE_SHIFT; - /* 8MB for 32bit, 256MB for 64bit */ + /* 32MB for 32bit, 1GB for 64bit */ if (TASK_IS_32BIT_ADDR) - rnd = rnd & 0x7ful; + rnd = rnd & SZ_32M; else - rnd = rnd & 0xffful; + rnd = rnd & SZ_1G; return rnd; } Hi Andrew, I have just noticed that this patch is wrong, do you want me to send another version of the entire series or is the following diff enough ? This mistake gets fixed anyway in patch 13/14 when it gets merged with the generic version. Sorry about that, Thanks, Alex diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c index a7e84b2e71d7..ff6ab87e9c56 100644 --- a/arch/mips/mm/mmap.c +++ b/arch/mips/mm/mmap.c @@ -16,6 +16,7 @@ #include #include #include +#include unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */ EXPORT_SYMBOL(shm_align_mask); @@ -189,11 +190,11 @@ static inline unsigned long brk_rnd(void) unsigned long rnd = get_random_long(); rnd = rnd << PAGE_SHIFT; - /* 8MB for 32bit, 256MB for 64bit */ + /* 32MB for 32bit, 1GB for 64bit */ if (TASK_IS_32BIT_ADDR) - rnd = rnd & 0x7ful; + rnd = rnd & (SZ_32M - 1); else - rnd = rnd & 0xffful; + rnd = rnd & (SZ_1G - 1); return rnd; }
Re: [EXTERNAL][PATCH REBASE v4 00/14] Provide generic top-down mmap layout functions
On 7/24/19 10:18 PM, Paul Burton wrote: Hi Alexandre, On Wed, Jul 24, 2019 at 01:58:36AM -0400, Alexandre Ghiti wrote: Hi Andrew, This is simply a rebase on top of next-20190719, where I added various Acked/Reviewed-by from Kees and Catalin and a note on commit 08/14 suggested by Kees regarding the removal of STACK_RND_MASK that is safe doing. I would have appreciated a feedback from a mips maintainer but failed to get it: can you consider this series for inclusion anyway ? Mips parts have been reviewed-by Kees. Whilst skimming email on vacation I hadn't spotted how extensive the changes in v4 were after acking v3... In any case, for patches 11-13: Acked-by: Paul Burton Great, thanks Paul ! I have just noticed there is an error in patch 11/14, but without much incidence since it gets fixed in patch 13/14. I'll see with Andrew if he wants a new version or not. Thanks for your time, Alex Thanks, Paul
Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit
On 7/25/19 6:29 AM, maowenan wrote:
>
> Syzkaller reproducer():
> r0 = socket$packet(0x11, 0x3, 0x300)
> r1 = socket$inet_tcp(0x2, 0x1, 0x0)
> bind$inet(r1, &(0x7f000300)={0x2, 0x4e21, @multicast1}, 0x10)
> connect$inet(r1, &(0x7f000140)={0x2, 0x104e21, @loopback}, 0x10)
> recvmmsg(r1, &(0x7f001e40)=[{{0x0, 0x0,
> &(0x7f000100)=[{&(0x7f0005c0)=""/88, 0x58}], 0x1}}], 0x1,
> 0x4000, 0x0)
> sendto$inet(r1, &(0x7f00)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0,
> 0x0)
> r2 = fcntl$dupfd(r1, 0x0, r0)
> connect$unix(r2, &(0x7f0001c0)=@file={0x0, './file0\x00'}, 0x6e)
>
>>
>> It does call tcp_disconnect(), by one of the connect() call.
>
> yes, __inet_stream_connect will call tcp_disconnect when sa_family ==
> AF_UNSPEC, in c repro if it
> passes sa_family with AF_INET it won't call disconnect, and then sk_send_head
> won't be NULL when tcp_connect.
>
Look again at the Syzkaller reproducer()
It definitely uses tcp_disconnect()
Do not be fooled by connect$unix(), this is a connect() call really, with
AF_UNSPEC
Re: kernel BUG at mm/swap_state.c:170!
On Tue, 23 Jul 2019 at 10:08, Huang, Ying wrote: > > Thanks! I have found another (easier way) to reproduce the panic. > Could you try the below patch on top of v5.2-rc2? It can fix the panic > for me. > Thanks! Amazing work! The patch fixes the issue completely. The system worked at a high load of 16 hours without failures. But still seems to me that page cache is being too actively crowded out with a lack of memory. Since, in addition to the top speed SSD on which the swap is located, there is also the slow HDD in the system that just starts to rustle continuously when swap being used. It would seem better to push some of the RAM onto a fast SSD into the swap partition than to leave the slow HDD without a cache. https://imgur.com/a/e8TIkBa But I am afraid it will be difficult to implement such an algorithm that analyzes the waiting time for the file I/O and waiting for paging (memory) and decides to leave parts in memory where the waiting time is more higher it would be more efficient for systems with several drives with access speeds can vary greatly. By waiting time I mean waiting time reading/writing to storage multiplied on the count of hits. Thus, we will not just keep in memory the most popular parts of the memory/disk, but also those parts of which read/write where was most costly. -- Best Regards, Mike Gavrilov.
Re: x86 - clang / objtool status
On Mon, Jul 22, 2019 at 5:40 PM Sedat Dilek wrote: > > On Fri, Jul 19, 2019 at 3:48 PM Sedat Dilek wrote: > > > > > First of all I find out that it is possible to download and apply the > > > series (here: v2) from patchwork (see [1]). > > > I highly appreciate to have this in Josh's Git [2]. > > > > > > > There it is. > > > > - sed@ - > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool-many-fixes-v2 > > next-20190722 has them. > > Parallely, I opened an CBL issue #617 > "drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: > .altinstr_replacement+0x86: redundant UACCESS disable" > > I hope Josh can look at this. > > - Sedat - > > [1] https://github.com/ClangBuiltLinux/linux/issues/617 The objtool warning is fixed by [1]. Now, I see only 3 objtool warnings (all "falls through to next function"): drivers/gpu/drm/radeon/atom.o: warning: objtool: atom_op_move() falls through to next function atom_op_and() drivers/gpu/drm/radeon/evergreen_cs.o: warning: objtool: evergreen_cs_parse() falls through to next function evergreen_dma_cs_parse() drivers/infiniband/hw/hfi1/platform.o: warning: objtool: tune_serdes() falls through to next function apply_tx_lanes() The other i915 call-trace I have seen was independent of $COMPILER and the objtool warning (details see [2] and [3]). I was able to boot into my system. - Sedat - [1] https://lore.kernel.org/patchwork/series/403494/mbox/ [2] https://lore.kernel.org/lkml/20190721142930.GA480@tigerII.localdomain/ [3] https://github.com/ClangBuiltLinux/linux/issues/617#issuecomment-514906560
Re: [HELP REQUESTED from the community] Was: Staging status of speakup
Hi, I have added a few things inline in Greg's message, mainly regarding the bleeps and cursor_time. FWIW, Willem On Wed, 24 Jul 2019, Gregory Nowak wrote: [The e-mail server of the sender could not be verified (SPF Record)] On Fri, Jul 12, 2019 at 05:46:23PM -0700, Gregory Nowak wrote: On Fri, Jul 12, 2019 at 11:23:19AM +0200, Samuel Thibault wrote: Hello, To readers of the linux-speakup: could you help on this so we can get Speakup in mainline? Neither Okash or I completely know what user consequences the files in /sys/accessibility/speakup/ have, so could people give brief explanations for each file (something like 3-6 lines of explanation)? I have a recollection of documenting most of this on the speakup list in response to a similar query a number of years ago. Unfortunately, the speakup mailing list archives aren't easily searchable, and I don't have a local copy of that mail. Kirk, doing grep with a few of the file names in /sys/accessibility/speakup against the list's mbox file archive should find that message if it's in fact there. If you can please find it, and post the date when it was sent, we can provide a URL to that thread as a starting point. If my recollection is wrong, and such a message isn't in the archives, I'll write up what I know about. I've located the message I was thinking of in the archives, but that describes some speakup key commands, not /sys/accessibility/speakup. So, here's what I know, and hopefully someone else can fill in the rest. attrib_bleep Beeps the PC speaker when there is an attribute change such as foreground or background color when using speakup review commands. One = on, zero = off. I'm not currently at a machine with a working PC speaker, so can't test this right now. bell_pos As far as I know, this works much like a typewriter bell. If for example 72 is echoed to bell_pos, it will beep the PC speaker when typing on a line past character 72. Again, no PC speaker at the moment here, so can't actually test this. Yes, it works as you say, a verry short beep happens at the echoed position. bleeps Not 100% sure, but I believe this controls whether one hears beeps through the PC speaker when using speakup's review commands. If no one jumps in on this, I'll experiment when at a machine with a working PC speaker, and will reply back with details. Yes, when 0 is echoed to /sys/accessibility/speakup/bleeps, review beeps stop. the default seem to be 3, so I suppose it controls more than just on or off. When set to zero, the bell still sounds when, e.g. in a terminal at a bash prompt, one press backspace. > bleep_time Again, not 100% sure, but I believe this controls the duration of the PC speaker beeps speakup produces. I'm not sure of the units this is in either, possibly jiffys. I'll come back with more details on this one if no one else does. Yes, it seems to control the time as you say, verry small units though. It was 30 and I could set it to 180, but not 360. At 180, the bleeps are clearly a little longer, but not much. cursor_time Don't know. As far as I know, one can set cursor_time to a higher value when working e.g. over a slow connection. When a connection is very slow, with the default setting, when moving with the arrows, or backspacing etc. speakup says the incorrect characters. I am not 100% sure though, but seem to recall having used such a setting in the past when working over dialup. delimiters Don't know. I've tried echoing various characters to this and looking for differences when reviewing the screen, but no luck. ex_num Don't know. key_echo Controls if speakup speaks keys when they are typed. One = on, zero = off or don't echo keys. keymap I believe this is the currently active kernel keymap. I'm not sure of the format, probably what dumpkeys(1) and showkey(1) use. Echoing different values here should allow for remapping speakup's review commands besides remapping the keyboard as a whole. no_interrupt Controls if typing interrupts output from speakup. With no_interrupt set to zero, typing on the keyboard will interrupt speakup if for example the say screen command is used before the entire screen is read. With no_interrupt set to one, if the say screen command is used, and one then types on the keyboard, speakup will continue to say the whole screen regardless until it finishes. punc_all This is a list of all the punctuation speakup should speak when punc_level is set to four. punc_level Controls the level of punctuation spoken as the screen is displayed, not reviewed. Levels range from zero no punctuation, to four, all punctuation. As far as I can tell, one corresponds to punc_some, two corresponds to punc_most, and three as well as four seem to both correspond to punc_all, though I do stand to be corrected. I am using the soft synthesizer driver, so it is possible that some hardware synthesizers have different levels each corresponding to three and four for punc_level. Also note that if punc_level
Re: [PATCH 1/2] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path
On Thu, Jul 25, 2019 at 12:48 AM Josh Poimboeuf wrote:
>
> Objtool reports:
>
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
> .altinstr_replacement+0x36: redundant UACCESS disable
>
> __copy_from_user() already does both STAC and CLAC, so the
> user_access_end() in its error path adds an extra unnecessary CLAC.
>
> Fixes: 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page fault
> exception case")
> Reported-by: Thomas Gleixner
> Reported-by: Sedat Dilek
> Acked-by: Peter Zijlstra (Intel)
> Tested-by: Nick Desaulniers
> Link: https://github.com/ClangBuiltLinux/linux/issues/617
> Signed-off-by: Josh Poimboeuf
Just for the records and ensuing ages:
Tested-by: Sedat Dilek
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 20 +--
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 5fae0e50aad0..41dab9ea33cd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1628,6 +1628,7 @@ static int check_relocations(const struct
> drm_i915_gem_exec_object2 *entry)
>
> static int eb_copy_relocations(const struct i915_execbuffer *eb)
> {
> + struct drm_i915_gem_relocation_entry *relocs;
> const unsigned int count = eb->buffer_count;
> unsigned int i;
> int err;
> @@ -1635,7 +1636,6 @@ static int eb_copy_relocations(const struct
> i915_execbuffer *eb)
> for (i = 0; i < count; i++) {
> const unsigned int nreloc = eb->exec[i].relocation_count;
> struct drm_i915_gem_relocation_entry __user *urelocs;
> - struct drm_i915_gem_relocation_entry *relocs;
> unsigned long size;
> unsigned long copied;
>
> @@ -1663,14 +1663,8 @@ static int eb_copy_relocations(const struct
> i915_execbuffer *eb)
>
> if (__copy_from_user((char *)relocs + copied,
> (char __user *)urelocs + copied,
> -len)) {
> -end_user:
> - user_access_end();
> -end:
> - kvfree(relocs);
> - err = -EFAULT;
> - goto err;
> - }
> +len))
> + goto end;
>
> copied += len;
> } while (copied < size);
> @@ -1699,10 +1693,14 @@ static int eb_copy_relocations(const struct
> i915_execbuffer *eb)
>
> return 0;
>
> +end_user:
> + user_access_end();
> +end:
> + kvfree(relocs);
> + err = -EFAULT;
> err:
> while (i--) {
> - struct drm_i915_gem_relocation_entry *relocs =
> - u64_to_ptr(typeof(*relocs), eb->exec[i].relocs_ptr);
> + relocs = u64_to_ptr(typeof(*relocs), eb->exec[i].relocs_ptr);
> if (eb->exec[i].relocation_count)
> kvfree(relocs);
> }
> --
> 2.20.1
>
Re: [PATCH REBASE v4 00/14] Provide generic top-down mmap layout functions
On 7/24/19 7:17 PM, Luis Chamberlain wrote: Other than the two comments: Reviewed-by: Luis Chamberlain Thanks for your time Luis, Alex Luis
Re: [PATCH 11/14] PCI/P2PDMA: dma_map P2PDMA map requests that traverse the host bridge
On Wed, Jul 24, 2019 at 09:58:59AM -0600, Logan Gunthorpe wrote:
>
>
> On 2019-07-24 12:32 a.m., Christoph Hellwig wrote:
> >>struct dev_pagemap *pgmap = sg_page(sg)->pgmap;
> >> + struct pci_dev *client;
> >> + int dist;
> >> +
> >> + client = find_parent_pci_dev(dev);
> >> + if (WARN_ON_ONCE(!client))
> >> + return 0;
> >>
> >> + dist = upstream_bridge_distance(pgmap->pci_p2pdma_provider,
> >> + client, NULL);
> >
> > Doing this on every mapping call sounds expensive..
>
> The result of this function is cached in an xarray (per patch 4) so, on
> the hot path, it should just be a single xa_load() which should be a
> relatively fast lookup which is similarly used for other hot path
> operations.
We don't cache find_parent_pci_dev, though. So we should probably
export find_parent_pci_dev with a proper namespaces name and cache
that in the caler.
> >
> >> + if (WARN_ON_ONCE(dist & P2PDMA_NOT_SUPPORTED))
> >> + return 0;
> >> +
> >> + if (dist & P2PDMA_THRU_HOST_BRIDGE)
> >> + return dma_map_sg_attrs(dev, sg, nents, dir, attrs);
> >> + else
> >> + return __pci_p2pdma_map_sg(pgmap, dev, sg, nents);
> >
> > Can't we organize the values so that we can switch on the return
> > value instead of doing flag checks?
>
> Sorry, I don't follow what you are saying here. If you mean for
> upstream_bridge_distance() to just return how to map and not the
> distance that would interfere with other uses of that function.
The point is that in the map path we don't even care about the
distance. I think we should just have a function that returns the
P2PDMA_ values from the xarray (maybe also store it there as two
values, but that isn't quite as important), and get rid of even
the concept of distance in the map path. e.g.:
switch (pci_p2pdma_supported(pgmap->pci_p2pdma_provider, client))) {
case P2PDMA_HOST_BRIDGE:
return dma_map_sg_attrs(dev, sg, nents, dir, attrs);
case P2PDMA_SWITCH:
return __pci_p2pdma_map_sg(pgmap, dev, sg, nents);
default:
WARN_ON_ONCE(1);
return 0;
}
Re: [PATCH REBASE v4 12/14] mips: Replace arch specific way to determine 32bit task with generic version
On 7/24/19 7:16 PM, Luis Chamberlain wrote: On Wed, Jul 24, 2019 at 01:58:48AM -0400, Alexandre Ghiti wrote: Mips uses TASK_IS_32BIT_ADDR to determine if a task is 32bit, but this define is mips specific and other arches do not have it: instead, use !IS_ENABLED(CONFIG_64BIT) || is_compat_task() condition. Signed-off-by: Alexandre Ghiti Reviewed-by: Kees Cook --- arch/mips/mm/mmap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c index faa5aa615389..d4eafbb82789 100644 --- a/arch/mips/mm/mmap.c +++ b/arch/mips/mm/mmap.c @@ -17,6 +17,7 @@ #include #include #include +#include unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */ EXPORT_SYMBOL(shm_align_mask); @@ -191,7 +192,7 @@ static inline unsigned long brk_rnd(void) rnd = rnd << PAGE_SHIFT; /* 32MB for 32bit, 1GB for 64bit */ - if (TASK_IS_32BIT_ADDR) + if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task()) rnd = rnd & SZ_32M; else rnd = rnd & SZ_1G; -- Since there are at least two users why not just create an inline for this which describes what we are looking for and remove the comments? Actually this is a preparatory patch, this will get merged with the generic version in the next patch. Alex Luis ___ linux-riscv mailing list linux-ri...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [alsa-devel] [PATCH 06/10] ASoC: dt-bindings: Document dl_mask property
On Thu, Jul 25, 2019 at 2:14 AM Nicolin Chen wrote: > > On Mon, Jul 22, 2019 at 03:48:29PM +0300, Daniel Baluta wrote: > > SAI supports up to 8 data lines. This property let the user > > configure how many data lines should be used per transfer > > direction (Tx/Rx). > > > > Signed-off-by: Daniel Baluta > > --- > > Documentation/devicetree/bindings/sound/fsl-sai.txt | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt > > b/Documentation/devicetree/bindings/sound/fsl-sai.txt > > index 2e726b983845..59f4d965a5fb 100644 > > --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt > > +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt > > @@ -49,6 +49,11 @@ Optional properties: > > > + - fsl,dl_mask : list of two integers (bitmask, first for > > RX, second > > Not quite in favor of the naming here; And this patch should > be sent to the devicetree maillist and add DT maintainers -- > they would give some good naming advice. > > From my point of view, I feel, since data lines are enabled > consecutively, probably it'd be clear just to have something > like "fsl,num-datalines = <2 2>", corresponding to "dl_mask > = <0x3 0x3>". I believe there're examples in the existing DT > bindings, so let's see how others suggest. > Your suggestion looks good to me. Anyhow, after reading again the documentation it seems that datalines are not always required to be consecutive. The need to be consecutive only when FIFO combine mode is enabled. Will fix the documentation in the next version.
Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"
On Wed, Jul 24, 2019 at 03:27:37PM -0700, Alexander Duyck wrote: > On Wed, 2019-07-24 at 18:08 -0400, Michael S. Tsirkin wrote: > > On Wed, Jul 24, 2019 at 03:03:56PM -0700, Alexander Duyck wrote: > > > On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote: > > > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote: > > > > > From: Alexander Duyck > > > > > > > > > > Add support for what I am referring to as "bubble hinting". Basically > > > > > the > > > > > idea is to function very similar to how the balloon works in that we > > > > > basically end up madvising the page as not being used. However we > > > > > don't > > > > > really need to bother with any deflate type logic since the page will > > > > > be > > > > > faulted back into the guest when it is read or written to. > > > > > > > > > > This is meant to be a simplification of the existing balloon interface > > > > > to use for providing hints to what memory needs to be freed. I am > > > > > assuming > > > > > this is safe to do as the deflate logic does not actually appear to > > > > > do very > > > > > much other than tracking what subpages have been released and which > > > > > ones > > > > > haven't. > > > > > > > > > > Signed-off-by: Alexander Duyck > > > > > > > > BTW I wonder about migration here. When we migrate we lose all hints > > > > right? Well destination could be smarter, detect that page is full of > > > > 0s and just map a zero page. Then we don't need a hint as such - but I > > > > don't think it's done like that ATM. > > > > > > I was wondering about that a bit myself. If you migrate with a balloon > > > active what currently happens with the pages in the balloon? Do you > > > actually migrate them, or do you ignore them and just assume a zero page? > > > > Ignore and assume zero page. > > > > > I'm just reusing the ram_block_discard_range logic that was being used for > > > the balloon inflation so I would assume the behavior would be the same. > > > > > > > I also wonder about interaction with deflate. ATM deflate will add > > > > pages to the free list, then balloon will come right back and report > > > > them as free. > > > > > > I don't know how likely it is that somebody who is getting the free page > > > reporting is likely to want to also use the balloon to take up memory. > > > > Why not? > > The two functions are essentially doing the same thing. The only real > difference is enforcement. If the balloon takes the pages the guest cannot > get them back. I suppose there might be some advantage if you are wanting > for force shrink a guest but that would be about it. Yea, that's a common use of the balloon ATM. Helps partition the host so guests don't conflict. OTOH deflate on oom thing probably will never be used with hinting. > > > However hinting on a page that came out of deflate might make sense when > > > you consider that the balloon operates on 4K pages and the hints are on 2M > > > pages. You are likely going to lose track of it all anyway as you have to > > > work to merge the 4K pages up to the higher order page. > > > > Right - we need to fix inflate/deflate anyway. > > When we do, we can do whatever :) > > One thing we could probably look at for the future would be to more > closely merge the balloon and this reporting logic. Ideally the balloon > would grab pages that were already hinted in order to enforce a certain > size limit on the guest, and then when it gave the pages back they would > retain their hinted status if possible. > > The only problem is that right now both of those require that > hinting/reporting be active for the zone being accessed since we otherwise > don't have pointers to the pages at the head of the "hinted" list. I guess I was talking about reworking host/guest ABI, you were talking about the internals. So both need to change :)
Re: [alsa-devel] [PATCH 09/10] ASoC: fsl_sai: Add support for SAI new version
On Thu, Jul 25, 2019 at 2:32 AM Nicolin Chen wrote: > > On Mon, Jul 22, 2019 at 03:48:32PM +0300, Daniel Baluta wrote: > > New IP version introduces Version ID and Parameter registers > > and optionally added Timestamp feature. > > > > VERID and PARAM registers are placed at the top of registers > > address space and some registers are shifted according to > > the following table: > > > > Tx/Rx data registers and Tx/Rx FIFO registers keep their > > addresses, all other registers are shifted by 8. > > Feels like Lucas's approach is neater. I saw that Register TMR > at 0x60 is exceptional during your previous discussion. So can > we apply an offset-cancellation for it exceptionally? I haven't > checked all the registers so this would look okay to me as well > if there are more than just Register TMR. It is not just TMR exceptional. There are like half of the registers. Thus: half of the registers need to be shifted and half of them need to stay the same as in previous version of SAI. I'm not seeing yet a neater approach. Lucas idea would somehow work if regmap will allow some sort of translation function applied over registers before being accessed. Maybe Mark has some clues here? thanks, daniel.
Re: [alsa-devel] [PATCH 08/10] ASoC: dt-bindings: Document fcomb_mode property
On Thu, Jul 25, 2019 at 2:22 AM Nicolin Chen wrote: > > On Mon, Jul 22, 2019 at 03:48:31PM +0300, Daniel Baluta wrote: > > This allows combining multiple-data-line FIFOs into a > > single-data-line FIFO. > > > > Signed-off-by: Daniel Baluta > > --- > > Documentation/devicetree/bindings/sound/fsl-sai.txt | 4 > > This should be sent to devicetree mail-list also. > > > 1 file changed, 4 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt > > b/Documentation/devicetree/bindings/sound/fsl-sai.txt > > index 59f4d965a5fb..ca27afd840ba 100644 > > --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt > > +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt > > @@ -54,6 +54,10 @@ Optional properties: > > represents first data line, bit 1 represents second > > data line and so on. Data line is enabled if > > corresponding bit is set to 1. > > + - fsl,fcomb_mode : list of two integers (first for RX, second for TX) > > + representing FIFO combine mode. Possible values for > > + combined mode are: 0 - disabled, 1 - Rx/Tx from > > shift > > + registers, 2 - Rx/Tx by software, 3 - both. > > Looks like a software configuration to me, instead of a device > property. Is this configurable by user case, or hard-coded by > SoC/hardware design? Indeed this is a software configuration and configurable by user case. Will think of a another way to specify it.
Re: WARNING in __mmdrop
On Mon, Jul 22, 2019 at 11:11:52AM -0300, Jason Gunthorpe wrote:
> On Sun, Jul 21, 2019 at 06:02:52AM -0400, Michael S. Tsirkin wrote:
> > On Sat, Jul 20, 2019 at 03:08:00AM -0700, syzbot wrote:
> > > syzbot has bisected this bug to:
> > >
> > > commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
> > > Author: Jason Wang
> > > Date: Fri May 24 08:12:18 2019 +
> > >
> > > vhost: access vq metadata through kernel virtual address
> > >
> > > bisection log:
> > > https://syzkaller.appspot.com/x/bisect.txt?x=149a8a2060
> > > start commit: 6d21a41b Add linux-next specific files for 20190718
> > > git tree: linux-next
> > > final crash:
> > > https://syzkaller.appspot.com/x/report.txt?x=169a8a2060
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=129a8a2060
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=e58112d71f77113ddb7b
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10139e6860
> > >
> > > Reported-by: syzbot+e58112d71f77113dd...@syzkaller.appspotmail.com
> > > Fixes: 7f466032dc9e ("vhost: access vq metadata through kernel virtual
> > > address")
> > >
> > > For information about bisection process see:
> > > https://goo.gl/tpsmEJ#bisection
> >
> >
> > OK I poked at this for a bit, I see several things that
> > we need to fix, though I'm not yet sure it's the reason for
> > the failures:
>
> This stuff looks quite similar to the hmm_mirror use model and other
> places in the kernel. I'm still hoping we can share this code a bit more.
Right. I think hmm is something we should look at.
--
MST
Re: [PATCH 07/14] PCI/P2PDMA: Add the provider's pci_dev to the dev_pgmap struct
On Wed, Jul 24, 2019 at 09:50:03AM -0600, Logan Gunthorpe wrote: > OK, I was going to do that, but you just removed the p2p specific page > map. ;) Only because it was empty at that time..
Re: [alsa-devel] [PATCH 01/10] ASoC: fsl_sai: add of_match data
On Thu, Jul 25, 2019 at 1:34 AM Nicolin Chen wrote: > > On Mon, Jul 22, 2019 at 03:48:24PM +0300, Daniel Baluta wrote: > > From: Lucas Stach > > > > New revisions of the SAI IP block have even more differences that need > > be taken into account by the driver. To avoid sprinking compatible > > checks all over the driver move the current differences into of_match_data. > > > > Signed-off-by: Lucas Stach > > Looks like Mark has applied this already? If so, should probably > drop applied ones and rebase the remaining patches for a resend. Yes 1/10 and 2/10 were already applied. Will drop them from next version.
Re: [PATCH v2 2/2] mwifiex: Make use of the new sdio_trigger_replug() API to reset
Doug Anderson writes:
> Hi,
>
> On Wed, Jul 24, 2019 at 4:35 AM Kalle Valo wrote:
>>
>> Douglas Anderson wrote:
>>
>> > As described in the patch ("mmc: core: Add sdio_trigger_replug()
>> > API"), the current mwifiex_sdio_card_reset() is broken in the cases
>> > where we're running Bluetooth on a second SDIO func on the same card
>> > as WiFi. The problem goes away if we just use the
>> > sdio_trigger_replug() API call.
>> >
>> > NOTE: Even though with this new solution there is less of a reason to
>> > do our work from a workqueue (the unplug / plug mechanism we're using
>> > is possible for a human to perform at any time so the stack is
>> > supposed to handle it without it needing to be called from a special
>> > context), we still need a workqueue because the Marvell reset function
>> > could called from a context where sleeping is invalid and thus we
>> > can't claim the host. One example is Marvell's wakeup_timer_fn().
>> >
>> > Cc: Andreas Fenkart
>> > Cc: Brian Norris
>> > Fixes: b4336a282db8 ("mwifiex: sdio: reset adapter using mmc_hw_reset")
>> > Signed-off-by: Douglas Anderson
>> > Reviewed-by: Brian Norris
>>
>> I assume this is going via some other tree so I'm dropping this from my
>> queue. If I should apply this please resend once the dependency is in
>> wireless-drivers-next.
>>
>> Patch set to Not Applicable.
>
> Thanks. For now I'll assume that Ulf will pick it up if/when he is
> happy with patch #1 in this series. Would you be willing to provide
> your Ack on this patch to make it clear to Ulf you're OK with that?
Sure, I was planning to do that already in my previous email but forgot.
Acked-by: Kalle Valo
--
Kalle Valo
Re: [PATCH v4 1/3] driver core: platform: Add an error message to platform_get_irq*()
…
> +++ b/drivers/base/platform.c
> @@ -99,12 +99,7 @@ void __iomem *devm_platform_ioremap_resource(struct
> platform_device *pdev,
…
> -int platform_get_irq(struct platform_device *dev, unsigned int num)
> +static int __platform_get_irq(struct platform_device *dev, unsigned int num)
> {
…
I suggest to avoid the usage of double underscores in such identifiers.
Will an other function name be more appropriate here?
Regards,
Markus
[PATCH 4.19 110/271] ath10k: add missing error handling
[ Upstream commit 4b553f3ca4cbde67399aa3a756c37eb92145b8a1 ]
In function ath10k_sdio_mbox_rx_alloc() [sdio.c],
ath10k_sdio_mbox_alloc_rx_pkt() is called without handling the error cases.
This will make the driver think the allocation for skb is successful and
try to access the skb. If we enable failslab, system will easily crash with
NULL pointer dereferencing.
Call trace of CONFIG_FAILSLAB:
ath10k_sdio_irq_handler+0x570/0xa88 [ath10k_sdio]
process_sdio_pending_irqs+0x4c/0x174
sdio_run_irqs+0x3c/0x64
sdio_irq_work+0x1c/0x28
Fixes: d96db25d2025 ("ath10k: add initial SDIO support")
Signed-off-by: Claire Chang
Reviewed-by: Brian Norris
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
---
drivers/net/wireless/ath/ath10k/sdio.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/sdio.c
b/drivers/net/wireless/ath/ath10k/sdio.c
index 7f61591ce0de..cb527a21f1ac 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -613,6 +613,10 @@ static int ath10k_sdio_mbox_rx_alloc(struct ath10k *ar,
full_len,
last_in_bundle,
last_in_bundle);
+ if (ret) {
+ ath10k_warn(ar, "alloc_rx_pkt error %d\n", ret);
+ goto err;
+ }
}
ar_sdio->n_rx_pkts = i;
--
2.20.1
[PATCH 4.19 105/271] rtlwifi: rtl8192cu: fix error handle when usb probe failed
[ Upstream commit 6c0ed66f1a5b84e2a812c7c2d6571a5621bf3396 ]
rtl_usb_probe() must do error handle rtl_deinit_core() only if
rtl_init_core() is done, otherwise goto error_out2.
| usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
| rtl_usb: reg 0xf0, usbctrl_vendorreq TimeOut! status:0xffb9 value=0x0
| rtl8192cu: Chip version 0x10
| rtl_usb: reg 0xa, usbctrl_vendorreq TimeOut! status:0xffb9 value=0x0
| rtl_usb: Too few input end points found
| INFO: trying to register non-static key.
| the code is fine but needs lockdep annotation.
| turning off the locking correctness validator.
| CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
| Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
| Google 01/01/2011
| Workqueue: usb_hub_wq hub_event
| Call Trace:
| __dump_stack lib/dump_stack.c:77 [inline]
| dump_stack+0xe8/0x16e lib/dump_stack.c:113
| assign_lock_key kernel/locking/lockdep.c:786 [inline]
| register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
| __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
| lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
| __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
| _raw_spin_lock_irqsave+0x44/0x60 kernel/locking/spinlock.c:152
| rtl_c2hcmd_launcher+0xd1/0x390
| drivers/net/wireless/realtek/rtlwifi/base.c:2344
| rtl_deinit_core+0x25/0x2d0 drivers/net/wireless/realtek/rtlwifi/base.c:574
| rtl_usb_probe.cold+0x861/0xa70
| drivers/net/wireless/realtek/rtlwifi/usb.c:1093
| usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
| really_probe+0x2da/0xb10 drivers/base/dd.c:509
| driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
| __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
| bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
| __device_attach+0x223/0x3a0 drivers/base/dd.c:844
| bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
| device_add+0xad2/0x16e0 drivers/base/core.c:2106
| usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
| generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
| usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
| really_probe+0x2da/0xb10 drivers/base/dd.c:509
| driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
| __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
| bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
| __device_attach+0x223/0x3a0 drivers/base/dd.c:844
| bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
| device_add+0xad2/0x16e0 drivers/base/core.c:2106
| usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
| hub_port_connect drivers/usb/core/hub.c:5089 [inline]
| hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
| port_event drivers/usb/core/hub.c:5350 [inline]
| hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
| process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
| worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
| kthread+0x313/0x420 kernel/kthread.c:253
| ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Reported-by: syzbot+1fcc5ef45175fc774...@syzkaller.appspotmail.com
Signed-off-by: Ping-Ke Shih
Acked-by: Larry Finger
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
---
drivers/net/wireless/realtek/rtlwifi/usb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 2ac5004d7a40..5adb939afee8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -1081,13 +1081,13 @@ int rtl_usb_probe(struct usb_interface *intf,
rtlpriv->cfg->ops->read_eeprom_info(hw);
err = _rtl_usb_init(hw);
if (err)
- goto error_out;
+ goto error_out2;
rtl_usb_init_sw(hw);
/* Init mac80211 sw */
err = rtl_init_core(hw);
if (err) {
pr_err("Can't allocate sw for mac80211\n");
- goto error_out;
+ goto error_out2;
}
if (rtlpriv->cfg->ops->init_sw_vars(hw)) {
pr_err("Can't init_sw_vars\n");
@@ -1108,6 +1108,7 @@ int rtl_usb_probe(struct usb_interface *intf,
error_out:
rtl_deinit_core(hw);
+error_out2:
_rtl_usb_io_handler_release(hw);
usb_put_dev(udev);
complete(&rtlpriv->firmware_loading_complete);
--
2.20.1
Trabaja conmigo
Hola, Tenemos algunas finanzas en su nombre de familia amablemente Póngase en contacto conmigo aquí [(info.attltz...@gmail.com)] para más información. Saludos, Lutz
[PATCH 4.19 083/271] x86/cacheinfo: Fix a -Wtype-limits warning
[ Upstream commit 1b7aebf0487613033aff26420e32fa2076d52846 ]
cpuinfo_x86.x86_model is an unsigned type, so comparing against zero
will generate a compilation warning:
arch/x86/kernel/cpu/cacheinfo.c: In function 'cacheinfo_amd_init_llc_id':
arch/x86/kernel/cpu/cacheinfo.c:662:19: warning: comparison is always true \
due to limited range of data type [-Wtype-limits]
Remove the unnecessary lower bound check.
[ bp: Massage. ]
Fixes: 68091ee7ac3c ("x86/CPU/AMD: Calculate last level cache ID from number of
sharing threads")
Signed-off-by: Qian Cai
Signed-off-by: Borislav Petkov
Reviewed-by: Sean Christopherson
Cc: "Gustavo A. R. Silva"
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Masami Hiramatsu
Cc: Pu Wen
Cc: Suravee Suthikulpanit
Cc: Thomas Gleixner
Cc: x86-ml
Link: https://lkml.kernel.org/r/1560954773-11967-1-git-send-email-...@lca.pw
Signed-off-by: Sasha Levin
---
arch/x86/kernel/cpu/cacheinfo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 0c5fcbd998cf..9d863e8f9b3f 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -651,8 +651,7 @@ void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int
cpu, u8 node_id)
if (c->x86 < 0x17) {
/* LLC is at the node level. */
per_cpu(cpu_llc_id, cpu) = node_id;
- } else if (c->x86 == 0x17 &&
- c->x86_model >= 0 && c->x86_model <= 0x1F) {
+ } else if (c->x86 == 0x17 && c->x86_model <= 0x1F) {
/*
* LLC is at the core complex level.
* Core complex ID is ApicId[3] for these processors.
--
2.20.1
[PATCH 4.19 119/271] ixgbe: Check DDM existence in transceiver before access
[ Upstream commit 655c91414579d7bb115a4f7898ee726fc18e0984 ]
Some transceivers may comply with SFF-8472 but not implement the Digital
Diagnostic Monitoring (DDM) interface described in it. The existence of
such area is specified by bit 6 of byte 92, set to 1 if implemented.
Currently, due to not checking this bit ixgbe fails trying to read SFP
module's eeprom with the follow message:
ethtool -m enP51p1s0f0
Cannot get Module EEPROM data: Input/output error
Because it fails to read the additional 256 bytes in which it was assumed
to exist the DDM data.
This issue was noticed using a Mellanox Passive DAC PN 01FT738. The eeprom
data was confirmed by Mellanox as correct and present in other Passive
DACs in from other manufacturers.
Signed-off-by: "Mauro S. M. Rodrigues"
Reviewed-by: Jesse Brandeburg
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 3 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index e5a8461fe6a9..8829bd95d0d3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -3223,7 +3223,8 @@ static int ixgbe_get_module_info(struct net_device *dev,
page_swap = true;
}
- if (sff8472_rev == IXGBE_SFF_SFF_8472_UNSUP || page_swap) {
+ if (sff8472_rev == IXGBE_SFF_SFF_8472_UNSUP || page_swap ||
+ !(addr_mode & IXGBE_SFF_DDM_IMPLEMENTED)) {
/* We have a SFP, but it does not support SFF-8472 */
modinfo->type = ETH_MODULE_SFF_8079;
modinfo->eeprom_len = ETH_MODULE_SFF_8079_LEN;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h
index 64e44e01c973..c56baad04ee6 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.h
@@ -45,6 +45,7 @@
#define IXGBE_SFF_SOFT_RS_SELECT_10G 0x8
#define IXGBE_SFF_SOFT_RS_SELECT_1G0x0
#define IXGBE_SFF_ADDRESSING_MODE 0x4
+#define IXGBE_SFF_DDM_IMPLEMENTED 0x40
#define IXGBE_SFF_QSFP_DA_ACTIVE_CABLE 0x1
#define IXGBE_SFF_QSFP_DA_PASSIVE_CABLE0x8
#define IXGBE_SFF_QSFP_CONNECTOR_NOT_SEPARABLE 0x23
--
2.20.1
[PATCH 4.19 081/271] vhost_net: disable zerocopy by default
[ Upstream commit 098eadce3c622c07b328d0a43dda379b38cf7c5e ] Vhost_net was known to suffer from HOL[1] issues which is not easy to fix. Several downstream disable the feature by default. What's more, the datapath was split and datacopy path got the support of batching and XDP support recently which makes it faster than zerocopy part for small packets transmission. It looks to me that disable zerocopy by default is more appropriate. It cold be enabled by default again in the future if we fix the above issues. [1] https://patchwork.kernel.org/patch/3787671/ Signed-off-by: Jason Wang Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/vhost/net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 39155d7cc894..ae704658b528 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -36,7 +36,7 @@ #include "vhost.h" -static int experimental_zcopytx = 1; +static int experimental_zcopytx = 0; module_param(experimental_zcopytx, int, 0444); MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;" " 1 -Enable; 0 - Disable"); -- 2.20.1
[PATCH 4.19 107/271] x86/build: Add set -e to mkcapflags.sh to delete broken capflags.c
[ Upstream commit bc53d3d777f81385c1bb08b07bd1c06450ecc2c1 ]
Without 'set -e', shell scripts continue running even after any
error occurs. The missed 'set -e' is a typical bug in shell scripting.
For example, when a disk space shortage occurs while this script is
running, it actually ends up with generating a truncated capflags.c.
Yet, mkcapflags.sh continues running and exits with 0. So, the build
system assumes it has succeeded.
It will not be re-generated in the next invocation of Make since its
timestamp is newer than that of any of the source files.
Add 'set -e' so that any error in this script is caught and propagated
to the build system.
Since 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special target"),
make automatically deletes the target on any failure. So, the broken
capflags.c will be deleted automatically.
Signed-off-by: Masahiro Yamada
Signed-off-by: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: Borislav Petkov
Link:
https://lkml.kernel.org/r/20190625072622.17679-1-yamada.masah...@socionext.com
Signed-off-by: Sasha Levin
---
arch/x86/kernel/cpu/mkcapflags.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/cpu/mkcapflags.sh
b/arch/x86/kernel/cpu/mkcapflags.sh
index d0dfb892c72f..aed45b8895d5 100644
--- a/arch/x86/kernel/cpu/mkcapflags.sh
+++ b/arch/x86/kernel/cpu/mkcapflags.sh
@@ -4,6 +4,8 @@
# Generate the x86_cap/bug_flags[] arrays from include/asm/cpufeatures.h
#
+set -e
+
IN=$1
OUT=$2
--
2.20.1
Re: WARNING in __mmdrop
On Tue, Jul 23, 2019 at 09:31:35PM +0800, Jason Wang wrote:
>
> On 2019/7/23 下午5:26, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 04:49:01PM +0800, Jason Wang wrote:
> > > On 2019/7/23 下午4:10, Michael S. Tsirkin wrote:
> > > > On Tue, Jul 23, 2019 at 03:53:06PM +0800, Jason Wang wrote:
> > > > > On 2019/7/23 下午3:23, Michael S. Tsirkin wrote:
> > > > > > > > Really let's just use kfree_rcu. It's way cleaner: fire and
> > > > > > > > forget.
> > > > > > > Looks not, you need rate limit the fire as you've figured out?
> > > > > > See the discussion that followed. Basically no, it's good enough
> > > > > > already and is only going to be better.
> > > > > >
> > > > > > > And in fact,
> > > > > > > the synchronization is not even needed, does it help if I leave a
> > > > > > > comment to
> > > > > > > explain?
> > > > > > Let's try to figure it out in the mail first. I'm pretty sure the
> > > > > > current logic is wrong.
> > > > > Here is what the code what to achieve:
> > > > >
> > > > > - The map was protected by RCU
> > > > >
> > > > > - Writers are: MMU notifier invalidation callbacks, file operations
> > > > > (ioctls
> > > > > etc), meta_prefetch (datapath)
> > > > >
> > > > > - Readers are: memory accessor
> > > > >
> > > > > Writer are synchronized through mmu_lock. RCU is used to synchronized
> > > > > between writers and readers.
> > > > >
> > > > > The synchronize_rcu() in vhost_reset_vq_maps() was used to
> > > > > synchronized it
> > > > > with readers (memory accessors) in the path of file operations. But
> > > > > in this
> > > > > case, vq->mutex was already held, this means it has been serialized
> > > > > with
> > > > > memory accessor. That's why I think it could be removed safely.
> > > > >
> > > > > Anything I miss here?
> > > > >
> > > > So invalidate callbacks need to reset the map, and they do
> > > > not have vq mutex. How can they do this and free
> > > > the map safely? They need synchronize_rcu or kfree_rcu right?
> > > Invalidation callbacks need but file operations (e.g ioctl) not.
> > >
> > >
> > > > And I worry somewhat that synchronize_rcu in an MMU notifier
> > > > is a problem, MMU notifiers are supposed to be quick:
> > > Looks not, since it can allow to be blocked and lots of driver depends on
> > > this. (E.g mmu_notifier_range_blockable()).
> > Right, they can block. So why don't we take a VQ mutex and be
> > done with it then? No RCU tricks.
>
>
> This is how I want to go with RFC and V1. But I end up with deadlock between
> vq locks and some MM internal locks. So I decide to use RCU which is 100%
> under the control of vhost.
>
> Thanks
And I guess the deadlock is because GUP is taking mmu locks which are
taken on mmu notifier path, right? How about we add a seqlock and take
that in invalidate callbacks? We can then drop the VQ lock before GUP,
and take it again immediately after.
something like
if (!vq_meta_mapped(vq)) {
vq_meta_setup(&uaddrs);
mutex_unlock(vq->mutex)
vq_meta_map(&uaddrs);
mutex_lock(vq->mutex)
/* recheck both sock->private_data and seqlock count. */
if changed - bail out
}
And also requires that VQ uaddrs is defined like this:
- writers must have both vq mutex and dev mutex
- readers must have either vq mutex or dev mutex
That's a big change though. For now, how about switching to a per-vq SRCU?
That is only a little bit more expensive than RCU, and we
can use synchronize_srcu_expedited.
--
MST
[PATCH 4.19 113/271] ASoC: Intel: hdac_hdmi: Set ops to NULL on remove
[ Upstream commit 0f6ff78540bd1b4df1e0f17806b0ce2e1dff0d78 ]
When we unload Skylake driver we may end up calling
hdac_component_master_unbind(), it uses acomp->audio_ops, which we set
in hdmi_codec_probe(), so we need to set it to NULL in hdmi_codec_remove(),
otherwise we will dereference no longer existing pointer.
Signed-off-by: Amadeusz Sławiński
Reviewed-by: Pierre-Louis Bossart
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/hdac_hdmi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c
index 63487240b61e..098196610542 100644
--- a/sound/soc/codecs/hdac_hdmi.c
+++ b/sound/soc/codecs/hdac_hdmi.c
@@ -1854,6 +1854,12 @@ static void hdmi_codec_remove(struct snd_soc_component
*component)
{
struct hdac_hdmi_priv *hdmi = snd_soc_component_get_drvdata(component);
struct hdac_device *hdev = hdmi->hdev;
+ int ret;
+
+ ret = snd_hdac_acomp_register_notifier(hdev->bus, NULL);
+ if (ret < 0)
+ dev_err(&hdev->dev, "notifier unregister failed: err: %d\n",
+ ret);
pm_runtime_disable(&hdev->dev);
}
--
2.20.1
[PATCH 4.19 115/271] clocksource/drivers/exynos_mct: Increase priority over ARM arch timer
[ Upstream commit 6282edb72bed5324352522d732080d4c1b9dfed6 ]
Exynos SoCs based on CA7/CA15 have 2 timer interfaces: custom Exynos MCT
(Multi Core Timer) and standard ARM Architected Timers.
There are use cases, where both timer interfaces are used simultanously.
One of such examples is using Exynos MCT for the main system timer and
ARM Architected Timers for the KVM and virtualized guests (KVM requires
arch timers).
Exynos Multi-Core Timer driver (exynos_mct) must be however started
before ARM Architected Timers (arch_timer), because they both share some
common hardware blocks (global system counter) and turning on MCT is
needed to get ARM Architected Timer working properly.
To ensure selecting Exynos MCT as the main system timer, increase MCT
timer rating. To ensure proper starting order of both timers during
suspend/resume cycle, increase MCT hotplug priority over ARM Archictected
Timers.
Signed-off-by: Marek Szyprowski
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Chanwoo Choi
Signed-off-by: Daniel Lezcano
Signed-off-by: Sasha Levin
---
drivers/clocksource/exynos_mct.c | 4 ++--
include/linux/cpuhotplug.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index d55c30f6981d..aaf5bfa9bd9c 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -211,7 +211,7 @@ static void exynos4_frc_resume(struct clocksource *cs)
static struct clocksource mct_frc = {
.name = "mct-frc",
- .rating = 400,
+ .rating = 450, /* use value higher than ARM arch timer */
.read = exynos4_frc_read,
.mask = CLOCKSOURCE_MASK(32),
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
@@ -466,7 +466,7 @@ static int exynos4_mct_starting_cpu(unsigned int cpu)
evt->set_state_oneshot_stopped = set_state_shutdown;
evt->tick_resume = set_state_shutdown;
evt->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
- evt->rating = 450;
+ evt->rating = 500; /* use value higher than ARM arch timer */
exynos4_mct_write(TICK_BASE_CNT, mevt->base + MCT_L_TCNTB_OFFSET);
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index dec0372efe2e..d67c0035165c 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -116,10 +116,10 @@ enum cpuhp_state {
CPUHP_AP_PERF_ARM_ACPI_STARTING,
CPUHP_AP_PERF_ARM_STARTING,
CPUHP_AP_ARM_L2X0_STARTING,
+ CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
CPUHP_AP_ARM_ARCH_TIMER_STARTING,
CPUHP_AP_ARM_GLOBAL_TIMER_STARTING,
CPUHP_AP_JCORE_TIMER_STARTING,
- CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
CPUHP_AP_ARM_TWD_STARTING,
CPUHP_AP_QCOM_TIMER_STARTING,
CPUHP_AP_ARMADA_TIMER_STARTING,
--
2.20.1
[PATCH 4.19 134/271] iwlwifi: mvm: Drop large non sta frames
[ Upstream commit ac70499ee97231a418dc1a4d6c9dc102e8f64631 ] In some buggy scenarios we could possible attempt to transmit frames larger than maximum MSDU size. Since our devices don't know how to handle this, it may result in asserts, hangs etc. This can happen, for example, when we receive a large multicast frame and try to transmit it back to the air in AP mode. Since in a legal scenario this should never happen, drop such frames and warn about it. Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin --- drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c index 2d21f0a1fa00..ffae299c3492 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c @@ -641,6 +641,9 @@ int iwl_mvm_tx_skb_non_sta(struct iwl_mvm *mvm, struct sk_buff *skb) memcpy(&info, skb->cb, sizeof(info)); + if (WARN_ON_ONCE(skb->len > IEEE80211_MAX_DATA_LEN + hdrlen)) + return -1; + if (WARN_ON_ONCE(info.flags & IEEE80211_TX_CTL_AMPDU)) return -1; -- 2.20.1
[PATCH 4.19 117/271] rslib: Fix decoding of shortened codes
[ Upstream commit 2034a42d1747fc1e1eeef2c6f1789c4d0762cb9c ]
The decoding of shortenend codes is broken. It only works as expected if
there are no erasures.
When decoding with erasures, Lambda (the error and erasure locator
polynomial) is initialized from the given erasure positions. The pad
parameter is not accounted for by the initialisation code, and hence
Lambda is initialized from incorrect erasure positions.
The fix is to adjust the erasure positions by the supplied pad.
Signed-off-by: Ferdinand Blomqvist
Signed-off-by: Thomas Gleixner
Link:
https://lkml.kernel.org/r/20190620141039.9874-3-ferdinand.blomqv...@gmail.com
Signed-off-by: Sasha Levin
---
lib/reed_solomon/decode_rs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/reed_solomon/decode_rs.c b/lib/reed_solomon/decode_rs.c
index 1db74eb098d0..3313bf944ff1 100644
--- a/lib/reed_solomon/decode_rs.c
+++ b/lib/reed_solomon/decode_rs.c
@@ -99,9 +99,9 @@
if (no_eras > 0) {
/* Init lambda to be the erasure locator polynomial */
lambda[1] = alpha_to[rs_modnn(rs,
- prim * (nn - 1 - eras_pos[0]))];
+ prim * (nn - 1 - (eras_pos[0] + pad)))];
for (i = 1; i < no_eras; i++) {
- u = rs_modnn(rs, prim * (nn - 1 - eras_pos[i]));
+ u = rs_modnn(rs, prim * (nn - 1 - (eras_pos[i] + pad)));
for (j = i + 1; j > 0; j--) {
tmp = index_of[lambda[j - 1]];
if (tmp != nn) {
--
2.20.1
Re: [PATCH v2 0/1] mm/memory-failure: Poison read receives SIGKILL instead of SIGBUS issue
On 7/24/2019 3:52 PM, Dan Williams wrote: On Wed, Jul 24, 2019 at 3:35 PM Jane Chu wrote: Changes in v2: - move 'tk' allocations internal to add_to_kill(), suggested by Dan; Oh, sorry if it wasn't clear, this should move to its own patch that only does the cleanup, and then the follow on fix patch becomes smaller and more straightforward. Make sense, thanks! I'll split up the patch next. thanks, -jane
[PATCH 4.19 133/271] igb: clear out skb->tstamp after reading the txtime
[ Upstream commit 1e08511d5d01884a3c9070afd52a47799312074a ]
If a packet which is utilizing the launchtime feature (via SO_TXTIME socket
option) also requests the hardware transmit timestamp, the hardware
timestamp is not delivered to the userspace. This is because the value in
skb->tstamp is mistaken as the software timestamp.
Applications, like ptp4l, request a hardware timestamp by setting the
SOF_TIMESTAMPING_TX_HARDWARE socket option. Whenever a new timestamp is
detected by the driver (this work is done in igb_ptp_tx_work() which calls
igb_ptp_tx_hwtstamps() in igb_ptp.c[1]), it will queue the timestamp in the
ERR_QUEUE for the userspace to read. When the userspace is ready, it will
issue a recvmsg() call to collect this timestamp. The problem is in this
recvmsg() call. If the skb->tstamp is not cleared out, it will be
interpreted as a software timestamp and the hardware tx timestamp will not
be successfully sent to the userspace. Look at skb_is_swtx_tstamp() and the
callee function __sock_recv_timestamp() in net/socket.c for more details.
Signed-off-by: Vedang Patel
Tested-by: Aaron Brown
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/intel/igb/igb_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 5aa083d9a6c9..ab76a5f77cd0 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -5703,6 +5703,7 @@ static void igb_tx_ctxtdesc(struct igb_ring *tx_ring,
*/
if (tx_ring->launchtime_enable) {
ts = ns_to_timespec64(first->skb->tstamp);
+ first->skb->tstamp = 0;
context_desc->seqnum_seed = cpu_to_le32(ts.tv_nsec / 32);
} else {
context_desc->seqnum_seed = 0;
--
2.20.1
[PATCH 4.19 132/271] net: mvpp2: prs: Dont override the sign bit in SRAM parser shift
[ Upstream commit 8ec3ede559956f8ad58db7b57d25ac724bab69e9 ]
The Header Parser allows identifying various fields in the packet
headers, used for various kind of filtering and classification
steps.
This is a re-entrant process, where the offset in the packet header
depends on the previous lookup results. This offset is represented in
the SRAM results of the TCAM, as a shift to be operated.
This shift can be negative in some cases, such as in IPv6 parsing.
This commit prevents overriding the sign bit when setting the shift
value, which could cause instabilities when parsing IPv6 flows.
Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network
unit")
Suggested-by: Alan Winkowski
Signed-off-by: Maxime Chevallier
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
index ae2240074d8e..5692c6087bbb 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
@@ -312,7 +312,8 @@ static void mvpp2_prs_sram_shift_set(struct mvpp2_prs_entry
*pe, int shift,
}
/* Set value */
- pe->sram[MVPP2_BIT_TO_WORD(MVPP2_PRS_SRAM_SHIFT_OFFS)] = shift &
MVPP2_PRS_SRAM_SHIFT_MASK;
+ pe->sram[MVPP2_BIT_TO_WORD(MVPP2_PRS_SRAM_SHIFT_OFFS)] |=
+ shift & MVPP2_PRS_SRAM_SHIFT_MASK;
/* Reset and set operation */
mvpp2_prs_sram_bits_clear(pe, MVPP2_PRS_SRAM_OP_SEL_SHIFT_OFFS,
--
2.20.1
[PATCH 4.19 078/271] perf/x86/intel/uncore: Handle invalid event coding for free-running counter
[ Upstream commit 543ac280b3576c0009e8c0fcd4d6bfc9978d7bd0 ]
Counting with invalid event coding for free-running counter may cause
OOPs, e.g. uncore_iio_free_running_0/event=1/.
Current code only validate the event with free-running event format,
event=0xff,umask=0xXY. Non-free-running event format never be checked
for the PMU with free-running counters.
Add generic hw_config() to check and reject the invalid event coding
for free-running PMU.
Signed-off-by: Kan Liang
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: a...@kernel.org
Cc: eran...@google.com
Fixes: 0f519f0352e3 ("perf/x86/intel/uncore: Support IIO free-running counters
on SKX")
Link:
https://lkml.kernel.org/r/1556672028-119221-2-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
---
arch/x86/events/intel/uncore.h | 10 ++
arch/x86/events/intel/uncore_snbep.c | 1 +
2 files changed, 11 insertions(+)
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index cc6dd4f78158..42fa3974c421 100644
--- a/arch/x86/events/intel/uncore.h
+++ b/arch/x86/events/intel/uncore.h
@@ -402,6 +402,16 @@ static inline bool is_freerunning_event(struct perf_event
*event)
(((cfg >> 8) & 0xff) >= UNCORE_FREERUNNING_UMASK_START);
}
+/* Check and reject invalid config */
+static inline int uncore_freerunning_hw_config(struct intel_uncore_box *box,
+ struct perf_event *event)
+{
+ if (is_freerunning_event(event))
+ return 0;
+
+ return -EINVAL;
+}
+
static inline void uncore_disable_box(struct intel_uncore_box *box)
{
if (box->pmu->type->ops->disable_box)
diff --git a/arch/x86/events/intel/uncore_snbep.c
b/arch/x86/events/intel/uncore_snbep.c
index b10e04387f38..8e4e8e423839 100644
--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -3585,6 +3585,7 @@ static struct uncore_event_desc
skx_uncore_iio_freerunning_events[] = {
static struct intel_uncore_ops skx_uncore_iio_freerunning_ops = {
.read_counter = uncore_msr_read_counter,
+ .hw_config = uncore_freerunning_hw_config,
};
static struct attribute *skx_uncore_iio_freerunning_formats_attr[] = {
--
2.20.1
Re: [PATCH 1/3] iio: imu: st_lsm6sdx: move some register definitions to sensor_settings struct
On 15.07.19 15:19, Martin Kepplinger wrote: > Move some register definitions to the per-device array of struct > st_lsm6dsx_sensor_settings in order to simplify adding new sensor > devices to the driver. > > Also, remove completely unused register definitions. > > Signed-off-by: Martin Kepplinger > --- > drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h | 6 > drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 31 ++-- > 2 files changed, 28 insertions(+), 9 deletions(-) > this series has been resent (and rebased) to be more readable: https://lore.kernel.org/linux-iio/20190725053132.9589-1-martin.kepplin...@puri.sm/ thanks, martin
[PATCH 4.19 123/271] EDAC: Fix global-out-of-bounds write when setting edac_mc_poll_msec
[ Upstream commit d8655e7630dafa88bc37f101640e39c736399771 ]
Commit 9da21b1509d8 ("EDAC: Poll timeout cannot be zero, p2") assumes
edac_mc_poll_msec to be unsigned long, but the type of the variable still
remained as int. Setting edac_mc_poll_msec can trigger out-of-bounds
write.
Reproducer:
# echo 1001 > /sys/module/edac_core/parameters/edac_mc_poll_msec
KASAN report:
BUG: KASAN: global-out-of-bounds in edac_set_poll_msec+0x140/0x150
Write of size 8 at addr b91b2d00 by task bash/1996
CPU: 1 PID: 1996 Comm: bash Not tainted 5.2.0-rc6+ #23
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30
04/01/2014
Call Trace:
dump_stack+0xca/0x13e
print_address_description.cold+0x5/0x246
__kasan_report.cold+0x75/0x9a
? edac_set_poll_msec+0x140/0x150
kasan_report+0xe/0x20
edac_set_poll_msec+0x140/0x150
? dimmdev_location_show+0x30/0x30
? vfs_lock_file+0xe0/0xe0
? _raw_spin_lock+0x87/0xe0
param_attr_store+0x1b5/0x310
? param_array_set+0x4f0/0x4f0
module_attr_store+0x58/0x80
? module_attr_show+0x80/0x80
sysfs_kf_write+0x13d/0x1a0
kernfs_fop_write+0x2bc/0x460
? sysfs_kf_bin_read+0x270/0x270
? kernfs_notify+0x1f0/0x1f0
__vfs_write+0x81/0x100
vfs_write+0x1e1/0x560
ksys_write+0x126/0x250
? __ia32_sys_read+0xb0/0xb0
? do_syscall_64+0x1f/0x390
do_syscall_64+0xc1/0x390
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7fa7caa5e970
Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44
00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 04
RSP: 002b:7fff6acfdfe8 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 0005 RCX: 7fa7caa5e970
RDX: 0005 RSI: 00e95c08 RDI: 0001
RBP: 00e95c08 R08: 7fa7cad1e760 R09: 7fa7cb36a700
R10: 0073 R11: 0246 R12: 0005
R13: 0001 R14: 7fa7cad1d600 R15: 0005
The buggy address belongs to the variable:
edac_mc_poll_msec+0x0/0x40
Memory state around the buggy address:
b91b2c00: 00 00 00 00 fa fa fa fa 00 00 00 00 fa fa fa fa
b91b2c80: 00 00 00 00 fa fa fa fa 00 00 00 00 fa fa fa fa
>b91b2d00: 04 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
^
b91b2d80: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
b91b2e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Fix it by changing the type of edac_mc_poll_msec to unsigned int.
The reason why this patch adopts unsigned int rather than unsigned long
is msecs_to_jiffies() assumes arg to be unsigned int. We can avoid
integer conversion bugs and unsigned int will be large enough for
edac_mc_poll_msec.
Reviewed-by: James Morse
Fixes: 9da21b1509d8 ("EDAC: Poll timeout cannot be zero, p2")
Signed-off-by: Eiichi Tsukata
Signed-off-by: Tony Luck
Signed-off-by: Sasha Levin
---
drivers/edac/edac_mc_sysfs.c | 16
drivers/edac/edac_module.h | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index e50610b5bd06..d4545a9222a0 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -26,7 +26,7 @@
static int edac_mc_log_ue = 1;
static int edac_mc_log_ce = 1;
static int edac_mc_panic_on_ue;
-static int edac_mc_poll_msec = 1000;
+static unsigned int edac_mc_poll_msec = 1000;
/* Getter functions for above */
int edac_mc_get_log_ue(void)
@@ -45,30 +45,30 @@ int edac_mc_get_panic_on_ue(void)
}
/* this is temporary */
-int edac_mc_get_poll_msec(void)
+unsigned int edac_mc_get_poll_msec(void)
{
return edac_mc_poll_msec;
}
static int edac_set_poll_msec(const char *val, const struct kernel_param *kp)
{
- unsigned long l;
+ unsigned int i;
int ret;
if (!val)
return -EINVAL;
- ret = kstrtoul(val, 0, &l);
+ ret = kstrtouint(val, 0, &i);
if (ret)
return ret;
- if (l < 1000)
+ if (i < 1000)
return -EINVAL;
- *((unsigned long *)kp->arg) = l;
+ *((unsigned int *)kp->arg) = i;
/* notify edac_mc engine to reset the poll period */
- edac_mc_reset_delay_period(l);
+ edac_mc_reset_delay_period(i);
return 0;
}
@@ -82,7 +82,7 @@ MODULE_PARM_DESC(edac_mc_log_ue,
module_param(edac_mc_log_ce, int, 0644);
MODULE_PARM_DESC(edac_mc_log_ce,
"Log correctable error to console: 0=off 1=on");
-module_param_call(edac_mc_poll_msec, edac_set_poll_msec, param_get_int,
+module_param_call(edac_mc_poll_msec, edac_set_poll_msec, param_get_uint,
&edac_mc_poll_msec, 0644);
MODULE_PARM_DESC(edac_mc_poll_msec, "Polling period in milliseconds");
diff --git a/drivers/edac/edac_module.h b/drivers/edac/edac_module.h
index dec88dcea036..c9f0e73872a6 100644
--- a/drivers/edac/edac_module.h
+++ b/
[PATCH 4.19 138/271] bnx2x: Prevent ptp_task to be rescheduled indefinitely
[ Upstream commit 3c91f25c2f72ba6001775a5932857c1d2131c531 ]
Currently bnx2x ptp worker tries to read a register with timestamp
information in case of TX packet timestamping and in case it fails,
the routine reschedules itself indefinitely. This was reported as a
kworker always at 100% of CPU usage, which was narrowed down to be
bnx2x ptp_task.
By following the ioctl handler, we could narrow down the problem to
an NTP tool (chrony) requesting HW timestamping from bnx2x NIC with
RX filter zeroed; this isn't reproducible for example with ptp4l
(from linuxptp) since this tool requests a supported RX filter.
It seems NIC FW timestamp mechanism cannot work well with
RX_FILTER_NONE - driver's PTP filter init routine skips a register
write to the adapter if there's not a supported filter request.
This patch addresses the problem of bnx2x ptp thread's everlasting
reschedule by retrying the register read 10 times; between the read
attempts the thread sleeps for an increasing amount of time starting
in 1ms to give FW some time to perform the timestamping. If it still
fails after all retries, we bail out in order to prevent an unbound
resource consumption from bnx2x.
The patch also adds an ethtool statistic for accounting the skipped
TX timestamp packets and it reduces the priority of timestamping
error messages to prevent log flooding. The code was tested using
both linuxptp and chrony.
Reported-and-tested-by: Przemyslaw Hausman
Suggested-by: Sudarsana Reddy Kalluru
Signed-off-by: Guilherme G. Piccoli
Acked-by: Sudarsana Reddy Kalluru
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
.../net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 5 ++-
.../ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 4 ++-
.../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 33 ++-
.../net/ethernet/broadcom/bnx2x/bnx2x_stats.h | 3 ++
4 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 5a727d4729da..e3ce29951c5e 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3858,9 +3858,12 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct
net_device *dev)
if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
if (!(bp->flags & TX_TIMESTAMPING_EN)) {
+ bp->eth_stats.ptp_skip_tx_ts++;
BNX2X_ERR("Tx timestamping was not enabled, this packet
will not be timestamped\n");
} else if (bp->ptp_tx_skb) {
- BNX2X_ERR("The device supports only a single
outstanding packet to timestamp, this packet will not be timestamped\n");
+ bp->eth_stats.ptp_skip_tx_ts++;
+ netdev_err_once(bp->dev,
+ "Device supports only a single
outstanding packet to timestamp, this packet won't be timestamped\n");
} else {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
/* schedule check for Tx timestamp */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index c428b0655c26..00f9ed93360c 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -182,7 +182,9 @@ static const struct {
{ STATS_OFFSET32(driver_filtered_tx_pkt),
4, false, "driver_filtered_tx_pkt" },
{ STATS_OFFSET32(eee_tx_lpi),
- 4, true, "Tx LPI entry count"}
+ 4, true, "Tx LPI entry count"},
+ { STATS_OFFSET32(ptp_skip_tx_ts),
+ 4, false, "ptp_skipped_tx_tstamp" },
};
#define BNX2X_NUM_STATSARRAY_SIZE(bnx2x_stats_arr)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index a585f1025a58..2c9af0f420e5 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -15244,11 +15244,24 @@ static void bnx2x_ptp_task(struct work_struct *work)
u32 val_seq;
u64 timestamp, ns;
struct skb_shared_hwtstamps shhwtstamps;
+ bool bail = true;
+ int i;
+
+ /* FW may take a while to complete timestamping; try a bit and if it's
+* still not complete, may indicate an error state - bail out then.
+*/
+ for (i = 0; i < 10; i++) {
+ /* Read Tx timestamp registers */
+ val_seq = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_SEQID :
+NIG_REG_P0_TLLH_PTP_BUF_SEQID);
+ if (val_seq & 0x1) {
+ bail = false;
+ break;
+ }
+ msleep(1 << i);
+ }
[PATCH 4.19 137/271] perf stat: Fix group lookup for metric group
[ Upstream commit 2f87f33f4226523df9c9cc28f9874ea02fcc3d3f ]
The metric group code tries to find a group it added earlier in the
evlist. Fix the lookup to handle groups with partially overlaps
correctly. When a sub string match fails and we reset the match, we have
to compare the first element again.
I also renamed the find_evsel function to find_evsel_group to make its
purpose clearer.
With the earlier changes this fixes:
Before:
% perf stat -M UPI,IPC sleep 1
...
1,032,922 uops_retired.retire_slots # 1.1 UPI
1,896,096 inst_retired.any
1,896,096 inst_retired.any
1,177,254 cpu_clk_unhalted.thread
After:
% perf stat -M UPI,IPC sleep 1
...
1,013,193 uops_retired.retire_slots # 1.1 UPI
932,033 inst_retired.any
932,033 inst_retired.any # 0.9 IPC
1,091,245 cpu_clk_unhalted.thread
Signed-off-by: Andi Kleen
Acked-by: Jiri Olsa
Cc: Kan Liang
Fixes: b18f3e365019 ("perf stat: Support JSON metrics in perf stat")
Link: http://lkml.kernel.org/r/20190624193711.35241-4-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/util/metricgroup.c | 47 ++-
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index a28f9b5cc4ff..8b3dafe3fac3 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -94,26 +94,49 @@ struct egroup {
const char *metric_expr;
};
-static struct perf_evsel *find_evsel(struct perf_evlist *perf_evlist,
-const char **ids,
-int idnum,
-struct perf_evsel **metric_events)
+static bool record_evsel(int *ind, struct perf_evsel **start,
+int idnum,
+struct perf_evsel **metric_events,
+struct perf_evsel *ev)
+{
+ metric_events[*ind] = ev;
+ if (*ind == 0)
+ *start = ev;
+ if (++*ind == idnum) {
+ metric_events[*ind] = NULL;
+ return true;
+ }
+ return false;
+}
+
+static struct perf_evsel *find_evsel_group(struct perf_evlist *perf_evlist,
+ const char **ids,
+ int idnum,
+ struct perf_evsel **metric_events)
{
struct perf_evsel *ev, *start = NULL;
int ind = 0;
evlist__for_each_entry (perf_evlist, ev) {
+ if (ev->collect_stat)
+ continue;
if (!strcmp(ev->name, ids[ind])) {
- metric_events[ind] = ev;
- if (ind == 0)
- start = ev;
- if (++ind == idnum) {
- metric_events[ind] = NULL;
+ if (record_evsel(&ind, &start, idnum,
+metric_events, ev))
return start;
- }
} else {
+ /*
+* We saw some other event that is not
+* in our list of events. Discard
+* the whole match and start again.
+*/
ind = 0;
start = NULL;
+ if (!strcmp(ev->name, ids[ind])) {
+ if (record_evsel(&ind, &start, idnum,
+metric_events, ev))
+ return start;
+ }
}
}
/*
@@ -143,8 +166,8 @@ static int metricgroup__setup_events(struct list_head
*groups,
ret = -ENOMEM;
break;
}
- evsel = find_evsel(perf_evlist, eg->ids, eg->idnum,
- metric_events);
+ evsel = find_evsel_group(perf_evlist, eg->ids, eg->idnum,
+metric_events);
if (!evsel) {
pr_debug("Cannot resolve %s: %s\n",
eg->metric_name, eg->metric_expr);
--
2.20.1
[PATCH 4.19 125/271] bcache: check CACHE_SET_IO_DISABLE bit in bch_journal()
[ Upstream commit 383ff2183ad16a8842d1fbd9dd3e1cbd66813e64 ] When too many I/O errors happen on cache set and CACHE_SET_IO_DISABLE bit is set, bch_journal() may continue to work because the journaling bkey might be still in write set yet. The caller of bch_journal() may believe the journal still work but the truth is in-memory journal write set won't be written into cache device any more. This behavior may introduce potential inconsistent metadata status. This patch checks CACHE_SET_IO_DISABLE bit at the head of bch_journal(), if the bit is set, bch_journal() returns NULL immediately to notice caller to know journal does not work. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- drivers/md/bcache/journal.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/md/bcache/journal.c b/drivers/md/bcache/journal.c index f880e5eba8dd..8d4d63b51553 100644 --- a/drivers/md/bcache/journal.c +++ b/drivers/md/bcache/journal.c @@ -810,6 +810,10 @@ atomic_t *bch_journal(struct cache_set *c, struct journal_write *w; atomic_t *ret; + /* No journaling if CACHE_SET_IO_DISABLE set already */ + if (unlikely(test_bit(CACHE_SET_IO_DISABLE, &c->flags))) + return NULL; + if (!CACHE_SYNC(&c->sb)) return NULL; -- 2.20.1
[PATCH 4.19 143/271] bonding: validate ip header before check IPPROTO_IGMP
[ Upstream commit 9d1bc24b52fb8c5d859f9a47084bf1179470e04c ]
bond_xmit_roundrobin() checks for IGMP packets but it parses
the IP header even before checking skb->protocol.
We should validate the IP header with pskb_may_pull() before
using iph->protocol.
Reported-and-tested-by: syzbot+e5be16aa39ad6e755...@syzkaller.appspotmail.com
Fixes: a2fd940f4cff ("bonding: fix broken multicast with round-robin mode")
Cc: Jay Vosburgh
Cc: Veaceslav Falico
Cc: Andy Gospodarek
Signed-off-by: Cong Wang
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/bonding/bond_main.c | 37 -
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 7e162fff01ab..be0b785becd0 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3852,8 +3852,8 @@ static netdev_tx_t bond_xmit_roundrobin(struct sk_buff
*skb,
struct net_device *bond_dev)
{
struct bonding *bond = netdev_priv(bond_dev);
- struct iphdr *iph = ip_hdr(skb);
struct slave *slave;
+ int slave_cnt;
u32 slave_id;
/* Start with the curr_active_slave that joined the bond as the
@@ -3862,23 +3862,32 @@ static netdev_tx_t bond_xmit_roundrobin(struct sk_buff
*skb,
* send the join/membership reports. The curr_active_slave found
* will send all of this type of traffic.
*/
- if (iph->protocol == IPPROTO_IGMP && skb->protocol == htons(ETH_P_IP)) {
- slave = rcu_dereference(bond->curr_active_slave);
- if (slave)
- bond_dev_queue_xmit(bond, skb, slave->dev);
- else
- bond_xmit_slave_id(bond, skb, 0);
- } else {
- int slave_cnt = READ_ONCE(bond->slave_cnt);
+ if (skb->protocol == htons(ETH_P_IP)) {
+ int noff = skb_network_offset(skb);
+ struct iphdr *iph;
- if (likely(slave_cnt)) {
- slave_id = bond_rr_gen_slave_id(bond);
- bond_xmit_slave_id(bond, skb, slave_id % slave_cnt);
- } else {
- bond_tx_drop(bond_dev, skb);
+ if (unlikely(!pskb_may_pull(skb, noff + sizeof(*iph
+ goto non_igmp;
+
+ iph = ip_hdr(skb);
+ if (iph->protocol == IPPROTO_IGMP) {
+ slave = rcu_dereference(bond->curr_active_slave);
+ if (slave)
+ bond_dev_queue_xmit(bond, skb, slave->dev);
+ else
+ bond_xmit_slave_id(bond, skb, 0);
+ return NETDEV_TX_OK;
}
}
+non_igmp:
+ slave_cnt = READ_ONCE(bond->slave_cnt);
+ if (likely(slave_cnt)) {
+ slave_id = bond_rr_gen_slave_id(bond);
+ bond_xmit_slave_id(bond, skb, slave_id % slave_cnt);
+ } else {
+ bond_tx_drop(bond_dev, skb);
+ }
return NETDEV_TX_OK;
}
--
2.20.1
[PATCH 4.19 148/271] Bluetooth: Add new 13d3:3501 QCA_ROME device
[ Upstream commit 881cec4f6b4da78e54b73c046a60f39315964c7d ]
Without the QCA ROME setup routine this adapter fails to establish a SCO
connection.
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3501 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
Signed-off-by: João Paulo Rechi Vita
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
---
drivers/bluetooth/btusb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index f494fa30a912..75cf605f54e5 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -279,6 +279,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x04ca, 0x301a), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x13d3, 0x3491), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x13d3, 0x3496), .driver_info = BTUSB_QCA_ROME },
+ { USB_DEVICE(0x13d3, 0x3501), .driver_info = BTUSB_QCA_ROME },
/* Broadcom BCM2035 */
{ USB_DEVICE(0x0a5c, 0x2009), .driver_info = BTUSB_BCM92035 },
--
2.20.1
[PATCH 4.19 177/271] crypto: crypto4xx - fix AES CTR blocksize value
From: Christian Lamparter
commit bfa2ba7d9e6b20aca82b99e6842fe18842ae3a0f upstream.
This patch fixes a issue with crypto4xx's ctr(aes) that was
discovered by libcapi's kcapi-enc-test.sh test.
The some of the ctr(aes) encryptions test were failing on the
non-power-of-two test:
kcapi-enc - Error: encryption failed with error 0
kcapi-enc - Error: decryption failed with error 0
[FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits):
original file (1d100e..cc96184c) and generated file (e3b0c442..1b7852b855)
[FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits)
(openssl generated CT): original file (e3b0..5) and generated file (3..8e)
[PASSED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits)
(openssl generated PT)
[FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (password):
original file (1d1..84c) and generated file (e3b..852b855)
But the 16, 32, 512, 65536 tests always worked.
Thankfully, this isn't a hidden hardware problem like previously,
instead this turned out to be a copy and paste issue.
With this patch, all the tests are passing with and
kcapi-enc-test.sh gives crypto4xx's a clean bill of health:
"Number of failures: 0" :).
Cc: sta...@vger.kernel.org
Fixes: 98e87e3d933b ("crypto: crypto4xx - add aes-ctr support")
Fixes: f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB
offloads")
Signed-off-by: Christian Lamparter
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
drivers/crypto/amcc/crypto4xx_core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -1186,7 +1186,7 @@ static struct crypto4xx_alg_common crypt
.cra_flags = CRYPTO_ALG_NEED_FALLBACK |
CRYPTO_ALG_ASYNC |
CRYPTO_ALG_KERN_DRIVER_ONLY,
- .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_blocksize = 1,
.cra_ctxsize = sizeof(struct crypto4xx_ctx),
.cra_module = THIS_MODULE,
},
@@ -1206,7 +1206,7 @@ static struct crypto4xx_alg_common crypt
.cra_priority = CRYPTO4XX_CRYPTO_PRIORITY,
.cra_flags = CRYPTO_ALG_ASYNC |
CRYPTO_ALG_KERN_DRIVER_ONLY,
- .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_blocksize = 1,
.cra_ctxsize = sizeof(struct crypto4xx_ctx),
.cra_module = THIS_MODULE,
},
[PATCH 4.19 145/271] tools: bpftool: Fix json dump crash on powerpc
[ Upstream commit aa52bcbe0e72fac36b1862db08b9c09c4caefae3 ]
Michael reported crash with by bpf program in json mode on powerpc:
# bpftool prog -p dump jited id 14
[{
"name": "0xda9aa760",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
Segmentation fault (core dumped)
The code is assuming char pointers in format, which is not always
true at least for powerpc. Fixing this by dumping the whole string
into buffer based on its format.
Please note that libopcodes code does not check return values from
fprintf callback, but as per Jakub suggestion returning -1 on allocation
failure so we do the best effort to propagate the error.
Fixes: 107f041212c1 ("tools: bpftool: add JSON output for `bpftool prog dump
jited *` command")
Reported-by: Michael Petlan
Signed-off-by: Jiri Olsa
Reviewed-by: Quentin Monnet
Reviewed-by: Jakub Kicinski
Signed-off-by: Daniel Borkmann
Signed-off-by: Sasha Levin
---
tools/bpf/bpftool/jit_disasm.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tools/bpf/bpftool/jit_disasm.c b/tools/bpf/bpftool/jit_disasm.c
index 87439320ef70..73d7252729fa 100644
--- a/tools/bpf/bpftool/jit_disasm.c
+++ b/tools/bpf/bpftool/jit_disasm.c
@@ -10,6 +10,8 @@
* Licensed under the GNU General Public License, version 2.0 (GPLv2)
*/
+#define _GNU_SOURCE
+#include
#include
#include
#include
@@ -51,11 +53,13 @@ static int fprintf_json(void *out, const char *fmt, ...)
char *s;
va_start(ap, fmt);
+ if (vasprintf(&s, fmt, ap) < 0)
+ return -1;
+ va_end(ap);
+
if (!oper_count) {
int i;
- s = va_arg(ap, char *);
-
/* Strip trailing spaces */
i = strlen(s) - 1;
while (s[i] == ' ')
@@ -68,11 +72,10 @@ static int fprintf_json(void *out, const char *fmt, ...)
} else if (!strcmp(fmt, ",")) {
/* Skip */
} else {
- s = va_arg(ap, char *);
jsonw_string(json_wtr, s);
oper_count++;
}
- va_end(ap);
+ free(s);
return 0;
}
--
2.20.1
[PATCH 4.19 127/271] bcache: check c->gc_thread by IS_ERR_OR_NULL in cache_set_flush()
[ Upstream commit b387e9b58679c60f5b1e4313939bd4878204fc37 ] When system memory is in heavy pressure, bch_gc_thread_start() from run_cache_set() may fail due to out of memory. In such condition, c->gc_thread is assigned to -ENOMEM, not NULL pointer. Then in following failure code path bch_cache_set_error(), when cache_set_flush() gets called, the code piece to stop c->gc_thread is broken, if (!IS_ERR_OR_NULL(c->gc_thread)) kthread_stop(c->gc_thread); And KASAN catches such NULL pointer deference problem, with the warning information: [ 561.207881] == [ 561.207900] BUG: KASAN: null-ptr-deref in kthread_stop+0x3b/0x440 [ 561.207904] Write of size 4 at addr 001c by task kworker/15:1/313 [ 561.207913] CPU: 15 PID: 313 Comm: kworker/15:1 Tainted: GW 5.0.0-vanilla+ #3 [ 561.207916] Hardware name: Lenovo ThinkSystem SR650 -[7X05CTO1WW]-/-[7X05CTO1WW]-, BIOS -[IVE136T-2.10]- 03/22/2019 [ 561.207935] Workqueue: events cache_set_flush [bcache] [ 561.207940] Call Trace: [ 561.207948] dump_stack+0x9a/0xeb [ 561.207955] ? kthread_stop+0x3b/0x440 [ 561.207960] ? kthread_stop+0x3b/0x440 [ 561.207965] kasan_report+0x176/0x192 [ 561.207973] ? kthread_stop+0x3b/0x440 [ 561.207981] kthread_stop+0x3b/0x440 [ 561.207995] cache_set_flush+0xd4/0x6d0 [bcache] [ 561.208008] process_one_work+0x856/0x1620 [ 561.208015] ? find_held_lock+0x39/0x1d0 [ 561.208028] ? drain_workqueue+0x380/0x380 [ 561.208048] worker_thread+0x87/0xb80 [ 561.208058] ? __kthread_parkme+0xb6/0x180 [ 561.208067] ? process_one_work+0x1620/0x1620 [ 561.208072] kthread+0x326/0x3e0 [ 561.208079] ? kthread_create_worker_on_cpu+0xc0/0xc0 [ 561.208090] ret_from_fork+0x3a/0x50 [ 561.208110] == [ 561.208113] Disabling lock debugging due to kernel taint [ 561.208115] irq event stamp: 11800231 [ 561.208126] hardirqs last enabled at (11800231): [] do_syscall_64+0x18/0x410 [ 561.208127] BUG: unable to handle kernel NULL pointer dereference at 001c [ 561.208129] #PF error: [WRITE] [ 561.312253] hardirqs last disabled at (11800230): [] trace_hardirqs_off_thunk+0x1a/0x1c [ 561.312259] softirqs last enabled at (11799832): [] __do_softirq+0x5c7/0x8c3 [ 561.405975] PGD 0 P4D 0 [ 561.442494] softirqs last disabled at (11799821): [] irq_exit+0x1ac/0x1e0 [ 561.791359] Oops: 0002 [#1] SMP KASAN NOPTI [ 561.791362] CPU: 15 PID: 313 Comm: kworker/15:1 Tainted: GB W 5.0.0-vanilla+ #3 [ 561.791363] Hardware name: Lenovo ThinkSystem SR650 -[7X05CTO1WW]-/-[7X05CTO1WW]-, BIOS -[IVE136T-2.10]- 03/22/2019 [ 561.791371] Workqueue: events cache_set_flush [bcache] [ 561.791374] RIP: 0010:kthread_stop+0x3b/0x440 [ 561.791376] Code: 00 00 65 8b 05 26 d5 e0 7c 89 c0 48 0f a3 05 ec aa df 02 0f 82 dc 02 00 00 4c 8d 63 20 be 04 00 00 00 4c 89 e7 e8 65 c5 53 00 ff 43 20 48 8d 7b 24 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 [ 561.791377] RSP: 0018:88872fc8fd10 EFLAGS: 00010286 [ 561.838895] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838916] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838934] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838948] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838966] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838979] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 561.838996] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 563.067028] RAX: RBX: fffc RCX: 832dd314 [ 563.067030] RDX: RSI: 0004 RDI: 0297 [ 563.067032] RBP: 88872fc8fe88 R08: fbfff0b8213d R09: fbfff0b8213d [ 563.067034] R10: 0001 R11: fbfff0b8213c R12: 001c [ 563.408618] R13: 88dc61cc0f68 R14: 888102b94900 R15: 88dc61cc0f68 [ 563.408620] FS: () GS:888f7dc0() knlGS: [ 563.408622] CS: 0010 DS: ES: CR0: 80050033 [ 563.408623] CR2: 001c CR3: 000f48a1a004 CR4: 007606e0 [ 563.408625] DR0: DR1: DR2: [ 563.408627] DR3: DR6: fffe0ff0 DR7: 0400 [ 563.904795] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 563.915796] PKRU: 5554 [ 563.915797] Call Trace: [ 563.915807] cache_set_flush+0xd4/0x6d0 [bcache] [ 563.915812] process_one_work+0x856/0x1620 [ 564.001226] bcache: bch_count_io_errors() nvme0n1: IO error on writing btree. [ 564.033563] ? find_held_lock+0x39/0x1d0 [ 564.033567] ? drain_workqueue+0x380/0x380 [ 564.033574] worker_thread+0x87/0xb80 [ 564.062823] bcache: bch_count_io_errors() nvme0n1: IO e
[PATCH 4.19 154/271] gtp: fix suspicious RCU usage
[ Upstream commit e198987e7dd7d3645a53875151cd6f8fc425b706 ]
gtp_encap_enable_socket() and gtp_encap_destroy() are not protected
by rcu_read_lock(). and it's not safe to write sk->sk_user_data.
This patch make these functions to use lock_sock() instead of
rcu_dereference_sk_user_data().
Test commands:
gtp-link add gtp1
Splat looks like:
[ 83.238315] =
[ 83.239127] WARNING: suspicious RCU usage
[ 83.239702] 5.2.0-rc6+ #49 Not tainted
[ 83.240268] -
[ 83.241205] drivers/net/gtp.c:799 suspicious rcu_dereference_check() usage!
[ 83.243828]
[ 83.243828] other info that might help us debug this:
[ 83.243828]
[ 83.246325]
[ 83.246325] rcu_scheduler_active = 2, debug_locks = 1
[ 83.247314] 1 lock held by gtp-link/1008:
[ 83.248523] #0: 17772c7f (rtnl_mutex){+.+.}, at:
__rtnl_newlink+0x5f5/0x11b0
[ 83.251503]
[ 83.251503] stack backtrace:
[ 83.252173] CPU: 0 PID: 1008 Comm: gtp-link Not tainted 5.2.0-rc6+ #49
[ 83.253271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[ 83.254562] Call Trace:
[ 83.254995] dump_stack+0x7c/0xbb
[ 83.255567] gtp_encap_enable_socket+0x2df/0x360 [gtp]
[ 83.256415] ? gtp_find_dev+0x1a0/0x1a0 [gtp]
[ 83.257161] ? memset+0x1f/0x40
[ 83.257843] gtp_newlink+0x90/0xa21 [gtp]
[ 83.258497] ? __netlink_ns_capable+0xc3/0xf0
[ 83.259260] __rtnl_newlink+0xb9f/0x11b0
[ 83.260022] ? rtnl_link_unregister+0x230/0x230
[ ... ]
Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional")
Signed-off-by: Taehee Yoo
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/gtp.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 83488f2bf7a0..f45a806b6c06 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -293,12 +293,14 @@ static void gtp_encap_destroy(struct sock *sk)
{
struct gtp_dev *gtp;
- gtp = rcu_dereference_sk_user_data(sk);
+ lock_sock(sk);
+ gtp = sk->sk_user_data;
if (gtp) {
udp_sk(sk)->encap_type = 0;
rcu_assign_sk_user_data(sk, NULL);
sock_put(sk);
}
+ release_sock(sk);
}
static void gtp_encap_disable_sock(struct sock *sk)
@@ -800,7 +802,8 @@ static struct sock *gtp_encap_enable_socket(int fd, int
type,
goto out_sock;
}
- if (rcu_dereference_sk_user_data(sock->sk)) {
+ lock_sock(sock->sk);
+ if (sock->sk->sk_user_data) {
sk = ERR_PTR(-EBUSY);
goto out_sock;
}
@@ -816,6 +819,7 @@ static struct sock *gtp_encap_enable_socket(int fd, int
type,
setup_udp_tunnel_sock(sock_net(sock->sk), sock, &tuncfg);
out_sock:
+ release_sock(sock->sk);
sockfd_put(sock);
return sk;
}
--
2.20.1
[PATCH 4.19 156/271] gtp: fix use-after-free in gtp_encap_destroy()
[ Upstream commit 1788b8569f5de27da09087fa3f6580d2aa04cc75 ]
gtp_encap_destroy() is called twice.
1. When interface is deleted.
2. When udp socket is destroyed.
either gtp->sk0 or gtp->sk1u could be freed by sock_put() in
gtp_encap_destroy(). so, when gtp_encap_destroy() is called again,
it would uses freed sk pointer.
patch makes gtp_encap_destroy() to set either gtp->sk0 or gtp->sk1u to
null. in addition, both gtp->sk0 and gtp->sk1u pointer are protected
by rtnl_lock. so, rtnl_lock() is added.
Test command:
gtp-link add gtp1 &
killall gtp-link
ip link del gtp1
Splat looks like:
[ 83.182767] BUG: KASAN: use-after-free in __lock_acquire+0x3a20/0x46a0
[ 83.184128] Read of size 8 at addr 8880cc7d5360 by task ip/1008
[ 83.185567] CPU: 1 PID: 1008 Comm: ip Not tainted 5.2.0-rc6+ #50
[ 83.188469] Call Trace:
[ ... ]
[ 83.200126] lock_acquire+0x141/0x380
[ 83.200575] ? lock_sock_nested+0x3a/0xf0
[ 83.201069] _raw_spin_lock_bh+0x38/0x70
[ 83.201551] ? lock_sock_nested+0x3a/0xf0
[ 83.202044] lock_sock_nested+0x3a/0xf0
[ 83.202520] gtp_encap_destroy+0x18/0xe0 [gtp]
[ 83.203065] gtp_encap_disable.isra.14+0x13/0x50 [gtp]
[ 83.203687] gtp_dellink+0x56/0x170 [gtp]
[ 83.204190] rtnl_delete_link+0xb4/0x100
[ ... ]
[ 83.236513] Allocated by task 976:
[ 83.236925] save_stack+0x19/0x80
[ 83.237332] __kasan_kmalloc.constprop.3+0xa0/0xd0
[ 83.237894] kmem_cache_alloc+0xd8/0x280
[ 83.238360] sk_prot_alloc.isra.42+0x50/0x200
[ 83.238874] sk_alloc+0x32/0x940
[ 83.239264] inet_create+0x283/0xc20
[ 83.239684] __sock_create+0x2dd/0x540
[ 83.240136] __sys_socket+0xca/0x1a0
[ 83.240550] __x64_sys_socket+0x6f/0xb0
[ 83.240998] do_syscall_64+0x9c/0x450
[ 83.241466] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 83.242061]
[ 83.242249] Freed by task 0:
[ 83.242616] save_stack+0x19/0x80
[ 83.243013] __kasan_slab_free+0x111/0x150
[ 83.243498] kmem_cache_free+0x89/0x250
[ 83.24] __sk_destruct+0x38f/0x5a0
[ 83.245366] rcu_core+0x7e9/0x1c20
[ 83.245766] __do_softirq+0x213/0x8fa
Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional")
Signed-off-by: Taehee Yoo
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/gtp.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 6f1ad7ccaea6..61e9b288d2dc 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -289,13 +289,17 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp,
struct sk_buff *skb)
return gtp_rx(pctx, skb, hdrlen, gtp->role);
}
-static void gtp_encap_destroy(struct sock *sk)
+static void __gtp_encap_destroy(struct sock *sk)
{
struct gtp_dev *gtp;
lock_sock(sk);
gtp = sk->sk_user_data;
if (gtp) {
+ if (gtp->sk0 == sk)
+ gtp->sk0 = NULL;
+ else
+ gtp->sk1u = NULL;
udp_sk(sk)->encap_type = 0;
rcu_assign_sk_user_data(sk, NULL);
sock_put(sk);
@@ -303,12 +307,19 @@ static void gtp_encap_destroy(struct sock *sk)
release_sock(sk);
}
+static void gtp_encap_destroy(struct sock *sk)
+{
+ rtnl_lock();
+ __gtp_encap_destroy(sk);
+ rtnl_unlock();
+}
+
static void gtp_encap_disable_sock(struct sock *sk)
{
if (!sk)
return;
- gtp_encap_destroy(sk);
+ __gtp_encap_destroy(sk);
}
static void gtp_encap_disable(struct gtp_dev *gtp)
@@ -1047,6 +1058,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct
genl_info *info)
return -EINVAL;
}
+ rtnl_lock();
rcu_read_lock();
gtp = gtp_find_dev(sock_net(skb->sk), info->attrs);
@@ -1071,6 +1083,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct
genl_info *info)
out_unlock:
rcu_read_unlock();
+ rtnl_unlock();
return err;
}
--
2.20.1
[PATCH 4.19 167/271] Revert "scsi: ncr5380: Increase register polling limit"
From: Finn Thain
commit 25fcf94a2fa89dd3e73e965ebb0b38a2a4f72aa4 upstream.
This reverts commit 4822827a69d7cd3bc5a07b7637484ebd2cf88db6.
The purpose of that commit was to suppress a timeout warning message which
appeared to be caused by target latency. But suppressing the warning is
undesirable as the warning may indicate a messed up transfer count.
Another problem with that commit is that 15 ms is too long to keep
interrupts disabled as interrupt latency can cause system clock drift and
other problems.
Cc: Michael Schmitz
Cc: sta...@vger.kernel.org
Fixes: 4822827a69d7 ("scsi: ncr5380: Increase register polling limit")
Signed-off-by: Finn Thain
Tested-by: Stan Johnson
Tested-by: Michael Schmitz
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/NCR5380.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -235,7 +235,7 @@ struct NCR5380_cmd {
#define NCR5380_PIO_CHUNK_SIZE 256
/* Time limit (ms) to poll registers when IRQs are disabled, e.g. during PDMA
*/
-#define NCR5380_REG_POLL_TIME 15
+#define NCR5380_REG_POLL_TIME 10
static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
{
[PATCH 4.19 149/271] Bluetooth: 6lowpan: search for destination address in all peers
[ Upstream commit b188b03270b7f8568fc714101ce82fbf5e811c5a ]
Handle overlooked case where the target address is assigned to a peer
and neither route nor gateway exist.
For one peer, no checks are performed to see if it is meant to receive
packets for a given address.
As soon as there is a second peer however, checks are performed
to deal with routes and gateways for handling complex setups with
multiple hops to a target address.
This logic assumed that no route and no gateway imply that the
destination address can not be reached, which is false in case of a
direct peer.
Acked-by: Jukka Rissanen
Tested-by: Michael Scott
Signed-off-by: Josua Mayer
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
---
net/bluetooth/6lowpan.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 4e2576fc0c59..357475cceec6 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -187,10 +187,16 @@ static inline struct lowpan_peer *peer_lookup_dst(struct
lowpan_btle_dev *dev,
}
if (!rt) {
- nexthop = &lowpan_cb(skb)->gw;
-
- if (ipv6_addr_any(nexthop))
- return NULL;
+ if (ipv6_addr_any(&lowpan_cb(skb)->gw)) {
+ /* There is neither route nor gateway,
+* probably the destination is a direct peer.
+*/
+ nexthop = daddr;
+ } else {
+ /* There is a known gateway
+*/
+ nexthop = &lowpan_cb(skb)->gw;
+ }
} else {
nexthop = rt6_nexthop(rt, daddr);
--
2.20.1
[PATCH 4.19 126/271] bcache: acquire bch_register_lock later in cached_dev_free()
[ Upstream commit 80265d8dfd77792e133793cef44a21323aac2908 ]
When enable lockdep engine, a lockdep warning can be observed when
reboot or shutdown system,
[ 3142.764557][T1] bcache: bcache_reboot() Stopping all devices:
[ 3142.776265][ T2649]
[ 3142.777159][ T2649] ==
[ 3142.780039][ T2649] WARNING: possible circular locking dependency detected
[ 3142.782869][ T2649] 5.2.0-rc4-lp151.20-default+ #1 Tainted: GW
[ 3142.785684][ T2649] --
[ 3142.788479][ T2649] kworker/3:67/2649 is trying to acquire lock:
[ 3142.790738][ T2649] aaf02291
((wq_completion)bcache_writeback_wq){+.+.}, at: flush_workqueue+0x87/0x4c0
[ 3142.794678][ T2649]
[ 3142.794678][ T2649] but task is already holding lock:
[ 3142.797402][ T2649] 4fcf89c5 (&bch_register_lock){+.+.}, at:
cached_dev_free+0x17/0x120 [bcache]
[ 3142.801462][ T2649]
[ 3142.801462][ T2649] which lock already depends on the new lock.
[ 3142.801462][ T2649]
[ 3142.805277][ T2649]
[ 3142.805277][ T2649] the existing dependency chain (in reverse order) is:
[ 3142.808902][ T2649]
[ 3142.808902][ T2649] -> #2 (&bch_register_lock){+.+.}:
[ 3142.812396][ T2649]__mutex_lock+0x7a/0x9d0
[ 3142.814184][ T2649]cached_dev_free+0x17/0x120 [bcache]
[ 3142.816415][ T2649]process_one_work+0x2a4/0x640
[ 3142.818413][ T2649]worker_thread+0x39/0x3f0
[ 3142.820276][ T2649]kthread+0x125/0x140
[ 3142.822061][ T2649]ret_from_fork+0x3a/0x50
[ 3142.823965][ T2649]
[ 3142.823965][ T2649] -> #1 ((work_completion)(&cl->work)#2){+.+.}:
[ 3142.827244][ T2649]process_one_work+0x277/0x640
[ 3142.829160][ T2649]worker_thread+0x39/0x3f0
[ 3142.830958][ T2649]kthread+0x125/0x140
[ 3142.832674][ T2649]ret_from_fork+0x3a/0x50
[ 3142.834915][ T2649]
[ 3142.834915][ T2649] -> #0 ((wq_completion)bcache_writeback_wq){+.+.}:
[ 3142.838121][ T2649]lock_acquire+0xb4/0x1c0
[ 3142.840025][ T2649]flush_workqueue+0xae/0x4c0
[ 3142.842035][ T2649]drain_workqueue+0xa9/0x180
[ 3142.844042][ T2649]destroy_workqueue+0x17/0x250
[ 3142.846142][ T2649]cached_dev_free+0x52/0x120 [bcache]
[ 3142.848530][ T2649]process_one_work+0x2a4/0x640
[ 3142.850663][ T2649]worker_thread+0x39/0x3f0
[ 3142.852464][ T2649]kthread+0x125/0x140
[ 3142.854106][ T2649]ret_from_fork+0x3a/0x50
[ 3142.855880][ T2649]
[ 3142.855880][ T2649] other info that might help us debug this:
[ 3142.855880][ T2649]
[ 3142.859663][ T2649] Chain exists of:
[ 3142.859663][ T2649] (wq_completion)bcache_writeback_wq -->
(work_completion)(&cl->work)#2 --> &bch_register_lock
[ 3142.859663][ T2649]
[ 3142.865424][ T2649] Possible unsafe locking scenario:
[ 3142.865424][ T2649]
[ 3142.868022][ T2649]CPU0CPU1
[ 3142.869885][ T2649]
[ 3142.871751][ T2649] lock(&bch_register_lock);
[ 3142.873379][ T2649]
lock((work_completion)(&cl->work)#2);
[ 3142.876399][ T2649]lock(&bch_register_lock);
[ 3142.879727][ T2649] lock((wq_completion)bcache_writeback_wq);
[ 3142.882064][ T2649]
[ 3142.882064][ T2649] *** DEADLOCK ***
[ 3142.882064][ T2649]
[ 3142.885060][ T2649] 3 locks held by kworker/3:67/2649:
[ 3142.887245][ T2649] #0: e774cdd0 ((wq_completion)events){+.+.}, at:
process_one_work+0x21e/0x640
[ 3142.890815][ T2649] #1: f7df89da
((work_completion)(&cl->work)#2){+.+.}, at: process_one_work+0x21e/0x640
[ 3142.894884][ T2649] #2: 4fcf89c5 (&bch_register_lock){+.+.}, at:
cached_dev_free+0x17/0x120 [bcache]
[ 3142.898797][ T2649]
[ 3142.898797][ T2649] stack backtrace:
[ 3142.900961][ T2649] CPU: 3 PID: 2649 Comm: kworker/3:67 Tainted: GW
5.2.0-rc4-lp151.20-default+ #1
[ 3142.904789][ T2649] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 04/13/2018
[ 3142.909168][ T2649] Workqueue: events cached_dev_free [bcache]
[ 3142.911422][ T2649] Call Trace:
[ 3142.912656][ T2649] dump_stack+0x85/0xcb
[ 3142.914181][ T2649] print_circular_bug+0x19a/0x1f0
[ 3142.916193][ T2649] __lock_acquire+0x16cd/0x1850
[ 3142.917936][ T2649] ? __lock_acquire+0x6a8/0x1850
[ 3142.919704][ T2649] ? lock_acquire+0xb4/0x1c0
[ 3142.921335][ T2649] ? find_held_lock+0x34/0xa0
[ 3142.923052][ T2649] lock_acquire+0xb4/0x1c0
[ 3142.924635][ T2649] ? flush_workqueue+0x87/0x4c0
[ 3142.926375][ T2649] flush_workqueue+0xae/0x4c0
[ 3142.928047][ T2649] ? flush_workqueue+0x87/0x4c0
[ 3142.929824][ T2649] ? drain_workqueue+0xa9/0x180
[ 3142.931686][ T2649] drain_workqueue+0xa9/0x180
[ 3142.933534][ T2649] destroy_workqueue+0x17/0x250
[ 3142.935787][ T2649] cached_dev_free+0x52/0x120 [bcache]
[ 3142.937795][ T2649] process_one_work+0x2a4/0x640
[ 3142.939803][ T2649] worker_thread+0x39/0x3f0
[ 314
[PATCH 4.19 189/271] Input: gtco - bounds check collection indent level
From: Grant Hernandez
commit 2a017fd82c5402b3c8df5e3d6e5165d9e6147dc1 upstream.
The GTCO tablet input driver configures itself from an HID report sent
via USB during the initial enumeration process. Some debugging messages
are generated during the parsing. A debugging message indentation
counter is not bounds checked, leading to the ability for a specially
crafted HID report to cause '-' and null bytes be written past the end
of the indentation array. As long as the kernel has CONFIG_DYNAMIC_DEBUG
enabled, this code will not be optimized out. This was discovered
during code review after a previous syzkaller bug was found in this
driver.
Signed-off-by: Grant Hernandez
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/input/tablet/gtco.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
--- a/drivers/input/tablet/gtco.c
+++ b/drivers/input/tablet/gtco.c
@@ -78,6 +78,7 @@ Scott Hill sh...@gtcocalcomp.com
/* Max size of a single report */
#define REPORT_MAX_SIZE 10
+#define MAX_COLLECTION_LEVELS 10
/* Bitmask whether pen is in range */
@@ -223,8 +224,7 @@ static void parse_hid_report_descriptor(
char maintype = 'x';
char globtype[12];
int indent = 0;
- char indentstr[10] = "";
-
+ char indentstr[MAX_COLLECTION_LEVELS + 1] = { 0 };
dev_dbg(ddev, "==>>PARSE<<==\n");
@@ -350,6 +350,13 @@ static void parse_hid_report_descriptor(
case TAG_MAIN_COL_START:
maintype = 'S';
+ if (indent == MAX_COLLECTION_LEVELS) {
+ dev_err(ddev, "Collection level %d
would exceed limit of %d\n",
+ indent + 1,
+ MAX_COLLECTION_LEVELS);
+ break;
+ }
+
if (data == 0) {
dev_dbg(ddev, "==>>
Physical\n");
strcpy(globtype, "Physical");
@@ -369,8 +376,15 @@ static void parse_hid_report_descriptor(
break;
case TAG_MAIN_COL_END:
- dev_dbg(ddev, "<<==\n");
maintype = 'E';
+
+ if (indent == 0) {
+ dev_err(ddev, "Collection level already
at zero\n");
+ break;
+ }
+
+ dev_dbg(ddev, "<<==\n");
+
indent--;
for (x = 0; x < indent; x++)
indentstr[x] = '-';
[PATCH 4.19 187/271] bcache: fix mistaken sysfs entry for io_error counter
From: Coly Li
commit 5461999848e0462c14f306a62923d22de820a59c upstream.
In bch_cached_dev_files[] from driver/md/bcache/sysfs.c, sysfs_errors is
incorrectly inserted in. The correct entry should be sysfs_io_errors.
This patch fixes the problem and now I/O errors of cached device can be
read from /sys/block/bcache/bcache/io_errors.
Fixes: c7b7bd07404c5 ("bcache: add io_disable to struct cached_dev")
Signed-off-by: Coly Li
Cc: sta...@vger.kernel.org
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/bcache/sysfs.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -175,7 +175,7 @@ SHOW(__bch_cached_dev)
var_print(writeback_percent);
sysfs_hprint(writeback_rate,
wb ? atomic_long_read(&dc->writeback_rate.rate) << 9 : 0);
- sysfs_hprint(io_errors, atomic_read(&dc->io_errors));
+ sysfs_printf(io_errors, "%i", atomic_read(&dc->io_errors));
sysfs_printf(io_error_limit,"%i", dc->error_limit);
sysfs_printf(io_disable,"%i", dc->io_disable);
var_print(writeback_rate_update_seconds);
@@ -426,7 +426,7 @@ static struct attribute *bch_cached_dev_
&sysfs_writeback_rate_p_term_inverse,
&sysfs_writeback_rate_minimum,
&sysfs_writeback_rate_debug,
- &sysfs_errors,
+ &sysfs_io_errors,
&sysfs_io_error_limit,
&sysfs_io_disable,
&sysfs_dirty_data,
[PATCH 4.19 192/271] Input: alps - fix a mismatch between a condition check and its comment
From: Hui Wang
commit 771a081e44a9baa1991ef011cc453ef425591740 upstream.
In the function alps_is_cs19_trackpoint(), we check if the param[1] is
in the 0x20~0x2f range, but the code we wrote for this checking is not
correct:
(param[1] & 0x20) does not mean param[1] is in the range of 0x20~0x2f,
it also means the param[1] is in the range of 0x30~0x3f, 0x60~0x6f...
Now fix it with a new condition checking ((param[1] & 0xf0) == 0x20).
Fixes: 7e4935ccc323 ("Input: alps - don't handle ALPS cs19 trackpoint-only
device")
Cc: sta...@vger.kernel.org
Signed-off-by: Hui Wang
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/input/mouse/alps.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -2879,7 +2879,7 @@ static bool alps_is_cs19_trackpoint(stru
* trackpoint-only devices have their variant_ids equal
* TP_VARIANT_ALPS and their firmware_ids are in 0x20~0x2f range.
*/
- return param[0] == TP_VARIANT_ALPS && (param[1] & 0x20);
+ return param[0] == TP_VARIANT_ALPS && ((param[1] & 0xf0) == 0x20);
}
static int alps_identify(struct psmouse *psmouse, struct alps_data *priv)
[PATCH 4.19 186/271] bcache: ignore read-ahead request failure on backing device
From: Coly Li
commit 578df99b1b0531d19af956530fe4da63d01a1604 upstream.
When md raid device (e.g. raid456) is used as backing device, read-ahead
requests on a degrading and recovering md raid device might be failured
immediately by md raid code, but indeed this md raid array can still be
read or write for normal I/O requests. Therefore such failed read-ahead
request are not real hardware failure. Further more, after degrading and
recovering accomplished, read-ahead requests will be handled by md raid
array again.
For such condition, I/O failures of read-ahead requests don't indicate
real health status (because normal I/O still be served), they should not
be counted into I/O error counter dc->io_errors.
Since there is no simple way to detect whether the backing divice is a
md raid device, this patch simply ignores I/O failures for read-ahead
bios on backing device, to avoid bogus backing device failure on a
degrading md raid array.
Suggested-and-tested-by: Thorsten Knabe
Signed-off-by: Coly Li
Cc: sta...@vger.kernel.org
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/bcache/io.c | 12
1 file changed, 12 insertions(+)
--- a/drivers/md/bcache/io.c
+++ b/drivers/md/bcache/io.c
@@ -58,6 +58,18 @@ void bch_count_backing_io_errors(struct
WARN_ONCE(!dc, "NULL pointer of struct cached_dev");
+ /*
+* Read-ahead requests on a degrading and recovering md raid
+* (e.g. raid6) device might be failured immediately by md
+* raid code, which is not a real hardware media failure. So
+* we shouldn't count failed REQ_RAHEAD bio to dc->io_errors.
+*/
+ if (bio->bi_opf & REQ_RAHEAD) {
+ pr_warn_ratelimited("%s: Read-ahead I/O failed on backing
device, ignore",
+ dc->backing_dev_name);
+ return;
+ }
+
errors = atomic_add_return(1, &dc->io_errors);
if (errors < dc->error_limit)
pr_err("%s: IO error on backing device, unrecoverable",
[PATCH 4.19 180/271] crypto: ccp - memset structure fields to zero before reuse
From: Hook, Gary
commit 20e833dc36355ed642d00067641a679c618303fa upstream.
The AES GCM function reuses an 'op' data structure, which members
contain values that must be cleared for each (re)use.
This fix resolves a crypto self-test failure:
alg: aead: gcm-aes-ccp encryption test failed (wrong result) on test vector 2,
cfg="two even aligned splits"
Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Cc:
Signed-off-by: Gary R Hook
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
drivers/crypto/ccp/ccp-ops.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -625,6 +625,7 @@ static int ccp_run_aes_gcm_cmd(struct cc
unsigned long long *final;
unsigned int dm_offset;
+ unsigned int jobid;
unsigned int ilen;
bool in_place = true; /* Default value */
int ret;
@@ -663,9 +664,11 @@ static int ccp_run_aes_gcm_cmd(struct cc
p_tag = scatterwalk_ffwd(sg_tag, p_inp, ilen);
}
+ jobid = CCP_NEW_JOBID(cmd_q->ccp);
+
memset(&op, 0, sizeof(op));
op.cmd_q = cmd_q;
- op.jobid = CCP_NEW_JOBID(cmd_q->ccp);
+ op.jobid = jobid;
op.sb_key = cmd_q->sb_key; /* Pre-allocated */
op.sb_ctx = cmd_q->sb_ctx; /* Pre-allocated */
op.init = 1;
@@ -816,6 +819,13 @@ static int ccp_run_aes_gcm_cmd(struct cc
final[0] = cpu_to_be64(aes->aad_len * 8);
final[1] = cpu_to_be64(ilen * 8);
+ memset(&op, 0, sizeof(op));
+ op.cmd_q = cmd_q;
+ op.jobid = jobid;
+ op.sb_key = cmd_q->sb_key; /* Pre-allocated */
+ op.sb_ctx = cmd_q->sb_ctx; /* Pre-allocated */
+ op.init = 1;
+ op.u.aes.type = aes->type;
op.u.aes.mode = CCP_AES_MODE_GHASH;
op.u.aes.action = CCP_AES_GHASHFINAL;
op.src.type = CCP_MEMTYPE_SYSTEM;
[PATCH 4.19 196/271] iwlwifi: pcie: fix ALIVE interrupt handling for gen2 devices w/o MSI-X
From: Emmanuel Grumbach
commit ec46ae30245ecb41d73f8254613db07c653fb498 upstream.
We added code to restock the buffer upon ALIVE interrupt
when MSI-X is disabled. This was added as part of the context
info code. This code was added only if the ISR debug level
is set which is very unlikely to be related.
Move this code to run even when the ISR debug level is not
set.
Note that gen2 devices work with MSI-X in most cases so that
this path is seldom used.
Cc: sta...@vger.kernel.org
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Luca Coelho
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 34 ---
1 file changed, 16 insertions(+), 18 deletions(-)
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1778,25 +1778,23 @@ irqreturn_t iwl_pcie_irq_handler(int irq
goto out;
}
- if (iwl_have_debug_level(IWL_DL_ISR)) {
- /* NIC fires this, but we don't use it, redundant with WAKEUP */
- if (inta & CSR_INT_BIT_SCD) {
- IWL_DEBUG_ISR(trans,
- "Scheduler finished to transmit the
frame/frames.\n");
- isr_stats->sch++;
- }
+ /* NIC fires this, but we don't use it, redundant with WAKEUP */
+ if (inta & CSR_INT_BIT_SCD) {
+ IWL_DEBUG_ISR(trans,
+ "Scheduler finished to transmit the
frame/frames.\n");
+ isr_stats->sch++;
+ }
- /* Alive notification via Rx interrupt will do the real work */
- if (inta & CSR_INT_BIT_ALIVE) {
- IWL_DEBUG_ISR(trans, "Alive interrupt\n");
- isr_stats->alive++;
- if (trans->cfg->gen2) {
- /*
-* We can restock, since firmware configured
-* the RFH
-*/
- iwl_pcie_rxmq_restock(trans, trans_pcie->rxq);
- }
+ /* Alive notification via Rx interrupt will do the real work */
+ if (inta & CSR_INT_BIT_ALIVE) {
+ IWL_DEBUG_ISR(trans, "Alive interrupt\n");
+ isr_stats->alive++;
+ if (trans->cfg->gen2) {
+ /*
+* We can restock, since firmware configured
+* the RFH
+*/
+ iwl_pcie_rxmq_restock(trans, trans_pcie->rxq);
}
}
Re: [PATCH 1/4] mailbox: arm_mhuv2: add device tree binding documentation
On Sun, Jul 21, 2019 at 4:58 PM Jassi Brar wrote:
>
> On Wed, Jul 17, 2019 at 2:26 PM Tushar Khandelwal
> wrote:
>
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > new file mode 100644
> > index ..3a05593414bc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.txt
> > @@ -0,0 +1,108 @@
> > +Arm MHUv2 Mailbox Driver
> > +
> > +
> > +The Arm Message-Handling-Unit (MHU) Version 2 is a mailbox controller that
> > has
> > +between 1 and 124 channel windows to provide unidirectional communication
> > with
> > +remote processor(s).
> > +
> > +Given the unidirectional nature of the device, an MHUv2 mailbox may only be
> > +written to or read from. If a pair of MHU devices is implemented between
> > two
> > +processing elements to provide bidirectional communication, these must be
> > +specified as two separate mailboxes.
> > +
> > +A device tree node for an Arm MHUv2 device must specify either a receiver
> > frame
> > +or a sender frame, indicating which end of the unidirectional MHU device
> > which
> > +the device node entry describes.
> > +
> > +An MHU device must be specified with a transport protocol. The transport
> > +protocol of an MHU device determines the method of data transmission as
> > well as
> > +the number of provided mailboxes.
> > +Following are the possible transport protocol types:
> > +- Single-word: An MHU device implements as many mailboxes as it
> > + provides channel windows. Data is transmitted through
> > + the MHU registers.
> > +- Multi-word: An MHU device implements a single mailbox. All channel
> > windows
> > + will be used during transmission. Data is transmitted
> > through
> > + the MHU registers.
> > +- Doorbell:An MHU device implements as many mailboxes as there are flag
> > + bits available in its channel windows. Optionally, data may
> > + be transmitted through a shared memory region, wherein the
> > MHU
> > + is used strictly as an interrupt generation mechanism.
> > +
> > +Mailbox Device Node:
> > +
> > +
> > +Required properties:
> > +
> > +- compatible: Shall be "arm,mhuv2" & "arm,primecell"
> > +- reg: Contains the mailbox register address range (base
> > + address and length)
> > +- #mbox-cells Shall be 1 - the index of the channel needed.
> > +- mhu-frameFrame type of the device.
> > + Shall be either "sender" or "receiver"
> > +- mhu-protocol Transport protocol of the device. Shall be one of the
> > + following: "single-word", "multi-word", "doorbell"
> > +
> > +Required properties (receiver frame):
> > +-
> > +- interrupts: Contains the interrupt information corresponding to the
> > + combined interrupt of the receiver frame
> > +
> > +Example:
> > +
> > +
> > + mbox_mw_tx: mhu@1000 {
> > + compatible = "arm,mhuv2","arm,primecell";
> > + reg = <0x1000 0x1000>;
> > + clocks = <&refclk100mhz>;
> > + clock-names = "apb_pclk";
> > + #mbox-cells = <1>;
> > + mhu-protocol = "multi-word";
> > + mhu-frame = "sender";
> > + };
> > +
> > + mbox_sw_tx: mhu@1000 {
> > + compatible = "arm,mhuv2","arm,primecell";
> > + reg = <0x1100 0x1000>;
> > + clocks = <&refclk100mhz>;
> > + clock-names = "apb_pclk";
> > + #mbox-cells = <1>;
> > + mhu-protocol = "single-word";
> > + mhu-frame = "sender";
> > + };
> > +
> > + mbox_db_rx: mhu@1000 {
> > + compatible = "arm,mhuv2","arm,primecell";
> > + reg = <0x1200 0x1000>;
> > + clocks = <&refclk100mhz>;
> > + clock-names = "apb_pclk";
> > + #mbox-cells = <1>;
> > + interrupts = <0 45 4>;
> > + interrupt-names = "mhu_rx";
> > + mhu-protocol = "doorbell";
> > + mhu-frame = "receiver";
> > + };
> > +
> > + mhu_client: scb@2e00 {
> > + compatible = "fujitsu,mb86s70-scb-1.0";
> > + reg = <0 0x2e00 0x4000>;
> > + mboxes =
> > + // For multi-word frames, client may only instantiate a
> > single
> > + // mailbox for a mailbox controller
> > + <&mbox_mw_tx 0>,
> > +
> > + // For single-word frames, client may instantiate as many
> > + // mailboxes as there are channel windows in the MHU
> > +<&mbox_sw_tx 0>,
> > +<&mbox_sw_tx 1>,
> > +<&mbox_sw_tx 2>,
> > +<&mbox_sw_tx 3>,
> > +
> > +
[PATCH 4.19 197/271] iwlwifi: dont WARN when calling iwl_get_shared_mem_conf with RF-Kill
From: Emmanuel Grumbach
commit 0d53cfd0cca3c729a089c39eef0e7d8ae7662974 upstream.
iwl_mvm_send_cmd returns 0 when the command won't be sent
because RF-Kill is asserted. Do the same when we call
iwl_get_shared_mem_conf since it is not sent through
iwl_mvm_send_cmd but directly calls the transport layer.
Cc: sta...@vger.kernel.org
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Luca Coelho
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/intel/iwlwifi/fw/smem.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/net/wireless/intel/iwlwifi/fw/smem.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/smem.c
@@ -8,7 +8,7 @@
* Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
* Copyright(c) 2016 - 2017 Intel Deutschland GmbH
- * Copyright(c) 2018 Intel Corporation
+ * Copyright(c) 2018 - 2019 Intel Corporation
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -31,7 +31,7 @@
* Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
* Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
* Copyright(c) 2016 - 2017 Intel Deutschland GmbH
- * Copyright(c) 2018 Intel Corporation
+ * Copyright(c) 2018 - 2019 Intel Corporation
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -134,6 +134,7 @@ void iwl_get_shared_mem_conf(struct iwl_
.len = { 0, },
};
struct iwl_rx_packet *pkt;
+ int ret;
if (fw_has_capa(&fwrt->fw->ucode_capa,
IWL_UCODE_TLV_CAPA_EXTEND_SHARED_MEM_CFG))
@@ -141,8 +142,13 @@ void iwl_get_shared_mem_conf(struct iwl_
else
cmd.id = SHARED_MEM_CFG;
- if (WARN_ON(iwl_trans_send_cmd(fwrt->trans, &cmd)))
+ ret = iwl_trans_send_cmd(fwrt->trans, &cmd);
+
+ if (ret) {
+ WARN(ret != -ERFKILL,
+"Could not send the SMEM command: %d\n", ret);
return;
+ }
pkt = cmd.resp_pkt;
if (fwrt->trans->cfg->device_family >= IWL_DEVICE_FAMILY_22000)
[PATCH 4.19 202/271] pnfs: Fix a problem where we gratuitously start doing I/O through the MDS
From: Trond Myklebust
commit 58bbeab425c6c5e318f5b6ae31d351331ddfb34b upstream.
If the client has to stop in pnfs_update_layout() to wait for another
layoutget to complete, it currently exits and defaults to I/O through
the MDS if the layoutget was successful.
Fixes: d03360aaf5cc ("pNFS: Ensure we return the error if someone kills...")
Signed-off-by: Trond Myklebust
Cc: sta...@vger.kernel.org # v4.20+
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/pnfs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -1867,7 +1867,7 @@ lookup_again:
spin_unlock(&ino->i_lock);
lseg = ERR_PTR(wait_var_event_killable(&lo->plh_outstanding,
!atomic_read(&lo->plh_outstanding)));
- if (IS_ERR(lseg) || !list_empty(&lo->plh_segs))
+ if (IS_ERR(lseg))
goto out_put_layout_hdr;
pnfs_put_layout_hdr(lo);
goto lookup_again;
[PATCH 4.19 200/271] pnfs/flexfiles: Fix PTR_ERR() dereferences in ff_layout_track_ds_error
From: Trond Myklebust
commit 8e04fdfadda75a849c649f7e50fe7d97772e1fcb upstream.
mirror->mirror_ds can be NULL if uninitialised, but can contain
a PTR_ERR() if call to GETDEVICEINFO failed.
Fixes: 65990d1afbd2 ("pNFS/flexfiles: Fix a deadlock on LAYOUTGET")
Signed-off-by: Trond Myklebust
Cc: sta...@vger.kernel.org # 4.10+
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/flexfilelayout/flexfilelayoutdev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/flexfilelayout/flexfilelayoutdev.c
+++ b/fs/nfs/flexfilelayout/flexfilelayoutdev.c
@@ -307,7 +307,7 @@ int ff_layout_track_ds_error(struct nfs4
if (status == 0)
return 0;
- if (mirror->mirror_ds == NULL)
+ if (IS_ERR_OR_NULL(mirror->mirror_ds))
return -EINVAL;
dserr = kmalloc(sizeof(*dserr), gfp_flags);
[PATCH 4.19 223/271] x86/boot: Fix memory leak in default_get_smp_config()
From: David Rientjes
commit e74bd96989dd42a51a73eddb4a5510a6f5e42ac3 upstream.
When default_get_smp_config() is called with early == 1 and mpf->feature1
is non-zero, mpf is leaked because the return path does not do
early_memunmap().
Fix this and share a common exit routine.
Fixes: 5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")
Reported-by: Cfir Cohen
Signed-off-by: David Rientjes
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
Link:
https://lkml.kernel.org/r/alpine.deb.2.21.1907091942570.28...@chino.kir.corp.google.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/mpparse.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -547,17 +547,15 @@ void __init default_get_smp_config(unsig
* local APIC has default address
*/
mp_lapic_addr = APIC_DEFAULT_PHYS_BASE;
- return;
+ goto out;
}
pr_info("Default MP configuration #%d\n", mpf->feature1);
construct_default_ISA_mptable(mpf->feature1);
} else if (mpf->physptr) {
- if (check_physptr(mpf, early)) {
- early_memunmap(mpf, sizeof(*mpf));
- return;
- }
+ if (check_physptr(mpf, early))
+ goto out;
} else
BUG();
@@ -566,7 +564,7 @@ void __init default_get_smp_config(unsig
/*
* Only use the first configuration found.
*/
-
+out:
early_memunmap(mpf, sizeof(*mpf));
}
[PATCH 4.19 203/271] lib/scatterlist: Fix mapping iterator when sg->offset is greater than PAGE_SIZE
From: Christophe Leroy
commit aeb87246537a83c2aff482f3f34a2e0991e02cbc upstream.
All mapping iterator logic is based on the assumption that sg->offset
is always lower than PAGE_SIZE.
But there are situations where sg->offset is such that the SG item
is on the second page. In that case sg_copy_to_buffer() fails
properly copying the data into the buffer. One of the reason is
that the data will be outside the kmapped area used to access that
data.
This patch fixes the issue by adjusting the mapping iterator
offset and pgoffset fields such that offset is always lower than
PAGE_SIZE.
Signed-off-by: Christophe Leroy
Fixes: 4225fc8555a9 ("lib/scatterlist: use page iterator in the mapping
iterator")
Cc: sta...@vger.kernel.org
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
lib/scatterlist.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -652,17 +652,18 @@ static bool sg_miter_get_next_page(struc
{
if (!miter->__remaining) {
struct scatterlist *sg;
- unsigned long pgoffset;
if (!__sg_page_iter_next(&miter->piter))
return false;
sg = miter->piter.sg;
- pgoffset = miter->piter.sg_pgoffset;
- miter->__offset = pgoffset ? 0 : sg->offset;
+ miter->__offset = miter->piter.sg_pgoffset ? 0 : sg->offset;
+ miter->piter.sg_pgoffset += miter->__offset >> PAGE_SHIFT;
+ miter->__offset &= PAGE_SIZE - 1;
miter->__remaining = sg->offset + sg->length -
- (pgoffset << PAGE_SHIFT) - miter->__offset;
+(miter->piter.sg_pgoffset << PAGE_SHIFT) -
+miter->__offset;
miter->__remaining = min_t(unsigned long, miter->__remaining,
PAGE_SIZE - miter->__offset);
}
[PATCH 4.19 206/271] ALSA: seq: Break too long mutex context in the write loop
From: Takashi Iwai
commit ede34f397ddb063b145b9e7d79c6026f819ded13 upstream.
The fix for the racy writes and ioctls to sequencer widened the
application of client->ioctl_mutex to the whole write loop. Although
it does unlock/relock for the lengthy operation like the event dup,
the loop keeps the ioctl_mutex for the whole time in other
situations. This may take quite long time if the user-space would
give a huge buffer, and this is a likely cause of some weird behavior
spotted by syzcaller fuzzer.
This patch puts a simple workaround, just adding a mutex break in the
loop when a large number of events have been processed. This
shouldn't hit any performance drop because the threshold is set high
enough for usual operations.
Fixes: 7bd800915677 ("ALSA: seq: More protection for concurrent write and ioctl
races")
Reported-by: syzbot+97aae04ce27e39cbf...@syzkaller.appspotmail.com
Reported-by: syzbot+4c595632b98bb8ffc...@syzkaller.appspotmail.com
Cc:
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/core/seq/seq_clientmgr.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -1004,7 +1004,7 @@ static ssize_t snd_seq_write(struct file
{
struct snd_seq_client *client = file->private_data;
int written = 0, len;
- int err;
+ int err, handled;
struct snd_seq_event event;
if (!(snd_seq_file_flags(file) & SNDRV_SEQ_LFLG_OUTPUT))
@@ -1017,6 +1017,8 @@ static ssize_t snd_seq_write(struct file
if (!client->accept_output || client->pool == NULL)
return -ENXIO;
+ repeat:
+ handled = 0;
/* allocate the pool now if the pool is not allocated yet */
mutex_lock(&client->ioctl_mutex);
if (client->pool->size > 0 && !snd_seq_write_pool_allocated(client)) {
@@ -1076,12 +1078,19 @@ static ssize_t snd_seq_write(struct file
0, 0, &client->ioctl_mutex);
if (err < 0)
break;
+ handled++;
__skip_event:
/* Update pointers and counts */
count -= len;
buf += len;
written += len;
+
+ /* let's have a coffee break if too many events are queued */
+ if (++handled >= 200) {
+ mutex_unlock(&client->ioctl_mutex);
+ goto repeat;
+ }
}
out:
[PATCH 4.19 210/271] media: coda: Remove unbalanced and unneeded mutex unlock
From: Ezequiel Garcia
commit 766b9b168f6c75c350dd87c3e0bc6a9b322f0013 upstream.
The mutex unlock in the threaded interrupt handler is not paired
with any mutex lock. Remove it.
This bug has been here for a really long time, so it applies
to any stable repo.
Reviewed-by: Philipp Zabel
Signed-off-by: Ezequiel Garcia
Signed-off-by: Hans Verkuil
Cc: sta...@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman
---
drivers/media/platform/coda/coda-bit.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2309,7 +2309,6 @@ irqreturn_t coda_irq_handler(int irq, vo
if (ctx == NULL) {
v4l2_err(&dev->v4l2_dev,
"Instance released before the end of transaction\n");
- mutex_unlock(&dev->coda_mutex);
return IRQ_HANDLED;
}
[PATCH 4.19 175/271] crypto: arm64/sha2-ce - correct digest for empty data in finup
From: Elena Petrova
commit 6bd934de1e393466b319d29c4427598fda096c57 upstream.
The sha256-ce finup implementation for ARM64 produces wrong digest
for empty input (len=0). Expected: the actual digest, result: initial
value of SHA internal state. The error is in sha256_ce_finup:
for empty data `finalize` will be 1, so the code is relying on
sha2_ce_transform to make the final round. However, in
sha256_base_do_update, the block function will not be called when
len == 0.
Fix it by setting finalize to 0 if data is empty.
Fixes: 03802f6a80b3a ("crypto: arm64/sha2-ce - move SHA-224/256 ARMv8
implementation to base layer")
Cc: sta...@vger.kernel.org
Signed-off-by: Elena Petrova
Reviewed-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/crypto/sha2-ce-glue.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/crypto/sha2-ce-glue.c
+++ b/arch/arm64/crypto/sha2-ce-glue.c
@@ -59,7 +59,7 @@ static int sha256_ce_finup(struct shash_
unsigned int len, u8 *out)
{
struct sha256_ce_state *sctx = shash_desc_ctx(desc);
- bool finalize = !sctx->sst.count && !(len % SHA256_BLOCK_SIZE);
+ bool finalize = !sctx->sst.count && !(len % SHA256_BLOCK_SIZE) && len;
if (!may_use_simd()) {
if (len)
[PATCH 4.19 219/271] dm zoned: fix zone state management race
From: Damien Le Moal
commit 3b8cafdd5436f9298b3bf6eb831df5eef5ee82b6 upstream.
dm-zoned uses the zone flag DMZ_ACTIVE to indicate that a zone of the
backend device is being actively read or written and so cannot be
reclaimed. This flag is set as long as the zone atomic reference
counter is not 0. When this atomic is decremented and reaches 0 (e.g.
on BIO completion), the active flag is cleared and set again whenever
the zone is reused and BIO issued with the atomic counter incremented.
These 2 operations (atomic inc/dec and flag set/clear) are however not
always executed atomically under the target metadata mutex lock and
this causes the warning:
WARN_ON(!test_bit(DMZ_ACTIVE, &zone->flags));
in dmz_deactivate_zone() to be displayed. This problem is regularly
triggered with xfstests generic/209, generic/300, generic/451 and
xfs/077 with XFS being used as the file system on the dm-zoned target
device. Similarly, xfstests ext4/303, ext4/304, generic/209 and
generic/300 trigger the warning with ext4 use.
This problem can be easily fixed by simply removing the DMZ_ACTIVE flag
and managing the "ACTIVE" state by directly looking at the reference
counter value. To do so, the functions dmz_activate_zone() and
dmz_deactivate_zone() are changed to inline functions respectively
calling atomic_inc() and atomic_dec(), while the dmz_is_active() macro
is changed to an inline function calling atomic_read().
Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
Cc: sta...@vger.kernel.org
Reported-by: Masato Suzuki
Signed-off-by: Damien Le Moal
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm-zoned-metadata.c | 24
drivers/md/dm-zoned.h | 28
2 files changed, 24 insertions(+), 28 deletions(-)
--- a/drivers/md/dm-zoned-metadata.c
+++ b/drivers/md/dm-zoned-metadata.c
@@ -1594,30 +1594,6 @@ struct dm_zone *dmz_get_zone_for_reclaim
}
/*
- * Activate a zone (increment its reference count).
- */
-void dmz_activate_zone(struct dm_zone *zone)
-{
- set_bit(DMZ_ACTIVE, &zone->flags);
- atomic_inc(&zone->refcount);
-}
-
-/*
- * Deactivate a zone. This decrement the zone reference counter
- * and clears the active state of the zone once the count reaches 0,
- * indicating that all BIOs to the zone have completed. Returns
- * true if the zone was deactivated.
- */
-void dmz_deactivate_zone(struct dm_zone *zone)
-{
- if (atomic_dec_and_test(&zone->refcount)) {
- WARN_ON(!test_bit(DMZ_ACTIVE, &zone->flags));
- clear_bit_unlock(DMZ_ACTIVE, &zone->flags);
- smp_mb__after_atomic();
- }
-}
-
-/*
* Get the zone mapping a chunk, if the chunk is mapped already.
* If no mapping exist and the operation is WRITE, a zone is
* allocated and used to map the chunk.
--- a/drivers/md/dm-zoned.h
+++ b/drivers/md/dm-zoned.h
@@ -115,7 +115,6 @@ enum {
DMZ_BUF,
/* Zone internal state */
- DMZ_ACTIVE,
DMZ_RECLAIM,
DMZ_SEQ_WRITE_ERR,
};
@@ -128,7 +127,6 @@ enum {
#define dmz_is_empty(z)((z)->wp_block == 0)
#define dmz_is_offline(z) test_bit(DMZ_OFFLINE, &(z)->flags)
#define dmz_is_readonly(z) test_bit(DMZ_READ_ONLY, &(z)->flags)
-#define dmz_is_active(z) test_bit(DMZ_ACTIVE, &(z)->flags)
#define dmz_in_reclaim(z) test_bit(DMZ_RECLAIM, &(z)->flags)
#define dmz_seq_write_err(z) test_bit(DMZ_SEQ_WRITE_ERR, &(z)->flags)
@@ -188,8 +186,30 @@ void dmz_unmap_zone(struct dmz_metadata
unsigned int dmz_nr_rnd_zones(struct dmz_metadata *zmd);
unsigned int dmz_nr_unmap_rnd_zones(struct dmz_metadata *zmd);
-void dmz_activate_zone(struct dm_zone *zone);
-void dmz_deactivate_zone(struct dm_zone *zone);
+/*
+ * Activate a zone (increment its reference count).
+ */
+static inline void dmz_activate_zone(struct dm_zone *zone)
+{
+ atomic_inc(&zone->refcount);
+}
+
+/*
+ * Deactivate a zone. This decrement the zone reference counter
+ * indicating that all BIOs to the zone have completed when the count is 0.
+ */
+static inline void dmz_deactivate_zone(struct dm_zone *zone)
+{
+ atomic_dec(&zone->refcount);
+}
+
+/*
+ * Test if a zone is active, that is, has a refcount > 0.
+ */
+static inline bool dmz_is_active(struct dm_zone *zone)
+{
+ return atomic_read(&zone->refcount);
+}
int dmz_lock_zone_reclaim(struct dm_zone *zone);
void dmz_unlock_zone_reclaim(struct dm_zone *zone);
[PATCH 4.19 173/271] crypto: ccp - Validate the the error value used to index error messages
From: Hook, Gary
commit 52393d617af7b554f03531e6756facf2ea687d2e upstream.
The error code read from the queue status register is only 6 bits wide,
but we need to verify its value is within range before indexing the error
messages.
Fixes: 81422badb3907 ("crypto: ccp - Make syslog errors human-readable")
Cc:
Reported-by: Cfir Cohen
Signed-off-by: Gary R Hook
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
drivers/crypto/ccp/ccp-dev.c | 96 ++-
drivers/crypto/ccp/ccp-dev.h |2
2 files changed, 52 insertions(+), 46 deletions(-)
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -35,56 +35,62 @@ struct ccp_tasklet_data {
};
/* Human-readable error strings */
+#define CCP_MAX_ERROR_CODE 64
static char *ccp_error_codes[] = {
"",
- "ERR 01: ILLEGAL_ENGINE",
- "ERR 02: ILLEGAL_KEY_ID",
- "ERR 03: ILLEGAL_FUNCTION_TYPE",
- "ERR 04: ILLEGAL_FUNCTION_MODE",
- "ERR 05: ILLEGAL_FUNCTION_ENCRYPT",
- "ERR 06: ILLEGAL_FUNCTION_SIZE",
- "ERR 07: Zlib_MISSING_INIT_EOM",
- "ERR 08: ILLEGAL_FUNCTION_RSVD",
- "ERR 09: ILLEGAL_BUFFER_LENGTH",
- "ERR 10: VLSB_FAULT",
- "ERR 11: ILLEGAL_MEM_ADDR",
- "ERR 12: ILLEGAL_MEM_SEL",
- "ERR 13: ILLEGAL_CONTEXT_ID",
- "ERR 14: ILLEGAL_KEY_ADDR",
- "ERR 15: 0xF Reserved",
- "ERR 16: Zlib_ILLEGAL_MULTI_QUEUE",
- "ERR 17: Zlib_ILLEGAL_JOBID_CHANGE",
- "ERR 18: CMD_TIMEOUT",
- "ERR 19: IDMA0_AXI_SLVERR",
- "ERR 20: IDMA0_AXI_DECERR",
- "ERR 21: 0x15 Reserved",
- "ERR 22: IDMA1_AXI_SLAVE_FAULT",
- "ERR 23: IDMA1_AIXI_DECERR",
- "ERR 24: 0x18 Reserved",
- "ERR 25: ZLIBVHB_AXI_SLVERR",
- "ERR 26: ZLIBVHB_AXI_DECERR",
- "ERR 27: 0x1B Reserved",
- "ERR 27: ZLIB_UNEXPECTED_EOM",
- "ERR 27: ZLIB_EXTRA_DATA",
- "ERR 30: ZLIB_BTYPE",
- "ERR 31: ZLIB_UNDEFINED_SYMBOL",
- "ERR 32: ZLIB_UNDEFINED_DISTANCE_S",
- "ERR 33: ZLIB_CODE_LENGTH_SYMBOL",
- "ERR 34: ZLIB _VHB_ILLEGAL_FETCH",
- "ERR 35: ZLIB_UNCOMPRESSED_LEN",
- "ERR 36: ZLIB_LIMIT_REACHED",
- "ERR 37: ZLIB_CHECKSUM_MISMATCH0",
- "ERR 38: ODMA0_AXI_SLVERR",
- "ERR 39: ODMA0_AXI_DECERR",
- "ERR 40: 0x28 Reserved",
- "ERR 41: ODMA1_AXI_SLVERR",
- "ERR 42: ODMA1_AXI_DECERR",
- "ERR 43: LSB_PARITY_ERR",
+ "ILLEGAL_ENGINE",
+ "ILLEGAL_KEY_ID",
+ "ILLEGAL_FUNCTION_TYPE",
+ "ILLEGAL_FUNCTION_MODE",
+ "ILLEGAL_FUNCTION_ENCRYPT",
+ "ILLEGAL_FUNCTION_SIZE",
+ "Zlib_MISSING_INIT_EOM",
+ "ILLEGAL_FUNCTION_RSVD",
+ "ILLEGAL_BUFFER_LENGTH",
+ "VLSB_FAULT",
+ "ILLEGAL_MEM_ADDR",
+ "ILLEGAL_MEM_SEL",
+ "ILLEGAL_CONTEXT_ID",
+ "ILLEGAL_KEY_ADDR",
+ "0xF Reserved",
+ "Zlib_ILLEGAL_MULTI_QUEUE",
+ "Zlib_ILLEGAL_JOBID_CHANGE",
+ "CMD_TIMEOUT",
+ "IDMA0_AXI_SLVERR",
+ "IDMA0_AXI_DECERR",
+ "0x15 Reserved",
+ "IDMA1_AXI_SLAVE_FAULT",
+ "IDMA1_AIXI_DECERR",
+ "0x18 Reserved",
+ "ZLIBVHB_AXI_SLVERR",
+ "ZLIBVHB_AXI_DECERR",
+ "0x1B Reserved",
+ "ZLIB_UNEXPECTED_EOM",
+ "ZLIB_EXTRA_DATA",
+ "ZLIB_BTYPE",
+ "ZLIB_UNDEFINED_SYMBOL",
+ "ZLIB_UNDEFINED_DISTANCE_S",
+ "ZLIB_CODE_LENGTH_SYMBOL",
+ "ZLIB _VHB_ILLEGAL_FETCH",
+ "ZLIB_UNCOMPRESSED_LEN",
+ "ZLIB_LIMIT_REACHED",
+ "ZLIB_CHECKSUM_MISMATCH0",
+ "ODMA0_AXI_SLVERR",
+ "ODMA0_AXI_DECERR",
+ "0x28 Reserved",
+ "ODMA1_AXI_SLVERR",
+ "ODMA1_AXI_DECERR",
};
-void ccp_log_error(struct ccp_device *d, int e)
+void ccp_log_error(struct ccp_device *d, unsigned int e)
{
- dev_err(d->dev, "CCP error: %s (0x%x)\n", ccp_error_codes[e], e);
+ if (WARN_ON(e >= CCP_MAX_ERROR_CODE))
+ return;
+
+ if (e < ARRAY_SIZE(ccp_error_codes))
+ dev_err(d->dev, "CCP error %d: %s\n", e, ccp_error_codes[e]);
+ else
+ dev_err(d->dev, "CCP error %d: Unknown Error\n", e);
}
/* List of CCPs, CCP count, read-write access lock, and access functions
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -632,7 +632,7 @@ struct ccp5_desc {
void ccp_add_device(struct ccp_device *ccp);
void ccp_del_device(struct ccp_device *ccp);
-extern void ccp_log_error(struct ccp_device *, int);
+extern void ccp_log_error(struct ccp_device *, unsigned int);
struct ccp_device *ccp_alloc_struct(struct sp_device *sp);
bool ccp_queues_suspended(struct ccp_device *ccp);
[PATCH 4.19 166/271] scsi: NCR5380: Always re-enable reselection interrupt
From: Finn Thain
commit 57f31326518e98ee4cabf9a04efe00ed57c54147 upstream.
The reselection interrupt gets disabled during selection and must be
re-enabled when hostdata->connected becomes NULL. If it isn't re-enabled a
disconnected command may time-out or the target may wedge the bus while
trying to reselect the host. This can happen after a command is aborted.
Fix this by enabling the reselection interrupt in NCR5380_main() after
calls to NCR5380_select() and NCR5380_information_transfer() return.
Cc: Michael Schmitz
Cc: sta...@vger.kernel.org # v4.9+
Fixes: 8b00c3d5d40d ("ncr5380: Implement new eh_abort_handler")
Signed-off-by: Finn Thain
Tested-by: Stan Johnson
Tested-by: Michael Schmitz
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/NCR5380.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -710,6 +710,8 @@ static void NCR5380_main(struct work_str
NCR5380_information_transfer(instance);
done = 0;
}
+ if (!hostdata->connected)
+ NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
spin_unlock_irq(&hostdata->lock);
if (!done)
cond_resched();
@@ -1106,8 +1108,6 @@ static struct scsi_cmnd *NCR5380_select(
spin_lock_irq(&hostdata->lock);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
NCR5380_reselect(instance);
- if (!hostdata->connected)
- NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
shost_printk(KERN_ERR, instance, "reselection after won
arbitration?\n");
goto out;
}
@@ -1115,7 +1115,6 @@ static struct scsi_cmnd *NCR5380_select(
if (err < 0) {
spin_lock_irq(&hostdata->lock);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
- NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
/* Can't touch cmd if it has been reclaimed by the scsi ML */
if (!hostdata->selecting)
@@ -1153,7 +1152,6 @@ static struct scsi_cmnd *NCR5380_select(
if (err < 0) {
shost_printk(KERN_ERR, instance, "select: REQ timeout\n");
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
- NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
goto out;
}
if (!hostdata->selecting) {
@@ -1820,9 +1818,6 @@ static void NCR5380_information_transfer
*/
NCR5380_write(TARGET_COMMAND_REG, 0);
- /* Enable reselect interrupts */
- NCR5380_write(SELECT_ENABLE_REG,
hostdata->id_mask);
-
maybe_release_dma_irq(instance);
return;
case MESSAGE_REJECT:
@@ -1854,8 +1849,6 @@ static void NCR5380_information_transfer
*/
NCR5380_write(TARGET_COMMAND_REG, 0);
- /* Enable reselect interrupts */
- NCR5380_write(SELECT_ENABLE_REG,
hostdata->id_mask);
#ifdef SUN3_SCSI_VME
dregs->csr |= CSR_DMA_ENABLE;
#endif
@@ -1957,7 +1950,6 @@ static void NCR5380_information_transfer
cmd->result = DID_ERROR << 16;
complete_cmd(instance, cmd);
maybe_release_dma_irq(instance);
- NCR5380_write(SELECT_ENABLE_REG,
hostdata->id_mask);
return;
}
msgout = NOP;
[PATCH 4.19 238/271] HID: wacom: correct touch resolution x/y typo
From: Aaron Armstrong Skomra
commit 68c20cc2164cc5c7c73f8012ae6491afdb1f7f72 upstream.
This affects the 2nd-gen Intuos Pro Medium and Large
when using their Bluetooth connection.
Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth
classic interface")
Cc: # v4.11+
Signed-off-by: Aaron Armstrong Skomra
Reviewed-by: Jason Gerecke
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/wacom_wac.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3734,7 +3734,7 @@ int wacom_setup_touch_input_capabilities
0, 5920, 4, 0);
}
input_abs_set_res(input_dev, ABS_MT_POSITION_X, 40);
- input_abs_set_res(input_dev, ABS_MT_POSITION_X, 40);
+ input_abs_set_res(input_dev, ABS_MT_POSITION_Y, 40);
/* fall through */
[PATCH 4.19 227/271] drm/edid: parse CEA blocks embedded in DisplayID
From: Andres Rodriguez
commit e28ad544f462231d3fd081a7316339359efbb481 upstream.
DisplayID blocks allow embedding of CEA blocks. The payloads are
identical to traditional top level CEA extension blocks, but the header
is slightly different.
This change allows the CEA parser to find a CEA block inside a DisplayID
block. Additionally, it adds support for parsing the embedded CTA
header. No further changes are necessary due to payload parity.
This change fixes audio support for the Valve Index HMD.
Signed-off-by: Andres Rodriguez
Reviewed-by: Dave Airlie
Cc: Jani Nikula
Cc: # v4.15
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20190619180901.17901-1-andre...@gmail.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_edid.c | 81 ++--
include/drm/drm_displayid.h | 10 +
2 files changed, 80 insertions(+), 11 deletions(-)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1349,6 +1349,7 @@ MODULE_PARM_DESC(edid_fixup,
static void drm_get_displayid(struct drm_connector *connector,
struct edid *edid);
+static int validate_displayid(u8 *displayid, int length, int idx);
static int drm_edid_block_checksum(const u8 *raw_edid)
{
@@ -2932,16 +2933,46 @@ static u8 *drm_find_edid_extension(const
return edid_ext;
}
-static u8 *drm_find_cea_extension(const struct edid *edid)
-{
- return drm_find_edid_extension(edid, CEA_EXT);
-}
static u8 *drm_find_displayid_extension(const struct edid *edid)
{
return drm_find_edid_extension(edid, DISPLAYID_EXT);
}
+static u8 *drm_find_cea_extension(const struct edid *edid)
+{
+ int ret;
+ int idx = 1;
+ int length = EDID_LENGTH;
+ struct displayid_block *block;
+ u8 *cea;
+ u8 *displayid;
+
+ /* Look for a top level CEA extension block */
+ cea = drm_find_edid_extension(edid, CEA_EXT);
+ if (cea)
+ return cea;
+
+ /* CEA blocks can also be found embedded in a DisplayID block */
+ displayid = drm_find_displayid_extension(edid);
+ if (!displayid)
+ return NULL;
+
+ ret = validate_displayid(displayid, length, idx);
+ if (ret)
+ return NULL;
+
+ idx += sizeof(struct displayid_hdr);
+ for_each_displayid_db(displayid, block, idx, length) {
+ if (block->tag == DATA_BLOCK_CTA) {
+ cea = (u8 *)block;
+ break;
+ }
+ }
+
+ return cea;
+}
+
/*
* Calculate the alternate clock for the CEA mode
* (60Hz vs. 59.94Hz etc.)
@@ -3665,13 +3696,38 @@ cea_revision(const u8 *cea)
static int
cea_db_offsets(const u8 *cea, int *start, int *end)
{
- /* Data block offset in CEA extension block */
- *start = 4;
- *end = cea[2];
- if (*end == 0)
- *end = 127;
- if (*end < 4 || *end > 127)
- return -ERANGE;
+ /* DisplayID CTA extension blocks and top-level CEA EDID
+* block header definitions differ in the following bytes:
+* 1) Byte 2 of the header specifies length differently,
+* 2) Byte 3 is only present in the CEA top level block.
+*
+* The different definitions for byte 2 follow.
+*
+* DisplayID CTA extension block defines byte 2 as:
+* Number of payload bytes
+*
+* CEA EDID block defines byte 2 as:
+* Byte number (decimal) within this block where the 18-byte
+* DTDs begin. If no non-DTD data is present in this extension
+* block, the value should be set to 04h (the byte after next).
+* If set to 00h, there are no DTDs present in this block and
+* no non-DTD data.
+*/
+ if (cea[0] == DATA_BLOCK_CTA) {
+ *start = 3;
+ *end = *start + cea[2];
+ } else if (cea[0] == CEA_EXT) {
+ /* Data block offset in CEA extension block */
+ *start = 4;
+ *end = cea[2];
+ if (*end == 0)
+ *end = 127;
+ if (*end < 4 || *end > 127)
+ return -ERANGE;
+ } else {
+ return -ENOTSUPP;
+ }
+
return 0;
}
@@ -5218,6 +5274,9 @@ static int drm_parse_display_id(struct d
case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
/* handled in mode gathering code. */
break;
+ case DATA_BLOCK_CTA:
+ /* handled in the cea parser code. */
+ break;
default:
DRM_DEBUG_KMS("found DisplayID tag 0x%x, unhandled\n",
block->tag);
break;
--- a/include/drm/drm_displayid.h
+++ b/include/drm/drm_displayid.h
@@ -40,6 +40,7 @@
#define DATA_BLOCK_DISPLAY_INTERFACE 0x0f
#define DATA_BLOCK_ST
[PATCH 4.19 226/271] perf/x86/amd/uncore: Set the thread mask for F17h L3 PMCs
From: Kim Phillips
commit 2f217d58a8a086d3399fecce39fb358848e799c4 upstream.
Fill in the L3 performance event select register ThreadMask
bitfield, to enable per hardware thread accounting.
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Cc:
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: Gary Hook
Cc: H. Peter Anvin
Cc: Janakarajan Natarajan
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Martin Liska
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Pu Wen
Cc: Stephane Eranian
Cc: Suravee Suthikulpanit
Cc: Thomas Gleixner
Cc: Vince Weaver
Link: https://lkml.kernel.org/r/20190628215906.4276-2-kim.phill...@amd.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/events/amd/uncore.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -210,15 +210,22 @@ static int amd_uncore_event_init(struct
hwc->config = event->attr.config & AMD64_RAW_EVENT_MASK_NB;
hwc->idx = -1;
+ if (event->cpu < 0)
+ return -EINVAL;
+
/*
* SliceMask and ThreadMask need to be set for certain L3 events in
* Family 17h. For other events, the two fields do not affect the count.
*/
- if (l3_mask && is_llc_event(event))
- hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK);
+ if (l3_mask && is_llc_event(event)) {
+ int thread = 2 * (cpu_data(event->cpu).cpu_core_id % 4);
- if (event->cpu < 0)
- return -EINVAL;
+ if (smp_num_siblings > 1)
+ thread += cpu_data(event->cpu).apicid & 1;
+
+ hwc->config |= (1ULL << (AMD64_L3_THREAD_SHIFT + thread) &
+ AMD64_L3_THREAD_MASK) | AMD64_L3_SLICE_MASK;
+ }
uncore = event_to_amd_uncore(event);
if (!uncore)
Re: [PATCH REBASE v4 05/14] arm64, mm: Make randomization selected by generic topdown mmap layout
On 7/24/19 7:11 PM, Luis Chamberlain wrote:
On Wed, Jul 24, 2019 at 01:58:41AM -0400, Alexandre Ghiti wrote:
diff --git a/mm/util.c b/mm/util.c
index 0781e5575cb3..16f1e56e2996 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -321,7 +321,15 @@ unsigned long randomize_stack_top(unsigned long stack_top)
}
#ifdef CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
-#ifdef CONFIG_ARCH_HAS_ELF_RANDOMIZE
+unsigned long arch_randomize_brk(struct mm_struct *mm)
+{
+ /* Is the current task 32bit ? */
+ if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task())
+ return randomize_page(mm->brk, SZ_32M);
+
+ return randomize_page(mm->brk, SZ_1G);
+}
+
unsigned long arch_mmap_rnd(void)
{
unsigned long rnd;
@@ -335,7 +343,6 @@ unsigned long arch_mmap_rnd(void)
return rnd << PAGE_SHIFT;
}
So arch_randomize_brk is no longer ifdef'd around
CONFIG_ARCH_HAS_ELF_RANDOMIZE either and yet the header
still has it. Is that intentional?
Yes, CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT selects
CONFIG_ARCH_HAS_ELF_RANDOMIZE, that's what's new about v4: the generic
functions proposed in this series come with elf randomization.
Alex
Luis
___
linux-riscv mailing list
linux-ri...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
[PATCH 4.19 217/271] drm/nouveau/i2c: Enable i2c pads & busses during preinit
From: Lyude Paul
commit 7cb95eeea6706c790571042a06782e378b2561ea upstream.
It turns out that while disabling i2c bus access from software when the
GPU is suspended was a step in the right direction with:
commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after
->fini()")
We also ended up accidentally breaking the vbios init scripts on some
older Tesla GPUs, as apparently said scripts can actually use the i2c
bus. Since these scripts are executed before initializing any
subdevices, we end up failing to acquire access to the i2c bus which has
left a number of cards with their fan controllers uninitialized. Luckily
this doesn't break hardware - it just means the fan gets stuck at 100%.
This also means that we've always been using our i2c busses before
initializing them during the init scripts for older GPUs, we just didn't
notice it until we started preventing them from being used until init.
It's pretty impressive this never caused us any issues before!
So, fix this by initializing our i2c pad and busses during subdev
pre-init. We skip initializing aux busses during pre-init, as those are
guaranteed to only ever be used by nouveau for DP aux transactions.
Signed-off-by: Lyude Paul
Tested-by: Marc Meledandri
Fixes: 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()")
Cc: sta...@vger.kernel.org
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 20
1 file changed, 20 insertions(+)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
@@ -185,6 +185,25 @@ nvkm_i2c_fini(struct nvkm_subdev *subdev
}
static int
+nvkm_i2c_preinit(struct nvkm_subdev *subdev)
+{
+ struct nvkm_i2c *i2c = nvkm_i2c(subdev);
+ struct nvkm_i2c_bus *bus;
+ struct nvkm_i2c_pad *pad;
+
+ /*
+* We init our i2c busses as early as possible, since they may be
+* needed by the vbios init scripts on some cards
+*/
+ list_for_each_entry(pad, &i2c->pad, head)
+ nvkm_i2c_pad_init(pad);
+ list_for_each_entry(bus, &i2c->bus, head)
+ nvkm_i2c_bus_init(bus);
+
+ return 0;
+}
+
+static int
nvkm_i2c_init(struct nvkm_subdev *subdev)
{
struct nvkm_i2c *i2c = nvkm_i2c(subdev);
@@ -238,6 +257,7 @@ nvkm_i2c_dtor(struct nvkm_subdev *subdev
static const struct nvkm_subdev_func
nvkm_i2c = {
.dtor = nvkm_i2c_dtor,
+ .preinit = nvkm_i2c_preinit,
.init = nvkm_i2c_init,
.fini = nvkm_i2c_fini,
.intr = nvkm_i2c_intr,
[PATCH 4.19 218/271] padata: use smp_mb in padata_reorder to avoid orphaned padata jobs
From: Daniel Jordan
commit cf144f81a99d1a3928f90b0936accfd3f45c9a0a upstream.
Testing padata with the tcrypt module on a 5.2 kernel...
# modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3
# modprobe tcrypt mode=211 sec=1
...produces this splat:
INFO: task modprobe:10075 blocked for more than 120 seconds.
Not tainted 5.2.0-base+ #16
modprobeD0 10075 10064 0x80004080
Call Trace:
? __schedule+0x4dd/0x610
? ring_buffer_unlock_commit+0x23/0x100
schedule+0x6c/0x90
schedule_timeout+0x3b/0x320
? trace_buffer_unlock_commit_regs+0x4f/0x1f0
wait_for_common+0x160/0x1a0
? wake_up_q+0x80/0x80
{ crypto_wait_req } # entries in braces added by hand
{ do_one_aead_op }
{ test_aead_jiffies }
test_aead_speed.constprop.17+0x681/0xf30 [tcrypt]
do_test+0x4053/0x6a2b [tcrypt]
? 0xa00f4000
tcrypt_mod_init+0x50/0x1000 [tcrypt]
...
The second modprobe command never finishes because in padata_reorder,
CPU0's load of reorder_objects is executed before the unlocking store in
spin_unlock_bh(pd->lock), causing CPU0 to miss CPU1's increment:
CPU0 CPU1
padata_reorder padata_do_serial
LOAD reorder_objects // 0
INC reorder_objects // 1
padata_reorder
TRYLOCK pd->lock // failed
UNLOCK pd->lock
CPU0 deletes the timer before returning from padata_reorder and since no
other job is submitted to padata, modprobe waits indefinitely.
Add a pair of full barriers to guarantee proper ordering:
CPU0 CPU1
padata_reorder padata_do_serial
UNLOCK pd->lock
smp_mb()
LOAD reorder_objects
INC reorder_objects
smp_mb__after_atomic()
padata_reorder
TRYLOCK pd->lock
smp_mb__after_atomic is needed so the read part of the trylock operation
comes after the INC, as Andrea points out. Thanks also to Andrea for
help with writing a litmus test.
Fixes: 16295bec6398 ("padata: Generic parallelization/serialization interface")
Signed-off-by: Daniel Jordan
Cc:
Cc: Andrea Parri
Cc: Boqun Feng
Cc: Herbert Xu
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Steffen Klassert
Cc: linux-a...@vger.kernel.org
Cc: linux-cry...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
kernel/padata.c | 12
1 file changed, 12 insertions(+)
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -267,7 +267,12 @@ static void padata_reorder(struct parall
* The next object that needs serialization might have arrived to
* the reorder queues in the meantime, we will be called again
* from the timer function if no one else cares for it.
+*
+* Ensure reorder_objects is read after pd->lock is dropped so we see
+* an increment from another task in padata_do_serial. Pairs with
+* smp_mb__after_atomic in padata_do_serial.
*/
+ smp_mb();
if (atomic_read(&pd->reorder_objects)
&& !(pinst->flags & PADATA_RESET))
mod_timer(&pd->timer, jiffies + HZ);
@@ -387,6 +392,13 @@ void padata_do_serial(struct padata_priv
list_add_tail(&padata->list, &pqueue->reorder.list);
spin_unlock(&pqueue->reorder.lock);
+ /*
+* Ensure the atomic_inc of reorder_objects above is ordered correctly
+* with the trylock of pd->lock in padata_reorder. Pairs with smp_mb
+* in padata_reorder.
+*/
+ smp_mb__after_atomic();
+
put_cpu();
/* If we're running on the wrong CPU, call padata_reorder() via a
[PATCH 4.19 254/271] parisc: Fix kernel panic due invalid values in IAOQ0 or IAOQ1
From: Helge Deller
commit 10835c854685393a921b68f529bf740fa7c9984d upstream.
On parisc the privilege level of a process is stored in the lowest two bits of
the instruction pointers (IAOQ0 and IAOQ1). On Linux we use privilege level 0
for the kernel and privilege level 3 for user-space. So userspace should not be
allowed to modify IAOQ0 or IAOQ1 of a ptraced process to change it's privilege
level to e.g. 0 to try to gain kernel privileges.
This patch prevents such modifications by always setting the two lowest bits to
one (which relates to privilege level 3 for user-space) if IAOQ0 or IAOQ1 are
modified via ptrace calls in the native and compat ptrace paths.
Link: https://bugs.gentoo.org/481768
Reported-by: Jeroen Roovers
Cc:
Tested-by: Rolf Eike Beer
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
---
arch/parisc/kernel/ptrace.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
--- a/arch/parisc/kernel/ptrace.c
+++ b/arch/parisc/kernel/ptrace.c
@@ -167,6 +167,9 @@ long arch_ptrace(struct task_struct *chi
if ((addr & (sizeof(unsigned long)-1)) ||
addr >= sizeof(struct pt_regs))
break;
+ if (addr == PT_IAOQ0 || addr == PT_IAOQ1) {
+ data |= 3; /* ensure userspace privilege */
+ }
if ((addr >= PT_GR1 && addr <= PT_GR31) ||
addr == PT_IAOQ0 || addr == PT_IAOQ1 ||
(addr >= PT_FR0 && addr <= PT_FR31 + 4) ||
@@ -228,16 +231,18 @@ long arch_ptrace(struct task_struct *chi
static compat_ulong_t translate_usr_offset(compat_ulong_t offset)
{
- if (offset < 0)
- return sizeof(struct pt_regs);
- else if (offset <= 32*4)/* gr[0..31] */
- return offset * 2 + 4;
- else if (offset <= 32*4+32*8) /* gr[0..31] + fr[0..31] */
- return offset + 32*4;
- else if (offset < sizeof(struct pt_regs)/2 + 32*4)
- return offset * 2 + 4 - 32*8;
+ compat_ulong_t pos;
+
+ if (offset < 32*4) /* gr[0..31] */
+ pos = offset * 2 + 4;
+ else if (offset < 32*4+32*8)/* fr[0] ... fr[31] */
+ pos = (offset - 32*4) + PT_FR0;
+ else if (offset < sizeof(struct pt_regs)/2 + 32*4) /* sr[0] ... ipsw */
+ pos = (offset - 32*4 - 32*8) * 2 + PT_SR0 + 4;
else
- return sizeof(struct pt_regs);
+ pos = sizeof(struct pt_regs);
+
+ return pos;
}
long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
@@ -281,9 +286,12 @@ long compat_arch_ptrace(struct task_stru
addr = translate_usr_offset(addr);
if (addr >= sizeof(struct pt_regs))
break;
+ if (addr == PT_IAOQ0+4 || addr == PT_IAOQ1+4) {
+ data |= 3; /* ensure userspace privilege */
+ }
if (addr >= PT_FR0 && addr <= PT_FR31 + 4) {
/* Special case, fp regs are 64 bits anyway */
- *(__u64 *) ((char *) task_regs(child) + addr) =
data;
+ *(__u32 *) ((char *) task_regs(child) + addr) =
data;
ret = 0;
}
else if ((addr >= PT_GR1+4 && addr <= PT_GR31+4) ||
[PATCH 4.19 263/271] intel_th: msu: Fix single mode with disabled IOMMU
From: Alexander Shishkin
commit 918b8646497b5dba6ae82d4a7325f01b258972b9 upstream.
Commit 4e0eaf239fb3 ("intel_th: msu: Fix single mode with IOMMU") switched
the single mode code to use dma mapping pages obtained from the page
allocator, but with IOMMU disabled, that may lead to using SWIOTLB bounce
buffers and without additional sync'ing, produces empty trace buffers.
Fix this by using a DMA32 GFP flag to the page allocation in single mode,
as the device supports full 32-bit DMA addressing.
Signed-off-by: Alexander Shishkin
Fixes: 4e0eaf239fb3 ("intel_th: msu: Fix single mode with IOMMU")
Reviewed-by: Andy Shevchenko
Reported-by: Ammy Yi
Cc: stable
Link:
https://lore.kernel.org/r/20190621161930.60785-4-alexander.shish...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/hwtracing/intel_th/msu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hwtracing/intel_th/msu.c
+++ b/drivers/hwtracing/intel_th/msu.c
@@ -632,7 +632,7 @@ static int msc_buffer_contig_alloc(struc
goto err_out;
ret = -ENOMEM;
- page = alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
+ page = alloc_pages(GFP_KERNEL | __GFP_ZERO | GFP_DMA32, order);
if (!page)
goto err_free_sgt;
[PATCH 4.19 264/271] Bluetooth: Add SMP workaround Microsoft Surface Precision Mouse bug
From: Szymon Janc
commit 1d87b88ba26eabd4745e158ecfd87c93a9b51dc2 upstream.
Microsoft Surface Precision Mouse provides bogus identity address when
pairing. It connects with Static Random address but provides Public
Address in SMP Identity Address Information PDU. Address has same
value but type is different. Workaround this by dropping IRK if ID
address discrepancy is detected.
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 75
Role: Master (0x00)
Peer address type: Random (0x01)
Peer address: E0:52:33:93:3B:21 (Static)
Connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
> ACL Data RX: Handle 75 flags 0x02 dlen 12
SMP: Identity Address Information (0x09) len 7
Address type: Public (0x00)
Address: E0:52:33:93:3B:21
Signed-off-by: Szymon Janc
Tested-by: Maarten Fonville
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199461
Cc: sta...@vger.kernel.org
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman
---
net/bluetooth/smp.c | 13 +
1 file changed, 13 insertions(+)
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -2580,6 +2580,19 @@ static int smp_cmd_ident_addr_info(struc
goto distribute;
}
+ /* Drop IRK if peer is using identity address during pairing but is
+* providing different address as identity information.
+*
+* Microsoft Surface Precision Mouse is known to have this bug.
+*/
+ if (hci_is_identity_address(&hcon->dst, hcon->dst_type) &&
+ (bacmp(&info->bdaddr, &hcon->dst) ||
+info->addr_type != hcon->dst_type)) {
+ bt_dev_err(hcon->hdev,
+ "ignoring IRK with invalid identity address");
+ goto distribute;
+ }
+
bacpy(&smp->id_addr, &info->bdaddr);
smp->id_addr_type = info->addr_type;
