linux-stable.git/include, branch v4.20.4

block: use rcu_work instead of call_rcu to avoid sleep in softirq

2019-01-22T20:09:57+00:00

commit 94a2c3a32b62e868dc1e3d854326745a7f1b8c7a upstream.

We recently got a stack by syzkaller like this:

BUG: sleeping function called from invalid context at mm/slab.h:361
in_atomic(): 1, irqs_disabled(): 0, pid: 6644, name: blkid
INFO: lockdep is turned off.
CPU: 1 PID: 6644 Comm: blkid Not tainted 4.4.163-514.55.6.9.x86_64+ #76
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
 0000000000000000 5ba6a6b879e50c00 ffff8801f6b07b10 ffffffff81cb2194
 0000000041b58ab3 ffffffff833c7745 ffffffff81cb2080 5ba6a6b879e50c00
 0000000000000000 0000000000000001 0000000000000004 0000000000000000
Call Trace:
   [] __dump_stack lib/dump_stack.c:15 [inline]
   [] dump_stack+0x114/0x1a0 lib/dump_stack.c:51
 [] ___might_sleep+0x291/0x490 kernel/sched/core.c:7675
 [] __might_sleep+0xb3/0x270 kernel/sched/core.c:7637
 [] slab_pre_alloc_hook mm/slab.h:361 [inline]
 [] slab_alloc_node mm/slub.c:2610 [inline]
 [] slab_alloc mm/slub.c:2692 [inline]
 [] kmem_cache_alloc_trace+0x2c3/0x5c0 mm/slub.c:2709
 [] kmalloc include/linux/slab.h:479 [inline]
 [] kzalloc include/linux/slab.h:623 [inline]
 [] kobject_uevent_env+0x2c7/0x1150 lib/kobject_uevent.c:227
 [] kobject_uevent+0x1f/0x30 lib/kobject_uevent.c:374
 [] kobject_cleanup lib/kobject.c:633 [inline]
 [] kobject_release+0x229/0x440 lib/kobject.c:675
 [] kref_sub include/linux/kref.h:73 [inline]
 [] kref_put include/linux/kref.h:98 [inline]
 [] kobject_put+0x72/0xd0 lib/kobject.c:692
 [] put_device+0x25/0x30 drivers/base/core.c:1237
 [] delete_partition_rcu_cb+0x1d4/0x2f0 block/partition-generic.c:232
 [] __rcu_reclaim kernel/rcu/rcu.h:118 [inline]
 [] rcu_do_batch kernel/rcu/tree.c:2705 [inline]
 [] invoke_rcu_callbacks kernel/rcu/tree.c:2973 [inline]
 [] __rcu_process_callbacks kernel/rcu/tree.c:2940 [inline]
 [] rcu_process_callbacks+0x59c/0x1c70 kernel/rcu/tree.c:2957
 [] __do_softirq+0x299/0xe20 kernel/softirq.c:273
 [] invoke_softirq kernel/softirq.c:350 [inline]
 [] irq_exit+0x216/0x2c0 kernel/softirq.c:391
 [] exiting_irq arch/x86/include/asm/apic.h:652 [inline]
 [] smp_apic_timer_interrupt+0x8b/0xc0 arch/x86/kernel/apic/apic.c:926
 [] apic_timer_interrupt+0xa5/0xb0 arch/x86/entry/entry_64.S:746
   [] ? audit_kill_trees+0x180/0x180
 [] fd_install+0x57/0x80 fs/file.c:626
 [] do_sys_open+0x45e/0x550 fs/open.c:1043
 [] SYSC_open fs/open.c:1055 [inline]
 [] SyS_open+0x32/0x40 fs/open.c:1050
 [] entry_SYSCALL_64_fastpath+0x1e/0x9a

In softirq context, we call rcu callback function delete_partition_rcu_cb(),
which may allocate memory by kzalloc with GFP_KERNEL flag. If the
allocation cannot be satisfied, it may sleep. However, That is not allowed
in softirq contex.

Although we found this problem on linux 4.4, the latest kernel version
seems to have this problem as well. And it is very similar to the
previous one:
	https://lkml.org/lkml/2018/7/9/391

Fix it by using RCU workqueue, which allows sleep.

Reviewed-by: Paul E. McKenney 
Signed-off-by: Yufen Yu 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

RDMA/vmw_pvrdma: Return the correct opcode when creating WR

2019-01-22T20:09:53+00:00

commit 6325e01b6cdf4636b721cf7259c1616e3cf28ce2 upstream.

Since the IB_WR_REG_MR opcode value changed, let's set the PVRDMA device
opcodes explicitly.

Reported-by: Ruishuang Wang 
Fixes: 9a59739bd01f ("IB/rxe: Revise the ib_wr_opcode enum")
Cc: stable@vger.kernel.org
Reviewed-by: Bryan Tan 
Reviewed-by: Ruishuang Wang 
Reviewed-by: Vishnu Dasa 
Signed-off-by: Adit Ranadive 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

MIPS: BCM47XX: Setup struct device for the SoC

2019-01-22T20:09:52+00:00

commit 321c46b91550adc03054125fa7a1639390608e1a upstream.

So far we never had any device registered for the SoC. This resulted in
some small issues that we kept ignoring like:
1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing)
2) Lack of proper tree in the /sys/devices/
3) mips_dma_alloc_coherent() silently handling empty coherent_dma_mask

Kernel 4.19 came with a lot of DMA changes and caused a regression on
bcm47xx. Starting with the commit f8c55dc6e828 ("MIPS: use generic dma
noncoherent ops for simple noncoherent platforms") DMA coherent
allocations just fail. Example:
[    1.114914] bgmac_bcma bcma0:2: Allocation of TX ring 0x200 failed
[    1.121215] bgmac_bcma bcma0:2: Unable to alloc memory for DMA
[    1.127626] bgmac_bcma: probe of bcma0:2 failed with error -12
[    1.133838] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded

The bgmac driver also triggers a WARNING:
[    0.959486] ------------[ cut here ]------------
[    0.964387] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 bgmac_enet_probe+0x1b4/0x5c4
[    0.973751] Modules linked in:
[    0.976913] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.9 #0
[    0.982750] Stack : 804a0000 804597c4 00000000 00000000 80458fd8 8381bc2c 838282d4 80481a47
[    0.991367]         8042e3ec 00000001 804d38f0 00000204 83980000 00000065 8381bbe0 6f55b24f
[    0.999975]         00000000 00000000 80520000 00002018 00000000 00000075 00000007 00000000
[    1.008583]         00000000 80480000 000ee811 00000000 00000000 00000000 80432c00 80248db8
[    1.017196]         00000009 00000204 83980000 803ad7b0 00000000 801feeec 00000000 804d0000
[    1.025804]         ...
[    1.028325] Call Trace:
[    1.030875] [<8000aef8>] show_stack+0x58/0x100
[    1.035513] [<8001f8b4>] __warn+0xe4/0x118
[    1.039708] [<8001f9a4>] warn_slowpath_null+0x48/0x64
[    1.044935] [<80248db8>] bgmac_enet_probe+0x1b4/0x5c4
[    1.050101] [<802498e0>] bgmac_probe+0x558/0x590
[    1.054906] [<80252fd0>] bcma_device_probe+0x38/0x70
[    1.060017] [<8020e1e8>] really_probe+0x170/0x2e8
[    1.064891] [<8020e714>] __driver_attach+0xa4/0xec
[    1.069784] [<8020c1e0>] bus_for_each_dev+0x58/0xb0
[    1.074833] [<8020d590>] bus_add_driver+0xf8/0x218
[    1.079731] [<8020ef24>] driver_register+0xcc/0x11c
[    1.084804] [<804b54cc>] bgmac_init+0x1c/0x44
[    1.089258] [<8000121c>] do_one_initcall+0x7c/0x1a0
[    1.094343] [<804a1d34>] kernel_init_freeable+0x150/0x218
[    1.099886] [<803a082c>] kernel_init+0x10/0x104
[    1.104583] [<80005878>] ret_from_kernel_thread+0x14/0x1c
[    1.110107] ---[ end trace f441c0d873d1fb5b ]---

This patch setups a "struct device" (and passes it to the bcma) which
allows fixing all the mentioned problems. It'll also require a tiny bcma
patch which will follow through the wireless tree & its maintainer.

Fixes: f8c55dc6e828 ("MIPS: use generic dma noncoherent ops for simple noncoherent platforms")
Signed-off-by: Rafał Miłecki 
Signed-off-by: Paul Burton 
Acked-by: Hauke Mehrtens 
Cc: Christoph Hellwig 
Cc: Linus Walleij 
Cc: linux-wireless@vger.kernel.org
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Greg Kroah-Hartman

IN_BADCLASS: fix macro to actually work

2019-01-22T20:09:49+00:00

[ Upstream commit f275ee0fa3a06eb87edc229749cf1eb18f0663fa ]

Commit 65cab850f0ee ("net: Allow class-e address assignment via ifconfig
ioctl") modified the IN_BADCLASS macro a bit, but unfortunatly one too
many '(' characters were added to the line, making any code that used
it, not build properly.

Also, the macro now compares an unsigned with a signed value, which
isn't ok, so fix that up by making both types match properly.

Reported-by: Christopher Ferris 
Fixes: 65cab850f0ee ("net: Allow class-e address assignment via ifconfig ioctl")
Cc: Dave Taht 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: phy: Add missing features to PHY drivers

2019-01-22T20:09:48+00:00

[ Upstream commit 9e857a40dc4eba15a739b4194d7db873d82c28a0 ]

The bcm87xx and micrel driver has PHYs which are missing the .features
value. Add them. The bcm87xx is a 10G FEC only PHY. Add the needed
features definition of this PHY.

Fixes: 719655a14971 ("net: phy: Replace phy driver features u32 with link_mode bitmap")
Reported-by: Scott Wood 
Reported-by: Camelia Groza 
Signed-off-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_conncount: speculative garbage collection on empty lists

2019-01-22T20:09:47+00:00

commit c80f10bc973af2ace6b1414724eeff61eaa71837 upstream.

Instead of removing a empty list node that might be reintroduced soon
thereafter, tentatively place the empty list node on the list passed to
tree_nodes_free(), then re-check if the list is empty again before erasing
it from the tree.

[ Florian: rebase on top of pending nf_conncount fixes ]

Fixes: 5c789e131cbb9 ("netfilter: nf_conncount: Add list lock and gc worker, and RCU for init tree search")
Reviewed-by: Shawn Bohrer 
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_conncount: merge lookup and add functions

2019-01-22T20:09:46+00:00

commit df4a902509766897f7371fdfa4c3bf8bc321b55d upstream.

'lookup' is always followed by 'add'.
Merge both and make the list-walk part of nf_conncount_add().

This also avoids one unneeded unlock/re-lock pair.

Extra care needs to be taken in count_tree, as we only hold rcu
read lock, i.e. we can only insert to an existing tree node after
acquiring its lock and making sure it has a nonzero count.

As a zero count should be rare, just fall back to insert_tree()
(which acquires tree lock).

This issue and its solution were pointed out by Shawn Bohrer
during patch review.

Reviewed-by: Shawn Bohrer 
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

sunrpc: use-after-free in svc_process_common()

2019-01-16T21:03:26+00:00

commit d4b09acf924b84bae77cad090a9d108e70b43643 upstream.

if node have NFSv41+ mounts inside several net namespaces
it can lead to use-after-free in svc_process_common()

svc_process_common()
        /* Setup reply header */
        rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr(rqstp); <<< HERE

svc_process_common() can use incorrect rqstp->rq_xprt,
its caller function bc_svc_process() takes it from serv->sv_bc_xprt.
The problem is that serv is global structure but sv_bc_xprt
is assigned per-netnamespace.

According to Trond, the whole "let's set up rqstp->rq_xprt
for the back channel" is nothing but a giant hack in order
to work around the fact that svc_process_common() uses it
to find the xpt_ops, and perform a couple of (meaningless
for the back channel) tests of xpt_flags.

All we really need in svc_process_common() is to be able to run
rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr()

Bruce J Fields points that this xpo_prep_reply_hdr() call
is an awfully roundabout way just to do "svc_putnl(resv, 0);"
in the tcp case.

This patch does not initialiuze rqstp->rq_xprt in bc_svc_process(),
now it calls svc_process_common() with rqstp->rq_xprt = NULL.

To adjust reply header svc_process_common() just check
rqstp->rq_prot and calls svc_tcp_prep_reply_hdr() for tcp case.

To handle rqstp->rq_xprt = NULL case in functions called from
svc_process_common() patch intruduces net namespace pointer
svc_rqst->rq_bc_net and adjust SVC_NET() definition.
Some other function was also adopted to properly handle described case.

Signed-off-by: Vasily Averin 
Cc: stable@vger.kernel.org
Fixes: 23c20ecd4475 ("NFS: callback up - users counting cleanup")
Signed-off-by: J. Bruce Fields 
v2: added lost extern svc_tcp_prep_reply_hdr()
Signed-off-by: Vasily Averin 
Signed-off-by: Greg Kroah-Hartman

x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE

2019-01-16T21:03:21+00:00

commit e4f358916d528d479c3c12bd2fd03f2d5a576380 upstream.

Commit

  4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")

replaced the RETPOLINE define with CONFIG_RETPOLINE checks. Remove the
remaining pieces.

 [ bp: Massage commit message. ]

Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
Signed-off-by: WANG Chao 
Signed-off-by: Borislav Petkov 
Reviewed-by: Zhenzhong Duan 
Reviewed-by: Masahiro Yamada 
Cc: "H. Peter Anvin" 
Cc: Andi Kleen 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Daniel Borkmann 
Cc: David Woodhouse 
Cc: Geert Uytterhoeven 
Cc: Jessica Yu 
Cc: Jiri Kosina 
Cc: Kees Cook 
Cc: Konrad Rzeszutek Wilk 
Cc: Luc Van Oostenryck 
Cc: Michal Marek 
Cc: Miguel Ojeda 
Cc: Peter Zijlstra 
Cc: Tim Chen 
Cc: Vasily Gorbik 
Cc: linux-kbuild@vger.kernel.org
Cc: srinivas.eeda@oracle.com
Cc: stable 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20181210163725.95977-1-chao.wang@ucloud.cn
Signed-off-by: Greg Kroah-Hartman

cpufreq: scpi/scmi: Fix freeing of dynamic OPPs

2019-01-16T21:03:20+00:00

commit 1690d8bb91e370ab772062b79bd434ce815c4729 upstream.

Since the commit 2a4eb7358aba "OPP: Don't remove dynamic OPPs from
_dev_pm_opp_remove_table()", dynamically created OPP aren't
automatically removed anymore by dev_pm_opp_cpumask_remove_table(). This
affects the scpi and scmi cpufreq drivers which no longer free OPPs on
failures or on invocations of the policy->exit() callback.

Create a generic OPP helper dev_pm_opp_remove_all_dynamic() which can be
called from these drivers instead of dev_pm_opp_cpumask_remove_table().

In dev_pm_opp_remove_all_dynamic(), we need to make sure that the
opp_list isn't getting accessed simultaneously from other parts of the
OPP core while the helper is freeing dynamic OPPs, i.e. we can't drop
the opp_table->lock while traversing through the OPP list. And to
accomplish that, this patch also creates _opp_kref_release_unlocked()
which can be called from this new helper with the opp_table lock already
held.

Cc: 4.20  # v4.20
Reported-by: Valentin Schneider 
Fixes: 2a4eb7358aba "OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table()"
Signed-off-by: Viresh Kumar 
Tested-by: Valentin Schneider 
Reviewed-by: Sudeep Holla 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman