2020-05-04 18:10:39

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 00/73] 5.6.11-rc1 review

This is the start of the stable review cycle for the 5.6.11 release.
There are 73 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.6.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 5.6.11-rc1

Jens Axboe <[email protected]>
io_uring: statx must grab the file table for valid fd

Vincenzo Frascino <[email protected]>
arm64: vdso: Add -fasynchronous-unwind-tables to cflags

Andy Shevchenko <[email protected]>
dmaengine: dmatest: Fix process hang when reading 'wait' parameter

Matt Roper <[email protected]>
drm/i915: Use proper fault mask in interrupt postinstall too

Andy Shevchenko <[email protected]>
dmaengine: dmatest: Fix iteration non-stop logic

Andreas Gruenbacher <[email protected]>
nfs: Fix potential posix_acl refcnt leak in nfs3_set_acl

Xiyu Yang <[email protected]>
drm/i915/selftests: Fix i915_address_space refcnt leak

Niklas Cassel <[email protected]>
nvme: prevent double free in nvme_alloc_ns() error handling

David Howells <[email protected]>
Fix use after free in get_tree_bdev()

Arnd Bergmann <[email protected]>
ALSA: opti9xx: shut up gcc-10 range warning

ryan_chen <[email protected]>
i2c: aspeed: Avoid i2c interrupt status clear race condition.

Suravee Suthikulpanit <[email protected]>
iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system

Lu Baolu <[email protected]>
iommu/vt-d: Use right Kconfig option name

Greg Kroah-Hartman <[email protected]>
iommu: Properly export iommu_group_get_for_dev()

David Disseldorp <[email protected]>
scsi: target/iblock: fix WRITE SAME zeroing

Dave Jiang <[email protected]>
dmaengine: fix channel index enumeration

Grygorii Strashko <[email protected]>
dmaengine: ti: k3-psil: fix deadlock on error path

Tang Bin <[email protected]>
iommu/qcom: Fix local_base status check

Sean Christopherson <[email protected]>
vfio/type1: Fix VA->PA translation for PFNMAP VMAs in vaddr_get_pfn()

Yan Zhao <[email protected]>
vfio: avoid possible overflow in vfio_iommu_type1_pin_pages

YueHaibing <[email protected]>
dmaengine: hisilicon: Fix build error without PCI_MSI

Rayagonda Kokatanur <[email protected]>
i2c: iproc: generate stop event for slave writes

Dan Carpenter <[email protected]>
RDMA/cm: Fix an error check in cm_alloc_id_priv()

Jason Gunthorpe <[email protected]>
RDMA/cm: Fix ordering of xa_alloc_cyclic() in ib_create_cm_id()

Leon Romanovsky <[email protected]>
RDMA/core: Fix race between destroy and release FD object

Leon Romanovsky <[email protected]>
RDMA/core: Fix overwriting of uobj in case of error

Leon Romanovsky <[email protected]>
RDMA/core: Prevent mixed use of FDs between shared ufiles

Jason Gunthorpe <[email protected]>
RDMA/siw: Fix potential siw_mem refcnt leak in siw_fastreg_mr()

Alaa Hleihel <[email protected]>
RDMA/mlx4: Initialize ib_spec on the stack

Jason Gunthorpe <[email protected]>
RDMA/uverbs: Fix a race with disassociate and exit_mmap()

Aharon Landau <[email protected]>
RDMA/mlx5: Set GRH fields in query QP on RoCE

Martin Wilck <[email protected]>
scsi: qla2xxx: check UNLOADING before posting async work

Martin Wilck <[email protected]>
scsi: qla2xxx: set UNLOADING before waiting for session deletion

Christoph Hellwig <[email protected]>
block: remove the bd_openers checks in blk_drop_partitions

Russell King <[email protected]>
ARM: dts: imx6qdl-sr-som-ti: indicate powering off wifi is safe

Gabriel Krisman Bertazi <[email protected]>
dm multipath: use updated MPATHF_QUEUE_IO on mapping for bio-based mpath

Mikulas Patocka <[email protected]>
dm writecache: fix data corruption when reloading the target

Sunwook Eom <[email protected]>
dm verity fec: fix hash block number in verity_fec_decode

Dexuan Cui <[email protected]>
PM: hibernate: Freeze kernel threads in software_resume()

Kai-Heng Feng <[email protected]>
PM: ACPI: Output correct message on target power state

Sudip Mukherjee <[email protected]>
IB/rdmavt: Always return ERR_PTR from rvt_create_mmap_info()

Paul Moore <[email protected]>
selinux: properly handle multiple messages in selinux_netlink_send()

Al Viro <[email protected]>
dlmfs_file_write(): fix the bogosity in handling non-zero *ppos

Dexuan Cui <[email protected]>
Drivers: hv: vmbus: Fix Suspend-to-Idle for Generation-2 VM

Dexuan Cui <[email protected]>
x86/hyperv: Suspend/resume the VP assist page for hibernation

Dan Carpenter <[email protected]>
i2c: amd-mp2-pci: Fix Oops in amd_mp2_pci_init() error handling

Takashi Iwai <[email protected]>
ALSA: pcm: oss: Place the plugin buffer overflow checks correctly

Vasily Khoruzhick <[email protected]>
ALSA: line6: Fix POD HD500 audio playback

Wu Bo <[email protected]>
ALSA: hda/hdmi: fix without unlocked before return

Takashi Iwai <[email protected]>
ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID

Hui Wang <[email protected]>
ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter

Iuliana Prodan <[email protected]>
crypto: caam - fix the address of the last entry of S/G

Martin Blumenstingl <[email protected]>
mmc: meson-mx-sdio: remove the broken ->card_busy() op

Martin Blumenstingl <[email protected]>
mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY

Veerabhadrarao Badiganti <[email protected]>
mmc: sdhci-msm: Enable host capabilities pertains to R1b response

Adrian Hunter <[email protected]>
mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers

Marek Behún <[email protected]>
mmc: sdhci-xenon: fix annoying 1.8V regulator warning

Douglas Anderson <[email protected]>
mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop

Qu Wenruo <[email protected]>
btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info

Filipe Manana <[email protected]>
btrfs: fix partial loss of prealloc extent past i_size after fsync

Xiyu Yang <[email protected]>
btrfs: fix block group leak when removing fails

Xiyu Yang <[email protected]>
btrfs: fix transaction leak in btrfs_recover_relocation

Olga Kornievskaia <[email protected]>
NFSv4.1: fix handling of backchannel binding in BIND_CONN_TO_SESSION

Vasily Averin <[email protected]>
drm/qxl: qxl_release use after free

Vasily Averin <[email protected]>
drm/qxl: qxl_release leak in qxl_hw_surface_alloc()

Vasily Averin <[email protected]>
drm/qxl: qxl_release leak in qxl_draw_dirty_fb()

Chris Wilson <[email protected]>
drm/i915/gt: Check cacheline is valid before acquiring

Chris Wilson <[email protected]>
drm/i915/gem: Hold obj->vma.lock over for_each_ggtt_vma()

Rodrigo Siqueira <[email protected]>
drm/amd/display: Fix green screen issue after suspend

Ville Syrjälä <[email protected]>
drm/edid: Fix off-by-one in DispID DTD pixel clock

Marek Olšák <[email protected]>
drm/amdgpu: invalidate L2 before SDMA IBs (v2)

Daniel Vetter <[email protected]>
dma-buf: Fix SET_NAME ioctl uapi

Christian König <[email protected]>
drm/scheduler: fix drm_sched_get_cleanup_job


-------------

Diffstat:

Makefile | 4 +-
arch/arm/boot/dts/imx6qdl-sr-som-ti.dtsi | 1 +
arch/arm64/kernel/vdso/Makefile | 2 +-
arch/x86/hyperv/hv_init.c | 12 +++-
block/partition-generic.c | 2 +-
drivers/acpi/device_pm.c | 4 +-
drivers/crypto/caam/caamalg.c | 2 +-
drivers/dma-buf/dma-buf.c | 3 +-
drivers/dma/Kconfig | 3 +-
drivers/dma/dmaengine.c | 60 +++++++++----------
drivers/dma/dmatest.c | 6 +-
drivers/dma/ti/k3-psil.c | 1 +
drivers/gpu/drm/amd/amdgpu/navi10_sdma_pkt_open.h | 16 ++++++
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 14 ++++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 +++++++++---
drivers/gpu/drm/drm_edid.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 20 ++++++-
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +
drivers/gpu/drm/i915/i915_irq.c | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 10 ++--
drivers/gpu/drm/qxl/qxl_cmd.c | 10 ++--
drivers/gpu/drm/qxl/qxl_display.c | 6 +-
drivers/gpu/drm/qxl/qxl_draw.c | 7 ++-
drivers/gpu/drm/qxl/qxl_ioctl.c | 5 +-
drivers/gpu/drm/scheduler/sched_main.c | 2 +-
drivers/hv/vmbus_drv.c | 43 +++++++++++---
drivers/i2c/busses/i2c-amd-mp2-pci.c | 2 +-
drivers/i2c/busses/i2c-aspeed.c | 5 +-
drivers/i2c/busses/i2c-bcm-iproc.c | 3 +
drivers/infiniband/core/cm.c | 27 ++++-----
drivers/infiniband/core/rdma_core.c | 9 ++-
drivers/infiniband/core/uverbs_main.c | 4 ++
drivers/infiniband/hw/mlx4/main.c | 3 +-
drivers/infiniband/hw/mlx5/qp.c | 4 +-
drivers/infiniband/sw/rdmavt/cq.c | 4 +-
drivers/infiniband/sw/rdmavt/mmap.c | 4 +-
drivers/infiniband/sw/rdmavt/qp.c | 4 +-
drivers/infiniband/sw/rdmavt/srq.c | 4 +-
drivers/infiniband/sw/siw/siw_qp_tx.c | 15 +++--
drivers/iommu/amd_iommu_init.c | 2 +-
drivers/iommu/intel-iommu.c | 4 +-
drivers/iommu/iommu.c | 2 +-
drivers/iommu/qcom_iommu.c | 5 +-
drivers/md/dm-mpath.c | 6 +-
drivers/md/dm-verity-fec.c | 2 +-
drivers/md/dm-writecache.c | 52 ++++++++++++-----
drivers/mmc/host/cqhci.c | 21 ++++---
drivers/mmc/host/meson-mx-sdio.c | 11 +---
drivers/mmc/host/sdhci-msm.c | 2 +
drivers/mmc/host/sdhci-pci-core.c | 3 +
drivers/mmc/host/sdhci-xenon.c | 10 ++++
drivers/nvme/host/core.c | 2 +
drivers/scsi/qla2xxx/qla_os.c | 35 ++++++------
drivers/target/target_core_iblock.c | 2 +-
drivers/vfio/vfio_iommu_type1.c | 6 +-
fs/btrfs/block-group.c | 16 ++++--
fs/btrfs/relocation.c | 1 +
fs/btrfs/transaction.c | 13 ++++-
fs/btrfs/tree-log.c | 43 +++++++++++++-
fs/io_uring.c | 12 +++-
fs/nfs/nfs3acl.c | 22 ++++---
fs/nfs/nfs4proc.c | 8 +++
fs/ocfs2/dlmfs/dlmfs.c | 27 ++++-----
fs/super.c | 2 +-
include/linux/dmaengine.h | 4 +-
include/linux/nfs_xdr.h | 2 +
include/linux/sunrpc/clnt.h | 5 ++
include/uapi/linux/dma-buf.h | 6 ++
kernel/power/hibernate.c | 7 +++
security/selinux/hooks.c | 70 +++++++++++++++--------
sound/core/oss/pcm_plugin.c | 20 ++++---
sound/isa/opti9xx/miro.c | 9 ++-
sound/isa/opti9xx/opti92x-ad1848.c | 9 ++-
sound/pci/hda/patch_hdmi.c | 4 +-
sound/pci/hda/patch_realtek.c | 1 +
sound/usb/line6/podhd.c | 22 ++-----
sound/usb/quirks.c | 2 +-
78 files changed, 554 insertions(+), 297 deletions(-)



2020-05-04 18:10:42

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 71/73] dmaengine: dmatest: Fix process hang when reading wait parameter

From: Andy Shevchenko <[email protected]>

commit aa72f1d20ee973d68f26d46fce5e1cf6f9b7e1ca upstream.

If we do

% echo 1 > /sys/module/dmatest/parameters/run
[ 115.851124] dmatest: Could not start test, no channels configured

% echo dma8chan7 > /sys/module/dmatest/parameters/channel
[ 127.563872] dmatest: Added 1 threads using dma8chan7

% cat /sys/module/dmatest/parameters/wait
... !!! HANG !!! ...

The culprit is the commit 6138f967bccc

("dmaengine: dmatest: Use fixed point div to calculate iops")

which makes threads not to run, but pending and being kicked off by writing
to the 'run' node. However, it forgot to consider 'wait' routine to avoid
above mentioned case.

In order to fix this, check for really running threads, i.e. with pending
and done flags unset.

It's pity the culprit commit hadn't updated documentation and tested all
possible scenarios.

Fixes: 6138f967bccc ("dmaengine: dmatest: Use fixed point div to calculate iops")
Cc: Seraj Alijan <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/dma/dmatest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -240,7 +240,7 @@ static bool is_threaded_test_run(struct
struct dmatest_thread *thread;

list_for_each_entry(thread, &dtc->threads, node) {
- if (!thread->done)
+ if (!thread->done && !thread->pending)
return true;
}
}


2020-05-04 18:10:45

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 47/73] RDMA/core: Prevent mixed use of FDs between shared ufiles

From: Leon Romanovsky <[email protected]>

commit 0fb00941dc63990a10951146df216fc7b0e20bc2 upstream.

FDs can only be used on the ufile that created them, they cannot be mixed
to other ufiles. We are lacking a check to prevent it.

BUG: KASAN: null-ptr-deref in atomic64_sub_and_test include/asm-generic/atomic-instrumented.h:1547 [inline]
BUG: KASAN: null-ptr-deref in atomic_long_sub_and_test include/asm-generic/atomic-long.h:460 [inline]
BUG: KASAN: null-ptr-deref in fput_many+0x1a/0x140 fs/file_table.c:336
Write of size 8 at addr 0000000000000038 by task syz-executor179/284

CPU: 0 PID: 284 Comm: syz-executor179 Not tainted 5.5.0-rc5+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x94/0xce lib/dump_stack.c:118
__kasan_report+0x18f/0x1b7 mm/kasan/report.c:510
kasan_report+0xe/0x20 mm/kasan/common.c:639
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x15d/0x1b0 mm/kasan/generic.c:192
atomic64_sub_and_test include/asm-generic/atomic-instrumented.h:1547 [inline]
atomic_long_sub_and_test include/asm-generic/atomic-long.h:460 [inline]
fput_many+0x1a/0x140 fs/file_table.c:336
rdma_lookup_put_uobject+0x85/0x130 drivers/infiniband/core/rdma_core.c:692
uobj_put_read include/rdma/uverbs_std_types.h:96 [inline]
_ib_uverbs_lookup_comp_file drivers/infiniband/core/uverbs_cmd.c:198 [inline]
create_cq+0x375/0xba0 drivers/infiniband/core/uverbs_cmd.c:1006
ib_uverbs_create_cq+0x114/0x140 drivers/infiniband/core/uverbs_cmd.c:1089
ib_uverbs_write+0xaa5/0xdf0 drivers/infiniband/core/uverbs_main.c:769
__vfs_write+0x7c/0x100 fs/read_write.c:494
vfs_write+0x168/0x4a0 fs/read_write.c:558
ksys_write+0xc8/0x200 fs/read_write.c:611
do_syscall_64+0x9c/0x390 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x44ef99
Code: 00 b8 00 01 00 00 eb e1 e8 74 1c 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c4 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc0b74c028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007ffc0b74c030 RCX: 000000000044ef99
RDX: 0000000000000040 RSI: 0000000020000040 RDI: 0000000000000005
RBP: 00007ffc0b74c038 R08: 0000000000401830 R09: 0000000000401830
R10: 00007ffc0b74c038 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00000000006be018 R15: 0000000000000000

Fixes: cf8966b3477d ("IB/core: Add support for fd objects")
Link: https://lore.kernel.org/r/[email protected]
Suggested-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/rdma_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/core/rdma_core.c
+++ b/drivers/infiniband/core/rdma_core.c
@@ -360,7 +360,7 @@ lookup_get_fd_uobject(const struct uverb
* uverbs_uobject_fd_release(), and the caller is expected to ensure
* that release is never done while a call to lookup is possible.
*/
- if (f->f_op != fd_type->fops) {
+ if (f->f_op != fd_type->fops || uobject->ufile != ufile) {
fput(f);
return ERR_PTR(-EBADF);
}


2020-05-04 18:11:11

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 45/73] RDMA/mlx4: Initialize ib_spec on the stack

From: Alaa Hleihel <[email protected]>

commit c08cfb2d8d78bfe81b37cc6ba84f0875bddd0d5c upstream.

Initialize ib_spec on the stack before using it, otherwise we will have
garbage values that will break creating default rules with invalid parsing
error.

Fixes: a37a1a428431 ("IB/mlx4: Add mechanism to support flow steering over IB links")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alaa Hleihel <[email protected]>
Reviewed-by: Maor Gottlieb <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/hw/mlx4/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1502,8 +1502,9 @@ static int __mlx4_ib_create_default_rule
int i;

for (i = 0; i < ARRAY_SIZE(pdefault_rules->rules_create_list); i++) {
+ union ib_flow_spec ib_spec = {};
int ret;
- union ib_flow_spec ib_spec;
+
switch (pdefault_rules->rules_create_list[i]) {
case 0:
/* no rule */


2020-05-04 18:11:18

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 31/73] dlmfs_file_write(): fix the bogosity in handling non-zero *ppos

From: Al Viro <[email protected]>

commit 3815f1be546e752327b5868af103ccdddcc4db77 upstream.

'count' is how much you want written, not the final position.
Moreover, it can legitimately be less than the current position...

Cc: [email protected]
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ocfs2/dlmfs/dlmfs.c | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)

--- a/fs/ocfs2/dlmfs/dlmfs.c
+++ b/fs/ocfs2/dlmfs/dlmfs.c
@@ -275,7 +275,6 @@ static ssize_t dlmfs_file_write(struct f
loff_t *ppos)
{
int bytes_left;
- ssize_t writelen;
char *lvb_buf;
struct inode *inode = file_inode(filp);

@@ -285,32 +284,30 @@ static ssize_t dlmfs_file_write(struct f
if (*ppos >= i_size_read(inode))
return -ENOSPC;

+ /* don't write past the lvb */
+ if (count > i_size_read(inode) - *ppos)
+ count = i_size_read(inode) - *ppos;
+
if (!count)
return 0;

if (!access_ok(buf, count))
return -EFAULT;

- /* don't write past the lvb */
- if ((count + *ppos) > i_size_read(inode))
- writelen = i_size_read(inode) - *ppos;
- else
- writelen = count - *ppos;
-
- lvb_buf = kmalloc(writelen, GFP_NOFS);
+ lvb_buf = kmalloc(count, GFP_NOFS);
if (!lvb_buf)
return -ENOMEM;

- bytes_left = copy_from_user(lvb_buf, buf, writelen);
- writelen -= bytes_left;
- if (writelen)
- user_dlm_write_lvb(inode, lvb_buf, writelen);
+ bytes_left = copy_from_user(lvb_buf, buf, count);
+ count -= bytes_left;
+ if (count)
+ user_dlm_write_lvb(inode, lvb_buf, count);

kfree(lvb_buf);

- *ppos = *ppos + writelen;
- mlog(0, "wrote %zd bytes\n", writelen);
- return writelen;
+ *ppos = *ppos + count;
+ mlog(0, "wrote %zu bytes\n", count);
+ return count;
}

static void dlmfs_init_once(void *foo)


2020-05-04 18:11:20

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 72/73] arm64: vdso: Add -fasynchronous-unwind-tables to cflags

From: Vincenzo Frascino <[email protected]>

commit 1578e5d03112e3e9d37e1c4d95b6dfb734c73955 upstream.

On arm64 linux gcc uses -fasynchronous-unwind-tables -funwind-tables
by default since gcc-8, so now the de facto platform ABI is to allow
unwinding from async signal handlers.

However on bare metal targets (aarch64-none-elf), and on old gcc,
async and sync unwind tables are not enabled by default to avoid
runtime memory costs.

This means if linux is built with a baremetal toolchain the vdso.so
may not have unwind tables which breaks the gcc platform ABI guarantee
in userspace.

Add -fasynchronous-unwind-tables explicitly to the vgettimeofday.o
cflags to address the ABI change.

Fixes: 28b1a824a4f4 ("arm64: vdso: Substitute gettimeofday() with C implementation")
Cc: Will Deacon <[email protected]>
Reported-by: Szabolcs Nagy <[email protected]>
Signed-off-by: Vincenzo Frascino <[email protected]>
Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/kernel/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -32,7 +32,7 @@ UBSAN_SANITIZE := n
OBJECT_FILES_NON_STANDARD := y
KCOV_INSTRUMENT := n

-CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny
+CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables

ifneq ($(c-gettimeofday-y),)
CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)


2020-05-04 18:11:21

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 44/73] RDMA/uverbs: Fix a race with disassociate and exit_mmap()

From: Jason Gunthorpe <[email protected]>

commit 39c011a538272589b9eb02ff1228af528522a22c upstream.

If uverbs_user_mmap_disassociate() is called while the mmap is
concurrently doing exit_mmap then the ordering of the
rdma_user_mmap_entry_put() is not reliable.

The put must be done before uvers_user_mmap_disassociate() returns,
otherwise there can be a use after free on the ucontext, and a left over
entry in the xarray. If the put is not done here then it is done during
rdma_umap_close() later.

Add the missing put to the error exit path.

WARNING: CPU: 7 PID: 7111 at drivers/infiniband/core/rdma_core.c:810 uverbs_destroy_ufile_hw+0x2a5/0x340 [ib_uverbs]
Modules linked in: bonding ipip tunnel4 geneve ip6_udp_tunnel udp_tunnel ip6_gre ip6_tunnel tunnel6 ip_gre ip_tunnel gre mlx5_ib mlx5_core mlxfw pci_hyperv_intf act_ct nf_flow_table ptp pps_core rdma_ucm ib_uverbs ib_ipoib ib_umad 8021q garp mrp openvswitch nsh nf_conncount nfsv3 nfs_acl xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype iptable_filter xt_conntrack br_netfilter bridge stp llc rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache overlay rpcrdma ib_isert iscsi_target_mod ib_iser kvm_intel ib_srpt iTCO_wdt target_core_mod iTCO_vendor_support kvm ib_srp nf_nat irqbypass crc32_pclmul crc32c_intel nf_conntrack rfkill nf_defrag_ipv6 virtio_net nf_defrag_ipv4 pcspkr ghash_clmulni_intel i2c_i801 net_failover failover i2c_core lpc_ich mfd_core rdma_cm ib_cm iw_cm button ib_core sunrpc sch_fq_codel ip_tables serio_raw [last unloaded: tunnel4]
CPU: 7 PID: 7111 Comm: python3 Tainted: G W 5.6.0-rc6-for-upstream-dbg-2020-03-21_06-41-26-18 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
RIP: 0010:uverbs_destroy_ufile_hw+0x2a5/0x340 [ib_uverbs]
Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 74 49 8b 84 24 08 01 00 00 48 85 c0 0f 84 13 ff ff ff 48 89 ef ff d0 e9 09 ff ff ff <0f> 0b e9 77 ff ff ff e8 0f d8 fa e0 e9 c5 fd ff ff e8 05 d8 fa e0
RSP: 0018:ffff88840e0779a0 EFLAGS: 00010286
RAX: dffffc0000000000 RBX: ffff8882a7721c00 RCX: 0000000000000000
RDX: 1ffff11054ee469f RSI: ffffffff8446d7e0 RDI: ffff8882a77234f8
RBP: ffff8882a7723400 R08: ffffed1085c0112c R09: 0000000000000001
R10: 0000000000000001 R11: ffffed1085c0112b R12: ffff888403c30000
R13: 0000000000000002 R14: ffff8882a7721cb0 R15: ffff8882a7721cd0
FS: 00007f2046089700(0000) GS:ffff88842de00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7cfe9a6e20 CR3: 000000040b8ac006 CR4: 0000000000360ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
ib_uverbs_remove_one+0x273/0x480 [ib_uverbs]
? up_write+0x15c/0x4a0
remove_client_context+0xa6/0xf0 [ib_core]
disable_device+0x12d/0x200 [ib_core]
? remove_client_context+0xf0/0xf0 [ib_core]
? mnt_get_count+0x1d0/0x1d0
__ib_unregister_device+0x79/0x150 [ib_core]
ib_unregister_device+0x21/0x30 [ib_core]
__mlx5_ib_remove+0x91/0x110 [mlx5_ib]
? __mlx5_ib_remove+0x110/0x110 [mlx5_ib]
mlx5_remove_device+0x241/0x310 [mlx5_core]
mlx5_unregister_device+0x4d/0x1e0 [mlx5_core]
mlx5_unload_one+0xc0/0x260 [mlx5_core]
remove_one+0x5c/0x160 [mlx5_core]
pci_device_remove+0xef/0x2a0
? pcibios_free_irq+0x10/0x10
device_release_driver_internal+0x1d8/0x470
unbind_store+0x152/0x200
? sysfs_kf_write+0x3b/0x180
? sysfs_file_ops+0x160/0x160
kernfs_fop_write+0x284/0x460
? __sb_start_write+0x243/0x3a0
vfs_write+0x197/0x4a0
ksys_write+0x156/0x1e0
? __x64_sys_read+0xb0/0xb0
? do_syscall_64+0x73/0x1330
? do_syscall_64+0x73/0x1330
do_syscall_64+0xe7/0x1330
? down_write_nested+0x3e0/0x3e0
? syscall_return_slowpath+0x970/0x970
? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
? lockdep_hardirqs_off+0x1de/0x2d0
? trace_hardirqs_off_thunk+0x1a/0x1c
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f20a3ff0cdb
Code: 53 48 89 d5 48 89 f3 48 83 ec 18 48 89 7c 24 08 e8 5a fd ff ff 48 89 ea 41 89 c0 48 89 de 48 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 90 fd ff ff 48
RSP: 002b:00007f2046087040 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f2038016df0 RCX: 00007f20a3ff0cdb
RDX: 000000000000000d RSI: 00007f2038016df0 RDI: 0000000000000018
RBP: 000000000000000d R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000100 R11: 0000000000000293 R12: 00007f2046e29630
R13: 00007f20280035a0 R14: 0000000000000018 R15: 00007f2038016df0

Fixes: c043ff2cfb7f ("RDMA: Connect between the mmap entry and the umap_priv structure")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Yishai Hadas <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/uverbs_main.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -820,6 +820,10 @@ void uverbs_user_mmap_disassociate(struc
ret = mmget_not_zero(mm);
if (!ret) {
list_del_init(&priv->list);
+ if (priv->entry) {
+ rdma_user_mmap_entry_put(priv->entry);
+ priv->entry = NULL;
+ }
mm = NULL;
continue;
}


2020-05-04 18:11:31

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 25/73] ALSA: hda/hdmi: fix without unlocked before return

From: Wu Bo <[email protected]>

commit a2f647240998aa49632fb09b01388fdf2b87acfc upstream.

Fix the following coccicheck warning:
sound/pci/hda/patch_hdmi.c:1852:2-8: preceding lock on line 1846

After add sanity check to pass klockwork check,
The spdif_mutex should be unlock before return true
in check_non_pcm_per_cvt().

Fixes: 960a581e22d9 ("ALSA: hda: fix some klockwork scan warnings")
Signed-off-by: Wu Bo <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/patch_hdmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1934,8 +1934,10 @@ static bool check_non_pcm_per_cvt(struct
/* Add sanity check to pass klockwork check.
* This should never happen.
*/
- if (WARN_ON(spdif == NULL))
+ if (WARN_ON(spdif == NULL)) {
+ mutex_unlock(&codec->spdif_mutex);
return true;
+ }
non_pcm = !!(spdif->status & IEC958_AES0_NONAUDIO);
mutex_unlock(&codec->spdif_mutex);
return non_pcm;


2020-05-04 18:11:31

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 35/73] PM: hibernate: Freeze kernel threads in software_resume()

From: Dexuan Cui <[email protected]>

commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.

Currently the kernel threads are not frozen in software_resume(), so
between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(),
system_freezable_power_efficient_wq can still try to submit SCSI
commands and this can cause a panic since the low level SCSI driver
(e.g. hv_storvsc) has quiesced the SCSI adapter and can not accept
any SCSI commands: https://lkml.org/lkml/2020/4/10/47

At first I posted a fix (https://lkml.org/lkml/2020/4/21/1318) trying
to resolve the issue from hv_storvsc, but with the help of
Bart Van Assche, I realized it's better to fix software_resume(),
since this looks like a generic issue, not only pertaining to SCSI.

Cc: All applicable <[email protected]>
Signed-off-by: Dexuan Cui <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/power/hibernate.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -898,6 +898,13 @@ static int software_resume(void)
error = freeze_processes();
if (error)
goto Close_Finish;
+
+ error = freeze_kernel_threads();
+ if (error) {
+ thaw_processes();
+ goto Close_Finish;
+ }
+
error = load_image_and_restore();
thaw_processes();
Finish:


2020-05-04 18:11:33

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 41/73] scsi: qla2xxx: set UNLOADING before waiting for session deletion

From: Martin Wilck <[email protected]>

commit 856e152a3c08bf7987cbd41900741d83d9cddc8e upstream.

The purpose of the UNLOADING flag is to avoid port login procedures to
continue when a controller is in the process of shutting down. It makes
sense to set this flag before starting session teardown.

Furthermore, use atomic test_and_set_bit() to avoid the shutdown being run
multiple times in parallel. In qla2x00_disable_board_on_pci_error(), the
test for UNLOADING is postponed until after the check for an already
disabled PCI board.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 45235022da99 ("scsi: qla2xxx: Fix driver unload by shutting down chip")
Reviewed-by: Arun Easi <[email protected]>
Reviewed-by: Daniel Wagner <[email protected]>
Reviewed-by: Roman Bolshakov <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Martin Wilck <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/qla2xxx/qla_os.c | 32 ++++++++++++++------------------
1 file changed, 14 insertions(+), 18 deletions(-)

--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -3720,6 +3720,13 @@ qla2x00_remove_one(struct pci_dev *pdev)
}
qla2x00_wait_for_hba_ready(base_vha);

+ /*
+ * if UNLOADING flag is already set, then continue unload,
+ * where it was set first.
+ */
+ if (test_and_set_bit(UNLOADING, &base_vha->dpc_flags))
+ return;
+
if (IS_QLA25XX(ha) || IS_QLA2031(ha) || IS_QLA27XX(ha) ||
IS_QLA28XX(ha)) {
if (ha->flags.fw_started)
@@ -3738,15 +3745,6 @@ qla2x00_remove_one(struct pci_dev *pdev)

qla2x00_wait_for_sess_deletion(base_vha);

- /*
- * if UNLOAD flag is already set, then continue unload,
- * where it was set first.
- */
- if (test_bit(UNLOADING, &base_vha->dpc_flags))
- return;
-
- set_bit(UNLOADING, &base_vha->dpc_flags);
-
qla_nvme_delete(base_vha);

dma_free_coherent(&ha->pdev->dev,
@@ -6044,13 +6042,6 @@ qla2x00_disable_board_on_pci_error(struc
struct pci_dev *pdev = ha->pdev;
scsi_qla_host_t *base_vha = pci_get_drvdata(ha->pdev);

- /*
- * if UNLOAD flag is already set, then continue unload,
- * where it was set first.
- */
- if (test_bit(UNLOADING, &base_vha->dpc_flags))
- return;
-
ql_log(ql_log_warn, base_vha, 0x015b,
"Disabling adapter.\n");

@@ -6061,9 +6052,14 @@ qla2x00_disable_board_on_pci_error(struc
return;
}

- qla2x00_wait_for_sess_deletion(base_vha);
+ /*
+ * if UNLOADING flag is already set, then continue unload,
+ * where it was set first.
+ */
+ if (test_and_set_bit(UNLOADING, &base_vha->dpc_flags))
+ return;

- set_bit(UNLOADING, &base_vha->dpc_flags);
+ qla2x00_wait_for_sess_deletion(base_vha);

qla2x00_delete_all_vps(ha, base_vha);



2020-05-04 18:11:33

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 08/73] drm/qxl: qxl_release leak in qxl_draw_dirty_fb()

From: Vasily Averin <[email protected]>

commit 85e9b88af1e6164f19ec71381efd5e2bcfc17620 upstream.

ret should be changed to release allocated struct qxl_release

Cc: [email protected]
Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations")
Signed-off-by: Vasily Averin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/qxl/qxl_draw.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/qxl/qxl_draw.c
+++ b/drivers/gpu/drm/qxl/qxl_draw.c
@@ -209,9 +209,10 @@ void qxl_draw_dirty_fb(struct qxl_device
goto out_release_backoff;

rects = drawable_set_clipping(qdev, num_clips, clips_bo);
- if (!rects)
+ if (!rects) {
+ ret = -EINVAL;
goto out_release_backoff;
-
+ }
drawable = (struct qxl_drawable *)qxl_release_map(qdev, release);

drawable->clip.type = SPICE_CLIP_TYPE_RECTS;


2020-05-04 18:11:42

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 70/73] drm/i915: Use proper fault mask in interrupt postinstall too

From: Matt Roper <[email protected]>

commit 8598eb781cf68fd6cb67c479f1479ae58bd54fb9 upstream.

The IRQ postinstall handling had open-coded pipe fault mask selection
that never got updated for gen11. Switch it to use
gen8_de_pipe_fault_mask() to ensure we don't miss updates for new
platforms.

Cc: José Roberto de Souza <[email protected]>
Fixes: d506a65d56fd ("drm/i915: Catch GTT fault errors for gen11+ planes")
Signed-off-by: Matt Roper <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Ville Syrjälä <[email protected]>
(cherry picked from commit 869129ee0c624a78c74e50b51635e183196cd2c6)
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i915/i915_irq.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3321,7 +3321,8 @@ static void gen8_de_irq_postinstall(stru
{
struct intel_uncore *uncore = &dev_priv->uncore;

- u32 de_pipe_masked = GEN8_PIPE_CDCLK_CRC_DONE;
+ u32 de_pipe_masked = gen8_de_pipe_fault_mask(dev_priv) |
+ GEN8_PIPE_CDCLK_CRC_DONE;
u32 de_pipe_enables;
u32 de_port_masked = GEN8_AUX_CHANNEL_A;
u32 de_port_enables;
@@ -3332,13 +3333,10 @@ static void gen8_de_irq_postinstall(stru
de_misc_masked |= GEN8_DE_MISC_GSE;

if (INTEL_GEN(dev_priv) >= 9) {
- de_pipe_masked |= GEN9_DE_PIPE_IRQ_FAULT_ERRORS;
de_port_masked |= GEN9_AUX_CHANNEL_B | GEN9_AUX_CHANNEL_C |
GEN9_AUX_CHANNEL_D;
if (IS_GEN9_LP(dev_priv))
de_port_masked |= BXT_DE_PORT_GMBUS;
- } else {
- de_pipe_masked |= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
}

if (INTEL_GEN(dev_priv) >= 11)


2020-05-04 18:11:46

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 67/73] drm/i915/selftests: Fix i915_address_space refcnt leak

From: Xiyu Yang <[email protected]>

commit 5d5e100a20348c336e56df604b353b978f8adbb9 upstream.

igt_ppgtt_pin_update() invokes i915_gem_context_get_vm_rcu(), which
returns a reference of the i915_address_space object to "vm" with
increased refcount.

When igt_ppgtt_pin_update() returns, "vm" becomes invalid, so the
refcount should be decreased to keep refcount balanced.

The reference counting issue happens in two exception handling paths of
igt_ppgtt_pin_update(). When i915_gem_object_create_internal() returns
IS_ERR, the refcnt increased by i915_gem_context_get_vm_rcu() is not
decreased, causing a refcnt leak.

Fix this issue by jumping to "out_vm" label when
i915_gem_object_create_internal() returns IS_ERR.

Fixes: a4e7ccdac38e ("drm/i915: Move context management under GEM")
Signed-off-by: Xiyu Yang <[email protected]>
Signed-off-by: Xin Tan <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit e07c7606a00c4361bad72ff4e72ed0dfbefa23b0)
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1578,8 +1578,10 @@ static int igt_ppgtt_pin_update(void *ar
unsigned int page_size = BIT(first);

obj = i915_gem_object_create_internal(dev_priv, page_size);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ if (IS_ERR(obj)) {
+ err = PTR_ERR(obj);
+ goto out_vm;
+ }

vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma)) {
@@ -1632,8 +1634,10 @@ static int igt_ppgtt_pin_update(void *ar
}

obj = i915_gem_object_create_internal(dev_priv, PAGE_SIZE);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ if (IS_ERR(obj)) {
+ err = PTR_ERR(obj);
+ goto out_vm;
+ }

vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma)) {


2020-05-04 18:11:53

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 65/73] Fix use after free in get_tree_bdev()

From: David Howells <[email protected]>

commit dd7bc8158b413e0b580c491e8bd18cb91057c7c2 upstream.

Commit 6fcf0c72e4b9, a fix to get_tree_bdev() put a missing blkdev_put() in
the wrong place, before a warnf() that displays the bdev under
consideration rather after it.

This results in a silent lockup in printk("%pg") called via warnf() from
get_tree_bdev() under some circumstances when there's a race with the
blockdev being frozen. This can be caused by xfstests/tests/generic/085 in
combination with Lukas Czerner's ext4 mount API conversion patchset. It
looks like it ought to occur with other users of get_tree_bdev() such as
XFS, but apparently doesn't.

Fix this by switching the order of the lines.

Fixes: 6fcf0c72e4b9 ("vfs: add missing blkdev_put() in get_tree_bdev()")
Reported-by: Lukas Czerner <[email protected]>
Signed-off-by: David Howells <[email protected]>
cc: Ian Kent <[email protected]>
cc: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/super.c
+++ b/fs/super.c
@@ -1302,8 +1302,8 @@ int get_tree_bdev(struct fs_context *fc,
mutex_lock(&bdev->bd_fsfreeze_mutex);
if (bdev->bd_fsfreeze_count > 0) {
mutex_unlock(&bdev->bd_fsfreeze_mutex);
- blkdev_put(bdev, mode);
warnf(fc, "%pg: Can't mount, blockdev is frozen", bdev);
+ blkdev_put(bdev, mode);
return -EBUSY;
}



2020-05-04 18:12:01

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 62/73] iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system

From: Suravee Suthikulpanit <[email protected]>

commit b74aa02d7a30ee5e262072a7d6e8deff10b37924 upstream.

Currently, system fails to boot because the legacy interrupt remapping
mode does not enable 128-bit IRTE (GA), which is required for x2APIC
support.

Fix by using AMD_IOMMU_GUEST_IR_LEGACY_GA mode when booting with
kernel option amd_iommu_intr=legacy instead. The initialization
logic will check GASup and automatically fallback to using
AMD_IOMMU_GUEST_IR_LEGACY if GA mode is not supported.

Fixes: 3928aa3f5775 ("iommu/amd: Detect and enable guest vAPIC support")
Signed-off-by: Suravee Suthikulpanit <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/iommu/amd_iommu_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2936,7 +2936,7 @@ static int __init parse_amd_iommu_intr(c
{
for (; *str; ++str) {
if (strncmp(str, "legacy", 6) == 0) {
- amd_iommu_guest_ir = AMD_IOMMU_GUEST_IR_LEGACY;
+ amd_iommu_guest_ir = AMD_IOMMU_GUEST_IR_LEGACY_GA;
break;
}
if (strncmp(str, "vapic", 5) == 0) {


2020-05-04 18:12:14

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 54/73] vfio: avoid possible overflow in vfio_iommu_type1_pin_pages

From: Yan Zhao <[email protected]>

commit 0ea971f8dcd6dee78a9a30ea70227cf305f11ff7 upstream.

add parentheses to avoid possible vaddr overflow.

Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices")
Signed-off-by: Yan Zhao <[email protected]>
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/vfio/vfio_iommu_type1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -554,7 +554,7 @@ static int vfio_iommu_type1_pin_pages(vo
continue;
}

- remote_vaddr = dma->vaddr + iova - dma->iova;
+ remote_vaddr = dma->vaddr + (iova - dma->iova);
ret = vfio_pin_page_external(dma, remote_vaddr, &phys_pfn[i],
do_accounting);
if (ret)


2020-05-04 18:12:19

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 66/73] nvme: prevent double free in nvme_alloc_ns() error handling

From: Niklas Cassel <[email protected]>

commit 132be62387c7a72a38872676c18b0dfae264adb8 upstream.

When jumping to the out_put_disk label, we will call put_disk(), which will
trigger a call to disk_release(), which calls blk_put_queue().

Later in the cleanup code, we do blk_cleanup_queue(), which will also call
blk_put_queue().

Putting the queue twice is incorrect, and will generate a KASAN splat.

Set the disk->queue pointer to NULL, before calling put_disk(), so that the
first call to blk_put_queue() will not free the queue.

The second call to blk_put_queue() uses another pointer to the same queue,
so this call will still free the queue.

Fixes: 85136c010285 ("lightnvm: simplify geometry enumeration")
Signed-off-by: Niklas Cassel <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/nvme/host/core.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3580,6 +3580,8 @@ static int nvme_alloc_ns(struct nvme_ctr

return 0;
out_put_disk:
+ /* prevent double queue cleanup */
+ ns->disk->queue = NULL;
put_disk(ns->disk);
out_unlink_ns:
mutex_lock(&ctrl->subsys->lock);


2020-05-04 18:12:22

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 49/73] RDMA/core: Fix race between destroy and release FD object

From: Leon Romanovsky <[email protected]>

commit f0abc761bbb9418876cc4d1ebc473e4ea6352e42 upstream.

The call to ->lookup_put() was too early and it caused an unlock of the
read/write protection of the uobject after the FD was put. This allows a
race:

CPU1 CPU2
rdma_lookup_put_uobject()
lookup_put_fd_uobject()
fput()
fput()
uverbs_uobject_fd_release()
WARN_ON(uverbs_try_lock_object(uobj,
UVERBS_LOOKUP_WRITE));
atomic_dec(usecnt)

Fix the code by changing the order, first unlock and call to
->lookup_put() after that.

Fixes: 3832125624b7 ("IB/core: Add support for idr types")
Link: https://lore.kernel.org/r/[email protected]
Suggested-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/rdma_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/core/rdma_core.c
+++ b/drivers/infiniband/core/rdma_core.c
@@ -678,7 +678,6 @@ void rdma_lookup_put_uobject(struct ib_u
enum rdma_lookup_mode mode)
{
assert_uverbs_usecnt(uobj, mode);
- uobj->uapi_object->type_class->lookup_put(uobj, mode);
/*
* In order to unlock an object, either decrease its usecnt for
* read access or zero it in case of exclusive access. See
@@ -695,6 +694,7 @@ void rdma_lookup_put_uobject(struct ib_u
break;
}

+ uobj->uapi_object->type_class->lookup_put(uobj, mode);
/* Pairs with the kref obtained by type->lookup_get */
uverbs_uobject_put(uobj);
}


2020-05-04 18:12:26

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 48/73] RDMA/core: Fix overwriting of uobj in case of error

From: Leon Romanovsky <[email protected]>

commit 83a2670212215a569ed133efc10c92055c96cc8c upstream.

In case of failure to get file, the uobj is overwritten and causes to
supply bad pointer as an input to uverbs_uobject_put().

BUG: KASAN: null-ptr-deref in atomic_fetch_sub include/asm-generic/atomic-instrumented.h:199 [inline]
BUG: KASAN: null-ptr-deref in refcount_sub_and_test include/linux/refcount.h:253 [inline]
BUG: KASAN: null-ptr-deref in refcount_dec_and_test include/linux/refcount.h:281 [inline]
BUG: KASAN: null-ptr-deref in kref_put include/linux/kref.h:64 [inline]
BUG: KASAN: null-ptr-deref in uverbs_uobject_put+0x22/0x90 drivers/infiniband/core/rdma_core.c:57
Write of size 4 at addr 0000000000000030 by task syz-executor.4/1691

CPU: 1 PID: 1691 Comm: syz-executor.4 Not tainted 5.6.0 #17
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x94/0xce lib/dump_stack.c:118
__kasan_report+0x10c/0x190 mm/kasan/report.c:515
kasan_report+0x32/0x50 mm/kasan/common.c:625
check_memory_region_inline mm/kasan/generic.c:187 [inline]
check_memory_region+0x16d/0x1c0 mm/kasan/generic.c:193
atomic_fetch_sub include/asm-generic/atomic-instrumented.h:199 [inline]
refcount_sub_and_test include/linux/refcount.h:253 [inline]
refcount_dec_and_test include/linux/refcount.h:281 [inline]
kref_put include/linux/kref.h:64 [inline]
uverbs_uobject_put+0x22/0x90 drivers/infiniband/core/rdma_core.c:57
alloc_begin_fd_uobject+0x1d0/0x250 drivers/infiniband/core/rdma_core.c:486
rdma_alloc_begin_uobject+0xa8/0xf0 drivers/infiniband/core/rdma_core.c:509
__uobj_alloc include/rdma/uverbs_std_types.h:117 [inline]
ib_uverbs_create_comp_channel+0x16d/0x230 drivers/infiniband/core/uverbs_cmd.c:982
ib_uverbs_write+0xaa5/0xdf0 drivers/infiniband/core/uverbs_main.c:665
__vfs_write+0x7c/0x100 fs/read_write.c:494
vfs_write+0x168/0x4a0 fs/read_write.c:558
ksys_write+0xc8/0x200 fs/read_write.c:611
do_syscall_64+0x9c/0x390 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x466479
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007efe9f6a7c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000466479
RDX: 0000000000000018 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00007efe9f6a86bc R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000005
R13: 0000000000000bf2 R14: 00000000004cb80a R15: 00000000006fefc0

Fixes: 849e149063bd ("RDMA/core: Do not allow alloc_commit to fail")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/rdma_core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/infiniband/core/rdma_core.c
+++ b/drivers/infiniband/core/rdma_core.c
@@ -474,16 +474,15 @@ alloc_begin_fd_uobject(const struct uver
filp = anon_inode_getfile(fd_type->name, fd_type->fops, NULL,
fd_type->flags);
if (IS_ERR(filp)) {
+ uverbs_uobject_put(uobj);
uobj = ERR_CAST(filp);
- goto err_uobj;
+ goto err_fd;
}
uobj->object = filp;

uobj->id = new_fd;
return uobj;

-err_uobj:
- uverbs_uobject_put(uobj);
err_fd:
put_unused_fd(new_fd);
return uobj;


2020-05-04 18:12:31

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 64/73] ALSA: opti9xx: shut up gcc-10 range warning

From: Arnd Bergmann <[email protected]>

commit 5ce00760a84848d008554c693ceb6286f4d9c509 upstream.

gcc-10 points out a few instances of suspicious integer arithmetic
leading to value truncation:

sound/isa/opti9xx/opti92x-ad1848.c: In function 'snd_opti9xx_configure':
sound/isa/opti9xx/opti92x-ad1848.c:322:43: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_opti9xx_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow]
322 | (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask)))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
sound/isa/opti9xx/opti92x-ad1848.c:351:3: note: in expansion of macro 'snd_opti9xx_write_mask'
351 | snd_opti9xx_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff);
| ^~~~~~~~~~~~~~~~~~~~~~
sound/isa/opti9xx/miro.c: In function 'snd_miro_configure':
sound/isa/opti9xx/miro.c:873:40: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_miro_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow]
873 | (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask)))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
sound/isa/opti9xx/miro.c:1010:3: note: in expansion of macro 'snd_miro_write_mask'
1010 | snd_miro_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff);
| ^~~~~~~~~~~~~~~~~~~

These are all harmless here as only the low 8 bit are passed down
anyway. Change the macros to inline functions to make the code
more readable and also avoid the warning.

Strictly speaking those functions also need locking to make the
read/write pair atomic, but it seems unlikely that anyone would
still run into that issue.

Fixes: 1841f613fd2e ("[ALSA] Add snd-miro driver")
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/isa/opti9xx/miro.c | 9 ++++++---
sound/isa/opti9xx/opti92x-ad1848.c | 9 ++++++---
2 files changed, 12 insertions(+), 6 deletions(-)

--- a/sound/isa/opti9xx/miro.c
+++ b/sound/isa/opti9xx/miro.c
@@ -867,10 +867,13 @@ static void snd_miro_write(struct snd_mi
spin_unlock_irqrestore(&chip->lock, flags);
}

+static inline void snd_miro_write_mask(struct snd_miro *chip,
+ unsigned char reg, unsigned char value, unsigned char mask)
+{
+ unsigned char oldval = snd_miro_read(chip, reg);

-#define snd_miro_write_mask(chip, reg, value, mask) \
- snd_miro_write(chip, reg, \
- (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask)))
+ snd_miro_write(chip, reg, (oldval & ~mask) | (value & mask));
+}

/*
* Proc Interface
--- a/sound/isa/opti9xx/opti92x-ad1848.c
+++ b/sound/isa/opti9xx/opti92x-ad1848.c
@@ -317,10 +317,13 @@ static void snd_opti9xx_write(struct snd
}


-#define snd_opti9xx_write_mask(chip, reg, value, mask) \
- snd_opti9xx_write(chip, reg, \
- (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask)))
+static inline void snd_opti9xx_write_mask(struct snd_opti9xx *chip,
+ unsigned char reg, unsigned char value, unsigned char mask)
+{
+ unsigned char oldval = snd_opti9xx_read(chip, reg);

+ snd_opti9xx_write(chip, reg, (oldval & ~mask) | (value & mask));
+}

static int snd_opti9xx_configure(struct snd_opti9xx *chip,
long port,


2020-05-04 18:12:41

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 50/73] RDMA/cm: Fix ordering of xa_alloc_cyclic() in ib_create_cm_id()

From: Jason Gunthorpe <[email protected]>

commit e8dc4e885c459343970b25acd9320fe9ee5492e7 upstream.

xa_alloc_cyclic() is a SMP release to be paired with some later acquire
during xa_load() as part of cm_acquire_id().

As such, xa_alloc_cyclic() must be done after the cm_id is fully
initialized, in particular, it absolutely must be after the
refcount_set(), otherwise the refcount_inc() in cm_acquire_id() may not
see the set.

As there are several cases where a reader will be able to use the
id.local_id after cm_acquire_id in the IB_CM_IDLE state there needs to be
an unfortunate split into a NULL allocate and a finalizing xa_store.

Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/cm.c | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)

--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -572,18 +572,6 @@ static int cm_init_av_by_path(struct sa_
return 0;
}

-static int cm_alloc_id(struct cm_id_private *cm_id_priv)
-{
- int err;
- u32 id;
-
- err = xa_alloc_cyclic_irq(&cm.local_id_table, &id, cm_id_priv,
- xa_limit_32b, &cm.local_id_next, GFP_KERNEL);
-
- cm_id_priv->id.local_id = (__force __be32)id ^ cm.random_id_operand;
- return err;
-}
-
static u32 cm_local_id(__be32 local_id)
{
return (__force u32) (local_id ^ cm.random_id_operand);
@@ -825,6 +813,7 @@ struct ib_cm_id *ib_create_cm_id(struct
void *context)
{
struct cm_id_private *cm_id_priv;
+ u32 id;
int ret;

cm_id_priv = kzalloc(sizeof *cm_id_priv, GFP_KERNEL);
@@ -836,9 +825,6 @@ struct ib_cm_id *ib_create_cm_id(struct
cm_id_priv->id.cm_handler = cm_handler;
cm_id_priv->id.context = context;
cm_id_priv->id.remote_cm_qpn = 1;
- ret = cm_alloc_id(cm_id_priv);
- if (ret)
- goto error;

spin_lock_init(&cm_id_priv->lock);
init_completion(&cm_id_priv->comp);
@@ -847,11 +833,20 @@ struct ib_cm_id *ib_create_cm_id(struct
INIT_LIST_HEAD(&cm_id_priv->altr_list);
atomic_set(&cm_id_priv->work_count, -1);
refcount_set(&cm_id_priv->refcount, 1);
+
+ ret = xa_alloc_cyclic_irq(&cm.local_id_table, &id, NULL, xa_limit_32b,
+ &cm.local_id_next, GFP_KERNEL);
+ if (ret)
+ goto error;
+ cm_id_priv->id.local_id = (__force __be32)id ^ cm.random_id_operand;
+ xa_store_irq(&cm.local_id_table, cm_local_id(cm_id_priv->id.local_id),
+ cm_id_priv, GFP_KERNEL);
+
return &cm_id_priv->id;

error:
kfree(cm_id_priv);
- return ERR_PTR(-ENOMEM);
+ return ERR_PTR(ret);
}
EXPORT_SYMBOL(ib_create_cm_id);



2020-05-04 18:12:57

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 73/73] io_uring: statx must grab the file table for valid fd

From: Jens Axboe <[email protected]>

commit 5b0bbee4732cbd58aa98213d4c11a366356bba3d upstream.

Clay reports that OP_STATX fails for a test case with a valid fd
and empty path:

-- Test 0: statx:fd 3: SUCCEED, file mode 100755
-- Test 1: statx:path ./uring_statx: SUCCEED, file mode 100755
-- Test 2: io_uring_statx:fd 3: FAIL, errno 9: Bad file descriptor
-- Test 3: io_uring_statx:path ./uring_statx: SUCCEED, file mode 100755

This is due to statx not grabbing the process file table, hence we can't
lookup the fd in async context. If the fd is valid, ensure that we grab
the file table so we can grab the file from async context.

Cc: [email protected] # v5.6
Reported-by: Clay Harris <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/io_uring.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -479,6 +479,7 @@ enum {
REQ_F_COMP_LOCKED_BIT,
REQ_F_NEED_CLEANUP_BIT,
REQ_F_OVERFLOW_BIT,
+ REQ_F_NO_FILE_TABLE_BIT,
};

enum {
@@ -521,6 +522,8 @@ enum {
REQ_F_NEED_CLEANUP = BIT(REQ_F_NEED_CLEANUP_BIT),
/* in overflow list */
REQ_F_OVERFLOW = BIT(REQ_F_OVERFLOW_BIT),
+ /* doesn't need file table for this request */
+ REQ_F_NO_FILE_TABLE = BIT(REQ_F_NO_FILE_TABLE_BIT),
};

/*
@@ -711,6 +714,7 @@ static const struct io_op_def io_op_defs
.needs_file = 1,
.fd_non_neg = 1,
.needs_fs = 1,
+ .file_table = 1,
},
[IORING_OP_READ] = {
.needs_mm = 1,
@@ -2843,8 +2847,12 @@ static int io_statx(struct io_kiocb *req
struct kstat stat;
int ret;

- if (force_nonblock)
+ if (force_nonblock) {
+ /* only need file table for an actual valid fd */
+ if (ctx->dfd == -1 || ctx->dfd == AT_FDCWD)
+ req->flags |= REQ_F_NO_FILE_TABLE;
return -EAGAIN;
+ }

if (vfs_stat_set_lookup_flags(&lookup_flags, ctx->how.flags))
return -EINVAL;
@@ -4632,7 +4640,7 @@ static int io_grab_files(struct io_kiocb
int ret = -EBADF;
struct io_ring_ctx *ctx = req->ctx;

- if (req->work.files)
+ if (req->work.files || (req->flags & REQ_F_NO_FILE_TABLE))
return 0;
if (!ctx->ring_file)
return -EBADF;


2020-05-04 18:12:59

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 43/73] RDMA/mlx5: Set GRH fields in query QP on RoCE

From: Aharon Landau <[email protected]>

commit 2d7e3ff7b6f2c614eb21d0dc348957a47eaffb57 upstream.

GRH fields such as sgid_index, hop limit, et. are set in the QP context
when QP is created/modified.

Currently, when query QP is performed, we fill the GRH fields only if the
GRH bit is set in the QP context, but this bit is not set for RoCE. Adjust
the check so we will set all relevant data for the RoCE too.

Since this data is returned to userspace, the below is an ABI regression.

Fixes: d8966fcd4c25 ("IB/core: Use rdma_ah_attr accessor functions")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Aharon Landau <[email protected]>
Reviewed-by: Maor Gottlieb <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/hw/mlx5/qp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -5545,7 +5545,9 @@ static void to_rdma_ah_attr(struct mlx5_
rdma_ah_set_path_bits(ah_attr, path->grh_mlid & 0x7f);
rdma_ah_set_static_rate(ah_attr,
path->static_rate ? path->static_rate - 5 : 0);
- if (path->grh_mlid & (1 << 7)) {
+
+ if (path->grh_mlid & (1 << 7) ||
+ ah_attr->type == RDMA_AH_ATTR_TYPE_ROCE) {
u32 tc_fl = be32_to_cpu(path->tclass_flowlabel);

rdma_ah_set_grh(ah_attr, NULL,


2020-05-04 18:13:00

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 30/73] Drivers: hv: vmbus: Fix Suspend-to-Idle for Generation-2 VM

From: Dexuan Cui <[email protected]>

commit 1a06d017fb3f388734ffbe5dedee6f8c3af5f2db upstream.

Before the hibernation patchset (e.g. f53335e3289f), in a Generation-2
Linux VM on Hyper-V, the user can run "echo freeze > /sys/power/state" to
freeze the system, i.e. Suspend-to-Idle. The user can press the keyboard
or move the mouse to wake up the VM.

With the hibernation patchset, Linux VM on Hyper-V can hibernate to disk,
but Suspend-to-Idle is broken: when the synthetic keyboard/mouse are
suspended, there is no way to wake up the VM.

Fix the issue by not suspending and resuming the vmbus devices upon
Suspend-to-Idle.

Fixes: f53335e3289f ("Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation")
Cc: [email protected]
Reviewed-by: Michael Kelley <[email protected]>
Signed-off-by: Dexuan Cui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Wei Liu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/hv/vmbus_drv.c | 43 ++++++++++++++++++++++++++++++++++---------
1 file changed, 34 insertions(+), 9 deletions(-)

--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -978,6 +978,9 @@ static int vmbus_resume(struct device *c

return drv->resume(dev);
}
+#else
+#define vmbus_suspend NULL
+#define vmbus_resume NULL
#endif /* CONFIG_PM_SLEEP */

/*
@@ -997,11 +1000,22 @@ static void vmbus_device_release(struct
}

/*
- * Note: we must use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS rather than
- * SET_SYSTEM_SLEEP_PM_OPS: see the comment before vmbus_bus_pm.
+ * Note: we must use the "noirq" ops: see the comment before vmbus_bus_pm.
+ *
+ * suspend_noirq/resume_noirq are set to NULL to support Suspend-to-Idle: we
+ * shouldn't suspend the vmbus devices upon Suspend-to-Idle, otherwise there
+ * is no way to wake up a Generation-2 VM.
+ *
+ * The other 4 ops are for hibernation.
*/
+
static const struct dev_pm_ops vmbus_pm = {
- SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(vmbus_suspend, vmbus_resume)
+ .suspend_noirq = NULL,
+ .resume_noirq = NULL,
+ .freeze_noirq = vmbus_suspend,
+ .thaw_noirq = vmbus_resume,
+ .poweroff_noirq = vmbus_suspend,
+ .restore_noirq = vmbus_resume,
};

/* The one and only one */
@@ -2281,6 +2295,9 @@ static int vmbus_bus_resume(struct devic

return 0;
}
+#else
+#define vmbus_bus_suspend NULL
+#define vmbus_bus_resume NULL
#endif /* CONFIG_PM_SLEEP */

static const struct acpi_device_id vmbus_acpi_device_ids[] = {
@@ -2291,16 +2308,24 @@ static const struct acpi_device_id vmbus
MODULE_DEVICE_TABLE(acpi, vmbus_acpi_device_ids);

/*
- * Note: we must use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS rather than
- * SET_SYSTEM_SLEEP_PM_OPS, otherwise NIC SR-IOV can not work, because the
- * "pci_dev_pm_ops" uses the "noirq" callbacks: in the resume path, the
- * pci "noirq" restore callback runs before "non-noirq" callbacks (see
+ * Note: we must use the "no_irq" ops, otherwise hibernation can not work with
+ * PCI device assignment, because "pci_dev_pm_ops" uses the "noirq" ops: in
+ * the resume path, the pci "noirq" restore op runs before "non-noirq" op (see
* resume_target_kernel() -> dpm_resume_start(), and hibernation_restore() ->
* dpm_resume_end()). This means vmbus_bus_resume() and the pci-hyperv's
- * resume callback must also run via the "noirq" callbacks.
+ * resume callback must also run via the "noirq" ops.
+ *
+ * Set suspend_noirq/resume_noirq to NULL for Suspend-to-Idle: see the comment
+ * earlier in this file before vmbus_pm.
*/
+
static const struct dev_pm_ops vmbus_bus_pm = {
- SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(vmbus_bus_suspend, vmbus_bus_resume)
+ .suspend_noirq = NULL,
+ .resume_noirq = NULL,
+ .freeze_noirq = vmbus_bus_suspend,
+ .thaw_noirq = vmbus_bus_resume,
+ .poweroff_noirq = vmbus_bus_suspend,
+ .restore_noirq = vmbus_bus_resume
};

static struct acpi_driver vmbus_acpi_driver = {


2020-05-04 18:13:02

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 27/73] ALSA: pcm: oss: Place the plugin buffer overflow checks correctly

From: Takashi Iwai <[email protected]>

commit 4285de0725b1bf73608abbcd35ad7fd3ddc0b61e upstream.

The checks of the plugin buffer overflow in the previous fix by commit
f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
are put in the wrong places mistakenly, which leads to the expected
(repeated) sound when the rate plugin is involved. Fix in the right
places.

Also, at those right places, the zero check is needed for the
termination node, so added there as well, and let's get it done,
finally.

Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/core/oss/pcm_plugin.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)

--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -211,21 +211,23 @@ static snd_pcm_sframes_t plug_client_siz
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
plugin = snd_pcm_plug_last(plug);
while (plugin && drv_frames > 0) {
- if (check_size && drv_frames > plugin->buf_frames)
- drv_frames = plugin->buf_frames;
plugin_prev = plugin->prev;
if (plugin->src_frames)
drv_frames = plugin->src_frames(plugin, drv_frames);
+ if (check_size && plugin->buf_frames &&
+ drv_frames > plugin->buf_frames)
+ drv_frames = plugin->buf_frames;
plugin = plugin_prev;
}
} else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
plugin = snd_pcm_plug_first(plug);
while (plugin && drv_frames > 0) {
plugin_next = plugin->next;
+ if (check_size && plugin->buf_frames &&
+ drv_frames > plugin->buf_frames)
+ drv_frames = plugin->buf_frames;
if (plugin->dst_frames)
drv_frames = plugin->dst_frames(plugin, drv_frames);
- if (check_size && drv_frames > plugin->buf_frames)
- drv_frames = plugin->buf_frames;
plugin = plugin_next;
}
} else
@@ -251,26 +253,28 @@ static snd_pcm_sframes_t plug_slave_size
plugin = snd_pcm_plug_first(plug);
while (plugin && frames > 0) {
plugin_next = plugin->next;
+ if (check_size && plugin->buf_frames &&
+ frames > plugin->buf_frames)
+ frames = plugin->buf_frames;
if (plugin->dst_frames) {
frames = plugin->dst_frames(plugin, frames);
if (frames < 0)
return frames;
}
- if (check_size && frames > plugin->buf_frames)
- frames = plugin->buf_frames;
plugin = plugin_next;
}
} else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
plugin = snd_pcm_plug_last(plug);
while (plugin) {
- if (check_size && frames > plugin->buf_frames)
- frames = plugin->buf_frames;
plugin_prev = plugin->prev;
if (plugin->src_frames) {
frames = plugin->src_frames(plugin, frames);
if (frames < 0)
return frames;
}
+ if (check_size && plugin->buf_frames &&
+ frames > plugin->buf_frames)
+ frames = plugin->buf_frames;
plugin = plugin_prev;
}
} else


2020-05-04 18:13:06

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 06/73] drm/i915/gem: Hold obj->vma.lock over for_each_ggtt_vma()

From: Chris Wilson <[email protected]>

commit f524a774a4ff702bdfbfc094c9dd463ee623252b upstream.

While the ggtt vma are protected by their object lifetime, the list
continues until it hits a non-ggtt vma, and that vma is not protected
and may be freed as we inspect it. Hence, we require the obj->vma.lock
to protect the list as we iterate.

An example of forgetting to hold the obj->vma.lock is

[1642834.464973] general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP PTI
[1642834.464977] CPU: 3 PID: 1954 Comm: Xorg Not tainted 5.6.0-300.fc32.x86_64 #1
[1642834.464979] Hardware name: LENOVO 20ARS25701/20ARS25701, BIOS GJET94WW (2.44 ) 09/14/2017
[1642834.465021] RIP: 0010:i915_gem_object_set_tiling+0x2c0/0x3e0 [i915]
[1642834.465024] Code: 8b 84 24 18 01 00 00 f6 c4 80 74 59 49 8b 94 24 a0 00 00 00 49 8b 84 24 e0 00 00 00 49 8b 74 24 10 48 8b 92 30 01 00 00 89 c7 <80> ba 0a 06 00 00 03 0f 87 86 00 00 00 ba 00 00 08 00 b9 00 00 10
[1642834.465025] RSP: 0018:ffffa98780c77d60 EFLAGS: 00010282
[1642834.465028] RAX: ffff8d232bfb2578 RBX: 0000000000000002 RCX: ffff8d25873a0000
[1642834.465029] RDX: dead000000000122 RSI: fffff0af8ac6e408 RDI: 000000002bfb2578
[1642834.465030] RBP: ffff8d25873a0000 R08: ffff8d252bfb5638 R09: 0000000000000000
[1642834.465031] R10: 0000000000000000 R11: ffff8d252bfb5640 R12: ffffa987801cb8f8
[1642834.465032] R13: 0000000000001000 R14: ffff8d233e972e50 R15: ffff8d233e972d00
[1642834.465034] FS: 00007f6a3d327f00(0000) GS:ffff8d25926c0000(0000) knlGS:0000000000000000
[1642834.465036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1642834.465037] CR2: 00007f6a2064d000 CR3: 00000002fb57c001 CR4: 00000000001606e0
[1642834.465038] Call Trace:
[1642834.465083] i915_gem_set_tiling_ioctl+0x122/0x230 [i915]
[1642834.465121] ? i915_gem_object_set_tiling+0x3e0/0x3e0 [i915]
[1642834.465151] drm_ioctl_kernel+0x86/0xd0 [drm]
[1642834.465156] ? avc_has_perm+0x3b/0x160
[1642834.465178] drm_ioctl+0x206/0x390 [drm]
[1642834.465216] ? i915_gem_object_set_tiling+0x3e0/0x3e0 [i915]
[1642834.465221] ? selinux_file_ioctl+0x122/0x1c0
[1642834.465226] ? __do_munmap+0x24b/0x4d0
[1642834.465231] ksys_ioctl+0x82/0xc0
[1642834.465235] __x64_sys_ioctl+0x16/0x20
[1642834.465238] do_syscall_64+0x5b/0xf0
[1642834.465243] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[1642834.465245] RIP: 0033:0x7f6a3d7b047b
[1642834.465247] Code: 0f 1e fa 48 8b 05 1d aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed a9 0c 00 f7 d8 64 89 01 48
[1642834.465249] RSP: 002b:00007ffe71adba28 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[1642834.465251] RAX: ffffffffffffffda RBX: 000055f99048fa40 RCX: 00007f6a3d7b047b
[1642834.465253] RDX: 00007ffe71adba30 RSI: 00000000c0106461 RDI: 000000000000000e
[1642834.465254] RBP: 0000000000000002 R08: 000055f98f3f1798 R09: 0000000000000002
[1642834.465255] R10: 0000000000001000 R11: 0000000000000246 R12: 0000000000000080
[1642834.465257] R13: 000055f98f3f1690 R14: 00000000c0106461 R15: 00007ffe71adba30

Now to take the spinlock during the list iteration, we need to break it
down into two phases. In the first phase under the lock, we cannot sleep
and so must defer the actual work to a second list, protected by the
ggtt->mutex.

We also need to hold the spinlock during creation of a new vma to
serialise with updates of the tiling on the object.

Reported-by: Dave Airlie <[email protected]>
Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: <[email protected]> # v5.5+
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit cb593e5d2b6d3ad489669914d9fd1c64c7a4a6af)
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 20 ++++++++++++++++++--
drivers/gpu/drm/i915/i915_vma.c | 10 ++++++----
2 files changed, 24 insertions(+), 6 deletions(-)

--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
@@ -183,21 +183,35 @@ i915_gem_object_fence_prepare(struct drm
int tiling_mode, unsigned int stride)
{
struct i915_ggtt *ggtt = &to_i915(obj->base.dev)->ggtt;
- struct i915_vma *vma;
+ struct i915_vma *vma, *vn;
+ LIST_HEAD(unbind);
int ret = 0;

if (tiling_mode == I915_TILING_NONE)
return 0;

mutex_lock(&ggtt->vm.mutex);
+
+ spin_lock(&obj->vma.lock);
for_each_ggtt_vma(vma, obj) {
+ GEM_BUG_ON(vma->vm != &ggtt->vm);
+
if (i915_vma_fence_prepare(vma, tiling_mode, stride))
continue;

+ list_move(&vma->vm_link, &unbind);
+ }
+ spin_unlock(&obj->vma.lock);
+
+ list_for_each_entry_safe(vma, vn, &unbind, vm_link) {
ret = __i915_vma_unbind(vma);
- if (ret)
+ if (ret) {
+ /* Restore the remaining vma on an error */
+ list_splice(&unbind, &ggtt->vm.bound_list);
break;
+ }
}
+
mutex_unlock(&ggtt->vm.mutex);

return ret;
@@ -269,6 +283,7 @@ i915_gem_object_set_tiling(struct drm_i9
}
mutex_unlock(&obj->mm.lock);

+ spin_lock(&obj->vma.lock);
for_each_ggtt_vma(vma, obj) {
vma->fence_size =
i915_gem_fence_size(i915, vma->size, tiling, stride);
@@ -279,6 +294,7 @@ i915_gem_object_set_tiling(struct drm_i9
if (vma->fence)
vma->fence->dirty = true;
}
+ spin_unlock(&obj->vma.lock);

obj->tiling_and_stride = tiling | stride;
i915_gem_object_unlock(obj);
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -158,16 +158,18 @@ vma_create(struct drm_i915_gem_object *o

GEM_BUG_ON(!IS_ALIGNED(vma->size, I915_GTT_PAGE_SIZE));

+ spin_lock(&obj->vma.lock);
+
if (i915_is_ggtt(vm)) {
if (unlikely(overflows_type(vma->size, u32)))
- goto err_vma;
+ goto err_unlock;

vma->fence_size = i915_gem_fence_size(vm->i915, vma->size,
i915_gem_object_get_tiling(obj),
i915_gem_object_get_stride(obj));
if (unlikely(vma->fence_size < vma->size || /* overflow */
vma->fence_size > vm->total))
- goto err_vma;
+ goto err_unlock;

GEM_BUG_ON(!IS_ALIGNED(vma->fence_size, I915_GTT_MIN_ALIGNMENT));

@@ -179,8 +181,6 @@ vma_create(struct drm_i915_gem_object *o
__set_bit(I915_VMA_GGTT_BIT, __i915_vma_flags(vma));
}

- spin_lock(&obj->vma.lock);
-
rb = NULL;
p = &obj->vma.tree.rb_node;
while (*p) {
@@ -225,6 +225,8 @@ vma_create(struct drm_i915_gem_object *o

return vma;

+err_unlock:
+ spin_unlock(&obj->vma.lock);
err_vma:
i915_vma_free(vma);
return ERR_PTR(-E2BIG);


2020-05-04 18:13:10

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 24/73] ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID

From: Takashi Iwai <[email protected]>

commit 547d2c9cf4f1f72adfecacbd5b093681fb0e8b3e upstream.

The USB vendor ID of NuPrime DAC-10 is not 16b0 but 16d0.

Fixes: f656891c6619 ("ALSA: usb-audio: add more quirks for DSD interfaces")
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/usb/quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1643,7 +1643,7 @@ u64 snd_usb_interface_dsd_format_quirks(

case USB_ID(0x0d8c, 0x0316): /* Hegel HD12 DSD */
case USB_ID(0x10cb, 0x0103): /* The Bit Opus #3; with fp->dsd_raw */
- case USB_ID(0x16b0, 0x06b2): /* NuPrime DAC-10 */
+ case USB_ID(0x16d0, 0x06b2): /* NuPrime DAC-10 */
case USB_ID(0x16d0, 0x09dd): /* Encore mDSD */
case USB_ID(0x16d0, 0x0733): /* Furutech ADL Stratos */
case USB_ID(0x16d0, 0x09db): /* NuPrime Audio DAC-9 */


2020-05-04 18:13:11

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 36/73] dm verity fec: fix hash block number in verity_fec_decode

From: Sunwook Eom <[email protected]>

commit ad4e80a639fc61d5ecebb03caa5cdbfb91fcebfc upstream.

The error correction data is computed as if data and hash blocks
were concatenated. But hash block number starts from v->hash_start.
So, we have to calculate hash block number based on that.

Fixes: a739ff3f543af ("dm verity: add support for forward error correction")
Cc: [email protected]
Signed-off-by: Sunwook Eom <[email protected]>
Reviewed-by: Sami Tolvanen <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/dm-verity-fec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -435,7 +435,7 @@ int verity_fec_decode(struct dm_verity *
fio->level++;

if (type == DM_VERITY_BLOCK_TYPE_METADATA)
- block += v->data_blocks;
+ block = block - v->hash_start + v->data_blocks;

/*
* For RS(M, N), the continuous FEC data is divided into blocks of N


2020-05-04 18:13:16

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 20/73] mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY

From: Martin Blumenstingl <[email protected]>

commit e53b868b3cf5beeaa2f851ec6740112bf4d6a8cb upstream.

The Meson SDIO controller uses the DAT0 lane for hardware busy
detection. Set MMC_CAP_WAIT_WHILE_BUSY accordingly. This fixes
the following error observed with Linux 5.7 (pre-rc-1):
mmc1: Card stuck being busy! __mmc_poll_for_busy
blk_update_request: I/O error, dev mmcblk1, sector 17111080 op
0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0

Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs")
Signed-off-by: Martin Blumenstingl <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mmc/host/meson-mx-sdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/mmc/host/meson-mx-sdio.c
+++ b/drivers/mmc/host/meson-mx-sdio.c
@@ -570,7 +570,7 @@ static int meson_mx_mmc_add_host(struct
mmc->f_max = clk_round_rate(host->cfg_div_clk,
clk_get_rate(host->parent_clk));

- mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23;
+ mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23 | MMC_CAP_WAIT_WHILE_BUSY;
mmc->ops = &meson_mx_mmc_ops;

ret = mmc_of_parse(mmc);


2020-05-04 18:13:17

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 02/73] dma-buf: Fix SET_NAME ioctl uapi

From: Daniel Vetter <[email protected]>

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 <[email protected]>
Cc: Chenbo Feng <[email protected]>
Cc: Greg Hackmann <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Martin Liu <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Tested-by: Martin Liu <[email protected]>
Reviewed-by: Martin Liu <[email protected]>
Signed-off-by: Sumit Semwal <[email protected]>
[sumits: updated some checkpatch fixes, corrected author email]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/dma-buf/dma-buf.c | 3 ++-
include/uapi/linux/dma-buf.h | 6 ++++++
2 files changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -388,7 +388,8 @@ static long dma_buf_ioctl(struct file *f

return ret;

- case DMA_BUF_SET_NAME:
+ case DMA_BUF_SET_NAME_A:
+ case DMA_BUF_SET_NAME_B:
return dma_buf_set_name(dmabuf, (const char __user *)arg);

default:
--- a/include/uapi/linux/dma-buf.h
+++ b/include/uapi/linux/dma-buf.h
@@ -39,6 +39,12 @@ struct dma_buf_sync {

#define DMA_BUF_BASE 'b'
#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)
+
+/* 32/64bitness of this uapi was botched in android, there's no difference
+ * between them in actual uapi, they're just different numbers.
+ */
#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *)
+#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, u32)
+#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64)

#endif


2020-05-04 18:13:25

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 56/73] iommu/qcom: Fix local_base status check

From: Tang Bin <[email protected]>

commit b52649aee6243ea661905bdc5fbe28cc5f6dec76 upstream.

The function qcom_iommu_device_probe() does not perform sufficient
error checking after executing devm_ioremap_resource(), which can
result in crashes if a critical error path is encountered.

Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu")
Signed-off-by: Tang Bin <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/iommu/qcom_iommu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/iommu/qcom_iommu.c
+++ b/drivers/iommu/qcom_iommu.c
@@ -813,8 +813,11 @@ static int qcom_iommu_device_probe(struc
qcom_iommu->dev = dev;

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res)
+ if (res) {
qcom_iommu->local_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(qcom_iommu->local_base))
+ return PTR_ERR(qcom_iommu->local_base);
+ }

qcom_iommu->iface_clk = devm_clk_get(dev, "iface");
if (IS_ERR(qcom_iommu->iface_clk)) {


2020-05-04 18:13:26

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 12/73] btrfs: fix transaction leak in btrfs_recover_relocation

From: Xiyu Yang <[email protected]>

commit 1402d17dfd9657be0da8458b2079d03c2d61c86a upstream.

btrfs_recover_relocation() invokes btrfs_join_transaction(), which joins
a btrfs_trans_handle object into transactions and returns a reference of
it with increased refcount to "trans".

When btrfs_recover_relocation() returns, "trans" becomes invalid, so the
refcount should be decreased to keep refcount balanced.

The reference counting issue happens in one exception handling path of
btrfs_recover_relocation(). When read_fs_root() failed, the refcnt
increased by btrfs_join_transaction() is not decreased, causing a refcnt
leak.

Fix this issue by calling btrfs_end_transaction() on this error path
when read_fs_root() failed.

Fixes: 79787eaab461 ("btrfs: replace many BUG_ONs with proper error handling")
CC: [email protected] # 4.4+
Reviewed-by: Filipe Manana <[email protected]>
Signed-off-by: Xiyu Yang <[email protected]>
Signed-off-by: Xin Tan <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/relocation.c | 1 +
1 file changed, 1 insertion(+)

--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -4614,6 +4614,7 @@ int btrfs_recover_relocation(struct btrf
if (IS_ERR(fs_root)) {
err = PTR_ERR(fs_root);
list_add_tail(&reloc_root->root_list, &reloc_roots);
+ btrfs_end_transaction(trans);
goto out_unset;
}



2020-05-04 18:13:41

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 17/73] mmc: sdhci-xenon: fix annoying 1.8V regulator warning

From: Marek Behún <[email protected]>

commit bb32e1987bc55ce1db400faf47d85891da3c9b9f upstream.

For some reason the Host Control2 register of the Xenon SDHCI controller
sometimes reports the bit representing 1.8V signaling as 0 when read
after it was written as 1. Subsequent read reports 1.

This causes the sdhci_start_signal_voltage_switch function to report
1.8V regulator output did not become stable

When CONFIG_PM is enabled, the host is suspended and resumend many
times, and in each resume the switch to 1.8V is called, and so the
kernel log reports this message annoyingly often.

Do an empty read of the Host Control2 register in Xenon's
.voltage_switch method to circumvent this.

This patch fixes this particular problem on Turris MOX.

Signed-off-by: Marek Behún <[email protected]>
Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V...")
Cc: [email protected] # v4.16+
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mmc/host/sdhci-xenon.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -235,6 +235,16 @@ static void xenon_voltage_switch(struct
{
/* Wait for 5ms after set 1.8V signal enable bit */
usleep_range(5000, 5500);
+
+ /*
+ * For some reason the controller's Host Control2 register reports
+ * the bit representing 1.8V signaling as 0 when read after it was
+ * written as 1. Subsequent read reports 1.
+ *
+ * Since this may cause some issues, do an empty read of the Host
+ * Control2 register here to circumvent this.
+ */
+ sdhci_readw(host, SDHCI_HOST_CONTROL2);
}

static const struct sdhci_ops sdhci_xenon_ops = {


2020-05-04 18:13:55

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 14/73] btrfs: fix partial loss of prealloc extent past i_size after fsync

From: Filipe Manana <[email protected]>

commit f135cea30de5f74d5bfb5116682073841fb4af8f upstream.

When we have an inode with a prealloc extent that starts at an offset
lower than the i_size and there is another prealloc extent that starts at
an offset beyond i_size, we can end up losing part of the first prealloc
extent (the part that starts at i_size) and have an implicit hole if we
fsync the file and then have a power failure.

Consider the following example with comments explaining how and why it
happens.

$ mkfs.btrfs -f /dev/sdb
$ mount /dev/sdb /mnt

# Create our test file with 2 consecutive prealloc extents, each with a
# size of 128Kb, and covering the range from 0 to 256Kb, with a file
# size of 0.
$ xfs_io -f -c "falloc -k 0 128K" /mnt/foo
$ xfs_io -c "falloc -k 128K 128K" /mnt/foo

# Fsync the file to record both extents in the log tree.
$ xfs_io -c "fsync" /mnt/foo

# Now do a redudant extent allocation for the range from 0 to 64Kb.
# This will merely increase the file size from 0 to 64Kb. Instead we
# could also do a truncate to set the file size to 64Kb.
$ xfs_io -c "falloc 0 64K" /mnt/foo

# Fsync the file, so we update the inode item in the log tree with the
# new file size (64Kb). This also ends up setting the number of bytes
# for the first prealloc extent to 64Kb. This is done by the truncation
# at btrfs_log_prealloc_extents().
# This means that if a power failure happens after this, a write into
# the file range 64Kb to 128Kb will not use the prealloc extent and
# will result in allocation of a new extent.
$ xfs_io -c "fsync" /mnt/foo

# Now set the file size to 256K with a truncate and then fsync the file.
# Since no changes happened to the extents, the fsync only updates the
# i_size in the inode item at the log tree. This results in an implicit
# hole for the file range from 64Kb to 128Kb, something which fsck will
# complain when not using the NO_HOLES feature if we replay the log
# after a power failure.
$ xfs_io -c "truncate 256K" -c "fsync" /mnt/foo

So instead of always truncating the log to the inode's current i_size at
btrfs_log_prealloc_extents(), check first if there's a prealloc extent
that starts at an offset lower than the i_size and with a length that
crosses the i_size - if there is one, just make sure we truncate to a
size that corresponds to the end offset of that prealloc extent, so
that we don't lose the part of that extent that starts at i_size if a
power failure happens.

A test case for fstests follows soon.

Fixes: 31d11b83b96f ("Btrfs: fix duplicate extents after fsync of file with prealloc extents")
CC: [email protected] # 4.14+
Signed-off-by: Filipe Manana <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/tree-log.c | 43 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 40 insertions(+), 3 deletions(-)

--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4211,6 +4211,9 @@ static int btrfs_log_prealloc_extents(st
const u64 ino = btrfs_ino(inode);
struct btrfs_path *dst_path = NULL;
bool dropped_extents = false;
+ u64 truncate_offset = i_size;
+ struct extent_buffer *leaf;
+ int slot;
int ins_nr = 0;
int start_slot;
int ret;
@@ -4225,9 +4228,43 @@ static int btrfs_log_prealloc_extents(st
if (ret < 0)
goto out;

+ /*
+ * We must check if there is a prealloc extent that starts before the
+ * i_size and crosses the i_size boundary. This is to ensure later we
+ * truncate down to the end of that extent and not to the i_size, as
+ * otherwise we end up losing part of the prealloc extent after a log
+ * replay and with an implicit hole if there is another prealloc extent
+ * that starts at an offset beyond i_size.
+ */
+ ret = btrfs_previous_item(root, path, ino, BTRFS_EXTENT_DATA_KEY);
+ if (ret < 0)
+ goto out;
+
+ if (ret == 0) {
+ struct btrfs_file_extent_item *ei;
+
+ leaf = path->nodes[0];
+ slot = path->slots[0];
+ ei = btrfs_item_ptr(leaf, slot, struct btrfs_file_extent_item);
+
+ if (btrfs_file_extent_type(leaf, ei) ==
+ BTRFS_FILE_EXTENT_PREALLOC) {
+ u64 extent_end;
+
+ btrfs_item_key_to_cpu(leaf, &key, slot);
+ extent_end = key.offset +
+ btrfs_file_extent_num_bytes(leaf, ei);
+
+ if (extent_end > i_size)
+ truncate_offset = extent_end;
+ }
+ } else {
+ ret = 0;
+ }
+
while (true) {
- struct extent_buffer *leaf = path->nodes[0];
- int slot = path->slots[0];
+ leaf = path->nodes[0];
+ slot = path->slots[0];

if (slot >= btrfs_header_nritems(leaf)) {
if (ins_nr > 0) {
@@ -4265,7 +4302,7 @@ static int btrfs_log_prealloc_extents(st
ret = btrfs_truncate_inode_items(trans,
root->log_root,
&inode->vfs_inode,
- i_size,
+ truncate_offset,
BTRFS_EXTENT_DATA_KEY);
} while (ret == -EAGAIN);
if (ret)


2020-05-04 18:14:25

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 37/73] dm writecache: fix data corruption when reloading the target

From: Mikulas Patocka <[email protected]>

commit 31b22120194b5c0d460f59e0c98504de1d3f1f14 upstream.

The dm-writecache reads metadata in the target constructor. However, when
we reload the target, there could be another active instance running on
the same device. This is the sequence of operations when doing a reload:

1. construct new target
2. suspend old target
3. resume new target
4. destroy old target

Metadata that were written by the old target between steps 1 and 2 would
not be visible by the new target.

Fix the data corruption by loading the metadata in the resume handler.

Also, validate block_size is at least as large as both the devices'
logical block size and only read 1 block from the metadata during
target constructor -- no need to read entirety of metadata now that it
is done during resume.

Fixes: 48debafe4f2f ("dm: add writecache target")
Cc: [email protected] # v4.18+
Signed-off-by: Mikulas Patocka <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/dm-writecache.c | 52 ++++++++++++++++++++++++++++++++-------------
1 file changed, 37 insertions(+), 15 deletions(-)

--- a/drivers/md/dm-writecache.c
+++ b/drivers/md/dm-writecache.c
@@ -882,6 +882,24 @@ static int writecache_alloc_entries(stru
return 0;
}

+static int writecache_read_metadata(struct dm_writecache *wc, sector_t n_sectors)
+{
+ struct dm_io_region region;
+ struct dm_io_request req;
+
+ region.bdev = wc->ssd_dev->bdev;
+ region.sector = wc->start_sector;
+ region.count = n_sectors;
+ req.bi_op = REQ_OP_READ;
+ req.bi_op_flags = REQ_SYNC;
+ req.mem.type = DM_IO_VMA;
+ req.mem.ptr.vma = (char *)wc->memory_map;
+ req.client = wc->dm_io;
+ req.notify.fn = NULL;
+
+ return dm_io(&req, 1, &region, NULL);
+}
+
static void writecache_resume(struct dm_target *ti)
{
struct dm_writecache *wc = ti->private;
@@ -892,8 +910,18 @@ static void writecache_resume(struct dm_

wc_lock(wc);

- if (WC_MODE_PMEM(wc))
+ if (WC_MODE_PMEM(wc)) {
persistent_memory_invalidate_cache(wc->memory_map, wc->memory_map_size);
+ } else {
+ r = writecache_read_metadata(wc, wc->metadata_sectors);
+ if (r) {
+ size_t sb_entries_offset;
+ writecache_error(wc, r, "unable to read metadata: %d", r);
+ sb_entries_offset = offsetof(struct wc_memory_superblock, entries);
+ memset((char *)wc->memory_map + sb_entries_offset, -1,
+ (wc->metadata_sectors << SECTOR_SHIFT) - sb_entries_offset);
+ }
+ }

wc->tree = RB_ROOT;
INIT_LIST_HEAD(&wc->lru);
@@ -2005,6 +2033,12 @@ static int writecache_ctr(struct dm_targ
ti->error = "Invalid block size";
goto bad;
}
+ if (wc->block_size < bdev_logical_block_size(wc->dev->bdev) ||
+ wc->block_size < bdev_logical_block_size(wc->ssd_dev->bdev)) {
+ r = -EINVAL;
+ ti->error = "Block size is smaller than device logical block size";
+ goto bad;
+ }
wc->block_size_bits = __ffs(wc->block_size);

wc->max_writeback_jobs = MAX_WRITEBACK_JOBS;
@@ -2093,8 +2127,6 @@ invalid_optional:
goto bad;
}
} else {
- struct dm_io_region region;
- struct dm_io_request req;
size_t n_blocks, n_metadata_blocks;
uint64_t n_bitmap_bits;

@@ -2151,19 +2183,9 @@ invalid_optional:
goto bad;
}

- region.bdev = wc->ssd_dev->bdev;
- region.sector = wc->start_sector;
- region.count = wc->metadata_sectors;
- req.bi_op = REQ_OP_READ;
- req.bi_op_flags = REQ_SYNC;
- req.mem.type = DM_IO_VMA;
- req.mem.ptr.vma = (char *)wc->memory_map;
- req.client = wc->dm_io;
- req.notify.fn = NULL;
-
- r = dm_io(&req, 1, &region, NULL);
+ r = writecache_read_metadata(wc, wc->block_size >> SECTOR_SHIFT);
if (r) {
- ti->error = "Unable to read metadata";
+ ti->error = "Unable to read first block of metadata";
goto bad;
}
}


2020-05-04 18:14:38

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 53/73] dmaengine: hisilicon: Fix build error without PCI_MSI

From: YueHaibing <[email protected]>

commit ae148b43516d90756ff8255925fb7df142b0c76e upstream.

If PCI_MSI is not set, building fais:

drivers/dma/hisi_dma.c: In function ‘hisi_dma_free_irq_vectors’:
drivers/dma/hisi_dma.c:138:2: error: implicit declaration of function ‘pci_free_irq_vectors’;
did you mean ‘pci_alloc_irq_vectors’? [-Werror=implicit-function-declaration]
pci_free_irq_vectors(data);
^~~~~~~~~~~~~~~~~~~~

Make HISI_DMA depends on PCI_MSI to fix this.

Fixes: e9f08b65250d ("dmaengine: hisilicon: Add Kunpeng DMA engine support")
Signed-off-by: YueHaibing <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/dma/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -241,7 +241,8 @@ config FSL_RAID

config HISI_DMA
tristate "HiSilicon DMA Engine support"
- depends on ARM64 || (COMPILE_TEST && PCI_MSI)
+ depends on ARM64 || COMPILE_TEST
+ depends on PCI_MSI
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
help


2020-05-04 18:14:48

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 05/73] drm/amd/display: Fix green screen issue after suspend

From: Rodrigo Siqueira <[email protected]>

commit 87b7ebc2e16c14d32a912f18206a4d6cc9abc3e8 upstream.

[why]
We have seen a green screen after resume from suspend in a Raven system
connected with two displays (HDMI and DP) on X based system. We noticed
that this issue is related to bad DCC metadata from user space which may
generate hangs and consequently an underflow on HUBP. After taking a
deep look at the code path we realized that after resume we try to
restore the commit with the DCC enabled framebuffer but the framebuffer
is no longer valid.

[how]
This problem was only reported on Raven based system and after suspend,
for this reason, this commit adds a new parameter on
fill_plane_dcc_attributes() to give the option of disabling DCC
programmatically. In summary, for disabling DCC we first verify if is a
Raven system and if it is in suspend; if both conditions are true we
disable DCC temporarily, otherwise, it is enabled.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1099
Co-developed-by: Nicholas Kazlauskas <[email protected]>
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Signed-off-by: Rodrigo Siqueira <[email protected]>
Reviewed-by: Nicholas Kazlauskas <[email protected]>
Acked-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 ++++++++++++++++------
1 file changed, 29 insertions(+), 9 deletions(-)

--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3212,7 +3212,8 @@ fill_plane_dcc_attributes(struct amdgpu_
const union dc_tiling_info *tiling_info,
const uint64_t info,
struct dc_plane_dcc_param *dcc,
- struct dc_plane_address *address)
+ struct dc_plane_address *address,
+ bool force_disable_dcc)
{
struct dc *dc = adev->dm.dc;
struct dc_dcc_surface_param input;
@@ -3224,6 +3225,9 @@ fill_plane_dcc_attributes(struct amdgpu_
memset(&input, 0, sizeof(input));
memset(&output, 0, sizeof(output));

+ if (force_disable_dcc)
+ return 0;
+
if (!offset)
return 0;

@@ -3273,7 +3277,8 @@ fill_plane_buffer_attributes(struct amdg
union dc_tiling_info *tiling_info,
struct plane_size *plane_size,
struct dc_plane_dcc_param *dcc,
- struct dc_plane_address *address)
+ struct dc_plane_address *address,
+ bool force_disable_dcc)
{
const struct drm_framebuffer *fb = &afb->base;
int ret;
@@ -3379,7 +3384,8 @@ fill_plane_buffer_attributes(struct amdg

ret = fill_plane_dcc_attributes(adev, afb, format, rotation,
plane_size, tiling_info,
- tiling_flags, dcc, address);
+ tiling_flags, dcc, address,
+ force_disable_dcc);
if (ret)
return ret;
}
@@ -3471,7 +3477,8 @@ fill_dc_plane_info_and_addr(struct amdgp
const struct drm_plane_state *plane_state,
const uint64_t tiling_flags,
struct dc_plane_info *plane_info,
- struct dc_plane_address *address)
+ struct dc_plane_address *address,
+ bool force_disable_dcc)
{
const struct drm_framebuffer *fb = plane_state->fb;
const struct amdgpu_framebuffer *afb =
@@ -3550,7 +3557,8 @@ fill_dc_plane_info_and_addr(struct amdgp
plane_info->rotation, tiling_flags,
&plane_info->tiling_info,
&plane_info->plane_size,
- &plane_info->dcc, address);
+ &plane_info->dcc, address,
+ force_disable_dcc);
if (ret)
return ret;

@@ -3573,6 +3581,7 @@ static int fill_dc_plane_attributes(stru
struct dc_plane_info plane_info;
uint64_t tiling_flags;
int ret;
+ bool force_disable_dcc = false;

ret = fill_dc_scaling_info(plane_state, &scaling_info);
if (ret)
@@ -3587,9 +3596,11 @@ static int fill_dc_plane_attributes(stru
if (ret)
return ret;

+ force_disable_dcc = adev->asic_type == CHIP_RAVEN && adev->in_suspend;
ret = fill_dc_plane_info_and_addr(adev, plane_state, tiling_flags,
&plane_info,
- &dc_plane_state->address);
+ &dc_plane_state->address,
+ force_disable_dcc);
if (ret)
return ret;

@@ -5171,6 +5182,7 @@ static int dm_plane_helper_prepare_fb(st
uint64_t tiling_flags;
uint32_t domain;
int r;
+ bool force_disable_dcc = false;

dm_plane_state_old = to_dm_plane_state(plane->state);
dm_plane_state_new = to_dm_plane_state(new_state);
@@ -5229,11 +5241,13 @@ static int dm_plane_helper_prepare_fb(st
dm_plane_state_old->dc_state != dm_plane_state_new->dc_state) {
struct dc_plane_state *plane_state = dm_plane_state_new->dc_state;

+ force_disable_dcc = adev->asic_type == CHIP_RAVEN && adev->in_suspend;
fill_plane_buffer_attributes(
adev, afb, plane_state->format, plane_state->rotation,
tiling_flags, &plane_state->tiling_info,
&plane_state->plane_size, &plane_state->dcc,
- &plane_state->address);
+ &plane_state->address,
+ force_disable_dcc);
}

return 0;
@@ -6514,7 +6528,12 @@ static void amdgpu_dm_commit_planes(stru
fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
&bundle->plane_infos[planes_count],
- &bundle->flip_addrs[planes_count].address);
+ &bundle->flip_addrs[planes_count].address,
+ false);
+
+ DRM_DEBUG_DRIVER("plane: id=%d dcc_en=%d\n",
+ new_plane_state->plane->index,
+ bundle->plane_infos[planes_count].dcc.enable);

bundle->surface_updates[planes_count].plane_info =
&bundle->plane_infos[planes_count];
@@ -7935,7 +7954,8 @@ dm_determine_update_type_for_commit(stru
ret = fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
plane_info,
- &flip_addr->address);
+ &flip_addr->address,
+ false);
if (ret)
goto cleanup;



2020-05-04 18:14:56

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 32/73] selinux: properly handle multiple messages in selinux_netlink_send()

From: Paul Moore <[email protected]>

commit fb73974172ffaaf57a7c42f35424d9aece1a5af6 upstream.

Fix the SELinux netlink_send hook to properly handle multiple netlink
messages in a single sk_buff; each message is parsed and subject to
SELinux access control. Prior to this patch, SELinux only inspected
the first message in the sk_buff.

Cc: [email protected]
Reported-by: Dmitry Vyukov <[email protected]>
Reviewed-by: Stephen Smalley <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
security/selinux/hooks.c | 70 ++++++++++++++++++++++++++++++-----------------
1 file changed, 45 insertions(+), 25 deletions(-)

--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5829,40 +5829,60 @@ static unsigned int selinux_ipv6_postrou

static int selinux_netlink_send(struct sock *sk, struct sk_buff *skb)
{
- int err = 0;
- u32 perm;
+ int rc = 0;
+ unsigned int msg_len;
+ unsigned int data_len = skb->len;
+ unsigned char *data = skb->data;
struct nlmsghdr *nlh;
struct sk_security_struct *sksec = sk->sk_security;
+ u16 sclass = sksec->sclass;
+ u32 perm;

- if (skb->len < NLMSG_HDRLEN) {
- err = -EINVAL;
- goto out;
- }
- nlh = nlmsg_hdr(skb);
+ while (data_len >= nlmsg_total_size(0)) {
+ nlh = (struct nlmsghdr *)data;

- err = selinux_nlmsg_lookup(sksec->sclass, nlh->nlmsg_type, &perm);
- if (err) {
- if (err == -EINVAL) {
+ /* NOTE: the nlmsg_len field isn't reliably set by some netlink
+ * users which means we can't reject skb's with bogus
+ * length fields; our solution is to follow what
+ * netlink_rcv_skb() does and simply skip processing at
+ * messages with length fields that are clearly junk
+ */
+ if (nlh->nlmsg_len < NLMSG_HDRLEN || nlh->nlmsg_len > data_len)
+ return 0;
+
+ rc = selinux_nlmsg_lookup(sclass, nlh->nlmsg_type, &perm);
+ if (rc == 0) {
+ rc = sock_has_perm(sk, perm);
+ if (rc)
+ return rc;
+ } else if (rc == -EINVAL) {
+ /* -EINVAL is a missing msg/perm mapping */
pr_warn_ratelimited("SELinux: unrecognized netlink"
- " message: protocol=%hu nlmsg_type=%hu sclass=%s"
- " pid=%d comm=%s\n",
- sk->sk_protocol, nlh->nlmsg_type,
- secclass_map[sksec->sclass - 1].name,
- task_pid_nr(current), current->comm);
- if (!enforcing_enabled(&selinux_state) ||
- security_get_allow_unknown(&selinux_state))
- err = 0;
+ " message: protocol=%hu nlmsg_type=%hu sclass=%s"
+ " pid=%d comm=%s\n",
+ sk->sk_protocol, nlh->nlmsg_type,
+ secclass_map[sclass - 1].name,
+ task_pid_nr(current), current->comm);
+ if (enforcing_enabled(&selinux_state) &&
+ !security_get_allow_unknown(&selinux_state))
+ return rc;
+ rc = 0;
+ } else if (rc == -ENOENT) {
+ /* -ENOENT is a missing socket/class mapping, ignore */
+ rc = 0;
+ } else {
+ return rc;
}

- /* Ignore */
- if (err == -ENOENT)
- err = 0;
- goto out;
+ /* move to the next message after applying netlink padding */
+ msg_len = NLMSG_ALIGN(nlh->nlmsg_len);
+ if (msg_len >= data_len)
+ return 0;
+ data_len -= msg_len;
+ data += msg_len;
}

- err = sock_has_perm(sk, perm);
-out:
- return err;
+ return rc;
}

static void ipc_init_security(struct ipc_security_struct *isec, u16 sclass)


2020-05-04 18:48:23

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 22/73] crypto: caam - fix the address of the last entry of S/G

From: Iuliana Prodan <[email protected]>

commit 55b3209acbb01cb02b1ee6b1afe80d83b1aab36d upstream.

For skcipher algorithms, the input, output HW S/G tables
look like this: [IV, src][dst, IV]
Now, we can have 2 conditions here:
- there is no IV;
- src and dst are equal (in-place encryption) and scattered
and the error is an "off-by-one" in the HW S/G table.

This issue was seen with KASAN:
BUG: KASAN: slab-out-of-bounds in skcipher_edesc_alloc+0x95c/0x1018

Read of size 4 at addr ffff000022a02958 by task cryptomgr_test/321

CPU: 2 PID: 321 Comm: cryptomgr_test Not tainted
5.6.0-rc1-00165-ge4ef8383-dirty #4
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load4+0x90/0xb0
skcipher_edesc_alloc+0x95c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0x178/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18

Allocated by task 321:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
skcipher_edesc_alloc+0x21c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0x178/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18

Freed by task 0:
(stack is not available)

The buggy address belongs to the object at ffff000022a02800
which belongs to the cache dma-kmalloc-512 of size 512
The buggy address is located 344 bytes inside of
512-byte region [ffff000022a02800, ffff000022a02a00)
The buggy address belongs to the page:
page:fffffe00006a8000 refcount:1 mapcount:0 mapping:ffff00093200c400
index:0x0 compound_mapcount: 0
flags: 0xffff00000010200(slab|head)
raw: 0ffff00000010200 dead000000000100 dead000000000122 ffff00093200c400
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff000022a02800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff000022a02880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff000022a02900: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
^
ffff000022a02980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff000022a02a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

Fixes: 334d37c9e263 ("crypto: caam - update IV using HW support")
Cc: <[email protected]> # v5.3+
Signed-off-by: Iuliana Prodan <[email protected]>
Reviewed-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/caam/caamalg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -1791,7 +1791,7 @@ static struct skcipher_edesc *skcipher_e

if (ivsize || mapped_dst_nents > 1)
sg_to_sec4_set_last(edesc->sec4_sg + dst_sg_idx +
- mapped_dst_nents);
+ mapped_dst_nents - 1 + !!ivsize);

if (sec4_sg_bytes) {
edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg,


2020-05-04 18:48:27

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 03/73] drm/amdgpu: invalidate L2 before SDMA IBs (v2)

From: Marek Olšák <[email protected]>

commit fdf83646c0542ecfb9adc4db8f741a1f43dca058 upstream.

This fixes GPU hangs due to cache coherency issues.

v2: Split the version bump to a separate patch

Signed-off-by: Marek Olšák <[email protected]>
Reviewed-by: Christian König <[email protected]>
Tested-by: Pierre-Eric Pelloux-Prayer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/amd/amdgpu/navi10_sdma_pkt_open.h | 16 ++++++++++++++++
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 14 +++++++++++++-
2 files changed, 29 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/amd/amdgpu/navi10_sdma_pkt_open.h
+++ b/drivers/gpu/drm/amd/amdgpu/navi10_sdma_pkt_open.h
@@ -73,6 +73,22 @@
#define SDMA_OP_AQL_COPY 0
#define SDMA_OP_AQL_BARRIER_OR 0

+#define SDMA_GCR_RANGE_IS_PA (1 << 18)
+#define SDMA_GCR_SEQ(x) (((x) & 0x3) << 16)
+#define SDMA_GCR_GL2_WB (1 << 15)
+#define SDMA_GCR_GL2_INV (1 << 14)
+#define SDMA_GCR_GL2_DISCARD (1 << 13)
+#define SDMA_GCR_GL2_RANGE(x) (((x) & 0x3) << 11)
+#define SDMA_GCR_GL2_US (1 << 10)
+#define SDMA_GCR_GL1_INV (1 << 9)
+#define SDMA_GCR_GLV_INV (1 << 8)
+#define SDMA_GCR_GLK_INV (1 << 7)
+#define SDMA_GCR_GLK_WB (1 << 6)
+#define SDMA_GCR_GLM_INV (1 << 5)
+#define SDMA_GCR_GLM_WB (1 << 4)
+#define SDMA_GCR_GL1_RANGE(x) (((x) & 0x3) << 2)
+#define SDMA_GCR_GLI_INV(x) (((x) & 0x3) << 0)
+
/*define for op field*/
#define SDMA_PKT_HEADER_op_offset 0
#define SDMA_PKT_HEADER_op_mask 0x000000FF
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
@@ -382,6 +382,18 @@ static void sdma_v5_0_ring_emit_ib(struc
unsigned vmid = AMDGPU_JOB_GET_VMID(job);
uint64_t csa_mc_addr = amdgpu_sdma_get_csa_mc_addr(ring, vmid);

+ /* Invalidate L2, because if we don't do it, we might get stale cache
+ * lines from previous IBs.
+ */
+ amdgpu_ring_write(ring, SDMA_PKT_HEADER_OP(SDMA_OP_GCR_REQ));
+ amdgpu_ring_write(ring, 0);
+ amdgpu_ring_write(ring, (SDMA_GCR_GL2_INV |
+ SDMA_GCR_GL2_WB |
+ SDMA_GCR_GLM_INV |
+ SDMA_GCR_GLM_WB) << 16);
+ amdgpu_ring_write(ring, 0xffffff80);
+ amdgpu_ring_write(ring, 0xffff);
+
/* An IB packet must end on a 8 DW boundary--the next dword
* must be on a 8-dword boundary. Our IB packet below is 6
* dwords long, thus add x number of NOPs, such that, in
@@ -1597,7 +1609,7 @@ static const struct amdgpu_ring_funcs sd
SOC15_FLUSH_GPU_TLB_NUM_WREG * 3 +
SOC15_FLUSH_GPU_TLB_NUM_REG_WAIT * 6 * 2 +
10 + 10 + 10, /* sdma_v5_0_ring_emit_fence x3 for user fence, vm fence */
- .emit_ib_size = 7 + 6, /* sdma_v5_0_ring_emit_ib */
+ .emit_ib_size = 5 + 7 + 6, /* sdma_v5_0_ring_emit_ib */
.emit_ib = sdma_v5_0_ring_emit_ib,
.emit_fence = sdma_v5_0_ring_emit_fence,
.emit_pipeline_sync = sdma_v5_0_ring_emit_pipeline_sync,


2020-05-04 18:48:37

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 58/73] dmaengine: fix channel index enumeration

From: Dave Jiang <[email protected]>

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 <[email protected]>
Signed-off-by: Dave Jiang <[email protected]>
Tested-by: Yixin Zhang <[email protected]>
Link: https://lore.kernel.org/r/158679961260.7674.8485924270472851852.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/dma/dmaengine.c | 60 +++++++++++++++++++---------------------------
include/linux/dmaengine.h | 4 +--
2 files changed, 28 insertions(+), 36 deletions(-)

--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -151,10 +151,6 @@ static void chan_dev_release(struct devi
struct dma_chan_dev *chan_dev;

chan_dev = container_of(dev, typeof(*chan_dev), device);
- if (atomic_dec_and_test(chan_dev->idr_ref)) {
- ida_free(&dma_ida, chan_dev->dev_id);
- kfree(chan_dev->idr_ref);
- }
kfree(chan_dev);
}

@@ -952,27 +948,9 @@ static int get_dma_id(struct dma_device
}

static int __dma_async_device_channel_register(struct dma_device *device,
- struct dma_chan *chan,
- int chan_id)
+ struct dma_chan *chan)
{
int rc = 0;
- int chancnt = device->chancnt;
- atomic_t *idr_ref;
- struct dma_chan *tchan;
-
- tchan = list_first_entry_or_null(&device->channels,
- struct dma_chan, device_node);
- if (!tchan)
- return -ENODEV;
-
- if (tchan->dev) {
- idr_ref = tchan->dev->idr_ref;
- } else {
- idr_ref = kmalloc(sizeof(*idr_ref), GFP_KERNEL);
- if (!idr_ref)
- return -ENOMEM;
- atomic_set(idr_ref, 0);
- }

chan->local = alloc_percpu(typeof(*chan->local));
if (!chan->local)
@@ -988,29 +966,36 @@ static int __dma_async_device_channel_re
* When the chan_id is a negative value, we are dynamically adding
* the channel. Otherwise we are static enumerating.
*/
- chan->chan_id = chan_id < 0 ? chancnt : chan_id;
+ mutex_lock(&device->chan_mutex);
+ chan->chan_id = ida_alloc(&device->chan_ida, GFP_KERNEL);
+ mutex_unlock(&device->chan_mutex);
+ if (chan->chan_id < 0) {
+ pr_err("%s: unable to alloc ida for chan: %d\n",
+ __func__, chan->chan_id);
+ goto err_out;
+ }
+
chan->dev->device.class = &dma_devclass;
chan->dev->device.parent = device->dev;
chan->dev->chan = chan;
- chan->dev->idr_ref = idr_ref;
chan->dev->dev_id = device->dev_id;
- atomic_inc(idr_ref);
dev_set_name(&chan->dev->device, "dma%dchan%d",
device->dev_id, chan->chan_id);
-
rc = device_register(&chan->dev->device);
if (rc)
- goto err_out;
+ goto err_out_ida;
chan->client_count = 0;
- device->chancnt = chan->chan_id + 1;
+ device->chancnt++;

return 0;

+ err_out_ida:
+ mutex_lock(&device->chan_mutex);
+ ida_free(&device->chan_ida, chan->chan_id);
+ mutex_unlock(&device->chan_mutex);
err_out:
free_percpu(chan->local);
kfree(chan->dev);
- if (atomic_dec_return(idr_ref) == 0)
- kfree(idr_ref);
return rc;
}

@@ -1019,7 +1004,7 @@ int dma_async_device_channel_register(st
{
int rc;

- rc = __dma_async_device_channel_register(device, chan, -1);
+ rc = __dma_async_device_channel_register(device, chan);
if (rc < 0)
return rc;

@@ -1039,6 +1024,9 @@ static void __dma_async_device_channel_u
device->chancnt--;
chan->dev->chan = NULL;
mutex_unlock(&dma_list_mutex);
+ mutex_lock(&device->chan_mutex);
+ ida_free(&device->chan_ida, chan->chan_id);
+ mutex_unlock(&device->chan_mutex);
device_unregister(&chan->dev->device);
free_percpu(chan->local);
}
@@ -1061,7 +1049,7 @@ EXPORT_SYMBOL_GPL(dma_async_device_chann
*/
int dma_async_device_register(struct dma_device *device)
{
- int rc, i = 0;
+ int rc;
struct dma_chan* chan;

if (!device)
@@ -1166,9 +1154,12 @@ int dma_async_device_register(struct dma
if (rc != 0)
return rc;

+ mutex_init(&device->chan_mutex);
+ ida_init(&device->chan_ida);
+
/* represent channels in sysfs. Probably want devs too */
list_for_each_entry(chan, &device->channels, device_node) {
- rc = __dma_async_device_channel_register(device, chan, i++);
+ rc = __dma_async_device_channel_register(device, chan);
if (rc < 0)
goto err_out;
}
@@ -1239,6 +1230,7 @@ void dma_async_device_unregister(struct
*/
dma_cap_set(DMA_PRIVATE, device->cap_mask);
dma_channel_rebalance();
+ ida_free(&dma_ida, device->dev_id);
dma_device_put(device);
mutex_unlock(&dma_list_mutex);
}
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -336,13 +336,11 @@ struct dma_chan {
* @chan: driver channel device
* @device: sysfs device
* @dev_id: parent dma_device dev_id
- * @idr_ref: reference count to gate release of dma_device dev_id
*/
struct dma_chan_dev {
struct dma_chan *chan;
struct device device;
int dev_id;
- atomic_t *idr_ref;
};

/**
@@ -827,6 +825,8 @@ struct dma_device {
int dev_id;
struct device *dev;
struct module *owner;
+ struct ida chan_ida;
+ struct mutex chan_mutex; /* to protect chan_ida */

u32 src_addr_widths;
u32 dst_addr_widths;


2020-05-04 18:48:39

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 52/73] i2c: iproc: generate stop event for slave writes

From: Rayagonda Kokatanur <[email protected]>

commit 068143a8195fb0fdeea1f3ca430b3db0f6d04a53 upstream.

When slave status is I2C_SLAVE_RX_END, generate I2C_SLAVE_STOP
event to i2c_client.

Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode")
Signed-off-by: Rayagonda Kokatanur <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/i2c/busses/i2c-bcm-iproc.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -360,6 +360,9 @@ static bool bcm_iproc_i2c_slave_isr(stru
value = (u8)((val >> S_RX_DATA_SHIFT) & S_RX_DATA_MASK);
i2c_slave_event(iproc_i2c->slave,
I2C_SLAVE_WRITE_RECEIVED, &value);
+ if (rx_status == I2C_SLAVE_RX_END)
+ i2c_slave_event(iproc_i2c->slave,
+ I2C_SLAVE_STOP, &value);
}
} else if (status & BIT(IS_S_TX_UNDERRUN_SHIFT)) {
/* Master read other than start */


2020-05-04 18:48:40

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 13/73] btrfs: fix block group leak when removing fails

From: Xiyu Yang <[email protected]>

commit f6033c5e333238f299c3ae03fac8cc1365b23b77 upstream.

btrfs_remove_block_group() invokes btrfs_lookup_block_group(), which
returns a local reference of the block group that contains the given
bytenr to "block_group" with increased refcount.

When btrfs_remove_block_group() returns, "block_group" becomes invalid,
so the refcount should be decreased to keep refcount balanced.

The reference counting issue happens in several exception handling paths
of btrfs_remove_block_group(). When those error scenarios occur such as
btrfs_alloc_path() returns NULL, the function forgets to decrease its
refcnt increased by btrfs_lookup_block_group() and will cause a refcnt
leak.

Fix this issue by jumping to "out_put_group" label and calling
btrfs_put_block_group() when those error scenarios occur.

CC: [email protected] # 4.4+
Signed-off-by: Xiyu Yang <[email protected]>
Signed-off-by: Xin Tan <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/block-group.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)

--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -916,7 +916,7 @@ int btrfs_remove_block_group(struct btrf
path = btrfs_alloc_path();
if (!path) {
ret = -ENOMEM;
- goto out;
+ goto out_put_group;
}

/*
@@ -954,7 +954,7 @@ int btrfs_remove_block_group(struct btrf
ret = btrfs_orphan_add(trans, BTRFS_I(inode));
if (ret) {
btrfs_add_delayed_iput(inode);
- goto out;
+ goto out_put_group;
}
clear_nlink(inode);
/* One for the block groups ref */
@@ -977,13 +977,13 @@ int btrfs_remove_block_group(struct btrf

ret = btrfs_search_slot(trans, tree_root, &key, path, -1, 1);
if (ret < 0)
- goto out;
+ goto out_put_group;
if (ret > 0)
btrfs_release_path(path);
if (ret == 0) {
ret = btrfs_del_item(trans, tree_root, path);
if (ret)
- goto out;
+ goto out_put_group;
btrfs_release_path(path);
}

@@ -1102,9 +1102,9 @@ int btrfs_remove_block_group(struct btrf

ret = remove_block_group_free_space(trans, block_group);
if (ret)
- goto out;
+ goto out_put_group;

- btrfs_put_block_group(block_group);
+ /* Once for the block groups rbtree */
btrfs_put_block_group(block_group);

ret = btrfs_search_slot(trans, root, &key, path, -1, 1);
@@ -1127,6 +1127,10 @@ int btrfs_remove_block_group(struct btrf
/* once for the tree */
free_extent_map(em);
}
+
+out_put_group:
+ /* Once for the lookup reference */
+ btrfs_put_block_group(block_group);
out:
if (remove_rsv)
btrfs_delayed_refs_rsv_release(fs_info, 1);


2020-05-04 18:48:40

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 51/73] RDMA/cm: Fix an error check in cm_alloc_id_priv()

From: Dan Carpenter <[email protected]>

commit 983653515849fb56b78ce55d349bb384d43030f6 upstream.

The xa_alloc_cyclic_irq() function returns either 0 or 1 on success and
negatives on error. This code treats 1 as an error and returns ERR_PTR(1)
which will cause an Oops in the caller.

Fixes: ae78ff3a0f0c ("RDMA/cm: Convert local_id_table to XArray")
Link: https://lore.kernel.org/r/20200407093714.GA80285@mwanda
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Matthew Wilcox (Oracle) <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/cm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -836,7 +836,7 @@ struct ib_cm_id *ib_create_cm_id(struct

ret = xa_alloc_cyclic_irq(&cm.local_id_table, &id, NULL, xa_limit_32b,
&cm.local_id_next, GFP_KERNEL);
- if (ret)
+ if (ret < 0)
goto error;
cm_id_priv->id.local_id = (__force __be32)id ^ cm.random_id_operand;
xa_store_irq(&cm.local_id_table, cm_local_id(cm_id_priv->id.local_id),


2020-05-04 18:48:41

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 63/73] i2c: aspeed: Avoid i2c interrupt status clear race condition.

From: ryan_chen <[email protected]>

commit c926c87b8e36dcc0ea5c2a0a0227ed4f32d0516a upstream.

In AST2600 there have a slow peripheral bus between CPU and i2c
controller. Therefore GIC i2c interrupt status clear have delay timing,
when CPU issue write clear i2c controller interrupt status. To avoid
this issue, the driver need have read after write clear at i2c ISR.

Fixes: f327c686d3ba ("i2c: aspeed: added driver for Aspeed I2C")
Signed-off-by: ryan_chen <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
[wsa: added Fixes tag]
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/i2c/busses/i2c-aspeed.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -603,6 +603,7 @@ static irqreturn_t aspeed_i2c_bus_irq(in
/* Ack all interrupts except for Rx done */
writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
bus->base + ASPEED_I2C_INTR_STS_REG);
+ readl(bus->base + ASPEED_I2C_INTR_STS_REG);
irq_remaining = irq_received;

#if IS_ENABLED(CONFIG_I2C_SLAVE)
@@ -645,9 +646,11 @@ static irqreturn_t aspeed_i2c_bus_irq(in
irq_received, irq_handled);

/* Ack Rx done */
- if (irq_received & ASPEED_I2CD_INTR_RX_DONE)
+ if (irq_received & ASPEED_I2CD_INTR_RX_DONE) {
writel(ASPEED_I2CD_INTR_RX_DONE,
bus->base + ASPEED_I2C_INTR_STS_REG);
+ readl(bus->base + ASPEED_I2C_INTR_STS_REG);
+ }
spin_unlock(&bus->lock);
return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
}


2020-05-04 18:48:50

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 68/73] nfs: Fix potential posix_acl refcnt leak in nfs3_set_acl

From: Andreas Gruenbacher <[email protected]>

commit 7648f939cb919b9d15c21fff8cd9eba908d595dc upstream.

nfs3_set_acl keeps track of the acl it allocated locally to determine if an acl
needs to be released at the end. This results in a memory leak when the
function allocates an acl as well as a default acl. Fix by releasing acls
that differ from the acl originally passed into nfs3_set_acl.

Fixes: b7fa0554cf1b ("[PATCH] NFS: Add support for NFSv3 ACLs")
Reported-by: Xiyu Yang <[email protected]>
Signed-off-by: Andreas Gruenbacher <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfs/nfs3acl.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)

--- a/fs/nfs/nfs3acl.c
+++ b/fs/nfs/nfs3acl.c
@@ -253,37 +253,45 @@ int nfs3_proc_setacls(struct inode *inod

int nfs3_set_acl(struct inode *inode, struct posix_acl *acl, int type)
{
- struct posix_acl *alloc = NULL, *dfacl = NULL;
+ struct posix_acl *orig = acl, *dfacl = NULL, *alloc;
int status;

if (S_ISDIR(inode->i_mode)) {
switch(type) {
case ACL_TYPE_ACCESS:
- alloc = dfacl = get_acl(inode, ACL_TYPE_DEFAULT);
+ alloc = get_acl(inode, ACL_TYPE_DEFAULT);
if (IS_ERR(alloc))
goto fail;
+ dfacl = alloc;
break;

case ACL_TYPE_DEFAULT:
- dfacl = acl;
- alloc = acl = get_acl(inode, ACL_TYPE_ACCESS);
+ alloc = get_acl(inode, ACL_TYPE_ACCESS);
if (IS_ERR(alloc))
goto fail;
+ dfacl = acl;
+ acl = alloc;
break;
}
}

if (acl == NULL) {
- alloc = acl = posix_acl_from_mode(inode->i_mode, GFP_KERNEL);
+ alloc = posix_acl_from_mode(inode->i_mode, GFP_KERNEL);
if (IS_ERR(alloc))
goto fail;
+ acl = alloc;
}
status = __nfs3_proc_setacls(inode, acl, dfacl);
- posix_acl_release(alloc);
+out:
+ if (acl != orig)
+ posix_acl_release(acl);
+ if (dfacl != orig)
+ posix_acl_release(dfacl);
return status;

fail:
- return PTR_ERR(alloc);
+ status = PTR_ERR(alloc);
+ goto out;
}

const struct xattr_handler *nfs3_xattr_handlers[] = {


2020-05-04 18:48:59

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 57/73] dmaengine: ti: k3-psil: fix deadlock on error path

From: Grygorii Strashko <[email protected]>

commit 172d59ecd61b89f535ad99a7e531c0f111453b9a upstream.

The mutex_unlock() is missed on error path of psil_get_ep_config()
which causes deadlock, so add missed mutex_unlock().

Fixes: 8c6bb62f6b4a ("dmaengine: ti: k3 PSI-L remote endpoint configuration")
Signed-off-by: Grygorii Strashko <[email protected]>
Acked-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/dma/ti/k3-psil.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/dma/ti/k3-psil.c
+++ b/drivers/dma/ti/k3-psil.c
@@ -27,6 +27,7 @@ struct psil_endpoint_config *psil_get_ep
soc_ep_map = &j721e_ep_map;
} else {
pr_err("PSIL: No compatible machine found for map\n");
+ mutex_unlock(&ep_map_mutex);
return ERR_PTR(-ENOTSUPP);
}
pr_debug("%s: Using map for %s\n", __func__, soc_ep_map->name);


2020-05-04 18:49:00

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 59/73] scsi: target/iblock: fix WRITE SAME zeroing

From: David Disseldorp <[email protected]>

commit 1d2ff149b263c9325875726a7804a0c75ef7112e upstream.

SBC4 specifies that WRITE SAME requests with the UNMAP bit set to zero
"shall perform the specified write operation to each LBA specified by the
command". Commit 2237498f0b5c ("target/iblock: Convert WRITE_SAME to
blkdev_issue_zeroout") modified the iblock backend to call
blkdev_issue_zeroout() when handling WRITE SAME requests with UNMAP=0 and a
zero data segment.

The iblock blkdev_issue_zeroout() call incorrectly provides a flags
parameter of 0 (bool false), instead of BLKDEV_ZERO_NOUNMAP. The bool
false parameter reflects the blkdev_issue_zeroout() API prior to commit
ee472d835c26 ("block: add a flags argument to (__)blkdev_issue_zeroout")
which was merged shortly before 2237498f0b5c.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 2237498f0b5c ("target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout")
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: David Disseldorp <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/target/target_core_iblock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -432,7 +432,7 @@ iblock_execute_zero_out(struct block_dev
target_to_linux_sector(dev, cmd->t_task_lba),
target_to_linux_sector(dev,
sbc_get_write_same_sectors(cmd)),
- GFP_KERNEL, false);
+ GFP_KERNEL, BLKDEV_ZERO_NOUNMAP);
if (ret)
return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;



2020-05-04 18:49:26

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 40/73] block: remove the bd_openers checks in blk_drop_partitions

From: Christoph Hellwig <[email protected]>

commit 10c70d95c0f2f9a6f52d0e33243d2877370cef51 upstream.

When replacing the bd_super check with a bd_openers I followed a logical
conclusion, which turns out to be utterly wrong. When a block device has
bd_super sets it has a mount file system on it (although not every
mounted file system sets bd_super), but that also implies it doesn't even
have partitions to start with.

So instead of trying to come up with a logical check for all openers,
just remove the check entirely.

Fixes: d3ef5536274f ("block: fix busy device checking in blk_drop_partitions")
Fixes: cb6b771b05c3 ("block: fix busy device checking in blk_drop_partitions again")
Reported-by: Michal Koutný <[email protected]>
Reported-by: Yang Xu <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
block/partition-generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -468,7 +468,7 @@ int blk_drop_partitions(struct gendisk *

if (!disk_part_scan_enabled(disk))
return 0;
- if (bdev->bd_part_count || bdev->bd_openers > 1)
+ if (bdev->bd_part_count)
return -EBUSY;
res = invalidate_partition(disk, 0);
if (res)


2020-05-04 18:49:40

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 42/73] scsi: qla2xxx: check UNLOADING before posting async work

From: Martin Wilck <[email protected]>

commit 5a263892d7d0b4fe351363f8d1a14c6a75955475 upstream.

qlt_free_session_done() tries to post async PRLO / LOGO, and waits for the
completion of these async commands. If UNLOADING is set, this is doomed to
timeout, because the async logout command will never complete.

The only way to avoid waiting pointlessly is to fail posting these commands
in the first place if the driver is in UNLOADING state. In general,
posting any command should be avoided when the driver is UNLOADING.

With this patch, "rmmod qla2xxx" completes without noticeable delay.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 45235022da99 ("scsi: qla2xxx: Fix driver unload by shutting down chip")
Acked-by: Arun Easi <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Martin Wilck <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/qla2xxx/qla_os.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -4854,6 +4854,9 @@ qla2x00_alloc_work(struct scsi_qla_host
struct qla_work_evt *e;
uint8_t bail;

+ if (test_bit(UNLOADING, &vha->dpc_flags))
+ return NULL;
+
QLA_VHA_MARK_BUSY(vha, bail);
if (bail)
return NULL;


2020-05-04 18:49:52

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 15/73] btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info

From: Qu Wenruo <[email protected]>

commit fcc99734d1d4ced30167eb02e17f656735cb9928 upstream.

[BUG]
One run of btrfs/063 triggered the following lockdep warning:
============================================
WARNING: possible recursive locking detected
5.6.0-rc7-custom+ #48 Not tainted
--------------------------------------------
kworker/u24:0/7 is trying to acquire lock:
ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]

but task is already holding lock:
ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]

other info that might help us debug this:
Possible unsafe locking scenario:

CPU0
----
lock(sb_internal#2);
lock(sb_internal#2);

*** DEADLOCK ***

May be due to missing lock nesting notation

4 locks held by kworker/u24:0/7:
#0: ffff88817b495948 ((wq_completion)btrfs-endio-write){+.+.}, at: process_one_work+0x557/0xb80
#1: ffff888189ea7db8 ((work_completion)(&work->normal_work)){+.+.}, at: process_one_work+0x557/0xb80
#2: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
#3: ffff888174ca4da8 (&fs_info->reloc_mutex){+.+.}, at: btrfs_record_root_in_trans+0x83/0xd0 [btrfs]

stack backtrace:
CPU: 0 PID: 7 Comm: kworker/u24:0 Not tainted 5.6.0-rc7-custom+ #48
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
Call Trace:
dump_stack+0xc2/0x11a
__lock_acquire.cold+0xce/0x214
lock_acquire+0xe6/0x210
__sb_start_write+0x14e/0x290
start_transaction+0x66c/0x890 [btrfs]
btrfs_join_transaction+0x1d/0x20 [btrfs]
find_free_extent+0x1504/0x1a50 [btrfs]
btrfs_reserve_extent+0xd5/0x1f0 [btrfs]
btrfs_alloc_tree_block+0x1ac/0x570 [btrfs]
btrfs_copy_root+0x213/0x580 [btrfs]
create_reloc_root+0x3bd/0x470 [btrfs]
btrfs_init_reloc_root+0x2d2/0x310 [btrfs]
record_root_in_trans+0x191/0x1d0 [btrfs]
btrfs_record_root_in_trans+0x90/0xd0 [btrfs]
start_transaction+0x16e/0x890 [btrfs]
btrfs_join_transaction+0x1d/0x20 [btrfs]
btrfs_finish_ordered_io+0x55d/0xcd0 [btrfs]
finish_ordered_fn+0x15/0x20 [btrfs]
btrfs_work_helper+0x116/0x9a0 [btrfs]
process_one_work+0x632/0xb80
worker_thread+0x80/0x690
kthread+0x1a3/0x1f0
ret_from_fork+0x27/0x50

It's pretty hard to reproduce, only one hit so far.

[CAUSE]
This is because we're calling btrfs_join_transaction() without re-using
the current running one:

btrfs_finish_ordered_io()
|- btrfs_join_transaction() <<< Call #1
|- btrfs_record_root_in_trans()
|- btrfs_reserve_extent()
|- btrfs_join_transaction() <<< Call #2

Normally such btrfs_join_transaction() call should re-use the existing
one, without trying to re-start a transaction.

But the problem is, in btrfs_join_transaction() call #1, we call
btrfs_record_root_in_trans() before initializing current::journal_info.

And in btrfs_join_transaction() call #2, we're relying on
current::journal_info to avoid such deadlock.

[FIX]
Call btrfs_record_root_in_trans() after we have initialized
current::journal_info.

CC: [email protected] # 4.4+
Signed-off-by: Qu Wenruo <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/transaction.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)

--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -660,10 +660,19 @@ again:
}

got_it:
- btrfs_record_root_in_trans(h, root);
-
if (!current->journal_info)
current->journal_info = h;
+
+ /*
+ * btrfs_record_root_in_trans() needs to alloc new extents, and may
+ * call btrfs_join_transaction() while we're also starting a
+ * transaction.
+ *
+ * Thus it need to be called after current->journal_info initialized,
+ * or we can deadlock.
+ */
+ btrfs_record_root_in_trans(h, root);
+
return h;

join_fail:


2020-05-04 18:49:56

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 18/73] mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers

From: Adrian Hunter <[email protected]>

commit 1a8eb6b373c2af6533c13d1ea11f504e5010ed9a upstream.

BIOS writers have begun the practice of setting 40 ohm eMMC driver strength
even though the eMMC may not support it, on the assumption that the kernel
will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH
[offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid.

This is done to avoid changing the value for different boards.

Putting aside the merits of this approach, it is clear the eMMC's mask
of supported driver strengths is more reliable than the value provided
by BIOS. Add validation accordingly.

Signed-off-by: Adrian Hunter <[email protected]>
Fixes: 51ced59cc02e ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices")
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mmc/host/sdhci-pci-core.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -601,6 +601,9 @@ static int intel_select_drive_strength(s
struct sdhci_pci_slot *slot = sdhci_priv(host);
struct intel_host *intel_host = sdhci_pci_priv(slot);

+ if (!(mmc_driver_type_mask(intel_host->drv_strength) & card_drv))
+ return 0;
+
return intel_host->drv_strength;
}



2020-05-04 18:50:03

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 28/73] i2c: amd-mp2-pci: Fix Oops in amd_mp2_pci_init() error handling

From: Dan Carpenter <[email protected]>

commit ac2b0813fceaf7cb3d8d46c7b33c90bae9fa49db upstream.

The problem is that we dereference "privdata->pci_dev" when we print
the error messages in amd_mp2_pci_init():

dev_err(ndev_dev(privdata), "Failed to enable MP2 PCI device\n");
^^^^^^^^^^^^^^^^^

Fixes: 529766e0a011 ("i2c: Add drivers for the AMD PCIe MP2 I2C controller")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/i2c/busses/i2c-amd-mp2-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/i2c/busses/i2c-amd-mp2-pci.c
+++ b/drivers/i2c/busses/i2c-amd-mp2-pci.c
@@ -349,12 +349,12 @@ static int amd_mp2_pci_probe(struct pci_
if (!privdata)
return -ENOMEM;

+ privdata->pci_dev = pci_dev;
rc = amd_mp2_pci_init(privdata, pci_dev);
if (rc)
return rc;

mutex_init(&privdata->c2p_lock);
- privdata->pci_dev = pci_dev;

pm_runtime_set_autosuspend_delay(&pci_dev->dev, 1000);
pm_runtime_use_autosuspend(&pci_dev->dev);


2020-05-04 18:50:04

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 04/73] drm/edid: Fix off-by-one in DispID DTD pixel clock

From: Ville Syrjälä <[email protected]>

commit 6292b8efe32e6be408af364132f09572aed14382 upstream.

The DispID DTD pixel clock is documented as:
"00 00 00 h → FF FF FF h | Pixel clock ÷ 10,000 0.01 → 167,772.16 Mega Pixels per Sec"
Which seems to imply that we to add one to the raw value.

Reality seems to agree as there are tiled displays in the wild
which currently show a 10kHz difference in the pixel clock
between the tiles (one tile gets its mode from the base EDID,
the other from the DispID block).

Cc: [email protected]
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Manasi Navare <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5009,7 +5009,7 @@ static struct drm_display_mode *drm_mode
struct drm_display_mode *mode;
unsigned pixel_clock = (timings->pixel_clock[0] |
(timings->pixel_clock[1] << 8) |
- (timings->pixel_clock[2] << 16));
+ (timings->pixel_clock[2] << 16)) + 1;
unsigned hactive = (timings->hactive[0] | timings->hactive[1] << 8) + 1;
unsigned hblank = (timings->hblank[0] | timings->hblank[1] << 8) + 1;
unsigned hsync = (timings->hsync[0] | (timings->hsync[1] & 0x7f) << 8) + 1;


2020-05-04 19:07:55

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.6 61/73] iommu/vt-d: Use right Kconfig option name

From: Lu Baolu <[email protected]>

commit ba61c3da00f4a5bf8805aeca1ba5ac3c9bd82e96 upstream.

The CONFIG_ prefix should be added in the code.

Fixes: 046182525db61 ("iommu/vt-d: Add Kconfig option to enable/disable scalable mode")
Reported-and-tested-by: Kumar, Sanjay K <[email protected]>
Signed-off-by: Lu Baolu <[email protected]>
Cc: Ashok Raj <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/iommu/intel-iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -371,11 +371,11 @@ int dmar_disabled = 0;
int dmar_disabled = 1;
#endif /* CONFIG_INTEL_IOMMU_DEFAULT_ON */

-#ifdef INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
+#ifdef CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
int intel_iommu_sm = 1;
#else
int intel_iommu_sm;
-#endif /* INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON */
+#endif /* CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON */

int intel_iommu_enabled = 0;
EXPORT_SYMBOL_GPL(intel_iommu_enabled);


2020-05-04 19:45:04

by Joe Perches

[permalink] [raw]
Subject: Re: [PATCH 5.6 61/73] iommu/vt-d: Use right Kconfig option name

On Mon, 2020-05-04 at 19:58 +0200, Greg Kroah-Hartman wrote:
> From: Lu Baolu <[email protected]>
>
> commit ba61c3da00f4a5bf8805aeca1ba5ac3c9bd82e96 upstream.
>
> The CONFIG_ prefix should be added in the code.
>
> Fixes: 046182525db61 ("iommu/vt-d: Add Kconfig option to enable/disable scalable mode")
> Reported-and-tested-by: Kumar, Sanjay K <[email protected]>
> Signed-off-by: Lu Baolu <[email protected]>
> Cc: Ashok Raj <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> Signed-off-by: Joerg Roedel <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> drivers/iommu/intel-iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -371,11 +371,11 @@ int dmar_disabled = 0;
> int dmar_disabled = 1;
> #endif /* CONFIG_INTEL_IOMMU_DEFAULT_ON */
>
> -#ifdef INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
> +#ifdef CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
> int intel_iommu_sm = 1;
> #else
> int intel_iommu_sm;
> -#endif /* INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON */
> +#endif /* CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON */

Perhaps simpler as

int intel_iommu_sm = IS_BUILTIN(CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON);

So perhaps:
---
drivers/iommu/intel-iommu.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0182cff2c7ac..ab8552c48391 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -365,17 +365,8 @@ static int intel_iommu_attach_device(struct iommu_domain *domain,
static phys_addr_t intel_iommu_iova_to_phys(struct iommu_domain *domain,
dma_addr_t iova);

-#ifdef CONFIG_INTEL_IOMMU_DEFAULT_ON
-int dmar_disabled = 0;
-#else
-int dmar_disabled = 1;
-#endif /* CONFIG_INTEL_IOMMU_DEFAULT_ON */
-
-#ifdef CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
-int intel_iommu_sm = 1;
-#else
-int intel_iommu_sm;
-#endif /* CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON */
+int dmar_disabled = !IS_BUILTIN(CONFIG_INTEL_IOMMU_DEFAULT_ON);
+int intel_iommu_sm = IS_BUILTIN(CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON);

int intel_iommu_enabled = 0;
EXPORT_SYMBOL_GPL(intel_iommu_enabled);

2020-05-05 08:40:49

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review


On 04/05/2020 18:57, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.6.11 release.
> There are 73 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.6.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v5.6:
13 builds: 13 pass, 0 fail
24 boots: 24 pass, 0 fail
40 tests: 40 pass, 0 fail

Linux version: 5.6.11-rc1-g6cd4bcd666cd
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2020-05-05 09:22:10

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On Tue, May 05, 2020 at 09:38:43AM +0100, Jon Hunter wrote:
>
> On 04/05/2020 18:57, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.6.11 release.
> > There are 73 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.6.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> All tests are passing for Tegra ...
>
> Test results for stable-v5.6:
> 13 builds: 13 pass, 0 fail
> 24 boots: 24 pass, 0 fail
> 40 tests: 40 pass, 0 fail
>
> Linux version: 5.6.11-rc1-g6cd4bcd666cd
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra210-p3450-0000,
> tegra30-cardhu-a04

Thanks for testing all of these and letting me know.

greg k-h

2020-05-05 14:30:57

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On Mon, 4 May 2020 at 23:36, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.6.11 release.
> There are 73 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.6.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 5.6.11-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.6.y
git commit: 6cd4bcd666cd831acf192bd7350b94121469ebcb
git describe: v5.6.10-74-g6cd4bcd666cd
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.6-oe/build/v5.6.10-74-g6cd4bcd666cd

No regressions (compared to build v5.6.10)

No fixes (compared to build v5.6.10)

Ran 29045 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* kselftest/drivers
* kselftest/filesystems
* libgpiod
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-io-tests
* kvm-unit-tests
* libhugetlbfs
* ltp-containers-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* perf
* kselftest/net
* kselftest/networking
* ltp-commands-tests
* ltp-cve-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-open-posix-tests
* ltp-sched-tests
* ltp-syscalls-tests
* network-basic-tests
* v4l2-compliance
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-native/networking
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kselftest-vsyscall-mode-none/networking

--
Linaro LKFT
https://lkft.linaro.org

2020-05-05 15:30:02

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On 5/4/20 11:57 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.6.11 release.
> There are 73 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.6.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 5.6.11-rc1
>

> Takashi Iwai <[email protected]>
> ALSA: pcm: oss: Place the plugin buffer overflow checks correctly
>
> Vasily Khoruzhick <[email protected]>
> ALSA: line6: Fix POD HD500 audio playback
>
> Wu Bo <[email protected]>
> ALSA: hda/hdmi: fix without unlocked before return
>
> Takashi Iwai <[email protected]>
> ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
>
> Hui Wang <[email protected]>
> ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
>

> sound/core/oss/pcm_plugin.c | 20 ++++---
> sound/isa/opti9xx/miro.c | 9 ++-
> sound/isa/opti9xx/opti92x-ad1848.c | 9 ++-
> sound/pci/hda/patch_hdmi.c | 4 +-
> sound/pci/hda/patch_realtek.c | 1 +
> sound/usb/line6/podhd.c | 22 ++-----
> sound/usb/quirks.c | 2 +-
> 78 files changed, 554 insertions(+), 297 deletions(-)
>
>
>

Compiled and booted on my test system. Tons of the of following
errors in dmesg

Adding Takashi Iwai

[ 33.980302] usb 2-2.4: 1:1: cannot set freq 48000 to ep 0x1
[ 49.340581] usb 2-2.4: 2:1: cannot set freq 48000 to ep 0x82
[ 59.580511] usb 2-2.4: 13:0: cannot get min/max values for control 2
(id 13)
[ 64.700532] usb 2-2.4: 9:0: cannot get min/max values for control 2
(id 9)
[ 69.792257] usb 2-2.4: 10:0: cannot get min/max values for control 2
(id 10)
[ 69.792736] usbcore: registered new interface driver snd-usb-audio
[ 74.871038] usb 2-2.4: 9:0: cannot get min/max values for control 2
(id 9)
[ 79.967099] usb 2-2.4: 9:0: cannot get min/max values for control 2
(id 9)
[ 85.076961] usb 2-2.4: 9:0: cannot get min/max values for control 2
(id 9)
[ 90.191415] usb 2-2.4: 9:0: cannot get min/max values for control 2
(id 9)
[ 95.308843] usb 2-2.4: 9:0: cannot get min/max values for control 2
(id 9)

followed by

[ 131.172280] usb 2-2.4: 1:1: usb_set_interface failed (-110)
[ 136.259909] usb 2-2.4: 1:1: usb_set_interface failed (-110)
[ 141.380345] usb 2-2.4: 1:1: usb_set_interface failed (-110)
[ 146.500227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
[ 151.620227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
[ 156.739899] usb 2-2.4: 1:1: usb_set_interface failed (-110)
[ 161.859999] usb 2-2.4: 1:1: usb_set_interface failed (-110)


I have audio on that port. I haven't tried yet reverting these
sound patches yet. demsg is filling up with these messages for
sure.

thanks,
-- Shuah

2020-05-05 15:34:14

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On 5/5/20 9:25 AM, shuah wrote:
> On 5/4/20 11:57 AM, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 5.6.11 release.
>> There are 73 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>>     https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
>>
>> or in the git tree and branch at:
>>     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> linux-5.6.y
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
>>
>> -------------
>> Pseudo-Shortlog of commits:
>>
>> Greg Kroah-Hartman <[email protected]>
>>      Linux 5.6.11-rc1
>>
>
>> Takashi Iwai <[email protected]>
>>      ALSA: pcm: oss: Place the plugin buffer overflow checks correctly
>>
>> Vasily Khoruzhick <[email protected]>
>>      ALSA: line6: Fix POD HD500 audio playback
>>
>> Wu Bo <[email protected]>
>>      ALSA: hda/hdmi: fix without unlocked before return
>>
>> Takashi Iwai <[email protected]>
>>      ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
>>
>> Hui Wang <[email protected]>
>>      ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
>>
>
>>   sound/core/oss/pcm_plugin.c                       | 20 ++++---
>>   sound/isa/opti9xx/miro.c                          |  9 ++-
>>   sound/isa/opti9xx/opti92x-ad1848.c                |  9 ++-
>>   sound/pci/hda/patch_hdmi.c                        |  4 +-
>>   sound/pci/hda/patch_realtek.c                     |  1 +
>>   sound/usb/line6/podhd.c                           | 22 ++-----
>>   sound/usb/quirks.c                                |  2 +-
>>   78 files changed, 554 insertions(+), 297 deletions(-)
>>
>>
>>
>
> Compiled and booted on my test system. Tons of the of following
> errors in dmesg
>
> Adding Takashi Iwai
>
> [   33.980302] usb 2-2.4: 1:1: cannot set freq 48000 to ep 0x1
> [   49.340581] usb 2-2.4: 2:1: cannot set freq 48000 to ep 0x82
> [   59.580511] usb 2-2.4: 13:0: cannot get min/max values for control 2
> (id 13)
> [   64.700532] usb 2-2.4: 9:0: cannot get min/max values for control 2
> (id 9)
> [   69.792257] usb 2-2.4: 10:0: cannot get min/max values for control 2
> (id 10)
> [   69.792736] usbcore: registered new interface driver snd-usb-audio
> [   74.871038] usb 2-2.4: 9:0: cannot get min/max values for control 2
> (id 9)
> [   79.967099] usb 2-2.4: 9:0: cannot get min/max values for control 2
> (id 9)
> [   85.076961] usb 2-2.4: 9:0: cannot get min/max values for control 2
> (id 9)
> [   90.191415] usb 2-2.4: 9:0: cannot get min/max values for control 2
> (id 9)
> [   95.308843] usb 2-2.4: 9:0: cannot get min/max values for control 2
> (id 9)
>
> followed by
>
> [  131.172280] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> [  136.259909] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> [  141.380345] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> [  146.500227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> [  151.620227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> [  156.739899] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> [  161.859999] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>
>
> I have audio on that port. I haven't tried yet reverting these
> sound patches yet. demsg is filling up with these messages for
> sure.
>

I just tried Linux 5.7-rc4 and it also has this problem. New in rc4 as
far as I can tell.

thanks,
-- Shuah

2020-05-05 15:38:24

by Takashi Iwai

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On Tue, 05 May 2020 17:30:07 +0200,
shuah wrote:
>
> On 5/5/20 9:25 AM, shuah wrote:
> > On 5/4/20 11:57 AM, Greg Kroah-Hartman wrote:
> >> This is the start of the stable review cycle for the 5.6.11 release.
> >> There are 73 patches in this series, all will be posted as a response
> >> to this one.  If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> >> Anything received after that time might be too late.
> >>
> >> The whole patch series can be found in one patch at:
> >>     https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
> >>
> >> or in the git tree and branch at:
> >>     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >> linux-5.6.y
> >> and the diffstat can be found below.
> >>
> >> thanks,
> >>
> >> greg k-h
> >>
> >> -------------
> >> Pseudo-Shortlog of commits:
> >>
> >> Greg Kroah-Hartman <[email protected]>
> >>      Linux 5.6.11-rc1
> >>
> >
> >> Takashi Iwai <[email protected]>
> >>      ALSA: pcm: oss: Place the plugin buffer overflow checks correctly
> >>
> >> Vasily Khoruzhick <[email protected]>
> >>      ALSA: line6: Fix POD HD500 audio playback
> >>
> >> Wu Bo <[email protected]>
> >>      ALSA: hda/hdmi: fix without unlocked before return
> >>
> >> Takashi Iwai <[email protected]>
> >>      ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
> >>
> >> Hui Wang <[email protected]>
> >>      ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
> >>
> >
> >>   sound/core/oss/pcm_plugin.c                       | 20 ++++---
> >>   sound/isa/opti9xx/miro.c                          |  9 ++-
> >>   sound/isa/opti9xx/opti92x-ad1848.c                |  9 ++-
> >>   sound/pci/hda/patch_hdmi.c                        |  4 +-
> >>   sound/pci/hda/patch_realtek.c                     |  1 +
> >>   sound/usb/line6/podhd.c                           | 22 ++-----
> >>   sound/usb/quirks.c                                |  2 +-
> >>   78 files changed, 554 insertions(+), 297 deletions(-)
> >>
> >>
> >>
> >
> > Compiled and booted on my test system. Tons of the of following
> > errors in dmesg
> >
> > Adding Takashi Iwai
> >
> > [   33.980302] usb 2-2.4: 1:1: cannot set freq 48000 to ep 0x1
> > [   49.340581] usb 2-2.4: 2:1: cannot set freq 48000 to ep 0x82
> > [   59.580511] usb 2-2.4: 13:0: cannot get min/max values for
> > control 2 (id 13)
> > [   64.700532] usb 2-2.4: 9:0: cannot get min/max values for control
> > 2 (id 9)
> > [   69.792257] usb 2-2.4: 10:0: cannot get min/max values for
> > control 2 (id 10)
> > [   69.792736] usbcore: registered new interface driver snd-usb-audio
> > [   74.871038] usb 2-2.4: 9:0: cannot get min/max values for control
> > 2 (id 9)
> > [   79.967099] usb 2-2.4: 9:0: cannot get min/max values for control
> > 2 (id 9)
> > [   85.076961] usb 2-2.4: 9:0: cannot get min/max values for control
> > 2 (id 9)
> > [   90.191415] usb 2-2.4: 9:0: cannot get min/max values for control
> > 2 (id 9)
> > [   95.308843] usb 2-2.4: 9:0: cannot get min/max values for control
> > 2 (id 9)
> >
> > followed by
> >
> > [  131.172280] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > [  136.259909] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > [  141.380345] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > [  146.500227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > [  151.620227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > [  156.739899] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > [  161.859999] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> >
> >
> > I have audio on that port. I haven't tried yet reverting these
> > sound patches yet. demsg is filling up with these messages for
> > sure.
> >
>
> I just tried Linux 5.7-rc4 and it also has this problem. New in rc4 as
> far as I can tell.

Then it's unlikely from the changes in sound/*, but I'd suspect rather
USB core side. There is only one change for USB-audio driver and it's
a correction of USB device ID.


thanks,

Takashi

2020-05-05 15:46:11

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On 5/5/20 9:36 AM, Takashi Iwai wrote:
> On Tue, 05 May 2020 17:30:07 +0200,
> shuah wrote:
>>
>> On 5/5/20 9:25 AM, shuah wrote:
>>> On 5/4/20 11:57 AM, Greg Kroah-Hartman wrote:
>>>> This is the start of the stable review cycle for the 5.6.11 release.
>>>> There are 73 patches in this series, all will be posted as a response
>>>> to this one.  If anyone has any issues with these being applied, please
>>>> let me know.
>>>>
>>>> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
>>>> Anything received after that time might be too late.
>>>>
>>>> The whole patch series can be found in one patch at:
>>>>     https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
>>>>
>>>> or in the git tree and branch at:
>>>>     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>>>> linux-5.6.y
>>>> and the diffstat can be found below.
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>>
>>>> -------------
>>>> Pseudo-Shortlog of commits:
>>>>
>>>> Greg Kroah-Hartman <[email protected]>
>>>>      Linux 5.6.11-rc1
>>>>
>>>
>>>> Takashi Iwai <[email protected]>
>>>>      ALSA: pcm: oss: Place the plugin buffer overflow checks correctly
>>>>
>>>> Vasily Khoruzhick <[email protected]>
>>>>      ALSA: line6: Fix POD HD500 audio playback
>>>>
>>>> Wu Bo <[email protected]>
>>>>      ALSA: hda/hdmi: fix without unlocked before return
>>>>
>>>> Takashi Iwai <[email protected]>
>>>>      ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
>>>>
>>>> Hui Wang <[email protected]>
>>>>      ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
>>>>
>>>
>>>>   sound/core/oss/pcm_plugin.c                       | 20 ++++---
>>>>   sound/isa/opti9xx/miro.c                          |  9 ++-
>>>>   sound/isa/opti9xx/opti92x-ad1848.c                |  9 ++-
>>>>   sound/pci/hda/patch_hdmi.c                        |  4 +-
>>>>   sound/pci/hda/patch_realtek.c                     |  1 +
>>>>   sound/usb/line6/podhd.c                           | 22 ++-----
>>>>   sound/usb/quirks.c                                |  2 +-
>>>>   78 files changed, 554 insertions(+), 297 deletions(-)
>>>>
>>>>
>>>>
>>>
>>> Compiled and booted on my test system. Tons of the of following
>>> errors in dmesg
>>>
>>> Adding Takashi Iwai
>>>
>>> [   33.980302] usb 2-2.4: 1:1: cannot set freq 48000 to ep 0x1
>>> [   49.340581] usb 2-2.4: 2:1: cannot set freq 48000 to ep 0x82
>>> [   59.580511] usb 2-2.4: 13:0: cannot get min/max values for
>>> control 2 (id 13)
>>> [   64.700532] usb 2-2.4: 9:0: cannot get min/max values for control
>>> 2 (id 9)
>>> [   69.792257] usb 2-2.4: 10:0: cannot get min/max values for
>>> control 2 (id 10)
>>> [   69.792736] usbcore: registered new interface driver snd-usb-audio
>>> [   74.871038] usb 2-2.4: 9:0: cannot get min/max values for control
>>> 2 (id 9)
>>> [   79.967099] usb 2-2.4: 9:0: cannot get min/max values for control
>>> 2 (id 9)
>>> [   85.076961] usb 2-2.4: 9:0: cannot get min/max values for control
>>> 2 (id 9)
>>> [   90.191415] usb 2-2.4: 9:0: cannot get min/max values for control
>>> 2 (id 9)
>>> [   95.308843] usb 2-2.4: 9:0: cannot get min/max values for control
>>> 2 (id 9)
>>>
>>> followed by
>>>
>>> [  131.172280] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>> [  136.259909] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>> [  141.380345] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>> [  146.500227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>> [  151.620227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>> [  156.739899] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>> [  161.859999] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>>
>>>
>>> I have audio on that port. I haven't tried yet reverting these
>>> sound patches yet. demsg is filling up with these messages for
>>> sure.
>>>
>>
>> I just tried Linux 5.7-rc4 and it also has this problem. New in rc4 as
>> far as I can tell.
>
> Then it's unlikely from the changes in sound/*, but I'd suspect rather
> USB core side. There is only one change for USB-audio driver and it's
> a correction of USB device ID.
>
>

For what its worth not seeing this on 5.4.39-rc1 with the same set of
sound changes. I will start bisect on 5.6.11-rc1

thanks,
-- Shuah

2020-05-05 15:49:03

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On 5/4/20 10:57 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.6.11 release.
> There are 73 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 427 pass: 427 fail: 0

Guenter

2020-05-05 16:21:50

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On 5/5/20 9:43 AM, shuah wrote:
> On 5/5/20 9:36 AM, Takashi Iwai wrote:
>> On Tue, 05 May 2020 17:30:07 +0200,
>> shuah wrote:
>>>
>>> On 5/5/20 9:25 AM, shuah wrote:
>>>> On 5/4/20 11:57 AM, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 5.6.11 release.
>>>>> There are 73 patches in this series, all will be posted as a response
>>>>> to this one.  If anyone has any issues with these being applied,
>>>>> please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>> The whole patch series can be found in one patch at:
>>>>>      https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
>>>>>
>>>>>
>>>>> or in the git tree and branch at:
>>>>>      git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>>>>>
>>>>> linux-5.6.y
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>>
>>>>> -------------
>>>>> Pseudo-Shortlog of commits:
>>>>>
>>>>> Greg Kroah-Hartman <[email protected]>
>>>>>       Linux 5.6.11-rc1
>>>>>
>>>>
>>>>> Takashi Iwai <[email protected]>
>>>>>       ALSA: pcm: oss: Place the plugin buffer overflow checks
>>>>> correctly
>>>>>
>>>>> Vasily Khoruzhick <[email protected]>
>>>>>       ALSA: line6: Fix POD HD500 audio playback
>>>>>
>>>>> Wu Bo <[email protected]>
>>>>>       ALSA: hda/hdmi: fix without unlocked before return
>>>>>
>>>>> Takashi Iwai <[email protected]>
>>>>>       ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
>>>>>
>>>>> Hui Wang <[email protected]>
>>>>>       ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
>>>>>
>>>>
>>>>>    sound/core/oss/pcm_plugin.c                       | 20 ++++---
>>>>>    sound/isa/opti9xx/miro.c                          |  9 ++-
>>>>>    sound/isa/opti9xx/opti92x-ad1848.c                |  9 ++-
>>>>>    sound/pci/hda/patch_hdmi.c                        |  4 +-
>>>>>    sound/pci/hda/patch_realtek.c                     |  1 +
>>>>>    sound/usb/line6/podhd.c                           | 22 ++-----
>>>>>    sound/usb/quirks.c                                |  2 +-
>>>>>    78 files changed, 554 insertions(+), 297 deletions(-)
>>>>>
>>>>>
>>>>>
>>>>
>>>> Compiled and booted on my test system. Tons of the of following
>>>> errors in dmesg
>>>>
>>>> Adding Takashi Iwai
>>>>
>>>> [   33.980302] usb 2-2.4: 1:1: cannot set freq 48000 to ep 0x1
>>>> [   49.340581] usb 2-2.4: 2:1: cannot set freq 48000 to ep 0x82
>>>> [   59.580511] usb 2-2.4: 13:0: cannot get min/max values for
>>>> control 2 (id 13)
>>>> [   64.700532] usb 2-2.4: 9:0: cannot get min/max values for control
>>>> 2 (id 9)
>>>> [   69.792257] usb 2-2.4: 10:0: cannot get min/max values for
>>>> control 2 (id 10)
>>>> [   69.792736] usbcore: registered new interface driver snd-usb-audio
>>>> [   74.871038] usb 2-2.4: 9:0: cannot get min/max values for control
>>>> 2 (id 9)
>>>> [   79.967099] usb 2-2.4: 9:0: cannot get min/max values for control
>>>> 2 (id 9)
>>>> [   85.076961] usb 2-2.4: 9:0: cannot get min/max values for control
>>>> 2 (id 9)
>>>> [   90.191415] usb 2-2.4: 9:0: cannot get min/max values for control
>>>> 2 (id 9)
>>>> [   95.308843] usb 2-2.4: 9:0: cannot get min/max values for control
>>>> 2 (id 9)
>>>>
>>>> followed by
>>>>
>>>> [  131.172280] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>>> [  136.259909] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>>> [  141.380345] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>>> [  146.500227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>>> [  151.620227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>>> [  156.739899] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>>> [  161.859999] usb 2-2.4: 1:1: usb_set_interface failed (-110)
>>>>
>>>>
>>>> I have audio on that port. I haven't tried yet reverting these
>>>> sound patches yet. demsg is filling up with these messages for
>>>> sure.
>>>>
>>>
>>> I just tried Linux 5.7-rc4 and it also has this problem. New in rc4 as
>>> far as I can tell.
>>
>> Then it's unlikely from the changes in sound/*, but I'd suspect rather
>> USB core side.  There is only one change for USB-audio driver and it's
>> a correction of USB device ID.
>>
>>
>
> For what its worth not seeing this on 5.4.39-rc1 with the same set of
> sound changes. I will start bisect on 5.6.11-rc1
>

I can't reproduce this problem on 5.7-rc1 and 5.6.11-rc1 after seeing
it once on both.

Tried powerdown vs reboot to see if it is tied to hardware init
sequence. Doesn't seem to make a difference. Oh well. I will
update if I see it again.

thanks,
-- Shuah

2020-05-05 17:02:32

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On Tue, May 05, 2020 at 10:19:31AM -0600, shuah wrote:
> On 5/5/20 9:43 AM, shuah wrote:
> > On 5/5/20 9:36 AM, Takashi Iwai wrote:
> > > On Tue, 05 May 2020 17:30:07 +0200,
> > > shuah wrote:
> > > >
> > > > On 5/5/20 9:25 AM, shuah wrote:
> > > > > On 5/4/20 11:57 AM, Greg Kroah-Hartman wrote:
> > > > > > This is the start of the stable review cycle for the 5.6.11 release.
> > > > > > There are 73 patches in this series, all will be posted as a response
> > > > > > to this one.? If anyone has any issues with these being
> > > > > > applied, please
> > > > > > let me know.
> > > > > >
> > > > > > Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> > > > > > Anything received after that time might be too late.
> > > > > >
> > > > > > The whole patch series can be found in one patch at:
> > > > > > ?????https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
> > > > > >
> > > > > >
> > > > > > or in the git tree and branch at:
> > > > > > ?????git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > > > >
> > > > > > linux-5.6.y
> > > > > > and the diffstat can be found below.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > > >
> > > > > > -------------
> > > > > > Pseudo-Shortlog of commits:
> > > > > >
> > > > > > Greg Kroah-Hartman <[email protected]>
> > > > > > ????? Linux 5.6.11-rc1
> > > > > >
> > > > >
> > > > > > Takashi Iwai <[email protected]>
> > > > > > ????? ALSA: pcm: oss: Place the plugin buffer overflow
> > > > > > checks correctly
> > > > > >
> > > > > > Vasily Khoruzhick <[email protected]>
> > > > > > ????? ALSA: line6: Fix POD HD500 audio playback
> > > > > >
> > > > > > Wu Bo <[email protected]>
> > > > > > ????? ALSA: hda/hdmi: fix without unlocked before return
> > > > > >
> > > > > > Takashi Iwai <[email protected]>
> > > > > > ????? ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
> > > > > >
> > > > > > Hui Wang <[email protected]>
> > > > > > ????? ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
> > > > > >
> > > > >
> > > > > > ?? sound/core/oss/pcm_plugin.c?????????????????????? | 20 ++++---
> > > > > > ?? sound/isa/opti9xx/miro.c????????????????????????? |? 9 ++-
> > > > > > ?? sound/isa/opti9xx/opti92x-ad1848.c??????????????? |? 9 ++-
> > > > > > ?? sound/pci/hda/patch_hdmi.c??????????????????????? |? 4 +-
> > > > > > ?? sound/pci/hda/patch_realtek.c???????????????????? |? 1 +
> > > > > > ?? sound/usb/line6/podhd.c?????????????????????????? | 22 ++-----
> > > > > > ?? sound/usb/quirks.c??????????????????????????????? |? 2 +-
> > > > > > ?? 78 files changed, 554 insertions(+), 297 deletions(-)
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > Compiled and booted on my test system. Tons of the of following
> > > > > errors in dmesg
> > > > >
> > > > > Adding Takashi Iwai
> > > > >
> > > > > [?? 33.980302] usb 2-2.4: 1:1: cannot set freq 48000 to ep 0x1
> > > > > [?? 49.340581] usb 2-2.4: 2:1: cannot set freq 48000 to ep 0x82
> > > > > [?? 59.580511] usb 2-2.4: 13:0: cannot get min/max values for
> > > > > control 2 (id 13)
> > > > > [?? 64.700532] usb 2-2.4: 9:0: cannot get min/max values for control
> > > > > 2 (id 9)
> > > > > [?? 69.792257] usb 2-2.4: 10:0: cannot get min/max values for
> > > > > control 2 (id 10)
> > > > > [?? 69.792736] usbcore: registered new interface driver snd-usb-audio
> > > > > [?? 74.871038] usb 2-2.4: 9:0: cannot get min/max values for control
> > > > > 2 (id 9)
> > > > > [?? 79.967099] usb 2-2.4: 9:0: cannot get min/max values for control
> > > > > 2 (id 9)
> > > > > [?? 85.076961] usb 2-2.4: 9:0: cannot get min/max values for control
> > > > > 2 (id 9)
> > > > > [?? 90.191415] usb 2-2.4: 9:0: cannot get min/max values for control
> > > > > 2 (id 9)
> > > > > [?? 95.308843] usb 2-2.4: 9:0: cannot get min/max values for control
> > > > > 2 (id 9)
> > > > >
> > > > > followed by
> > > > >
> > > > > [? 131.172280] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > > > > [? 136.259909] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > > > > [? 141.380345] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > > > > [? 146.500227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > > > > [? 151.620227] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > > > > [? 156.739899] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > > > > [? 161.859999] usb 2-2.4: 1:1: usb_set_interface failed (-110)
> > > > >
> > > > >
> > > > > I have audio on that port. I haven't tried yet reverting these
> > > > > sound patches yet. demsg is filling up with these messages for
> > > > > sure.
> > > > >
> > > >
> > > > I just tried Linux 5.7-rc4 and it also has this problem. New in rc4 as
> > > > far as I can tell.
> > >
> > > Then it's unlikely from the changes in sound/*, but I'd suspect rather
> > > USB core side.? There is only one change for USB-audio driver and it's
> > > a correction of USB device ID.
> > >
> > >
> >
> > For what its worth not seeing this on 5.4.39-rc1 with the same set of
> > sound changes. I will start bisect on 5.6.11-rc1
> >
>
> I can't reproduce this problem on 5.7-rc1 and 5.6.11-rc1 after seeing
> it once on both.
>
> Tried powerdown vs reboot to see if it is tied to hardware init
> sequence. Doesn't seem to make a difference. Oh well. I will
> update if I see it again.

Thanks for the report, and for testing all of these. Looks like your
USB device got "stuck" in an odd state, if it shows up again, please let
us know on linux-usb@vger.

thanks,

greg k-h

2020-05-05 18:14:28

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On Tue, May 05, 2020 at 08:45:59AM -0700, Guenter Roeck wrote:
> On 5/4/20 10:57 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.6.11 release.
> > There are 73 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 155 pass: 155 fail: 0
> Qemu test results:
> total: 427 pass: 427 fail: 0

Thanks for testing all of these and letting me know.

greg k-h

2020-05-05 18:16:56

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 5.6 00/73] 5.6.11-rc1 review

On Tue, May 05, 2020 at 07:57:55PM +0530, Naresh Kamboju wrote:
> On Mon, 4 May 2020 at 23:36, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.6.11 release.
> > There are 73 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.11-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.6.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Thanks for testing all of these and letting me know.

greg k-h