user/sven/linux.git/include, branch v5.6.11

dmaengine: fix channel index enumeration

2020-05-06T06:16:45Z

commit 0821009445a8261ac4d32a6df4b83938e007c765 upstream. When the channel register code was changed to allow hotplug operations, dynamic indexing wasn't taken into account. When channels are randomly plugged and unplugged out of order, the serial indexing breaks. Convert channel indexing to using IDA tracking in order to allow dynamic assignment. The previous code does not cause any regression bug for existing channel allocation besides idxd driver since the hotplug usage case is only used by idxd at this point. With this change, the chan->idr_ref is also not needed any longer. We can have a device with no channels registered due to hot plug. The channel device release code no longer should attempt to free the dma device id on the last channel release. Fixes: e81274cd6b52 ("dmaengine: add support to dynamic register/unregister of channels") Reported-by: Yixin Zhang Signed-off-by: Dave Jiang Tested-by: Yixin Zhang Link: https://lore.kernel.org/r/158679961260.7674.8485924270472851852.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

NFSv4.1: fix handling of backchannel binding in BIND_CONN_TO_SESSION

2020-05-06T06:16:20Z

commit dff58530c4ca8ce7ee5a74db431c6e35362cf682 upstream. Currently, if the client sends BIND_CONN_TO_SESSION with NFS4_CDFC4_FORE_OR_BOTH but only gets NFS4_CDFS4_FORE back it ignores that it wasn't able to enable a backchannel. To make sure, the client sends BIND_CONN_TO_SESSION as the first operation on the connections (ie., no other session compounds haven't been sent before), and if the client's request to bind the backchannel is not satisfied, then reset the connection and retry. Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman

dma-buf: Fix SET_NAME ioctl uapi

2020-05-06T06:16:12Z

commit a5bff92eaac45bdf6221badf9505c26792fdf99e upstream. The uapi is the same on 32 and 64 bit, but the number isn't. Everyone who botched this please re-read: https://www.kernel.org/doc/html/v5.4-preprc-cpu/ioctl/botching-up-ioctls.html Also, the type argument for the ioctl macros is for the type the void __user *arg pointer points at, which in this case would be the variable-sized char[] of a 0 terminated string. So this was botched in more than just the usual ways. Cc: Sumit Semwal Cc: Chenbo Feng Cc: Greg Hackmann Cc: Daniel Vetter Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: minchan@kernel.org Cc: surenb@google.com Cc: jenhaochen@google.com Cc: Martin Liu Signed-off-by: Daniel Vetter Tested-by: Martin Liu Reviewed-by: Martin Liu Signed-off-by: Sumit Semwal [sumits: updated some checkpatch fixes, corrected author email] Link: https://patchwork.freedesktop.org/patch/msgid/20200407133002.3486387-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman

ASoC: soc-core: disable route checks for legacy devices

2020-05-02T06:51:05Z

commit a22ae72b86a4f754e8d25fbf9ea5a8f77365e531 upstream. v5.4 changes in soc-core tightened the checks on soc_dapm_add_routes, which results in the ASoC card probe failing. Introduce a flag to be set in machine drivers to prevent the probe from stopping in case of incomplete topologies or missing routes. This flag is for backwards compatibility only and shall not be used for newer machine drivers. Example with an HDaudio card with a bad topology: [ 236.177898] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Failed to add route iDisp1_out -> direct -> iDisp1 Tx [ 236.177902] skl_hda_dsp_generic skl_hda_dsp_generic: snd_soc_bind_card: snd_soc_dapm_add_routes failed: -19 with the disable_route_checks set: [ 64.031657] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Failed to add route iDisp1_out -> direct -> iDisp1 Tx [ 64.031661] skl_hda_dsp_generic skl_hda_dsp_generic: snd_soc_bind_card: disable_route_checks set, ignoring errors on add_routes Fixes: daa480bde6b3a9 ("ASoC: soc-core: tidyup for snd_soc_dapm_add_routes()") Signed-off-by: Pierre-Louis Bossart Acked-by: Kuninori Morimoto Link: https://lore.kernel.org/r/20200309192744.18380-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

qed: Fix use after free in qed_chain_free

2020-05-02T06:51:05Z

commit 8063f761cd7c17fc1d0018728936e0c33a25388a upstream. The qed_chain data structure was modified in commit 1a4a69751f4d ("qed: Chain support for external PBL") to support receiving an external pbl (due to iWARP FW requirements). The pages pointed to by the pbl are allocated in qed_chain_alloc and their virtual address are stored in an virtual addresses array to enable accessing and freeing the data. The physical addresses however weren't stored and were accessed directly from the external-pbl during free. Destroy-qp flow, leads to freeing the external pbl before the chain is freed, when the chain is freed it tries accessing the already freed external pbl, leading to a use-after-free. Therefore we need to store the physical addresses in additional to the virtual addresses in a new data structure. Fixes: 1a4a69751f4d ("qed: Chain support for external PBL") Signed-off-by: Michal Kalderon Signed-off-by: Yuval Bason Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

taprio: do not use BIT() in TCA_TAPRIO_ATTR_FLAG_* definitions

2020-05-02T06:51:04Z

commit 673040c3a82a7564423e09c791e242a846591e30 upstream. BIT() macro definition is internal to the Linux kernel and is not to be used in UAPI headers; replace its usage with the _BITUL() macro that is already used elsewhere in the header. Fixes: 9c66d1564676 ("taprio: Add support for hardware offloading") Signed-off-by: Eugene Syromiatnikov Acked-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling

2020-05-02T06:51:03Z

[ Upstream commit 96806229ca033f85310bc5c203410189f8a1d2ee ] When a vPE is made resident, the GIC starts parsing the virtual pending table to deliver pending interrupts. This takes place asynchronously, and can at times take a long while. Long enough that the vcpu enters the guest and hits WFI before any interrupt has been signaled yet. The vcpu then exits, blocks, and now gets a doorbell. Rince, repeat. In order to avoid the above, a (optional on GICv4, mandatory on v4.1) feature allows the GIC to feedback to the hypervisor whether it is done parsing the VPT by clearing the GICR_VPENDBASER.Dirty bit. The hypervisor can then wait until the GIC is ready before actually running the vPE. Plug the detection code as well as polling on vPE schedule. While at it, tidy-up the kernel message that displays the GICv4 optional features. Reviewed-by: Zenghui Yu Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin

blk-iocost: Fix error on iocost_ioc_vrate_adj

2020-05-02T06:50:54Z

commit d6c8e949a35d6906d6c03a50e9a9cdf4e494528a upstream. Systemtap 4.2 is unable to correctly interpret the "u32 (*missed_ppm)[2]" argument of the iocost_ioc_vrate_adj trace entry defined in include/trace/events/iocost.h leading to the following error: /tmp/stapAcz0G0/stap_c89c58b83cea1724e26395efa9ed4939_6321_aux_6.c:78:8: error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ token , u32[]* __tracepoint_arg_missed_ppm That argument type is indeed rather complex and hard to read. Looking at block/blk-iocost.c. It is just a 2-entry u32 array. By simplifying the argument to a simple "u32 *missed_ppm" and adjusting the trace entry accordingly, the compilation error was gone. Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Acked-by: Steven Rostedt (VMware) Acked-by: Tejun Heo Signed-off-by: Waiman Long Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

PCI: Add Zhaoxin Vendor ID

2020-05-02T06:50:50Z

commit 3375590623e4a132b19a8740512f4deb95728933 upstream. Add Zhaoxin Vendor ID to pci_ids.h Link: https://lore.kernel.org/r/20200327091148.5190-2-RaymondPang-oc@zhaoxin.com Signed-off-by: Raymond Pang Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman

svcrdma: Fix leak of svc_rdma_recv_ctxt objects

2020-05-02T06:50:49Z

commit 23cf1ee1f1869966b75518c59b5cbda4c6c92450 upstream. Utilize the xpo_release_rqst transport method to ensure that each rqstp's svc_rdma_recv_ctxt object is released even when the server cannot return a Reply for that rqstp. Without this fix, each RPC whose Reply cannot be sent leaks one svc_rdma_recv_ctxt. This is a 2.5KB structure, a 4KB DMA-mapped Receive buffer, and any pages that might be part of the Reply message. The leak is infrequent unless the network fabric is unreliable or Kerberos is in use, as GSS sequence window overruns, which result in connection loss, are more common on fast transports. Fixes: 3a88092ee319 ("svcrdma: Preserve Receive buffer until svc_rdma_sendto") Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman