Changes

sctp: remove sched init from sctp_stream_init
[ Upstream commit 2e990dfd13974d9eae493006f42ffb48707970ef ]
syzbot reported a NULL-ptr deref caused by that sched->init() in 
sctp_stream_init() set stream->rr_next = NULL.
  kasan: GPF could be caused by NULL-ptr deref or user memory access
 RIP: 0010:sctp_sched_rr_dequeue+0xd3/0x170
net/sctp/stream_sched_rr.c:141
 Call Trace:
   sctp_outq_dequeue_data net/sctp/outqueue.c:90 [inline]
   sctp_outq_flush_data net/sctp/outqueue.c:1079 [inline]
   sctp_outq_flush+0xba2/0x2790 net/sctp/outqueue.c:1205
All sched info is saved in sout->ext now, in sctp_stream_init() 
sctp_stream_alloc_out() will not change it, there's no need to call
sched->init() again, since sctp_outq_init() has already done it.
Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") 
Reported-by: syzbot+4c9934f20522c0efd657@syzkaller.appspotmail.com 
Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Neil Horman
<nhorman@tuxdriver.com> Acked-by: Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> Signed-off-by: David S. Miller
<davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

tcp: do not report TCP_CM_INQ of 0 for closed connections
[ Upstream commit 6466e715651f9f358e60c5ea4880e4731325827f ]
Returning 0 as inq to userspace indicates there is no more data to read,
and the application needs to wait for EPOLLIN. For a connection that has
received FIN from the remote peer, however, the application must
continue reading until getting EOF (return value of 0 from tcp_recvmsg)
or an error, if edge-triggered epoll (EPOLLET) is being used. Otherwise,
the application will never receive a new EPOLLIN, since there is no
epoll edge after the FIN.
Return 1 when there is no data left on the queue but the connection has
received FIN, so that the applications continue reading.
Fixes: b75eba76d3d72 (tcp: send in-queue bytes in cmsg upon read) 
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal
Cardwell <ncardwell@google.com> Signed-off-by: Eric Dumazet
<edumazet@google.com> Acked-by: Yuchung Cheng <ycheng@google.com> 
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: Don't access TCP_SKB_CB before initializing it
[ Upstream commit f2feaefdabb0a6253aa020f65e7388f07a9ed47c ]
Since commit eeea10b83a13 ("tcp: add 
tcp_v4_fill_cb()/tcp_v4_restore_cb()"), tcp_vX_fill_cb is only called 
after tcp_filter(). That means, TCP_SKB_CB(skb)->end_seq still points to 
the IP-part of the cb.
We thus should not mock with it, as this can trigger bugs (thanks 
syzkaller):
[   12.349396]
==================================================================
[   12.350188] BUG: KASAN: slab-out-of-bounds in
ip6_datagram_recv_specific_ctl+0x19b3/0x1a20
[   12.351035] Read of size 1 at addr ffff88006adbc208 by task
test_ip6_datagr/1799
Setting end_seq is actually no more necessary in tcp_filter as it gets 
initialized later on in tcp_vX_fill_cb.
Cc: Eric Dumazet <edumazet@google.com> Fixes: eeea10b83a13 ("tcp: add
tcp_v4_fill_cb()/tcp_v4_restore_cb()") Signed-off-by: Christoph Paasch
<cpaasch@apple.com> Signed-off-by: Eric Dumazet <edumazet@google.com> 
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: handle inet_csk_reqsk_queue_add() failures
[  Upstream commit 9d3e1368bb45893a75a5dfb7cd21fdebfa6b47af ]
Commit 7716682cc58e ("tcp/dccp: fix another race at listener dismantle")
let inet_csk_reqsk_queue_add() fail, and adjusted
{tcp,dccp}_check_req() accordingly. However, TFO and syncookies weren't
modified, thus leaking allocated resources on error.
Contrary to tcp_check_req(), in both syncookies and TFO cases, we need
to drop the request socket. Also, since the child socket is created with
inet_csk_clone_lock(), we have to unlock it and drop an extra reference
(->sk_refcount is initially set to 2 and inet_csk_reqsk_queue_add()
drops only one ref).
For TFO, we also need to revert the work done by tcp_try_fastopen()
(with reqsk_fastopen_remove()).
Fixes: 7716682cc58e ("tcp/dccp: fix another race at listener dismantle") 
Signed-off-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Eric
Dumazet <edumazet@google.com> Signed-off-by: David S. Miller
<davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

vxlan: Fix GRO cells race condition between receive and link delete
[ Upstream commit ad6c9986bcb627c7c22b8f9e9a934becc27df87c ]
If we receive a packet while deleting a VXLAN device, there's a chance 
vxlan_rcv() is called at the same time as vxlan_dellink(). This is fine, 
except that vxlan_dellink() should never ever touch stuff that's still
in use, such as the GRO cells list.
Otherwise, vxlan_rcv() crashes while queueing packets via 
gro_cells_receive().
Move the gro_cells_destroy() to vxlan_uninit(), which runs after the RCU 
grace period is elapsed and nothing needs the gro_cells anymore.
This is now done in the same way as commit 8e816df87997 ("geneve: Use
GRO cells infrastructure.") originally implemented for GENEVE.
Reported-by: Jianlin Shi <jishi@redhat.com> Fixes: 58ce31cca1ff ("vxlan:
GRO support at tunnel layer") Signed-off-by: Stefano Brivio
<sbrivio@redhat.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> 
Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S.
Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

vxlan: test dev->flags & IFF_UP before calling gro_cells_receive()
[ Upstream commit 59cbf56fcd98ba2a715b6e97c4e43f773f956393 ]
Same reasons than the ones explained in commit 4179cb5a4c92
("vxlan: test dev->flags & IFF_UP before calling netif_rx()")
netif_rx() or gro_cells_receive() must be called under a strict
contract.
At device dismantle phase, core networking clears IFF_UP and
flush_all_backlogs() is called after rcu grace period to make sure no
incoming packet might be in a cpu backlog and still referencing the
device.
A similar protocol is used for gro_cells infrastructure, as 
gro_cells_destroy() will be called only after a full rcu grace period is
observed after IFF_UP has been cleared.
Most drivers call netif_rx() from their interrupt handler, and since the
interrupts are disabled at device dismantle, netif_rx() does not have to
check dev->flags & IFF_UP
Virtual drivers do not have this guarantee, and must therefore make the
check themselves.
Otherwise we risk use-after-free and/or crashes.
Fixes: d342894c5d2f ("vxlan: virtual extensible lan") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller
<davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

net/mlx4_core: Fix reset flow when in command polling mode
[ Upstream commit e15ce4b8d11227007577e6dc1364d288b8874fbe ]
As part of unloading a device, the driver switches from FW command event
mode to FW command polling mode.
Part of switching over to polling mode is freeing the command context
array memory (unfortunately, currently, without NULLing the command
context array pointer).
The reset flow calls "complete" to complete all outstanding fw commands
(if we are in event mode). The check for event vs. polling mode here is
to test if the command context array pointer is NULL.
If the reset flow is activated after the switch to polling mode, it will 
attempt (incorrectly) to complete all the commands in the context array
-- because the pointer was not NULLed when the driver switched over to
polling mode.
As a result, we have a use-after-free situation, which results in a 
kernel crash.
For example: BUG: unable to handle kernel NULL pointer dereference at   
       (null) IP: [<ffffffff876c4a8e>] __wake_up_common+0x2e/0x90 PGD 0 
Oops: 0000 [#1] SMP Modules linked in: netconsole nfsv3 nfs_acl nfs
lockd grace ... CPU: 2 PID: 940 Comm: kworker/2:3 Kdump: loaded Not
tainted 3.10.0-862.el7.x86_64 #1 Hardware name: Microsoft Corporation
Virtual Machine/Virtual Machine, BIOS 090006  04/28/2016 Workqueue:
events hv_eject_device_work [pci_hyperv] task: ffff8d1734ca0fd0 ti:
ffff8d17354bc000 task.ti: ffff8d17354bc000 RIP:
0010:[<ffffffff876c4a8e>]  [<ffffffff876c4a8e>]
__wake_up_common+0x2e/0x90 RSP: 0018:ffff8d17354bfa38  EFLAGS: 00010082 
RAX: 0000000000000000 RBX: ffff8d17362d42c8 RCX: 0000000000000000 RDX:
0000000000000001 RSI: 0000000000000003 RDI: ffff8d17362d42c8 RBP:
ffff8d17354bfa70 R08: 0000000000000000 R09: 0000000000000000 R10:
0000000000000298 R11: ffff8d173610e000 R12: ffff8d17362d42d0 R13:
0000000000000246 R14: 0000000000000000 R15: 0000000000000003 FS: 
0000000000000000(0000) GS:ffff8d1802680000(0000) knlGS:0000000000000000 
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000
CR3: 00000000f16d8000 CR4: 00000000001406e0 Call Trace:
[<ffffffff876c7adc>] complete+0x3c/0x50
[<ffffffffc04242f0>] mlx4_cmd_wake_completions+0x70/0x90 [mlx4_core]
[<ffffffffc041e7b1>] mlx4_enter_error_state+0xe1/0x380 [mlx4_core]
[<ffffffffc041fa4b>] mlx4_comm_cmd+0x29b/0x360 [mlx4_core]
[<ffffffffc041ff51>] __mlx4_cmd+0x441/0x920 [mlx4_core]
[<ffffffff877f62b1>] ? __slab_free+0x81/0x2f0
[<ffffffff87951384>] ? __radix_tree_lookup+0x84/0xf0
[<ffffffffc043a8eb>] mlx4_free_mtt_range+0x5b/0xb0 [mlx4_core]
[<ffffffffc043a957>] mlx4_mtt_cleanup+0x17/0x20 [mlx4_core]
[<ffffffffc04272c7>] mlx4_free_eq+0xa7/0x1c0 [mlx4_core]
[<ffffffffc042803e>] mlx4_cleanup_eq_table+0xde/0x130 [mlx4_core]
[<ffffffffc0433e08>] mlx4_unload_one+0x118/0x300 [mlx4_core]
[<ffffffffc0434191>] mlx4_remove_one+0x91/0x1f0 [mlx4_core]
The fix is to set the command context array pointer to NULL after
freeing the array.
Fixes: f5aef5aa3506 ("net/mlx4_core: Activate reset flow upon fatal
command cases") Signed-off-by: Jack Morgenstein
<jackm@dev.mellanox.co.il> Signed-off-by: Tariq Toukan
<tariqt@mellanox.com> Signed-off-by: David S. Miller
<davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

net/mlx4_core: Fix locking in SRIOV mode when switching between events
and polling
[ Upstream commit c07d27927f2f2e96fcd27bb9fb330c9ea65612d0 ]
In procedures mlx4_cmd_use_events() and mlx4_cmd_use_polling(), we need
to guarantee that there are no FW commands in progress on the comm
channel
(for VFs) or wrapped FW commands (on the PF) when SRIOV is active.
We do this by also taking the slave_cmd_mutex when SRIOV is active.
This is especially important when switching from event to polling, since
we free the command-context array during the switch.  If there are FW
commands in progress (e.g., waiting for a completion event), the
completion event handler will access freed memory.
Since the decision to use comm_wait or comm_poll is taken before
grabbing the event_sem/poll_sem in mlx4_comm_cmd_wait/poll, we must take
the slave_cmd_mutex as well (to guarantee that the decision to use
events or polling and the call to the appropriate cmd function are
atomic).
Fixes: a7e1f04905e5 ("net/mlx4_core: Fix deadlock when switching between
polling and event fw commands") Signed-off-by: Jack Morgenstein
<jackm@dev.mellanox.co.il> Signed-off-by: Tariq Toukan
<tariqt@mellanox.com> Signed-off-by: David S. Miller
<davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

net/mlx4_core: Fix qp mtt size calculation
[ Upstream commit 8511a653e9250ef36b95803c375a7be0e2edb628 ]
Calculation of qp mtt size (in function mlx4_RST2INIT_wrapper) 
ultimately depends on function roundup_pow_of_two.
If the amount of memory required by the QP is less than one page, 
roundup_pow_of_two is called with argument zero.  In this case, the 
roundup_pow_of_two result is undefined.
Calling roundup_pow_of_two with a zero argument resulted in the 
following stack trace:
UBSAN: Undefined behaviour in ./include/linux/log2.h:61:13 shift
exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 4 PID:
26939 Comm: rping Tainted: G OE 4.19.0-rc1 Hardware name: Supermicro
X9DR3-F/X9DR3-F, BIOS 3.2a 07/09/2015 Call Trace: dump_stack+0x9a/0xeb 
ubsan_epilogue+0x9/0x7c
__ubsan_handle_shift_out_of_bounds+0x254/0x29d
? __ubsan_handle_load_invalid_value+0x180/0x180
? debug_show_all_locks+0x310/0x310
? sched_clock+0x5/0x10
? sched_clock+0x5/0x10
? sched_clock_cpu+0x18/0x260
? find_held_lock+0x35/0x1e0
? mlx4_RST2INIT_QP_wrapper+0xfb1/0x1440 [mlx4_core] 
mlx4_RST2INIT_QP_wrapper+0xfb1/0x1440 [mlx4_core]
Fix this by explicitly testing for zero, and returning one if the 
argument is zero (assuming that the next higher power of 2 in this case 
should be one).
Fixes: c82e9aa0a8bc ("mlx4_core: resource tracking for HCA resources
used by guests") Signed-off-by: Jack Morgenstein
<jackm@dev.mellanox.co.il> Signed-off-by: Tariq Toukan
<tariqt@mellanox.com> Signed-off-by: David S. Miller
<davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

net: dsa: mv88e6xxx: Set correct interface mode for CPU/DSA ports
[ Upstream commit 7cbbee050c959f41b512599bafd99685f419ce26 ]
By default, the switch driver is expected to configure CPU and DSA ports
to their maximum speed. For the 6341 and 6390 families, the ports
interface mode has to be configured as well. The 6390X range support 10G
ports using XAUI, while the 6341 and 6390 supports 2500BaseX, as their
maximum speed.
Fixes: 787799a9d555 ("net: dsa: mv88e6xxx: Default ports 9/10 6390X
CMODE to 1000BaseX") Signed-off-by: Andrew Lunn <andrew@lunn.ch> 
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

net: hns3: fix to stop multiple HNS reset due to the AER changes
[ Upstream commit 69b51bbb03f73e04c486f79d1556b2d9becf4dbc ]
The commit bfcb79fca19d
("PCI/ERR: Run error recovery callbacks for all affected devices") 
affected the non-fatal error recovery logic for the HNS and RDMA
devices. This is because each HNS PF under PCIe bus receive callbacks 
from the AER driver when an error is reported for one of the PF. This
causes unwanted PF resets because the HNS decides which PF to reset
based on the reset type set. The HNS error handling code sets the reset
type based on the hw error type detected.
This patch provides fix for the above issue for the recovery of the hw
errors in the HNS and RDMA devices.
This patch needs backporting to the kernel v5.0+
Fixes: 332fbf576579 ("net: hns3: add handling of hw ras errors using new
set of commands") Reported-by: Xiaofei Tan <tanxiaofei@huawei.com> 
Signed-off-by: Shiju Jose <shiju.jose@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller
<davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

vsock/virtio: fix kernel panic from virtio_transport_reset_no_sock
[ Upstream commit 4c404ce23358d5d8fbdeb7a6021a9b33d3c3c167 ]
Previous to commit 22b5c0b63f32 ("vsock/virtio: fix kernel panic after
device hot-unplug"), vsock_core_init() was called from 
virtio_vsock_probe(). Now, virtio_transport_reset_no_sock() can be
called before vsock_core_init() has the chance to run.
[Wed Feb 27 14:17:09 2019] BUG: unable to handle kernel NULL pointer
dereference at 0000000000000110
[Wed Feb 27 14:17:09 2019] #PF error: [normal kernel read fault]
[Wed Feb 27 14:17:09 2019] PGD 0 P4D 0
[Wed Feb 27 14:17:09 2019] Oops: 0000 [#1] SMP PTI
[Wed Feb 27 14:17:09 2019] CPU: 3 PID: 59 Comm: kworker/3:1 Not tainted
5.0.0-rc7-390-generic-hvi #390
[Wed Feb 27 14:17:09 2019] Hardware name: QEMU Standard PC (i440FX +
PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[Wed Feb 27 14:17:09 2019] Workqueue: virtio_vsock
virtio_transport_rx_work [vmw_vsock_virtio_transport]
[Wed Feb 27 14:17:09 2019] RIP:
0010:virtio_transport_reset_no_sock+0x8c/0xc0
[vmw_vsock_virtio_transport_common]
[Wed Feb 27 14:17:09 2019] Code: 35 8b 4f 14 48 8b 57 08 31 f6 44 8b 4f
10 44 8b 07 48 8d 7d c8 e8 84 f8 ff ff 48 85 c0 48 89 c3 74 2a e8 f7 31
03 00 48 89 df <48> 8b 80 10 01 00 00 e8 68 fb 69 ed 48 8b 75 f0 65 48
33 34 25 28
[Wed Feb 27 14:17:09 2019] RSP: 0018:ffffb42701ab7d40 EFLAGS: 00010282
[Wed Feb 27 14:17:09 2019] RAX: 0000000000000000 RBX: ffff9d79637ee080
RCX: 0000000000000003
[Wed Feb 27 14:17:09 2019] RDX: 0000000000000001 RSI: 0000000000000002
RDI: ffff9d79637ee080
[Wed Feb 27 14:17:09 2019] RBP: ffffb42701ab7d78 R08: ffff9d796fae70e0
R09: ffff9d796f403500
[Wed Feb 27 14:17:09 2019] R10: ffffb42701ab7d90 R11: 0000000000000000
R12: ffff9d7969d09240
[Wed Feb 27 14:17:09 2019] R13: ffff9d79624e6840 R14: ffff9d7969d09318
R15: ffff9d796d48ff80
[Wed Feb 27 14:17:09 2019] FS:  0000000000000000(0000)
GS:ffff9d796fac0000(0000) knlGS:0000000000000000
[Wed Feb 27 14:17:09 2019] CS:  0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[Wed Feb 27 14:17:09 2019] CR2: 0000000000000110 CR3: 0000000427f22000
CR4: 00000000000006e0
[Wed Feb 27 14:17:09 2019] DR0: 0000000000000000 DR1: 0000000000000000
DR2: 0000000000000000
[Wed Feb 27 14:17:09 2019] DR3: 0000000000000000 DR6: 00000000fffe0ff0
DR7: 0000000000000400
[Wed Feb 27 14:17:09 2019] Call Trace:
[Wed Feb 27 14:17:09 2019]  virtio_transport_recv_pkt+0x63/0x820
[vmw_vsock_virtio_transport_common]
[Wed Feb 27 14:17:09 2019]  ? kfree+0x17e/0x190
[Wed Feb 27 14:17:09 2019]  ? detach_buf_split+0x145/0x160
[Wed Feb 27 14:17:09 2019]  ? __switch_to_asm+0x40/0x70
[Wed Feb 27 14:17:09 2019]  virtio_transport_rx_work+0xa0/0x106
[vmw_vsock_virtio_transport]
[Wed Feb 27 14:17:09 2019] NET: Registered protocol family 40
[Wed Feb 27 14:17:09 2019]  process_one_work+0x167/0x410
[Wed Feb 27 14:17:09 2019]  worker_thread+0x4d/0x460
[Wed Feb 27 14:17:09 2019]  kthread+0x105/0x140
[Wed Feb 27 14:17:09 2019]  ? rescuer_thread+0x360/0x360
[Wed Feb 27 14:17:09 2019]  ? kthread_destroy_worker+0x50/0x50
[Wed Feb 27 14:17:09 2019]  ret_from_fork+0x35/0x40
[Wed Feb 27 14:17:09 2019] Modules linked in: vmw_vsock_virtio_transport
vmw_vsock_virtio_transport_common input_leds vsock serio_raw i2c_piix4
mac_hid qemu_fw_cfg autofs4 cirrus ttm drm_kms_helper syscopyarea
sysfillrect sysimgblt fb_sys_fops virtio_net psmouse drm net_failover
pata_acpi virtio_blk failover floppy
Fixes: 22b5c0b63f32 ("vsock/virtio: fix kernel panic after device
hot-unplug") Reported-by: Alexandru Herghelegiu
<aherghelegiu@bitdefender.com> Signed-off-by: Adalbert Lazăr
<alazar@bitdefender.com> Co-developed-by: Stefan Hajnoczi
<stefanha@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> 
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

net: sched: flower: insert new filter to idr after setting its mask
[ Upstream commit ecb3dea400d3beaf611ce76ac7a51d4230492cf2 ]
When adding new filter to flower classifier, fl_change() inserts it to 
handle_idr before initializing filter extensions and assigning it a
mask. Normally this ordering doesn't matter because all flower
classifier ops callbacks assume rtnl lock protection. However, when
filter has an action that doesn't have its kernel module loaded, rtnl
lock is released before call to request_module(). During this time the
filter can be accessed bu concurrent task before its initialization is
completed, which can lead to a crash.
Example case of NULL pointer dereference in concurrent dump:
Task 1                           Task 2
tc_new_tfilter()
fl_change()
 idr_alloc_u32(fnew)
 fl_set_parms()
  tcf_exts_validate()
   tcf_action_init()
    tcf_action_init_1()
     rtnl_unlock()
     request_module()
     ...                        rtnl_lock()
     				 tc_dump_tfilter()
     				  tcf_chain_dump()
			   fl_walk()
			    idr_get_next_ul()
			    tcf_node_dump()
			     tcf_fill_node()
			      fl_dump()
			       mask = &f->mask->key; <- NULL ptr
     rtnl_lock()
Extension initialization and mask assignment don't depend on
fnew->handle that is allocated by idr_alloc_u32(). Move idr allocation
code after action creation and mask assignment in fl_change() to prevent
concurrent access to not fully initialized filter when rtnl lock is
released to load action module.
Fixes: 01683a146999 ("net: sched: refactor flower walk to iterate over
idr") Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Reviewed-by: Roi
Dayan <roid@mellanox.com> Signed-off-by: David S. Miller
<davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

f2fs: wait on atomic writes to count F2FS_CP_WB_DATA
commit 31867b23d7d1ee3535136c6a410a6cf56f666bfc upstream.
Otherwise, we can get wrong counts incurring checkpoint hang.
IO_W (CP:  -24, Data:   24, Flush: (   0    0    1), Discard: (   0   
0))
Thread A                        Thread B
- f2fs_write_data_pages
-  __write_data_page
 - f2fs_submit_page_write
  - inc_page_count(F2FS_WB_DATA)
    type is F2FS_WB_DATA due to file is non-atomic one
- f2fs_ioc_start_atomic_write
- set_inode_flag(FI_ATOMIC_FILE)
                               - f2fs_write_end_io
                                - dec_page_count(F2FS_WB_CP_DATA)
                                  type is F2FS_WB_DATA due to file
becomes
                                  atomic one
Cc: <stable@vger.kernel.org> Reviewed-by: Chao Yu <yuchao0@huawei.com> 
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

perf/x86: Fixup typo in stub functions
commit f764c58b7faa26f5714e6907f892abc2bc0de4f8 upstream.
Guenter reported a build warning for CONFIG_CPU_SUP_INTEL=n:
  > With allmodconfig-CONFIG_CPU_SUP_INTEL, this patch results in:
 >
 > In file included from arch/x86/events/amd/core.c:8:0:
 > arch/x86/events/amd/../perf_event.h:1036:45: warning: ‘struct
cpu_hw_event’ declared inside parameter list will not be visible outside
of this definition or declaration
 >  static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int
cpu)
While harmless (an unsed pointer is an unused pointer, no matter the
type) it needs fixing.
Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Peter
Zijlstra (Intel) <peterz@infradead.org> Cc: Greg Kroah-Hartman
<gregkh@linuxfoundation.org> Cc: Linus Torvalds
<torvalds@linux-foundation.org> Cc: Peter Zijlstra
<peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc:
stable@vger.kernel.org Fixes: d01b1f96a82e ("perf/x86/intel: Make cpuc
allocations consistent") Link:
http://lkml.kernel.org/r/20190315081410.GR5996@hirez.programming.kicks-ass.net 
Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: bebob: use more identical mod_alias for Saffire Pro 10 I/O against
Liquid Saffire 56
commit 7dc661bd8d3261053b69e4e2d0050cd1ee540fc1 upstream.
ALSA bebob driver has an entry for Focusrite Saffire Pro 10 I/O. The 
entry matches vendor_id in root directory and model_id in unit directory
of configuration ROM for IEEE 1394 bus.
On the other hand, configuration ROM of Focusrite Liquid Saffire 56 has
the same vendor_id and model_id. This device is an application of TCAT
Dice (TCD2220 a.k.a Dice Jr.) however ALSA bebob driver can be bound to
it randomly instead of ALSA dice driver. At present, drivers in ALSA
firewire stack can not handle this situation appropriately.
This commit uses more identical mod_alias for Focusrite Saffire Pro 10 
I/O in ALSA bebob driver.
$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
              ROM header and bus information block
             
----------------------------------------------------------------- 400 
042a829d  bus_info_length 4, crc_length 42, crc 33437 404  31333934 
bus_name "1394" 408  f0649222  irmc 1, cmc 1, isc 1, bmc 1, pmc 0,
cyc_clk_acc 100,
              max_rec 9 (1024), max_rom 2, gen 2, spd 2 (S400) 40c 
00130e01  company_id 00130e     | 410  000606e0  device_id 01000606e0  |
EUI-64 00130e01000606e0
               root directory
             
----------------------------------------------------------------- 414 
0009d31c  directory_length 9, crc 54044 418  04000014  hardware version 
41c  0c0083c0  node capabilities per IEEE 1394 420  0300130e  vendor 424
 81000012  --> descriptor leaf at 46c 428  17000006  model 42c  81000016
 --> descriptor leaf at 484 430  130120c2  version 434  d1000002  -->
unit directory at 43c 438  d4000006  --> dependent info directory at 450
               unit directory at 43c
             
----------------------------------------------------------------- 43c 
0004707c  directory_length 4, crc 28796 440  1200a02d  specifier id:
1394 TA 444  13010001  version: AV/C 448  17000006  model 44c  81000013 
--> descriptor leaf at 498
               dependent info directory at 450
             
----------------------------------------------------------------- 450 
000637c7  directory_length 6, crc 14279 454  120007f5  specifier id 458 
13000001  version 45c  3affffc7  (immediate value) 460  3b100000 
(immediate value) 464  3cffffc7  (immediate value) 468  3d600000 
(immediate value)
               descriptor leaf at 46c
             
----------------------------------------------------------------- 46c 
00056f3b  leaf_length 5, crc 28475 470  00000000  textual descriptor 474
 00000000  minimal ASCII 478  466f6375  "Focu" 47c  73726974  "srit" 480
 65000000  "e"
               descriptor leaf at 484
             
----------------------------------------------------------------- 484 
0004a165  leaf_length 4, crc 41317 488  00000000  textual descriptor 48c
 00000000  minimal ASCII 490  50726f31  "Pro1" 494  30494f00  "0IO"
               descriptor leaf at 498
             
----------------------------------------------------------------- 498 
0004a165  leaf_length 4, crc 41317 49c  00000000  textual descriptor 4a0
 00000000  minimal ASCII 4a4  50726f31  "Pro1" 4a8  30494f00  "0IO"
$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
              ROM header and bus information block
             
----------------------------------------------------------------- 400 
040442e4  bus_info_length 4, crc_length 4, crc 17124 404  31333934 
bus_name "1394" 408  e0ff8112  irmc 1, cmc 1, isc 1, bmc 0, pmc 0,
cyc_clk_acc 255,
              max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400) 40c 
00130e04  company_id 00130e     | 410  018001e9  device_id 04018001e9  |
EUI-64 00130e04018001e9
               root directory
             
----------------------------------------------------------------- 414 
00065612  directory_length 6, crc 22034 418  0300130e  vendor 41c 
8100000a  --> descriptor leaf at 444 420  17000006  model 424  8100000e 
--> descriptor leaf at 45c 428  0c0087c0  node capabilities per IEEE
1394 42c  d1000001  --> unit directory at 430
               unit directory at 430
             
----------------------------------------------------------------- 430 
000418a0  directory_length 4, crc 6304 434  1200130e  specifier id 438 
13000001  version 43c  17000006  model 440  8100000f  --> descriptor
leaf at 47c
               descriptor leaf at 444
             
----------------------------------------------------------------- 444 
00056f3b  leaf_length 5, crc 28475 448  00000000  textual descriptor 44c
 00000000  minimal ASCII 450  466f6375  "Focu" 454  73726974  "srit" 458
 65000000  "e"
               descriptor leaf at 45c
             
----------------------------------------------------------------- 45c 
000762c6  leaf_length 7, crc 25286 460  00000000  textual descriptor 464
 00000000  minimal ASCII 468  4c495155  "LIQU" 46c  49445f53  "ID_S" 470
 41464649  "AFFI" 474  52455f35  "RE_5" 478  36000000  "6"
               descriptor leaf at 47c
             
----------------------------------------------------------------- 47c 
000762c6  leaf_length 7, crc 25286 480  00000000  textual descriptor 484
 00000000  minimal ASCII 488  4c495155  "LIQU" 48c  49445f53  "ID_S" 490
 41464649  "AFFI" 494  52455f35  "RE_5" 498  36000000  "6"
Cc: <stable@vger.kernel.org> # v3.16+ Fixes: 25784ec2d034 ("ALSA: bebob:
Add support for Focusrite Saffire/SaffirePro series") Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai
<tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

ALSA: firewire-motu: fix construction of PCM frame for capture direction
commit f97a0944a72b26a2bece72516294e112a890f98a upstream.
In data blocks of common isochronous packet for MOTU devices, PCM frames
are multiplexed in a shape of '24 bit * 4 Audio Pack', described in IEC
61883-6. The frames are not aligned to quadlet.
For capture PCM substream, ALSA firewire-motu driver constructs PCM 
frames by reading data blocks byte-by-byte. However this operation 
includes bug for lower byte of the PCM sample. This brings invalid 
content of the PCM samples.
This commit fixes the bug.
Reported-by: Peter Sjöberg <autopeter@gmail.com> Cc:
<stable@vger.kernel.org> # v4.12+ Fixes: 4641c9394010 ("ALSA:
firewire-motu: add MOTU specific protocol layer") Signed-off-by: Takashi
Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai
<tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

ALSA: hda: Extend i915 component bind timeout
commit cfc35f9c128cea8fce6a5513b1de50d36f3b209f upstream.
I set 10 seconds for the timeout of the i915 audio component binding 
with a hope that recent machines are fast enough to handle all probe 
tasks in that period, but I was too optimistic.  The binding may take 
longer than that, and this caused a problem on the machine with both 
audio and graphics driver modules loaded in parallel, as Paul Menzel 
experienced.  This problem haven't hit so often just because the KMS 
driver is loaded in initrd on most machines.
As a simple workaround, extend the timeout to 60 seconds.
Fixes: f9b54e1961c7 ("ALSA: hda/i915: Allow delayed i915 audio component
binding") Reported-by: Paul Menzel <pmenzel+alsa-devel@molgen.mpg.de> 
Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - add more quirks for HP Z2 G4 and HP Z240
commit 167897f4b32c2bc18b3b6183029a33fb420a114e upstream.
Apply the HP_MIC_NO_PRESENCE fixups for the more HP Z2 G4 and HP Z240
models.
Reported-by: Jeff Burrell <jeff.burrell@hp.com> Signed-off-by: Jaroslav
Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

ALSA: hda/realtek: Enable audio jacks of ASUS UX362FA with ALC294
commit 8bb37a2a4d7c02affef554f5dc05f6d2e39c31f9 upstream.
The ASUS UX362FA with ALC294 cannot detect the headset MIC and outputs 
through the internal speaker and the headphone.  This issue can be fixed 
by the quirk in the commit 4e0511067 ALSA: hda/realtek: Enable audio 
jacks of ASUS UX533FD with ALC294.
Besides, ASUS UX362FA and UX533FD have the same audio initial pin config 
values.  So, this patch replaces SND_PCI_QUIRK of UX533FD with a new 
SND_HDA_PIN_QUIRK which benefits both UX362FA and UX533FD.
Fixes: 4e051106730d ("ALSA: hda/realtek: Enable audio jacks of ASUS
UX533FD with ALC294") Signed-off-by: Jian-Hong Pan
<jian-hong@endlessm.com> Signed-off-by: Ming Shuo Chiu
<chiu@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi
Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

ALSA: hda/realtek - Reduce click noise on Dell Precision 5820 headphone
commit c0ca5eced22215c1e03e3ad479f8fab0bbb30772 upstream.
Dell Precision 5820 with ALC3234 codec (which is equivalent with ALC255)
shows click noises at (runtime) PM resume on the headphone. The biggest
source of the noise comes from the cleared headphone pin control at
resume, which is done via the standard shutup procedure.
Although we have an override of the standard shutup callback to replace
with NOP, this would skip other needed stuff (e.g. the pull down of
headset power).  So, instead, this "fixes" the behavior of 
alc_fixup_no_shutup() by introducing spec->no_shutup_pins flag. When
this flag is set, Realtek codec won't call the standard 
snd_hda_shutup_pins() & co.  Now alc_fixup_no_shutup() just sets this 
flag instead of overriding spec->shutup callback itself.  This allows us
to apply the similar fix for other entries easily if needed in future.
Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Enable headset MIC of Acer TravelMate X514-51T with
ALC255
commit cbc05fd6708c1744ee6a61cb4c461ff956d30524 upstream.
The Acer TravelMate X514-51T with ALC255 cannot detect the headset MIC 
until ALC255_FIXUP_ACER_HEADSET_MIC quirk applied.  Although, the 
internal DMIC uses another module - snd_soc_skl as the driver.  We still 
need the NID 0x1a in the quirk to enable the headset MIC.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> 
Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

perf/x86/intel: Fix memory corruption
commit ede271b059463731cbd6dffe55ffd70d7dbe8392 upstream.
Through:
  validate_event()
   x86_pmu.get_event_constraints(.idx=-1)
     tfa_get_event_constraints()
       dyn_constraint()
cpuc->constraint_list[-1] is used, which is an obvious out-of-bound
access.
In this case, simply skip the TFA constraint code, there is no event 
constraint with just PMC3, therefore the code will never result in the 
empty set.
Fixes: 400816f60c54 ("perf/x86/intel: Implement support for TSX Force
Abort") Reported-by: Tony Jones <tonyj@suse.com> Reported-by: "DSouza,
Nelson" <nelson.dsouza@intel.com> Signed-off-by: Peter Zijlstra (Intel)
<peterz@infradead.org> Signed-off-by: Thomas Gleixner
<tglx@linutronix.de> Tested-by: Tony Jones <tonyj@suse.com> Tested-by:
"DSouza, Nelson" <nelson.dsouza@intel.com> Cc: eranian@google.com Cc:
jolsa@redhat.com Cc: stable@kernel.org Link:
https://lkml.kernel.org/r/20190314130705.441549378@infradead.org 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf/x86/intel: Make dev_attr_allow_tsx_force_abort static
commit c634dc6bdedeb0b2c750fc611612618a85639ab2 upstream.
Fixes: 400816f60c54 ("perf/x86/intel: Implement support for TSX Force
Abort") Signed-off-by: kbuild test robot <lkp@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: "Peter Zijlstra (Intel)"
<peterz@infradead.org> Cc: kbuild-all@01.org Cc: Borislav Petkov
<bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Kan Liang
<kan.liang@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Andi
Kleen <ak@linux.intel.com> Cc: stable@vger.kernel.org Link:
https://lkml.kernel.org/r/20190313184243.GA10820@lkp-sb-ep06 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It's wrong to add len to sector_nr in raid10 reshape twice
commit b761dcf1217760a42f7897c31dcb649f59b2333e upstream.
In reshape_request it already adds len to sector_nr already. It's wrong
to add len to sector_nr again after adding pages to bio. If there is bad
block it can't copy one chunk at a time, it needs to goto read_more. Now
the sector_nr is wrong. It can cause data corruption.
Cc: stable@vger.kernel.org # v3.16+ Signed-off-by: Xiao Ni
<xni@redhat.com> Signed-off-by: Song Liu <songliubraving@fb.com> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm: Block fb changes for async plane updates
commit 25dc194b34dd5919dd07b8873ee338182e15df9d upstream.
The prepare_fb call always happens on new_plane_state.
The drm_atomic_helper_cleanup_planes checks to see if plane state
pointer has changed when deciding to call cleanup_fb on either the
new_plane_state or the old_plane_state.
For a non-async atomic commit the state pointer is swapped, so this 
helper calls prepare_fb on the new_plane_state and cleanup_fb on the 
old_plane_state. This makes sense, since we want to prepare the 
framebuffer we are going to use and cleanup the the framebuffer we are 
no longer using.
For the async atomic update helpers this differs. The async atomic 
update helpers perform in-place updates on the existing state. They call 
drm_atomic_helper_cleanup_planes but the state pointer is not swapped. 
This means that prepare_fb is called on the new_plane_state and 
cleanup_fb is called on the new_plane_state (not the old).
In the case where old_plane_state->fb == new_plane_state->fb then there
should be no behavioral difference between an async update and a
non-async commit. But there are issues that arise when 
old_plane_state->fb != new_plane_state->fb.
The first is that the new_plane_state->fb is immediately cleaned up 
after it has been prepared, so we're using a fb that we shouldn't be.
The second occurs during a sequence of async atomic updates and 
non-async regular atomic commits. Suppose there are two framebuffers 
being interleaved in a double-buffering scenario, fb1 and fb2:
- Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
We call cleanup_fb on fb2 twice in this example scenario, and any 
further use will result in use-after-free.
The simple fix to this problem is to block framebuffer changes in the
drm_atomic_helper_async_check function for now.
v2: Move check by itself, add a FIXME (Daniel)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Harry Wentland
<harry.wentland@amd.com> Cc: Andrey Grodzovsky
<andrey.grodzovsky@amd.com> Cc: <stable@vger.kernel.org> # v4.14+ Fixes:
fef9df8b5945 ("drm/atomic: initial support for asynchronous plane
update") Signed-off-by: Nicholas Kazlauskas
<nicholas.kazlauskas@amd.com> Acked-by: Andrey Grodzovsky
<andrey.grodzovsky@amd.com> Acked-by: Harry Wentland
<harry.wentland@amd.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> 
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Link:
https://patchwork.freedesktop.org/patch/275364/ Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 5.0.3

9p: use inode->i_lock to protect i_size_write() under 32-bit
commit 5e3cc1ee1405a7eb3487ed24f786dec01b4cbe1f upstream.
Use inode->i_lock to protect i_size_write(), else i_size_read() in 
generic_fillattr() may loop infinitely in read_seqcount_begin() when 
multiple processes invoke v9fs_vfs_getattr() or v9fs_vfs_getattr_dotl() 
simultaneously under 32-bit SMP environment, and a soft lockup will be 
triggered as show below:
  watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [stat:2217]
 Modules linked in:
 CPU: 5 PID: 2217 Comm: stat Not tainted 5.0.0-rc1-00005-g7f702faf5a9e
#4
 Hardware name: Generic DT based system
 PC is at generic_fillattr+0x104/0x108
 LR is at 0xec497f00
 pc : [<802b8898>]    lr : [<ec497f00>]    psr: 200c0013
 sp : ec497e20  ip : ed608030  fp : ec497e3c
 r10: 00000000  r9 : ec497f00  r8 : ed608030
 r7 : ec497ebc  r6 : ec497f00  r5 : ee5c1550  r4 : ee005780
 r3 : 0000052d  r2 : 00000000  r1 : ec497f00  r0 : ed608030
 Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
 Control: 10c5387d  Table: ac48006a  DAC: 00000051
 CPU: 5 PID: 2217 Comm: stat Not tainted 5.0.0-rc1-00005-g7f702faf5a9e
#4
 Hardware name: Generic DT based system
 Backtrace:
 [<8010d974>] (dump_backtrace) from [<8010dc88>] (show_stack+0x20/0x24)
 [<8010dc68>] (show_stack) from [<80a1d194>] (dump_stack+0xb0/0xdc)
 [<80a1d0e4>] (dump_stack) from [<80109f34>] (show_regs+0x1c/0x20)
 [<80109f18>] (show_regs) from [<801d0a80>]
(watchdog_timer_fn+0x280/0x2f8)
 [<801d0800>] (watchdog_timer_fn) from [<80198658>]
(__hrtimer_run_queues+0x18c/0x380)
 [<801984cc>] (__hrtimer_run_queues) from [<80198e60>]
(hrtimer_run_queues+0xb8/0xf0)
 [<80198da8>] (hrtimer_run_queues) from [<801973e8>]
(run_local_timers+0x28/0x64)
 [<801973c0>] (run_local_timers) from [<80197460>]
(update_process_times+0x3c/0x6c)
 [<80197424>] (update_process_times) from [<801ab2b8>]
(tick_nohz_handler+0xe0/0x1bc)
 [<801ab1d8>] (tick_nohz_handler) from [<80843050>]
(arch_timer_handler_virt+0x38/0x48)
 [<80843018>] (arch_timer_handler_virt) from [<80180a64>]
(handle_percpu_devid_irq+0x8c/0x240)
 [<801809d8>] (handle_percpu_devid_irq) from [<8017ac20>]
(generic_handle_irq+0x34/0x44)
 [<8017abec>] (generic_handle_irq) from [<8017b344>]
(__handle_domain_irq+0x6c/0xc4)
 [<8017b2d8>] (__handle_domain_irq) from [<801022e0>]
(gic_handle_irq+0x4c/0x88)
 [<80102294>] (gic_handle_irq) from [<80101a30>] (__irq_svc+0x70/0x98)
 [<802b8794>] (generic_fillattr) from [<8056b284>]
(v9fs_vfs_getattr_dotl+0x74/0xa4)
 [<8056b210>] (v9fs_vfs_getattr_dotl) from [<802b8904>]
(vfs_getattr_nosec+0x68/0x7c)
 [<802b889c>] (vfs_getattr_nosec) from [<802b895c>]
(vfs_getattr+0x44/0x48)
 [<802b8918>] (vfs_getattr) from [<802b8a74>] (vfs_statx+0x9c/0xec)
 [<802b89d8>] (vfs_statx) from [<802b9428>] (sys_lstat64+0x48/0x78)
 [<802b93e0>] (sys_lstat64) from [<80101000>]
(ret_fast_syscall+0x0/0x28)
[dominique.martinet@cea.fr: updated comment to not refer to a function 
in another subsystem] Link:
http://lkml.kernel.org/r/20190124063514.8571-2-houtao1@huawei.com Cc:
stable@vger.kernel.org Fixes: 7549ae3e81cc ("9p: Use the i_size_[read,
write]() macros instead of using inode->i_size directly.") Reported-by:
Xing Gaopeng <xingaopeng@huawei.com> Signed-off-by: Hou Tao
<houtao1@huawei.com> Signed-off-by: Dominique Martinet
<dominique.martinet@cea.fr> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

9p/net: fix memory leak in p9_client_create
commit bb06c388fa20ae24cfe80c52488de718a7e3a53f upstream.
If msize is less than 4096, we should close and put trans, destroy 
tagpool, not just free client. This patch fixes that.
Link:
http://lkml.kernel.org/m/1552464097-142659-1-git-send-email-zhengbin13@huawei.com 
Cc: stable@vger.kernel.org Fixes: 574d356b7a02 ("9p/net: put a lower
bound on msize") Reported-by: Hulk Robot <hulkci@huawei.com> 
Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Dominique
Martinet <dominique.martinet@cea.fr> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

ASoC: fsl_esai: fix register setting issue in RIGHT_J mode
commit cc29ea007347f39f4c5a4d27b0b555955a0277f9 upstream.
The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to 
wrong register, correct it.
Fixes 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Cc:
<stable@vger.kernel.org> Signed-off-by: Shengjiu Wang
<shengjiu.wang@nxp.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> 
Ackedy-by: Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by: Mark
Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

ASoC: codecs: pcm186x: fix wrong usage of DECLARE_TLV_DB_SCALE()
commit fcf4daabf08079e6d09958a2992e7446ef8d0438 upstream.
According to DS, the gain is between -12 dB and 40 dB, with a 0.5 dB
step. Tested on pcm1863.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> 
Acked-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Mark Brown
<broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: codecs: pcm186x: Fix energysense SLEEP bit
commit 05bd7fcdd06b19a10f069af1bea3ad9abac038d7 upstream.
The ADCs are sleeping when the SLEEP bit is set and running when it's 
cleared, so the bit should be inverted. Tested on pcm1863.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> 
Acked-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Mark Brown
<broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

iio: adc: exynos-adc: Fix NULL pointer exception on unbind
commit 2ea8bab4dd2a9014e723b28091831fa850b82d83 upstream.
Fix NULL pointer exception on device unbind when device tree does not 
contain "has-touchscreen" property.  In such case the input device is 
not registered so it should not be unregistered.
    $ echo "12d10000.adc" > /sys/bus/platform/drivers/exynos-adc/unbind
    Unable to handle kernel NULL pointer dereference at virtual address
00000474
   ...
   (input_unregister_device) from [<c0772060>]
(exynos_adc_remove+0x20/0x80)
   (exynos_adc_remove) from [<c0587d5c>] (platform_drv_remove+0x20/0x40)
   (platform_drv_remove) from [<c05860f0>]
(device_release_driver_internal+0xdc/0x1ac)
   (device_release_driver_internal) from [<c0583ecc>]
(unbind_store+0x60/0xd4)
   (unbind_store) from [<c031b89c>] (kernfs_fop_write+0x100/0x1e0)
   (kernfs_fop_write) from [<c029709c>] (__vfs_write+0x2c/0x17c)
   (__vfs_write) from [<c0297374>] (vfs_write+0xa4/0x184)
   (vfs_write) from [<c0297594>] (ksys_write+0x4c/0xac)
   (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
Fixes: 2bb8ad9b44c5 ("iio: exynos-adc: add experimental touchscreen
support") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof
Kozlowski <krzk@kernel.org> Signed-off-by: Jonathan Cameron
<Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

iio: adc: exynos-adc: Use proper number of channels for Exynos4x12
commit 103cda6a3b8d2c10d5f8cd7abad118e9db8f4776 upstream.
Exynos4212 and Exynos4412 have only four ADC channels so using
"samsung,exynos-adc-v1" compatible (for eight channels ADCv1) on them is 
wrong.  Add a new compatible for Exynos4x12.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Cc:
<Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron
<Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

mei: hbm: clean the feature flags on link reset
commit 37fd0b623023484ef6df79ed46f21f06ecc611ff upstream.
The list of supported functions can be altered upon link reset, clean
the flags to allow correct selections of supported features.
Cc: <stable@vger.kernel.org> v4.19+ Signed-off-by: Alexander Usyskin
<alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler
<tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

mei: bus: move hw module get/put to probe/release
commit b5958faa34e2f99f3475ad89c52d98dfea079d33 upstream.
Fix unbalanced module reference counting during internal reset, which 
prevents the drivers unloading. Tracking mei_me/txe modules on mei
client bus via mei_cldev_enable/disable is error prone due to possible
internal reset flow, where clients are disconnected underneath. Moving
reference counting to probe and release of mei bus client driver solves
this issue in simplest way, as each client provides only a single
connection to a client bus driver.
Cc: <stable@vger.kernel.org> Signed-off-by: Alexander Usyskin
<alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler
<tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

stm class: Prevent division by zero
commit bf7cbaae0831252b416f375ca9b1027ecd4642dd upstream.
Using STP_POLICY_ID_SET ioctl command with dummy_stm device, or any STM 
device that supplies zero mmio channel size, will trigger a division by 
zero bug in the kernel.
Prevent this by disallowing channel widths other than 1 for such
devices.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> 
Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for System
Trace Module devices") CC: stable@vger.kernel.org # v4.4+ Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

stm class: Fix an endless loop in channel allocation
commit a1d75dad3a2c689e70a1c4e0214cca9de741d0aa upstream.
There is a bug in the channel allocation logic that leads to an endless 
loop when looking for a contiguous range of channels in a range with a 
mixture of free and occupied channels. For example, opening three 
consequtive channels, closing the first two and requesting 4 channels in 
a row will trigger this soft lockup. The bug is that the search loop 
forgets to skip over the range once it detects that one channel in that 
range is occupied.
Restore the original intent to the logic by fixing the omission.
Signed-off-by: Zhi Jin <zhi.jin@intel.com> Signed-off-by: Alexander
Shishkin <alexander.shishkin@linux.intel.com> Fixes: 7bd1d4093c2f ("stm
class: Introduce an abstraction for System Trace Module devices") CC:
stable@vger.kernel.org # v4.4+ Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: caam - fix hash context DMA unmap size
commit 65055e2108847af5e577cc7ce6bde45ea136d29a upstream.
When driver started using state->caam_ctxt for storing both running hash 
and final hash, it was not updated to handle different DMA unmap 
lengths.
Cc: <stable@vger.kernel.org> # v4.19+ Fixes: c19650d6ea99 ("crypto: caam
- fix DMA mapping of stack memory") Signed-off-by: Franck LENORMAND
<franck.lenormand@nxp.com> Signed-off-by: Horia Geantă
<horia.geanta@nxp.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: ccree - fix missing break in switch statement
commit b5be853181a8d4a6e20f2073ccd273d6280cad88 upstream.
Add missing break statement in order to prevent the code from falling 
through to case S_DIN_to_DES.
This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.
Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support") Cc:
stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva
<gustavo@embeddedor.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: caam - fixed handling of sg list
commit 42e95d1f10dcf8b18b1d7f52f7068985b3dc5b79 upstream.
when the source sg contains more than 1 fragment and destination sg
contains 1 fragment, the caam driver mishandle the buffers to be sent to
caam.
Fixes: f2147b88b2b1 ("crypto: caam - Convert GCM to new AEAD interface") 
Cc: <stable@vger.kernel.org> # 4.2+ Signed-off-by: Pankaj Gupta
<pankaj.gupta@nxp.com> Signed-off-by: Arun Pathak <arun.pathak@nxp.com> 
Reviewed-by: Horia Geanta <horia.geanta@nxp.com> Signed-off-by: Herbert
Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: caam - fix DMA mapping of stack memory
commit c19650d6ea99bcd903d3e55dd61860026c701339 upstream.
Roland reports the following issue and provides a root cause analysis:
"On a v4.19 i.MX6 system with IMA and CONFIG_DMA_API_DEBUG enabled, a 
warning is generated when accessing files on a filesystem for which IMA 
measurement is enabled:
    ------------[ cut here ]------------
   WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:1181
check_for_stack.part.9+0xd0/0x120
   caam_jr 2101000.jr0: DMA-API: device driver maps memory from stack
[addr=b668049e]
   Modules linked in:
   CPU: 0 PID: 1 Comm: switch_root Not tainted 4.19.0-20181214-1 #2
   Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
   Backtrace:
   [<c010efb8>] (dump_backtrace) from [<c010f2d0>]
(show_stack+0x20/0x24)
   [<c010f2b0>] (show_stack) from [<c08b04f4>] (dump_stack+0xa0/0xcc)
   [<c08b0454>] (dump_stack) from [<c012b610>] (__warn+0xf0/0x108)
   [<c012b520>] (__warn) from [<c012b680>] (warn_slowpath_fmt+0x58/0x74)
   [<c012b62c>] (warn_slowpath_fmt) from [<c0199acc>]
(check_for_stack.part.9+0xd0/0x120)
   [<c01999fc>] (check_for_stack.part.9) from [<c019a040>]
(debug_dma_map_page+0x144/0x174)
   [<c0199efc>] (debug_dma_map_page) from [<c065f7f4>]
(ahash_final_ctx+0x5b4/0xcf0)
   [<c065f240>] (ahash_final_ctx) from [<c065b3c4>]
(ahash_final+0x1c/0x20)
   [<c065b3a8>] (ahash_final) from [<c03fe278>]
(crypto_ahash_op+0x38/0x80)
   [<c03fe240>] (crypto_ahash_op) from [<c03fe2e0>]
(crypto_ahash_final+0x20/0x24)
   [<c03fe2c0>] (crypto_ahash_final) from [<c03f19a8>]
(ima_calc_file_hash+0x29c/0xa40)
   [<c03f170c>] (ima_calc_file_hash) from [<c03f2b24>]
(ima_collect_measurement+0x1dc/0x240)
   [<c03f2948>] (ima_collect_measurement) from [<c03f0a60>]
(process_measurement+0x4c4/0x6b8)
   [<c03f059c>] (process_measurement) from [<c03f0cdc>]
(ima_file_check+0x88/0xa4)
   [<c03f0c54>] (ima_file_check) from [<c02d8adc>]
(path_openat+0x5d8/0x1364)
   [<c02d8504>] (path_openat) from [<c02dad24>] (do_filp_open+0x84/0xf0)
   [<c02daca0>] (do_filp_open) from [<c02cf50c>]
(do_open_execat+0x84/0x1b0)
   [<c02cf488>] (do_open_execat) from [<c02d1058>]
(__do_execve_file+0x43c/0x890)
   [<c02d0c1c>] (__do_execve_file) from [<c02d1770>]
(sys_execve+0x44/0x4c)
   [<c02d172c>] (sys_execve) from [<c0101000>]
(ret_fast_syscall+0x0/0x28)
   ---[ end trace 3455789a10e3aefd ]---
The cause is that the struct ahash_request *req is created as a 
stack-local variable up in the stack (presumably somewhere in the IMA 
implementation), then passed down into the CAAM driver, which tries to 
dma_single_map the req->result (indirectly via map_seq_out_ptr_result) 
in order to make that buffer available for the CAAM to store the result 
of the following hash operation.
The calling code doesn't know how req will be used by the CAAM driver, 
and there could be other such occurrences where stack memory is passed 
down to the CAAM driver. Therefore we should rather fix this issue in 
the CAAM driver where the requirements are known."
Fix this problem by:
-instructing the crypto engine to write the final hash in
state->caam_ctx
-subsequently memcpy-ing the final hash into req->result
Cc: <stable@vger.kernel.org> # v4.19+ Reported-by: Roland Hieber
<rhi@pengutronix.de> Signed-off-by: Horia Geantă <horia.geanta@nxp.com> 
Tested-by: Roland Hieber <rhi@pengutronix.de> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: ccree - fix free of unallocated mlli buffer
commit a49411959ea6d4915a9fd2a7eb5ba220e6284e9a upstream.
In cc_unmap_aead_request(), call dma_pool_free() for mlli buffer only if
an item is allocated from the pool and not always if there is a pool
allocated. This fixes a kernel panic when trying to free a non-allocated
item.
Cc: stable@vger.kernel.org Signed-off-by: Hadar Gat <hadar.gat@arm.com> 
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: ccree - unmap buffer before copying IV
commit c139c72e2beb3e3db5148910b3962b7322e24374 upstream.
We were copying the last ciphertext block into the IV field for CBC
before removing the DMA mapping of the output buffer with the result of
the buffer sometime being out-of-sync cache wise and were getting
intermittent cases of bad output IV.
Fix it by moving the DMA buffer unmapping before the copy.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Fixes:
00904aa0cd59 ("crypto: ccree - fix iv handling") Cc:
<stable@vger.kernel.org> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: ccree - don't copy zero size ciphertext
commit 2b5ac17463dcb2411fed506edcf259a89bb538ba upstream.
For decryption in CBC mode we need to save the last ciphertext block for
use as the next IV. However, we were trying to do this also with zero
sized ciphertext resulting in a panic.
Fix this by only doing the copy if the ciphertext length is at least of
IV size.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Cc:
stable@vger.kernel.org Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: cfb - add missing 'chunksize' property
commit 394a9e044702e6a8958a5e89d2a291605a587a2a upstream.
Like some other block cipher mode implementations, the CFB 
implementation assumes that while walking through the scatterlist, a 
partial block does not occur until the end.  But the walk is incorrectly 
being done with a blocksize of 1, as 'cra_blocksize' is set to 1 (since 
CFB is a stream cipher) but no 'chunksize' is set.  This bug causes 
incorrect encryption/decryption for some scatterlist layouts.
Fix it by setting the 'chunksize'.  Also extend the CFB test vectors to 
cover this bug as well as cases where the message length is not a 
multiple of the block size.
Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack
mode") Cc: <stable@vger.kernel.org> # v4.17+ Cc: James Bottomley
<James.Bottomley@HansenPartnership.com> Signed-off-by: Eric Biggers
<ebiggers@google.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: cfb - remove bogus memcpy() with src == dest
commit 6c2e322b3621dc8be72e5c86d4fdb587434ba625 upstream.
The memcpy() in crypto_cfb_decrypt_inplace() uses walk->iv as both the 
source and destination, which has undefined behavior.  It is unneeded 
because walk->iv is already used to hold the previous ciphertext block; 
thus, walk->iv is already updated to its final value.  So, remove it.
Also, note that in-place decryption is the only case where the previous 
ciphertext block is not directly available.  Therefore, as a related 
cleanup I also updated crypto_cfb_encrypt_segment() to directly use the 
previous ciphertext block rather than save it into walk->iv.  This makes 
it consistent with in-place encryption and out-of-place decryption; now 
only in-place decryption is different, because it has to be.
Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack
mode") Cc: <stable@vger.kernel.org> # v4.17+ Cc: James Bottomley
<James.Bottomley@HansenPartnership.com> Signed-off-by: Eric Biggers
<ebiggers@google.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: ofb - fix handling partial blocks and make thread-safe
commit b3e3e2db7de4a1ffe8845876c3520b866cd48de1 upstream.
Fix multiple bugs in the OFB implementation:
1. It stored the per-request state 'cnt' in the tfm context, which can
be
  used by multiple threads concurrently (e.g. via AF_ALG). 2. It didn't
support messages not a multiple of the block cipher size,
  despite being a stream cipher. 3. It didn't set cra_blocksize to 1 to
indicate it is a stream cipher.
To fix these, set the 'chunksize' property to the cipher block size to 
guarantee that when walking through the scatterlist, a partial block can 
only occur at the end.  Then change the implementation to XOR a block at 
a time at first, then XOR the partial block at the end if needed.  This 
is the same way CTR and CFB are implemented.  As a bonus, this also 
improves performance in most cases over the current approach.
Fixes: e497c51896b3 ("crypto: ofb - add output feedback mode") Cc:
<stable@vger.kernel.org> # v4.20+ Cc: Gilad Ben-Yossef
<gilad@benyossef.com> Signed-off-by: Eric Biggers <ebiggers@google.com> 
Reviewed-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: ahash - fix another early termination in hash walk
commit 77568e535af7c4f97eaef1e555bf0af83772456c upstream.
Hash algorithms with an alignmask set, e.g. "xcbc(aes-aesni)" and
"michael_mic", fail the improved hash tests because they sometimes 
produce the wrong digest.  The bug is that in the case where a 
scatterlist element crosses pages, not all the data is actually hashed 
because the scatterlist walk terminates too early.  This happens because 
the 'nbytes' variable in crypto_hash_walk_done() is assigned the number 
of bytes remaining in the page, then later interpreted as the number of 
bytes remaining in the scatterlist element.  Fix it.
Fixes: 900a081f6912 ("crypto: ahash - Fix early termination in hash
walk") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers
<ebiggers@google.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: rockchip - fix scatterlist nents error
commit 4359669a087633132203c52d67dd8c31e09e7b2e upstream.
In some cases, the nents of src scatterlist is different from dst
scatterlist. So two variables are used to handle the nents of src&dst
scatterlist.
Reported-by: Eric Biggers <ebiggers@google.com> Fixes: 433cd2c617bf
("crypto: rockchip - add crypto driver for rk3288") Cc:
<stable@vger.kernel.org> # v4.5+ Signed-off-by: Zhang Zhijie
<zhangzj@rock-chips.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: rockchip - update new iv to device in multiple operations
commit c1c214adcb56d36433480c8fedf772498e7e539c upstream.
For chain mode in cipher(eg. AES-CBC/DES-CBC), the iv is continuously 
updated in the operation. The new iv value should be written to device 
register by software.
Reported-by: Eric Biggers <ebiggers@google.com> Fixes: 433cd2c617bf
("crypto: rockchip - add crypto driver for rk3288") Cc:
<stable@vger.kernel.org> # v4.5+ Signed-off-by: Zhang Zhijie
<zhangzj@rock-chips.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

dax: Flush partial PMDs correctly
commit e4b3448bc346fedf36db64124a664a959995b085 upstream.
The radix tree would rewind the index in an iterator to the lowest index 
of a multi-slot entry.  The XArray iterators instead leave the index 
unchanged, but I overlooked that when converting DAX from the radix tree 
to the XArray.  Adjust the index that we use for flushing to the start 
of the PMD range.
Fixes: c1901cd33cf4 ("page cache: Convert find_get_entries_tag to
XArray") Cc: <stable@vger.kernel.org> Reported-by: Piotr Balcer
<piotr.balcer@intel.com> Tested-by: Dan Williams
<dan.j.williams@intel.com> Reviewed-by: Jan Kara <jack@suse.cz> 
Signed-off-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Dan
Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

nfit: Fix nfit_intel_shutdown_status() command submission
commit f596c8844fe1d0022007ae6c7a377361fb653eff upstream.
The implementation is broken in all the ways the unit test did not
touch:
1/ The local definition of in_buf and in_obj violated C99 initializer
  expectations for zeroing. By only initializing 2 out of the three
  struct members the compiler was free to zero-initialize the remaining
  entry even though the aliased location in the union was initialized.
2/ The implementation made assumptions about the state of the 'smart'
  payload after command execution that are satisfied by
  acpi_nfit_ctl(), but not acpi_evaluate_dsm().
3/ populate_shutdown_status() is skipped on Intel NVDIMMs due to the
early
  return for skipping the common _LS{I,R,W} enabling.
4/ The input length should be zero.
This breakage was missed due to the unit test implementation only 
testing the case where nfit_intel_shutdown_status() returns a valid 
payload.
Much of this complexity would be saved if acpi_nfit_ctl() could be used,
but that currently requires a 'struct nvdimm *' argument and one is not
created until later in the init process. The health result is needed
before the device is created because the payload gates whether the
nmemX/nfit/dirty_shutdown property is visible in sysfs.
Cc: <stable@vger.kernel.org> Fixes: 0ead11181fe0 ("acpi, nfit: Collect
shutdown status") Reported-by: Dexuan Cui <decui@microsoft.com> 
Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Dan
Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

nfit: acpi_nfit_ctl(): Check out_obj->type in the right place
commit 43f89877f26671c6309cd87d7364b1a3e66e71cf upstream.
In the case of ND_CMD_CALL, we should also check out_obj->type.
The patch uses out_obj->type, which is a short alias to 
out_obj->package.type.
Fixes: 31eca76ba2fc ("nfit, libnvdimm: limited/whitelisted dimm command
marshaling mechanism") Cc: <stable@vger.kernel.org> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by: Dan Williams
<dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

acpi/nfit: Fix bus command validation
commit ebe9f6f19d80d8978d16078dff3d5bd93ad8d102 upstream.
Commit 11189c1089da "acpi/nfit: Fix command-supported detection" broke 
ND_CMD_CALL for bus-level commands. The "func = cmd" assumption is only 
valid for:
    ND_CMD_ARS_CAP
   ND_CMD_ARS_START
   ND_CMD_ARS_STATUS
   ND_CMD_CLEAR_ERROR
The function number otherwise needs to be pulled from the command 
payload for:
    NFIT_CMD_TRANSLATE_SPA
   NFIT_CMD_ARS_INJECT_SET
   NFIT_CMD_ARS_INJECT_CLEAR
   NFIT_CMD_ARS_INJECT_GET
Update cmd_to_func() for the bus case and call it in the common path.
Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection") Cc:
<stable@vger.kernel.org> Reviewed-by: Vishal Verma
<vishal.l.verma@intel.com> Reported-by: Grzegorz Burzynski
<grzegorz.burzynski@intel.com> Tested-by: Jeff Moyer <jmoyer@redhat.com> 
Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfit/ars: Attempt a short-ARS whenever the ARS state is idle at boot
commit c6c5df293bf1b488cf8459aac658aecfdccb13a9 upstream.
If query-ARS reports that ARS has stopped and requires continuation 
attempt to retrieve short-ARS results before continuing the long 
operation.
Fixes: bc6ba8085842 ("nfit, address-range-scrub: rework and simplify
ARS...") Cc: <stable@vger.kernel.org> Reported-by: Krzysztof Rusocki
<krzysztof.rusocki@intel.com> Reviewed-by: Toshi Kani
<toshi.kani@hpe.com> Signed-off-by: Dan Williams
<dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

nfit/ars: Attempt short-ARS even in the no_init_ars case
commit fa3ed4d981b1fc19acdd07fcb152a4bd3706892b upstream.
The no_init_ars option is meant to prevent long-ARS, but short-ARS 
should be allowed to grab any immediate results.
Fixes: bc6ba8085842 ("nfit, address-range-scrub: rework and simplify
ARS...") Cc: <stable@vger.kernel.org> Reported-by: Erwin Tsaur
<erwin.tsaur@oracle.com> Reviewed-by: Toshi Kani <toshi.kani@hpe.com> 
Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

libnvdimm/label: Clear 'updating' flag after label-set update
commit 966d23a006ca7b44ac8cf4d0c96b19785e0c3da0 upstream.
The UEFI 2.7 specification sets expectations that the 'updating' flag is 
eventually cleared. To date, the libnvdimm core has never adhered to 
that protocol. The policy of the core matches the policy of other 
multi-device info-block formats like MD-Software-RAID that expect 
administrator intervention on inconsistent info-blocks, not automatic 
invalidation.
However, some pre-boot environments may unfortunately attempt to "clean 
up" the labels and invalidate a set when it fails to find at least one
"non-updating" label in the set. Clear the updating flag after set 
updates to minimize the window of vulnerability to aggressive pre-boot 
environments.
Ideally implementations would not write to the label area outside of 
creating namespaces.
Note that this only minimizes the window, it does not close it as the 
system can still crash while clearing the flag and the set can be 
subsequently deleted / invalidated by the pre-boot environment.
Fixes: f524bf271a5c ("libnvdimm: write pmem label set") Cc:
<stable@vger.kernel.org> Cc: Kelly Couch <kelly.j.couch@intel.com> 
Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

libnvdimm, pfn: Fix over-trim in trim_pfn_device()
commit f101ada7da6551127d192c2f1742c1e9e0f62799 upstream.
When trying to see whether current nd_region intersects with others, 
trim_pfn_device() has already calculated the *size* to be expanded to 
SECTION size.
Do not double append 'adjust' to 'size' when calculating whether the end 
of a region collides with the next pmem region.
Fixes: ae86cbfef381 "libnvdimm, pfn: Pad pfn namespaces relative to
other regions" Cc: <stable@vger.kernel.org> Signed-off-by: Wei Yang
<richardw.yang@linux.intel.com> Signed-off-by: Dan Williams
<dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

libnvdimm/pmem: Honor force_raw for legacy pmem regions
commit fa7d2e639cd90442d868dfc6ca1d4cc9d8bf206e upstream.
For recovery, where non-dax access is needed to a given physical address 
range, and testing, allow the 'force_raw' attribute to override the 
default establishment of a dev_pagemap.
Otherwise without this capability it is possible to end up with a 
namespace that can not be activated due to corrupted info-block, and one 
that can not be repaired due to a section collision.
Cc: <stable@vger.kernel.org> Fixes: 004f1afbe199 ("libnvdimm, pmem:
direct map legacy pmem by default") Signed-off-by: Dan Williams
<dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

libnvdimm: Fix altmap reservation size calculation
commit 07464e88365e9236febaca9ed1a2e2006d8bc952 upstream.
Libnvdimm reserves the first 8K of pfn and devicedax namespaces to store
a superblock describing the namespace. This 8K reservation is contained
within the altmap area which the kernel uses for the vmemmap backing for
the pages within the namespace. The altmap allows for some pages at the
start of the altmap area to be reserved and that mechanism is used to
protect the superblock from being re-used as vmemmap backing.
The number of PFNs to reserve is calculated using:
	PHYS_PFN(SZ_8K)
Which is implemented as:
 #define PHYS_PFN(x) ((unsigned long)((x) >> PAGE_SHIFT))
So on systems where PAGE_SIZE is greater than 8K the reservation size is
truncated to zero and the superblock area is re-used as vmemmap backing.
As a result all the namespace information stored in the superblock (i.e.
if it's a PFN or DAX namespace) is lost and the namespace needs to be
re-created to get access to the contents.
This patch fixes this by using PFN_UP() rather than PHYS_PFN() to ensure 
that at least one page is reserved. On systems with a 4K pages size this 
patch should have no effect.
Cc: stable@vger.kernel.org Cc: Dan Williams <dan.j.williams@intel.com> 
Fixes: ac515c084be9 ("libnvdimm, pmem, pfn: move pfn setup to the core") 
Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vishal
Verma <vishal.l.verma@intel.com> Signed-off-by: Dan Williams
<dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

fix cgroup_do_mount() handling of failure exits
commit 399504e21a10be16dd1408ba0147367d9d82a10c upstream.
same story as with last May fixes in sysfs (7b745a4e4051
"unfuck sysfs_mount()"); new_sb is left uninitialized in case of early
errors in kernfs_mount_ns() and papering over it by treating any error
from kernfs_mount_ns() as equivalent to !new_ns ends up conflating the
cases when objects had never been transferred to a superblock with ones
when that has happened and resulting new superblock had been dropped. 
Easily fixed (same way as in sysfs case).  Additionally, there's a
superblock leak on kernfs_node_dentry() failure *and* a dentry leak
inside kernfs_node_dentry() itself - the latter on probably impossible
errors, but the former not impossible to trigger
(as the matter of fact, injecting allocation failures at that point
*does* trigger it).
Cc: stable@kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: aead - set CRYPTO_TFM_NEED_KEY if ->setkey() fails
commit 6ebc97006b196aafa9df0497fdfa866cf26f259b upstream.
Some algorithms have a ->setkey() method that is not atomic, in the 
sense that setting a key can fail after changes were already made to the 
tfm context.  In this case, if a key was already set the tfm can end up 
in a state that corresponds to neither the old key nor the new key.
For example, in gcm.c, if the kzalloc() fails due to lack of memory, 
then the CTR part of GCM will have the new key but GHASH will not.
It's not feasible to make all ->setkey() methods atomic, especially ones 
that have to key multiple sub-tfms.  Therefore, make the crypto API set 
CRYPTO_TFM_NEED_KEY if ->setkey() fails, to prevent the tfm from being 
used until a new key is set.
[Cc stable mainly because when introducing the NEED_KEY flag I changed
AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG
previously didn't have this problem.  So these "incompletely keyed"
states became theoretically accessible via AF_ALG -- though, the
opportunities for causing real mischief seem pretty limited.]
Fixes: dc26c17f743a ("crypto: aead - prevent using AEADs without setting
key") Cc: <stable@vger.kernel.org> # v4.16+ Signed-off-by: Eric Biggers
<ebiggers@google.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: aegis - fix handling chunked inputs
commit 0f533e67d26f228ea5dfdacc8a4bdeb487af5208 upstream.
The generic AEGIS implementations all fail the improved AEAD tests 
because they produce the wrong result with some data layouts.  The issue 
is that they assume that if the skcipher_walk API gives 'nbytes' not 
aligned to the walksize (a.k.a. walk.stride), then it is the end of the 
data.  In fact, this can happen before the end.  Fix them.
Fixes: f606a88e5823 ("crypto: aegis - Add generic AEGIS AEAD
implementations") Cc: <stable@vger.kernel.org> # v4.18+ Cc: Ondrej
Mosnacek <omosnace@redhat.com> Signed-off-by: Eric Biggers
<ebiggers@google.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com> 
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: arm/crct10dif - revert to C code for short inputs
commit 62fecf295e3c48be1b5f17c440b93875b9adb4d6 upstream.
The SIMD routine ported from x86 used to have a special code path for
inputs < 16 bytes, which got lost somewhere along the way. Instead, the
current glue code aligns the input pointer to permit the NEON routine to
use special versions of the vld1 instructions that assume 16 byte
alignment, but this could result in inputs of less than 16 bytes to be
passed in. This not only fails the new extended tests that Eric has
implemented, it also results in the code reading past the end of the
input, which could potentially result in crashes when dealing with less
than 16 bytes of input at the end of a page which is followed by an
unmapped page.
So update the glue code to only invoke the NEON routine if the input is
at least 16 bytes.
Reported-by: Eric Biggers <ebiggers@kernel.org> Reviewed-by: Eric
Biggers <ebiggers@kernel.org> Fixes: 1d481f1cd892 ("crypto:
arm/crct10dif - port x86 SSE implementation to ARM") Cc:
<stable@vger.kernel.org> # v4.10+ Signed-off-by: Ard Biesheuvel
<ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: arm64/aes-neonbs - fix returning final keystream block
commit 12455e320e19e9cc7ad97f4ab89c280fe297387c upstream.
The arm64 NEON bit-sliced implementation of AES-CTR fails the improved 
skcipher tests because it sometimes produces the wrong ciphertext.  The 
bug is that the final keystream block isn't returned from the assembly 
code when the number of non-final blocks is zero.  This can happen if 
the input data ends a few bytes after a page boundary.  In this case the 
last bytes get "encrypted" by XOR'ing them with uninitialized memory.
Fix the assembly code to return the final keystream block when needed.
Fixes: 88a3f582bea9 ("crypto: arm64/aes - don't use IV buffer to return
final keystream block") Cc: <stable@vger.kernel.org> # v4.11+ 
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: arm64/crct10dif - revert to C code for short inputs
commit d72b9d4acd548251f55b16843fc7a05dc5c80de8 upstream.
The SIMD routine ported from x86 used to have a special code path for
inputs < 16 bytes, which got lost somewhere along the way. Instead, the
current glue code aligns the input pointer to 16 bytes, which is not
really necessary on this architecture (although it could be beneficial
to performance to expose aligned data to the the NEON routine), but this
could result in inputs of less than 16 bytes to be passed in. This not
only fails the new extended tests that Eric has implemented, it also
results in the code reading past the end of the input, which could
potentially result in crashes when dealing with less than 16 bytes of
input at the end of a page which is followed by an unmapped page.
So update the glue code to only invoke the NEON routine if the input is
at least 16 bytes.
Reported-by: Eric Biggers <ebiggers@kernel.org> Reviewed-by: Eric
Biggers <ebiggers@kernel.org> Fixes: 6ef5737f3931 ("crypto:
arm64/crct10dif - port x86 SSE implementation to arm64") Cc:
<stable@vger.kernel.org> # v4.10+ Signed-off-by: Ard Biesheuvel
<ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: hash - set CRYPTO_TFM_NEED_KEY if ->setkey() fails
commit ba7d7433a0e998c902132bd47330e355a1eaa894 upstream.
Some algorithms have a ->setkey() method that is not atomic, in the 
sense that setting a key can fail after changes were already made to the 
tfm context.  In this case, if a key was already set the tfm can end up 
in a state that corresponds to neither the old key nor the new key.
It's not feasible to make all ->setkey() methods atomic, especially ones 
that have to key multiple sub-tfms.  Therefore, make the crypto API set 
CRYPTO_TFM_NEED_KEY if ->setkey() fails and the algorithm requires a 
key, to prevent the tfm from being used until a new key is set.
Note: we can't set CRYPTO_TFM_NEED_KEY for OPTIONAL_KEY algorithms, so
->setkey() for those must nevertheless be atomic.  That's fine for now 
since only the crc32 and crc32c algorithms set OPTIONAL_KEY, and it's 
not intended that OPTIONAL_KEY be used much.
[Cc stable mainly because when introducing the NEED_KEY flag I changed
AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG
previously didn't have this problem.  So these "incompletely keyed"
states became theoretically accessible via AF_ALG -- though, the
opportunities for causing real mischief seem pretty limited.]
Fixes: 9fa68f620041 ("crypto: hash - prevent using keyed hashes without
setting key") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers
<ebiggers@google.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: morus - fix handling chunked inputs
commit d644f1c8746ed24f81075480f9e9cb3777ae8d65 upstream.
The generic MORUS implementations all fail the improved AEAD tests 
because they produce the wrong result with some data layouts.  The issue 
is that they assume that if the skcipher_walk API gives 'nbytes' not 
aligned to the walksize (a.k.a. walk.stride), then it is the end of the 
data.  In fact, this can happen before the end.  Fix them.
Fixes: 396be41f16fd ("crypto: morus - Add generic MORUS AEAD
implementations") Cc: <stable@vger.kernel.org> # v4.18+ Cc: Ondrej
Mosnacek <omosnace@redhat.com> Signed-off-by: Eric Biggers
<ebiggers@google.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com> 
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: pcbc - remove bogus memcpy()s with src == dest
commit 251b7aea34ba3c4d4fdfa9447695642eb8b8b098 upstream.
The memcpy()s in the PCBC implementation use walk->iv as both the source 
and destination, which has undefined behavior.  These memcpy()'s are 
actually unneeded, because walk->iv is already used to hold the previous 
plaintext block XOR'd with the previous ciphertext block.  Thus, 
walk->iv is already updated to its final value.
So remove the broken and unnecessary memcpy()s.
Fixes: 91652be5d1b9 ("[CRYPTO] pcbc: Add Propagated CBC template") Cc:
<stable@vger.kernel.org> # v2.6.21+ Cc: David Howells
<dhowells@redhat.com> Signed-off-by: Eric Biggers <ebiggers@google.com> 
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: skcipher - set CRYPTO_TFM_NEED_KEY if ->setkey() fails
commit b1f6b4bf416b49f00f3abc49c639371cdecaaad1 upstream.
Some algorithms have a ->setkey() method that is not atomic, in the 
sense that setting a key can fail after changes were already made to the 
tfm context.  In this case, if a key was already set the tfm can end up 
in a state that corresponds to neither the old key nor the new key.
For example, in lrw.c, if gf128mul_init_64k_bbe() fails due to lack of 
memory, then priv::table will be left NULL.  After that, encryption with 
that tfm will cause a NULL pointer dereference.
It's not feasible to make all ->setkey() methods atomic, especially ones 
that have to key multiple sub-tfms.  Therefore, make the crypto API set 
CRYPTO_TFM_NEED_KEY if ->setkey() fails and the algorithm requires a 
key, to prevent the tfm from being used until a new key is set.
[Cc stable mainly because when introducing the NEED_KEY flag I changed
AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG
previously didn't have this problem.  So these "incompletely keyed"
states became theoretically accessible via AF_ALG -- though, the
opportunities for causing real mischief seem pretty limited.]
Fixes: f8d33fac8480 ("crypto: skcipher - prevent using skciphers without
setting key") Cc: <stable@vger.kernel.org> # v4.16+ Signed-off-by: Eric
Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: testmgr - skip crc32c context test for ahash algorithms
commit eb5e6730db98fcc4b51148b4a819fa4bf864ae54 upstream.
Instantiating "cryptd(crc32c)" causes a crypto self-test failure because 
the crypto_alloc_shash() in alg_test_crc32c() fails.  This is because 
cryptd(crc32c) is an ahash algorithm, not a shash algorithm; so it can 
only be accessed through the ahash API, unlike shash algorithms which 
can be accessed through both the ahash and shash APIs.
As the test is testing the shash descriptor format which is only 
applicable to shash algorithms, skip it for ahash algorithms.
(Note that it's still important to fix crypto self-test failures even
for weird algorithm instantiations like cryptd(crc32c) that no one
would really use; in fips_enabled mode unprivileged users can use them
to panic the kernel, and also they prevent treating a crypto self-test
failure as a bug when fuzzing the kernel.)
Fixes: 8e3ee85e68c5 ("crypto: crc32c - Test descriptor context format") 
Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers
<ebiggers@google.com> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: x86/aegis - fix handling chunked inputs and MAY_SLEEP
commit ba6771c0a0bc2fac9d6a8759bab8493bd1cffe3b upstream.
The x86 AEGIS implementations all fail the improved AEAD tests because 
they produce the wrong result with some data layouts.  The issue is that 
they assume that if the skcipher_walk API gives 'nbytes' not aligned to 
the walksize (a.k.a. walk.stride), then it is the end of the data.  In 
fact, this can happen before the end.
Also, when the CRYPTO_TFM_REQ_MAY_SLEEP flag is given, they can 
incorrectly sleep in the skcipher_walk_*() functions while preemption 
has been disabled by kernel_fpu_begin().
Fix these bugs.
Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS
implementations") Cc: <stable@vger.kernel.org> # v4.18+ Cc: Ondrej
Mosnacek <omosnace@redhat.com> Signed-off-by: Eric Biggers
<ebiggers@google.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com> 
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: x86/aesni-gcm - fix crash on empty plaintext
commit 3af349639597fea582a93604734d717e59a0e223 upstream.
gcmaes_crypt_by_sg() dereferences the NULL pointer returned by 
scatterwalk_ffwd() when encrypting an empty plaintext and the source 
scatterlist ends immediately after the associated data.
Fix it by only fast-forwarding to the src/dst data scatterlists if the 
data length is nonzero.
This bug is reproduced by the "rfc4543(gcm(aes))" test vectors when run 
with the new AEAD test manager.
Fixes: e845520707f8 ("crypto: aesni - Update aesni-intel_glue to use
scatter/gather") Cc: <stable@vger.kernel.org> # v4.17+ Cc: Dave Watson
<davejwatson@fb.com> Signed-off-by: Eric Biggers <ebiggers@google.com> 
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: x86/morus - fix handling chunked inputs and MAY_SLEEP
commit 2060e284e9595fc3baed6e035903c05b93266555 upstream.
The x86 MORUS implementations all fail the improved AEAD tests because 
they produce the wrong result with some data layouts.  The issue is that 
they assume that if the skcipher_walk API gives 'nbytes' not aligned to 
the walksize (a.k.a. walk.stride), then it is the end of the data.  In 
fact, this can happen before the end.
Also, when the CRYPTO_TFM_REQ_MAY_SLEEP flag is given, they can 
incorrectly sleep in the skcipher_walk_*() functions while preemption 
has been disabled by kernel_fpu_begin().
Fix these bugs.
Fixes: 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for
MORUS") Cc: <stable@vger.kernel.org> # v4.18+ Cc: Ondrej Mosnacek
<omosnace@redhat.com> Signed-off-by: Eric Biggers <ebiggers@google.com> 
Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: arm64/aes-ccm - fix logical bug in AAD MAC handling
commit eaf46edf6ea89675bd36245369c8de5063a0272c upstream.
The NEON MAC calculation routine fails to handle the case correctly 
where there is some data in the buffer, and the input fills it up 
exactly. In this case, we enter the loop at the end with w8 == 0, while
a negative value is assumed, and so the loop carries on until the
increment of the 32-bit counter wraps around, which is quite obviously
wrong.
So omit the loop altogether in this case, and exit right away.
Reported-by: Eric Biggers <ebiggers@kernel.org> Fixes: a3fd82105b9d1
("arm64/crypto: AES in CCM mode using ARMv8 Crypto ...") Cc:
stable@vger.kernel.org Signed-off-by: Ard Biesheuvel
<ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

crypto: arm64/aes-ccm - fix bugs in non-NEON fallback routine
commit 969e2f59d589c15f6aaf306e590dde16f12ea4b3 upstream.
Commit 5092fcf34908 ("crypto: arm64/aes-ce-ccm: add non-SIMD generic 
fallback") introduced C fallback code to replace the NEON routines when
invoked from a context where the NEON is not available (i.e., from the
context of a softirq taken while the NEON is already being used in
kernel process context)
Fix two logical flaws in the MAC calculation of the associated data.
Reported-by: Eric Biggers <ebiggers@kernel.org> Fixes: 5092fcf34908
("crypto: arm64/aes-ce-ccm: add non-SIMD generic fallback") Cc:
stable@vger.kernel.org Signed-off-by: Ard Biesheuvel
<ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu
<herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

CIFS: Fix leaking locked VFS cache pages in writeback retry
commit 165df9a080b6863ae286fa01780c13d87cd81076 upstream.
If we don't find a writable file handle when retrying writepages we
break of the loop and do not unlock and put pages neither from wdata2
nor from the original wdata. Fix this by walking through all the
remaining pages and cleanup them properly.
Cc: <stable@vger.kernel.org> Signed-off-by: Pavel Shilovsky
<pshilov@microsoft.com> Signed-off-by: Steve French
<stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

CIFS: Do not reset lease state to NONE on lease break
commit 7b9b9edb49ad377b1e06abf14354c227e9ac4b06 upstream.
Currently on lease break the client sets a caching level twice: when
oplock is detected and when oplock is processed. While the 1st attempt
sets the level to the value provided by the server, the 2nd one resets
the level to None unconditionally. This happens because the oplock/lease
processing code was changed to avoid races between page cache flushes
and oplock breaks. The commit c11f1df5003d534 ("cifs: Wait for
writebacks to complete before attempting write.") fixed the races for
oplocks but didn't apply the same changes for leases resulting in
overwriting the server granted value to None. Fix this by properly
processing lease breaks.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
Steve French <stfrench@microsoft.com> CC: Stable
<stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

CIFS: Do not skip SMB2 message IDs on send failures
commit c781af7e0c1fed9f1d0e0ec31b86f5b21a8dca17 upstream.
When we hit failures during constructing MIDs or sending PDUs through
the network, we end up not using message IDs assigned to the packet. The
next SMB packet will skip those message IDs and continue with the next
one. This behavior may lead to a server not granting us credits until we
use the skipped IDs. Fix this by reverting the current ID to the
original value if any errors occur before we push the packet through the
network stack.
This patch fixes the generic/310 test from the xfs-tests.
Cc: <stable@vger.kernel.org> # 4.19.x Signed-off-by: Pavel Shilovsky
<pshilov@microsoft.com> Signed-off-by: Steve French
<stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

CIFS: Fix read after write for files with read caching
commit 6dfbd84684700cb58b34e8602c01c12f3d2595c8 upstream.
When we have a READ lease for a file and have just issued a write 
operation to the server we need to purge the cache and set oplock/lease 
level to NONE to avoid reading stale data. Currently we do that only if
a write operation succedeed thus not covering cases when a request was
sent to the server but a negative error code was returned later for some
other reasons (e.g. -EIOCBQUEUED or -EINTR). Fix this by turning off
caching regardless of the error code being returned.
The patches fixes generic tests 075 and 112 from the xfs-tests.
Cc: <stable@vger.kernel.org> Signed-off-by: Pavel Shilovsky
<pshilov@microsoft.com> Signed-off-by: Steve French
<stfrench@microsoft.com> Reviewed-by: Ronnie Sahlberg
<lsahlber@redhat.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

smb3: make default i/o size for smb3 mounts larger
commit e8506d25f740fd058791cc12a6dfa9386ada6b96 upstream.
We negotiate rsize mounts (and it can be overridden by user) to 
typically 4MB, so using larger default I/O sizes from userspace
(changing to 1MB default i/o size returned by stat) the performance is
much better (and not just for long latency network connections) in most
use cases for SMB3 than the default I/O size (which ends up being 128K
for cp and can be even smaller for cp). This can be 4x slower or worse
depending on network latency.
By changing inode->blocksize from 32K (which was perhaps ok for very old
SMB1/CIFS) to a larger value, 1MB (but still less than max size
negotiated with the server which is 4MB, in order to minimize risk) it
significantly increases performance for the noncached case, and slightly
increases it for the cached case. This can be changed by the user on
mount (specifying bsize= values from 16K to 16MB) to tune better for
performance for applications that depend on blocksize.
Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Ronnie
Sahlberg <lsahlber@redhat.com> CC: Stable <stable@vger.kernel.org> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing: Use strncpy instead of memcpy for string keys in hist triggers
commit 9f0bbf3115ca9f91f43b7c74e9ac7d79f47fc6c2 upstream.
Because there may be random garbage beyond a string's null terminator, 
it's not correct to copy the the complete character array for use as a 
hist trigger key.  This results in multiple histogram entries for the
'same' string key.
So, in the case of a string key, use strncpy instead of memcpy to avoid
copying in the extra bytes.
Before, using the gdbus entries in the following hist trigger as an 
example:
  # echo 'hist:key=comm' >
/sys/kernel/debug/tracing/events/sched/sched_waking/trigger
 # cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist
  ...
  { comm: ImgDecoder #4                      } hitcount:        203
 { comm: gmain                              } hitcount:        213
 { comm: gmain                              } hitcount:        216
 { comm: StreamTrans #73                    } hitcount:        221
 { comm: mozStorage #3                      } hitcount:        230
 { comm: gdbus                              } hitcount:        233
 { comm: StyleThread#5                      } hitcount:        253
 { comm: gdbus                              } hitcount:        256
 { comm: gdbus                              } hitcount:        260
 { comm: StyleThread#4                      } hitcount:        271
  ...
  # cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist | egrep
gdbus | wc -l
 51
After:
  # cat /sys/kernel/debug/tracing/events/sched/sched_waking/hist | egrep
gdbus | wc -l
 1
Link:
http://lkml.kernel.org/r/50c35ae1267d64eee975b8125e151e600071d4dc.1549309756.git.tom.zanussi@linux.intel.com
Cc: Namhyung Kim <namhyung@kernel.org> Cc: stable@vger.kernel.org Fixes:
79e577cbce4c4 ("tracing: Support string type key properly") 
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

tracing: Do not free iter->trace in fail path of tracing_open_pipe()
commit e7f0c424d0806b05d6f47be9f202b037eb701707 upstream.
Commit d716ff71dd12 ("tracing: Remove taking of trace_types_lock in pipe
files") use the current tracer instead of the copy in 
tracing_open_pipe(), but it forget to remove the freeing sentence in the
error path.
There's an error path that can call kfree(iter->trace) after the
iter->trace was assigned to tr->current_trace, which would be bad to
free.
Link:
http://lkml.kernel.org/r/1550060946-45984-1-git-send-email-yi.zhang@huawei.com
Cc: stable@vger.kernel.org Fixes: d716ff71dd12 ("tracing: Remove taking
of trace_types_lock in pipe files") Signed-off-by: zhangyi (F)
<yi.zhang@huawei.com> Signed-off-by: Steven Rostedt (VMware)
<rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

tracing/perf: Use strndup_user() instead of buggy open-coded version
commit 83540fbc8812a580b6ad8f93f4c29e62e417687e upstream.
The first version of this method was missing the check for
`ret == PATH_MAX`; then such a check was added, but it didn't call
kfree() on error, so there was still a small memory leak in the error
case. Fix it by using strndup_user() instead of open-coding it.
Link: http://lkml.kernel.org/r/20190220165443.152385-1-jannh@google.com
Cc: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Fixes:
0eadcc7a7bc0 ("perf/core: Fix perf_uprobe_init()") Reviewed-by: Masami
Hiramatsu <mhiramat@kernel.org> Acked-by: Song Liu
<songliubraving@fb.com> Signed-off-by: Jann Horn <jannh@google.com> 
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vmw_balloon: release lock on error in vmballoon_reset()
commit d04071a5d6413b65f17f7bd6e2bdb22e22e4ace7 upstream.
We added some locking to this function but forgot to drop the lock on 
these two error paths.  This bug would lead to an immediate deadlock.
Fixes: c7b3690fb152 ("vmw_balloon: stats rework") Signed-off-by: Dan
Carpenter <dan.carpenter@oracle.com> Cc: stable@vger.kernel.org 
Reviewed-by: Nadav Amit <namit@vmware.com> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

xen: fix dom0 boot on huge systems
commit 01bd2ac2f55a1916d81dace12fa8d7ae1c79b5ea upstream.
Commit f7c90c2aa40048 ("x86/xen: don't write ptes directly in 32-bit PV
guests") introduced a regression for booting dom0 on huge systems with
lots of RAM (in the TB range).
Reason is that on those hosts the p2m list needs to be moved early in 
the boot process and this requires temporary page tables to be created. 
Said commit modified xen_set_pte_init() to use a hypercall for writing a
PTE, but this requires the page table being in the direct mapped area,
which is not the case for the temporary page tables used in 
xen_relocate_p2m().
As the page tables are completely written before being linked to the 
actual address space instead of set_pte() a plain write to memory can be
used in xen_relocate_p2m().
Fixes: f7c90c2aa40048 ("x86/xen: don't write ptes directly in 32-bit PV
guests") Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross
<jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> 
Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI / device_sysfs: Avoid OF modalias creation for removed device
commit f16eb8a4b096514ac06fb25bf599dcc792899b3d upstream.
If SSDT overlay is loaded via ConfigFS and then unloaded the device, we
would like to have OF modalias for, already gone. Thus, acpi_get_name() 
returns no allocated buffer for such case and kernel crashes afterwards:
 ACPI: Host-directed Dynamic ACPI Table Unload
ads7950 spi-PRP0001:00: Dropping the link to regulator.0
BUG: unable to handle kernel NULL pointer dereference at
0000000000000000
#PF error: [normal kernel read fault]
PGD 80000000070d6067 P4D 80000000070d6067 PUD 70d0067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 40 Comm: kworker/u4:2 Not tainted 5.0.0+ #96
Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542
2015.01.21:18.19.48
Workqueue: kacpi_hotplug acpi_device_del_work_fn
RIP: 0010:create_of_modalias.isra.1+0x4c/0x150
Code: 00 00 48 89 44 24 18 31 c0 48 8d 54 24 08 48 c7 44 24 10 00 00 00
00 48 c7 44 24 08 ff ff ff ff e8 7a b0 03 00 48 8b 4c 24 10 <0f> b6 01
84 c0 74 27 48 c7 c7 00 09 f4 a5 0f b6 f0 8d 50 20 f6 04
RSP: 0000:ffffa51040297c10 EFLAGS: 00010246
RAX: 0000000000001001 RBX: 0000000000000785 RCX: 0000000000000000
RDX: 0000000000001001 RSI: 0000000000000286 RDI: ffffa2163dc042e0
RBP: ffffa216062b1196 R08: 0000000000001001 R09: ffffa21639873000
R10: ffffffffa606761d R11: 0000000000000001 R12: ffffa21639873218
R13: ffffa2163deb5060 R14: ffffa216063d1010 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffa2163e000000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000007114000 CR4: 00000000001006f0
Call Trace:
 __acpi_device_uevent_modalias+0xb0/0x100
 spi_uevent+0xd/0x40
 ...
In order to fix above let create_of_modalias() check the status returned 
by acpi_get_name() and bail out in case of failure.
Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when
"compatible" is present") Link:
https://bugzilla.kernel.org/show_bug.cgi?id=201381 Reported-by: Ferry
Toth <fntoth@gmail.com> Tested-by: Ferry Toth<fntoth@gmail.com> 
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> 
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: 4.1+
<stable@vger.kernel.org> # 4.1+ Signed-off-by: Rafael J. Wysocki
<rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

mmc: sdhci-esdhc-imx: fix HS400 timing issue
commit de0a0decf2edfc5b0c782915f4120cf990a9bd13 upstream.
Now tuning reset will be done when the timing is MMC_TIMING_LEGACY/ 
MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS. But for timing MMC_TIMING_MMC_HS, we
can not do tuning reset, otherwise HS400 timing is not right.
Here is the process of init HS400, first finish tuning in HS200 mode, 
then switch to HS mode and 8 bit DDR mode, finally switch to HS400 mode.
If we do tuning reset in HS mode, this will cause HS400 mode lost the
tuning setting, which will cause CRC error.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Cc:
stable@vger.kernel.org # v4.12+ Acked-by: Adrian Hunter
<adrian.hunter@intel.com> Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx:
reset tuning circuit when power on mmc card") Signed-off-by: Ulf Hansson
<ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

mmc: renesas_sdhi: Fix card initialization failure in high speed mode
commit d30ae056adb81e1d2b8b953efa74735a020b8e3b upstream.
This fixes card initialization failure in high speed mode.
If U-Boot uses SDR or HS200/400 mode before starting Linux and Linux DT
does not enable SDR/HS200/HS400 mode, card initialization fails in high
speed mode.
It is necessary to initialize SCC registers during card initialization 
phase. HW reset function is registered only for a port with either of 
SDR/HS200/HS400 properties in device tree. If SDR/HS200/HS400 properties 
are not present in device tree, SCC registers will not be reset. In SoC 
that support SCC registers, HW reset function should be registered 
regardless of the configuration of device tree.
Reproduction procedure:
- Use U-Boot that support MMC HS200/400 mode.
- Delete HS200/HS400 properties in device tree.
 (Delete mmc-hs200-1_8v and mmc-hs400-1_8v)
- MMC port works high speed mode and all commands fail.
Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com> 
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Niklas
Söderlund <niklas.soderlund+renesas@ragnatech.se> Cc: Simon Horman
<horms+renesas@verge.net.au> Reviewed-by: Wolfram Sang
<wsa+renesas@sang-engineering.com> Cc: stable@vger.kernel.org 
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

mmc:fix a bug when max_discard is 0
commit d4721339dcca7def04909a8e60da43c19a24d8bf upstream.
The original purpose of the code I fix is to replace max_discard with 
max_trim if max_trim is less than max_discard. When max_discard is 0 we
should replace max_discard with max_trim as well, because max_discard
equals 0 happens only when the max_do_calc_max_discard process is
overflowed, so if mmc_can_trim(card) is true, max_discard should be
replaced by an available max_trim. However, in the original code, there
are two lines of code interfere the right process. 1) if (max_discard &&
mmc_can_trim(card)) when max_discard is 0, it skips the process checking
if max_discard needs to be replaced with max_trim. 2) if (max_trim <
max_discard) the condition is false when max_discard is 0. it also skips
the process that replaces max_discard with max_trim, in fact, we should
replace the 0-valued max_discard with max_trim.
Signed-off-by: Jiong Wu <Lohengrin1024@gmail.com> Fixes: b305882fbc87
(mmc: core: optimize mmc_calc_max_discard) Cc: stable@vger.kernel.org #
v4.17+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: ti-qspi: Fix mmap read when more than one CS in use
commit 673c865efbdc5fec3cc525c46d71844d42c60072 upstream.
Commit 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support") has 
has got order of parameter wrong when calling regmap_update_bits() to 
select CS for mmap access. Mask and value arguments are interchanged. 
Code will work on a system with single slave, but fails when more than 
one CS is in use. Fix this by correcting the order of parameters when 
calling regmap_update_bits().
Fixes: 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support") Cc:
stable@vger.kernel.org Signed-off-by: Vignesh R <vigneshr@ti.com> 
Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

spi: pxa2xx: Setup maximum supported DMA transfer length
commit ef070b4e4aa25bb5f8632ad196644026c11903bf upstream.
When the commit b6ced294fb61
   ("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
switches to SPI core provided DMA helpers, it missed to setup maximum 
supported DMA transfer length for the controller and thus users 
mistakenly try to send more data than supported with the following 
warning:
  ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600
greater than 65536
Setup maximum supported DMA transfer length in order to make users know 
the limit.
Fixes: b6ced294fb61 ("spi: pxa2xx: Switch to SPI core DMA mapping
functionality") Signed-off-by: Andy Shevchenko
<andriy.shevchenko@linux.intel.com> Signed-off-by: Mark Brown
<broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

spi: omap2-mcspi: Fix DMA and FIFO event trigger size mismatch
commit baf8b9f8d260c55a86405f70a384c29cda888476 upstream.
Commit b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to
word length") broke SPI transfers where bits_per_word != 8. This is
because of mimsatch between McSPI FIFO level event trigger size (SPI
word length) and DMA request size(word length * maxburst). This leads to
data corruption, lockup and errors like:
	spi1.0: EOW timed out
Fix this by setting DMA maxburst size to 1 so that McSPI FIFO level
event trigger size matches DMA request size.
Fixes: b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to
word length") Cc: stable@vger.kernel.org Reported-by: David Lechner
<david@lechnology.com> Tested-by: David Lechner <david@lechnology.com> 
Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Mark Brown
<broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

spi: spi-gpio: fix SPI_CS_HIGH capability
commit b89fefda7d4e3a649129584d855be233c7465264 upstream.
spi-gpio is capable of dealing with active-high chip-selects. 
Unfortunately, commit 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE 
support") broke this by setting master->mode_bits, which overrides the
setting in the spi-bitbang code.  Fix this.
[Fixed a trivial conflict with SPI_3WIRE_HIZ support -- broonie]
Fixes: 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support") 
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: s2mps11: Fix steps for buck7, buck8 and LDO35
commit 56b5d4ea778c1b0989c5cdb5406d4a488144c416 upstream.
LDO35 uses 25 mV step, not 50 mV.  Bucks 7 and 8 use 12.5 mV step 
instead of 6.25 mV.  Wrong step caused over-voltage (LDO35) or 
under-voltage (buck7 and 8) if regulators were used (e.g. on Exynos5420 
Arndale Octa board).
Cc: <stable@vger.kernel.org> Fixes: cb74685ecb39 ("regulator: s2mps11:
Add samsung s2mps11 regulator driver") Signed-off-by: Krzysztof
Kozlowski <krzk@kernel.org> Signed-off-by: Mark Brown
<broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

regulator: max77620: Initialize values for DT properties
commit 0ab66b3c326ef8f77dae9f528118966365757c0c upstream.
If regulator DT node doesn't exist, its of_parse_cb callback function
isn't called. Then all values for DT properties are filled with zero.
This leads to wrong register update for FPS and POK settings.
Signed-off-by: Jinyoung Park <jinyoungp@nvidia.com> Signed-off-by: Mark
Zhang <markz@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org> 
Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

regulator: s2mpa01: Fix step values for some LDOs
commit 28c4f730d2a44f2591cb104091da29a38dac49fe upstream.
The step values for some of the LDOs appears to be incorrect, resulting 
in incorrect voltages (or at least, ones which are different from the 
Samsung 3.4 vendor kernel).
Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com> 
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Mark
Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mt76: fix corrupted software generated tx CCMP PN
commit 906d2d3f874a54183df5a609fda180adf0462428 upstream.
Since ccmp_pn is u8 *, the second half needs to start at array index 4 
instead of 0. Fixes a connection stall after a certain amount of traffic
Fixes: 23405236460b9 ("mt76: fix transmission of encrypted management
frames") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau
<nbd@nbd.name> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

clocksource/drivers/exynos_mct: Move one-shot check from tick clear to
ISR
commit a5719a40aef956ba704f2aa1c7b977224d60fa96 upstream.
When a timer tick occurs and the clock is in one-shot mode, the timer 
needs to be stopped to prevent it triggering subsequent interrupts. 
Currently this code is in exynos4_mct_tick_clear(), but as it is only
needed when an ISR occurs move it into exynos4_mct_tick_isr(), leaving
exynos4_mct_tick_clear() just doing what its name suggests it should.
Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com> 
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Marek
Szyprowski <m.szyprowski@samsung.com> Cc: stable@vger.kernel.org # v4.3+ 
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clocksource/drivers/exynos_mct: Clear timer interrupt when shutdown
commit d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c upstream.
When shutting down the timer, ensure that after we have stopped the 
timer any pending interrupts are cleared. This fixes a problem when 
suspending, as interrupts are disabled before the timer is stopped, so
the timer interrupt may still be asserted, preventing the system 
entering a low power state when the wfi is executed.
Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com> 
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Marek
Szyprowski <m.szyprowski@samsung.com> Cc: <stable@vger.kernel.org> #
v4.3+ Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer
instability
commit c950ca8c35eeb32224a63adc47e12f9e226da241 upstream.
The Allwinner A64 SoC is known[1] to have an unstable architectural 
timer, which manifests itself most obviously in the time jumping forward 
a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a timer
frequency of 24 MHz, implying that the time went slightly backward
(and this was interpreted by the kernel as it jumping forward and 
wrapping around past the epoch).
Investigation revealed instability in the low bits of CNTVCT at the 
point a high bit rolls over. This leads to power-of-two cycle forward 
and backward jumps. (Testing shows that forward jumps are about twice as 
likely as backward jumps.) Since the counter value returns to normal 
after an indeterminate read, each "jump" really consists of both a 
forward and backward jump from the software perspective.
Unless the kernel is trapping CNTVCT reads, a userspace program is able 
to read the register in a loop faster than it changes. A test program 
running on all 4 CPU cores that reported jumps larger than 100 ms was 
run for 13.6 hours and reported the following:
 Count | Event
-------+---------------------------
 9940 | jumped backward      699ms
  268 | jumped backward     1398ms
    1 | jumped backward     2097ms
16020 | jumped forward       175ms
 6443 | jumped forward       699ms
 2976 | jumped forward      1398ms
    9 | jumped forward    356516ms
    9 | jumped forward    357215ms
    4 | jumped forward    714430ms
    1 | jumped forward   3578440ms
This works out to a jump larger than 100 ms about every 5.5 seconds on 
each CPU core.
The largest jump (almost an hour!) was the following sequence of reads:
   0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000
Note that the middle bits don't necessarily all read as all zeroes or 
all ones during the anomalous behavior; however the low 10 bits checked 
by the function in this patch have never been observed with any other 
value.
Also note that smaller jumps are much more common, with backward jumps 
of 2048 (2^11) cycles observed over 400 times per second on each core.
(Of course, this is partially explained by lower bits rolling over more 
frequently.) Any one of these could have caused the 95 year time skip.
Similar anomalies were observed while reading CNTPCT (after patching the 
kernel to allow reads from userspace). However, the CNTPCT jumps are 
much less frequent, and only small jumps were observed. The same program 
as before (except now reading CNTPCT) observed after 72 hours:
 Count | Event
-------+---------------------------
   17 | jumped backward      699ms
   52 | jumped forward       175ms
 2831 | jumped forward       699ms
    5 | jumped forward      1398ms
Further investigation showed that the instability in CNTPCT/CNTVCT also 
affected the respective timer's TVAL register. The following values were 
observed immediately after writing CNVT_TVAL to 0x10000000:
 CNTVCT             | CNTV_TVAL  | CNTV_CVAL          | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000
0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000
0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000
0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000
The pattern of errors in CNTV_TVAL seemed to depend on exactly which 
value was written to it. For example, after writing 0x10101010:
 CNTVCT             | CNTV_TVAL  | CNTV_CVAL          | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000
0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000
0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000
0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000
0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000
0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000
I was also twice able to reproduce the issue covered by Allwinner's 
workaround[4], that writing to TVAL sometimes fails, and both CVAL and 
TVAL are left with entirely bogus values. One was the following values:
 CNTVCT             | CNTV_TVAL  | CNTV_CVAL
--------------------+------------+--------------------------------------
0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past) 
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
========================================================================
Because the CPU can read the CNTPCT/CNTVCT registers faster than they 
change, performing two reads of the register and comparing the high bits
(like other workarounds) is not a workable solution. And because the 
timer can jump both forward and backward, no pair of reads can 
distinguish a good value from a bad one. The only way to guarantee a 
good value from consecutive reads would be to read _three_ times, and 
take the middle value only if the three values are 1) each unique and 2)
increasing. This takes at minimum 3 counter cycles (125 ns), or more if
an anomaly is detected.
However, since there is a distinct pattern to the bad values, we can 
optimize the common case (1022/1024 of the time) to a single read by 
simply ignoring values that match the error pattern. This still takes no 
more than 3 cycles in the worst case, and requires much less code. As an 
additional safety check, we still limit the loop iteration to the number 
of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods.
For the TVAL registers, the simple solution is to not use them. Instead, 
read or write the CVAL and calculate the TVAL value in software.
Although the manufacturer is aware of at least part of the erratum[4], 
there is no official name for it. For now, use the kernel-internal name
"UNKNOWN1".
[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
[4]:
https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Andre
Przywara <andre.przywara@arm.com> Signed-off-by: Samuel Holland
<samuel@sholland.org> Cc: stable@vger.kernel.org Signed-off-by: Daniel
Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
commit 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 upstream.
Libudev relies on having a subsystem link for non-root devices. To avoid
libudev (and potentially other userspace tools) choking on the matrix
device let us introduce a matrix bus and with it the matrix bus
subsytem. Also make the matrix device reside within the matrix bus.
Doing this we remove the forced link from the matrix device to the 
vfio_ap driver and the device_type we do not need anymore.
Since the associated matrix driver is not the vfio_ap driver any more, 
we have to change the search for the devices on the vfio_ap driver in 
the function vfio_ap_verify_queue_reserved. Fixes: 1fde573413b5 ("s390:
vfio-ap: base implementation of VFIO AP device driver") Cc:
stable@vger.kernel.org
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Reported-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Pierre
Morel <pmorel@linux.ibm.com> Tested-by: Christian Borntraeger
<borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> 
Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Acked-by: Halil Pasic
<pasic@linux.ibm.com> Signed-off-by: Martin Schwidefsky
<schwidefsky@de.ibm.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

s390/setup: fix early warning messages
commit 8727638426b0aea59d7f904ad8ddf483f9234f88 upstream.
The setup_lowcore() function creates a new prefix page for the boot CPU. 
The PSW mask for the system_call, external interrupt, i/o interrupt and 
the program check handler have the DAT bit set in this new prefix page.
At the time setup_lowcore is called the system still runs without
virtual address translation, the paging_init() function creates the
kernel page table and loads the CR13 with the kernel ASCE.
Any code between setup_lowcore() and the end of paging_init() that has a
BUG or WARN statement will create a program check that can not be 
handled correctly as there is no kernel page table yet.
To allow early WARN statements initially setup the lowcore with DAT off 
and set the DAT bit only after paging_init() has completed.
Cc: stable@vger.kernel.org Signed-off-by: Martin Schwidefsky
<schwidefsky@de.ibm.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

s390/virtio: handle find on invalid queue gracefully
commit 3438b2c039b4bf26881786a1f3450f016d66ad11 upstream.
A queue with a capacity of zero is clearly not a valid virtio queue. 
Some emulators report zero queue size if queried with an invalid queue 
index. Instead of crashing in this case let us just return -ENOENT. To 
make that work properly, let us fix the notifier cleanup logic as well.
Cc: stable@vger.kernel.org Signed-off-by: Halil Pasic
<pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> 
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: virtio_scsi: don't send sc payload with tmfs
commit 3722e6a52174d7c3a00e6f5efd006ca093f346c1 upstream.
The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of 
device-readable records and a single device-writable response entry:
    struct virtio_scsi_ctrl_tmf
   {
       // Device-readable part
       le32 type;
       le32 subtype;
       u8 lun[8];
       le64 id;
       // Device-writable part
       u8 response;
   }
The above should be organised as two descriptor entries (or potentially 
more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after
"le64 id" or after "u8 response".
The Linux driver doesn't respect that, with virtscsi_abort() and 
virtscsi_device_reset() setting cmd->sc before calling virtscsi_tmf(). 
It results in the original scsi command payload (or writable buffers)
added to the tmf.
This fixes the problem by leaving cmd->sc zeroed out, which makes 
virtscsi_kick_cmd() add the tmf to the control vq without any payload.
Cc: stable@vger.kernel.org Signed-off-by: Felipe Franciosi
<felipe@nutanix.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> 
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: aacraid: Fix performance issue on logical drives
commit 0015437cc046e5ec2b57b00ff8312b8d432eac7c upstream.
Fix performance issue where the queue depth for SmartIOC logical volumes
is set to 1, and allow the usual logical volume code to be executed
Fixes: a052865fe287 (aacraid: Set correct Queue Depth for HBA1000 RAW
disks) Cc: stable@vger.kernel.org Signed-off-by: Sagar Biradar
<Sagar.Biradar@microchip.com> Reviewed-by: Dave Carroll
<david.carroll@microsemi.com> Signed-off-by: Martin K. Petersen
<martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

scsi: sd: Optimal I/O size should be a multiple of physical block size
commit a83da8a4509d3ebfe03bb7fffce022e4d5d4764f upstream.
It was reported that some devices report an OPTIMAL TRANSFER LENGTH of 
0xFFFF blocks. That looks bogus, especially for a device with a 
4096-byte physical block size.
Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's 
reported physical block size.
To make the sanity checking conditionals more readable--and to 
facilitate printing warnings--relocate the checking to a helper 
function. No functional change aside from the printks.
Cc: <stable@vger.kernel.org> Bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=199759 Reported-by:
Christoph Anton Mitterer <calestyo@scientia.net> Reviewed-by: Christoph
Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen
<martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

scsi: target/iscsi: Avoid iscsit_release_commands_from_conn() deadlock
commit 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 upstream.
When using SCSI passthrough in combination with the iSCSI target driver 
then cmd->t_state_lock may be obtained from interrupt context. Hence,
all code that obtains cmd->t_state_lock from thread context must disable 
interrupts first. This patch avoids that lockdep reports the following:
WARNING: inconsistent lock state 4.18.0-dbg+ #1 Not tainted
-------------------------------- inconsistent {HARDIRQ-ON-W} ->
{IN-HARDIRQ-W} usage. iscsi_ttx/1800 [HC1[1]:SC0[2]:HE0:SE0] takes: 
000000006e7b0ceb (&(&cmd->t_state_lock)->rlock){?...}, at:
target_complete_cmd+0x47/0x2c0 [target_core_mod]
{HARDIRQ-ON-W} state was registered at:
lock_acquire+0xd2/0x260
_raw_spin_lock+0x32/0x50
iscsit_close_connection+0x97e/0x1020 [iscsi_target_mod]
iscsit_take_action_for_connection_exit+0x108/0x200 [iscsi_target_mod]
iscsi_target_rx_thread+0x180/0x190 [iscsi_target_mod]
kthread+0x1cf/0x1f0
ret_from_fork+0x24/0x30 irq event stamp: 1281 hardirqs last  enabled at
(1279): [<ffffffff970ade79>] __local_bh_enable_ip+0xa9/0x160 hardirqs
last disabled at (1281): [<ffffffff97a008a5>] interrupt_entry+0xb5/0xd0 
softirqs last  enabled at (1278): [<ffffffff977cd9a1>]
lock_sock_nested+0x51/0xc0 softirqs last disabled at (1280):
[<ffffffffc07a6e04>] ip6_finish_output2+0x124/0xe40 [ipv6]
other info that might help us debug this: Possible unsafe locking
scenario:
      CPU0
     ----
lock(&(&cmd->t_state_lock)->rlock);
<Interrupt>
  lock(&(&cmd->t_state_lock)->rlock);

scsi: qla2xxx: Fix LUN discovery if loop id is not assigned yet by
firmware
commit ec322937a7f152d68755dc8316523bf6f831b48f upstream.
This patch fixes LUN discovery when loop ID is not yet assigned by the 
firmware during driver load/sg_reset operations. Driver will now search
for new loop id before retrying login.
Fixes: 48acad099074 ("scsi: qla2xxx: Fix N2N link re-connect") Cc:
stable@vger.kernel.org #4.19 Signed-off-by: Himanshu Madhani
<hmadhani@marvell.com> Signed-off-by: Martin K. Petersen
<martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

scsi: qla2xxx: Avoid PCI IRQ affinity mapping when multiqueue is not
supported
commit f3e026951771bceb17319a4d0d6121ca58746c88 upstream.
This patch fixes warning seen when BLK-MQ is enabled and hardware does
not support MQ. This will result into driver requesting MSIx vectors
which are equal or less than pre_desc via PCI IRQ Affinity
infrastructure.
    [   19.746300] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel
HBA Driver: 10.00.00.12-k.
   [   19.746599] qla2xxx [0000:02:00.0]-001d: : Found an ISP2432 irq 18
iobase 0x(____ptrval____).
   [   20.203186] ------------[ cut here ]------------
   [   20.203306] WARNING: CPU: 8 PID: 268 at drivers/pci/msi.c:1273
pci_irq_get_affinity+0xf4/0x120
   [   20.203481] Modules linked in: tg3 ptp qla2xxx(+) pps_core sg
libphy scsi_transport_fc flash loop autofs4
   [   20.203700] CPU: 8 PID: 268 Comm: systemd-udevd Not tainted
5.0.0-rc5-00358-gdf3865f #113
   [   20.203830] Call Trace:
   [   20.203933]  [0000000000461bb0] __warn+0xb0/0xe0
   [   20.204090]  [00000000006c8f34] pci_irq_get_affinity+0xf4/0x120
   [   20.204219]  [000000000068c764] blk_mq_pci_map_queues+0x24/0x120
   [   20.204396]  [00000000007162f4] scsi_map_queues+0x14/0x40
   [   20.204626]  [0000000000673654] blk_mq_update_queue_map+0x94/0xe0
   [   20.204698]  [0000000000676ce0] blk_mq_alloc_tag_set+0x120/0x300
   [   20.204869]  [000000000071077c] scsi_add_host_with_dma+0x7c/0x300
   [   20.205419]  [00000000100ead54] qla2x00_probe_one+0x19d4/0x2640
[qla2xxx]
   [   20.205621]  [00000000006b3c88] pci_device_probe+0xc8/0x160
   [   20.205697]  [0000000000701c0c] really_probe+0x1ac/0x2e0
   [   20.205770]  [0000000000701f90] driver_probe_device+0x50/0x100
   [   20.205843]  [0000000000702134] __driver_attach+0xf4/0x120
   [   20.205913]  [0000000000700644] bus_for_each_dev+0x44/0x80
   [   20.206081]  [0000000000700c98] bus_add_driver+0x198/0x220
   [   20.206300]  [0000000000702950] driver_register+0x70/0x120
   [   20.206582]  [0000000010248224] qla2x00_module_init+0x224/0x284
[qla2xxx]
   [   20.206857] ---[ end trace b1de7a3f79fab2c2 ]---
The fix is to check if the hardware does not have Multi Queue
capabiltiy, use pci_alloc_irq_vectors() call instead of
pci_alloc_irq_affinity().
Fixes: f664a3cc17b7d ("scsi: kill off the legacy IO path") Cc:
stable@vger.kernel.org #4.19 Signed-off-by: Giridhar Malavali
<gmalavali@marvell.com> Signed-off-by: Himanshu Madhani
<hmadhani@marvell.com> Signed-off-by: Martin K. Petersen
<martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

scsi: qla2xxx: Use complete switch scan for RSCN events
commit 1560bafdff9ed54857ac3a03c4c8d8f10d791ba6 upstream.
This patch removes unnecessary code to handle RSCN, instead performs
full scan everytime driver receives RSCN
Fixes: d4f7a16aeca6f ("scsi: qla2xxx: Remove ASYNC GIDPN switch
command") Cc: stable@vger.kernel.org #4.19 Signed-off-by: Quinn Tran
<qtran@marvell.com> Signed-off-by: Himanshu Madhani
<hmadhani@marvell.com> Signed-off-by: Martin K. Petersen
<martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

fs/devpts: always delete dcache dentry-s in dput()
commit 73052b0daee0b750b39af18460dfec683e4f5887 upstream.
d_delete only unhashes an entry if it is reached with 
dentry->d_lockref.count != 1. Prior to commit 8ead9dd54716 ("devpts: 
more pty driver interface cleanups"), d_delete was called on a dentry 
from devpts_pty_kill with two references held, which would trigger the 
unhashing, and the subsequent dputs would release it.
Commit 8ead9dd54716 reworked devpts_pty_kill to stop acquiring the
second reference from d_find_alias, and the d_delete call left the
dentries still on the hashed list without actually ever being dropped
from dcache before explicit cleanup. This causes the number of negative
dentries for devpts to pile up, and an `ls /dev/pts` invocation can take
seconds to return.
Provide always_delete_dentry() from simple_dentry_operations as
.d_delete for devpts, to make the dentry be dropped from dcache.
Without this cleanup, the number of dentries in /dev/pts/ can be grown 
arbitrarily as:
`python -c 'import pty; pty.spawn(["ls", "/dev/pts"])'`
A systemtap probe on dcache_readdir to count d_subdirs shows this count 
to increase with each pty spawn invocation above:
probe kernel.function("dcache_readdir") {
   subdirs = &@cast($file->f_path->dentry, "dentry")->d_subdirs;
   p = subdirs;
   p = @cast(p, "list_head")->next;
   i = 0
   while (p != subdirs) {
     p = @cast(p, "list_head")->next;
     i = i+1;
   }
   printf("number of dentries: %d\n", i);
}
Fixes: 8ead9dd54716 ("devpts: more pty driver interface cleanups") 
Signed-off-by: Varad Gautam <vrd@amazon.de> Reported-by: Zheng Wang
<wanz@amazon.de> Reported-by: Brandon Schwartz <bsschwar@amazon.de> 
Root-caused-by: Maximilian Heyne <mheyne@amazon.de> Root-caused-by:
Nicolas Pernas Maradei <npernas@amazon.de> CC: David Woodhouse
<dwmw@amazon.co.uk> CC: Maximilian Heyne <mheyne@amazon.de> CC: Stefan
Nuernberger <snu@amazon.de> CC: Amit Shah <aams@amazon.de> CC: Linus
Torvalds <torvalds@linux-foundation.org> CC: Greg Kroah-Hartman
<gregkh@linuxfoundation.org> CC: Al Viro <viro@ZenIV.linux.org.uk> CC:
Christian Brauner <christian.brauner@ubuntu.com> CC: Eric W. Biederman
<ebiederm@xmission.com> CC: Matthew Wilcox <willy@infradead.org> CC:
Eric Biggers <ebiggers@google.com> CC: <stable@vger.kernel.org> # 4.9+ 
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

splice: don't merge into linked buffers
commit a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 upstream.
Before this patch, it was possible for two pipes to affect each other
after data had been transferred between them with tee():
============
$ cat tee_test.c
int main(void) {
 int pipe_a[2];
 if (pipe(pipe_a)) err(1, "pipe");
 int pipe_b[2];
 if (pipe(pipe_b)) err(1, "pipe");
 if (write(pipe_a[1], "abcd", 4) != 4) err(1, "write");
 if (tee(pipe_a[0], pipe_b[1], 2, 0) != 2) err(1, "tee");
 if (write(pipe_b[1], "xx", 2) != 2) err(1, "write");
  char buf[5];
 if (read(pipe_a[0], buf, 4) != 4) err(1, "read");
 buf[4] = 0;
 printf("got back: '%s'\n", buf);
}
$ gcc -o tee_test tee_test.c
$ ./tee_test got back: 'abxx'
$
============
As suggested by Al Viro, fix it by creating a separate type for 
non-mergeable pipe buffers, then changing the types of buffers in 
splice_pipe_to_pipe() and link_pipe().
Cc: <stable@vger.kernel.org> Fixes: 7c77f0b3f920 ("splice: implement
pipe to pipe splicing") Fixes: 70524490ee2e ("[PATCH] splice: add
support for sys_tee()") Suggested-by: Al Viro <viro@zeniv.linux.org.uk> 
Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Al Viro
<viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

ovl: During copy up, first copy up data and then xattrs
commit 5f32879ea35523b9842bdbdc0065e13635caada2 upstream.
If a file with capability set (and hence security.capability xattr) is 
written kernel clears security.capability xattr. For overlay, during
file copy up if xattrs are copied up first and then data is, copied up.
This means data copy up will result in clearing of security.capability
xattr file on lower has. And this can result into surprises. If a lower
file has CAP_SETUID, then it should not be cleared over copy up (if
nothing was actually written to file).
This also creates problems with chown logic where it first copies up
file and then tries to clear setuid bit. But by that time
security.capability xattr is already gone (due to data copy up), and
caller gets -ENODATA. This has been reported by Giuseppe here.
https://github.com/containers/libpod/issues/2015#issuecomment-447824842
Fix this by copying up data first and then metadta. This is a regression 
which has been introduced by my commit as part of metadata only copy up 
patches.
TODO: There will be some corner cases where a file is copied up metadata 
only and later data copy up happens and that will clear
security.capability xattr. Something needs to be done about that too.
Fixes: bd64e57586d3 ("ovl: During copy up, first copy up metadata and
then data") Cc: <stable@vger.kernel.org> # v4.19+ Reported-by: Giuseppe
Scrivano <gscrivan@redhat.com> Signed-off-by: Vivek Goyal
<vgoyal@redhat.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ovl: Do not lose security.capability xattr over metadata file copy-up
commit 993a0b2aec52754f0897b1dab4c453be8217cae5 upstream.
If a file has been copied up metadata only, and later data is copied up, 
upper loses any security.capability xattr it has (underlying filesystem 
clears it as upon file write).
From a user's point of view, this is just a file copy-up and that should 
not result in losing security.capability xattr.  Hence, before data copy 
up, save security.capability xattr (if any) and restore it on upper
after data copy up is complete.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Reviewed-by: Amir
Goldstein <amir73il@gmail.com> Fixes: 0c2888749363 ("ovl: A new xattr
OVL_XATTR_METACOPY for file on upper") Cc: <stable@vger.kernel.org> #
v4.19+ Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

m68k: Add -ffreestanding to CFLAGS
commit 28713169d879b67be2ef2f84dcf54905de238294 upstream.
This patch fixes a build failure when using GCC 8.1:
/usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock': 
block/partitions/ldm.c:153: undefined reference to `strcmp'
This is caused by a new optimization which effectively replaces a 
strncmp() call with a strcmp() call. This affects a number of strncmp() 
call sites in the kernel.
The entire class of optimizations is avoided with -fno-builtin, which 
gets enabled by -ffreestanding. This may avoid possible future build 
failures in case new optimizations appear in future compilers.
I haven't done any performance measurements with this patch but I did 
count the function calls in a defconfig build. For example, there are
now 23 more sprintf() calls and 39 fewer strcpy() calls. The effect on
the other libc functions is smaller.
If this harms performance we can tackle that regression by optimizing 
the call sites, ideally using semantic patches. That way, clang and ICC 
builds might benfit too.
Cc: stable@vger.kernel.org Reference:
https://marc.info/?l=linux-m68k&m=154514816222244&w=2 Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Geert
Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

Btrfs: setup a nofs context for memory allocation at btrfs_create_tree()
commit b89f6d1fcb30a8cbdc18ce00c7d93792076af453 upstream.
We are holding a transaction handle when creating a tree, therefore we
can not allocate the root using GFP_KERNEL, as we could deadlock if
reclaim is triggered by the allocation, therefore setup a nofs context.
Fixes: 74e4d82757f74 ("btrfs: let callers of btrfs_alloc_root pass gfp
flags") CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Nikolay Borisov
<nborisov@suse.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> 
Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba
<dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

Btrfs: setup a nofs context for memory allocation at __btrfs_set_acl
commit a0873490660246db587849a9e172f2b7b21fa88a upstream.
We are holding a transaction handle when setting an acl, therefore we
can not allocate the xattr value buffer using GFP_KERNEL, as we could
deadlock if reclaim is triggered by the allocation, therefore setup a
nofs context.
Fixes: 39a27ec1004e8 ("btrfs: use GFP_KERNEL for xattr and acl
allocations") CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Nikolay
Borisov <nborisov@suse.com> Signed-off-by: Filipe Manana
<fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> 
Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: scrub: fix circular locking dependency warning
commit 1cec3f27168d7835ff3d23ab371cd548440131bb upstream.
This fixes a longstanding lockdep warning triggered by 
fstests/btrfs/011.
Circular locking dependency check reports warning[1], that's because the 
btrfs_scrub_dev() calls the stack #0 below with, the fs_info::scrub_lock 
held. The test case leading to this warning:
  $ mkfs.btrfs -f /dev/sdb
 $ mount /dev/sdb /btrfs
 $ btrfs scrub start -B /btrfs
In fact we have fs_info::scrub_workers_refcnt to track if the init and
destroy of the scrub workers are needed. So once we have incremented and
decremented the fs_info::scrub_workers_refcnt value in the thread, its
ok to drop the scrub_lock, and then actually do the
btrfs_destroy_workqueue() part. So this patch drops the scrub_lock
before calling btrfs_destroy_workqueue().
  [359.258534] ======================================================
 [359.260305] WARNING: possible circular locking dependency detected
 [359.261938] 5.0.0-rc6-default #461 Not tainted
 [359.263135] ------------------------------------------------------
 [359.264672] btrfs/20975 is trying to acquire lock:
 [359.265927] 00000000d4d32bea ((wq_completion)"%s-%s""btrfs",
name){+.+.}, at: flush_workqueue+0x87/0x540
 [359.268416]
 [359.268416] but task is already holding lock:
 [359.270061] 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at:
btrfs_scrub_dev+0x322/0x590 [btrfs]
 [359.272418]
 [359.272418] which lock already depends on the new lock.
 [359.272418]
 [359.274692]
 [359.274692] the existing dependency chain (in reverse order) is:
 [359.276671]
 [359.276671] -> #3 (&fs_info->scrub_lock){+.+.}:
 [359.278187]        __mutex_lock+0x86/0x9c0
 [359.279086]        btrfs_scrub_pause+0x31/0x100 [btrfs]
 [359.280421]        btrfs_commit_transaction+0x1e4/0x9e0 [btrfs]
 [359.281931]        close_ctree+0x30b/0x350 [btrfs]
 [359.283208]        generic_shutdown_super+0x64/0x100
 [359.284516]        kill_anon_super+0x14/0x30
 [359.285658]        btrfs_kill_super+0x12/0xa0 [btrfs]
 [359.286964]        deactivate_locked_super+0x29/0x60
 [359.288242]        cleanup_mnt+0x3b/0x70
 [359.289310]        task_work_run+0x98/0xc0
 [359.290428]        exit_to_usermode_loop+0x83/0x90
 [359.291445]        do_syscall_64+0x15b/0x180
 [359.292598]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
 [359.294011]
 [359.294011] -> #2 (sb_internal#2){.+.+}:
 [359.295432]        __sb_start_write+0x113/0x1d0
 [359.296394]        start_transaction+0x369/0x500 [btrfs]
 [359.297471]        btrfs_finish_ordered_io+0x2aa/0x7c0 [btrfs]
 [359.298629]        normal_work_helper+0xcd/0x530 [btrfs]
 [359.299698]        process_one_work+0x246/0x610
 [359.300898]        worker_thread+0x3c/0x390
 [359.302020]        kthread+0x116/0x130
 [359.303053]        ret_from_fork+0x24/0x30
 [359.304152]
 [359.304152] -> #1 ((work_completion)(&work->normal_work)){+.+.}:
 [359.306100]        process_one_work+0x21f/0x610
 [359.307302]        worker_thread+0x3c/0x390
 [359.308465]        kthread+0x116/0x130
 [359.309357]        ret_from_fork+0x24/0x30
 [359.310229]
 [359.310229] -> #0 ((wq_completion)"%s-%s""btrfs", name){+.+.}:
 [359.311812]        lock_acquire+0x90/0x180
 [359.312929]        flush_workqueue+0xaa/0x540
 [359.313845]        drain_workqueue+0xa1/0x180
 [359.314761]        destroy_workqueue+0x17/0x240
 [359.315754]        btrfs_destroy_workqueue+0x57/0x200 [btrfs]
 [359.317245]        scrub_workers_put+0x2c/0x60 [btrfs]
 [359.318585]        btrfs_scrub_dev+0x336/0x590 [btrfs]
 [359.319944]        btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb
[btrfs]
 [359.321622]        btrfs_ioctl+0x28a4/0x2e40 [btrfs]
 [359.322908]        do_vfs_ioctl+0xa2/0x6d0
 [359.324021]        ksys_ioctl+0x3a/0x70
 [359.325066]        __x64_sys_ioctl+0x16/0x20
 [359.326236]        do_syscall_64+0x54/0x180
 [359.327379]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
 [359.328772]
 [359.328772] other info that might help us debug this:
 [359.328772]
 [359.330990] Chain exists of:
 [359.330990]   (wq_completion)"%s-%s""btrfs", name --> sb_internal#2
--> &fs_info->scrub_lock
 [359.330990]
 [359.334376]  Possible unsafe locking scenario:
 [359.334376]
 [359.336020]        CPU0                    CPU1
 [359.337070]        ----                    ----
 [359.337821]   lock(&fs_info->scrub_lock);
 [359.338506]                                lock(sb_internal#2);
 [359.339506]                                lock(&fs_info->scrub_lock);
 [359.341461]   lock((wq_completion)"%s-%s""btrfs", name);
 [359.342437]
 [359.342437]  *** DEADLOCK ***
 [359.342437]
 [359.343745] 1 lock held by btrfs/20975:
 [359.344788]  #0: 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at:
btrfs_scrub_dev+0x322/0x590 [btrfs]
 [359.346778]
 [359.346778] stack backtrace:
 [359.347897] CPU: 0 PID: 20975 Comm: btrfs Not tainted
5.0.0-rc6-default #461
 [359.348983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014
 [359.350501] Call Trace:
 [359.350931]  dump_stack+0x67/0x90
 [359.351676]  print_circular_bug.isra.37.cold.56+0x15c/0x195
 [359.353569]  check_prev_add.constprop.44+0x4f9/0x750
 [359.354849]  ? check_prev_add.constprop.44+0x286/0x750
 [359.356505]  __lock_acquire+0xb84/0xf10
 [359.357505]  lock_acquire+0x90/0x180
 [359.358271]  ? flush_workqueue+0x87/0x540
 [359.359098]  flush_workqueue+0xaa/0x540
 [359.359912]  ? flush_workqueue+0x87/0x540
 [359.360740]  ? drain_workqueue+0x1e/0x180
 [359.361565]  ? drain_workqueue+0xa1/0x180
 [359.362391]  drain_workqueue+0xa1/0x180
 [359.363193]  destroy_workqueue+0x17/0x240
 [359.364539]  btrfs_destroy_workqueue+0x57/0x200 [btrfs]
 [359.365673]  scrub_workers_put+0x2c/0x60 [btrfs]
 [359.366618]  btrfs_scrub_dev+0x336/0x590 [btrfs]
 [359.367594]  ? start_transaction+0xa1/0x500 [btrfs]
 [359.368679]  btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs]
 [359.369545]  btrfs_ioctl+0x28a4/0x2e40 [btrfs]
 [359.370186]  ? __lock_acquire+0x263/0xf10
 [359.370777]  ? kvm_clock_read+0x14/0x30
 [359.371392]  ? kvm_sched_clock_read+0x5/0x10
 [359.372248]  ? sched_clock+0x5/0x10
 [359.372786]  ? sched_clock_cpu+0xc/0xc0
 [359.373662]  ? do_vfs_ioctl+0xa2/0x6d0
 [359.374552]  do_vfs_ioctl+0xa2/0x6d0
 [359.375378]  ? do_sigaction+0xff/0x250
 [359.376233]  ksys_ioctl+0x3a/0x70
 [359.376954]  __x64_sys_ioctl+0x16/0x20
 [359.377772]  do_syscall_64+0x54/0x180
 [359.378841]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
 [359.380422] RIP: 0033:0x7f5429296a97
Backporting to older kernels: scrub_nocow_workers must be freed the same 
way as the others.
CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Anand Jain
<anand.jain@oracle.com>
[ update changelog ] Reviewed-by: David Sterba <dsterba@suse.com> 
Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: drop the lock on error in btrfs_dev_replace_cancel
commit 669e859b5ea7c6f4fce0149d3907c64e550c294b upstream.
We should drop the lock on this error path.  This has been found by a 
static tool.
The lock needs to be released, it's there to protect access to the 
dev_replace members and is not supposed to be left locked. The value of 
state that's being switched would need to be artifically changed to an 
invalid value so the default: branch is taken.
Fixes: d189dd70e255 ("btrfs: fix use-after-free due to race between
replace start and cancel") CC: stable@vger.kernel.org # 5.0+ 
Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Dan
Carpenter <dan.carpenter@oracle.com> Reviewed-by: David Sterba
<dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: ensure that a DUP or RAID1 block group has exactly two stripes
commit 349ae63f40638a28c6fce52e8447c2d14b84cc0c upstream.
We recently had a customer issue with a corrupted filesystem. When 
trying to mount this image btrfs panicked with a division by zero in 
calc_stripe_length().
The corrupt chunk had a 'num_stripes' value of 1. calc_stripe_length() 
takes this value and divides it by the number of copies the RAID profile 
is expected to have to calculate the amount of data stripes. As a DUP 
profile is expected to have 2 copies this division resulted in 1/2 = 0. 
Later then the 'data_stripes' variable is used as a divisor in the 
stripe length calculation which results in a division by 0 and thus a 
kernel panic.
When encountering a filesystem with a DUP block group and a
'num_stripes' value unequal to 2, refuse mounting as the image is 
corrupted and will lead to unexpected behaviour.
Code inspection showed a RAID1 block group has the same issues.
Fixes: e06cd3dd7cea ("Btrfs: add validadtion checks for chunk loading") 
CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Qu Wenruo <wqu@suse.com> 
Reviewed-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Johannes
Thumshirn <jthumshirn@suse.de> Reviewed-by: David Sterba
<dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: init csum_list before possible free
commit e49be14b8d80e23bb7c53d78c21717a474ade76b upstream.
The scrub_ctx csum_list member must be initialized before scrub_free_ctx 
is called. If the csum_list is not initialized beforehand, the 
list_empty call in scrub_free_csums will result in a null deref if the 
allocation fails in the for loop.
Fixes: a2de733c78fa ("btrfs: scrub") CC: stable@vger.kernel.org # 3.0+ 
Reviewed-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Dan
Robertson <dan@dlrobertson.com> Reviewed-by: David Sterba
<dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Btrfs: fix corruption reading shared and compressed extents after hole
punching
commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
In the past we had data corruption when reading compressed extents that 
are shared within the same file and they are consecutive, this got fixed 
by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and 
shared extents") and by commit 808f80b46790f ("Btrfs: update fix for
read corruption of compressed and shared extents"). However there was a
case that was missing in those fixes, which is when the shared and
compressed extents are referenced with a non-zero offset. The following
shell script creates a reproducer for this issue:
  #!/bin/bash
  mkfs.btrfs -f /dev/sdc &> /dev/null
 mount -o compress /dev/sdc /mnt/sdc
  # Create a file with 3 consecutive compressed extents, each has an
 # uncompressed size of 128Kb and a compressed size of 4Kb.
 for ((i = 1; i <= 3; i++)); do
     head -c 4096 /dev/zero
     for ((j = 1; j <= 31; j++)); do
         head -c 4096 /dev/zero | tr '\0' "\377"
     done
 done > /mnt/sdc/foobar
 sync
  echo "Digest after file creation:   $(md5sum /mnt/sdc/foobar)"
  # Clone the first extent into offsets 128K and 256K.
 xfs_io -c "reflink /mnt/sdc/foobar 0 128K 128K" /mnt/sdc/foobar
 xfs_io -c "reflink /mnt/sdc/foobar 0 256K 128K" /mnt/sdc/foobar
 sync
  echo "Digest after cloning:         $(md5sum /mnt/sdc/foobar)"
  # Punch holes into the regions that are already full of zeroes.
 xfs_io -c "fpunch 0 4K" /mnt/sdc/foobar
 xfs_io -c "fpunch 128K 4K" /mnt/sdc/foobar
 xfs_io -c "fpunch 256K 4K" /mnt/sdc/foobar
 sync
  echo "Digest after hole punching:   $(md5sum /mnt/sdc/foobar)"
  echo "Dropping page cache..."
 sysctl -q vm.drop_caches=1
 echo "Digest after hole punching:   $(md5sum /mnt/sdc/foobar)"
  umount /dev/sdc
When running the script we get the following output:
  Digest after file creation:   5a0888d80d7ab1fd31c229f83a3bbcc8 
/mnt/sdc/foobar
 linked 131072/131072 bytes at offset 131072
 128 KiB, 1 ops; 0.0033 sec (36.960 MiB/sec and 295.6830 ops/sec)
 linked 131072/131072 bytes at offset 262144
 128 KiB, 1 ops; 0.0015 sec (78.567 MiB/sec and 628.5355 ops/sec)
 Digest after cloning:         5a0888d80d7ab1fd31c229f83a3bbcc8 
/mnt/sdc/foobar
 Digest after hole punching:   5a0888d80d7ab1fd31c229f83a3bbcc8 
/mnt/sdc/foobar
 Dropping page cache...
 Digest after hole punching:   fba694ae8664ed0c2e9ff8937e7f1484 
/mnt/sdc/foobar
This happens because after reading all the pages of the extent in the 
range from 128K to 256K for example, we read the hole at offset 256K and
then when reading the page at offset 260K we don't submit the existing
bio, which is responsible for filling all the page in the range 128K to
256K only, therefore adding the pages from range 260K to 384K to the
existing bio and submitting it after iterating over the entire range.
Once the bio completes, the uncompressed data fills only the pages in
the range 128K to 256K because there's no more data read from disk,
leaving the pages in the range 260K to 384K unfilled. It is just a
slightly different variant of what was solved by commit 005efedf2c7d0
("Btrfs: fix read corruption of compressed and shared extents").
Fix this by forcing a bio submit, during readpages(), whenever we find a 
compressed extent map for a page that is different from the extent map 
for the previous page or has a different starting offset (in case it's 
the same compressed extent), instead of the extent map's original start 
offset.
A test case for fstests follows soon.
Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org> Fixes:
808f80b46790f ("Btrfs: update fix for read corruption of compressed and
shared extents") Fixes: 005efedf2c7d0 ("Btrfs: fix read corruption of
compressed and shared extents") Cc: stable@vger.kernel.org # 4.3+ 
Tested-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org> Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba
<dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

Btrfs: fix deadlock between clone/dedupe and rename
commit 4ea748e1d2c9f8a27332b949e8210dbbf392987e upstream.
Reflinking (clone/dedupe) and rename are operations that operate on two 
inodes and therefore need to lock them in the same order to avoid ABBA 
deadlocks. It happens that Btrfs' reflink implementation always locked 
them in a different order from VFS's lock_two_nondirectories() helper, 
which is used by the rename code in VFS, resulting in ABBA type
deadlocks.
Btrfs' locking order:
  static void btrfs_double_inode_lock(struct inode *inode1, struct inode
*inode2)
 {
        if (inode1 < inode2)
               swap(inode1, inode2);
         inode_lock_nested(inode1, I_MUTEX_PARENT);
        inode_lock_nested(inode2, I_MUTEX_CHILD);
 }
VFS's locking order:
  void lock_two_nondirectories(struct inode *inode1, struct inode
*inode2)
 {
       if (inode1 > inode2)
               swap(inode1, inode2);
        if (inode1 && !S_ISDIR(inode1->i_mode))
               inode_lock(inode1);
       if (inode2 && !S_ISDIR(inode2->i_mode) && inode2 != inode1)
               inode_lock_nested(inode2, I_MUTEX_NONDIR2);
}
Fix this by killing the btrfs helper function that does the double inode 
locking and replace it with VFS's helper lock_two_nondirectories().
Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org> Fixes:
416161db9b63e3 ("btrfs: offline dedupe") CC: stable@vger.kernel.org #
4.4+ Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

soc: qcom: rpmh: Avoid accessing freed memory from batch API
commit baef1c90aac7e5bf13f0360a3b334825a23d31a1 upstream.
Using the batch API from the interconnect driver sometimes leads to a 
KASAN error due to an access to freed memory. This is easier to trigger 
with threadirqs on the kernel commandline.
 BUG: KASAN: use-after-free in rpmh_tx_done+0x114/0x12c
Read of size 1 at addr fffffff51414ad84 by task irq/110-apps_rs/57
 CPU: 0 PID: 57 Comm: irq/110-apps_rs Tainted: G        W        
4.19.10 #72
Call trace:
 dump_backtrace+0x0/0x2f8
 show_stack+0x20/0x2c
 __dump_stack+0x20/0x28
 dump_stack+0xcc/0x10c
 print_address_description+0x74/0x240
 kasan_report+0x250/0x26c
 __asan_report_load1_noabort+0x20/0x2c
 rpmh_tx_done+0x114/0x12c
 tcs_tx_done+0x450/0x768
 irq_forced_thread_fn+0x58/0x9c
 irq_thread+0x120/0x1dc
 kthread+0x248/0x260
 ret_from_fork+0x10/0x18
 Allocated by task 385:
 kasan_kmalloc+0xac/0x148
 __kmalloc+0x170/0x1e4
 rpmh_write_batch+0x174/0x540
 qcom_icc_set+0x8dc/0x9ac
 icc_set+0x288/0x2e8
 a6xx_gmu_stop+0x320/0x3c0
 a6xx_pm_suspend+0x108/0x124
 adreno_suspend+0x50/0x60
 pm_generic_runtime_suspend+0x60/0x78
 __rpm_callback+0x214/0x32c
 rpm_callback+0x54/0x184
 rpm_suspend+0x3f8/0xa90
 pm_runtime_work+0xb4/0x178
 process_one_work+0x544/0xbc0
 worker_thread+0x514/0x7d0
 kthread+0x248/0x260
 ret_from_fork+0x10/0x18
 Freed by task 385:
 __kasan_slab_free+0x12c/0x1e0
 kasan_slab_free+0x10/0x1c
 kfree+0x134/0x588
 rpmh_write_batch+0x49c/0x540
 qcom_icc_set+0x8dc/0x9ac
 icc_set+0x288/0x2e8
 a6xx_gmu_stop+0x320/0x3c0
 a6xx_pm_suspend+0x108/0x124
 adreno_suspend+0x50/0x60
cr50_spi spi5.0: SPI transfer timed out
 pm_generic_runtime_suspend+0x60/0x78
 __rpm_callback+0x214/0x32c
 rpm_callback+0x54/0x184
 rpm_suspend+0x3f8/0xa90
 pm_runtime_work+0xb4/0x178
 process_one_work+0x544/0xbc0
 worker_thread+0x514/0x7d0
 kthread+0x248/0x260
 ret_from_fork+0x10/0x18
 The buggy address belongs to the object at fffffff51414ac80
 which belongs to the cache kmalloc-512 of size 512
The buggy address is located 260 bytes inside of
 512-byte region [fffffff51414ac80, fffffff51414ae80)
The buggy address belongs to the page:
page:ffffffbfd4505200 count:1 mapcount:0 mapping:fffffff51e00c680
index:0x0 compound_mapcount: 0
flags: 0x4000000000008100(slab|head)
raw: 4000000000008100 ffffffbfd4529008 ffffffbfd44f9208 fffffff51e00c680
raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
 Memory state around the buggy address:
 fffffff51414ac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 fffffff51414ad00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>fffffff51414ad80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                   ^
 fffffff51414ae00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 fffffff51414ae80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
The batch API sets the same completion for each rpmh message that's sent 
and then loops through all the messages and waits for that single 
completion declared on the stack to be completed before returning from 
the function and freeing the message structures. Unfortunately, some 
messages may still be in process and 'stuck' in the TCS. At some later 
point, the tcs_tx_done() interrupt will run and try to process messages 
that have already been freed at the end of rpmh_write_batch(). This will 
in turn access the 'needs_free' member of the rpmh_request structure and 
cause KASAN to complain. Furthermore, if there's a message that's 
completed in rpmh_tx_done() and freed immediately after the complete() 
call is made we'll be racing with potentially freed memory when 
accessing the 'needs_free' member:
	CPU0                         CPU1
----                         ----
rpmh_tx_done()
 complete(&compl)
                             wait_for_completion(&compl)
                             kfree(rpm_msg)
 if (rpm_msg->needs_free)
 <KASAN warning splat>
Let's fix this by allocating a chunk of completions for each message and 
waiting for all of them to be completed before returning from the batch 
API. Alternatively, we could wait for the last message in the batch, but 
that may be a more complicated change because it looks like 
tcs_tx_done() just iterates through the indices of the queue and 
completes each message instead of tracking the last inserted message and 
completing that first.
Fixes: c8790cb6da58 ("drivers: qcom: rpmh: add support for batch RPMH
request") Cc: Lina Iyer <ilina@codeaurora.org> Cc: "Raju P.L.S.S.S.N"
<rplsssn@codeaurora.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc:
Evan Green <evgreen@chromium.org> Cc: stable@vger.kernel.org 
Reviewed-by: Lina Iyer <ilina@codeaurora.org> Reviewed-by: Evan Green
<evgreen@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> 
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> 
Signed-off-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

libertas_tf: don't set URB_ZERO_PACKET on IN USB transfer
commit 607076a904c435f2677fadaadd4af546279db68b upstream.
It doesn't make sense and the USB core warns on each submit of such URB,
easily flooding the message buffer with tracebacks.
Analogous issue was fixed in regular libertas driver in commit
6528d8804780
("libertas: don't set URB_ZERO_PACKET on IN USB transfer").
Cc: stable@vger.kernel.org Signed-off-by: Lubomir Rintel
<lkundrak@v3.sk> Reviewed-by: Steve deRosier <derosier@cal-sierra.com> 
Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

irqchip/gic-v3-its: Avoid parsing _indirect_ twice for Device table
commit 8d565748b6035eeda18895c213396a4c9fac6a4c upstream.
In current logic, its_parse_indirect_baser() will be invoked twice when
allocating Device tables. Add a *break* to omit the unnecessary and
annoying (might be ...) invoking.
Fixes: 32bd44dc19de ("irqchip/gic-v3-its: Fix the incorrect parsing of
VCPU table size") Cc: stable@vger.kernel.org Signed-off-by: Zenghui Yu
<yuzenghui@huawei.com> Signed-off-by: Marc Zyngier
<marc.zyngier@arm.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

irqchip/brcmstb-l2: Use _irqsave locking variants in non-interrupt code
commit 33517881ede742107f416533b8c3e4abc56763da upstream.
Using the irq_gc_lock/irq_gc_unlock functions in the suspend and resume
functions creates the opportunity for a deadlock during suspend, resume,
and shutdown. Using the irq_gc_lock_irqsave/ irq_gc_unlock_irqrestore
variants prevents this possible deadlock.
Cc: stable@vger.kernel.org Fixes: 7f646e92766e2 ("irqchip: brcmstb-l2:
Add Broadcom Set Top Box Level-2 interrupt controller") Signed-off-by:
Doug Berger <opendmb@gmail.com> Signed-off-by: Florian Fainelli
<f.fainelli@gmail.com>
[maz: tidied up $SUBJECT] Signed-off-by: Marc Zyngier
<marc.zyngier@arm.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

x86/kprobes: Prohibit probing on optprobe template code
commit 0192e6535ebe9af68614198ced4fd6d37b778ebf upstream.
Prohibit probing on optprobe template code, since it is not a code but a
template instruction sequence. If we modify this template, copied
template must be broken.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Cc: Alexander
Shishkin <alexander.shishkin@linux.intel.com> Cc: Andrea Righi
<righi.andrea@gmail.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> 
Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds
<torvalds@linux-foundation.org> Cc: Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> Cc: Peter Zijlstra
<peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc:
Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Fixes:
9326638cbee2 ("kprobes, x86: Use NOKPROBE_SYMBOL() instead of __kprobes
annotation") Link:
http://lkml.kernel.org/r/154998787911.31052.15274376330136234452.stgit@devbox 
Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

cpufreq: kryo: Release OPP tables on module removal
commit 0334906c06967142c8805fbe88acf787f65d3d26 upstream.
Commit 5ad7346b4ae2 ("cpufreq: kryo: Add module remove and exit") made 
it possible to build the kryo cpufreq driver as a module, but it failed 
to release all the resources, i.e. OPP tables, when the module is 
unloaded.
This patch fixes it by releasing the OPP tables, by calling 
dev_pm_opp_put_supported_hw() for them, from the 
qcom_cpufreq_kryo_remove() routine. The array of pointers to the OPP 
tables is also allocated dynamically now in qcom_cpufreq_kryo_probe(), 
as the pointers will be required while releasing the resources.
Compile tested only.
Cc: 4.18+ <stable@vger.kernel.org> # v4.18+ Fixes: 5ad7346b4ae2
("cpufreq: kryo: Add module remove and exit") Reviewed-by: Georgi Djakov
<georgi.djakov@linaro.org> Signed-off-by: Viresh Kumar
<viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

cpufreq: tegra124: add missing of_node_put()
commit 446fae2bb5395f3028d8e3aae1508737e5a72ea1 upstream.
of_cpu_device_node_get() will increase the refcount of device_node, it
is necessary to call of_node_put() at the end to release the refcount.
Fixes: 9eb15dbbfa1a2 ("cpufreq: Add cpufreq driver for Tegra124") Cc:
<stable@vger.kernel.org> # 4.4+ Signed-off-by: Yangtao Li
<tiny.windzz@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> 
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cpufreq: pxa2xx: remove incorrect __init annotation
commit 9505b98ccddc454008ca7efff90044e3e857c827 upstream.
pxa_cpufreq_init_voltages() is marked __init but usually inlined into 
the non-__init pxa_cpufreq_init() function. When building with clang, it
can stay as a standalone function in a discarded section, and produce 
this warning:
WARNING: vmlinux.o(.text+0x616a00): Section mismatch in reference from
the function pxa_cpufreq_init() to the function
.init.text:pxa_cpufreq_init_voltages() The function pxa_cpufreq_init()
references the function __init pxa_cpufreq_init_voltages(). This is
often because pxa_cpufreq_init lacks a __init annotation or the
annotation of pxa_cpufreq_init_voltages is wrong.
Fixes: 50e77fcd790e ("ARM: pxa: remove __init from
cpufreq_driver->init()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Nathan
Chancellor <natechancellor@gmail.com> Acked-by: Robert Jarzmik
<robert.jarzmik@free.fr> Cc: All applicable <stable@vger.kernel.org> 
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix check of inode in swap_inode_boot_loader
commit 67a11611e1a5211f6569044fbf8150875764d1d0 upstream.
Before really do swap between inode and boot inode, something need to 
check to avoid invalid or not permitted operation, like does this inode 
has inline data. But the condition check should be protected by inode 
lock to avoid change while swapping. Also some other condition will not 
change between swapping, but there has no problem to do this under inode 
lock.
Signed-off-by: yangerkun <yangerkun@huawei.com> Signed-off-by: Theodore
Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: cleanup pagecache before swap i_data
commit a46c68a318b08f819047843abf349aeee5d10ac2 upstream.
While do swap, we should make sure there has no new dirty page since we 
should swap i_data between two inode: 1.We should lock i_mmap_sem with
write to avoid new pagecache from mmap read/write; 2.Change
filemap_flush to filemap_write_and_wait and move them to the space
protected by inode lock to avoid new pagecache from buffer read/write.
Signed-off-by: yangerkun <yangerkun@huawei.com> Signed-off-by: Theodore
Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

mm: hwpoison: fix thp split handing in soft_offline_in_use_page()
commit 46612b751c4941c5c0472ddf04027e877ae5990f upstream.
When soft_offline_in_use_page() runs on a thp tail page after pmd is 
split, we trigger the following VM_BUG_ON_PAGE():
  Memory failure: 0x3755ff: non anonymous thp
 __get_any_page: 0x3755ff: unknown zero refcount page type
2fffff80000000
 Soft offlining pfn 0x34d805 at process virtual address 0x20fff000
 page:ffffea000d360140 count:0 mapcount:0 mapping:0000000000000000
index:0x1
 flags: 0x2fffff80000000()
 raw: 002fffff80000000 ffffea000d360108 ffffea000d360188
0000000000000000
 raw: 0000000000000001 0000000000000000 00000000ffffffff
0000000000000000
 page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
 ------------[ cut here ]------------
 kernel BUG at ./include/linux/mm.h:519!
soft_offline_in_use_page() passed refcount and page lock from tail page 
to head page, which is not needed because we can pass any subpage to 
split_huge_page().
Naoya had fixed a similar issue in c3901e722b29 ("mm: hwpoison: fix thp 
split handling in memory_failure()").  But he missed fixing soft 
offline.
Link:
http://lkml.kernel.org/r/1551452476-24000-1-git-send-email-zhongjiang@huawei.com 
Fixes: 61f5d698cc97 ("mm: re-enable THP") Signed-off-by: zhongjiang
<zhongjiang@huawei.com> Acked-by: Naoya Horiguchi
<n-horiguchi@ah.jp.nec.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Hugh
Dickins <hughd@google.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> 
Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: <stable@vger.kernel.org>
[4.5+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm/vmalloc: fix size check for remap_vmalloc_range_partial()
commit 401592d2e095947344e10ec0623adbcd58934dd4 upstream.
When VM_NO_GUARD is not set area->size includes adjacent guard page, 
thus for correct size checking get_vm_area_size() should be used, but 
not area->size.
This fixes possible kernel oops when userspace tries to mmap an area on 
1 page bigger than was allocated by vmalloc_user() call: the size check 
inside remap_vmalloc_range_partial() accounts non-existing guard page 
also, so check successfully passes but vmalloc_to_page() returns NULL
(guard page does not physically exist).
The following code pattern example should trigger an oops:
  static int oops_mmap(struct file *file, struct vm_area_struct *vma)
 {
       void *mem;
        mem = vmalloc_user(4096);
       BUG_ON(!mem);
       /* Do not care about mem leak */
        return remap_vmalloc_range(vma, mem, 0);
 }
And userspace simply mmaps size + PAGE_SIZE:
  mmap(NULL, 8192, PROT_WRITE|PROT_READ, MAP_PRIVATE, fd, 0);
Possible candidates for oops which do not have any explicit size checks:
   *** drivers/media/usb/stkwebcam/stk-webcam.c:
  v4l_stk_mmap[789]   ret = remap_vmalloc_range(vma, sbuf->buffer, 0);
Or the following one:
   *** drivers/video/fbdev/core/fbmem.c
  static int
  fb_mmap(struct file *file, struct vm_area_struct * vma)
       ...
       res = fb->fb_mmap(info, vma);
Where fb_mmap callback calls remap_vmalloc_range() directly without any 
explicit checks:
   *** drivers/video/fbdev/vfb.c
  static int vfb_mmap(struct fb_info *info,
            struct vm_area_struct *vma)
  {
      return remap_vmalloc_range(vma, (void *)info->fix.smem_start,
vma->vm_pgoff);
  }
Link: http://lkml.kernel.org/r/20190103145954.16942-2-rpenyaev@suse.de 
Signed-off-by: Roman Penyaev <rpenyaev@suse.de> Acked-by: Michal Hocko
<mhocko@suse.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Joe
Perches <joe@perches.com> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org> 
Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

mm/memory.c: do_fault: avoid usage of stale vm_area_struct
commit fc8efd2ddfed3f343c11b693e87140ff358d7ff5 upstream.
LTP testcase mtest06 [1] can trigger a crash on s390x running 5.0.0-rc8. 
This is a stress test, where one thread mmaps/writes/munmaps memory area 
and other thread is trying to read from it:
  CPU: 0 PID: 2611 Comm: mmap1 Not tainted 5.0.0-rc8+ #51
 Hardware name: IBM 2964 N63 400 (z/VM 6.4.0)
 Krnl PSW : 0404e00180000000 00000000001ac8d8 (__lock_acquire+0x7/0x7a8)
 Call Trace:
 ([<0000000000000000>]           (null))
  [<00000000001adae4>] lock_acquire+0xec/0x258
  [<000000000080d1ac>] _raw_spin_lock_bh+0x5c/0x98
  [<000000000012a780>] page_table_free+0x48/0x1a8
  [<00000000002f6e54>] do_fault+0xdc/0x670
  [<00000000002fadae>] __handle_mm_fault+0x416/0x5f0
  [<00000000002fb138>] handle_mm_fault+0x1b0/0x320
  [<00000000001248cc>] do_dat_exception+0x19c/0x2c8
  [<000000000080e5ee>] pgm_check_handler+0x19e/0x200
page_table_free() is called with NULL mm parameter, but because "0" is a 
valid address on s390 (see S390_lowcore), it keeps going until it 
eventually crashes in lockdep's lock_acquire.  This crash is 
reproducible at least since 4.14.
Problem is that "vmf->vma" used in do_fault() can become stale.  Because 
mmap_sem may be released, other threads can come in, call munmap() and 
cause "vma" be returned to kmem cache, and get zeroed/re-initialized and 
re-used:
handle_mm_fault                           |
 __handle_mm_fault                       |
   do_fault                              |
     vma = vmf->vma                      |
     do_read_fault                       |
       __do_fault                        |
         vma->vm_ops->fault(vmf);        |
           mmap_sem is released          |
                                         |
                                         | do_munmap()
                                         |   remove_vma_list()
                                         |     remove_vma()
                                         |       vm_area_free()
                                         |         # vma is released
                                         | ...
                                         | # same vma is allocated
                                         | # from kmem cache
                                         | do_mmap()
                                         |   vm_area_alloc()
                                         |     memset(vma, 0, ...)
                                         |
     pte_free(vma->vm_mm, ...);          |
       page_table_free                   |
         spin_lock_bh(&mm->context.lock);|
           <crash>                       |
Cache mm_struct to avoid using potentially stale "vma".
[1]
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mtest06/mmap1.c
Link:
http://lkml.kernel.org/r/5b3fdf19e2a5be460a384b936f5b56e13733f1b8.1551595137.git.jstancek@redhat.com 
Signed-off-by: Jan Stancek <jstancek@redhat.com> Reviewed-by: Andrea
Arcangeli <aarcange@redhat.com> Reviewed-by: Matthew Wilcox
<willy@infradead.org> Acked-by: Rafael Aquini <aquini@redhat.com> 
Reviewed-by: Minchan Kim <minchan@kernel.org> Acked-by: Kirill A.
Shutemov <kirill.shutemov@linux.intel.com> Cc: Rik van Riel
<riel@surriel.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Huang Ying
<ying.huang@intel.com> Cc: Souptick Joarder <jrdr.linux@gmail.com> Cc:
Jerome Glisse <jglisse@redhat.com> Cc: Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> Cc: David Hildenbrand <david@redhat.com> 
Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Rientjes
<rientjes@google.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc:
<stable@vger.kernel.org> Signed-off-by: Andrew Morton
<akpm@linux-foundation.org> Signed-off-by: Linus Torvalds
<torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

kernel/sysctl.c: add missing range check in do_proc_dointvec_minmax_conv
commit 8cf7630b29701d364f8df4a50e4f1f5e752b2778 upstream.
This bug has apparently existed since the introduction of this function 
in the pre-git era (4500e91754d3 in Thomas Gleixner's history.git,
"[NET]: Add proc_dointvec_userhz_jiffies, use it for proper handling of 
neighbour sysctls.").
As a minimal fix we can simply duplicate the corresponding check in 
do_proc_dointvec_conv().
Link:
http://lkml.kernel.org/r/20190207123426.9202-3-zev@bewilderbeest.net 
Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Cc: Brendan Higgins
<brendanhiggins@google.com> Cc: Iurii Zaikin <yzaikin@google.com> Cc:
Kees Cook <keescook@chromium.org> Cc: Luis Chamberlain
<mcgrof@kernel.org> Cc: <stable@vger.kernel.org>	[2.6.2+] 
Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: core: don't check the return value of notifier chain call
commit f4853e1c321edb48af229ad5ac85076790d34968 upstream.
blocking_notifier_call_chain() returns the value returned by the last 
registered callback. A positive return value doesn't indicate an error 
and an nvmem device should correctly register irrespective of any 
notifier callback failures. Drop the retval check.
Fixes: bee1138bea15 ("nvmem: add a notifier chain") Cc:
stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski
<bgolaszewski@baylibre.com> Acked-by: Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

device property: Fix the length used in PROPERTY_ENTRY_STRING()
commit 2b6e492467c78183bb629bb0a100ea3509b615a5 upstream.
With string type property entries we need to use sizeof(const char *)
instead of the number of characters as the length of the entry.
If the string was shorter then sizeof(const char *), attempts to read it
would have failed with -EOVERFLOW. The problem has been hidden because
all build-in string properties have had a string longer then 8
characters until now.
Fixes: a85f42047533 ("device property: helper macros for property entry
creation") Cc: 4.5+ <stable@vger.kernel.org> # 4.5+ Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Andy
Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J.
Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

intel_th: Don't reference unassigned outputs
commit 9ed3f22223c33347ed963e7c7019cf2956dd4e37 upstream.
When an output port driver is removed, also remove references to it from 
any masters. Failing to do this causes a NULL ptr dereference when 
configuring another output port:
> BUG: unable to handle kernel NULL pointer dereference at
000000000000000d
> RIP: 0010:master_attr_store+0x9d/0x160 [intel_th_gth]
> Call Trace:
> dev_attr_store+0x1b/0x30
> sysfs_kf_write+0x3c/0x50
> kernfs_fop_write+0x125/0x1a0
> __vfs_write+0x3a/0x190
> ? __vfs_write+0x5/0x190
> ? _cond_resched+0x1a/0x50
> ? rcu_all_qs+0x5/0xb0
> ? __vfs_write+0x5/0x190
> vfs_write+0xb8/0x1b0
> ksys_write+0x55/0xc0
> __x64_sys_write+0x1a/0x20
> do_syscall_64+0x5a/0x140
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> 
Fixes: b27a6a3f97b9 ("intel_th: Add Global Trace Hub driver") CC:
stable@vger.kernel.org # v4.4+ Reported-by: Ammy Yi <ammy.yi@intel.com> 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parport_pc: fix find_superio io compare code, should use equal test.
commit 21698fd57984cd28207d841dbdaa026d6061bceb upstream.
In the original code before 181bf1e815a2 the loop was continuing until 
it finds the first matching superios[i].io and p->base. But after
181bf1e815a2 the logic changed and the loop now returns the pointer to
the first mismatched array element which is then used in 
get_superio_dma() and get_superio_irq() and thus returning the wrong 
value. Fix the condition so that it now returns the correct pointer.
Fixes: 181bf1e815a2 ("parport_pc: clean up the modified while loops
using for") Cc: Alan Cox <alan@linux.intel.com> Cc:
stable@vger.kernel.org Signed-off-by: QiaoChong <qiaochong@loongson.cn>
[rewrite the commit message] Signed-off-by: Sudip Mukherjee
<sudipm.mukherjee@gmail.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

i2c: tegra: fix maximum transfer size
commit f4e3f4ae1d9c9330de355f432b69952e8cef650c upstream.
Tegra186 and prior supports maximum 4K bytes per packet transfer 
including 12 bytes of packet header.
This patch fixes max write length limit to account packet header size
for transfers.
Cc: stable@vger.kernel.org # 4.4+
Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sowjanya
Komatineni <skomatineni@nvidia.com> Signed-off-by: Wolfram Sang
<wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

i2c: tegra: update maximum transfer size
commit b03ff2a23359d0dd6f0a1516c6a9e9c4760ed230 upstream.
Tegra194 supports maximum 64K bytes per packet including 12 bytes of 
packet header irrespective of PIO or DMA mode transfer.
This patch updates Tegra194 max write length to account for packet 
header size for transfers.
Cc: stable@vger.kernel.org # 4.20+
Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sowjanya
Komatineni <skomatineni@nvidia.com> Signed-off-by: Wolfram Sang
<wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

media: i2c: ov5640: Fix post-reset delay
commit 1d4c41f3d887bcd66e82cb2fda124533dad8808a upstream.
According to the ov5640 specification (2.7 power up sequence), host can 
access the sensor's registers 20ms after reset. Trying to access them 
before leads to undefined behavior and result in sporadic initialization 
errors.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro
Carvalho Chehab <mchehab+samsung@kernel.org> Cc: Adam Ford
<aford173@gmail.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

gpio: pca953x: Fix dereference of irq data in shutdown
commit c378b3aa015931a46c91d6ccc2fe04d97801d060 upstream.
If a PCA953x gpio was used as an interrupt and then released, the
shutdown function was trying to extract the pca953x_chip pointer
directly from the irq_data, but in reality was getting the gpio_chip
structure.
The net effect was that the subsequent writes to the data structure
corrupted data in the gpio_chip structure, which wasn't immediately
obvious until attempting to use the GPIO again in the future, at which
point the kernel panics.
This fix correctly extracts the pca953x_chip structure via the gpio_chip
structure, as is correctly done in the other irq functions.
Fixes: 0a70fe00efea ("gpio: pca953x: Clear irq trigger type on irq
shutdown") Cc: stable@vger.kernel.org Signed-off-by: Mark Walton
<mark.walton@serialtek.com> Reviewed-by: Bartosz Golaszewski
<bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij
<linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

ext4: update quota information while swapping boot loader inode
commit aa507b5faf38784defe49f5e64605ac3c4425e26 upstream.
While do swap between two inode, they swap i_data without update quota
information. Also, swap_inode_boot_loader can do "revert" somtimes, so
update the quota while all operations has been finished.
Signed-off-by: yangerkun <yangerkun@huawei.com> Signed-off-by: Theodore
Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: add mask of ext4 flags to swap
commit abdc644e8cbac2e9b19763680e5a7cf9bab2bee7 upstream.
The reason is that while swapping two inode, we swap the flags too. Some
flags such as EXT4_JOURNAL_DATA_FL can really confuse the things since
we're not resetting the address operations structure.  The simplest way
to keep things sane is to restrict the flags that can be swapped.
Signed-off-by: yangerkun <yangerkun@huawei.com> Signed-off-by: Theodore
Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix crash during online resizing
commit f96c3ac8dfc24b4e38fc4c2eba5fea2107b929d1 upstream.
When computing maximum size of filesystem possible with given number of 
group descriptor blocks, we forget to include s_first_data_block into 
the number of blocks. Thus for filesystems with non-zero 
s_first_data_block it can happen that computed maximum filesystem size 
is actually lower than current filesystem size which confuses the code 
and eventually leads to a BUG_ON in ext4_alloc_group_tables() hitting on 
flex_gd->count == 0. The problem can be reproduced like:
truncate -s 100g /tmp/image mkfs.ext4 -b 1024 -E resize=262144
/tmp/image 32768 mount -t ext4 -o loop /tmp/image /mnt resize2fs
/dev/loop0 262145 resize2fs /dev/loop0 300000
Fix the problem by properly including s_first_data_block into the 
computed number of filesystem blocks.
Fixes: 1c6bd7173d66 "ext4: convert file system to meta_bg if needed..." 
Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o
<tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

dma: Introduce dma_max_mapping_size()
commit 133d624b1cee16906134e92d5befb843b58bcf31 upstream.
The function returns the maximum size that can be mapped using DMA-API
functions. The patch also adds the implementation for direct DMA and a
new dma_map_ops pointer so that other implementations can expose their
limit.
Cc: stable@vger.kernel.org Reviewed-by: Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> 
Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Michael S.
Tsirkin <mst@redhat.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

swiotlb: Introduce swiotlb_max_mapping_size()
commit abe420bfae528c92bd8cc5ecb62dc95672b1fd6f upstream.
The function returns the maximum size that can be remapped by the
SWIOTLB implementation. This function will be later exposed to users
through the DMA-API.
Cc: stable@vger.kernel.org Reviewed-by: Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> 
Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Michael S.
Tsirkin <mst@redhat.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

swiotlb: Add is_swiotlb_active() function
commit 492366f7b4237257ef50ca9c431a6a0d50225aca upstream.
This function will be used from dma_direct code to determine the maximum
segment size of a dma mapping.
Cc: stable@vger.kernel.org Reviewed-by: Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> 
Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Michael S.
Tsirkin <mst@redhat.com> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

PCI/ASPM: Use LTR if already enabled by platform
commit 10ecc818ea7319b5d0d2b4e1aa6a77323e776f76 upstream.
RussianNeuroMancer reported that the Intel 7265 wifi on a Dell Venue 11
Pro 7140 table stopped working after wakeup from suspend and bisected
the problem to 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we
don't have LTR").  David Ward reported the same problem on a Dell
Latitude 7350.
After af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before 
using it"), we don't enable LTR unless the platform has granted LTR
control to us.  In addition, we don't notice if the platform had already
enabled LTR itself.
After 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't
have LTR"), we avoid using LTR if we don't think the path to the device
has LTR enabled.
The combination means that if the platform itself enables LTR but
declines to give the OS control over LTR, we unnecessarily avoided using
ASPM L1.2.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201469 Fixes:
9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have
LTR") Fixes: af8bb9f89838 ("PCI/ACPI: Request LTR control from platform
before using it") Reported-by: RussianNeuroMancer
<russianneuromancer@ya.ru> Reported-by: David Ward
<david.ward@ll.mit.edu> Signed-off-by: Bjorn Helgaas
<bhelgaas@google.com> CC: stable@vger.kernel.org	# v4.18+ 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI/DPC: Fix print AER status in DPC event handling
commit 9f08a5d896ce43380314c34ed3f264c8e6075b80 upstream.
Previously dpc_handler() called aer_get_device_error_info() without 
initializing info->severity, so aer_get_device_error_info() relied on 
uninitialized data.
Add dpc_get_aer_uncorrect_severity() to read the port's AER status,
mask, and severity registers and set info->severity.
Also, clear the port's AER fatal error status bits.
Fixes: 8aefa9b0d910 ("PCI/DPC: Print AER status in DPC event handling") 
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
[bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 
Reviewed-by: Keith Busch <keith.busch@intel.com> Cc:
stable@vger.kernel.org	# v4.19+ Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

PCI: qcom: Don't deassert reset GPIO during probe
commit 02b485e31d98265189b91f3e69c43df2ed50610c upstream.
Acquiring the reset GPIO low means that reset is being deasserted, this 
is followed almost immediately with qcom_pcie_host_init() asserting it, 
initializing it and then finally deasserting it again, for the link to 
come up.
Some PCIe devices requires a minimum time between the initial deassert 
and subsequent reset cycles. In a platform that boots with the reset 
GPIO asserted this requirement is being violated by this deassert/assert 
pulse.
Acquire the reset GPIO high to prevent this situation by matching the 
state to the subsequent asserted state.
Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") 
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by: Lorenzo
Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Stanimir Varbanov
<svarbanov@mm-sol.com> Cc: stable@vger.kernel.org Signed-off-by: Greg
Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: dwc: skip MSI init if MSIs have been explicitly disabled
commit 3afc8299f39a27b60e1519a28e18878ce878e7dd upstream.
Since 7c5925afbc58 (PCI: dwc: Move MSI IRQs allocation to IRQ domains 
hierarchical API) the MSI init claims one of the controller IRQs as a 
chained IRQ line for the MSI controller. On some designs, like the
i.MX6, this line is shared with a PCIe legacy IRQ. When the line is
claimed for the MSI domain, any device trying to use this legacy IRQs
will fail to request this IRQ line.
As MSI and legacy IRQs are already mutually exclusive on the DWC core, 
as the core won't forward any legacy IRQs once any MSI has been enabled, 
users wishing to use legacy IRQs already need to explictly disable MSI 
support (usually via the pci=nomsi kernel commandline option). To avoid 
any issues with MSI conflicting with legacy IRQs, just skip all of the 
DWC MSI initalization, including the IRQ line claim, when MSI is
disabled.
Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains
hierarchical API") Tested-by: Tim Harvey <tharvey@gateworks.com> 
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Gustavo Pimentel
<gustavo.pimentel@synopsys.com> Cc: stable@vger.kernel.org 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: pciehp: Disable Data Link Layer State Changed event on suspend
commit bbe54ea5330d828cc396d451c0e1e5c3f9764c1e upstream.
Commit 0e157e528604 ("PCI/PME: Implement runtime PM callbacks") tried to 
solve an issue where the hierarchy immediately wakes up when it is 
transitioned into D3cold.  However, it turns out to prevent PME 
propagation on some systems that do not support D3cold.
I looked more closely at what might cause the immediate wakeup.  It
happens when the ACPI power resource of the root port is turned off. 
The AML code associated with the _OFF() method of the ACPI power
resource starts a PCIe L2/L3 Ready transition and waits for it to
complete.  Right after the L2/L3 Ready transition is started the root
port receives a PME from the downstream port.
The simplest hierarchy where this happens looks like this:
  00:1d.0 PCIe Root Port
   ^
   |
   v
   05:00.0 PCIe switch #1 upstream port
     06:01.0 PCIe switch #1 downstream hotplug port
       ^
       |
       v
       08:00.0 PCIe switch #2 upstream port
It seems that the PCIe link between the two switches, before 
PME_Turn_Off/PME_TO_Ack is complete for the whole hierarchy, goes 
inactive and triggers PME towards the root port bringing it back to D0. 
The L2/L3 Ready sequence is described in PCIe r4.0 spec sections 5.2 and 
5.3.3 but unfortunately they do not state what happens if DLLSCE is 
enabled during the sequence.
Disabling Data Link Layer State Changed event (DLLSCE) seems to prevent 
the issue and still allows the downstream hotplug port to notice when a 
device is plugged/unplugged.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=202593 Fixes:
0e157e528604 ("PCI/PME: Implement runtime PM callbacks") Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn
Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki
<rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org	# v4.20+ 
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: pci-bridge-emul: Create per-bridge copy of register behavior
commit 59f81c35e0df840f7112cb296dde48df84a67c79 upstream.
The behavior of the different registers of the PCI-to-PCI bridge is 
currently encoded in two global arrays, shared by all instances of 
PCI-to-PCI bridge emulation.
However, we will need to tweak the behavior on a per-bridge basis, to 
accommodate for different capabilities of the platforms where this code
is used. In preparation for this, create a per-bridge copy of the 
register behavior arrays, so that they can later be tweaked on a 
per-bridge basis.
Fixes: 1f08673eef123 ("PCI: mvebu: Convert to PCI emulated bridge config
space") Reported-by: Luís Mendes <luis.p.mendes@gmail.com> Reported-by:
Leigh Brown <leigh@solinno.co.uk> Tested-by: Leigh Brown
<leigh@solinno.co.uk> Tested-by: Luis Mendes <luis.p.mendes@gmail.com> 
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> 
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc:
stable@vger.kernel.org Cc: Luís Mendes <luis.p.mendes@gmail.com> Cc:
Leigh Brown <leigh@solinno.co.uk> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>

PCI: pci-bridge-emul: Extend pci_bridge_emul_init() with flags
commit 33776d059630e5045ea9ccf756c74de8f9cc86de upstream.
Depending on the capabilities of the PCI controller/platform, the 
PCI-to-PCI bridge emulation behavior might need to be different. For 
example, on platforms that use the pci-mvebu code, we currently don't 
support prefetchable memory BARs, so the corresponding fields in the 
PCI-to-PCI bridge configuration space should be read-only.
To implement this, extend pci_bridge_emul_init() to take a "flags" 
argument, with currently one flag supported:
PCI_BRIDGE_EMUL_NO_PREFETCHABLE_BAR
that will make the prefetchable memory base and limit registers 
read-only.
The pci-mvebu and pci-aardvark drivers are updated accordingly.
Fixes: 1f08673eef123 ("PCI: mvebu: Convert to PCI emulated bridge config
space") Reported-by: Luís Mendes <luis.p.mendes@gmail.com> Reported-by:
Leigh Brown <leigh@solinno.co.uk> Tested-by: Leigh Brown
<leigh@solinno.co.uk> Tested-by: Luis Mendes <luis.p.mendes@gmail.com> 
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> 
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc:
stable@vger.kernel.org Cc: Luís Mendes <luis.p.mendes@gmail.com> Cc:
Leigh Brown <leigh@solinno.co.uk> Signed-off-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>