- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "ipv6: addrconf: break critical section in addrconf_verify_rtnl()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: addrconf: break critical section in addrconf_verify_rtnl() to the 4.15-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: ipv6-addrconf-break-critical-section-in-addrconf_verify_rtnl.patch and it can be found in the queue-4.15 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 Wed Feb 7 11:29:33 PST 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Fri, 26 Jan 2018 16:10:43 -0800 Subject: ipv6: addrconf: break critical section in addrconf_verify_rtnl() From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit e64e469b9a2c22d41b3dd7172118760cec22d473 ] Heiner reported a lockdep splat [1] This is caused by attempting GFP_KERNEL allocation while RCU lock is held and BH blocked. We believe that addrconf_verify_rtnl() could run for a long period, so instead of using GFP_ATOMIC here as Ido suggested, we should break the critical section and restart it after the allocation. [1] [86220.125562] ============================= [86220.125586] WARNING: suspicious RCU usage [86220.125612] 4.15.0-rc7-next-20180110+ #7 Not tainted [86220.125641] ----------------------------- [86220.125666] kernel/sched/core.c:6026 Illegal context switch in RCU-bh read-side critical section! [86220.125711] other info that might help us debug this: [86220.125755] rcu_scheduler_active = 2, debug_locks = 1 [86220.125792] 4 locks held by kworker/0:2/1003: [86220.125817] #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000da8e9b73>] process_one_work+0x1de/0x680 [86220.125895] #1: ((addr_chk_work).work){+.+.}, at: [<00000000da8e9b73>] process_one_work+0x1de/0x680 [86220.125959] #2: (rtnl_mutex){+.+.}, at: [<00000000b06d9510>] rtnl_lock+0x12/0x20 [86220.126017] #3: (rcu_read_lock_bh){....}, at: [<00000000aef52299>] addrconf_verify_rtnl+0x1e/0x510 [ipv6] [86220.126111] stack backtrace: [86220.126142] CPU: 0 PID: 1003 Comm: kworker/0:2 Not tainted 4.15.0-rc7-next-20180110+ #7 [86220.126185] Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015 [86220.126250] Workqueue: ipv6_addrconf addrconf_verify_work [ipv6] [86220.126288] Call Trace: [86220.126312] dump_stack+0x70/0x9e [86220.126337] lockdep_rcu_suspicious+0xce/0xf0 [86220.126365] ___might_sleep+0x1d3/0x240 [86220.126390] __might_sleep+0x45/0x80 [86220.126416] kmem_cache_alloc_trace+0x53/0x250 [86220.126458] ? ipv6_add_addr+0xfe/0x6e0 [ipv6] [86220.126498] ipv6_add_addr+0xfe/0x6e0 [ipv6] [86220.126538] ipv6_create_tempaddr+0x24d/0x430 [ipv6] [86220.126580] ? ipv6_create_tempaddr+0x24d/0x430 [ipv6] [86220.126623] addrconf_verify_rtnl+0x339/0x510 [ipv6] [86220.126664] ? addrconf_verify_rtnl+0x339/0x510 [ipv6] [86220.126708] addrconf_verify_work+0xe/0x20 [ipv6] [86220.126738] process_one_work+0x258/0x680 [86220.126765] worker_thread+0x35/0x3f0 [86220.126790] kthread+0x124/0x140 [86220.126813] ? process_one_work+0x680/0x680 [86220.126839] ? kthread_create_worker_on_cpu+0x40/0x40 [86220.126869] ? umh_complete+0x40/0x40 [86220.126893] ? call_usermodehelper_exec_async+0x12a/0x160 [86220.126926] ret_from_fork+0x4b/0x60 [86220.126999] BUG: sleeping function called from invalid context at mm/slab.h:420 [86220.127041] in_atomic(): 1, irqs_disabled(): 0, pid: 1003, name: kworker/0:2 [86220.127082] 4 locks held by kworker/0:2/1003: [86220.127107] #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000da8e9b73>] process_one_work+0x1de/0x680 [86220.127179] #1: ((addr_chk_work).work){+.+.}, at: [<00000000da8e9b73>] process_one_work+0x1de/0x680 [86220.127242] #2: (rtnl_mutex){+.+.}, at: [<00000000b06d9510>] rtnl_lock+0x12/0x20 [86220.127300] #3: (rcu_read_lock_bh){....}, at: [<00000000aef52299>] addrconf_verify_rtnl+0x1e/0x510 [ipv6] [86220.127414] CPU: 0 PID: 1003 Comm: kworker/0:2 Not tainted 4.15.0-rc7-next-20180110+ #7 [86220.127463] Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015 [86220.127528] Workqueue: ipv6_addrconf addrconf_verify_work [ipv6] [86220.127568] Call Trace: [86220.127591] dump_stack+0x70/0x9e [86220.127616] ___might_sleep+0x14d/0x240 [86220.127644] __might_sleep+0x45/0x80 [86220.127672] kmem_cache_alloc_trace+0x53/0x250 [86220.127717] ? ipv6_add_addr+0xfe/0x6e0 [ipv6] [86220.127762] ipv6_add_addr+0xfe/0x6e0 [ipv6] [86220.127807] ipv6_create_tempaddr+0x24d/0x430 [ipv6] [86220.127854] ? ipv6_create_tempaddr+0x24d/0x430 [ipv6] [86220.127903] addrconf_verify_rtnl+0x339/0x510 [ipv6] [86220.127950] ? addrconf_verify_rtnl+0x339/0x510 [ipv6] [86220.127998] addrconf_verify_work+0xe/0x20 [ipv6] [86220.128032] process_one_work+0x258/0x680 [86220.128063] worker_thread+0x35/0x3f0 [86220.128091] kthread+0x124/0x140 [86220.128117] ? process_one_work+0x680/0x680 [86220.128146] ? kthread_create_worker_on_cpu+0x40/0x40 [86220.128180] ? umh_complete+0x40/0x40 [86220.128207] ? call_usermodehelper_exec_async+0x12a/0x160 [86220.128243] ret_from_fork+0x4b/0x60 Fixes: f3d9832e56c4 ("ipv6: addrconf: cleanup locking in ipv6_add_addr") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reported-by: Heiner Kallweit <hkallweit1(a)gmail.com> Reviewed-by: Ido Schimmel <idosch(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/addrconf.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -4352,9 +4352,11 @@ restart: spin_lock(&ifpub->lock); ifpub->regen_count = 0; spin_unlock(&ifpub->lock); + rcu_read_unlock_bh(); ipv6_create_tempaddr(ifpub, ifp, true); in6_ifa_put(ifpub); in6_ifa_put(ifp); + rcu_read_lock_bh(); goto restart; } } else if (time_before(ifp->tstamp + ifp->prefered_lft * HZ - regen_advance * HZ, next)) Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.15/tcp-release-sk_frag.page-in-tcp_disconnect.patch queue-4.15/net_sched-get-rid-of-rcu_barrier-in-tcf_block_put_ext.patch queue-4.15/net-igmp-add-a-missing-rcu-locking-section.patch queue-4.15/ipv6-change-route-cache-aging-logic.patch queue-4.15/soreuseport-fix-mem-leak-in-reuseport_add_sock.patch queue-4.15/revert-defer-call-to-mem_cgroup_sk_alloc.patch queue-4.15/ipv6-addrconf-break-critical-section-in-addrconf_verify_rtnl.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "ip6mr: fix stale iterator" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ip6mr: fix stale iterator to the 4.15-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: ip6mr-fix-stale-iterator.patch and it can be found in the queue-4.15 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 Wed Feb 7 11:29:33 PST 2018 From: Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com> Date: Wed, 31 Jan 2018 16:29:30 +0200 Subject: ip6mr: fix stale iterator From: Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com> [ Upstream commit 4adfa79fc254efb7b0eb3cd58f62c2c3f805f1ba ] When we dump the ip6mr mfc entries via proc, we initialize an iterator with the table to dump but we don't clear the cache pointer which might be initialized from a prior read on the same descriptor that ended. This can result in lock imbalance (an unnecessary unlock) leading to other crashes and hangs. Clear the cache pointer like ipmr does to fix the issue. Thanks for the reliable reproducer. Here's syzbot's trace: WARNING: bad unlock balance detected! 4.15.0-rc3+ #128 Not tainted syzkaller971460/3195 is trying to release lock (mrt_lock) at: [<000000006898068d>] ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553 but there are no more locks to release! other info that might help us debug this: 1 lock held by syzkaller971460/3195: #0: (&p->lock){+.+.}, at: [<00000000744a6565>] seq_read+0xd5/0x13d0 fs/seq_file.c:165 stack backtrace: CPU: 1 PID: 3195 Comm: syzkaller971460 Not tainted 4.15.0-rc3+ #128 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 print_unlock_imbalance_bug+0x12f/0x140 kernel/locking/lockdep.c:3561 __lock_release kernel/locking/lockdep.c:3775 [inline] lock_release+0x5f9/0xda0 kernel/locking/lockdep.c:4023 __raw_read_unlock include/linux/rwlock_api_smp.h:225 [inline] _raw_read_unlock+0x1a/0x30 kernel/locking/spinlock.c:255 ipmr_mfc_seq_stop+0xe1/0x130 net/ipv6/ip6mr.c:553 traverse+0x3bc/0xa00 fs/seq_file.c:135 seq_read+0x96a/0x13d0 fs/seq_file.c:189 proc_reg_read+0xef/0x170 fs/proc/inode.c:217 do_loop_readv_writev fs/read_write.c:673 [inline] do_iter_read+0x3db/0x5b0 fs/read_write.c:897 compat_readv+0x1bf/0x270 fs/read_write.c:1140 do_compat_preadv64+0xdc/0x100 fs/read_write.c:1189 C_SYSC_preadv fs/read_write.c:1209 [inline] compat_SyS_preadv+0x3b/0x50 fs/read_write.c:1203 do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline] do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389 entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125 RIP: 0023:0xf7f73c79 RSP: 002b:00000000e574a15c EFLAGS: 00000292 ORIG_RAX: 000000000000014d RAX: ffffffffffffffda RBX: 000000000000000f RCX: 0000000020a3afb0 RDX: 0000000000000001 RSI: 0000000000000067 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 BUG: sleeping function called from invalid context at lib/usercopy.c:25 in_atomic(): 1, irqs_disabled(): 0, pid: 3195, name: syzkaller971460 INFO: lockdep is turned off. CPU: 1 PID: 3195 Comm: syzkaller971460 Not tainted 4.15.0-rc3+ #128 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 ___might_sleep+0x2b2/0x470 kernel/sched/core.c:6060 __might_sleep+0x95/0x190 kernel/sched/core.c:6013 __might_fault+0xab/0x1d0 mm/memory.c:4525 _copy_to_user+0x2c/0xc0 lib/usercopy.c:25 copy_to_user include/linux/uaccess.h:155 [inline] seq_read+0xcb4/0x13d0 fs/seq_file.c:279 proc_reg_read+0xef/0x170 fs/proc/inode.c:217 do_loop_readv_writev fs/read_write.c:673 [inline] do_iter_read+0x3db/0x5b0 fs/read_write.c:897 compat_readv+0x1bf/0x270 fs/read_write.c:1140 do_compat_preadv64+0xdc/0x100 fs/read_write.c:1189 C_SYSC_preadv fs/read_write.c:1209 [inline] compat_SyS_preadv+0x3b/0x50 fs/read_write.c:1203 do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline] do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389 entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125 RIP: 0023:0xf7f73c79 RSP: 002b:00000000e574a15c EFLAGS: 00000292 ORIG_RAX: 000000000000014d RAX: ffffffffffffffda RBX: 000000000000000f RCX: 0000000020a3afb0 RDX: 0000000000000001 RSI: 0000000000000067 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 WARNING: CPU: 1 PID: 3195 at lib/usercopy.c:26 _copy_to_user+0xb5/0xc0 lib/usercopy.c:26 Reported-by: syzbot <bot+eceb3204562c41a438fa1f2335e0fe4f6886d669(a)syzkaller.appspotmail.com> Signed-off-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/ipv6/ip6mr.c | 1 + 1 file changed, 1 insertion(+) --- a/net/ipv6/ip6mr.c +++ b/net/ipv6/ip6mr.c @@ -495,6 +495,7 @@ static void *ipmr_mfc_seq_start(struct s return ERR_PTR(-ENOENT); it->mrt = mrt; + it->cache = NULL; return *pos ? ipmr_mfc_seq_idx(net, seq->private, *pos - 1) : SEQ_START_TOKEN; } Patches currently in stable-queue which might be from nikolay(a)cumulusnetworks.com are queue-4.15/ip6mr-fix-stale-iterator.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "cls_u32: add missing RCU annotation." has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cls_u32: add missing RCU annotation. to the 4.15-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-add-missing-rcu-annotation.patch and it can be found in the queue-4.15 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 Wed Feb 7 11:29:33 PST 2018 From: Paolo Abeni <pabeni(a)redhat.com> Date: Fri, 2 Feb 2018 16:02:22 +0100 Subject: cls_u32: add missing RCU annotation. From: Paolo Abeni <pabeni(a)redhat.com> [ Upstream commit 058a6c033488494a6b1477b05fe8e1a16e344462 ] In a couple of points of the control path, n->ht_down is currently accessed without the required RCU annotation. The accesses are safe, but sparse complaints. Since we already held the rtnl lock, let use rtnl_dereference(). Fixes: a1b7c5fd7fe9 ("net: sched: add cls_u32 offload hooks for netdevs") Fixes: de5df63228fc ("net: sched: cls_u32 changes to knode must appear atomic to readers") 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 | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/net/sched/cls_u32.c +++ b/net/sched/cls_u32.c @@ -544,6 +544,7 @@ static void u32_remove_hw_knode(struct t static int u32_replace_hw_knode(struct tcf_proto *tp, struct tc_u_knode *n, u32 flags) { + struct tc_u_hnode *ht = rtnl_dereference(n->ht_down); struct tcf_block *block = tp->chain->block; struct tc_cls_u32_offload cls_u32 = {}; bool skip_sw = tc_skip_sw(flags); @@ -563,7 +564,7 @@ static int u32_replace_hw_knode(struct t cls_u32.knode.sel = &n->sel; cls_u32.knode.exts = &n->exts; if (n->ht_down) - cls_u32.knode.link_handle = n->ht_down->handle; + cls_u32.knode.link_handle = ht->handle; err = tc_setup_cb_call(block, NULL, TC_SETUP_CLSU32, &cls_u32, skip_sw); if (err < 0) { @@ -840,8 +841,9 @@ static void u32_replace_knode(struct tcf static struct tc_u_knode *u32_init_knode(struct tcf_proto *tp, struct tc_u_knode *n) { - struct tc_u_knode *new; + struct tc_u_hnode *ht = rtnl_dereference(n->ht_down); struct tc_u32_sel *s = &n->sel; + struct tc_u_knode *new; new = kzalloc(sizeof(*n) + s->nkeys*sizeof(struct tc_u32_key), GFP_KERNEL); @@ -859,11 +861,11 @@ static struct tc_u_knode *u32_init_knode new->fshift = n->fshift; new->res = n->res; new->flags = n->flags; - RCU_INIT_POINTER(new->ht_down, n->ht_down); + RCU_INIT_POINTER(new->ht_down, ht); /* bump reference count as long as we hold pointer to structure */ - if (new->ht_down) - new->ht_down->refcnt++; + if (ht) + ht->refcnt++; #ifdef CONFIG_CLS_U32_PERF /* Statistics may be incremented by readers during update Patches currently in stable-queue which might be from pabeni(a)redhat.com are queue-4.15/net_sched-get-rid-of-rcu_barrier-in-tcf_block_put_ext.patch queue-4.15/ipv6-change-route-cache-aging-logic.patch queue-4.15/cls_u32-add-missing-rcu-annotation.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch "kbuild: rpm-pkg: keep spec file until make mrproper" 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 kbuild: rpm-pkg: keep spec file until make mrproper 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: kbuild-rpm-pkg-keep-spec-file-until-make-mrproper.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 af60e207087975d069858741c44ed4f450330ac4 Mon Sep 17 00:00:00 2001 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> Date: Sat, 30 Sep 2017 10:10:10 +0900 Subject: kbuild: rpm-pkg: keep spec file until make mrproper From: Masahiro Yamada <yamada.masahiro(a)socionext.com> commit af60e207087975d069858741c44ed4f450330ac4 upstream. If build fails during (bin)rpm-pkg, the spec file is not cleaned by anyone until the next successful build of the package. We do not have to immediately delete the spec file in case somebody may want to take a look at it. Instead, make them ignored by git, and cleaned up by make mrproper. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- .gitignore | 5 +++++ scripts/package/Makefile | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) --- a/.gitignore +++ b/.gitignore @@ -56,6 +56,11 @@ modules.builtin /Module.markers # +# RPM spec file (make rpm-pkg) +# +/*.spec + +# # Debian directory (make deb-pkg) # /debian/ --- a/scripts/package/Makefile +++ b/scripts/package/Makefile @@ -50,7 +50,6 @@ rpm-pkg rpm: FORCE $(CONFIG_SHELL) $(MKSPEC) >$(objtree)/kernel.spec $(call cmd,src_tar,$(KERNELPATH),kernel.spec) +rpmbuild $(RPMOPTS) --target $(UTS_MACHINE) -ta $(KERNELPATH).tar.gz - rm $(KERNELPATH).tar.gz kernel.spec # binrpm-pkg # --------------------------------------------------------------------------- @@ -59,7 +58,8 @@ binrpm-pkg: FORCE $(CONFIG_SHELL) $(MKSPEC) prebuilt > $(objtree)/binkernel.spec +rpmbuild $(RPMOPTS) --define "_builddir $(objtree)" --target \ $(UTS_MACHINE) -bb $(objtree)/binkernel.spec - rm binkernel.spec + +clean-files += $(objtree)/*.spec # Deb target # --------------------------------------------------------------------------- Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are queue-4.14/gitignore-move-.dtb-and-.dtb.s-patterns-to-the-top-level-.gitignore.patch queue-4.14/kbuild-rpm-pkg-keep-spec-file-until-make-mrproper.patch queue-4.14/gitignore-sort-normal-pattern-rules-alphabetically.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch ".gitignore: sort normal pattern rules alphabetically" 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 .gitignore: sort normal pattern rules alphabetically 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: gitignore-sort-normal-pattern-rules-alphabetically.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 1377dd3e29878b8f5d9f5c9000975f50a428a0cd Mon Sep 17 00:00:00 2001 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> Date: Tue, 31 Oct 2017 00:33:45 +0900 Subject: .gitignore: sort normal pattern rules alphabetically From: Masahiro Yamada <yamada.masahiro(a)socionext.com> commit 1377dd3e29878b8f5d9f5c9000975f50a428a0cd upstream. We are having more and more ignore patterns. Sort the list alphabetically. We will easily catch duplicated patterns if any. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Signed-off-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- .gitignore | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) --- a/.gitignore +++ b/.gitignore @@ -7,38 +7,38 @@ # command after changing this file, to see if there are # any tracked files which get ignored after the change. # -# Normal rules +# Normal rules (sorted alphabetically) # .* +*.a +*.bin +*.bz2 +*.c.[012]*.* +*.dwo +*.elf +*.gcno +*.gz +*.i +*.ko +*.ll +*.lst +*.lz4 +*.lzma +*.lzo +*.mod.c *.o *.o.* -*.a +*.order +*.patch *.s -*.ko *.so *.so.dbg -*.mod.c -*.i -*.lst +*.su *.symtypes -*.order -*.elf -*.bin *.tar -*.gz -*.bz2 -*.lzma *.xz -*.lz4 -*.lzo -*.patch -*.gcno -*.ll -modules.builtin Module.symvers -*.dwo -*.su -*.c.[012]*.* +modules.builtin # # Top-level generic files Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are queue-4.14/gitignore-move-.dtb-and-.dtb.s-patterns-to-the-top-level-.gitignore.patch queue-4.14/kbuild-rpm-pkg-keep-spec-file-until-make-mrproper.patch queue-4.14/gitignore-sort-normal-pattern-rules-alphabetically.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] Patch ".gitignore: move *.dtb and *.dtb.S patterns to the top-level .gitignore" 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 .gitignore: move *.dtb and *.dtb.S patterns to the top-level .gitignore 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: gitignore-move-.dtb-and-.dtb.s-patterns-to-the-top-level-.gitignore.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 10b62a2f785ab55857380f0c63d9fa468fd8c676 Mon Sep 17 00:00:00 2001 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> Date: Tue, 31 Oct 2017 00:33:46 +0900 Subject: .gitignore: move *.dtb and *.dtb.S patterns to the top-level .gitignore From: Masahiro Yamada <yamada.masahiro(a)socionext.com> commit 10b62a2f785ab55857380f0c63d9fa468fd8c676 upstream. Most of DT files are compiled under arch/*/boot/dts/, but we have some other directories, like drivers/of/unittest-data/. We often miss to add gitignore patterns per directory. Since there are no source files that end with .dtb or .dtb.S, we can ignore the patterns globally. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Signed-off-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- .gitignore | 2 ++ arch/arc/boot/.gitignore | 1 - arch/arm/boot/.gitignore | 1 - arch/arm64/boot/dts/.gitignore | 1 - arch/metag/boot/.gitignore | 1 - arch/microblaze/boot/.gitignore | 1 - arch/mips/boot/.gitignore | 1 - arch/nios2/boot/.gitignore | 1 - arch/powerpc/boot/.gitignore | 1 - arch/xtensa/boot/.gitignore | 1 - drivers/of/unittest-data/.gitignore | 2 -- 11 files changed, 2 insertions(+), 11 deletions(-) --- a/.gitignore +++ b/.gitignore @@ -14,6 +14,8 @@ *.bin *.bz2 *.c.[012]*.* +*.dtb +*.dtb.S *.dwo *.elf *.gcno --- a/arch/arc/boot/.gitignore +++ b/arch/arc/boot/.gitignore @@ -1,2 +1 @@ -*.dtb* uImage --- a/arch/arm/boot/.gitignore +++ b/arch/arm/boot/.gitignore @@ -3,4 +3,3 @@ zImage xipImage bootpImage uImage -*.dtb --- a/arch/arm64/boot/dts/.gitignore +++ /dev/null @@ -1 +0,0 @@ -*.dtb --- a/arch/metag/boot/.gitignore +++ b/arch/metag/boot/.gitignore @@ -1,4 +1,3 @@ vmlinux* uImage* ramdisk.* -*.dtb* --- a/arch/microblaze/boot/.gitignore +++ b/arch/microblaze/boot/.gitignore @@ -1,3 +1,2 @@ -*.dtb linux.bin* simpleImage.* --- a/arch/mips/boot/.gitignore +++ b/arch/mips/boot/.gitignore @@ -5,4 +5,3 @@ zImage zImage.tmp calc_vmlinuz_load_addr uImage -*.dtb --- a/arch/nios2/boot/.gitignore +++ b/arch/nios2/boot/.gitignore @@ -1,2 +1 @@ -*.dtb vmImage --- a/arch/powerpc/boot/.gitignore +++ b/arch/powerpc/boot/.gitignore @@ -18,7 +18,6 @@ otheros.bld uImage cuImage.* dtbImage.* -*.dtb treeImage.* vmlinux.strip zImage --- a/arch/xtensa/boot/.gitignore +++ b/arch/xtensa/boot/.gitignore @@ -1,3 +1,2 @@ uImage zImage.redboot -*.dtb --- a/drivers/of/unittest-data/.gitignore +++ /dev/null @@ -1,2 +0,0 @@ -testcases.dtb -testcases.dtb.S Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are queue-4.14/gitignore-move-.dtb-and-.dtb.s-patterns-to-the-top-level-.gitignore.patch queue-4.14/kbuild-rpm-pkg-keep-spec-file-until-make-mrproper.patch queue-4.14/gitignore-sort-normal-pattern-rules-alphabetically.patch

7 years, 3 months

1
0
0 0

Re: [Linux-stable-mirror] Regression for ip6-in-ip4 IPsec tunnel in 4.14.16

by Mike Maloney

On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez <corsac(a)debian.org> wrote: > On Wed, 2018-02-07 at 18:05 +0100, Yves-Alexis Perez wrote: >> I'll try to printk the mtu before returning EINVAL to see why it's lower than >> 1280, but maybe the IP encapsulation is not correctly handled? > > I did: > > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c > index 3763dc01e374..d3c651158d35 100644 > --- a/net/ipv6/ip6_output.c > +++ b/net/ipv6/ip6_output.c > @@ -1215,7 +1215,7 @@ static int ip6_setup_cork(struct sock *sk, struct inet_cork_full *cork, > mtu = np->frag_size; > } > if (mtu < IPV6_MIN_MTU) > - return -EINVAL; > + printk("mtu: %d\n", mtu); > cork->base.fragsize = mtu; > if (dst_allfrag(rt->dst.path)) > cork->base.flags |= IPCORK_ALLFRAG; > > and I get: > > févr. 07 18:19:50 scapa kernel: mtu: 1218 > > and it doesn't depend on the original packet size (same thing happens with > ping -s 100). It also happens with UDP (DNS) traffic, but apparently not with > TCP. > > Regards, > -- > Yves-Alexis Hi Yves-Alexis - I apologize for the problem. It seems to me that tunneling with an outer MTU that causes the inner MTU to be smaller than the min, is potentially problematic in other ways as well. But also it could seem unfortunate that the code with my fix does not look at actual packet size, but instead only looks at the MTU and then fails, even if no packet was going to be so large. The intention of my patch was to prevent a negative number while calculating the maxfraglen in __ip6_append_data(). An alternative fix maybe to instead return an error only if the mtu is less than or equal to the fragheaderlen. Something like: diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 3763dc01e374..5d912a289b95 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1214,8 +1214,6 @@ static int ip6_setup_cork(struct sock *sk, struct inet_cork_full *cork, if (np->frag_size) mtu = np->frag_size; } - if (mtu < IPV6_MIN_MTU) - return -EINVAL; cork->base.fragsize = mtu; if (dst_allfrag(rt->dst.path)) cork->base.flags |= IPCORK_ALLFRAG; @@ -1264,6 +1262,8 @@ static int __ip6_append_data(struct sock *sk, fragheaderlen = sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len + (opt ? opt->opt_nflen : 0); + if (mtu < fragheaderlen + 8) + return -EINVAL; maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen - sizeof(struct frag_hdr); (opt ? opt->opt_nflen : 0); But then we also have to convince ourselves that maxfraglen can never be <= 0. I'd have to think about that. I am not sure if others have thoughts on supporting MTUs configured below the min in the spec. Thanks. -- Mike Maloney

7 years, 3 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 3.18 00/36] 3.18.94-stable review

by Greg Kroah-Hartman

On Tue, Feb 06, 2018 at 11:42:15AM +0000, Harsh Shandilya wrote: > On Tue 6 Feb, 2018, 4:04 PM Greg Kroah-Hartman, <gregkh(a)linuxfoundation.org> > wrote: > > > On Tue, Feb 06, 2018 at 06:48:53AM +0000, Harsh Shandilya wrote: > > > On Tue 6 Feb, 2018, 12:09 AM Greg Kroah-Hartman, < > > gregkh(a)linuxfoundation.org> > > > wrote: > > > > > > > This is the start of the stable review cycle for the 3.18.94 release. > > > > There are 36 patches in this series, all will be posted as a response > > > > to this one. If anyone has any issues with these being applied, please > > > > let me know. > > > > > > > > Responses should be made by Wed Feb 7 18:23:41 UTC 2018. > > > > Anything received after that time might be too late. > > > > > > > > The whole patch series can be found in one patch at: > > > > > > > > kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.94-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-3.18.y > > > > and the diffstat can be found below. > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > > > > > Builds and boots on the OnePlus 3T, no regressions noticed. > > > > Yeah! That device is the only reason I keep this tree alive :) > > > > thanks for testing and letting me know. > > > > greg k-h > > > > Guess I should drop my kernel tree for the device and save you the pain of > maintaining 3.18 :P Heh, maybe :) > Atleast CAF has been keeping up with upstream now thanks to your > kernel-common merges so there's still hope for MSM platform users :) That's good to see. Now if only those platform users would actually update their kernels to these new versions :( > P.S. common merge should go in cleanly, both the merge conflicts I had were > from CAF changes. Thanks for letting me know, that's great to hear as I just had a question from some companies who are worried that taking stable patches will cause tons of merge issues. It hasn't in my experience, and seeing reports of this from others is great news. thanks, greg k-h

7 years, 3 months

2
3
0 0

[Linux-stable-mirror] Patch "x86/microcode/AMD: Do not load when running on a hypervisor" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/AMD: Do not load when running on a hypervisor to the 4.9-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-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch and it can be found in the queue-4.9 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 a15a753539eca8ba243d576f02e7ca9c4b7d7042 Mon Sep 17 00:00:00 2001 From: Borislav Petkov <bp(a)suse.de> Date: Sun, 18 Dec 2016 17:44:13 +0100 Subject: x86/microcode/AMD: Do not load when running on a hypervisor From: Borislav Petkov <bp(a)suse.de> commit a15a753539eca8ba243d576f02e7ca9c4b7d7042 upstream. Doing so is completely void of sense for multiple reasons so prevent it. Set dis_ucode_ldr to true and thus disable the microcode loader by default to address xen pv guests which execute the AP path but not the BSP path. By having it turned off by default, the APs won't run into the loader either. Also, check CPUID(1).ECX[31] which hypervisors set. Well almost, not the xen pv one. That one gets the aforementioned "fix". Also, improve the detection method by caching the final decision whether to continue loading in dis_ucode_ldr and do it once on the BSP. The APs then simply test that value. Signed-off-by: Borislav Petkov <bp(a)suse.de> Tested-by: Juergen Gross <jgross(a)suse.com> Tested-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Acked-by: Juergen Gross <jgross(a)suse.com> Link: http://lkml.kernel.org/r/20161218164414.9649-4-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Rolf Neugebauer <rolf.neugebauer(a)docker.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/core.c | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -43,7 +43,7 @@ #define MICROCODE_VERSION "2.01" static struct microcode_ops *microcode_ops; -static bool dis_ucode_ldr; +static bool dis_ucode_ldr = true; /* * Synchronization. @@ -73,6 +73,7 @@ struct cpu_info_ctx { static bool __init check_loader_disabled_bsp(void) { static const char *__dis_opt_str = "dis_ucode_ldr"; + u32 a, b, c, d; #ifdef CONFIG_X86_32 const char *cmdline = (const char *)__pa_nodebug(boot_command_line); @@ -85,8 +86,23 @@ static bool __init check_loader_disabled bool *res = &dis_ucode_ldr; #endif - if (cmdline_find_option_bool(cmdline, option)) - *res = true; + if (!have_cpuid_p()) + return *res; + + a = 1; + c = 0; + native_cpuid(&a, &b, &c, &d); + + /* + * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not + * completely accurate as xen pv guests don't see that CPUID bit set but + * that's good enough as they don't land on the BSP path anyway. + */ + if (c & BIT(31)) + return *res; + + if (cmdline_find_option_bool(cmdline, option) <= 0) + *res = false; return *res; } @@ -118,9 +134,6 @@ void __init load_ucode_bsp(void) if (check_loader_disabled_bsp()) return; - if (!have_cpuid_p()) - return; - vendor = x86_cpuid_vendor(); family = x86_cpuid_family(); @@ -154,9 +167,6 @@ void load_ucode_ap(void) if (check_loader_disabled_ap()) return; - if (!have_cpuid_p()) - return; - vendor = x86_cpuid_vendor(); family = x86_cpuid_family(); Patches currently in stable-queue which might be from bp(a)suse.de are queue-4.9/x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] [PATCH] rtlwifi: rtl8821ae: Fix connection lost problem correctly

by Larry Finger

There has been a coding error in rtl8821ae since it was first introduced, namely that an 8-bit register was read using a 16-bit read in _rtl8821ae_dbi_read(). This error was fixed with commit 40b368af4b75 ("rtlwifi: Fix alignment issues"); however, this change led to instability in the connection. To restore stability, this change was reverted in commit b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem"). Unfortunately, the unaligned access causes machine checks in ARM architecture, and we were finally forced to find the actual cause of the problem on x86 platforms. Following a suggestion from Pkshih <pkshih(a)realtek.com>, it was found that increasing the ASPM L1 latency from 0 to 7 fixed the instability. This parameter was varied to see if a smaller value would work; however, it appears that 7 is the safest value. A new symbol is defined for this quantity, thus it can be easily changed if necessary. Fixes: b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem") Cc: Stable <stable(a)vger.kernel.org> # 4.14+ Fix-suggested-by: Pkshih <pkshih(a)realtek.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> --- Kalle, This patch should be submitted to 4.16. Larry --- drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 +++-- drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c index f20e77b4bb65..317c1b3101da 100644 --- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c @@ -1123,7 +1123,7 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, u16 addr) } if (0 == tmp) { read_addr = REG_DBI_RDATA + addr % 4; - ret = rtl_read_word(rtlpriv, read_addr); + ret = rtl_read_byte(rtlpriv, read_addr); } return ret; } @@ -1165,7 +1165,8 @@ static void _rtl8821ae_enable_aspm_back_door(struct ieee80211_hw *hw) } tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f); - _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7)); + _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | + ASPM_L1_LATENCY << 3); tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719); _rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4)); diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h index 1c9ed28b42da..4f48b934ec01 100644 --- a/drivers/net/wireless/realtek/rtlwifi/wifi.h +++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h @@ -99,6 +99,7 @@ #define RTL_USB_MAX_RX_COUNT 100 #define QBSS_LOAD_SIZE 5 #define MAX_WMMELE_LENGTH 64 +#define ASPM_L1_LATENCY 7 #define TOTAL_CAM_ENTRY 32 -- 2.16.1

7 years, 3 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror