2022-09-02 14:32:30

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 00/56] 4.19.257-rc1 review

This is the start of the stable review cycle for the 4.19.257 release.
There are 56 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 Sun, 04 Sep 2022 12:13:47 +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/v4.x/stable-review/patch-4.19.257-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-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Yang Yingliang <[email protected]>
net: neigh: don't call kfree_skb() under spin_lock_irqsave()

Kuniyuki Iwashima <[email protected]>
kprobes: don't call disarm_kprobe() for disabled kprobes

Geert Uytterhoeven <[email protected]>
netfilter: conntrack: NF_CONNTRACK_PROCFS should no longer default to y

Juergen Gross <[email protected]>
s390/hypfs: avoid error message under KVM

Denis V. Lunev <[email protected]>
neigh: fix possible DoS due to net iface start/stop loop

Fudong Wang <[email protected]>
drm/amd/display: clear optc underflow before turn off odm clock

Jann Horn <[email protected]>
mm/rmap: Fix anon_vma->degree ambiguity leading to double-reuse

Yang Jihong <[email protected]>
ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead

Letu Ren <[email protected]>
fbdev: fb_pm2fb: Avoid potential divide by zero error

Karthik Alapati <[email protected]>
HID: hidraw: fix memory leak in hidraw_release()

Dongliang Mu <[email protected]>
media: pvrusb2: fix memory leak in pvr_probe

Lee Jones <[email protected]>
HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report

Luiz Augusto von Dentz <[email protected]>
Bluetooth: L2CAP: Fix build errors in some archs

Jing Leng <[email protected]>
kbuild: Fix include path in scripts/Makefile.modpost

Pawan Gupta <[email protected]>
x86/bugs: Add "unknown" reporting for MMIO Stale Data

Gerald Schaefer <[email protected]>
s390/mm: do not trigger write fault when vma does not allow VM_WRITE

Stanislav Fomichev <[email protected]>
selftests/bpf: Fix test_align verifier log patterns

Maxim Mikityanskiy <[email protected]>
bpf: Fix the off-by-two error in range markings

Hsin-Yi Wang <[email protected]>
arm64: map FDT as RW for early_init_dt_scan()

Jann Horn <[email protected]>
mm: Force TLB flush for PFNMAP mappings before unlink_file_vma()

Saurabh Sengar <[email protected]>
scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq

Guoqing Jiang <[email protected]>
md: call __md_stop_writes in md_stop

David Hildenbrand <[email protected]>
mm/hugetlb: fix hugetlb not supporting softdirty tracking

Brian Foster <[email protected]>
s390: fix double free of GS and RI CBs on fork() failure

Quanyang Wang <[email protected]>
asm-generic: sections: refactor memory_intersects

Siddh Raman Pant <[email protected]>
loop: Check for overflow while configuring loop

Chen Zhongjin <[email protected]>
x86/unwind/orc: Unwind ftrace trampolines with correct ORC entry

Goldwyn Rodrigues <[email protected]>
btrfs: check if root is readonly while setting security xattr

Jacob Keller <[email protected]>
ixgbe: stop resetting SYSTIME in ixgbe_ptp_start_cyclecounter

Kuniyuki Iwashima <[email protected]>
net: Fix a data-race around sysctl_somaxconn.

Kuniyuki Iwashima <[email protected]>
net: Fix a data-race around netdev_budget_usecs.

Kuniyuki Iwashima <[email protected]>
net: Fix a data-race around netdev_budget.

Kuniyuki Iwashima <[email protected]>
net: Fix a data-race around sysctl_net_busy_read.

Kuniyuki Iwashima <[email protected]>
net: Fix a data-race around sysctl_net_busy_poll.

Kuniyuki Iwashima <[email protected]>
net: Fix a data-race around sysctl_tstamp_allow_data.

Kuniyuki Iwashima <[email protected]>
ratelimit: Fix data-races in ___ratelimit().

Kuniyuki Iwashima <[email protected]>
net: Fix data-races around netdev_tstamp_prequeue.

Kuniyuki Iwashima <[email protected]>
net: Fix data-races around weight_p and dev_weight_[rt]x_bias.

Pablo Neira Ayuso <[email protected]>
netfilter: nft_tunnel: restrict it to netdev family

Pablo Neira Ayuso <[email protected]>
netfilter: nft_osf: restrict osf to ipv4, ipv6 and inet families

Pablo Neira Ayuso <[email protected]>
netfilter: nft_payload: do not truncate csum_offset and csum_type

Pablo Neira Ayuso <[email protected]>
netfilter: nft_payload: report ERANGE for too long offset and length

Florian Westphal <[email protected]>
netfilter: ebtables: reject blobs that don't provide all entry points

Maciej Żenczykowski <[email protected]>
net: ipvtap - add __init/__exit annotations to module init/exit funcs

Jonathan Toppins <[email protected]>
bonding: 802.3ad: fix no transmission of LACPDUs

Bernard Pidoux <[email protected]>
rose: check NULL rose_loopback_neigh->loopback

Herbert Xu <[email protected]>
af_key: Do not call xfrm_probe_algs in parallel

Xin Xiong <[email protected]>
xfrm: fix refcount leak in __xfrm_policy_check()

Hui Su <[email protected]>
kernel/sched: Remove dl_boosted flag comment

Juri Lelli <[email protected]>
sched/deadline: Fix priority inheritance with multiple scheduling classes

Lucas Stach <[email protected]>
sched/deadline: Fix stale throttling on de-/boosted tasks

Daniel Bristot de Oliveira <[email protected]>
sched/deadline: Unthrottle PI boosted threads while enqueuing

Basavaraj Natikar <[email protected]>
pinctrl: amd: Don't save/restore interrupt status and wake status bits

Randy Dunlap <[email protected]>
kernel/sys_ni: add compat entry for fadvise64_64

Helge Deller <[email protected]>
parisc: Fix exception handler for fldw and fstw instructions

Gaosheng Cui <[email protected]>
audit: fix potential double free on error path from fsnotify_add_inode_mark


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

Diffstat:

.../hw-vuln/processor_mmio_stale_data.rst | 14 +++
Makefile | 4 +-
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/kernel/kaslr.c | 5 +-
arch/arm64/kernel/setup.c | 9 +-
arch/arm64/mm/mmu.c | 15 +--
arch/parisc/kernel/unaligned.c | 2 +-
arch/s390/hypfs/hypfs_diag.c | 2 +-
arch/s390/hypfs/inode.c | 2 +-
arch/s390/kernel/process.c | 22 +++-
arch/s390/mm/fault.c | 4 +-
arch/x86/include/asm/cpufeatures.h | 3 +-
arch/x86/kernel/cpu/bugs.c | 14 ++-
arch/x86/kernel/cpu/common.c | 34 ++++--
arch/x86/kernel/unwind_orc.c | 15 ++-
drivers/block/loop.c | 5 +
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 5 +
drivers/hid/hid-steam.c | 10 ++
drivers/hid/hidraw.c | 3 +
drivers/md/md.c | 1 +
drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 1 +
drivers/net/bonding/bond_3ad.c | 38 +++---
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 59 ++++++++--
drivers/net/ipvlan/ipvtap.c | 4 +-
drivers/pinctrl/pinctrl-amd.c | 11 +-
drivers/scsi/storvsc_drv.c | 2 +-
drivers/video/fbdev/pm2fb.c | 5 +
fs/btrfs/xattr.c | 3 +
include/asm-generic/sections.h | 7 +-
include/linux/netfilter_bridge/ebtables.h | 4 -
include/linux/rmap.h | 7 +-
include/linux/sched.h | 14 ++-
include/net/busy_poll.h | 2 +-
kernel/audit_fsnotify.c | 1 +
kernel/kprobes.c | 9 +-
kernel/sched/core.c | 11 +-
kernel/sched/deadline.c | 131 +++++++++++++--------
kernel/sys_ni.c | 1 +
kernel/trace/ftrace.c | 10 ++
lib/ratelimit.c | 12 +-
mm/mmap.c | 20 +++-
mm/rmap.c | 31 ++---
net/bluetooth/l2cap_core.c | 10 +-
net/bridge/netfilter/ebtable_broute.c | 8 --
net/bridge/netfilter/ebtable_filter.c | 8 --
net/bridge/netfilter/ebtable_nat.c | 8 --
net/bridge/netfilter/ebtables.c | 8 +-
net/core/dev.c | 14 +--
net/core/neighbour.c | 27 ++++-
net/core/skbuff.c | 2 +-
net/core/sock.c | 2 +-
net/core/sysctl_net_core.c | 15 ++-
net/key/af_key.c | 3 +
net/netfilter/Kconfig | 1 -
net/netfilter/nft_osf.c | 18 ++-
net/netfilter/nft_payload.c | 29 +++--
net/netfilter/nft_tunnel.c | 1 +
net/rose/rose_loopback.c | 3 +-
net/sched/sch_generic.c | 2 +-
net/socket.c | 2 +-
net/xfrm/xfrm_policy.c | 1 +
scripts/Makefile.modpost | 3 +-
tools/testing/selftests/bpf/test_align.c | 27 +++--
tools/testing/selftests/bpf/test_verifier.c | 32 ++---
64 files changed, 493 insertions(+), 285 deletions(-)



2022-09-02 14:32:31

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 06/56] sched/deadline: Fix stale throttling on de-/boosted tasks

From: Lucas Stach <[email protected]>

commit 46fcc4b00c3cca8adb9b7c9afdd499f64e427135 upstream.

When a boosted task gets throttled, what normally happens is that it's
immediately enqueued again with ENQUEUE_REPLENISH, which replenishes the
runtime and clears the dl_throttled flag. There is a special case however:
if the throttling happened on sched-out and the task has been deboosted in
the meantime, the replenish is skipped as the task will return to its
normal scheduling class. This leaves the task with the dl_throttled flag
set.

Now if the task gets boosted up to the deadline scheduling class again
while it is sleeping, it's still in the throttled state. The normal wakeup
however will enqueue the task with ENQUEUE_REPLENISH not set, so we don't
actually place it on the rq. Thus we end up with a task that is runnable,
but not actually on the rq and neither a immediate replenishment happens,
nor is the replenishment timer set up, so the task is stuck in
forever-throttled limbo.

Clear the dl_throttled flag before dropping back to the normal scheduling
class to fix this issue.

Signed-off-by: Lucas Stach <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Acked-by: Juri Lelli <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
[Ankit: Regenerated the patch for v4.19.y]
Signed-off-by: Ankit Jain <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/sched/deadline.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)

--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1507,12 +1507,15 @@ static void enqueue_task_dl(struct rq *r
}
} else if (!dl_prio(p->normal_prio)) {
/*
- * Special case in which we have a !SCHED_DEADLINE task
- * that is going to be deboosted, but exceeds its
- * runtime while doing so. No point in replenishing
- * it, as it's going to return back to its original
- * scheduling class after this.
+ * Special case in which we have a !SCHED_DEADLINE task that is going
+ * to be deboosted, but exceeds its runtime while doing so. No point in
+ * replenishing it, as it's going to return back to its original
+ * scheduling class after this. If it has been throttled, we need to
+ * clear the flag, otherwise the task may wake up as throttled after
+ * being boosted again with no means to replenish the runtime and clear
+ * the throttle.
*/
+ p->dl.dl_throttled = 0;
BUG_ON(!p->dl.dl_boosted || flags != ENQUEUE_REPLENISH);
return;
}


2022-09-02 14:32:41

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 10/56] af_key: Do not call xfrm_probe_algs in parallel

From: Herbert Xu <[email protected]>

[ Upstream commit ba953a9d89a00c078b85f4b190bc1dde66fe16b5 ]

When namespace support was added to xfrm/afkey, it caused the
previously single-threaded call to xfrm_probe_algs to become
multi-threaded. This is buggy and needs to be fixed with a mutex.

Reported-by: Abhishek Shah <[email protected]>
Fixes: 283bc9f35bbb ("xfrm: Namespacify xfrm state/policy locks")
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/key/af_key.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index af67e0d265c05..337c6bc8211ed 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -1707,9 +1707,12 @@ static int pfkey_register(struct sock *sk, struct sk_buff *skb, const struct sad
pfk->registered |= (1<<hdr->sadb_msg_satype);
}

+ mutex_lock(&pfkey_mutex);
xfrm_probe_algs();

supp_skb = compose_sadb_supported(hdr, GFP_KERNEL | __GFP_ZERO);
+ mutex_unlock(&pfkey_mutex);
+
if (!supp_skb) {
if (hdr->sadb_msg_satype != SADB_SATYPE_UNSPEC)
pfk->registered &= ~(1<<hdr->sadb_msg_satype);
--
2.35.1



2022-09-02 14:32:55

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 31/56] loop: Check for overflow while configuring loop

From: Siddh Raman Pant <[email protected]>

commit c490a0b5a4f36da3918181a8acdc6991d967c5f3 upstream.

The userspace can configure a loop using an ioctl call, wherein
a configuration of type loop_config is passed (see lo_ioctl()'s
case on line 1550 of drivers/block/loop.c). This proceeds to call
loop_configure() which in turn calls loop_set_status_from_info()
(see line 1050 of loop.c), passing &config->info which is of type
loop_info64*. This function then sets the appropriate values, like
the offset.

loop_device has lo_offset of type loff_t (see line 52 of loop.c),
which is typdef-chained to long long, whereas loop_info64 has
lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).

The function directly copies offset from info to the device as
follows (See line 980 of loop.c):
lo->lo_offset = info->lo_offset;

This results in an overflow, which triggers a warning in iomap_iter()
due to a call to iomap_iter_done() which has:
WARN_ON_ONCE(iter->iomap.offset > iter->pos);

Thus, check for negative value during loop_set_status_from_info().

Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e

Reported-and-tested-by: [email protected]
Cc: [email protected]
Reviewed-by: Matthew Wilcox (Oracle) <[email protected]>
Signed-off-by: Siddh Raman Pant <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/block/loop.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1351,6 +1351,11 @@ loop_get_status(struct loop_device *lo,
info->lo_number = lo->lo_number;
info->lo_offset = lo->lo_offset;
info->lo_sizelimit = lo->lo_sizelimit;
+
+ /* loff_t vars have been assigned __u64 */
+ if (lo->lo_offset < 0 || lo->lo_sizelimit < 0)
+ return -EOVERFLOW;
+
info->lo_flags = lo->lo_flags;
memcpy(info->lo_file_name, lo->lo_file_name, LO_NAME_SIZE);
memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE);


2022-09-02 14:34:45

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 40/56] selftests/bpf: Fix test_align verifier log patterns

From: Stanislav Fomichev <[email protected]>

commit 5366d2269139ba8eb6a906d73a0819947e3e4e0a upstream.

Commit 294f2fc6da27 ("bpf: Verifer, adjust_scalar_min_max_vals to always
call update_reg_bounds()") changed the way verifier logs some of its state,
adjust the test_align accordingly. Where possible, I tried to not copy-paste
the entire log line and resorted to dropping the last closing brace instead.

Fixes: 294f2fc6da27 ("bpf: Verifer, adjust_scalar_min_max_vals to always call update_reg_bounds()")
Signed-off-by: Stanislav Fomichev <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
[OP: adjust for 4.19 selftests, apply only the relevant diffs]
Signed-off-by: Ovidiu Panait <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/bpf/test_align.c | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)

--- a/tools/testing/selftests/bpf/test_align.c
+++ b/tools/testing/selftests/bpf/test_align.c
@@ -359,15 +359,15 @@ static struct bpf_align_test tests[] = {
* is still (4n), fixed offset is not changed.
* Also, we create a new reg->id.
*/
- {29, "R5_w=pkt(id=4,off=18,r=0,umax_value=2040,var_off=(0x0; 0x7fc))"},
+ {29, "R5_w=pkt(id=4,off=18,r=0,umax_value=2040,var_off=(0x0; 0x7fc)"},
/* At the time the word size load is performed from R5,
* its total fixed offset is NET_IP_ALIGN + reg->off (18)
* which is 20. Then the variable offset is (4n), so
* the total offset is 4-byte aligned and meets the
* load's requirements.
*/
- {33, "R4=pkt(id=4,off=22,r=22,umax_value=2040,var_off=(0x0; 0x7fc))"},
- {33, "R5=pkt(id=4,off=18,r=22,umax_value=2040,var_off=(0x0; 0x7fc))"},
+ {33, "R4=pkt(id=4,off=22,r=22,umax_value=2040,var_off=(0x0; 0x7fc)"},
+ {33, "R5=pkt(id=4,off=18,r=22,umax_value=2040,var_off=(0x0; 0x7fc)"},
},
},
{
@@ -410,15 +410,15 @@ static struct bpf_align_test tests[] = {
/* Adding 14 makes R6 be (4n+2) */
{9, "R6_w=inv(id=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
/* Packet pointer has (4n+2) offset */
- {11, "R5_w=pkt(id=1,off=0,r=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
- {13, "R4=pkt(id=1,off=4,r=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
+ {11, "R5_w=pkt(id=1,off=0,r=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc)"},
+ {13, "R4=pkt(id=1,off=4,r=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc)"},
/* At the time the word size load is performed from R5,
* its total fixed offset is NET_IP_ALIGN + reg->off (0)
* which is 2. Then the variable offset is (4n+2), so
* the total offset is 4-byte aligned and meets the
* load's requirements.
*/
- {15, "R5=pkt(id=1,off=0,r=4,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
+ {15, "R5=pkt(id=1,off=0,r=4,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc)"},
/* Newly read value in R6 was shifted left by 2, so has
* known alignment of 4.
*/
@@ -426,15 +426,15 @@ static struct bpf_align_test tests[] = {
/* Added (4n) to packet pointer's (4n+2) var_off, giving
* another (4n+2).
*/
- {19, "R5_w=pkt(id=2,off=0,r=0,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc))"},
- {21, "R4=pkt(id=2,off=4,r=0,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc))"},
+ {19, "R5_w=pkt(id=2,off=0,r=0,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc)"},
+ {21, "R4=pkt(id=2,off=4,r=0,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc)"},
/* At the time the word size load is performed from R5,
* its total fixed offset is NET_IP_ALIGN + reg->off (0)
* which is 2. Then the variable offset is (4n+2), so
* the total offset is 4-byte aligned and meets the
* load's requirements.
*/
- {23, "R5=pkt(id=2,off=0,r=4,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc))"},
+ {23, "R5=pkt(id=2,off=0,r=4,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc)"},
},
},
{
@@ -469,11 +469,11 @@ static struct bpf_align_test tests[] = {
.matches = {
{4, "R5_w=pkt_end(id=0,off=0,imm=0)"},
/* (ptr - ptr) << 2 == unknown, (4n) */
- {6, "R5_w=inv(id=0,smax_value=9223372036854775804,umax_value=18446744073709551612,var_off=(0x0; 0xfffffffffffffffc))"},
+ {6, "R5_w=inv(id=0,smax_value=9223372036854775804,umax_value=18446744073709551612,var_off=(0x0; 0xfffffffffffffffc)"},
/* (4n) + 14 == (4n+2). We blow our bounds, because
* the add could overflow.
*/
- {7, "R5=inv(id=0,var_off=(0x2; 0xfffffffffffffffc))"},
+ {7, "R5=inv(id=0,smin_value=-9223372036854775806,smax_value=9223372036854775806,umin_value=2,umax_value=18446744073709551614,var_off=(0x2; 0xfffffffffffffffc)"},
/* Checked s>=0 */
{9, "R5=inv(id=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
/* packet pointer + nonnegative (4n+2) */
@@ -528,7 +528,7 @@ static struct bpf_align_test tests[] = {
/* New unknown value in R7 is (4n) */
{11, "R7_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
/* Subtracting it from R6 blows our unsigned bounds */
- {12, "R6=inv(id=0,smin_value=-1006,smax_value=1034,var_off=(0x2; 0xfffffffffffffffc))"},
+ {12, "R6=inv(id=0,smin_value=-1006,smax_value=1034,umin_value=2,umax_value=18446744073709551614,var_off=(0x2; 0xfffffffffffffffc)"},
/* Checked s>= 0 */
{14, "R6=inv(id=0,umin_value=2,umax_value=1034,var_off=(0x2; 0x7fc))"},
/* At the time the word size load is performed from R5,
@@ -537,7 +537,8 @@ static struct bpf_align_test tests[] = {
* the total offset is 4-byte aligned and meets the
* load's requirements.
*/
- {20, "R5=pkt(id=1,off=0,r=4,umin_value=2,umax_value=1034,var_off=(0x2; 0x7fc))"},
+ {20, "R5=pkt(id=1,off=0,r=4,umin_value=2,umax_value=1034,var_off=(0x2; 0x7fc)"},
+
},
},
{


2022-09-02 14:52:23

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 19/56] net: Fix data-races around weight_p and dev_weight_[rt]x_bias.

From: Kuniyuki Iwashima <[email protected]>

[ Upstream commit bf955b5ab8f6f7b0632cdef8e36b14e4f6e77829 ]

While reading weight_p, it can be changed concurrently. Thus, we need
to add READ_ONCE() to its reader.

Also, dev_[rt]x_weight can be read/written at the same time. So, we
need to use READ_ONCE() and WRITE_ONCE() for its access. Moreover, to
use the same weight_p while changing dev_[rt]x_weight, we add a mutex
in proc_do_dev_weight().

Fixes: 3d48b53fb2ae ("net: dev_weight: TX/RX orthogonality")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kuniyuki Iwashima <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/core/dev.c | 2 +-
net/core/sysctl_net_core.c | 15 +++++++++------
net/sched/sch_generic.c | 2 +-
3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 42f6ff8b9703c..6ee4390863fbe 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5851,7 +5851,7 @@ static int process_backlog(struct napi_struct *napi, int quota)
net_rps_action_and_irq_enable(sd);
}

- napi->weight = dev_rx_weight;
+ napi->weight = READ_ONCE(dev_rx_weight);
while (again) {
struct sk_buff *skb;

diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index 0a0bf80623658..d7e39167ceca0 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -231,14 +231,17 @@ static int set_default_qdisc(struct ctl_table *table, int write,
static int proc_do_dev_weight(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
- int ret;
+ static DEFINE_MUTEX(dev_weight_mutex);
+ int ret, weight;

+ mutex_lock(&dev_weight_mutex);
ret = proc_dointvec(table, write, buffer, lenp, ppos);
- if (ret != 0)
- return ret;
-
- dev_rx_weight = weight_p * dev_weight_rx_bias;
- dev_tx_weight = weight_p * dev_weight_tx_bias;
+ if (!ret && write) {
+ weight = READ_ONCE(weight_p);
+ WRITE_ONCE(dev_rx_weight, weight * dev_weight_rx_bias);
+ WRITE_ONCE(dev_tx_weight, weight * dev_weight_tx_bias);
+ }
+ mutex_unlock(&dev_weight_mutex);

return ret;
}
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index cad2586c34734..c966dacf1130b 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -397,7 +397,7 @@ static inline bool qdisc_restart(struct Qdisc *q, int *packets)

void __qdisc_run(struct Qdisc *q)
{
- int quota = dev_tx_weight;
+ int quota = READ_ONCE(dev_tx_weight);
int packets;

while (qdisc_restart(q, &packets)) {
--
2.35.1



2022-09-02 23:08:44

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/56] 4.19.257-rc1 review

On 9/2/22 06:18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.257 release.
> There are 56 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 Sun, 04 Sep 2022 12:13:47 +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/v4.x/stable-review/patch-4.19.257-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-4.19.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

2022-09-03 00:57:10

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/56] 4.19.257-rc1 review

On Fri, Sep 02, 2022 at 02:18:20PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.257 release.
> There are 56 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 Sun, 04 Sep 2022 12:13:47 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 422 pass: 422 fail: 0

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

Guenter

2022-09-03 11:55:18

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/56] 4.19.257-rc1 review

Hi Greg,

On Fri, Sep 02, 2022 at 02:18:20PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.257 release.
> There are 56 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 Sun, 04 Sep 2022 12:13:47 +0000.
> Anything received after that time might be too late.

Build test (gcc version 11.3.1 20220819):
mips: 63 configs -> no failure
arm: 115 configs -> no failure
arm64: 2 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure

Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]

[1]. https://openqa.qa.codethink.co.uk/tests/1754


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

--
Regards
Sudip

2022-09-03 14:09:14

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/56] 4.19.257-rc1 review

On Fri, 2 Sept 2022 at 17:55, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.257 release.
> There are 56 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 Sun, 04 Sep 2022 12:13:47 +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/v4.x/stable-review/patch-4.19.257-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-4.19.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: 4.19.257-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.19.y
* git commit: 56ebf961480f5507db5b5ff29f49ab7c03b05a24
* git describe: v4.19.256-57-g56ebf961480f
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.256-57-g56ebf961480f

## No test Regressions (compared to v4.19.256)

## No metric Regressions (compared to v4.19.256)

## No test Fixes (compared to v4.19.256)

## No metric Fixes (compared to v4.19.256)

## Test result summary
total: 84836, pass: 74060, fail: 668, skip: 9690, xfail: 418

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 291 total, 286 passed, 5 failed
* arm64: 58 total, 57 passed, 1 failed
* i386: 26 total, 25 passed, 1 failed
* mips: 35 total, 35 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 54 total, 54 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 52 total, 51 passed, 1 failed

## Test suites summary
* fwts
* igt-gpu-tools
* kunit
* kvm-unit-tests
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* rcutorture
* v4l2-compliance
* vdso

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

2022-09-05 08:21:04

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/56] 4.19.257-rc1 review

Hi!

> This is the start of the stable review cycle for the 4.19.257 release.
> There are 56 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.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.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) (1.08 kB)
signature.asc (201.00 B)
Download all attachments