March 2018 - Linux-stable-mirror

Patch "fib_semantics: Don't match route with mismatching tclassid" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fib_semantics: Don't match route with mismatching tclassid to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fib_semantics-don-t-match-route-with-mismatching-tclassid.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Mar 6 19:02:12 PST 2018 From: Stefano Brivio <sbrivio(a)redhat.com> Date: Thu, 15 Feb 2018 09:46:03 +0100 Subject: fib_semantics: Don't match route with mismatching tclassid From: Stefano Brivio <sbrivio(a)redhat.com> [ Upstream commit a8c6db1dfd1b1d18359241372bb204054f2c3174 ] In fib_nh_match(), if output interface or gateway are passed in the FIB configuration, we don't have to check next hops of multipath routes to conclude whether we have a match or not. However, we might still have routes with different realms matching the same output interface and gateway configuration, and this needs to cause the match to fail. Otherwise the first route inserted in the FIB will match, regardless of the realms: # ip route add 1.1.1.1 dev eth0 table 1234 realms 1/2 # ip route append 1.1.1.1 dev eth0 table 1234 realms 3/4 # ip route list table 1234 1.1.1.1 dev eth0 scope link realms 1/2 1.1.1.1 dev eth0 scope link realms 3/4 # ip route del 1.1.1.1 dev ens3 table 1234 realms 3/4 # ip route list table 1234 1.1.1.1 dev ens3 scope link realms 3/4 whereas route with realms 3/4 should have been deleted instead. Explicitly check for fc_flow passed in the FIB configuration (this comes from RTA_FLOW extracted by rtm_to_fib_config()) and fail matching if it differs from nh_tclassid. The handling of RTA_FLOW for multipath routes later in fib_nh_match() is still needed, as we can have multiple RTA_FLOW attributes that need to be matched against the tclassid of each next hop. v2: Check that fc_flow is set before discarding the match, so that the user can still select the first matching rule by not specifying any realm, as suggested by David Ahern. Reported-by: Jianlin Shi <jishi(a)redhat.com> Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> Acked-by: David Ahern <dsahern(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/fib_semantics.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/net/ipv4/fib_semantics.c +++ b/net/ipv4/fib_semantics.c @@ -654,6 +654,11 @@ int fib_nh_match(struct fib_config *cfg, fi->fib_nh, cfg, extack)) return 1; } +#ifdef CONFIG_IP_ROUTE_CLASSID + if (cfg->fc_flow && + cfg->fc_flow != fi->fib_nh->nh_tclassid) + return 1; +#endif if ((!cfg->fc_oif || cfg->fc_oif == fi->fib_nh->nh_oif) && (!cfg->fc_gw || cfg->fc_gw == fi->fib_nh->nh_gw)) return 0; Patches currently in stable-queue which might be from sbrivio(a)redhat.com are queue-4.14/net-ipv4-don-t-allow-setting-net.ipv4.route.min_pmtu-below-68.patch queue-4.14/fib_semantics-don-t-match-route-with-mismatching-tclassid.patch

6 years, 10 months

1
0
0 0

Patch "doc: Change the min default value of tcp_wmem/tcp_rmem." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled doc: Change the min default value of tcp_wmem/tcp_rmem. to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: doc-change-the-min-default-value-of-tcp_wmem-tcp_rmem.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Mar 6 19:02:12 PST 2018 From: Tonghao Zhang <xiangxia.m.yue(a)gmail.com> Date: Sun, 4 Feb 2018 18:07:10 -0800 Subject: doc: Change the min default value of tcp_wmem/tcp_rmem. From: Tonghao Zhang <xiangxia.m.yue(a)gmail.com> [ Upstream commit a61a86f8db92923a2a4c857c49a795bcae754497 ] The SK_MEM_QUANTUM was changed from PAGE_SIZE to 4096. And the tcp_wmem/tcp_rmem min default values are 4096. Fixes: bd68a2a854ad ("net: set SK_MEM_QUANTUM to 4096") Cc: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Tonghao Zhang <xiangxia.m.yue(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/networking/ip-sysctl.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -508,7 +508,7 @@ tcp_rmem - vector of 3 INTEGERs: min, de min: Minimal size of receive buffer used by TCP sockets. It is guaranteed to each TCP socket, even under moderate memory pressure. - Default: 1 page + Default: 4K default: initial size of receive buffer used by TCP sockets. This value overrides net.core.rmem_default used by other protocols. @@ -666,7 +666,7 @@ tcp_window_scaling - BOOLEAN tcp_wmem - vector of 3 INTEGERs: min, default, max min: Amount of memory reserved for send buffers for TCP sockets. Each TCP socket has rights to use it due to fact of its birth. - Default: 1 page + Default: 4K default: initial size of send buffer used by TCP sockets. This value overrides net.core.wmem_default used by other protocols. Patches currently in stable-queue which might be from xiangxia.m.yue(a)gmail.com are queue-4.14/doc-change-the-min-default-value-of-tcp_wmem-tcp_rmem.patch

6 years, 10 months

1
0
0 0

Patch "cls_u32: fix use after free in u32_destroy_key()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cls_u32: fix use after free in u32_destroy_key() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cls_u32-fix-use-after-free-in-u32_destroy_key.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Mar 6 19:02:12 PST 2018 From: Paolo Abeni <pabeni(a)redhat.com> Date: Mon, 5 Feb 2018 22:23:01 +0100 Subject: cls_u32: fix use after free in u32_destroy_key() From: Paolo Abeni <pabeni(a)redhat.com> [ Upstream commit d7cdee5ea8d28ae1b6922deb0c1badaa3aa0ef8c ] Li Shuang reported an Oops with cls_u32 due to an use-after-free in u32_destroy_key(). The use-after-free can be triggered with: dev=lo tc qdisc add dev $dev root handle 1: htb default 10 tc filter add dev $dev parent 1: prio 5 handle 1: protocol ip u32 divisor 256 tc filter add dev $dev protocol ip parent 1: prio 5 u32 ht 800:: match ip dst\ 10.0.0.0/8 hashkey mask 0x0000ff00 at 16 link 1: tc qdisc del dev $dev root Which causes the following kasan splat: ================================================================== BUG: KASAN: use-after-free in u32_destroy_key.constprop.21+0x117/0x140 [cls_u32] Read of size 4 at addr ffff881b83dae618 by task kworker/u48:5/571 CPU: 17 PID: 571 Comm: kworker/u48:5 Not tainted 4.15.0+ #87 Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.1.7 06/16/2016 Workqueue: tc_filter_workqueue u32_delete_key_freepf_work [cls_u32] Call Trace: dump_stack+0xd6/0x182 ? dma_virt_map_sg+0x22e/0x22e print_address_description+0x73/0x290 kasan_report+0x277/0x360 ? u32_destroy_key.constprop.21+0x117/0x140 [cls_u32] u32_destroy_key.constprop.21+0x117/0x140 [cls_u32] u32_delete_key_freepf_work+0x1c/0x30 [cls_u32] process_one_work+0xae0/0x1c80 ? sched_clock+0x5/0x10 ? pwq_dec_nr_in_flight+0x3c0/0x3c0 ? _raw_spin_unlock_irq+0x29/0x40 ? trace_hardirqs_on_caller+0x381/0x570 ? _raw_spin_unlock_irq+0x29/0x40 ? finish_task_switch+0x1e5/0x760 ? finish_task_switch+0x208/0x760 ? preempt_notifier_dec+0x20/0x20 ? __schedule+0x839/0x1ee0 ? check_noncircular+0x20/0x20 ? firmware_map_remove+0x73/0x73 ? find_held_lock+0x39/0x1c0 ? worker_thread+0x434/0x1820 ? lock_contended+0xee0/0xee0 ? lock_release+0x1100/0x1100 ? init_rescuer.part.16+0x150/0x150 ? retint_kernel+0x10/0x10 worker_thread+0x216/0x1820 ? process_one_work+0x1c80/0x1c80 ? lock_acquire+0x1a5/0x540 ? lock_downgrade+0x6b0/0x6b0 ? sched_clock+0x5/0x10 ? lock_release+0x1100/0x1100 ? compat_start_thread+0x80/0x80 ? do_raw_spin_trylock+0x190/0x190 ? _raw_spin_unlock_irq+0x29/0x40 ? trace_hardirqs_on_caller+0x381/0x570 ? _raw_spin_unlock_irq+0x29/0x40 ? finish_task_switch+0x1e5/0x760 ? finish_task_switch+0x208/0x760 ? preempt_notifier_dec+0x20/0x20 ? __schedule+0x839/0x1ee0 ? kmem_cache_alloc_trace+0x143/0x320 ? firmware_map_remove+0x73/0x73 ? sched_clock+0x5/0x10 ? sched_clock_cpu+0x18/0x170 ? find_held_lock+0x39/0x1c0 ? schedule+0xf3/0x3b0 ? lock_downgrade+0x6b0/0x6b0 ? __schedule+0x1ee0/0x1ee0 ? do_wait_intr_irq+0x340/0x340 ? do_raw_spin_trylock+0x190/0x190 ? _raw_spin_unlock_irqrestore+0x32/0x60 ? process_one_work+0x1c80/0x1c80 ? process_one_work+0x1c80/0x1c80 kthread+0x312/0x3d0 ? kthread_create_worker_on_cpu+0xc0/0xc0 ret_from_fork+0x3a/0x50 Allocated by task 1688: kasan_kmalloc+0xa0/0xd0 __kmalloc+0x162/0x380 u32_change+0x1220/0x3c9e [cls_u32] tc_ctl_tfilter+0x1ba6/0x2f80 rtnetlink_rcv_msg+0x4f0/0x9d0 netlink_rcv_skb+0x124/0x320 netlink_unicast+0x430/0x600 netlink_sendmsg+0x8fa/0xd60 sock_sendmsg+0xb1/0xe0 ___sys_sendmsg+0x678/0x980 __sys_sendmsg+0xc4/0x210 do_syscall_64+0x232/0x7f0 return_from_SYSCALL_64+0x0/0x75 Freed by task 112: kasan_slab_free+0x71/0xc0 kfree+0x114/0x320 rcu_process_callbacks+0xc3f/0x1600 __do_softirq+0x2bf/0xc06 The buggy address belongs to the object at ffff881b83dae600 which belongs to the cache kmalloc-4096 of size 4096 The buggy address is located 24 bytes inside of 4096-byte region [ffff881b83dae600, ffff881b83daf600) The buggy address belongs to the page: page:ffffea006e0f6a00 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0x17ffffc0008100(slab|head) raw: 0017ffffc0008100 0000000000000000 0000000000000000 0000000100070007 raw: dead000000000100 dead000000000200 ffff880187c0e600 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff881b83dae500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff881b83dae580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff881b83dae600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff881b83dae680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff881b83dae700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== The problem is that the htnode is freed before the linked knodes and the latter will try to access the first at u32_destroy_key() time. This change addresses the issue using the htnode refcnt to guarantee the correct free order. While at it also add a RCU annotation, to keep sparse happy. v1 -> v2: use rtnl_derefence() instead of RCU read locks v2 -> v3: - don't check refcnt in u32_destroy_hnode() - cleaned-up u32_destroy() implementation - cleaned-up code comment v3 -> v4: - dropped unneeded comment Reported-by: Li Shuang <shuali(a)redhat.com> Fixes: c0d378ef1266 ("net_sched: use tcf_queue_work() in u32 filter") Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Acked-by: Cong Wang <xiyou.wangcong(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sched/cls_u32.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) --- a/net/sched/cls_u32.c +++ b/net/sched/cls_u32.c @@ -398,10 +398,12 @@ static int u32_init(struct tcf_proto *tp static int u32_destroy_key(struct tcf_proto *tp, struct tc_u_knode *n, bool free_pf) { + struct tc_u_hnode *ht = rtnl_dereference(n->ht_down); + tcf_exts_destroy(&n->exts); tcf_exts_put_net(&n->exts); - if (n->ht_down) - n->ht_down->refcnt--; + if (ht && --ht->refcnt == 0) + kfree(ht); #ifdef CONFIG_CLS_U32_PERF if (free_pf) free_percpu(n->pf); @@ -649,16 +651,15 @@ static void u32_destroy(struct tcf_proto hlist_del(&tp_c->hnode); - for (ht = rtnl_dereference(tp_c->hlist); - ht; - ht = rtnl_dereference(ht->next)) { - ht->refcnt--; - u32_clear_hnode(tp, ht); - } - while ((ht = rtnl_dereference(tp_c->hlist)) != NULL) { + u32_clear_hnode(tp, ht); RCU_INIT_POINTER(tp_c->hlist, ht->next); - kfree_rcu(ht, rcu); + + /* u32_destroy_key() will later free ht for us, if it's + * still referenced by some knode + */ + if (--ht->refcnt == 0) + kfree_rcu(ht, rcu); } kfree(tp_c); Patches currently in stable-queue which might be from pabeni(a)redhat.com are queue-4.14/cls_u32-fix-use-after-free-in-u32_destroy_key.patch

6 years, 10 months

1
0
0 0

Patch "bridge: Fix VLAN reference count problem" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bridge: Fix VLAN reference count problem to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bridge-fix-vlan-reference-count-problem.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Mar 6 19:02:12 PST 2018 From: Ido Schimmel <idosch(a)mellanox.com> Date: Sun, 25 Feb 2018 21:59:06 +0200 Subject: bridge: Fix VLAN reference count problem From: Ido Schimmel <idosch(a)mellanox.com> [ Upstream commit 0e5a82efda872c2469c210957d7d4161ef8f4391 ] When a VLAN is added on a port, a reference is taken on the corresponding master VLAN entry. If it does not already exist, then it is created and a reference taken. However, in the second case a reference is not really taken when CONFIG_REFCOUNT_FULL is enabled as refcount_inc() is replaced by refcount_inc_not_zero(). Fix this by using refcount_set() on a newly created master VLAN entry. Fixes: 251277598596 ("net, bridge: convert net_bridge_vlan.refcnt from atomic_t to refcount_t") Signed-off-by: Ido Schimmel <idosch(a)mellanox.com> Acked-by: Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/bridge/br_vlan.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/bridge/br_vlan.c +++ b/net/bridge/br_vlan.c @@ -157,6 +157,8 @@ static struct net_bridge_vlan *br_vlan_g masterv = br_vlan_find(vg, vid); if (WARN_ON(!masterv)) return NULL; + refcount_set(&masterv->refcnt, 1); + return masterv; } refcount_inc(&masterv->refcnt); Patches currently in stable-queue which might be from idosch(a)mellanox.com are queue-4.14/mlxsw-spectrum_router-fix-error-path-in-mlxsw_sp_vr_create.patch queue-4.14/mlxsw-spectrum_router-do-not-unconditionally-clear-route-offload-indication.patch queue-4.14/bridge-fix-vlan-reference-count-problem.patch queue-4.14/net-ipv4-set-addr_type-in-hash_keys-for-forwarded-case.patch queue-4.14/mlxsw-spectrum_switchdev-check-success-of-fdb-add-operation.patch

6 years, 10 months

1
0
0 0

Patch "bridge: check brport attr show in brport_show" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bridge: check brport attr show in brport_show to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bridge-check-brport-attr-show-in-brport_show.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Mar 6 19:02:12 PST 2018 From: Xin Long <lucien.xin(a)gmail.com> Date: Mon, 12 Feb 2018 17:15:40 +0800 Subject: bridge: check brport attr show in brport_show From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit 1b12580af1d0677c3c3a19e35bfe5d59b03f737f ] Now br_sysfs_if file flush doesn't have attr show. To read it will cause kernel panic after users chmod u+r this file. Xiong found this issue when running the commands: ip link add br0 type bridge ip link add type veth ip link set veth0 master br0 chmod u+r /sys/devices/virtual/net/veth0/brport/flush timeout 3 cat /sys/devices/virtual/net/veth0/brport/flush kernel crashed with NULL a pointer dereference call trace. This patch is to fix it by return -EINVAL when brport_attr->show is null, just the same as the check for brport_attr->store in brport_store(). Fixes: 9cf637473c85 ("bridge: add sysfs hook to flush forwarding table") Reported-by: Xiong Zhou <xzhou(a)redhat.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/bridge/br_sysfs_if.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/bridge/br_sysfs_if.c +++ b/net/bridge/br_sysfs_if.c @@ -235,6 +235,9 @@ static ssize_t brport_show(struct kobjec struct brport_attribute *brport_attr = to_brport_attr(attr); struct net_bridge_port *p = to_brport(kobj); + if (!brport_attr->show) + return -EINVAL; + return brport_attr->show(p, buf); } Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-4.14/bridge-check-brport-attr-show-in-brport_show.patch queue-4.14/sctp-do-not-pr_err-for-the-duplicated-node-in-transport-rhlist.patch

6 years, 10 months

1
0
0 0

Patch "amd-xgbe: Restore PCI interrupt enablement setting on resume" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled amd-xgbe: Restore PCI interrupt enablement setting on resume to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: amd-xgbe-restore-pci-interrupt-enablement-setting-on-resume.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Mar 6 19:02:12 PST 2018 From: Tom Lendacky <thomas.lendacky(a)amd.com> Date: Tue, 20 Feb 2018 15:22:05 -0600 Subject: amd-xgbe: Restore PCI interrupt enablement setting on resume From: Tom Lendacky <thomas.lendacky(a)amd.com> [ Upstream commit cfd092f2db8b4b6727e1c03ef68a7842e1023573 ] After resuming from suspend, the PCI device support must re-enable the interrupt setting so that interrupts are actually delivered. Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c @@ -426,6 +426,8 @@ static int xgbe_pci_resume(struct pci_de struct net_device *netdev = pdata->netdev; int ret = 0; + XP_IOWRITE(pdata, XP_INT_EN, 0x1fffff); + pdata->lpm_ctrl &= ~MDIO_CTRL1_LPOWER; XMDIO_WRITE(pdata, MDIO_MMD_PCS, MDIO_CTRL1, pdata->lpm_ctrl); Patches currently in stable-queue which might be from thomas.lendacky(a)amd.com are queue-4.14/net-amd-xgbe-fix-comparison-to-bitshift-when-dealing-with-a-mask.patch queue-4.14/amd-xgbe-restore-pci-interrupt-enablement-setting-on-resume.patch

6 years, 10 months

1
0
0 0

Re: [PATCH 0/29] arm meltdown fix backporting review for lts 4.9

by Greg KH

On Mon, Mar 05, 2018 at 12:46:38PM +0000, Mark Brown wrote: > On Fri, Mar 02, 2018 at 05:54:15PM +0100, Greg KH wrote: > > On Fri, Mar 02, 2018 at 05:14:50PM +0800, Alex Shi wrote: > > > On 03/01/2018 11:24 PM, Greg KH wrote: > > > > > And why are you making this patchset up? What is wrong with the patches > > > > in the android-common tree for this? > > > > We believe the LTS is the base kernel for android/lsk, so the fixing > > > patches should get it first and then merge to other tree. > > > But you know that android-common is already fine here, the needed > > patches are all integrated into there, so no additional work is needed > > for android devices. So what devices do you expect to use this 4.9 > > backport? > > See below... > > > What is "lsk"? > > The Linaro Stable Kernel, it's LTS plus some feature backports. > > > But really, I don't see this need as all ARM devices that I know of that > > are stuck on 4.9.y are already using the android-common tree. Same for > > 4.4.y. Do you know of any that are not, and that can not just use > > 4.14.y instead? > > There's way more to ARM than just Android systems, assuming that getting > things into the Android kernel is enough is like assuming that x86 is > covered since the distros have their own backports - it covers a lot of > users but not everyone. Off the top of my head there's things like > routers, NASs, cameras, IoT, radio systems, industrial appliances, set > top boxes and these days even servers. Most of these segments are just > as conservative about taking new kernel versions on shipping product as > the phone vendors are, the practices that make people relucant to take > bigger updates in production are general engineering practices common > across industry. I know there is lots more than Android to ARM, but the huge majority by quantity is Android. What I'm saying here is look at all of the backports that were required to get this working in the android tree. It was non-trivial by a long shot, and based on that work, this series feels really "small" and I'm really worried that it's not really working or solving the problem here. There are major features that were backported to the android trees for ARM that the upstream features for Spectre and Meltdown built on top of to get their solution. To not backport all of that is a huge risk, right? So that's why I keep pointing people at the android trees. Look at what they did there. There's nothing stoping anyone who is really insistant on staying on these old kernel versions from pulling from those branches to get these bugfixes in a known stable, and tested, implementation. That's why I point people there[1]. To do all of the backporting and add the new features feels _way_ beyond what I should be taking into the stable kernels. We didn't do it for x86, why should we do it for ARM? Yes, we did a horrid hack for the x86 backports (with the known issues that it has, and people seem to keep ignoring, which is crazy), and I would suggest NOT doing that same type of hack for ARM, but go grab a tree that we all know to work correctly if you are suck with these old kernels! Or just move to 4.14.y. Seriously, that's probably the safest thing in the long run for anyone here. And when you realize you can't do that, go yell at your SoC for forcing you into the nightmare that they conned you into by their 3+ million lines added to their kernel tree. You were always living on borowed time, and it looks like that time is finally up... thanks, greg k-h [1] It's also why I keep doing the LTS merges into the android-common trees within days of the upstream LTS release (today being an exception). That way once you do a pull/merge, you can just keep always merging to keep a secure device that is always up to date with the latest LTS releases in a simple way. How much easier can I make it for the ARM ecosystem here, really? Oh, I know, get the SoC vendors to merge from the android-common trees into their trees. Look, that's already happening today for at least 3 major SoCs! So just go pull the update from your SoC today, for your chip, and it automatically has all of these fixes in it already! If you know a SoC that is not pulling these updates regularly, let me know and I'll work with them to resolve that[2]. [2] I have offered to do that merge myself, from the android-common trees into any "internal" tree, so that future merges happen cleanly and automatically, for any company that asks for it. So far only one company has taken me up on it, and it only took me a week to get it all up and working properly. It took a ton of "fun" quilt and git work, but in the end, it all worked, and has worked cleanly since then, showing it can be done.

6 years, 10 months

2
1
0 0

Please apply 32cba57ba74be to v4.1.y

by Guenter Roeck

Hi Sasha, due to improved testing, I see crashes when running sabrelite images in qemu with v4.1.y and older kernels. Please apply 32cba57ba74be ("net: fec: introduce fec_ptp_stop and use in probe fail path") to v4.1.y to fix the problem in this release. I'll send a backport to v3.18 separately. Thanks, Guenter

6 years, 10 months

1
0
0 0

Patch "x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-xen-zero-msr_ia32_spec_ctrl-before-suspend.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 71c208dd54ab971036d83ff6d9837bae4976e623 Mon Sep 17 00:00:00 2001 From: Juergen Gross <jgross(a)suse.com> Date: Mon, 26 Feb 2018 15:08:18 +0100 Subject: x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend From: Juergen Gross <jgross(a)suse.com> commit 71c208dd54ab971036d83ff6d9837bae4976e623 upstream. Older Xen versions (4.5 and before) might have problems migrating pv guests with MSR_IA32_SPEC_CTRL having a non-zero value. So before suspending zero that MSR and restore it after being resumed. Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Jan Beulich <jbeulich(a)suse.com> Cc: stable(a)vger.kernel.org Cc: xen-devel(a)lists.xenproject.org Cc: boris.ostrovsky(a)oracle.com Link: https://lkml.kernel.org/r/20180226140818.4849-1-jgross@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/xen/suspend.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --- a/arch/x86/xen/suspend.c +++ b/arch/x86/xen/suspend.c @@ -1,11 +1,14 @@ #include <linux/types.h> #include <linux/tick.h> +#include <linux/percpu-defs.h> #include <xen/xen.h> #include <xen/interface/xen.h> #include <xen/grant_table.h> #include <xen/events.h> +#include <asm/cpufeatures.h> +#include <asm/msr-index.h> #include <asm/xen/hypercall.h> #include <asm/xen/page.h> #include <asm/fixmap.h> @@ -68,6 +71,8 @@ static void xen_pv_post_suspend(int susp xen_mm_unpin_all(); } +static DEFINE_PER_CPU(u64, spec_ctrl); + void xen_arch_pre_suspend(void) { if (xen_pv_domain()) @@ -84,6 +89,9 @@ void xen_arch_post_suspend(int cancelled static void xen_vcpu_notify_restore(void *data) { + if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) + wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl)); + /* Boot processor notified via generic timekeeping_resume() */ if (smp_processor_id() == 0) return; @@ -93,7 +101,15 @@ static void xen_vcpu_notify_restore(void static void xen_vcpu_notify_suspend(void *data) { + u64 tmp; + tick_suspend_local(); + + if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) { + rdmsrl(MSR_IA32_SPEC_CTRL, tmp); + this_cpu_write(spec_ctrl, tmp); + wrmsrl(MSR_IA32_SPEC_CTRL, 0); + } } void xen_arch_resume(void) Patches currently in stable-queue which might be from jgross(a)suse.com are queue-4.4/x86-xen-zero-msr_ia32_spec_ctrl-before-suspend.patch

6 years, 10 months

2
1
0 0

[PATCH] libnvdimm, {btt, blk}: do integrity setup before add_disk()

by Vishal Verma

Prior to 25520d55cdb6 ("block: Inline blk_integrity in struct gendisk") we needed to temporarily add a zero-capacity disk before registering for blk-integrity. But adding a zero-capacity disk caused the partition table scanning to bail early, and this resulted in partitions not coming up after a probe of the BTT or blk namespaces. We can now register for integrity before the disk has been added, and this fixes the rescan problems. Fixes: 25520d55cdb6 ("block: Inline blk_integrity in struct gendisk") Reported-by: Dariusz Dokupil <dariusz.dokupil(a)intel.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: stable(a)vger.kernel.org Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com> --- drivers/nvdimm/blk.c | 3 +-- drivers/nvdimm/btt.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/nvdimm/blk.c b/drivers/nvdimm/blk.c index 345acca576b3..1bd7b3734751 100644 --- a/drivers/nvdimm/blk.c +++ b/drivers/nvdimm/blk.c @@ -278,8 +278,6 @@ static int nsblk_attach_disk(struct nd_namespace_blk *nsblk) disk->queue = q; disk->flags = GENHD_FL_EXT_DEVT; nvdimm_namespace_disk_name(&nsblk->common, disk->disk_name); - set_capacity(disk, 0); - device_add_disk(dev, disk); if (devm_add_action_or_reset(dev, nd_blk_release_disk, disk)) return -ENOMEM; @@ -292,6 +290,7 @@ static int nsblk_attach_disk(struct nd_namespace_blk *nsblk) } set_capacity(disk, available_disk_size >> SECTOR_SHIFT); + device_add_disk(dev, disk); revalidate_disk(disk); return 0; } diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c index 2ef544f10ec8..4b95ac513de2 100644 --- a/drivers/nvdimm/btt.c +++ b/drivers/nvdimm/btt.c @@ -1545,8 +1545,6 @@ static int btt_blk_init(struct btt *btt) queue_flag_set_unlocked(QUEUE_FLAG_NONROT, btt->btt_queue); btt->btt_queue->queuedata = btt; - set_capacity(btt->btt_disk, 0); - device_add_disk(&btt->nd_btt->dev, btt->btt_disk); if (btt_meta_size(btt)) { int rc = nd_integrity_init(btt->btt_disk, btt_meta_size(btt)); @@ -1558,6 +1556,7 @@ static int btt_blk_init(struct btt *btt) } } set_capacity(btt->btt_disk, btt->nlba * btt->sector_size >> 9); + device_add_disk(&btt->nd_btt->dev, btt->btt_disk); btt->nd_btt->size = btt->nlba * (u64)btt->sector_size; revalidate_disk(btt->btt_disk); -- 2.14.3

6 years, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2018