2021-04-26 07:53:27

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 00/36] 5.10.33-rc1 review

This is the start of the stable review cycle for the 5.10.33 release.
There are 36 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.33-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 5.10.33-rc1

Mike Galbraith <[email protected]>
x86/crash: Fix crash_setup_memmap_entries() out-of-bounds access

John Paul Adrian Glaubitz <[email protected]>
ia64: tools: remove duplicate definition of ia64_mf() on ia64

Randy Dunlap <[email protected]>
ia64: fix discontig.c section mismatches

Randy Dunlap <[email protected]>
csky: change a Kconfig symbol name to fix e1000 build error

Arnd Bergmann <[email protected]>
kasan: fix hwasan build for gcc

Wan Jiabing <[email protected]>
cavium/liquidio: Fix duplicate argument

Michael Brown <[email protected]>
xen-netback: Check for hotplug-status existence before watching

Jisheng Zhang <[email protected]>
arm64: kprobes: Restore local irqflag if kprobes is cancelled

Vasily Gorbik <[email protected]>
s390/entry: save the caller of psw_idle

Dinghao Liu <[email protected]>
dmaengine: tegra20: Fix runtime PM imbalance on error

Phillip Potter <[email protected]>
net: geneve: check skb is large enough for IPv4/IPv6 header

Tony Lindgren <[email protected]>
ARM: dts: Fix swapped mmc order for omap3

Laurent Pinchart <[email protected]>
dmaengine: xilinx: dpdma: Fix race condition in done IRQ

Laurent Pinchart <[email protected]>
dmaengine: xilinx: dpdma: Fix descriptor issuing on video group

Shawn Guo <[email protected]>
soc: qcom: geni: shield geni_icc_get() for ACPI boot

Jiapeng Zhong <[email protected]>
HID: wacom: Assign boolean values to a bool variable

Douglas Gilbert <[email protected]>
HID cp2112: fix support for multiple gpiochips

Jia-Ju Bai <[email protected]>
HID: alps: fix error return code in alps_input_configured()

Shou-Chieh Hsu <[email protected]>
HID: google: add don USB id

Zhen Lei <[email protected]>
perf map: Fix error return code in maps__clone()

Leo Yan <[email protected]>
perf auxtrace: Fix potential NULL pointer dereference

Jim Mattson <[email protected]>
perf/x86/kvm: Fix Broadwell Xeon stepping in isolation_ucodes[]

Kan Liang <[email protected]>
perf/x86/intel/uncore: Remove uncore extra PCI dev HSWEP_PCI_PCU_3

Ali Saidi <[email protected]>
locking/qrwlock: Fix ordering in queued_write_lock_slowpath()

Daniel Borkmann <[email protected]>
bpf: Tighten speculative pointer arithmetic mask

Daniel Borkmann <[email protected]>
bpf: Refactor and streamline bounds check into helper

Andrei Matei <[email protected]>
bpf: Allow variable-offset stack access

Yonghong Song <[email protected]>
bpf: Permits pointers on stack for helper calls

Andre Przywara <[email protected]>
arm64: dts: allwinner: Revert SD card CD GPIO for Pine64-LTS

Andy Shevchenko <[email protected]>
pinctrl: core: Show pin numbers for the controllers with base = 0

Christoph Hellwig <[email protected]>
block: return -EBUSY when there are open partitions in blkdev_reread_part

Yuanyuan Zhong <[email protected]>
pinctrl: lewisburg: Update number of pins in community

Eli Cohen <[email protected]>
vdpa/mlx5: Set err = -ENOMEM in case dma_map_sg_attrs fails

James Bottomley <[email protected]>
KEYS: trusted: Fix TPM reservation for seal/unseal

Tony Lindgren <[email protected]>
gpio: omap: Save and restore sysconfig

Xie Yongji <[email protected]>
vhost-vdpa: protect concurrent access to vhost device iotlb


-------------

Diffstat:

Makefile | 4 +-
arch/arm/boot/dts/omap3.dtsi | 3 +
.../boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 2 +-
arch/arm64/kernel/probes/kprobes.c | 6 +-
arch/csky/Kconfig | 2 +-
arch/csky/include/asm/page.h | 2 +-
arch/ia64/mm/discontig.c | 6 +-
arch/s390/kernel/entry.S | 1 +
arch/x86/events/intel/core.c | 2 +-
arch/x86/events/intel/uncore_snbep.c | 61 +-
arch/x86/kernel/crash.c | 2 +-
block/ioctl.c | 2 +
drivers/dma/tegra20-apb-dma.c | 4 +-
drivers/dma/xilinx/xilinx_dpdma.c | 31 +-
drivers/gpio/gpio-omap.c | 9 +
drivers/hid/hid-alps.c | 1 +
drivers/hid/hid-cp2112.c | 22 +-
drivers/hid/hid-google-hammer.c | 2 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/wacom_wac.c | 2 +-
drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h | 2 +-
drivers/net/geneve.c | 6 +
drivers/net/xen-netback/xenbus.c | 12 +-
drivers/pinctrl/core.c | 14 +-
drivers/pinctrl/intel/pinctrl-lewisburg.c | 6 +-
drivers/soc/qcom/qcom-geni-se.c | 3 +
drivers/vdpa/mlx5/core/mr.c | 4 +-
drivers/vhost/vdpa.c | 6 +-
include/linux/bpf.h | 5 +
include/linux/bpf_verifier.h | 3 +-
include/linux/platform_data/gpio-omap.h | 3 +
kernel/bpf/verifier.c | 774 ++++++++++++++++-----
kernel/locking/qrwlock.c | 7 +-
scripts/Makefile.kasan | 12 +-
security/keys/trusted-keys/trusted_tpm2.c | 2 +-
tools/arch/ia64/include/asm/barrier.h | 3 -
tools/perf/util/auxtrace.c | 2 +-
tools/perf/util/map.c | 7 +-
38 files changed, 742 insertions(+), 294 deletions(-)



2021-04-26 07:53:30

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 36/36] x86/crash: Fix crash_setup_memmap_entries() out-of-bounds access

From: Mike Galbraith <[email protected]>

commit 5849cdf8c120e3979c57d34be55b92d90a77a47e upstream.

Commit in Fixes: added support for kexec-ing a kernel on panic using a
new system call. As part of it, it does prepare a memory map for the new
kernel.

However, while doing so, it wrongly accesses memory it has not
allocated: it accesses the first element of the cmem->ranges[] array in
memmap_exclude_ranges() but it has not allocated the memory for it in
crash_setup_memmap_entries(). As KASAN reports:

BUG: KASAN: vmalloc-out-of-bounds in crash_setup_memmap_entries+0x17e/0x3a0
Write of size 8 at addr ffffc90000426008 by task kexec/1187

(gdb) list *crash_setup_memmap_entries+0x17e
0xffffffff8107cafe is in crash_setup_memmap_entries (arch/x86/kernel/crash.c:322).
317 unsigned long long mend)
318 {
319 unsigned long start, end;
320
321 cmem->ranges[0].start = mstart;
322 cmem->ranges[0].end = mend;
323 cmem->nr_ranges = 1;
324
325 /* Exclude elf header region */
326 start = image->arch.elf_load_addr;
(gdb)

Make sure the ranges array becomes a single element allocated.

[ bp: Write a proper commit message. ]

Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Mike Galbraith <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Dave Young <[email protected]>
Cc: <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/crash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -337,7 +337,7 @@ int crash_setup_memmap_entries(struct ki
struct crash_memmap_data cmd;
struct crash_mem *cmem;

- cmem = vzalloc(sizeof(struct crash_mem));
+ cmem = vzalloc(struct_size(cmem, ranges, 1));
if (!cmem)
return -ENOMEM;



2021-04-26 07:53:49

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 18/36] HID: google: add don USB id

From: Shou-Chieh Hsu <[email protected]>

[ Upstream commit 36b87cf302a4f13f8b4344bcf98f67405a145e2f ]

Add 1 additional hammer-like device.

Signed-off-by: Shou-Chieh Hsu <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/hid/hid-google-hammer.c | 2 ++
drivers/hid/hid-ids.h | 1 +
2 files changed, 3 insertions(+)

diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 85a054f1ce38..2a176f77b32e 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -526,6 +526,8 @@ static void hammer_remove(struct hid_device *hdev)
}

static const struct hid_device_id hammer_devices[] = {
+ { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
+ USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_DON) },
{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER) },
{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 06813f297dcc..b93ce0d475e0 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -486,6 +486,7 @@
#define USB_DEVICE_ID_GOOGLE_MASTERBALL 0x503c
#define USB_DEVICE_ID_GOOGLE_MAGNEMITE 0x503d
#define USB_DEVICE_ID_GOOGLE_MOONBALL 0x5044
+#define USB_DEVICE_ID_GOOGLE_DON 0x5050

#define USB_VENDOR_ID_GOTOP 0x08f2
#define USB_DEVICE_ID_SUPER_Q2 0x007f
--
2.30.2



2021-04-26 07:53:50

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 27/36] dmaengine: tegra20: Fix runtime PM imbalance on error

From: Dinghao Liu <[email protected]>

[ Upstream commit 917a3200b9f467a154999c7572af345f2470aaf4 ]

pm_runtime_get_sync() will increase the runtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.

Signed-off-by: Dinghao Liu <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/dma/tegra20-apb-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 71827d9b0aa1..b7260749e8ee 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -723,7 +723,7 @@ static void tegra_dma_issue_pending(struct dma_chan *dc)
goto end;
}
if (!tdc->busy) {
- err = pm_runtime_get_sync(tdc->tdma->dev);
+ err = pm_runtime_resume_and_get(tdc->tdma->dev);
if (err < 0) {
dev_err(tdc2dev(tdc), "Failed to enable DMA\n");
goto end;
@@ -818,7 +818,7 @@ static void tegra_dma_synchronize(struct dma_chan *dc)
struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
int err;

- err = pm_runtime_get_sync(tdc->tdma->dev);
+ err = pm_runtime_resume_and_get(tdc->tdma->dev);
if (err < 0) {
dev_err(tdc2dev(tdc), "Failed to synchronize DMA: %d\n", err);
return;
--
2.30.2



2021-04-26 07:55:52

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 32/36] kasan: fix hwasan build for gcc

From: Arnd Bergmann <[email protected]>

[ Upstream commit 5c595ac4c776c44b5c59de22ab43b3fe256d9fbb ]

gcc-11 adds support for -fsanitize=kernel-hwaddress, so it becomes
possible to enable CONFIG_KASAN_SW_TAGS.

Unfortunately this fails to build at the moment, because the
corresponding command line arguments use llvm specific syntax.

Change it to use the cc-param macro instead, which works on both clang
and gcc.

[[email protected]: fixup for "kasan: fix hwasan build for gcc"]
Link: https://lkml.kernel.org/r/YHQZVfVVLE/[email protected]

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Marco Elver <[email protected]>
Reviewed-by: Marco Elver <[email protected]>
Acked-by: Andrey Konovalov <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Michal Marek <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
scripts/Makefile.kasan | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 1e000cc2e7b4..127012f45166 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -2,6 +2,8 @@
CFLAGS_KASAN_NOSANITIZE := -fno-builtin
KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)

+cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
+
ifdef CONFIG_KASAN_GENERIC

ifdef CONFIG_KASAN_INLINE
@@ -12,8 +14,6 @@ endif

CFLAGS_KASAN_MINIMAL := -fsanitize=kernel-address

-cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
-
# -fasan-shadow-offset fails without -fsanitize
CFLAGS_KASAN_SHADOW := $(call cc-option, -fsanitize=kernel-address \
-fasan-shadow-offset=$(KASAN_SHADOW_OFFSET), \
@@ -36,14 +36,14 @@ endif # CONFIG_KASAN_GENERIC
ifdef CONFIG_KASAN_SW_TAGS

ifdef CONFIG_KASAN_INLINE
- instrumentation_flags := -mllvm -hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET)
+ instrumentation_flags := $(call cc-param,hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET))
else
- instrumentation_flags := -mllvm -hwasan-instrument-with-calls=1
+ instrumentation_flags := $(call cc-param,hwasan-instrument-with-calls=1)
endif

CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
- -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
- -mllvm -hwasan-use-short-granules=0 \
+ $(call cc-param,hwasan-instrument-stack=$(CONFIG_KASAN_STACK)) \
+ $(call cc-param,hwasan-use-short-granules=0) \
$(instrumentation_flags)

endif # CONFIG_KASAN_SW_TAGS
--
2.30.2



2021-04-26 07:55:52

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 09/36] bpf: Permits pointers on stack for helper calls

From: Yonghong Song <[email protected]>

[ Upstream commit cd17d38f8b28f808c368121041c0a4fa91757e0d ]

Currently, when checking stack memory accessed by helper calls,
for spills, only PTR_TO_BTF_ID and SCALAR_VALUE are
allowed.

Song discovered an issue where the below bpf program
int dump_task(struct bpf_iter__task *ctx)
{
struct seq_file *seq = ctx->meta->seq;
static char[] info = "abc";
BPF_SEQ_PRINTF(seq, "%s\n", info);
return 0;
}
may cause a verifier failure.

The verifier output looks like:
; struct seq_file *seq = ctx->meta->seq;
1: (79) r1 = *(u64 *)(r1 +0)
; BPF_SEQ_PRINTF(seq, "%s\n", info);
2: (18) r2 = 0xffff9054400f6000
4: (7b) *(u64 *)(r10 -8) = r2
5: (bf) r4 = r10
;
6: (07) r4 += -8
; BPF_SEQ_PRINTF(seq, "%s\n", info);
7: (18) r2 = 0xffff9054400fe000
9: (b4) w3 = 4
10: (b4) w5 = 8
11: (85) call bpf_seq_printf#126
R1_w=ptr_seq_file(id=0,off=0,imm=0) R2_w=map_value(id=0,off=0,ks=4,vs=4,imm=0)
R3_w=inv4 R4_w=fp-8 R5_w=inv8 R10=fp0 fp-8_w=map_value
last_idx 11 first_idx 0
regs=8 stack=0 before 10: (b4) w5 = 8
regs=8 stack=0 before 9: (b4) w3 = 4
invalid indirect read from stack off -8+0 size 8

Basically, the verifier complains the map_value pointer at "fp-8" location.
To fix the issue, if env->allow_ptr_leaks is true, let us also permit
pointers on the stack to be accessible by the helper.

Reported-by: Song Liu <[email protected]>
Suggested-by: Alexei Starovoitov <[email protected]>
Signed-off-by: Yonghong Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Song Liu <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/bpf/verifier.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 3370f0d476e9..2e09e691a6be 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3759,7 +3759,8 @@ static int check_stack_boundary(struct bpf_verifier_env *env, int regno,
goto mark;

if (state->stack[spi].slot_type[0] == STACK_SPILL &&
- state->stack[spi].spilled_ptr.type == SCALAR_VALUE) {
+ (state->stack[spi].spilled_ptr.type == SCALAR_VALUE ||
+ env->allow_ptr_leaks)) {
__mark_reg_unknown(env, &state->stack[spi].spilled_ptr);
for (j = 0; j < BPF_REG_SIZE; j++)
state->stack[spi].slot_type[j] = STACK_MISC;
--
2.30.2



2021-04-26 07:55:52

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 07/36] pinctrl: core: Show pin numbers for the controllers with base = 0

From: Andy Shevchenko <[email protected]>

[ Upstream commit 482715ff0601c836152b792f06c353464d826b9b ]

The commit f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file")
enabled GPIO pin number and label in debugfs for pin controller. However,
it limited that feature to the chips where base is positive number. This,
in particular, excluded chips where base is 0 for the historical or backward
compatibility reasons. Refactor the code to include the latter as well.

Fixes: f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file")
Cc: Drew Fustini <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Tested-by: Drew Fustini <[email protected]>
Reviewed-by: Drew Fustini <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/pinctrl/core.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 9fc4433fece4..20b477cd5a30 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1604,8 +1604,8 @@ static int pinctrl_pins_show(struct seq_file *s, void *what)
unsigned i, pin;
#ifdef CONFIG_GPIOLIB
struct pinctrl_gpio_range *range;
- unsigned int gpio_num;
struct gpio_chip *chip;
+ int gpio_num;
#endif

seq_printf(s, "registered pins: %d\n", pctldev->desc->npins);
@@ -1625,7 +1625,7 @@ static int pinctrl_pins_show(struct seq_file *s, void *what)
seq_printf(s, "pin %d (%s) ", pin, desc->name);

#ifdef CONFIG_GPIOLIB
- gpio_num = 0;
+ gpio_num = -1;
list_for_each_entry(range, &pctldev->gpio_ranges, node) {
if ((pin >= range->pin_base) &&
(pin < (range->pin_base + range->npins))) {
@@ -1633,10 +1633,12 @@ static int pinctrl_pins_show(struct seq_file *s, void *what)
break;
}
}
- chip = gpio_to_chip(gpio_num);
- if (chip && chip->gpiodev && chip->gpiodev->base)
- seq_printf(s, "%u:%s ", gpio_num -
- chip->gpiodev->base, chip->label);
+ if (gpio_num >= 0)
+ chip = gpio_to_chip(gpio_num);
+ else
+ chip = NULL;
+ if (chip)
+ seq_printf(s, "%u:%s ", gpio_num - chip->gpiodev->base, chip->label);
else
seq_puts(s, "0:? ");
#endif
--
2.30.2



2021-04-26 07:55:53

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 31/36] cavium/liquidio: Fix duplicate argument

From: Wan Jiabing <[email protected]>

[ Upstream commit 416dcc5ce9d2a810477171c62ffa061a98f87367 ]

Fix the following coccicheck warning:

./drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h:413:6-28:
duplicated argument to & or |

The CN6XXX_INTR_M1UPB0_ERR here is duplicate.
Here should be CN6XXX_INTR_M1UNB0_ERR.

Signed-off-by: Wan Jiabing <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h b/drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h
index b248966837b4..7aad40b2aa73 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h
+++ b/drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h
@@ -412,7 +412,7 @@
| CN6XXX_INTR_M0UNWI_ERR \
| CN6XXX_INTR_M1UPB0_ERR \
| CN6XXX_INTR_M1UPWI_ERR \
- | CN6XXX_INTR_M1UPB0_ERR \
+ | CN6XXX_INTR_M1UNB0_ERR \
| CN6XXX_INTR_M1UNWI_ERR \
| CN6XXX_INTR_INSTR_DB_OF_ERR \
| CN6XXX_INTR_SLIST_DB_OF_ERR \
--
2.30.2



2021-04-26 07:56:03

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 02/36] gpio: omap: Save and restore sysconfig

From: Tony Lindgren <[email protected]>

[ Upstream commit ddd8d94ca31e768c76cf8bfe34ba7b10136b3694 ]

As we are using cpu_pm to save and restore context, we must also save and
restore the GPIO sysconfig register. This is needed because we are not
calling PM runtime functions at all with cpu_pm.

We need to save the sysconfig on idle as it's value can get reconfigured by
PM runtime and can be different from the init time value. Device specific
flags like "ti,no-idle-on-init" can affect the init value.

Fixes: b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")
Cc: Aaro Koskinen <[email protected]>
Cc: Adam Ford <[email protected]>
Cc: Andreas Kemnade <[email protected]>
Cc: Grygorii Strashko <[email protected]>
Cc: Peter Ujfalusi <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Acked-by: Grygorii Strashko <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpio/gpio-omap.c | 9 +++++++++
include/linux/platform_data/gpio-omap.h | 3 +++
2 files changed, 12 insertions(+)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f7ceb2b11afc..a7e8ed5191a8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -29,6 +29,7 @@
#define OMAP4_GPIO_DEBOUNCINGTIME_MASK 0xFF

struct gpio_regs {
+ u32 sysconfig;
u32 irqenable1;
u32 irqenable2;
u32 wake_en;
@@ -1072,6 +1073,7 @@ static void omap_gpio_init_context(struct gpio_bank *p)
const struct omap_gpio_reg_offs *regs = p->regs;
void __iomem *base = p->base;

+ p->context.sysconfig = readl_relaxed(base + regs->sysconfig);
p->context.ctrl = readl_relaxed(base + regs->ctrl);
p->context.oe = readl_relaxed(base + regs->direction);
p->context.wake_en = readl_relaxed(base + regs->wkup_en);
@@ -1091,6 +1093,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
const struct omap_gpio_reg_offs *regs = bank->regs;
void __iomem *base = bank->base;

+ writel_relaxed(bank->context.sysconfig, base + regs->sysconfig);
writel_relaxed(bank->context.wake_en, base + regs->wkup_en);
writel_relaxed(bank->context.ctrl, base + regs->ctrl);
writel_relaxed(bank->context.leveldetect0, base + regs->leveldetect0);
@@ -1118,6 +1121,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)

bank->saved_datain = readl_relaxed(base + bank->regs->datain);

+ /* Save syconfig, it's runtime value can be different from init value */
+ if (bank->loses_context)
+ bank->context.sysconfig = readl_relaxed(base + bank->regs->sysconfig);
+
if (!bank->enabled_non_wakeup_gpios)
goto update_gpio_context_count;

@@ -1282,6 +1289,7 @@ static int gpio_omap_cpu_notifier(struct notifier_block *nb,

static const struct omap_gpio_reg_offs omap2_gpio_regs = {
.revision = OMAP24XX_GPIO_REVISION,
+ .sysconfig = OMAP24XX_GPIO_SYSCONFIG,
.direction = OMAP24XX_GPIO_OE,
.datain = OMAP24XX_GPIO_DATAIN,
.dataout = OMAP24XX_GPIO_DATAOUT,
@@ -1305,6 +1313,7 @@ static const struct omap_gpio_reg_offs omap2_gpio_regs = {

static const struct omap_gpio_reg_offs omap4_gpio_regs = {
.revision = OMAP4_GPIO_REVISION,
+ .sysconfig = OMAP4_GPIO_SYSCONFIG,
.direction = OMAP4_GPIO_OE,
.datain = OMAP4_GPIO_DATAIN,
.dataout = OMAP4_GPIO_DATAOUT,
diff --git a/include/linux/platform_data/gpio-omap.h b/include/linux/platform_data/gpio-omap.h
index 8b30b14b47d3..f377817ce75c 100644
--- a/include/linux/platform_data/gpio-omap.h
+++ b/include/linux/platform_data/gpio-omap.h
@@ -85,6 +85,7 @@
* omap2+ specific GPIO registers
*/
#define OMAP24XX_GPIO_REVISION 0x0000
+#define OMAP24XX_GPIO_SYSCONFIG 0x0010
#define OMAP24XX_GPIO_IRQSTATUS1 0x0018
#define OMAP24XX_GPIO_IRQSTATUS2 0x0028
#define OMAP24XX_GPIO_IRQENABLE2 0x002c
@@ -108,6 +109,7 @@
#define OMAP24XX_GPIO_SETDATAOUT 0x0094

#define OMAP4_GPIO_REVISION 0x0000
+#define OMAP4_GPIO_SYSCONFIG 0x0010
#define OMAP4_GPIO_EOI 0x0020
#define OMAP4_GPIO_IRQSTATUSRAW0 0x0024
#define OMAP4_GPIO_IRQSTATUSRAW1 0x0028
@@ -148,6 +150,7 @@
#ifndef __ASSEMBLER__
struct omap_gpio_reg_offs {
u16 revision;
+ u16 sysconfig;
u16 direction;
u16 datain;
u16 dataout;
--
2.30.2



2021-04-26 07:56:32

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 24/36] dmaengine: xilinx: dpdma: Fix race condition in done IRQ

From: Laurent Pinchart <[email protected]>

[ Upstream commit 868833fbffbe51c487df4f95d4de9194264a4b30 ]

The active descriptor pointer is accessed from different contexts,
including different interrupt handlers, and its access must be protected
by the channel's lock. This wasn't done in the done IRQ handler. Fix it.

Signed-off-by: Laurent Pinchart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/dma/xilinx/xilinx_dpdma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c
index d504112c609e..70b29bd079c9 100644
--- a/drivers/dma/xilinx/xilinx_dpdma.c
+++ b/drivers/dma/xilinx/xilinx_dpdma.c
@@ -1048,13 +1048,14 @@ static int xilinx_dpdma_chan_stop(struct xilinx_dpdma_chan *chan)
*/
static void xilinx_dpdma_chan_done_irq(struct xilinx_dpdma_chan *chan)
{
- struct xilinx_dpdma_tx_desc *active = chan->desc.active;
+ struct xilinx_dpdma_tx_desc *active;
unsigned long flags;

spin_lock_irqsave(&chan->lock, flags);

xilinx_dpdma_debugfs_desc_done_irq(chan);

+ active = chan->desc.active;
if (active)
vchan_cyclic_callback(&active->vdesc);
else
--
2.30.2



2021-04-26 07:56:48

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 30/36] xen-netback: Check for hotplug-status existence before watching

From: Michael Brown <[email protected]>

[ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ]

The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist. This assumption is incorrect: xenstore does allow a watch to
be registered for a nonexistent node (and will send notifications
should the node be subsequently created).

As of commit 1f2565780 ("xen-netback: remove 'hotplug-status' once it
has served its purpose"), this leads to a failure when a domU
transitions into XenbusStateConnected more than once. On the first
domU transition into Connected state, the "hotplug-status" node will
be deleted by the hotplug_status_changed() callback in dom0. On the
second or subsequent domU transition into Connected state, the
hotplug_status_changed() callback will therefore never be invoked, and
so the backend will remain stuck in InitWait.

This failure prevents scenarios such as reloading the xen-netfront
module within a domU, or booting a domU via iPXE. There is
unfortunately no way for the domU to work around this dom0 bug.

Fix by explicitly checking for existence of the "hotplug-status" node,
thereby creating the behaviour that was previously assumed to exist.

Signed-off-by: Michael Brown <[email protected]>
Reviewed-by: Paul Durrant <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/xen-netback/xenbus.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 6f10e0998f1c..94d19158efc1 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -824,11 +824,15 @@ static void connect(struct backend_info *be)
xenvif_carrier_on(be->vif);

unregister_hotplug_status_watch(be);
- err = xenbus_watch_pathfmt(dev, &be->hotplug_status_watch, NULL,
- hotplug_status_changed,
- "%s/%s", dev->nodename, "hotplug-status");
- if (!err)
+ if (xenbus_exists(XBT_NIL, dev->nodename, "hotplug-status")) {
+ err = xenbus_watch_pathfmt(dev, &be->hotplug_status_watch,
+ NULL, hotplug_status_changed,
+ "%s/%s", dev->nodename,
+ "hotplug-status");
+ if (err)
+ goto err;
be->have_hotplug_status_watch = 1;
+ }

netif_tx_wake_all_queues(be->vif->dev);

--
2.30.2



2021-04-26 07:57:00

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 26/36] net: geneve: check skb is large enough for IPv4/IPv6 header

From: Phillip Potter <[email protected]>

[ Upstream commit 6628ddfec7580882f11fdc5c194a8ea781fdadfa ]

Check within geneve_xmit_skb/geneve6_xmit_skb that sk_buff structure
is large enough to include IPv4 or IPv6 header, and reject if not. The
geneve_xmit_skb portion and overall idea was contributed by Eric Dumazet.
Fixes a KMSAN-found uninit-value bug reported by syzbot at:
https://syzkaller.appspot.com/bug?id=abe95dc3e3e9667fc23b8d81f29ecad95c6f106f

Suggested-by: Eric Dumazet <[email protected]>
Reported-by: [email protected]
Signed-off-by: Phillip Potter <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/geneve.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index abd37f26af68..11864ac101b8 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -890,6 +890,9 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
__be16 sport;
int err;

+ if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+ return -EINVAL;
+
sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
rt = geneve_get_v4_rt(skb, dev, gs4, &fl4, info,
geneve->cfg.info.key.tp_dst, sport);
@@ -984,6 +987,9 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
__be16 sport;
int err;

+ if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+ return -EINVAL;
+
sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
dst = geneve_get_v6_dst(skb, dev, gs6, &fl6, info,
geneve->cfg.info.key.tp_dst, sport);
--
2.30.2



2021-04-26 07:57:26

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 33/36] csky: change a Kconfig symbol name to fix e1000 build error

From: Randy Dunlap <[email protected]>

[ Upstream commit d199161653d612b8fb96ac51bfd5b2d2782ecef3 ]

e1000's #define of CONFIG_RAM_BASE conflicts with a Kconfig symbol in
arch/csky/Kconfig.

The symbol in e1000 has been around longer, so change arch/csky/ to use
DRAM_BASE instead of RAM_BASE to remove the conflict. (although e1000
is also a 2-line change)

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Randy Dunlap <[email protected]>
Reported-by: kernel test robot <[email protected]>
Acked-by: Guo Ren <[email protected]>
Cc: Jesse Brandeburg <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/csky/Kconfig | 2 +-
arch/csky/include/asm/page.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
index 268fad5f51cf..7bf0a617e94c 100644
--- a/arch/csky/Kconfig
+++ b/arch/csky/Kconfig
@@ -292,7 +292,7 @@ config FORCE_MAX_ZONEORDER
int "Maximum zone order"
default "11"

-config RAM_BASE
+config DRAM_BASE
hex "DRAM start addr (the same with memory-section in dts)"
default 0x0

diff --git a/arch/csky/include/asm/page.h b/arch/csky/include/asm/page.h
index 9b98bf31d57c..16878240ef9a 100644
--- a/arch/csky/include/asm/page.h
+++ b/arch/csky/include/asm/page.h
@@ -28,7 +28,7 @@
#define SSEG_SIZE 0x20000000
#define LOWMEM_LIMIT (SSEG_SIZE * 2)

-#define PHYS_OFFSET_OFFSET (CONFIG_RAM_BASE & (SSEG_SIZE - 1))
+#define PHYS_OFFSET_OFFSET (CONFIG_DRAM_BASE & (SSEG_SIZE - 1))

#ifndef __ASSEMBLY__

--
2.30.2



2021-04-26 14:26:31

by Fox Chen

[permalink] [raw]
Subject: RE: [PATCH 5.10 00/36] 5.10.33-rc1 review

On Mon, 26 Apr 2021 09:29:42 +0200, Greg Kroah-Hartman <[email protected]> wrote:
> This is the start of the stable review cycle for the 5.10.33 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.33-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

5.10.33-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)

Tested-by: Fox Chen <[email protected]>

2021-04-26 15:52:18

by Patrick Mccormick

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/36] 5.10.33-rc1 review

We ran tests on this kernel version:

Linux version 5.10.33-rc1-1-generic
(root@9eabe40e-b732-44f1-4800-0b445d85332c) (gcc (Ubuntu
7.3.0-27ubuntu1~18.04) 7.3.0, GNU ld (GNU Binutils for Ubuntu) 2.30)
#0964102fc SMP Mon Apr 26 07:21:26 UTC 2021

With this hardware:

model name : Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz

And there were no failures.

Specific tests ran:

1..40
ok 1 ltp.py:LTP.test_nptl
ok 2 ltp.py:LTP.test_math
ok 3 ltp.py:LTP.test_dio
ok 4 ltp.py:LTP.test_io
ok 5 ltp.py:LTP.test_power_management_tests
ok 6 ltp.py:LTP.test_can
ok 7 ltp.py:LTP.test_input
ok 8 ltp.py:LTP.test_hugetlb
ok 9 ltp.py:LTP.test_ipc
ok 10 ltp.py:LTP.test_uevent
ok 11 ltp.py:LTP.test_smoketest
ok 12 ltp.py:LTP.test_containers
ok 13 ltp.py:LTP.test_filecaps
ok 14 ltp.py:LTP.test_sched
ok 15 ltp.py:LTP.test_hyperthreading
ok 16 ltp.py:LTP.test_cap_bounds
ok 17 /home/ci-hypervisor/.local/lib/python3.6/site-packages/fathom/tests/kpatch.sh
ok 18 perf.py:PerfNonPriv.test_perf_help
ok 19 perf.py:PerfNonPriv.test_perf_version
ok 20 perf.py:PerfNonPriv.test_perf_list
ok 21 perf.py:PerfPriv.test_perf_record
ok 22 perf.py:PerfPriv.test_perf_cmd_kallsyms
ok 23 perf.py:PerfPriv.test_perf_cmd_annotate
ok 24 perf.py:PerfPriv.test_perf_cmd_evlist
ok 25 perf.py:PerfPriv.test_perf_cmd_script
ok 26 perf.py:PerfPriv.test_perf_stat
ok 27 perf.py:PerfPriv.test_perf_bench
ok 28 kselftest.py:kselftest.test_sysctl
ok 29 kselftest.py:kselftest.test_size
ok 30 kselftest.py:kselftest.test_sync
ok 31 kselftest.py:kselftest.test_capabilities
ok 32 kselftest.py:kselftest.test_x86
ok 33 kselftest.py:kselftest.test_pidfd
ok 34 kselftest.py:kselftest.test_membarrier
ok 35 kselftest.py:kselftest.test_sigaltstack
ok 36 kselftest.py:kselftest.test_tmpfs
ok 37 kselftest.py:kselftest.test_user
ok 38 kselftest.py:kselftest.test_sched
ok 39 kselftest.py:kselftest.test_timens
ok 40 kselftest.py:kselftest.test_timers

Tested-By: Patrick McCormick <[email protected]>

On Mon, Apr 26, 2021 at 12:44 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.10.33 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.33-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 5.10.33-rc1
>
> Mike Galbraith <[email protected]>
> x86/crash: Fix crash_setup_memmap_entries() out-of-bounds access
>
> John Paul Adrian Glaubitz <[email protected]>
> ia64: tools: remove duplicate definition of ia64_mf() on ia64
>
> Randy Dunlap <[email protected]>
> ia64: fix discontig.c section mismatches
>
> Randy Dunlap <[email protected]>
> csky: change a Kconfig symbol name to fix e1000 build error
>
> Arnd Bergmann <[email protected]>
> kasan: fix hwasan build for gcc
>
> Wan Jiabing <[email protected]>
> cavium/liquidio: Fix duplicate argument
>
> Michael Brown <[email protected]>
> xen-netback: Check for hotplug-status existence before watching
>
> Jisheng Zhang <[email protected]>
> arm64: kprobes: Restore local irqflag if kprobes is cancelled
>
> Vasily Gorbik <[email protected]>
> s390/entry: save the caller of psw_idle
>
> Dinghao Liu <[email protected]>
> dmaengine: tegra20: Fix runtime PM imbalance on error
>
> Phillip Potter <[email protected]>
> net: geneve: check skb is large enough for IPv4/IPv6 header
>
> Tony Lindgren <[email protected]>
> ARM: dts: Fix swapped mmc order for omap3
>
> Laurent Pinchart <[email protected]>
> dmaengine: xilinx: dpdma: Fix race condition in done IRQ
>
> Laurent Pinchart <[email protected]>
> dmaengine: xilinx: dpdma: Fix descriptor issuing on video group
>
> Shawn Guo <[email protected]>
> soc: qcom: geni: shield geni_icc_get() for ACPI boot
>
> Jiapeng Zhong <[email protected]>
> HID: wacom: Assign boolean values to a bool variable
>
> Douglas Gilbert <[email protected]>
> HID cp2112: fix support for multiple gpiochips
>
> Jia-Ju Bai <[email protected]>
> HID: alps: fix error return code in alps_input_configured()
>
> Shou-Chieh Hsu <[email protected]>
> HID: google: add don USB id
>
> Zhen Lei <[email protected]>
> perf map: Fix error return code in maps__clone()
>
> Leo Yan <[email protected]>
> perf auxtrace: Fix potential NULL pointer dereference
>
> Jim Mattson <[email protected]>
> perf/x86/kvm: Fix Broadwell Xeon stepping in isolation_ucodes[]
>
> Kan Liang <[email protected]>
> perf/x86/intel/uncore: Remove uncore extra PCI dev HSWEP_PCI_PCU_3
>
> Ali Saidi <[email protected]>
> locking/qrwlock: Fix ordering in queued_write_lock_slowpath()
>
> Daniel Borkmann <[email protected]>
> bpf: Tighten speculative pointer arithmetic mask
>
> Daniel Borkmann <[email protected]>
> bpf: Refactor and streamline bounds check into helper
>
> Andrei Matei <[email protected]>
> bpf: Allow variable-offset stack access
>
> Yonghong Song <[email protected]>
> bpf: Permits pointers on stack for helper calls
>
> Andre Przywara <[email protected]>
> arm64: dts: allwinner: Revert SD card CD GPIO for Pine64-LTS
>
> Andy Shevchenko <[email protected]>
> pinctrl: core: Show pin numbers for the controllers with base = 0
>
> Christoph Hellwig <[email protected]>
> block: return -EBUSY when there are open partitions in blkdev_reread_part
>
> Yuanyuan Zhong <[email protected]>
> pinctrl: lewisburg: Update number of pins in community
>
> Eli Cohen <[email protected]>
> vdpa/mlx5: Set err = -ENOMEM in case dma_map_sg_attrs fails
>
> James Bottomley <[email protected]>
> KEYS: trusted: Fix TPM reservation for seal/unseal
>
> Tony Lindgren <[email protected]>
> gpio: omap: Save and restore sysconfig
>
> Xie Yongji <[email protected]>
> vhost-vdpa: protect concurrent access to vhost device iotlb
>
>
> -------------
>
> Diffstat:
>
> Makefile | 4 +-
> arch/arm/boot/dts/omap3.dtsi | 3 +
> .../boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 2 +-
> arch/arm64/kernel/probes/kprobes.c | 6 +-
> arch/csky/Kconfig | 2 +-
> arch/csky/include/asm/page.h | 2 +-
> arch/ia64/mm/discontig.c | 6 +-
> arch/s390/kernel/entry.S | 1 +
> arch/x86/events/intel/core.c | 2 +-
> arch/x86/events/intel/uncore_snbep.c | 61 +-
> arch/x86/kernel/crash.c | 2 +-
> block/ioctl.c | 2 +
> drivers/dma/tegra20-apb-dma.c | 4 +-
> drivers/dma/xilinx/xilinx_dpdma.c | 31 +-
> drivers/gpio/gpio-omap.c | 9 +
> drivers/hid/hid-alps.c | 1 +
> drivers/hid/hid-cp2112.c | 22 +-
> drivers/hid/hid-google-hammer.c | 2 +
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/wacom_wac.c | 2 +-
> drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h | 2 +-
> drivers/net/geneve.c | 6 +
> drivers/net/xen-netback/xenbus.c | 12 +-
> drivers/pinctrl/core.c | 14 +-
> drivers/pinctrl/intel/pinctrl-lewisburg.c | 6 +-
> drivers/soc/qcom/qcom-geni-se.c | 3 +
> drivers/vdpa/mlx5/core/mr.c | 4 +-
> drivers/vhost/vdpa.c | 6 +-
> include/linux/bpf.h | 5 +
> include/linux/bpf_verifier.h | 3 +-
> include/linux/platform_data/gpio-omap.h | 3 +
> kernel/bpf/verifier.c | 774 ++++++++++++++++-----
> kernel/locking/qrwlock.c | 7 +-
> scripts/Makefile.kasan | 12 +-
> security/keys/trusted-keys/trusted_tpm2.c | 2 +-
> tools/arch/ia64/include/asm/barrier.h | 3 -
> tools/perf/util/auxtrace.c | 2 +-
> tools/perf/util/map.c | 7 +-
> 38 files changed, 742 insertions(+), 294 deletions(-)
>
>

2021-04-26 16:56:15

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/36] 5.10.33-rc1 review

On 4/26/21 12:29 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.33 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.33-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels:

Tested-by: Florian Fainelli <[email protected]>
--
Florian

2021-04-26 18:37:18

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/36] 5.10.33-rc1 review

On Mon, Apr 26, 2021 at 09:29:42AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.33 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 156 pass: 156 fail: 0
Qemu test results:
total: 455 pass: 455 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter

2021-04-26 20:35:20

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/36] 5.10.33-rc1 review

Hi Greg,

On Mon, Apr 26, 2021 at 09:29:42AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.33 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
> Anything received after that time might be too late.

Build test:
mips (gcc version 10.3.1 20210419): 63 configs -> no new failure
arm (gcc version 10.3.1 20210419): 105 configs -> no new failure
x86_64 (gcc version 10.2.1 20210110): 2 configs -> no failure

Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression.
arm: Booted on rpi3b. No regression.

Tested-by: Sudip Mukherjee <[email protected]>

--
Regards
Sudip

2021-04-26 23:48:08

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/36] 5.10.33-rc1 review

On 4/26/21 1:29 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.33 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.33-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

Tested-by: Shuah Khan <[email protected]>

thanks,
-- Shuah


2021-04-27 02:17:42

by Zou Wei

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/36] 5.10.33-rc1 review



On 2021/4/26 15:29, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.33 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.33-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Tested on arm64 and x86 for 5.10.33-rc1,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.10.y
Version: 5.10.33-rc1
Commit: f52b4f86deb4f6bcd54159dfce2303f4928de80c
Compiler: gcc version 7.3.0 (GCC)

arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 6304
passed: 6304
failed: 0
timeout: 0
--------------------------------------------------------------------

x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 6304
passed: 6304
failed: 0
timeout: 0
--------------------------------------------------------------------

Tested-by: Hulk Robot <[email protected]>

2021-04-27 06:16:04

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/36] 5.10.33-rc1 review

On Mon, 26 Apr 2021 at 13:10, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.10.33 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.33-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing <[email protected]>

## Build
* kernel: 5.10.33-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.10.y
* git commit: f52b4f86deb4f6bcd54159dfce2303f4928de80c
* git describe: v5.10.32-37-gf52b4f86deb4
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.32-37-gf52b4f86deb4

## No regressions (compared to v5.10.32)

## No fixes (compared to v5.10.32)


## Test result summary
total: 81811, pass: 66606, fail: 2889, skip: 12062, xfail: 254,

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 192 total, 192 passed, 0 failed
* arm64: 26 total, 26 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 25 total, 25 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 45 total, 45 passed, 0 failed
* parisc: 9 total, 9 passed, 0 failed
* powerpc: 27 total, 27 passed, 0 failed
* riscv: 21 total, 21 passed, 0 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 18 total, 18 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 26 total, 26 passed, 0 failed

## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest-
* kselftest-android
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-vsyscall-mode-native-
* kselftest-vsyscall-mode-none-
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

2021-04-27 07:43:08

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/36] 5.10.33-rc1 review

Hi!

> This is the start of the stable review cycle for the 5.10.33 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
> Anything received after that time might be too late.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Tested-by: Pavel Machek (CIP) <[email protected]>

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (794.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2021-04-27 16:09:34

by Andrei Rabusov

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/36] 5.10.33-rc1 review

On Mon, Apr 26, 2021 at 09:29:42AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.33 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 28 Apr 2021 07:28:08 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.33-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

I tested 5.10.33-rc1 on i686 and x86_64. Works fine for me.

The short outlook of the test results:

+------------+---------------+-----------+---------------+
| | | | selftests |
| arch/cfg | compile | boot | [ok/not ok] |
|------------+---------------+-----------+---------------+
| i686 lmc* | yes | yes | [1433/82] |
|------------+---------------+-----------+---------------+
| x86_64 lmc | yes | yes | [1573/74] |
|------------+---------------+-----------+---------------+
| x86_64+tun | yes | yes | [1575/73] |
+------------+---------------+-----------+---------------+

Tested-by: Andrei Rabusov <[email protected]>