5.3.9-stable review
Subsystems (6)
Greg Kroah-Hartman
maintainerPATCH 151/163 NFC: pn533: fix use-after-free and memleaks
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 6af3aa57a0984e061f61308fe181a9a12359fecc upstream.
The driver would fail to deregister and its class device and free related resources on late probe errors.
--- drivers/nfc/pn533/usb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/nfc/pn533/usb.c +8 -1
@@ -547,18 +547,25 @@ static int pn533_usb_probe(struct usb_in rc =pn533_finalize_setup (priv);if (rc) - goto error; + goto err_deregister;usb_set_intfdata (interface, phy);return 0 ; +err_deregister: +pn533_unregister_device (phy->priv); error: +usb_kill_urb (phy->in_urb); +usb_kill_urb (phy->out_urb); +usb_kill_urb (phy->ack_urb); +usb_free_urb (phy->in_urb);usb_free_urb (phy->out_urb);usb_free_urb (phy->ack_urb);usb_put_dev (phy->udev);kfree (in_buf); +kfree (phy->ack_buffer);return rc; }
Greg Kroah-Hartman
maintainerPATCH 152/163 bonding: fix potential NULL deref in bond_update_slave_arr
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit a7137534b597b7c303203e6bc3ed87e87a273bb8 upstream.
syzbot got a NULL dereference in bond_update_slave_arr() [1], happening after a failure to allocate bond->slave_arr
A workqueue (bond_slave_arr_handler) is supposed to retry the allocation later, but if the slave is removed before the workqueue had a chance to complete, bond->slave_arr can still be NULL.
[1]
Failed to build slave-array.
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN PTI Modules linked in: Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:bond_update_slave_arr.cold+0xc6/0x198 drivers/net/bonding/bond_main.c:4039 RSP: 0018:ffff88018fe33678 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc9000290b000 RDX: 0000000000000000 RSI: ffffffff82b63037 RDI: ffff88019745ea20 RBP: ffff88018fe33760 R08: ffff880170754280 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88019745ea00 R14: 0000000000000000 R15: ffff88018fe338b0 FS: 00007febd837d700(0000) GS:ffff8801dad00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004540a0 CR3: 00000001c242e005 CR4: 00000000001626f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: [<ffffffff82b5b45e>] __bond_release_one+0x43e/0x500 drivers/net/bonding/bond_main.c:1923 [<ffffffff82b5b966>] bond_release drivers/net/bonding/bond_main.c:2039 [inline] [<ffffffff82b5b966>] bond_do_ioctl+0x416/0x870 drivers/net/bonding/bond_main.c:3562 [<ffffffff83ae25f4>] dev_ifsioc+0x6f4/0x940 net/core/dev_ioctl.c:328 [<ffffffff83ae2e58>] dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:495 [<ffffffff83995ffd>] sock_do_ioctl+0x1bd/0x300 net/socket.c:1088 [<ffffffff83996a80>] sock_ioctl+0x300/0x5d0 net/socket.c:1196 [<ffffffff81b124db>] vfs_ioctl fs/ioctl.c:47 [inline] [<ffffffff81b124db>] file_ioctl fs/ioctl.c:501 [inline] [<ffffffff81b124db>] do_vfs_ioctl+0xacb/0x1300 fs/ioctl.c:688 [<ffffffff81b12dc6>] SYSC_ioctl fs/ioctl.c:705 [inline] [<ffffffff81b12dc6>] SyS_ioctl+0xb6/0xe0 fs/ioctl.c:696 [<ffffffff8101ccc8>] do_syscall_64+0x528/0x770 arch/x86/entry/common.c:305 [<ffffffff84400091>] entry_SYSCALL_64_after_hwframe+0x42/0xb7
--- drivers/net/bonding/bond_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/bonding/bond_main.c +1 -1
@@ -4039,7 +4039,7 @@ out:* this to-be-skipped slave to send a packet out. */ old_arr =rtnl_dereference (bond->slave_arr); -for (idx =0 ; idx < old_arr->count; idx++) { +for (idx =0 ; old_arr !=NULL && idx < old_arr->count; idx++) {if (skipslave == old_arr->arr[idx]) { old_arr->arr[idx] = old_arr->arr[old_arr->count-1 ];
Greg Kroah-Hartman
maintainerPATCH 153/163 netfilter: conntrack: avoid possible false sharing
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit e37542ba111f3974dc622ae0a21c1787318de500 upstream.
As hinted by KCSAN, we need at least one READ_ONCE() to prevent a compiler optimization.
More details on :
https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE#it-may-improve-performance
sysbot report :
BUG: KCSAN: data-race in __nf_ct_refresh_acct / __nf_ct_refresh_acct
read to 0xffff888123eb4f08 of 4 bytes by interrupt on cpu 0:
__nf_ct_refresh_acct+0xd4/0x1b0 net/netfilter/nf_conntrack_core.c:1796 nf_ct_refresh_acct include/net/netfilter/nf_conntrack.h:201 [inline] nf_conntrack_tcp_packet+0xd40/0x3390 net/netfilter/nf_conntrack_proto_tcp.c:1161 nf_conntrack_handle_packet net/netfilter/nf_conntrack_core.c:1633 [inline] nf_conntrack_in+0x410/0xaa0 net/netfilter/nf_conntrack_core.c:1727 ipv4_conntrack_in+0x27/0x40 net/netfilter/nf_conntrack_proto.c:178 nf_hook_entry_hookfn include/linux/netfilter.h:135 [inline] nf_hook_slow+0x83/0x160 net/netfilter/core.c:512 nf_hook include/linux/netfilter.h:260 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] ip_rcv+0x12f/0x1a0 net/ipv4/ip_input.c:523 __netif_receive_skb_one_core+0xa7/0xe0 net/core/dev.c:5004 __netif_receive_skb+0x37/0xf0 net/core/dev.c:5118 netif_receive_skb_internal+0x59/0x190 net/core/dev.c:5208 napi_skb_finish net/core/dev.c:5671 [inline] napi_gro_receive+0x28f/0x330 net/core/dev.c:5704 receive_buf+0x284/0x30b0 drivers/net/virtio_net.c:1061 virtnet_receive drivers/net/virtio_net.c:1323 [inline] virtnet_poll+0x436/0x7d0 drivers/net/virtio_net.c:1428 napi_poll net/core/dev.c:6352 [inline] net_rx_action+0x3ae/0xa50 net/core/dev.c:6418 __do_softirq+0x115/0x33f kernel/softirq.c:292
write to 0xffff888123eb4f08 of 4 bytes by task 7191 on cpu 1:
__nf_ct_refresh_acct+0xfb/0x1b0 net/netfilter/nf_conntrack_core.c:1797 nf_ct_refresh_acct include/net/netfilter/nf_conntrack.h:201 [inline] nf_conntrack_tcp_packet+0xd40/0x3390 net/netfilter/nf_conntrack_proto_tcp.c:1161 nf_conntrack_handle_packet net/netfilter/nf_conntrack_core.c:1633 [inline] nf_conntrack_in+0x410/0xaa0 net/netfilter/nf_conntrack_core.c:1727 ipv4_conntrack_local+0xbe/0x130 net/netfilter/nf_conntrack_proto.c:200 nf_hook_entry_hookfn include/linux/netfilter.h:135 [inline] nf_hook_slow+0x83/0x160 net/netfilter/core.c:512 nf_hook include/linux/netfilter.h:260 [inline] __ip_local_out+0x1f7/0x2b0 net/ipv4/ip_output.c:114 ip_local_out+0x31/0x90 net/ipv4/ip_output.c:123 __ip_queue_xmit+0x3a8/0xa40 net/ipv4/ip_output.c:532 ip_queue_xmit+0x45/0x60 include/net/ip.h:236 __tcp_transmit_skb+0xdeb/0x1cd0 net/ipv4/tcp_output.c:1158 __tcp_send_ack+0x246/0x300 net/ipv4/tcp_output.c:3685 tcp_send_ack+0x34/0x40 net/ipv4/tcp_output.c:3691 tcp_cleanup_rbuf+0x130/0x360 net/ipv4/tcp.c:1575
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 7191 Comm: syz-fuzzer Not tainted 5.3.0+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
--- net/netfilter/nf_conntrack_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/netfilter/nf_conntrack_core.c +2 -2
@@ -1793,8 +1793,8 @@ void __nf_ct_refresh_acct(struct nf_connif (nf_ct_is_confirmed (ct)) extra_jiffies += nfct_time_stamp; -if (ct->timeout != extra_jiffies) - ct->timeout = extra_jiffies; +if (READ_ONCE (ct->timeout) != extra_jiffies) +WRITE_ONCE (ct->timeout, extra_jiffies); acct:if (do_acct)nf_ct_acct_update (ct, ctinfo, skb->len);
Greg Kroah-Hartman
maintainerPATCH 154/163 net: usb: sr9800: fix uninitialized local variable
In reply to Greg Kroah-HartmanFrom: Valentin Vidic <[email protected]>
commit 77b6d09f4ae66d42cd63b121af67780ae3d1a5e9 upstream.
Make sure res does not contain random value if the call to sr_read_cmd fails for some reason.
--- drivers/net/usb/sr9800.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/usb/sr9800.c +1 -1
@@ -336,7 +336,7 @@ static void sr_set_multicast(struct net_static int sr_mdio_read (struct net_device *net,int phy_id,int loc) {struct usbnet *dev =netdev_priv (net); -__le16 res; +__le16 res =0 ;mutex_lock (&dev->phy_mutex);sr_set_sw_mii (dev);
Greg Kroah-Hartman
maintainerPATCH 155/163 sch_netem: fix rcu splat in netem_enqueue()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit 159d2c7d8106177bd9a986fd005a311fe0d11285 upstream.
qdisc_root() use from netem_enqueue() triggers a lockdep warning.
__dev_queue_xmit() uses rcu_read_lock_bh() which is not equivalent to rcu_read_lock() + local_bh_disable_bh as far as lockdep is concerned.
WARNING: suspicious RCU usage
5.3.0-rc7+ #0 Not tainted
-----------------------------include/net/sch_generic.h:492 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by syz-executor427/8855:
#0: 00000000b5525c01 (rcu_read_lock_bh){....}, at: lwtunnel_xmit_redirect include/net/lwtunnel.h:92 [inline] #0: 00000000b5525c01 (rcu_read_lock_bh){....}, at: ip_finish_output2+0x2dc/0x2570 net/ipv4/ip_output.c:214 #1: 00000000b5525c01 (rcu_read_lock_bh){....}, at: __dev_queue_xmit+0x20a/0x3650 net/core/dev.c:3804 #2: 00000000364bae92 (&(&sch->q.lock)->rlock){+.-.}, at: spin_lock include/linux/spinlock.h:338 [inline] #2: 00000000364bae92 (&(&sch->q.lock)->rlock){+.-.}, at: __dev_xmit_skb net/core/dev.c:3502 [inline] #2: 00000000364bae92 (&(&sch->q.lock)->rlock){+.-.}, at: __dev_queue_xmit+0x14b8/0x3650 net/core/dev.c:3838
stack backtrace: CPU: 0 PID: 8855 Comm: syz-executor427 Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5357 qdisc_root include/net/sch_generic.h:492 [inline] netem_enqueue+0x1cfb/0x2d80 net/sched/sch_netem.c:479 __dev_xmit_skb net/core/dev.c:3527 [inline] __dev_queue_xmit+0x15d2/0x3650 net/core/dev.c:3838 dev_queue_xmit+0x18/0x20 net/core/dev.c:3902 neigh_hh_output include/net/neighbour.h:500 [inline] neigh_output include/net/neighbour.h:509 [inline] ip_finish_output2+0x1726/0x2570 net/ipv4/ip_output.c:228 __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x5fc/0xb90 net/ipv4/ip_output.c:290 ip_finish_output+0x38/0x1f0 net/ipv4/ip_output.c:318 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip_mc_output+0x292/0xf40 net/ipv4/ip_output.c:417 dst_output include/net/dst.h:436 [inline] ip_local_out+0xbb/0x190 net/ipv4/ip_output.c:125 ip_send_skb+0x42/0xf0 net/ipv4/ip_output.c:1555 udp_send_skb.isra.0+0x6b2/0x1160 net/ipv4/udp.c:887 udp_sendmsg+0x1e96/0x2820 net/ipv4/udp.c:1174 inet_sendmsg+0x9e/0xe0 net/ipv4/af_inet.c:807 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:657 ___sys_sendmsg+0x3e2/0x920 net/socket.c:2311 __sys_sendmmsg+0x1bf/0x4d0 net/socket.c:2413 __do_sys_sendmmsg net/socket.c:2442 [inline] __se_sys_sendmmsg net/socket.c:2439 [inline] __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2439 do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe
--- include/net/sch_generic.h | 5 +++++ net/sched/sch_netem.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-)
include/net/sch_generic.h +5 -0
@@ -520,6 +520,11 @@ static inline struct Qdisc *qdisc_root(creturn q; } +static inline struct Qdisc *qdisc_root_bh (const struct Qdisc *qdisc) +{ +return rcu_dereference_bh (qdisc->dev_queue->qdisc); +} +static inline struct Qdisc *qdisc_root_sleeping (const struct Qdisc *qdisc) {return qdisc->dev_queue->qdisc_sleeping;
net/sched/sch_netem.c +1 -1
@@ -476,7 +476,7 @@ static int netem_enqueue(struct sk_buff* skb will be queued. */ if (count >1 && (skb2 =skb_clone (skb,GFP_ATOMIC )) !=NULL ) { -struct Qdisc *rootq =qdisc_root (sch); +struct Qdisc *rootq =qdisc_root_bh (sch);u32 dupsave = q->duplicate;/* prevent duplicating a dup... */ q->duplicate =0 ;
Greg Kroah-Hartman
maintainerPATCH 156/163 net: sched: sch_sfb: dont call qdisc_put() while holding tree lock
In reply to Greg Kroah-HartmanFrom: Vlad Buslov <[email protected]>
commit e3ae1f96accd21405715fe9c56b4d83bc7d96d44 upstream.
Recent changes that removed rtnl dependency from rules update path of tc also made tcf_block_put() function sleeping. This function is called from ops->destroy() of several Qdisc implementations, which in turn is called by qdisc_put(). Some Qdiscs call qdisc_put() while holding sch tree spinlock, which results sleeping-while-atomic BUG.
Steps to reproduce for sfb:
tc qdisc add dev ens1f0 handle 1: root sfb
tc qdisc add dev ens1f0 parent 1:10 handle 50: sfq perturb 10 tc qdisc change dev ens1f0 root handle 1: sfb
Resulting dmesg:
[ 7265.938717] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:909 [ 7265.940152] in_atomic(): 1, irqs_disabled(): 0, pid: 28579, name: tc [ 7265.941455] INFO: lockdep is turned off. [ 7265.942744] CPU: 11 PID: 28579 Comm: tc Tainted: G W 5.3.0-rc8+ #721 [ 7265.944065] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017 [ 7265.945396] Call Trace: [ 7265.946709] dump_stack+0x85/0xc0 [ 7265.947994] ___might_sleep.cold+0xac/0xbc [ 7265.949282] __mutex_lock+0x5b/0x960 [ 7265.950543] ? tcf_chain0_head_change_cb_del.isra.0+0x1b/0xf0 [ 7265.951803] ? tcf_chain0_head_change_cb_del.isra.0+0x1b/0xf0 [ 7265.953022] tcf_chain0_head_change_cb_del.isra.0+0x1b/0xf0 [ 7265.954248] tcf_block_put_ext.part.0+0x21/0x50 [ 7265.955478] tcf_block_put+0x50/0x70 [ 7265.956694] sfq_destroy+0x15/0x50 [sch_sfq] [ 7265.957898] qdisc_destroy+0x5f/0x160 [ 7265.959099] sfb_change+0x175/0x330 [sch_sfb] [ 7265.960304] tc_modify_qdisc+0x324/0x840 [ 7265.961503] rtnetlink_rcv_msg+0x170/0x4b0 [ 7265.962692] ? netlink_deliver_tap+0x95/0x400 [ 7265.963876] ? rtnl_dellink+0x2d0/0x2d0 [ 7265.965064] netlink_rcv_skb+0x49/0x110 [ 7265.966251] netlink_unicast+0x171/0x200 [ 7265.967427] netlink_sendmsg+0x224/0x3f0 [ 7265.968595] sock_sendmsg+0x5e/0x60 [ 7265.969753] ___sys_sendmsg+0x2ae/0x330 [ 7265.970916] ? ___sys_recvmsg+0x159/0x1f0 [ 7265.972074] ? do_wp_page+0x9c/0x790 [ 7265.973233] ? __handle_mm_fault+0xcd3/0x19e0 [ 7265.974407] __sys_sendmsg+0x59/0xa0 [ 7265.975591] do_syscall_64+0x5c/0xb0 [ 7265.976753] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 7265.977938] RIP: 0033:0x7f229069f7b8 [ 7265.979117] Code: 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 65 8f 0c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 89 5 4 [ 7265.981681] RSP: 002b:00007ffd7ed2d158 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 7265.983001] RAX: ffffffffffffffda RBX: 000000005d813ca1 RCX: 00007f229069f7b8 [ 7265.984336] RDX: 0000000000000000 RSI: 00007ffd7ed2d1c0 RDI: 0000000000000003 [ 7265.985682] RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000165c9a0 [ 7265.987021] R10: 0000000000404eda R11: 0000000000000246 R12: 0000000000000001 [ 7265.988309] R13: 000000000047f640 R14: 0000000000000000 R15: 0000000000000000
In sfb_change() function use qdisc_purge_queue() instead of qdisc_tree_flush_backlog() to properly reset old child Qdisc and save pointer to it into local temporary variable. Put reference to Qdisc after sch tree lock is released in order not to call potentially sleeping cls API in atomic section. This is safe to do because Qdisc has already been reset by qdisc_purge_queue() inside sch tree lock critical section.
--- net/sched/sch_sfb.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
net/sched/sch_sfb.c +4 -3
@@ -488,7 +488,7 @@ static int sfb_change(struct Qdisc *sch, struct netlink_ext_ack *extack) {struct sfb_sched_data *q =qdisc_priv (sch); -struct Qdisc *child; +struct Qdisc *child, *old;struct nlattr *tb[TCA_SFB_MAX +1 ];const struct tc_sfb_qopt *ctl = &sfb_default_ops;u32 limit;
@@ -518,8 +518,8 @@ static int sfb_change(struct Qdisc *sch,qdisc_hash_add (child, true);sch_tree_lock (sch); -qdisc_tree_flush_backlog (q->qdisc); -qdisc_put (q->qdisc); +qdisc_purge_queue (q->qdisc); + old = q->qdisc; q->qdisc = child; q->rehash_interval =msecs_to_jiffies (ctl->rehash_interval);
@@ -542,6 +542,7 @@ static int sfb_change(struct Qdisc *sch,sfb_init_perturbation (1 , q);sch_tree_unlock (sch); +qdisc_put (old);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 157/163 iwlwifi: exclude GEO SAR support for 3168
In reply to Greg Kroah-HartmanFrom: Luca Coelho <[email protected]>
commit 12e36d98d3e5acf5fc57774e0a15906d55f30cb9 upstream.
We currently support two NICs in FW version 29, namely 7265D and 3168. Out of these, only 7265D supports GEO SAR, so adjust the function that checks for it accordingly.
--- drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
drivers/net/wireless/intel/iwlwifi/mvm/fw.c +9 -7
@@ -887,15 +887,17 @@ static bool iwl_mvm_sar_geo_support(stru* firmware versions. Unfortunately, we don't have a TLV API * flag to rely on, so rely on the major version which is in * the first byte of ucode_ver. This was implemented -* initially on version 38 and then backported to29 and 17. -* The intention was to have it in 36 as well, but not all -* 8000 family got this feature enabled. The 8000 family is -* the only one using version 36, so skip this version -* entirely. +* initially on version 38 and then backported to 17. It was +* also backported to 29, but only for 7265D devices. The +* intention was to have it in 36 as well, but not all 8000 +* family got this feature enabled. The 8000 family is the +* only one using version 36, so skip this version entirely. */ return IWL_UCODE_SERIAL (mvm->fw->ucode_ver) >=38 || -IWL_UCODE_SERIAL (mvm->fw->ucode_ver) ==29 || -IWL_UCODE_SERIAL (mvm->fw->ucode_ver) ==17 ; +IWL_UCODE_SERIAL (mvm->fw->ucode_ver) ==17 || + (IWL_UCODE_SERIAL (mvm->fw->ucode_ver) ==29 && + ((mvm->trans->hw_rev &CSR_HW_REV_TYPE_MSK ) == +CSR_HW_REV_TYPE_7265D )); }int iwl_mvm_get_sar_geo_profile (struct iwl_mvm *mvm)
Greg Kroah-Hartman
maintainerPATCH 158/163 sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
In reply to Greg Kroah-HartmanFrom: Dave Chiluk <[email protected]>
commit de53fd7aedb100f03e5d2231cfce0e4993282425 upstream.
It has been observed, that highly-threaded, non-cpu-bound applications running under cpu.cfs_quota_us constraints can hit a high percentage of periods throttled while simultaneously not consuming the allocated amount of quota. This use case is typical of user-interactive non-cpu bound applications, such as those running in kubernetes or mesos when run on multiple cpu cores.
This has been root caused to cpu-local run queue being allocated per cpu bandwidth slices, and then not fully using that slice within the period. At which point the slice and quota expires. This expiration of unused slice results in applications not being able to utilize the quota for which they are allocated.
The non-expiration of per-cpu slices was recently fixed by 'commit 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")'. Prior to that it appears that this had been broken since at least 'commit 51f2176d74ac ("sched/fair: Fix unlocked reads of some cfs_b->quota/period")' which was introduced in v3.16-rc1 in 2014. That added the following conditional which resulted in slices never being expired.
if (cfs_rq->runtime_expires != cfs_b->runtime_expires) {
/* extend local deadline, drift is bounded above by 2 ticks */
cfs_rq->runtime_expires += TICK_NSEC;Because this was broken for nearly 5 years, and has recently been fixed and is now being noticed by many users running kubernetes
(https://github.com/kubernetes/kubernetes/issues/67577) it is my opinion that the mechanisms around expiring runtime should be removed altogether.
This allows quota already allocated to per-cpu run-queues to live longer than the period boundary. This allows threads on runqueues that do not use much CPU to continue to use their remaining slice over a longer period of time than cpu.cfs_period_us. However, this helps prevent the above condition of hitting throttling while also not fully utilizing your cpu quota.
This theoretically allows a machine to use slightly more than its allotted quota in some periods. This overflow would be bounded by the remaining quota left on each per-cpu runqueueu. This is typically no more than min_cfs_rq_runtime=1ms per cpu. For CPU bound tasks this will change nothing, as they should theoretically fully utilize all of their quota in each period. For user-interactive tasks as described above this provides a much better user/application experience as their cpu utilization will more closely match the amount they requested when they hit throttling. This means that cpu limits no longer strictly apply per period for non-cpu bound applications, but that they are still accurate over longer timeframes.
This greatly improves performance of high-thread-count, non-cpu bound applications with low cfs_quota_us allocation on high-core-count machines. In the case of an artificial testcase (10ms/100ms of quota on 80 CPU machine), this commit resulted in almost 30x performance improvement, while still maintaining correct cpu quota restrictions. That testcase is available at https://github.com/indeedeng/fibtest.
--- Documentation/scheduler/sched-bwc.rst | 74 +++++++++++++++++++++++++++------- kernel/sched/fair.c | 72 +++------------------------------ kernel/sched/sched.h | 4 - 3 files changed, 67 insertions(+), 83 deletions(-)
Documentation/scheduler/sched-bwc.rst +60 -14
@@ -9,15 +9,16 @@ CFS bandwidth control is a CONFIG_FAIR_G specification of the maximum CPU bandwidth available to a group or hierarchy. The bandwidth allowed for a group is specified using a quota and period. Within -each given "period" (microseconds), a group is allowed to consume only up to -"quota" microseconds of CPU time. When the CPU bandwidth consumption of a -group exceeds this limit (for that period), the tasks belonging to its -hierarchy will be throttled and are not allowed to run again until the next -period. - -A group's unused runtime is globally tracked, being refreshed with quota units -above at each period boundary. As threads consume this bandwidth it is -transferred to cpu-local "silos" on a demand basis. The amount transferred +each given "period" (microseconds), a task group is allocated up to "quota" +microseconds of CPU time. That quota is assigned to per-cpu run queues in +slices as threads in the cgroup become runnable. Once all quota has been +assigned any additional requests for quota will result in those threads being +throttled. Throttled threads will not be able to run again until the next +period when the quota is replenished. + +A group's unassigned quota is globally tracked, being refreshed back to +cfs_quota units at each period boundary. As threads consume this bandwidth it +is transferred to cpu-local "silos" on a demand basis. The amount transferred within each of these updates is tunable and described as the "slice". Management
@@ -35,12 +36,12 @@ The default values are:: A value of -1 for cpu.cfs_quota_us indicates that the group does not have any bandwidth restriction in place, such a group is described as an unconstrained -bandwidth group. This represents the traditional work-conserving behavior for +bandwidth group. This represents the traditional work-conserving behavior for CFS. Writing any (valid) positive value(s) will enact the specified bandwidth limit. -The minimum quota allowed for the quota or period is 1ms. There is also an -upper bound on the period length of 1s. Additional restrictions exist when +The minimum quota allowed for the quota or period is 1ms. There is also an +upper bound on the period length of 1s. Additional restrictions exist when bandwidth limits are used in a hierarchical fashion, these are explained in more detail below.
@@ -53,8 +54,8 @@ unthrottled if it is in a constrained st System wide settings -------------------- For efficiency run-time is transferred between the global pool and CPU local -"silos" in a batch fashion. This greatly reduces global accounting pressure -on large systems. The amount transferred each time such an update is required +"silos" in a batch fashion. This greatly reduces global accounting pressure +on large systems. The amount transferred each time such an update is required is described as the "slice". This is tunable via procfs::
@@ -97,6 +98,51 @@ There are two ways in which a group may In case b) above, even though the child may have runtime remaining it will not be allowed to until the parent's runtime is refreshed. +CFS Bandwidth Quota Caveats +--------------------------- +Once a slice is assigned to a cpu it does not expire. However all but 1ms of +the slice may be returned to the global pool if all threads on that cpu become +unrunnable. This is configured at compile time by the min_cfs_rq_runtime +variable. This is a performance tweak that helps prevent added contention on +the global lock. + +The fact that cpu-local slices do not expire results in some interesting corner +cases that should be understood. + +For cgroup cpu constrained applications that are cpu limited this is a +relatively moot point because they will naturally consume the entirety of their +quota as well as the entirety of each cpu-local slice in each period. As a +result it is expected that nr_periods roughly equal nr_throttled, and that +cpuacct.usage will increase roughly equal to cfs_quota_us in each period. + +For highly-threaded, non-cpu bound applications this non-expiration nuance +allows applications to briefly burst past their quota limits by the amount of +unused slice on each cpu that the task group is running on (typically at most +1ms per cpu or as defined by min_cfs_rq_runtime). This slight burst only +applies if quota had been assigned to a cpu and then not fully used or returned +in previous periods. This burst amount will not be transferred between cores. +As a result, this mechanism still strictly limits the task group to quota +average usage, albeit over a longer time window than a single period. This +also limits the burst ability to no more than 1ms per cpu. This provides +better more predictable user experience for highly threaded applications with +small quota limits on high core count machines. It also eliminates the +propensity to throttle these applications while simultanously using less than +quota amounts of cpu. Another way to say this, is that by allowing the unused +portion of a slice to remain valid across periods we have decreased the +possibility of wastefully expiring quota on cpu-local silos that don't need a +full slice's amount of cpu time. + +The interaction between cpu-bound and non-cpu-bound-interactive applications +should also be considered, especially when single core usage hits 100%. If you +gave each of these applications half of a cpu-core and they both got scheduled +on the same CPU it is theoretically possible that the non-cpu bound application +will use up to 1ms additional quota in some periods, thereby preventing the +cpu-bound application from fully using its quota by that same amount. In these +instances it will be up to the CFS algorithm (see sched-design-CFS.rst) to +decide which application is chosen to run, as they will both be runnable and +have remaining quota. This runtime discrepancy will be made up in the following +periods when the interactive application idles. + Examples -------- 1. Limit a group to 1 CPU worth of runtime::
kernel/sched/fair.c +7 -65
163 lines not on this page · raw message
kernel/sched/sched.h +0 -4
@@ -335,8 +335,6 @@ struct cfs_bandwidth {u64 quota;u64 runtime;s64 hierarchical_quota; -u64 runtime_expires; -int expires_seq;u8 idle;u8 period_active;
@@ -556,8 +554,6 @@ struct cfs_rq {#ifdef CONFIG_CFS_BANDWIDTH int runtime_enabled; -int expires_seq; -u64 runtime_expires;s64 runtime_remaining;u64 throttled_clock;
Greg Kroah-Hartman
maintainerPATCH 159/163 ALSA: usb-audio: DSD auto-detection for Playback Designs
In reply to Greg Kroah-HartmanFrom: Jussi Laako <[email protected]>
[ Upstream commit eb7505d52a2f8b0cfc3fd7146d8cb2dab5a73f0d ]
Add DSD support auto-detection for newer Playback Designs devices. Older device generations have a different USB interface implementation.
Keep the auto-detection VID whitelist sorted.
--- sound/usb/quirks.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
sound/usb/quirks.c +4 -2
@@ -1563,7 +1563,8 @@ u64 snd_usb_interface_dsd_format_quirks(struct snd_usb_audio *chip,struct usb_interface *iface;/* Playback Designs */ -if (USB_ID_VENDOR (chip->usb_id) ==0x23ba ) { +if (USB_ID_VENDOR (chip->usb_id) ==0x23ba && +USB_ID_PRODUCT (chip->usb_id) <0x0110 ) {switch (fp->altsetting) {case 1 : fp->dsd_dop = true;
@@ -1651,8 +1652,9 @@ u64 snd_usb_interface_dsd_format_quirks(struct snd_usb_audio *chip,* from XMOS/Thesycon */ switch (USB_ID_VENDOR (chip->usb_id)) { -case 0x20b1 :/* XMOS based devices */ case 0x152a :/* Thesycon devices */ +case 0x20b1 :/* XMOS based devices */ +case 0x23ba :/* Playback Designs */ case 0x25ce :/* Mytek devices */ case 0x2ab6 :/* T+A devices */ case 0x3842 :/* EVGA */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 160/163 ALSA: usb-audio: Update DSD support quirks for Oppo and Rotel
In reply to Greg Kroah-HartmanFrom: Jussi Laako <[email protected]>
[ Upstream commit 0067e154b11e236d62a7a8205f321b097c21a35b ]
Oppo has issued firmware updates that change alt setting used for DSD support. However, these devices seem to support auto-detection, so support is moved from explicit whitelisting to auto-detection.
Also Rotel devices have USB interfaces that support DSD with auto-detection.
--- sound/usb/quirks.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
sound/usb/quirks.c +2 -4
@@ -1581,9 +1581,6 @@ u64 snd_usb_interface_dsd_format_quirks(struct snd_usb_audio *chip,/* XMOS based USB DACs */ switch (chip->usb_id) {case USB_ID (0x1511 ,0x0037 ):/* AURALiC VEGA */ -case USB_ID (0x22d9 ,0x0416 ):/* OPPO HA-1 */ -case USB_ID (0x22d9 ,0x0436 ):/* OPPO Sonica */ -case USB_ID (0x22d9 ,0x0461 ):/* OPPO UDP-205 */ case USB_ID (0x2522 ,0x0012 ):/* LH Labs VI DAC Infinity */ case USB_ID (0x2772 ,0x0230 ):/* Pro-Ject Pre Box S2 Digital */ if (fp->altsetting ==2 )
@@ -1597,7 +1594,6 @@ u64 snd_usb_interface_dsd_format_quirks(struct snd_usb_audio *chip,case USB_ID (0x16d0 ,0x0733 ):/* Furutech ADL Stratos */ case USB_ID (0x16d0 ,0x09db ):/* NuPrime Audio DAC-9 */ case USB_ID (0x1db5 ,0x0003 ):/* Bryston BDA3 */ -case USB_ID (0x22d9 ,0x0426 ):/* OPPO HA-2 */ case USB_ID (0x22e1 ,0xca01 ):/* HDTA Serenade DSD */ case USB_ID (0x249c ,0x9326 ):/* M2Tech Young MkIII */ case USB_ID (0x2616 ,0x0106 ):/* PS Audio NuWave DAC */
@@ -1654,8 +1650,10 @@ u64 snd_usb_interface_dsd_format_quirks(struct snd_usb_audio *chip,switch (USB_ID_VENDOR (chip->usb_id)) {case 0x152a :/* Thesycon devices */ case 0x20b1 :/* XMOS based devices */ +case 0x22d9 :/* Oppo */ case 0x23ba :/* Playback Designs */ case 0x25ce :/* Mytek devices */ +case 0x278b :/* Rotel? */ case 0x2ab6 :/* T+A devices */ case 0x3842 :/* EVGA */ case 0xc502 :/* HiBy devices */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 161/163 ALSA: usb-audio: Add DSD support for Gustard U16/X26 USB Interface
In reply to Greg Kroah-HartmanFrom: Justin Song <[email protected]>
[ Upstream commit e2995b95a914bbc6b5352be27d5d5f33ec802d2c ]
This patch adds native DSD support for Gustard U16/X26 USB Interface. Tested using VID and fp->dsd_raw method.
--- sound/usb/quirks.c | 1 + 1 file changed, 1 insertion(+)
sound/usb/quirks.c +1 -0
@@ -1654,6 +1654,7 @@ u64 snd_usb_interface_dsd_format_quirks(struct snd_usb_audio *chip,case 0x23ba :/* Playback Designs */ case 0x25ce :/* Mytek devices */ case 0x278b :/* Rotel? */ +case 0x292b :/* Gustard/Ess based devices */ case 0x2ab6 :/* T+A devices */ case 0x3842 :/* EVGA */ case 0xc502 :/* HiBy devices */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 162/163 RDMA/mlx5: Use irq xarray locking for mkey_table
In reply to Greg Kroah-HartmanFrom: Jason Gunthorpe <[email protected]>
[ Upstream commit 1524b12a6e02a85264af4ed208b034a2239ef374 ]
The mkey_table xarray is touched by the reg_mr_callback() function which is called from a hard irq. Thus all other uses of xa_lock must use the _irq variants.
WARNING: inconsistent lock state
5.4.0-rc1 #12 Not tainted
--------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. python3/343 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff888182be1d40 (&(&xa->xa_lock)->rlock#3){?.-.}, at: xa_erase+0x12/0x30 {IN-HARDIRQ-W} state was registered at:
lock_acquire+0xe1/0x200
_raw_spin_lock_irqsave+0x35/0x50
reg_mr_callback+0x2dd/0x450 [mlx5_ib]
mlx5_cmd_exec_cb_handler+0x2c/0x70 [mlx5_core]
mlx5_cmd_comp_handler+0x355/0x840 [mlx5_core]
[..]
Possible unsafe locking scenario: CPU0
----
lock(&(&xa->xa_lock)->rlock#3);
<Interrupt>
lock(&(&xa->xa_lock)->rlock#3);*** DEADLOCK ***
2 locks held by python3/343:
#0: ffff88818eb4bd38 (&uverbs_dev->disassociate_srcu){....}, at: ib_uverbs_ioctl+0xe5/0x1e0 [ib_uverbs] #1: ffff888176c76d38 (&file->hw_destroy_rwsem){++++}, at: uobj_destroy+0x2d/0x90 [ib_uverbs]
stack backtrace: CPU: 3 PID: 343 Comm: python3 Not tainted 5.4.0-rc1 #12 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0x86/0xca print_usage_bug.cold.50+0x2e5/0x355 mark_lock+0x871/0xb50 ? match_held_lock+0x20/0x250 ? check_usage_forwards+0x240/0x240 __lock_acquire+0x7de/0x23a0 ? __kasan_check_read+0x11/0x20 ? mark_lock+0xae/0xb50 ? mark_held_locks+0xb0/0xb0 ? find_held_lock+0xca/0xf0 lock_acquire+0xe1/0x200 ? xa_erase+0x12/0x30 _raw_spin_lock+0x2a/0x40 ? xa_erase+0x12/0x30 xa_erase+0x12/0x30 mlx5_ib_dealloc_mw+0x55/0xa0 [mlx5_ib] uverbs_dealloc_mw+0x3c/0x70 [ib_uverbs] uverbs_free_mw+0x1a/0x20 [ib_uverbs] destroy_hw_idr_uobject+0x49/0xa0 [ib_uverbs] [..]
--- drivers/infiniband/hw/mlx5/mr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/infiniband/hw/mlx5/mr.c +2 -2
@@ -1975,8 +1975,8 @@ int mlx5_ib_dealloc_mw(struct ib_mw *mw)int err;if (IS_ENABLED (CONFIG_INFINIBAND_ON_DEMAND_PAGING )) { -xa_erase (&dev->mdev->priv.mkey_table, -mlx5_base_mkey (mmw->mmkey.key)); +xa_erase_irq (&dev->mdev->priv.mkey_table, +mlx5_base_mkey (mmw->mmkey.key));/* * pagefault_single_data_segment() may be accessing mmw under * SRCU if the user bound an ODP MR to this MW.
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 163/163 sched/fair: Fix -Wunused-but-set-variable warnings
In reply to Greg Kroah-HartmanFrom: Qian Cai <[email protected]>
[ Upstream commit 763a9ec06c409dcde2a761aac4bb83ff3938e0b3 ]
Commit:
de53fd7aedb1 ("sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices")
introduced a few compilation warnings:
kernel/sched/fair.c: In function '__refill_cfs_bandwidth_runtime':
kernel/sched/fair.c:4365:6: warning: variable 'now' set but not used [-Wunused-but-set-variable] kernel/sched/fair.c: In function 'start_cfs_bandwidth':
kernel/sched/fair.c:4992:6: warning: variable 'overrun' set but not used [-Wunused-but-set-variable]
Also, __refill_cfs_bandwidth_runtime() does no longer update the expiration time, so fix the comments accordingly.
--- kernel/sched/fair.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-)
kernel/sched/fair.c +6 -13
@@ -4355,21 +4355,16 @@ static inline u64 sched_cfs_bandwidth_slice(void) }/* -* Replenish runtime according to assigned quota and update expiration time. -* We use sched_clock_cpu directly instead of rq->clock to avoid adding -* additional synchronization around rq->lock. +* Replenish runtime according to assigned quota. We use sched_clock_cpu +* directly instead of rq->clock to avoid adding additional synchronization +* around rq->lock. * * requires cfs_b->lock */ void __refill_cfs_bandwidth_runtime (struct cfs_bandwidth *cfs_b) { -u64 now; - -if (cfs_b->quota ==RUNTIME_INF ) -return ; - - now =sched_clock_cpu (smp_processor_id ()); - cfs_b->runtime = cfs_b->quota; +if (cfs_b->quota !=RUNTIME_INF ) + cfs_b->runtime = cfs_b->quota; }static inline struct cfs_bandwidth *tg_cfs_bandwidth (struct task_group *tg)
@@ -4999,15 +4994,13 @@ static void init_cfs_rq_runtime(struct cfs_rq *cfs_rq)void start_cfs_bandwidth (struct cfs_bandwidth *cfs_b) { -u64 overrun; -lockdep_assert_held (&cfs_b->lock);if (cfs_b->period_active)return ; cfs_b->period_active =1 ; - overrun =hrtimer_forward_now (&cfs_b->period_timer, cfs_b->period); +hrtimer_forward_now (&cfs_b->period_timer, cfs_b->period);hrtimer_start_expires (&cfs_b->period_timer,HRTIMER_MODE_ABS_PINNED ); }
Signature · 1 line
2.20.1
stable-rc/linux-5.3.y boot: 128 boots: 1 failed, 120 passed with 7 offline (v5.3.8-164-g75c9913bbf6e)
stable-rc/linux-5.3.y boot: 128 boots: 1 failed, 120 passed with 7 offline (v5.3.8-164-g75c9913bbf6e)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.3.y/kernel/v5.3.8-164-g75c9913bbf6e/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.3.y/kernel/v5.3.8-164-g75c9913bbf6e/
Tree: stable-rc
Branch: linux-5.3.y
Git Describe: v5.3.8-164-g75c9913bbf6e
Git Commit: 75c9913bbf6e9e64cb669236571e6af45cddfd68
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 77 unique boards, 25 SoC families, 16 builds out of 208
Boot Failure Detected:
arm64:
defconfig:
gcc-8:
meson-gxl-s805x-libretech-ac: 1 failed lab
Offline Platforms:
arm:
sunxi_defconfig:
gcc-8
sun5i-r8-chip: 1 offline lab
sun7i-a20-bananapi: 1 offline lab
multi_v7_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
sun5i-r8-chip: 1 offline lab
sun7i-a20-bananapi: 1 offline lab
davinci_all_defconfig:
gcc-8
dm365evm,legacy: 1 offline lab
qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab---
For more info write to <[email protected]>
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.3.9 release. There are 163 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 06 Nov 2019 09:14:04 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.3.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.
Summary
------------------------------------------------------------------------
kernel: 5.3.9-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.3.y
git commit: 75c9913bbf6e9e64cb669236571e6af45cddfd68
git describe: v5.3.8-164-g75c9913bbf6e
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.3-oe/build/v5.3.8-164-g75c9913bbf6e
No regressions (compared to build v5.3.8)
No fixes (compared to build v5.3.8)
Ran 24209 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-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-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-open-posix-tests
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 17 lines · Naresh Kamboju
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.3.9 release. There are 163 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 06 Nov 2019 09:14:04 PM UTC. 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.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.3.y
and the diffstat can be found below.
Quoted 6 lines
Quoted 3 lines
thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm,x86_64, and i386.
Thanks for testing all of these so quickly and letting me know.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.3.9 release. There are 163 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 06 Nov 2019 09:14:04 PM UTC. Anything received after that time might be too late.
Build results:
total: 158 pass: 158 fail: 0 Qemu test results: total: 391 pass: 391 fail: 0
Guenter
Greg Kroah-Hartman
maintainerQuoted 6 lines · Guenter Roeck
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.3.9 release. There are 163 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.
Quoted 8 lines
Quoted 3 lines
Responses should be made by Wed 06 Nov 2019 09:14:04 PM UTC. Anything received after that time might be too late.
Build results:
total: 158 pass: 158 fail: 0 Qemu test results: total: 391 pass: 391 fail: 0
THanks for testing all of these and letting me know.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.3.9 release. There are 163 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 06 Nov 2019 09:14:04 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.3.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerQuoted 15 lines · shuah
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.3.9 release. There are 163 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 06 Nov 2019 09:14:04 PM UTC. 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.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.3.y
and the diffstat can be found below.
Quoted 6 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.3.9 release. There are 163 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 06 Nov 2019 09:14:04 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.3.y
and the diffstat can be found below.thanks,
greg k-h
All tests for Tegra are passing ...
Test results for stable-v5.3:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 38 pass, 0 failLinux version: 5.3.9-rc1-g75c9913bbf6e
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04Cheers
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 23 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.3.9 release. There are 163 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 06 Nov 2019 09:14:04 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.3.y
and the diffstat can be found below.thanks,
greg k-h
All tests for Tegra are passing ...
Test results for stable-v5.3:
Quoted 8 lines
12 builds: 12 pass, 0 fail 22 boots: 22 pass, 0 fail 38 tests: 38 pass, 0 failLinux version: 5.3.9-rc1-g75c9913bbf6e
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Thanks for testing all of these and letting me know.
greg k-h