From: Paul Kocialkowski contact@paulk.fr
[ Upstream commit ad2091f893bd5dfe2824f0d6819600d120698e9f ]
The Allwinner V3 SoC shares the same base as the V3s but comes with extra pins and features available. As a result, it has its dedicated compatible string (already used in device trees), which is added here.
Signed-off-by: Paul Kocialkowski contact@paulk.fr Signed-off-by: Maxime Ripard maxime@cerno.tech Link: https://lore.kernel.org/r/20201031182137.1879521-2-contact@paulk.fr Signed-off-by: Sasha Levin sashal@kernel.org --- arch/arm/mach-sunxi/sunxi.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c index 933b6930f024f..a0ca5e7a68de2 100644 --- a/arch/arm/mach-sunxi/sunxi.c +++ b/arch/arm/mach-sunxi/sunxi.c @@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] = { "allwinner,sun8i-h2-plus", "allwinner,sun8i-h3", "allwinner,sun8i-r40", + "allwinner,sun8i-v3", "allwinner,sun8i-v3s", NULL, };
From: Sara Sharon sara.sharon@intel.com
[ Upstream commit f495acd8851d7b345e5f0e521b2645b1e1f928a0 ]
In case we have old supplicant, the akm field is uninitialized.
Signed-off-by: Sara Sharon sara.sharon@intel.com Signed-off-by: Luca Coelho luciano.coelho@intel.com Link: https://lore.kernel.org/r/iwlwifi.20201129172929.930f0ab7ebee.Ic546e384efab3... Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- net/wireless/nl80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index dbac5c0995a0f..5bb2316befb98 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -12033,7 +12033,7 @@ static int nl80211_set_rekey_data(struct sk_buff *skb, struct genl_info *info) struct net_device *dev = info->user_ptr[1]; struct wireless_dev *wdev = dev->ieee80211_ptr; struct nlattr *tb[NUM_NL80211_REKEY_DATA]; - struct cfg80211_gtk_rekey_data rekey_data; + struct cfg80211_gtk_rekey_data rekey_data = {}; int err;
if (!info->attrs[NL80211_ATTR_REKEY_DATA])
From: Serge Hallyn shallyn@cisco.com
[ Upstream commit ed9b25d1970a4787ac6a39c2091e63b127ecbfc1 ]
Namespaced file capabilities were introduced in 8db6c34f1dbc . When userspace reads an xattr for a namespaced capability, a virtualized representation of it is returned if the caller is in a user namespace owned by the capability's owning rootid. The function which performs this virtualization was not hooked up if CONFIG_SECURITY=n. Therefore in that case the original xattr was shown instead of the virtualized one.
To test this using libcap-bin (*1),
$ v=$(mktemp) $ unshare -Ur setcap cap_sys_admin-eip $v $ unshare -Ur setcap -v cap_sys_admin-eip $v /tmp/tmp.lSiIFRvt8Y: OK
"setcap -v" verifies the values instead of setting them, and will check whether the rootid value is set. Therefore, with this bug un-fixed, and with CONFIG_SECURITY=n, setcap -v will fail:
$ v=$(mktemp) $ unshare -Ur setcap cap_sys_admin=eip $v $ unshare -Ur setcap -v cap_sys_admin=eip $v nsowner[got=1000, want=0],/tmp/tmp.HHDiOOl9fY differs in []
Fix this bug by calling cap_inode_getsecurity() in security_inode_getsecurity() instead of returning -EOPNOTSUPP, when CONFIG_SECURITY=n.
*1 - note, if libcap is too old for getcap to have the '-n' option, then use verify-caps instead.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209689 Cc: Hervé Guillemet herve@guillemet.org Acked-by: Casey Schaufler casey@schaufler-ca.com Signed-off-by: Serge Hallyn shallyn@cisco.com Signed-off-by: Andrew G. Morgan morgan@kernel.org Signed-off-by: James Morris jamorris@linux.microsoft.com Signed-off-by: Sasha Levin sashal@kernel.org --- include/linux/security.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/security.h b/include/linux/security.h index fd022768e91df..df90399a8af98 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -852,7 +852,7 @@ static inline int security_inode_killpriv(struct dentry *dentry)
static inline int security_inode_getsecurity(struct inode *inode, const char *name, void **buffer, bool alloc) { - return -EOPNOTSUPP; + return cap_inode_getsecurity(inode, name, buffer, alloc); }
static inline int security_inode_setsecurity(struct inode *inode, const char *name, const void *value, size_t size, int flags)
From: Dongdong Wang wangdongdong.6@bytedance.com
[ Upstream commit d9054a1ff585ba01029584ab730efc794603d68f ]
The per-cpu bpf_redirect_info is shared among all skb_do_redirect() and BPF redirect helpers. Callers on RX path are all in BH context, disabling preemption is not sufficient to prevent BH interruption.
In production, we observed strange packet drops because of the race condition between LWT xmit and TC ingress, and we verified this issue is fixed after we disable BH.
Although this bug was technically introduced from the beginning, that is commit 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure"), at that time call_rcu() had to be call_rcu_bh() to match the RCU context. So this patch may not work well before RCU flavor consolidation has been completed around v5.0.
Update the comments above the code too, as call_rcu() is now BH friendly.
Signed-off-by: Dongdong Wang wangdongdong.6@bytedance.com Signed-off-by: Alexei Starovoitov ast@kernel.org Reviewed-by: Cong Wang cong.wang@bytedance.com Link: https://lore.kernel.org/bpf/20201205075946.497763-1-xiyou.wangcong@gmail.com Signed-off-by: Sasha Levin sashal@kernel.org --- net/core/lwt_bpf.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c index 99a6de52b21da..a5502c5aa44e7 100644 --- a/net/core/lwt_bpf.c +++ b/net/core/lwt_bpf.c @@ -39,12 +39,11 @@ static int run_lwt_bpf(struct sk_buff *skb, struct bpf_lwt_prog *lwt, { int ret;
- /* Preempt disable is needed to protect per-cpu redirect_info between - * BPF prog and skb_do_redirect(). The call_rcu in bpf_prog_put() and - * access to maps strictly require a rcu_read_lock() for protection, - * mixing with BH RCU lock doesn't work. + /* Preempt disable and BH disable are needed to protect per-cpu + * redirect_info between BPF prog and skb_do_redirect(). */ preempt_disable(); + local_bh_disable(); bpf_compute_data_pointers(skb); ret = bpf_prog_run_save_cb(lwt->prog, skb);
@@ -78,6 +77,7 @@ static int run_lwt_bpf(struct sk_buff *skb, struct bpf_lwt_prog *lwt, break; }
+ local_bh_enable(); preempt_enable();
return ret;
From: Chris Park Chris.Park@amd.com
[ Upstream commit 80089dd8410f356d5104496d5ab71a66a4f4646b ]
[Why] At very high pixel clock, bandwidth calculation exceeds 32 bit size and overflow value. This causes the resulting selection of link rate to be inaccurate.
[How] Change order of operation and use fixed point to deal with integer accuracy. Also address bug found when forcing link rate.
Signed-off-by: Chris Park Chris.Park@amd.com Reviewed-by: Wenjing Liu Wenjing.Liu@amd.com Acked-by: Eryk Brol eryk.brol@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index 47cefc05fd3f5..f933791f1fbbb 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -2906,11 +2906,14 @@ uint32_t dc_bandwidth_in_kbps_from_timing( { uint32_t bits_per_channel = 0; uint32_t kbps; + struct fixed31_32 link_bw_kbps;
#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT if (timing->flags.DSC) { - kbps = (timing->pix_clk_100hz * timing->dsc_cfg.bits_per_pixel); - kbps = kbps / 160 + ((kbps % 160) ? 1 : 0); + link_bw_kbps = dc_fixpt_from_int(timing->pix_clk_100hz); + link_bw_kbps = dc_fixpt_div_int(link_bw_kbps, 160); + link_bw_kbps = dc_fixpt_mul_int(link_bw_kbps, timing->dsc_cfg.bits_per_pixel); + kbps = dc_fixpt_ceil(link_bw_kbps); return kbps; } #endif
From: Felix Kuehling Felix.Kuehling@amd.com
[ Upstream commit c897934da15f182ce99536007f8ef61c4748c07e ]
Release dmabuf reference before returning from kfd_ioctl_import_dmabuf. amdgpu_amdkfd_gpuvm_import_dmabuf takes a reference to the underlying GEM BO and doesn't keep the reference to the dmabuf wrapper.
Signed-off-by: Felix Kuehling Felix.Kuehling@amd.com Reviewed-by: Kent Russell kent.russell@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c index 1d3cd5c50d5f2..4a0ef9268918c 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c @@ -1664,6 +1664,7 @@ static int kfd_ioctl_import_dmabuf(struct file *filep, }
mutex_unlock(&p->mutex); + dma_buf_put(dmabuf);
args->handle = MAKE_HANDLE(args->gpu_id, idr_handle);
@@ -1673,6 +1674,7 @@ static int kfd_ioctl_import_dmabuf(struct file *filep, amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem *)mem); err_unlock: mutex_unlock(&p->mutex); + dma_buf_put(dmabuf); return r; }
From: Dmitry Torokhov dmitry.torokhov@gmail.com
[ Upstream commit 80db2a087f425b63f0163bc95217abd01c637cb5 ]
To let userspace know what 'scancodes' should be used in EVIOCGKEYCODE and EVIOCSKEYCODE ioctls, we should send EV_MSC/MSC_SCAN events in addition to EV_KEY/KEY_* events. The driver already declared MSC_SCAN capability, so it is only matter of actually sending the events.
Link: https://lore.kernel.org/r/X87aOaSptPTvZ3nZ@google.com Acked-by: Rajat Jain rajatja@google.com Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/input/keyboard/cros_ec_keyb.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c index 8d4d9786cc745..cae262b6ff398 100644 --- a/drivers/input/keyboard/cros_ec_keyb.c +++ b/drivers/input/keyboard/cros_ec_keyb.c @@ -183,6 +183,7 @@ static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev, "changed: [r%d c%d]: byte %02x\n", row, col, new_state);
+ input_event(idev, EV_MSC, MSC_SCAN, pos); input_report_key(idev, keycodes[pos], new_state); }
From: Jean-Philippe Brucker jean-philippe@linaro.org
[ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]
The test fails because of a recent fix to the verifier, even though this program is valid. In details what happens is:
7: (61) r1 = *(u32 *)(r0 +0)
Load a 32-bit value, with signed bounds [S32_MIN, S32_MAX]. The bounds of the 64-bit value are [0, U32_MAX]...
8: (65) if r1 s> 0xffffffff goto pc+1
... therefore this is always true (the operand is sign-extended).
10: (b4) w2 = 11 11: (6d) if r2 s> r1 goto pc+1
When true, the 64-bit bounds become [0, 10]. The 32-bit bounds are still [S32_MIN, 10].
13: (64) w1 <<= 2
Because this is a 32-bit operation, the verifier propagates the new 32-bit bounds to the 64-bit ones, and the knowledge gained from insn 11 is lost.
14: (0f) r0 += r1 15: (7a) *(u64 *)(r0 +0) = 4
Then the verifier considers r0 unbounded here, rejecting the test. To make the test work, change insn 8 to check the sign of the 32-bit value.
Signed-off-by: Jean-Philippe Brucker jean-philippe@linaro.org Acked-by: John Fastabend john.fastabend@gmail.com Signed-off-by: Alexei Starovoitov ast@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- tools/testing/selftests/bpf/verifier/array_access.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/verifier/array_access.c b/tools/testing/selftests/bpf/verifier/array_access.c index f3c33e128709b..a80d806ead15f 100644 --- a/tools/testing/selftests/bpf/verifier/array_access.c +++ b/tools/testing/selftests/bpf/verifier/array_access.c @@ -68,7 +68,7 @@ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 9), BPF_LDX_MEM(BPF_W, BPF_REG_1, BPF_REG_0, 0), - BPF_JMP_IMM(BPF_JSGT, BPF_REG_1, 0xffffffff, 1), + BPF_JMP32_IMM(BPF_JSGT, BPF_REG_1, 0xffffffff, 1), BPF_MOV32_IMM(BPF_REG_1, 0), BPF_MOV32_IMM(BPF_REG_2, MAX_ENTRIES), BPF_JMP_REG(BPF_JSGT, BPF_REG_2, BPF_REG_1, 1),
Hi,
On Sat, Dec 19, 2020 at 10:34:55PM -0500, Sasha Levin wrote:
From: Jean-Philippe Brucker jean-philippe@linaro.org
[ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]
The test fails because of a recent fix to the verifier, even though this
That fix is commit b02709587ea3 ("bpf: Fix propagation of 32-bit signed bounds from 64-bit bounds.") upstream, which only needed backport to 5.9. So although backporting this patch to 5.4 shouldn't break anything, I wouldn't bother.
Thanks, Jean
program is valid. In details what happens is:
7: (61) r1 = *(u32 *)(r0 +0)Load a 32-bit value, with signed bounds [S32_MIN, S32_MAX]. The bounds of the 64-bit value are [0, U32_MAX]...
8: (65) if r1 s> 0xffffffff goto pc+1... therefore this is always true (the operand is sign-extended).
10: (b4) w2 = 11 11: (6d) if r2 s> r1 goto pc+1When true, the 64-bit bounds become [0, 10]. The 32-bit bounds are still [S32_MIN, 10].
13: (64) w1 <<= 2Because this is a 32-bit operation, the verifier propagates the new 32-bit bounds to the 64-bit ones, and the knowledge gained from insn 11 is lost.
14: (0f) r0 += r1 15: (7a) *(u64 *)(r0 +0) = 4Then the verifier considers r0 unbounded here, rejecting the test. To make the test work, change insn 8 to check the sign of the 32-bit value.
Signed-off-by: Jean-Philippe Brucker jean-philippe@linaro.org Acked-by: John Fastabend john.fastabend@gmail.com Signed-off-by: Alexei Starovoitov ast@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
tools/testing/selftests/bpf/verifier/array_access.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/verifier/array_access.c b/tools/testing/selftests/bpf/verifier/array_access.c index f3c33e128709b..a80d806ead15f 100644 --- a/tools/testing/selftests/bpf/verifier/array_access.c +++ b/tools/testing/selftests/bpf/verifier/array_access.c @@ -68,7 +68,7 @@ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 9), BPF_LDX_MEM(BPF_W, BPF_REG_1, BPF_REG_0, 0),
- BPF_JMP_IMM(BPF_JSGT, BPF_REG_1, 0xffffffff, 1),
- BPF_JMP32_IMM(BPF_JSGT, BPF_REG_1, 0xffffffff, 1), BPF_MOV32_IMM(BPF_REG_1, 0), BPF_MOV32_IMM(BPF_REG_2, MAX_ENTRIES), BPF_JMP_REG(BPF_JSGT, BPF_REG_2, BPF_REG_1, 1),
-- 2.27.0
On Sun, Dec 20, 2020 at 01:05:19PM +0100, Jean-Philippe Brucker wrote:
Hi,
On Sat, Dec 19, 2020 at 10:34:55PM -0500, Sasha Levin wrote:
From: Jean-Philippe Brucker jean-philippe@linaro.org
[ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]
The test fails because of a recent fix to the verifier, even though this
That fix is commit b02709587ea3 ("bpf: Fix propagation of 32-bit signed bounds from 64-bit bounds.") upstream, which only needed backport to 5.9. So although backporting this patch to 5.4 shouldn't break anything, I wouldn't bother.
I'll drop it from 5.4, thanks!
From: Arnd Bergmann arnd@arndb.de
[ Upstream commit 55d5b7dd6451b58489ce384282ca5a4a289eb8d5 ]
There is only one function in init/initramfs.c that is in the .text section, and it is marked __weak. When building with clang-12 and the integrated assembler, this leads to a bug with recordmcount:
./scripts/recordmcount "init/initramfs.o" Cannot find symbol for section 2: .text. init/initramfs.o: failed
I'm not quite sure what exactly goes wrong, but I notice that this function is only ever called from an __init function, and normally inlined. Marking it __init as well is clearly correct and it leads to recordmcount no longer complaining.
Link: https://lkml.kernel.org/r/20201204165742.3815221-1-arnd@kernel.org Signed-off-by: Arnd Bergmann arnd@arndb.de Cc: Nathan Chancellor natechancellor@gmail.com Cc: Nick Desaulniers ndesaulniers@google.com Cc: Barret Rhoden brho@google.com Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- init/initramfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/initramfs.c b/init/initramfs.c index 5feee4f616d55..00a32799a38b0 100644 --- a/init/initramfs.c +++ b/init/initramfs.c @@ -527,7 +527,7 @@ extern unsigned long __initramfs_size; #include <linux/initrd.h> #include <linux/kexec.h>
-void __weak free_initrd_mem(unsigned long start, unsigned long end) +void __weak __init free_initrd_mem(unsigned long start, unsigned long end) { free_reserved_area((void *)start, (void *)end, POISON_FREE_INITMEM, "initrd");
From: Simon Beginn linux@simonmicro.de
[ Upstream commit cffdd6d90482316e18d686060a4397902ea04bd2 ]
The touchscreen on the Teclast x98 Pro is also mounted upside-down in relation to the display orientation.
Signed-off-by: Simon Beginn linux@simonmicro.de Signed-off-by: Bastien Nocera hadess@hadess.net Link: https://lore.kernel.org/r/20201117004253.27A5A27EFD@localhost Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/input/touchscreen/goodix.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c index 37b35ab97beb2..bfb945fc33a17 100644 --- a/drivers/input/touchscreen/goodix.c +++ b/drivers/input/touchscreen/goodix.c @@ -137,6 +137,18 @@ static const struct dmi_system_id rotated_screen[] = { DMI_MATCH(DMI_BIOS_DATE, "12/19/2014"), }, }, + { + .ident = "Teclast X98 Pro", + .matches = { + /* + * Only match BIOS date, because the manufacturers + * BIOS does not report the board name at all + * (sometimes)... + */ + DMI_MATCH(DMI_BOARD_VENDOR, "TECLAST"), + DMI_MATCH(DMI_BIOS_DATE, "10/28/2015"), + }, + }, { .ident = "WinBook TW100", .matches = {
linux-stable-mirror@lists.linaro.org
-
Jean-Philippe Brucker -
Sasha Levin