2021-12-15 17:22:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 00/42] 5.15.9-rc1 review

This is the start of the stable review cycle for the 5.15.9 release.
There are 42 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 Fri, 17 Dec 2021 17:20:14 +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.15.9-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.15.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Adrian Hunter <[email protected]>
perf inject: Fix itrace space allowed for new attributes

Miklos Szeredi <[email protected]>
fuse: make sure reclaim doesn't write the inode

Nikita Yushchenko <[email protected]>
staging: most: dim2: use device release method

Chen Jun <[email protected]>
tracing: Fix a kmemleak false positive in tracing_map

Philip Yang <[email protected]>
drm/amdkfd: process_info lock not needed for svm

Perry Yuan <[email protected]>
drm/amd/display: add connector type check for CRC source set

Philip Yang <[email protected]>
drm/amdkfd: fix double free mem structure

Mustapha Ghaddar <[email protected]>
drm/amd/display: Fix for the no Audio bug with Tiled Displays

Flora Cui <[email protected]>
drm/amdgpu: check atomic flag to differeniate with legacy path

Flora Cui <[email protected]>
drm/amdgpu: cancel the correct hrtimer on exit

Harshit Mogalapalli <[email protected]>
net: netlink: af_netlink: Prevent empty skb by adding a check on len.

Ondrej Jirman <[email protected]>
i2c: rk3x: Handle a spurious start completion interrupt flag

Helge Deller <[email protected]>
parisc/agp: Annotate parisc agp init functions with __init

Kai Vehmanen <[email protected]>
ALSA: hda/hdmi: fix HDA codec entry table order for ADL-P

Kai Vehmanen <[email protected]>
ALSA: hda: Add Intel DG2 PCI ID and HDMI codec vid

Tetsuo Handa <[email protected]>
loop: Use pr_warn_once() for loop_control_remove() warning

Erik Ekman <[email protected]>
net/mlx4_en: Update reported link modes for 1/10G

Alexander Stein <[email protected]>
Revert "tty: serial: fsl_lpuart: drop earlycon entry for i.MX8QXP"

Ilie Halip <[email protected]>
s390/test_unwind: use raw opcode instead of invalid instruction

Marc Zyngier <[email protected]>
KVM: arm64: Save PSTATE early on exit

Douglas Anderson <[email protected]>
drm/msm/dp: Avoid unpowered AUX xfers that caused crashes

Philip Chen <[email protected]>
drm/msm/dsi: set default num_data_lanes

Akhil P Oommen <[email protected]>
drm/msm/a6xx: Fix uinitialized use of gpu_scid

Akhil P Oommen <[email protected]>
drm/msm: Fix null ptr access msm_ioctl_gem_submit()

Vincent Whitchurch <[email protected]>
i2c: virtio: fix completion handling

Ronak Doshi <[email protected]>
vmxnet3: fix minimum vectors alloc issue

Yahui Cao <[email protected]>
ice: fix FDIR init missing when reset VF

Tatyana Nikolova <[email protected]>
RDMA/irdma: Don't arm the CQ more than two times if no CE for this CQ

Shiraz Saleem <[email protected]>
RDMA/irdma: Report correct WC errors

Christophe JAILLET <[email protected]>
RDMA/irdma: Fix a potential memory allocation issue in 'irdma_prm_add_pble_mem()'

Shiraz Saleem <[email protected]>
RDMA/irdma: Fix a user-after-free in add_pble_prm

David Howells <[email protected]>
netfs: Fix lockdep warning from taking sb_writers whilst holding mmap_lock

Song Liu <[email protected]>
perf bpf_skel: Do not use typedef to avoid error on old clang

Martin Botka <[email protected]>
clk: qcom: sm6125-gcc: Swap ops of ice and apps on sdcc1

Rob Herring <[email protected]>
dt-bindings: media: nxp,imx7-mipi-csi2: Drop bad if/then schema

Eric Dumazet <[email protected]>
inet: use #ifdef CONFIG_SOCK_RX_QUEUE_MAPPING consistently

Herve Codina <[email protected]>
mtd: rawnand: Fix nand_choose_best_timings() on unsupported interface

Herve Codina <[email protected]>
mtd: rawnand: Fix nand_erase_op delay

Alaa Hleihel <[email protected]>
RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow

Pavel Skripkin <[email protected]>
RDMA: Fix use-after-free in rxe_queue_cleanup

Wilken Gottwalt <[email protected]>
hwmon: (corsair-psu) fix plain integer used as NULL pointer

Tadeusz Struk <[email protected]>
nfc: fix segfault in nfc_genl_dump_devices_done


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

Diffstat:

.../bindings/media/nxp,imx7-mipi-csi2.yaml | 14 +-----
Makefile | 4 +-
arch/arm64/kvm/hyp/include/hyp/switch.h | 6 +++
arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 7 ++-
arch/s390/lib/test_unwind.c | 5 +-
drivers/block/loop.c | 2 +-
drivers/char/agp/parisc-agp.c | 6 +--
drivers/clk/qcom/gcc-sm6125.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 9 ----
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 8 ++++
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 18 +++----
drivers/gpu/drm/msm/dp/dp_aux.c | 17 +++++++
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +
drivers/gpu/drm/msm/msm_gem_submit.c | 1 +
drivers/hwmon/corsair-psu.c | 2 +-
drivers/i2c/busses/i2c-rk3x.c | 4 +-
drivers/i2c/busses/i2c-virtio.c | 32 +++++--------
drivers/infiniband/hw/irdma/hw.c | 7 ++-
drivers/infiniband/hw/irdma/main.h | 1 +
drivers/infiniband/hw/irdma/pble.c | 8 ++--
drivers/infiniband/hw/irdma/pble.h | 1 -
drivers/infiniband/hw/irdma/utils.c | 24 +++++++---
drivers/infiniband/hw/irdma/verbs.c | 23 +++++++--
drivers/infiniband/hw/irdma/verbs.h | 2 +
drivers/infiniband/hw/mlx5/mlx5_ib.h | 6 +--
drivers/infiniband/hw/mlx5/mr.c | 26 +++++-----
drivers/infiniband/sw/rxe/rxe_qp.c | 1 +
drivers/mtd/nand/raw/nand_base.c | 6 +--
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 2 +
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 6 +--
drivers/net/vmxnet3/vmxnet3_drv.c | 13 ++---
drivers/staging/most/dim2/dim2.c | 55 ++++++++++++----------
drivers/tty/serial/fsl_lpuart.c | 1 +
fs/fuse/dir.c | 8 ++++
fs/fuse/file.c | 15 ++++++
fs/fuse/fuse_i.h | 1 +
fs/fuse/inode.c | 3 ++
fs/netfs/read_helper.c | 15 ++----
kernel/trace/tracing_map.c | 3 ++
net/ipv4/inet_connection_sock.c | 2 +-
net/netlink/af_netlink.c | 5 ++
net/nfc/netlink.c | 6 ++-
sound/pci/hda/hda_intel.c | 12 ++++-
sound/pci/hda/patch_hdmi.c | 3 +-
tools/perf/builtin-inject.c | 2 +-
tools/perf/util/bpf_skel/bperf.h | 14 ------
tools/perf/util/bpf_skel/bperf_follower.bpf.c | 16 +++++--
tools/perf/util/bpf_skel/bperf_leader.bpf.c | 16 +++++--
52 files changed, 284 insertions(+), 180 deletions(-)




2021-12-15 17:22:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 02/42] hwmon: (corsair-psu) fix plain integer used as NULL pointer

From: Wilken Gottwalt <[email protected]>

[ Upstream commit 8383226583251858814d5521b542e7bf7dbadc4b ]

sparse warnings: (new ones prefixed by >>)
>> drivers/hwmon/corsair-psu.c:536:82: sparse: sparse: Using plain
integer as NULL pointer

Fixes: d115b51e0e56 ("hwmon: add Corsair PSU HID controller driver")
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Wilken Gottwalt <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/hwmon/corsair-psu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/corsair-psu.c b/drivers/hwmon/corsair-psu.c
index 731d5117f9f10..14389fd7afb89 100644
--- a/drivers/hwmon/corsair-psu.c
+++ b/drivers/hwmon/corsair-psu.c
@@ -729,7 +729,7 @@ static int corsairpsu_probe(struct hid_device *hdev, const struct hid_device_id
corsairpsu_check_cmd_support(priv);

priv->hwmon_dev = hwmon_device_register_with_info(&hdev->dev, "corsairpsu", priv,
- &corsairpsu_chip_info, 0);
+ &corsairpsu_chip_info, NULL);

if (IS_ERR(priv->hwmon_dev)) {
ret = PTR_ERR(priv->hwmon_dev);
--
2.33.0




2021-12-15 17:22:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 11/42] netfs: Fix lockdep warning from taking sb_writers whilst holding mmap_lock

From: David Howells <[email protected]>

[ Upstream commit 598ad0bd09329818ee041cb3e4b60ba0a70cb1ee ]

Taking sb_writers whilst holding mmap_lock isn't allowed and will result in
a lockdep warning like that below. The problem comes from cachefiles
needing to take the sb_writers lock in order to do a write to the cache,
but being asked to do this by netfslib called from readpage, readahead or
write_begin[1].

Fix this by always offloading the write to the cache off to a worker
thread. The main thread doesn't need to wait for it, so deadlock can be
avoided.

This can be tested by running the quick xfstests on something like afs or
ceph with lockdep enabled.

WARNING: possible circular locking dependency detected
5.15.0-rc1-build2+ #292 Not tainted
------------------------------------------------------
holetest/65517 is trying to acquire lock:
ffff88810c81d730 (mapping.invalidate_lock#3){.+.+}-{3:3}, at: filemap_fault+0x276/0x7a5

but task is already holding lock:
ffff8881595b53e8 (&mm->mmap_lock#2){++++}-{3:3}, at: do_user_addr_fault+0x28d/0x59c

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&mm->mmap_lock#2){++++}-{3:3}:
validate_chain+0x3c4/0x4a8
__lock_acquire+0x89d/0x949
lock_acquire+0x2dc/0x34b
__might_fault+0x87/0xb1
strncpy_from_user+0x25/0x18c
removexattr+0x7c/0xe5
__do_sys_fremovexattr+0x73/0x96
do_syscall_64+0x67/0x7a
entry_SYSCALL_64_after_hwframe+0x44/0xae

-> #1 (sb_writers#10){.+.+}-{0:0}:
validate_chain+0x3c4/0x4a8
__lock_acquire+0x89d/0x949
lock_acquire+0x2dc/0x34b
cachefiles_write+0x2b3/0x4bb
netfs_rreq_do_write_to_cache+0x3b5/0x432
netfs_readpage+0x2de/0x39d
filemap_read_page+0x51/0x94
filemap_get_pages+0x26f/0x413
filemap_read+0x182/0x427
new_sync_read+0xf0/0x161
vfs_read+0x118/0x16e
ksys_read+0xb8/0x12e
do_syscall_64+0x67/0x7a
entry_SYSCALL_64_after_hwframe+0x44/0xae

-> #0 (mapping.invalidate_lock#3){.+.+}-{3:3}:
check_noncircular+0xe4/0x129
check_prev_add+0x16b/0x3a4
validate_chain+0x3c4/0x4a8
__lock_acquire+0x89d/0x949
lock_acquire+0x2dc/0x34b
down_read+0x40/0x4a
filemap_fault+0x276/0x7a5
__do_fault+0x96/0xbf
do_fault+0x262/0x35a
__handle_mm_fault+0x171/0x1b5
handle_mm_fault+0x12a/0x233
do_user_addr_fault+0x3d2/0x59c
exc_page_fault+0x85/0xa5
asm_exc_page_fault+0x1e/0x30

other info that might help us debug this:

Chain exists of:
mapping.invalidate_lock#3 --> sb_writers#10 --> &mm->mmap_lock#2

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&mm->mmap_lock#2);
lock(sb_writers#10);
lock(&mm->mmap_lock#2);
lock(mapping.invalidate_lock#3);

*** DEADLOCK ***

1 lock held by holetest/65517:
#0: ffff8881595b53e8 (&mm->mmap_lock#2){++++}-{3:3}, at: do_user_addr_fault+0x28d/0x59c

stack backtrace:
CPU: 0 PID: 65517 Comm: holetest Not tainted 5.15.0-rc1-build2+ #292
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
Call Trace:
dump_stack_lvl+0x45/0x59
check_noncircular+0xe4/0x129
? print_circular_bug+0x207/0x207
? validate_chain+0x461/0x4a8
? add_chain_block+0x88/0xd9
? hlist_add_head_rcu+0x49/0x53
check_prev_add+0x16b/0x3a4
validate_chain+0x3c4/0x4a8
? check_prev_add+0x3a4/0x3a4
? mark_lock+0xa5/0x1c6
__lock_acquire+0x89d/0x949
lock_acquire+0x2dc/0x34b
? filemap_fault+0x276/0x7a5
? rcu_read_unlock+0x59/0x59
? add_to_page_cache_lru+0x13c/0x13c
? lock_is_held_type+0x7b/0xd3
down_read+0x40/0x4a
? filemap_fault+0x276/0x7a5
filemap_fault+0x276/0x7a5
? pagecache_get_page+0x2dd/0x2dd
? __lock_acquire+0x8bc/0x949
? pte_offset_kernel.isra.0+0x6d/0xc3
__do_fault+0x96/0xbf
? do_fault+0x124/0x35a
do_fault+0x262/0x35a
? handle_pte_fault+0x1c1/0x20d
__handle_mm_fault+0x171/0x1b5
? handle_pte_fault+0x20d/0x20d
? __lock_release+0x151/0x254
? mark_held_locks+0x1f/0x78
? rcu_read_unlock+0x3a/0x59
handle_mm_fault+0x12a/0x233
do_user_addr_fault+0x3d2/0x59c
? pgtable_bad+0x70/0x70
? rcu_read_lock_bh_held+0xab/0xab
exc_page_fault+0x85/0xa5
? asm_exc_page_fault+0x8/0x30
asm_exc_page_fault+0x1e/0x30
RIP: 0033:0x40192f
Code: ff 48 89 c3 48 8b 05 50 28 00 00 48 85 ed 7e 23 31 d2 4b 8d 0c 2f eb 0a 0f 1f 00 48 8b 05 39 28 00 00 48 0f af c2 48 83 c2 01 <48> 89 1c 01 48 39 d5 7f e8 8b 0d f2 27 00 00 31 c0 85 c9 74 0e 8b
RSP: 002b:00007f9931867eb0 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 00007f9931868700 RCX: 00007f993206ac00
RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00007ffc13e06ee0
RBP: 0000000000000100 R08: 0000000000000000 R09: 00007f9931868700
R10: 00007f99318689d0 R11: 0000000000000202 R12: 00007ffc13e06ee0
R13: 0000000000000c00 R14: 00007ffc13e06e00 R15: 00007f993206a000

Fixes: 726218fdc22c ("netfs: Define an interface to talk to a cache")
Signed-off-by: David Howells <[email protected]>
Tested-by: Jeff Layton <[email protected]>
cc: Jan Kara <[email protected]>
cc: [email protected]
cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]/ [1]
Link: https://lore.kernel.org/r/163887597541.1596626.2668163316598972956.stgit@warthog.procyon.org.uk/ # v1
Signed-off-by: Sasha Levin <[email protected]>
---
fs/netfs/read_helper.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/fs/netfs/read_helper.c b/fs/netfs/read_helper.c
index 994ec22d40402..4b54529f8176b 100644
--- a/fs/netfs/read_helper.c
+++ b/fs/netfs/read_helper.c
@@ -354,16 +354,11 @@ static void netfs_rreq_write_to_cache_work(struct work_struct *work)
netfs_rreq_do_write_to_cache(rreq);
}

-static void netfs_rreq_write_to_cache(struct netfs_read_request *rreq,
- bool was_async)
+static void netfs_rreq_write_to_cache(struct netfs_read_request *rreq)
{
- if (was_async) {
- rreq->work.func = netfs_rreq_write_to_cache_work;
- if (!queue_work(system_unbound_wq, &rreq->work))
- BUG();
- } else {
- netfs_rreq_do_write_to_cache(rreq);
- }
+ rreq->work.func = netfs_rreq_write_to_cache_work;
+ if (!queue_work(system_unbound_wq, &rreq->work))
+ BUG();
}

/*
@@ -560,7 +555,7 @@ static void netfs_rreq_assess(struct netfs_read_request *rreq, bool was_async)
wake_up_bit(&rreq->flags, NETFS_RREQ_IN_PROGRESS);

if (test_bit(NETFS_RREQ_WRITE_TO_CACHE, &rreq->flags))
- return netfs_rreq_write_to_cache(rreq, was_async);
+ return netfs_rreq_write_to_cache(rreq);

netfs_rreq_completed(rreq, was_async);
}
--
2.33.0




2021-12-15 17:22:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 12/42] RDMA/irdma: Fix a user-after-free in add_pble_prm

From: Shiraz Saleem <[email protected]>

[ Upstream commit 1e11a39a82e95ce86f849f40dda0d9c0498cebd9 ]

When irdma_hmc_sd_one fails, 'chunk' is freed while its still on the PBLE
info list.

Add the chunk entry to the PBLE info list only after successful setting of
the SD in irdma_hmc_sd_one.

Fixes: e8c4dbc2fcac ("RDMA/irdma: Add PBLE resource manager")
Link: https://lore.kernel.org/r/[email protected]
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Shiraz Saleem <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/infiniband/hw/irdma/pble.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/irdma/pble.c b/drivers/infiniband/hw/irdma/pble.c
index aeeb1c310965d..da032b952755e 100644
--- a/drivers/infiniband/hw/irdma/pble.c
+++ b/drivers/infiniband/hw/irdma/pble.c
@@ -283,7 +283,6 @@ add_pble_prm(struct irdma_hmc_pble_rsrc *pble_rsrc)
"PBLE: next_fpm_addr = %llx chunk_size[%llu] = 0x%llx\n",
pble_rsrc->next_fpm_addr, chunk->size, chunk->size);
pble_rsrc->unallocated_pble -= (u32)(chunk->size >> 3);
- list_add(&chunk->list, &pble_rsrc->pinfo.clist);
sd_reg_val = (sd_entry_type == IRDMA_SD_TYPE_PAGED) ?
sd_entry->u.pd_table.pd_page_addr.pa :
sd_entry->u.bp.addr.pa;
@@ -295,6 +294,7 @@ add_pble_prm(struct irdma_hmc_pble_rsrc *pble_rsrc)
goto error;
}

+ list_add(&chunk->list, &pble_rsrc->pinfo.clist);
sd_entry->valid = true;
return 0;

--
2.33.0




2021-12-15 17:22:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 13/42] RDMA/irdma: Fix a potential memory allocation issue in irdma_prm_add_pble_mem()

From: Christophe JAILLET <[email protected]>

[ Upstream commit 117697cc935b0ab04ec66274d8e64ccfebd7d0d2 ]

'pchunk->bitmapbuf' is a bitmap. Its size (in number of bits) is stored in
'pchunk->sizeofbitmap'.

When it is allocated, the size (in bytes) is computed by:
size_in_bits >> 3

There are 2 issues (numbers bellow assume that longs are 64 bits):
- there is no guarantee here that 'pchunk->bitmapmem.size' is modulo
BITS_PER_LONG but bitmaps are stored as longs
(sizeofbitmap=8 bits will only allocate 1 byte, instead of 8 (1 long))

- the number of bytes is computed with a shift, not a round up, so we
may allocate less memory than needed
(sizeofbitmap=65 bits will only allocate 8 bytes (i.e. 1 long), when 2
longs are needed = 16 bytes)

Fix both issues by using 'bitmap_zalloc()' and remove the useless
'bitmapmem' from 'struct irdma_chunk'.

While at it, remove some useless NULL test before calling
kfree/bitmap_free.

Fixes: 915cc7ac0f8e ("RDMA/irdma: Add miscellaneous utility definitions")
Link: https://lore.kernel.org/r/5e670b640508e14b1869c3e8e4fb970d78cbe997.1638692171.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <[email protected]>
Reviewed-by: Shiraz Saleem <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/infiniband/hw/irdma/pble.c | 6 ++----
drivers/infiniband/hw/irdma/pble.h | 1 -
drivers/infiniband/hw/irdma/utils.c | 9 ++-------
3 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/infiniband/hw/irdma/pble.c b/drivers/infiniband/hw/irdma/pble.c
index da032b952755e..fed49da770f3b 100644
--- a/drivers/infiniband/hw/irdma/pble.c
+++ b/drivers/infiniband/hw/irdma/pble.c
@@ -25,8 +25,7 @@ void irdma_destroy_pble_prm(struct irdma_hmc_pble_rsrc *pble_rsrc)
list_del(&chunk->list);
if (chunk->type == PBLE_SD_PAGED)
irdma_pble_free_paged_mem(chunk);
- if (chunk->bitmapbuf)
- kfree(chunk->bitmapmem.va);
+ bitmap_free(chunk->bitmapbuf);
kfree(chunk->chunkmem.va);
}
}
@@ -299,8 +298,7 @@ add_pble_prm(struct irdma_hmc_pble_rsrc *pble_rsrc)
return 0;

error:
- if (chunk->bitmapbuf)
- kfree(chunk->bitmapmem.va);
+ bitmap_free(chunk->bitmapbuf);
kfree(chunk->chunkmem.va);

return ret_code;
diff --git a/drivers/infiniband/hw/irdma/pble.h b/drivers/infiniband/hw/irdma/pble.h
index e1b3b8118a2ca..aa20827dcc9de 100644
--- a/drivers/infiniband/hw/irdma/pble.h
+++ b/drivers/infiniband/hw/irdma/pble.h
@@ -78,7 +78,6 @@ struct irdma_chunk {
u32 pg_cnt;
enum irdma_alloc_type type;
struct irdma_sc_dev *dev;
- struct irdma_virt_mem bitmapmem;
struct irdma_virt_mem chunkmem;
};

diff --git a/drivers/infiniband/hw/irdma/utils.c b/drivers/infiniband/hw/irdma/utils.c
index ac91ea5296db9..1bbf23689de48 100644
--- a/drivers/infiniband/hw/irdma/utils.c
+++ b/drivers/infiniband/hw/irdma/utils.c
@@ -2284,15 +2284,10 @@ enum irdma_status_code irdma_prm_add_pble_mem(struct irdma_pble_prm *pprm,

sizeofbitmap = (u64)pchunk->size >> pprm->pble_shift;

- pchunk->bitmapmem.size = sizeofbitmap >> 3;
- pchunk->bitmapmem.va = kzalloc(pchunk->bitmapmem.size, GFP_KERNEL);
-
- if (!pchunk->bitmapmem.va)
+ pchunk->bitmapbuf = bitmap_zalloc(sizeofbitmap, GFP_KERNEL);
+ if (!pchunk->bitmapbuf)
return IRDMA_ERR_NO_MEMORY;

- pchunk->bitmapbuf = pchunk->bitmapmem.va;
- bitmap_zero(pchunk->bitmapbuf, sizeofbitmap);
-
pchunk->sizeofbitmap = sizeofbitmap;
/* each pble is 8 bytes hence shift by 3 */
pprm->total_pble_alloc += pchunk->size >> 3;
--
2.33.0




2021-12-15 17:23:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 14/42] RDMA/irdma: Report correct WC errors

From: Shiraz Saleem <[email protected]>

[ Upstream commit 25b5d6fd6d13b2de3780a0ae247befc43c4576fe ]

Return IBV_WC_REM_OP_ERR for responder QP errors instead of
IBV_WC_REM_ACCESS_ERR.

Return IBV_WC_LOC_QP_OP_ERR for errors detected on the SQ with bad opcodes

Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Shiraz Saleem <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/infiniband/hw/irdma/hw.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/irdma/hw.c b/drivers/infiniband/hw/irdma/hw.c
index 7de525a5ccf8c..7f58a1b9bb4f8 100644
--- a/drivers/infiniband/hw/irdma/hw.c
+++ b/drivers/infiniband/hw/irdma/hw.c
@@ -146,6 +146,7 @@ static void irdma_set_flush_fields(struct irdma_sc_qp *qp,
qp->flush_code = FLUSH_PROT_ERR;
break;
case IRDMA_AE_AMP_BAD_QP:
+ case IRDMA_AE_WQE_UNEXPECTED_OPCODE:
qp->flush_code = FLUSH_LOC_QP_OP_ERR;
break;
case IRDMA_AE_AMP_BAD_STAG_KEY:
@@ -156,7 +157,6 @@ static void irdma_set_flush_fields(struct irdma_sc_qp *qp,
case IRDMA_AE_PRIV_OPERATION_DENIED:
case IRDMA_AE_IB_INVALID_REQUEST:
case IRDMA_AE_IB_REMOTE_ACCESS_ERROR:
- case IRDMA_AE_IB_REMOTE_OP_ERROR:
qp->flush_code = FLUSH_REM_ACCESS_ERR;
qp->event_type = IRDMA_QP_EVENT_ACCESS_ERR;
break;
@@ -184,6 +184,9 @@ static void irdma_set_flush_fields(struct irdma_sc_qp *qp,
case IRDMA_AE_AMP_MWBIND_INVALID_BOUNDS:
qp->flush_code = FLUSH_MW_BIND_ERR;
break;
+ case IRDMA_AE_IB_REMOTE_OP_ERROR:
+ qp->flush_code = FLUSH_REM_OP_ERR;
+ break;
default:
qp->flush_code = FLUSH_FATAL_ERR;
break;
--
2.33.0




2021-12-15 17:23:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 15/42] RDMA/irdma: Dont arm the CQ more than two times if no CE for this CQ

From: Tatyana Nikolova <[email protected]>

[ Upstream commit 10467ce09fefa2e74359f5b2ab1efb8909402f19 ]

Completion events (CEs) are lost if the application is allowed to arm the
CQ more than two times when no new CE for this CQ has been generated by
the HW.

Check if arming has been done for the CQ and if not, arm the CQ for any
event otherwise promote to arm the CQ for any event only when the last arm
event was solicited.

Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Tatyana Nikolova <[email protected]>
Signed-off-by: Shiraz Saleem <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/infiniband/hw/irdma/hw.c | 2 ++
drivers/infiniband/hw/irdma/main.h | 1 +
drivers/infiniband/hw/irdma/utils.c | 15 +++++++++++++++
drivers/infiniband/hw/irdma/verbs.c | 23 ++++++++++++++++++-----
drivers/infiniband/hw/irdma/verbs.h | 2 ++
5 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/drivers/infiniband/hw/irdma/hw.c b/drivers/infiniband/hw/irdma/hw.c
index 7f58a1b9bb4f8..aa119441eb45c 100644
--- a/drivers/infiniband/hw/irdma/hw.c
+++ b/drivers/infiniband/hw/irdma/hw.c
@@ -60,6 +60,8 @@ static void irdma_iwarp_ce_handler(struct irdma_sc_cq *iwcq)
{
struct irdma_cq *cq = iwcq->back_cq;

+ if (!cq->user_mode)
+ cq->armed = false;
if (cq->ibcq.comp_handler)
cq->ibcq.comp_handler(&cq->ibcq, cq->ibcq.cq_context);
}
diff --git a/drivers/infiniband/hw/irdma/main.h b/drivers/infiniband/hw/irdma/main.h
index b678fe712447e..8b215f3cee891 100644
--- a/drivers/infiniband/hw/irdma/main.h
+++ b/drivers/infiniband/hw/irdma/main.h
@@ -541,6 +541,7 @@ int irdma_ah_cqp_op(struct irdma_pci_f *rf, struct irdma_sc_ah *sc_ah, u8 cmd,
void (*callback_fcn)(struct irdma_cqp_request *cqp_request),
void *cb_param);
void irdma_gsi_ud_qp_ah_cb(struct irdma_cqp_request *cqp_request);
+bool irdma_cq_empty(struct irdma_cq *iwcq);
int irdma_inetaddr_event(struct notifier_block *notifier, unsigned long event,
void *ptr);
int irdma_inet6addr_event(struct notifier_block *notifier, unsigned long event,
diff --git a/drivers/infiniband/hw/irdma/utils.c b/drivers/infiniband/hw/irdma/utils.c
index 1bbf23689de48..feebfe6bf31ad 100644
--- a/drivers/infiniband/hw/irdma/utils.c
+++ b/drivers/infiniband/hw/irdma/utils.c
@@ -2531,3 +2531,18 @@ void irdma_ib_qp_event(struct irdma_qp *iwqp, enum irdma_qp_event_type event)
ibevent.element.qp = &iwqp->ibqp;
iwqp->ibqp.event_handler(&ibevent, iwqp->ibqp.qp_context);
}
+
+bool irdma_cq_empty(struct irdma_cq *iwcq)
+{
+ struct irdma_cq_uk *ukcq;
+ u64 qword3;
+ __le64 *cqe;
+ u8 polarity;
+
+ ukcq = &iwcq->sc_cq.cq_uk;
+ cqe = IRDMA_GET_CURRENT_CQ_ELEM(ukcq);
+ get_64bit_val(cqe, 24, &qword3);
+ polarity = (u8)FIELD_GET(IRDMA_CQ_VALID, qword3);
+
+ return polarity != ukcq->polarity;
+}
diff --git a/drivers/infiniband/hw/irdma/verbs.c b/drivers/infiniband/hw/irdma/verbs.c
index 102dc9342f2a2..8bbc4620a97a2 100644
--- a/drivers/infiniband/hw/irdma/verbs.c
+++ b/drivers/infiniband/hw/irdma/verbs.c
@@ -3604,18 +3604,31 @@ static int irdma_req_notify_cq(struct ib_cq *ibcq,
struct irdma_cq *iwcq;
struct irdma_cq_uk *ukcq;
unsigned long flags;
- enum irdma_cmpl_notify cq_notify = IRDMA_CQ_COMPL_EVENT;
+ enum irdma_cmpl_notify cq_notify;
+ bool promo_event = false;
+ int ret = 0;

+ cq_notify = notify_flags == IB_CQ_SOLICITED ?
+ IRDMA_CQ_COMPL_SOLICITED : IRDMA_CQ_COMPL_EVENT;
iwcq = to_iwcq(ibcq);
ukcq = &iwcq->sc_cq.cq_uk;
- if (notify_flags == IB_CQ_SOLICITED)
- cq_notify = IRDMA_CQ_COMPL_SOLICITED;

spin_lock_irqsave(&iwcq->lock, flags);
- irdma_uk_cq_request_notification(ukcq, cq_notify);
+ /* Only promote to arm the CQ for any event if the last arm event was solicited. */
+ if (iwcq->last_notify == IRDMA_CQ_COMPL_SOLICITED && notify_flags != IB_CQ_SOLICITED)
+ promo_event = true;
+
+ if (!iwcq->armed || promo_event) {
+ iwcq->armed = true;
+ iwcq->last_notify = cq_notify;
+ irdma_uk_cq_request_notification(ukcq, cq_notify);
+ }
+
+ if ((notify_flags & IB_CQ_REPORT_MISSED_EVENTS) && !irdma_cq_empty(iwcq))
+ ret = 1;
spin_unlock_irqrestore(&iwcq->lock, flags);

- return 0;
+ return ret;
}

static int irdma_roce_port_immutable(struct ib_device *ibdev, u32 port_num,
diff --git a/drivers/infiniband/hw/irdma/verbs.h b/drivers/infiniband/hw/irdma/verbs.h
index 5c244cd321a3a..d0fdef8d09ead 100644
--- a/drivers/infiniband/hw/irdma/verbs.h
+++ b/drivers/infiniband/hw/irdma/verbs.h
@@ -110,6 +110,8 @@ struct irdma_cq {
u16 cq_size;
u16 cq_num;
bool user_mode;
+ bool armed;
+ enum irdma_cmpl_notify last_notify;
u32 polled_cmpls;
u32 cq_mem_size;
struct irdma_dma_mem kmem;
--
2.33.0




2021-12-15 17:23:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 03/42] RDMA: Fix use-after-free in rxe_queue_cleanup

From: Pavel Skripkin <[email protected]>

[ Upstream commit 84b01721e8042cdd1e8ffeb648844a09cd4213e0 ]

On error handling path in rxe_qp_from_init() qp->sq.queue is freed and
then rxe_create_qp() will drop last reference to this object. qp clean up
function will try to free this queue one time and it causes UAF bug.

Fix it by zeroing queue pointer after freeing queue in rxe_qp_from_init().

Fixes: 514aee660df4 ("RDMA: Globally allocate and release QP memory")
Link: https://lore.kernel.org/r/[email protected]
Reported-by: [email protected]
Signed-off-by: Pavel Skripkin <[email protected]>
Reviewed-by: Zhu Yanjun <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/infiniband/sw/rxe/rxe_qp.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/sw/rxe/rxe_qp.c b/drivers/infiniband/sw/rxe/rxe_qp.c
index 1ab6af7ddb254..ed326d82725cd 100644
--- a/drivers/infiniband/sw/rxe/rxe_qp.c
+++ b/drivers/infiniband/sw/rxe/rxe_qp.c
@@ -367,6 +367,7 @@ int rxe_qp_from_init(struct rxe_dev *rxe, struct rxe_qp *qp, struct rxe_pd *pd,

err2:
rxe_queue_cleanup(qp->sq.queue);
+ qp->sq.queue = NULL;
err1:
qp->pd = NULL;
qp->rcq = NULL;
--
2.33.0




2021-12-15 17:23:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 05/42] mtd: rawnand: Fix nand_erase_op delay

From: Herve Codina <[email protected]>

[ Upstream commit 16d8b628a4152e8e8b01b6a1d82e30208ee2dd30 ]

NAND_OP_CMD() expects a delay parameter in nanoseconds.
The delay value is wrongly given in milliseconds.

Fix the conversion macro used in order to set this
delay in nanoseconds.

Fixes: d7a773e8812b ("mtd: rawnand: Access SDR and NV-DDR timings through a common macro")
Signed-off-by: Herve Codina <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/mtd/nand/raw/nand_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 3d6c6e8805207..5c6b065837eff 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -1837,7 +1837,7 @@ int nand_erase_op(struct nand_chip *chip, unsigned int eraseblock)
NAND_OP_CMD(NAND_CMD_ERASE1, 0),
NAND_OP_ADDR(2, addrs, 0),
NAND_OP_CMD(NAND_CMD_ERASE2,
- NAND_COMMON_TIMING_MS(conf, tWB_max)),
+ NAND_COMMON_TIMING_NS(conf, tWB_max)),
NAND_OP_WAIT_RDY(NAND_COMMON_TIMING_MS(conf, tBERS_max),
0),
};
--
2.33.0




2021-12-15 17:23:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 04/42] RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow

From: Alaa Hleihel <[email protected]>

[ Upstream commit f0ae4afe3d35e67db042c58a52909e06262b740f ]

For the case of IB_MR_TYPE_DM the mr does doesn't have a umem, even though
it is a user MR. This causes function mlx5_free_priv_descs() to think that
it is a kernel MR, leading to wrongly accessing mr->descs that will get
wrong values in the union which leads to attempt to release resources that
were not allocated in the first place.

For example:
DMA-API: mlx5_core 0000:08:00.1: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=0 bytes]
WARNING: CPU: 8 PID: 1021 at kernel/dma/debug.c:961 check_unmap+0x54f/0x8b0
RIP: 0010:check_unmap+0x54f/0x8b0
Call Trace:
debug_dma_unmap_page+0x57/0x60
mlx5_free_priv_descs+0x57/0x70 [mlx5_ib]
mlx5_ib_dereg_mr+0x1fb/0x3d0 [mlx5_ib]
ib_dereg_mr_user+0x60/0x140 [ib_core]
uverbs_destroy_uobject+0x59/0x210 [ib_uverbs]
uobj_destroy+0x3f/0x80 [ib_uverbs]
ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs]
? uverbs_finalize_object+0x50/0x50 [ib_uverbs]
? lock_acquire+0xc4/0x2e0
? lock_acquired+0x12/0x380
? lock_acquire+0xc4/0x2e0
? lock_acquire+0xc4/0x2e0
? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]
? lock_release+0x28a/0x400
ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs]
? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]
__x64_sys_ioctl+0x7f/0xb0
do_syscall_64+0x38/0x90

Fix it by reorganizing the dereg flow and mlx5_ib_mr structure:
- Move the ib_umem field into the user MRs structure in the union as it's
applicable only there.
- Function mlx5_ib_dereg_mr() will now call mlx5_free_priv_descs() only
in case there isn't udata, which indicates that this isn't a user MR.

Fixes: f18ec4223117 ("RDMA/mlx5: Use a union inside mlx5_ib_mr")
Link: https://lore.kernel.org/r/66bb1dd253c1fd7ceaa9fc411061eefa457b86fb.1637581144.git.leonro@nvidia.com
Signed-off-by: Alaa Hleihel <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/infiniband/hw/mlx5/mlx5_ib.h | 6 +++---
drivers/infiniband/hw/mlx5/mr.c | 26 ++++++++++++--------------
2 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index bf20a388eabe1..6204ae2caef58 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -641,7 +641,6 @@ struct mlx5_ib_mr {

/* User MR data */
struct mlx5_cache_ent *cache_ent;
- struct ib_umem *umem;

/* This is zero'd when the MR is allocated */
union {
@@ -653,7 +652,7 @@ struct mlx5_ib_mr {
struct list_head list;
};

- /* Used only by kernel MRs (umem == NULL) */
+ /* Used only by kernel MRs */
struct {
void *descs;
void *descs_alloc;
@@ -675,8 +674,9 @@ struct mlx5_ib_mr {
int data_length;
};

- /* Used only by User MRs (umem != NULL) */
+ /* Used only by User MRs */
struct {
+ struct ib_umem *umem;
unsigned int page_shift;
/* Current access_flags */
int access_flags;
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index 22e2f4d79743d..69b2ce4c292ae 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1911,19 +1911,18 @@ mlx5_alloc_priv_descs(struct ib_device *device,
return ret;
}

-static void
-mlx5_free_priv_descs(struct mlx5_ib_mr *mr)
+static void mlx5_free_priv_descs(struct mlx5_ib_mr *mr)
{
- if (!mr->umem && mr->descs) {
- struct ib_device *device = mr->ibmr.device;
- int size = mr->max_descs * mr->desc_size;
- struct mlx5_ib_dev *dev = to_mdev(device);
+ struct mlx5_ib_dev *dev = to_mdev(mr->ibmr.device);
+ int size = mr->max_descs * mr->desc_size;

- dma_unmap_single(&dev->mdev->pdev->dev, mr->desc_map, size,
- DMA_TO_DEVICE);
- kfree(mr->descs_alloc);
- mr->descs = NULL;
- }
+ if (!mr->descs)
+ return;
+
+ dma_unmap_single(&dev->mdev->pdev->dev, mr->desc_map, size,
+ DMA_TO_DEVICE);
+ kfree(mr->descs_alloc);
+ mr->descs = NULL;
}

int mlx5_ib_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata)
@@ -1999,7 +1998,8 @@ int mlx5_ib_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata)
if (mr->cache_ent) {
mlx5_mr_cache_free(dev, mr);
} else {
- mlx5_free_priv_descs(mr);
+ if (!udata)
+ mlx5_free_priv_descs(mr);
kfree(mr);
}
return 0;
@@ -2086,7 +2086,6 @@ static struct mlx5_ib_mr *mlx5_ib_alloc_pi_mr(struct ib_pd *pd,
if (err)
goto err_free_in;

- mr->umem = NULL;
kfree(in);

return mr;
@@ -2213,7 +2212,6 @@ static struct ib_mr *__mlx5_ib_alloc_mr(struct ib_pd *pd,
}

mr->ibmr.device = pd->device;
- mr->umem = NULL;

switch (mr_type) {
case IB_MR_TYPE_MEM_REG:
--
2.33.0




2021-12-15 17:23:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 06/42] mtd: rawnand: Fix nand_choose_best_timings() on unsupported interface

From: Herve Codina <[email protected]>

[ Upstream commit 36a65982a98c4bc72fdcfef2c4aaf90193746631 ]

When the NV-DDR interface is not supported by the NAND chip,
the value of onfi->nvddr_timing_modes is 0. In this case,
the best_mode variable value in nand_choose_best_nvddr_timings()
is -1. The last for-loop is skipped and the function returns an
uninitialized value.
If this returned value is 0, the nand_choose_best_sdr_timings()
is not executed and no 'best timing' are set. This leads the host
controller and the NAND chip working at default mode 0 timing
even if a better timing can be used.

Fix this uninitialized returned value.

nand_choose_best_sdr_timings() is pretty similar to
nand_choose_best_nvddr_timings(). Even if onfi->sdr_timing_modes
should never be seen as 0, nand_choose_best_sdr_timings() returned
value is fixed.

Fixes: a9ecc8c814e9 ("mtd: rawnand: Choose the best timings, NV-DDR included")
Signed-off-by: Herve Codina <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/mtd/nand/raw/nand_base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 5c6b065837eff..a130320de4128 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -926,7 +926,7 @@ int nand_choose_best_sdr_timings(struct nand_chip *chip,
struct nand_sdr_timings *spec_timings)
{
const struct nand_controller_ops *ops = chip->controller->ops;
- int best_mode = 0, mode, ret;
+ int best_mode = 0, mode, ret = -EOPNOTSUPP;

iface->type = NAND_SDR_IFACE;

@@ -977,7 +977,7 @@ int nand_choose_best_nvddr_timings(struct nand_chip *chip,
struct nand_nvddr_timings *spec_timings)
{
const struct nand_controller_ops *ops = chip->controller->ops;
- int best_mode = 0, mode, ret;
+ int best_mode = 0, mode, ret = -EOPNOTSUPP;

iface->type = NAND_NVDDR_IFACE;

--
2.33.0




2021-12-15 17:23:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 08/42] dt-bindings: media: nxp,imx7-mipi-csi2: Drop bad if/then schema

From: Rob Herring <[email protected]>

[ Upstream commit b54472a02cefd0dc468158bbc4d636b27cd6fc34 ]

The if/then schema for 'data-lanes' doesn't work as 'compatible' is at a
different level than 'data-lanes'. To make it work, the if/then schema
would have to be moved to the top level and then whole hierarchy of
nodes down to 'data-lanes' created. I don't think it is worth the
complexity to do that, so let's just drop it.

The error in this schema is masked by a fixup in the tools causing the
'allOf' to get overwritten. Removing the fixup as part of moving to
json-schema draft 2019-09 revealed the issue:

Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.example.dt.yaml: mipi-csi@30750000: ports:port@0:endpoint:data-lanes:0: [1] is too short
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.example.dt.yaml: mipi-csi@32e30000: ports:port@0:endpoint:data-lanes:0: [1, 2, 3, 4] is too long
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml

The if condition was always true because 'compatible' did not exist in
'endpoint' node and a non-existent property is true for json-schema.

Fixes: 85b62ff2cb97 ("media: dt-bindings: media: nxp,imx7-mipi-csi2: Add i.MX8MM support")
Cc: Rui Miguel Silva <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: Pengutronix Kernel Team <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: NXP Linux Team <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Rob Herring <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Acked-by: Rui Miguel Silva <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
.../bindings/media/nxp,imx7-mipi-csi2.yaml | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
index 877183cf42787..1ef849dc74d7e 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
@@ -79,6 +79,8 @@ properties:

properties:
data-lanes:
+ description:
+ Note that 'fsl,imx7-mipi-csi2' only supports up to 2 data lines.
items:
minItems: 1
maxItems: 4
@@ -91,18 +93,6 @@ properties:
required:
- data-lanes

- allOf:
- - if:
- properties:
- compatible:
- contains:
- const: fsl,imx7-mipi-csi2
- then:
- properties:
- data-lanes:
- items:
- maxItems: 2
-
port@1:
$ref: /schemas/graph.yaml#/properties/port
description:
--
2.33.0




2021-12-15 17:23:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 09/42] clk: qcom: sm6125-gcc: Swap ops of ice and apps on sdcc1

From: Martin Botka <[email protected]>

[ Upstream commit e53f2086856c16ccab80fd0ac012baa1ae88af73 ]

Without this change eMMC runs at overclocked freq.
Swap the ops to not OC the eMMC.

Signed-off-by: Martin Botka <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bjorn Andersson <[email protected]>
Fixes: 4b8d6ae57cdf ("clk: qcom: Add SM6125 (TRINKET) GCC driver")
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/clk/qcom/gcc-sm6125.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/qcom/gcc-sm6125.c b/drivers/clk/qcom/gcc-sm6125.c
index 543cfab7561f9..431b55bb0d2f7 100644
--- a/drivers/clk/qcom/gcc-sm6125.c
+++ b/drivers/clk/qcom/gcc-sm6125.c
@@ -1121,7 +1121,7 @@ static struct clk_rcg2 gcc_sdcc1_apps_clk_src = {
.name = "gcc_sdcc1_apps_clk_src",
.parent_data = gcc_parent_data_1,
.num_parents = ARRAY_SIZE(gcc_parent_data_1),
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};

@@ -1143,7 +1143,7 @@ static struct clk_rcg2 gcc_sdcc1_ice_core_clk_src = {
.name = "gcc_sdcc1_ice_core_clk_src",
.parent_data = gcc_parent_data_0,
.num_parents = ARRAY_SIZE(gcc_parent_data_0),
- .ops = &clk_rcg2_floor_ops,
+ .ops = &clk_rcg2_ops,
},
};

--
2.33.0




2021-12-15 17:23:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 07/42] inet: use #ifdef CONFIG_SOCK_RX_QUEUE_MAPPING consistently

From: Eric Dumazet <[email protected]>

[ Upstream commit a9418924552e52e63903cbb0310d7537260702bf ]

Since commit 4e1beecc3b58 ("net/sock: Add kernel config
SOCK_RX_QUEUE_MAPPING"),
sk_rx_queue_mapping access is guarded by CONFIG_SOCK_RX_QUEUE_MAPPING.

Fixes: 54b92e841937 ("tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Kuniyuki Iwashima <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Martin KaFai Lau <[email protected]>
Cc: Tariq Toukan <[email protected]>
Acked-by: Kuniyuki Iwashima <[email protected]>
Reviewed-by: Tariq Toukan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/ipv4/inet_connection_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index f7fea3a7c5e64..62a67fdc344cd 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -721,7 +721,7 @@ static struct request_sock *inet_reqsk_clone(struct request_sock *req,

sk_node_init(&nreq_sk->sk_node);
nreq_sk->sk_tx_queue_mapping = req_sk->sk_tx_queue_mapping;
-#ifdef CONFIG_XPS
+#ifdef CONFIG_SOCK_RX_QUEUE_MAPPING
nreq_sk->sk_rx_queue_mapping = req_sk->sk_rx_queue_mapping;
#endif
nreq_sk->sk_incoming_cpu = req_sk->sk_incoming_cpu;
--
2.33.0




2021-12-15 17:23:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 10/42] perf bpf_skel: Do not use typedef to avoid error on old clang

From: Song Liu <[email protected]>

[ Upstream commit 5a897531e00243cebbcc4dbe4ab06cd559ccf53f ]

When building bpf_skel with clang-10, typedef causes confusions like:

libbpf: map 'prev_readings': unexpected def kind var.

Fix this by removing the typedef.

Fixes: 7fac83aaf2eecc9e ("perf stat: Introduce 'bperf' to share hardware PMCs with BPF")
Reported-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Song Liu <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
tools/perf/util/bpf_skel/bperf.h | 14 --------------
tools/perf/util/bpf_skel/bperf_follower.bpf.c | 16 +++++++++++++---
tools/perf/util/bpf_skel/bperf_leader.bpf.c | 16 +++++++++++++---
3 files changed, 26 insertions(+), 20 deletions(-)
delete mode 100644 tools/perf/util/bpf_skel/bperf.h

diff --git a/tools/perf/util/bpf_skel/bperf.h b/tools/perf/util/bpf_skel/bperf.h
deleted file mode 100644
index 186a5551ddb9d..0000000000000
--- a/tools/perf/util/bpf_skel/bperf.h
+++ /dev/null
@@ -1,14 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-// Copyright (c) 2021 Facebook
-
-#ifndef __BPERF_STAT_H
-#define __BPERF_STAT_H
-
-typedef struct {
- __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
- __uint(key_size, sizeof(__u32));
- __uint(value_size, sizeof(struct bpf_perf_event_value));
- __uint(max_entries, 1);
-} reading_map;
-
-#endif /* __BPERF_STAT_H */
diff --git a/tools/perf/util/bpf_skel/bperf_follower.bpf.c b/tools/perf/util/bpf_skel/bperf_follower.bpf.c
index b8fa3cb2da230..6d2ea67b161ac 100644
--- a/tools/perf/util/bpf_skel/bperf_follower.bpf.c
+++ b/tools/perf/util/bpf_skel/bperf_follower.bpf.c
@@ -4,11 +4,21 @@
#include <linux/perf_event.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
-#include "bperf.h"
#include "bperf_u.h"

-reading_map diff_readings SEC(".maps");
-reading_map accum_readings SEC(".maps");
+struct {
+ __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
+ __uint(key_size, sizeof(__u32));
+ __uint(value_size, sizeof(struct bpf_perf_event_value));
+ __uint(max_entries, 1);
+} diff_readings SEC(".maps");
+
+struct {
+ __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
+ __uint(key_size, sizeof(__u32));
+ __uint(value_size, sizeof(struct bpf_perf_event_value));
+ __uint(max_entries, 1);
+} accum_readings SEC(".maps");

struct {
__uint(type, BPF_MAP_TYPE_HASH);
diff --git a/tools/perf/util/bpf_skel/bperf_leader.bpf.c b/tools/perf/util/bpf_skel/bperf_leader.bpf.c
index 4f70d1459e86c..d82e1633a2e0a 100644
--- a/tools/perf/util/bpf_skel/bperf_leader.bpf.c
+++ b/tools/perf/util/bpf_skel/bperf_leader.bpf.c
@@ -4,7 +4,6 @@
#include <linux/perf_event.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
-#include "bperf.h"

struct {
__uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
@@ -13,8 +12,19 @@ struct {
__uint(map_flags, BPF_F_PRESERVE_ELEMS);
} events SEC(".maps");

-reading_map prev_readings SEC(".maps");
-reading_map diff_readings SEC(".maps");
+struct {
+ __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
+ __uint(key_size, sizeof(__u32));
+ __uint(value_size, sizeof(struct bpf_perf_event_value));
+ __uint(max_entries, 1);
+} prev_readings SEC(".maps");
+
+struct {
+ __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
+ __uint(key_size, sizeof(__u32));
+ __uint(value_size, sizeof(struct bpf_perf_event_value));
+ __uint(max_entries, 1);
+} diff_readings SEC(".maps");

SEC("raw_tp/sched_switch")
int BPF_PROG(on_switch)
--
2.33.0




2021-12-15 17:23:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 01/42] nfc: fix segfault in nfc_genl_dump_devices_done

From: Tadeusz Struk <[email protected]>

commit fd79a0cbf0b2e34bcc45b13acf962e2032a82203 upstream.

When kmalloc in nfc_genl_dump_devices() fails then
nfc_genl_dump_devices_done() segfaults as below

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014
Workqueue: events netlink_sock_destruct_work
RIP: 0010:klist_iter_exit+0x26/0x80
Call Trace:
<TASK>
class_dev_iter_exit+0x15/0x20
nfc_genl_dump_devices_done+0x3b/0x50
genl_lock_done+0x84/0xd0
netlink_sock_destruct+0x8f/0x270
__sk_destruct+0x64/0x3b0
sk_destruct+0xa8/0xd0
__sk_free+0x2e8/0x3d0
sk_free+0x51/0x90
netlink_sock_destruct_work+0x1c/0x20
process_one_work+0x411/0x710
worker_thread+0x6fd/0xa80

Link: https://syzkaller.appspot.com/bug?id=fc0fa5a53db9edd261d56e74325419faf18bd0df
Reported-by: [email protected]
Signed-off-by: Tadeusz Struk <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/nfc/netlink.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -636,8 +636,10 @@ static int nfc_genl_dump_devices_done(st
{
struct class_dev_iter *iter = (struct class_dev_iter *) cb->args[0];

- nfc_device_iter_exit(iter);
- kfree(iter);
+ if (iter) {
+ nfc_device_iter_exit(iter);
+ kfree(iter);
+ }

return 0;
}



2021-12-15 17:23:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 17/42] vmxnet3: fix minimum vectors alloc issue

From: Ronak Doshi <[email protected]>

[ Upstream commit f71ef02f1a4a3c49962fa341ad8de19071f0f9bf ]

'Commit 39f9895a00f4 ("vmxnet3: add support for 32 Tx/Rx queues")'
added support for 32Tx/Rx queues. Within that patch, value of
VMXNET3_LINUX_MIN_MSIX_VECT was updated.

However, there is a case (numvcpus = 2) which actually requires 3
intrs which matches VMXNET3_LINUX_MIN_MSIX_VECT which then is
treated as failure by stack to allocate more vectors. This patch
fixes this issue.

Fixes: 39f9895a00f4 ("vmxnet3: add support for 32 Tx/Rx queues")
Signed-off-by: Ronak Doshi <[email protected]>
Acked-by: Guolin Yang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 8799854bacb29..5b0215b7c1761 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -3261,7 +3261,7 @@ vmxnet3_alloc_intr_resources(struct vmxnet3_adapter *adapter)

#ifdef CONFIG_PCI_MSI
if (adapter->intr.type == VMXNET3_IT_MSIX) {
- int i, nvec;
+ int i, nvec, nvec_allocated;

nvec = adapter->share_intr == VMXNET3_INTR_TXSHARE ?
1 : adapter->num_tx_queues;
@@ -3274,14 +3274,15 @@ vmxnet3_alloc_intr_resources(struct vmxnet3_adapter *adapter)
for (i = 0; i < nvec; i++)
adapter->intr.msix_entries[i].entry = i;

- nvec = vmxnet3_acquire_msix_vectors(adapter, nvec);
- if (nvec < 0)
+ nvec_allocated = vmxnet3_acquire_msix_vectors(adapter, nvec);
+ if (nvec_allocated < 0)
goto msix_err;

/* If we cannot allocate one MSIx vector per queue
* then limit the number of rx queues to 1
*/
- if (nvec == VMXNET3_LINUX_MIN_MSIX_VECT) {
+ if (nvec_allocated == VMXNET3_LINUX_MIN_MSIX_VECT &&
+ nvec != VMXNET3_LINUX_MIN_MSIX_VECT) {
if (adapter->share_intr != VMXNET3_INTR_BUDDYSHARE
|| adapter->num_rx_queues != 1) {
adapter->share_intr = VMXNET3_INTR_TXSHARE;
@@ -3291,14 +3292,14 @@ vmxnet3_alloc_intr_resources(struct vmxnet3_adapter *adapter)
}
}

- adapter->intr.num_intrs = nvec;
+ adapter->intr.num_intrs = nvec_allocated;
return;

msix_err:
/* If we cannot allocate MSIx vectors use only one rx queue */
dev_info(&adapter->pdev->dev,
"Failed to enable MSI-X, error %d. "
- "Limiting #rx queues to 1, try MSI.\n", nvec);
+ "Limiting #rx queues to 1, try MSI.\n", nvec_allocated);

adapter->intr.type = VMXNET3_IT_MSI;
}
--
2.33.0




2021-12-15 17:23:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 26/42] net/mlx4_en: Update reported link modes for 1/10G

From: Erik Ekman <[email protected]>

[ Upstream commit 2191b1dfef7d45f44b5008d2148676d9f2c82874 ]

When link modes were initially added in commit 2c762679435dc
("net/mlx4_en: Use PTYS register to query ethtool settings") and
later updated for the new ethtool API in commit 3d8f7cc78d0eb
("net: mlx4: use new ETHTOOL_G/SSETTINGS API") the only 1/10G non-baseT
link modes configured were 1000baseKX, 10000baseKX4 and 10000baseKR.
It looks like these got picked to represent other modes since nothing
better was available.

Switch to using more specific link modes added in commit 5711a98221443
("net: ethtool: add support for 1000BaseX and missing 10G link modes").

Tested with MCX311A-XCAT connected via DAC.
Before:

% sudo ethtool enp3s0
Settings for enp3s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseKX/Full
10000baseKR/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: 1000baseKX/Full
10000baseKR/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: off
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000014 (20)
link ifdown
Link detected: yes

With this change:

% sudo ethtool enp3s0
Settings for enp3s0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: 1000baseX/Full
10000baseCR/Full
10000baseSR/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: off
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000014 (20)
link ifdown
Link detected: yes

Tested-by: Michael Stapelberg <[email protected]>
Signed-off-by: Erik Ekman <[email protected]>
Reviewed-by: Tariq Toukan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index ef518b1040f72..fde521b1eecad 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -663,7 +663,7 @@ void __init mlx4_en_init_ptys2ethtool_map(void)
MLX4_BUILD_PTYS2ETHTOOL_CONFIG(MLX4_1000BASE_T, SPEED_1000,
ETHTOOL_LINK_MODE_1000baseT_Full_BIT);
MLX4_BUILD_PTYS2ETHTOOL_CONFIG(MLX4_1000BASE_CX_SGMII, SPEED_1000,
- ETHTOOL_LINK_MODE_1000baseKX_Full_BIT);
+ ETHTOOL_LINK_MODE_1000baseX_Full_BIT);
MLX4_BUILD_PTYS2ETHTOOL_CONFIG(MLX4_1000BASE_KX, SPEED_1000,
ETHTOOL_LINK_MODE_1000baseKX_Full_BIT);
MLX4_BUILD_PTYS2ETHTOOL_CONFIG(MLX4_10GBASE_T, SPEED_10000,
@@ -675,9 +675,9 @@ void __init mlx4_en_init_ptys2ethtool_map(void)
MLX4_BUILD_PTYS2ETHTOOL_CONFIG(MLX4_10GBASE_KR, SPEED_10000,
ETHTOOL_LINK_MODE_10000baseKR_Full_BIT);
MLX4_BUILD_PTYS2ETHTOOL_CONFIG(MLX4_10GBASE_CR, SPEED_10000,
- ETHTOOL_LINK_MODE_10000baseKR_Full_BIT);
+ ETHTOOL_LINK_MODE_10000baseCR_Full_BIT);
MLX4_BUILD_PTYS2ETHTOOL_CONFIG(MLX4_10GBASE_SR, SPEED_10000,
- ETHTOOL_LINK_MODE_10000baseKR_Full_BIT);
+ ETHTOOL_LINK_MODE_10000baseSR_Full_BIT);
MLX4_BUILD_PTYS2ETHTOOL_CONFIG(MLX4_20GBASE_KR2, SPEED_20000,
ETHTOOL_LINK_MODE_20000baseMLD2_Full_BIT,
ETHTOOL_LINK_MODE_20000baseKR2_Full_BIT);
--
2.33.0




2021-12-15 17:23:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 27/42] loop: Use pr_warn_once() for loop_control_remove() warning

From: Tetsuo Handa <[email protected]>

[ Upstream commit e3f9387aea67742b9d1f4de8e5bb2fd08a8a4584 ]

kernel test robot reported that RCU stall via printk() flooding is
possible [1] when stress testing.

Link: https://lkml.kernel.org/r/20211129073709.GA18483@xsang-OptiPlex-9020 [1]
Reported-by: kernel test robot <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Tetsuo Handa <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/block/loop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index dfc72a1f6500d..c00ae30fde89e 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -2429,7 +2429,7 @@ static int loop_control_remove(int idx)
int ret;

if (idx < 0) {
- pr_warn("deleting an unspecified loop device is not supported.\n");
+ pr_warn_once("deleting an unspecified loop device is not supported.\n");
return -EINVAL;
}

--
2.33.0




2021-12-15 17:23:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 28/42] ALSA: hda: Add Intel DG2 PCI ID and HDMI codec vid

From: Kai Vehmanen <[email protected]>

[ Upstream commit d85ffff5302b1509efc482e8877c253b0a668b33 ]

Add HD Audio PCI ID and HDMI codec vendor ID for Intel DG2.

Reviewed-by: Uma Shankar <[email protected]>
Signed-off-by: Kai Vehmanen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
sound/pci/hda/hda_intel.c | 12 +++++++++++-
sound/pci/hda/patch_hdmi.c | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 90e9263ac0bd7..21fec82489bd7 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -335,7 +335,10 @@ enum {
((pci)->device == 0x0c0c) || \
((pci)->device == 0x0d0c) || \
((pci)->device == 0x160c) || \
- ((pci)->device == 0x490d))
+ ((pci)->device == 0x490d) || \
+ ((pci)->device == 0x4f90) || \
+ ((pci)->device == 0x4f91) || \
+ ((pci)->device == 0x4f92))

#define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98)

@@ -2472,6 +2475,13 @@ static const struct pci_device_id azx_ids[] = {
/* DG1 */
{ PCI_DEVICE(0x8086, 0x490d),
.driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE},
+ /* DG2 */
+ { PCI_DEVICE(0x8086, 0x4f90),
+ .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE},
+ { PCI_DEVICE(0x8086, 0x4f91),
+ .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE},
+ { PCI_DEVICE(0x8086, 0x4f92),
+ .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE},
/* Alderlake-S */
{ PCI_DEVICE(0x8086, 0x7ad0),
.driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE},
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 65d2c55399195..98633d2684deb 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -4382,6 +4382,7 @@ HDA_CODEC_ENTRY(0x80862814, "DG1 HDMI", patch_i915_tgl_hdmi),
HDA_CODEC_ENTRY(0x80862815, "Alderlake HDMI", patch_i915_tgl_hdmi),
HDA_CODEC_ENTRY(0x8086281c, "Alderlake-P HDMI", patch_i915_tgl_hdmi),
HDA_CODEC_ENTRY(0x80862816, "Rocketlake HDMI", patch_i915_tgl_hdmi),
+HDA_CODEC_ENTRY(0x80862819, "DG2 HDMI", patch_i915_tgl_hdmi),
HDA_CODEC_ENTRY(0x8086281a, "Jasperlake HDMI", patch_i915_icl_hdmi),
HDA_CODEC_ENTRY(0x8086281b, "Elkhartlake HDMI", patch_i915_icl_hdmi),
HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI", patch_generic_hdmi),
--
2.33.0




2021-12-15 17:24:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 29/42] ALSA: hda/hdmi: fix HDA codec entry table order for ADL-P

From: Kai Vehmanen <[email protected]>

[ Upstream commit 289047db1143c42c81820352f195a393ff639a52 ]

Keep the HDA_CODEC_ENTRY entries sorted by the codec VID. ADL-P
is the only misplaced Intel HDMI codec.

Signed-off-by: Kai Vehmanen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
sound/pci/hda/patch_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 98633d2684deb..415701bd10ac8 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -4380,11 +4380,11 @@ HDA_CODEC_ENTRY(0x8086280f, "Icelake HDMI", patch_i915_icl_hdmi),
HDA_CODEC_ENTRY(0x80862812, "Tigerlake HDMI", patch_i915_tgl_hdmi),
HDA_CODEC_ENTRY(0x80862814, "DG1 HDMI", patch_i915_tgl_hdmi),
HDA_CODEC_ENTRY(0x80862815, "Alderlake HDMI", patch_i915_tgl_hdmi),
-HDA_CODEC_ENTRY(0x8086281c, "Alderlake-P HDMI", patch_i915_tgl_hdmi),
HDA_CODEC_ENTRY(0x80862816, "Rocketlake HDMI", patch_i915_tgl_hdmi),
HDA_CODEC_ENTRY(0x80862819, "DG2 HDMI", patch_i915_tgl_hdmi),
HDA_CODEC_ENTRY(0x8086281a, "Jasperlake HDMI", patch_i915_icl_hdmi),
HDA_CODEC_ENTRY(0x8086281b, "Elkhartlake HDMI", patch_i915_icl_hdmi),
+HDA_CODEC_ENTRY(0x8086281c, "Alderlake-P HDMI", patch_i915_tgl_hdmi),
HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI", patch_generic_hdmi),
HDA_CODEC_ENTRY(0x80862882, "Valleyview2 HDMI", patch_i915_byt_hdmi),
HDA_CODEC_ENTRY(0x80862883, "Braswell HDMI", patch_i915_byt_hdmi),
--
2.33.0




2021-12-15 17:24:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 30/42] parisc/agp: Annotate parisc agp init functions with __init

From: Helge Deller <[email protected]>

[ Upstream commit 8d88382b7436551a9ebb78475c546b670790cbf6 ]

Signed-off-by: Helge Deller <[email protected]>
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/char/agp/parisc-agp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/agp/parisc-agp.c b/drivers/char/agp/parisc-agp.c
index ed3c4c42fc23b..d68d05d5d3838 100644
--- a/drivers/char/agp/parisc-agp.c
+++ b/drivers/char/agp/parisc-agp.c
@@ -281,7 +281,7 @@ agp_ioc_init(void __iomem *ioc_regs)
return 0;
}

-static int
+static int __init
lba_find_capability(int cap)
{
struct _parisc_agp_info *info = &parisc_agp_info;
@@ -366,7 +366,7 @@ parisc_agp_setup(void __iomem *ioc_hpa, void __iomem *lba_hpa)
return error;
}

-static int
+static int __init
find_quicksilver(struct device *dev, void *data)
{
struct parisc_device **lba = data;
@@ -378,7 +378,7 @@ find_quicksilver(struct device *dev, void *data)
return 0;
}

-static int
+static int __init
parisc_agp_init(void)
{
extern struct sba_device *sba_list;
--
2.33.0




2021-12-15 17:24:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 35/42] drm/amd/display: Fix for the no Audio bug with Tiled Displays

From: Mustapha Ghaddar <[email protected]>

[ Upstream commit 5ceaebcda9061c04f439c93961f0819878365c0f ]

[WHY]
It seems like after a series of plug/unplugs we end up in a situation
where tiled display doesnt support Audio.

[HOW]
The issue seems to be related to when we check streams changed after an
HPD, we should be checking the audio_struct as well to see if any of its
values changed.

Reviewed-by: Jun Lei <[email protected]>
Acked-by: Bhawanpreet Lakha <[email protected]>
Signed-off-by: Mustapha Ghaddar <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index a60396d5be445..e94546187cf15 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1623,6 +1623,10 @@ bool dc_is_stream_unchanged(
if (old_stream->ignore_msa_timing_param != stream->ignore_msa_timing_param)
return false;

+ // Only Have Audio left to check whether it is same or not. This is a corner case for Tiled sinks
+ if (old_stream->audio_info.mode_count != stream->audio_info.mode_count)
+ return false;
+
return true;
}

--
2.33.0




2021-12-15 17:24:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 18/42] i2c: virtio: fix completion handling

From: Vincent Whitchurch <[email protected]>

[ Upstream commit b503de239f62eca898cfb7e820d9a35499137d22 ]

The driver currently assumes that the notify callback is only received
when the device is done with all the queued buffers.

However, this is not true, since the notify callback could be called
without any of the queued buffers being completed (for example, with
virtio-pci and shared interrupts) or with only some of the buffers being
completed (since the driver makes them available to the device in
multiple separate virtqueue_add_sgs() calls).

This can lead to incorrect data on the I2C bus or memory corruption in
the guest if the device operates on buffers which are have been freed by
the driver. (The WARN_ON in the driver is also triggered.)

BUG kmalloc-128 (Tainted: G W ): Poison overwritten
First byte 0x0 instead of 0x6b
Allocated in i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28
memdup_user+0x2e/0xbd
i2cdev_ioctl_rdwr+0x9d/0x1de
i2cdev_ioctl+0x247/0x2ed
vfs_ioctl+0x21/0x30
sys_ioctl+0xb18/0xb41
Freed in i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28
kfree+0x1bd/0x1cc
i2cdev_ioctl_rdwr+0x1bb/0x1de
i2cdev_ioctl+0x247/0x2ed
vfs_ioctl+0x21/0x30
sys_ioctl+0xb18/0xb41

Fix this by calling virtio_get_buf() from the notify handler like other
virtio drivers and by actually waiting for all the buffers to be
completed.

Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend driver")
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Vincent Whitchurch <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/i2c/busses/i2c-virtio.c | 32 ++++++++++++--------------------
1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
index 7b2474e6876f4..5cb21d7da05b6 100644
--- a/drivers/i2c/busses/i2c-virtio.c
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -22,24 +22,24 @@
/**
* struct virtio_i2c - virtio I2C data
* @vdev: virtio device for this controller
- * @completion: completion of virtio I2C message
* @adap: I2C adapter for this controller
* @vq: the virtio virtqueue for communication
*/
struct virtio_i2c {
struct virtio_device *vdev;
- struct completion completion;
struct i2c_adapter adap;
struct virtqueue *vq;
};

/**
* struct virtio_i2c_req - the virtio I2C request structure
+ * @completion: completion of virtio I2C message
* @out_hdr: the OUT header of the virtio I2C message
* @buf: the buffer into which data is read, or from which it's written
* @in_hdr: the IN header of the virtio I2C message
*/
struct virtio_i2c_req {
+ struct completion completion;
struct virtio_i2c_out_hdr out_hdr ____cacheline_aligned;
uint8_t *buf ____cacheline_aligned;
struct virtio_i2c_in_hdr in_hdr ____cacheline_aligned;
@@ -47,9 +47,11 @@ struct virtio_i2c_req {

static void virtio_i2c_msg_done(struct virtqueue *vq)
{
- struct virtio_i2c *vi = vq->vdev->priv;
+ struct virtio_i2c_req *req;
+ unsigned int len;

- complete(&vi->completion);
+ while ((req = virtqueue_get_buf(vq, &len)))
+ complete(&req->completion);
}

static int virtio_i2c_prepare_reqs(struct virtqueue *vq,
@@ -62,6 +64,8 @@ static int virtio_i2c_prepare_reqs(struct virtqueue *vq,
for (i = 0; i < num; i++) {
int outcnt = 0, incnt = 0;

+ init_completion(&reqs[i].completion);
+
/*
* We don't support 0 length messages and so filter out
* 0 length transfers by using i2c_adapter_quirks.
@@ -108,21 +112,15 @@ static int virtio_i2c_complete_reqs(struct virtqueue *vq,
struct virtio_i2c_req *reqs,
struct i2c_msg *msgs, int num)
{
- struct virtio_i2c_req *req;
bool failed = false;
- unsigned int len;
int i, j = 0;

for (i = 0; i < num; i++) {
- /* Detach the ith request from the vq */
- req = virtqueue_get_buf(vq, &len);
+ struct virtio_i2c_req *req = &reqs[i];

- /*
- * Condition req == &reqs[i] should always meet since we have
- * total num requests in the vq. reqs[i] can never be NULL here.
- */
- if (!failed && (WARN_ON(req != &reqs[i]) ||
- req->in_hdr.status != VIRTIO_I2C_MSG_OK))
+ wait_for_completion(&req->completion);
+
+ if (!failed && req->in_hdr.status != VIRTIO_I2C_MSG_OK)
failed = true;

i2c_put_dma_safe_msg_buf(reqs[i].buf, &msgs[i], !failed);
@@ -158,12 +156,8 @@ static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
* remote here to clear the virtqueue, so we can try another set of
* messages later on.
*/
-
- reinit_completion(&vi->completion);
virtqueue_kick(vq);

- wait_for_completion(&vi->completion);
-
count = virtio_i2c_complete_reqs(vq, reqs, msgs, count);

err_free:
@@ -211,8 +205,6 @@ static int virtio_i2c_probe(struct virtio_device *vdev)
vdev->priv = vi;
vi->vdev = vdev;

- init_completion(&vi->completion);
-
ret = virtio_i2c_setup_vqs(vi);
if (ret)
return ret;
--
2.33.0




2021-12-15 17:24:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 36/42] drm/amdkfd: fix double free mem structure

From: Philip Yang <[email protected]>

[ Upstream commit 494f2e42ce4a9ddffb5d8c5b2db816425ef90397 ]

drm_gem_object_put calls release_notify callback to free the mem
structure and unreserve_mem_limit, move it down after the last access
of mem and make it conditional call.

Signed-off-by: Philip Yang <[email protected]>
Reviewed-by: Felix Kuehling <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index cdf46bd0d8d5b..ab36cce59d2e4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1393,7 +1393,7 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
struct sg_table *sg = NULL;
uint64_t user_addr = 0;
struct amdgpu_bo *bo;
- struct drm_gem_object *gobj;
+ struct drm_gem_object *gobj = NULL;
u32 domain, alloc_domain;
u64 alloc_flags;
int ret;
@@ -1503,14 +1503,16 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
drm_vma_node_revoke(&gobj->vma_node, drm_priv);
err_node_allow:
- drm_gem_object_put(gobj);
/* Don't unreserve system mem limit twice */
goto err_reserve_limit;
err_bo_create:
unreserve_mem_limit(adev, size, alloc_domain, !!sg);
err_reserve_limit:
mutex_destroy(&(*mem)->lock);
- kfree(*mem);
+ if (gobj)
+ drm_gem_object_put(gobj);
+ else
+ kfree(*mem);
err:
if (sg) {
sg_free_table(sg);
--
2.33.0




2021-12-15 17:24:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 32/42] net: netlink: af_netlink: Prevent empty skb by adding a check on len.

From: Harshit Mogalapalli <[email protected]>

[ Upstream commit f123cffdd8fe8ea6c7fded4b88516a42798797d0 ]

Adding a check on len parameter to avoid empty skb. This prevents a
division error in netem_enqueue function which is caused when skb->len=0
and skb->data_len=0 in the randomized corruption step as shown below.

skb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8);

Crash Report:
[ 343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family
0 port 6081 - 0
[ 343.216110] netem: version 1.3
[ 343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
[ 343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+
[ 343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.11.0-2.el7 04/01/2014
[ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem]
[ 343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff
ff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f
74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03
[ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246
[ 343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:
0000000000000000
[ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:
ffff88800f8eda40
[ 343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:
ffffffff94fb8445
[ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:
0000000000000000
[ 343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:
0000000000000020
[ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000)
knlGS:0000000000000000
[ 343.248350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:
00000000000006e0
[ 343.250076] Call Trace:
[ 343.250423] <TASK>
[ 343.250713] ? memcpy+0x4d/0x60
[ 343.251162] ? netem_init+0xa0/0xa0 [sch_netem]
[ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem]
[ 343.253102] ? stack_trace_save+0x87/0xb0
[ 343.253655] ? filter_irq_stacks+0xb0/0xb0
[ 343.254220] ? netem_init+0xa0/0xa0 [sch_netem]
[ 343.254837] ? __kasan_check_write+0x14/0x20
[ 343.255418] ? _raw_spin_lock+0x88/0xd6
[ 343.255953] dev_qdisc_enqueue+0x50/0x180
[ 343.256508] __dev_queue_xmit+0x1a7e/0x3090
[ 343.257083] ? netdev_core_pick_tx+0x300/0x300
[ 343.257690] ? check_kcov_mode+0x10/0x40
[ 343.258219] ? _raw_spin_unlock_irqrestore+0x29/0x40
[ 343.258899] ? __kasan_init_slab_obj+0x24/0x30
[ 343.259529] ? setup_object.isra.71+0x23/0x90
[ 343.260121] ? new_slab+0x26e/0x4b0
[ 343.260609] ? kasan_poison+0x3a/0x50
[ 343.261118] ? kasan_unpoison+0x28/0x50
[ 343.261637] ? __kasan_slab_alloc+0x71/0x90
[ 343.262214] ? memcpy+0x4d/0x60
[ 343.262674] ? write_comp_data+0x2f/0x90
[ 343.263209] ? __kasan_check_write+0x14/0x20
[ 343.263802] ? __skb_clone+0x5d6/0x840
[ 343.264329] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.264958] dev_queue_xmit+0x1c/0x20
[ 343.265470] netlink_deliver_tap+0x652/0x9c0
[ 343.266067] netlink_unicast+0x5a0/0x7f0
[ 343.266608] ? netlink_attachskb+0x860/0x860
[ 343.267183] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.267820] ? write_comp_data+0x2f/0x90
[ 343.268367] netlink_sendmsg+0x922/0xe80
[ 343.268899] ? netlink_unicast+0x7f0/0x7f0
[ 343.269472] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.270099] ? write_comp_data+0x2f/0x90
[ 343.270644] ? netlink_unicast+0x7f0/0x7f0
[ 343.271210] sock_sendmsg+0x155/0x190
[ 343.271721] ____sys_sendmsg+0x75f/0x8f0
[ 343.272262] ? kernel_sendmsg+0x60/0x60
[ 343.272788] ? write_comp_data+0x2f/0x90
[ 343.273332] ? write_comp_data+0x2f/0x90
[ 343.273869] ___sys_sendmsg+0x10f/0x190
[ 343.274405] ? sendmsg_copy_msghdr+0x80/0x80
[ 343.274984] ? slab_post_alloc_hook+0x70/0x230
[ 343.275597] ? futex_wait_setup+0x240/0x240
[ 343.276175] ? security_file_alloc+0x3e/0x170
[ 343.276779] ? write_comp_data+0x2f/0x90
[ 343.277313] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.277969] ? write_comp_data+0x2f/0x90
[ 343.278515] ? __fget_files+0x1ad/0x260
[ 343.279048] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.279685] ? write_comp_data+0x2f/0x90
[ 343.280234] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.280874] ? sockfd_lookup_light+0xd1/0x190
[ 343.281481] __sys_sendmsg+0x118/0x200
[ 343.281998] ? __sys_sendmsg_sock+0x40/0x40
[ 343.282578] ? alloc_fd+0x229/0x5e0
[ 343.283070] ? write_comp_data+0x2f/0x90
[ 343.283610] ? write_comp_data+0x2f/0x90
[ 343.284135] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.284776] ? ktime_get_coarse_real_ts64+0xb8/0xf0
[ 343.285450] __x64_sys_sendmsg+0x7d/0xc0
[ 343.285981] ? syscall_enter_from_user_mode+0x4d/0x70
[ 343.286664] do_syscall_64+0x3a/0x80
[ 343.287158] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 343.287850] RIP: 0033:0x7fdde24cf289
[ 343.288344] Code: 01 00 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 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 8b 0d b7 db 2c 00 f7 d8 64 89 01 48
[ 343.290729] RSP: 002b:00007fdde2bd6d98 EFLAGS: 00000246 ORIG_RAX:
000000000000002e
[ 343.291730] RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
00007fdde24cf289
[ 343.292673] RDX: 0000000000000000 RSI: 00000000200000c0 RDI:
0000000000000004
[ 343.293618] RBP: 00007fdde2bd6e20 R08: 0000000100000001 R09:
0000000000000000
[ 343.294557] R10: 0000000100000001 R11: 0000000000000246 R12:
0000000000000000
[ 343.295493] R13: 0000000000021000 R14: 0000000000000000 R15:
00007fdde2bd7700
[ 343.296432] </TASK>
[ 343.296735] Modules linked in: sch_netem ip6_vti ip_vti ip_gre ipip
sit ip_tunnel geneve macsec macvtap tap ipvlan macvlan 8021q garp mrp
hsr wireguard libchacha20poly1305 chacha_x86_64 poly1305_x86_64
ip6_udp_tunnel udp_tunnel libblake2s blake2s_x86_64 libblake2s_generic
curve25519_x86_64 libcurve25519_generic libchacha xfrm_interface
xfrm6_tunnel tunnel4 veth netdevsim psample batman_adv nlmon dummy team
bonding tls vcan ip6_gre ip6_tunnel tunnel6 gre tun ip6t_rpfilter
ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set
ebtable_nat ebtable_broute ip6table_nat ip6table_mangle
ip6table_security ip6table_raw iptable_nat nf_nat nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_security
iptable_raw ebtable_filter ebtables rfkill ip6table_filter ip6_tables
iptable_filter ppdev bochs drm_vram_helper drm_ttm_helper ttm
drm_kms_helper cec parport_pc drm joydev floppy parport sg syscopyarea
sysfillrect sysimgblt i2c_piix4 qemu_fw_cfg fb_sys_fops pcspkr
[ 343.297459] ip_tables xfs virtio_net net_failover failover sd_mod
sr_mod cdrom t10_pi ata_generic pata_acpi ata_piix libata virtio_pci
virtio_pci_legacy_dev serio_raw virtio_pci_modern_dev dm_mirror
dm_region_hash dm_log dm_mod
[ 343.311074] Dumping ftrace buffer:
[ 343.311532] (ftrace buffer empty)
[ 343.312040] ---[ end trace a2e3db5a6ae05099 ]---
[ 343.312691] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem]
[ 343.313481] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff
ff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f
74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03
[ 343.315893] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246
[ 343.316622] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:
0000000000000000
[ 343.317585] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:
ffff88800f8eda40
[ 343.318549] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:
ffffffff94fb8445
[ 343.319503] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:
0000000000000000
[ 343.320455] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:
0000000000000020
[ 343.321414] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000)
knlGS:0000000000000000
[ 343.322489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 343.323283] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:
00000000000006e0
[ 343.324264] Kernel panic - not syncing: Fatal exception in interrupt
[ 343.333717] Dumping ftrace buffer:
[ 343.334175] (ftrace buffer empty)
[ 343.334653] Kernel Offset: 0x13600000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 343.336027] Rebooting in 86400 seconds..

Reported-by: syzkaller <[email protected]>
Signed-off-by: Harshit Mogalapalli <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/netlink/af_netlink.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index ada47e59647a0..81ba8e51e01ff 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1871,6 +1871,11 @@ static int netlink_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
if (msg->msg_flags & MSG_OOB)
return -EOPNOTSUPP;

+ if (len == 0) {
+ pr_warn_once("Zero length message leads to an empty skb\n");
+ return -ENODATA;
+ }
+
err = scm_send(sock, msg, &scm, true);
if (err < 0)
return err;
--
2.33.0




2021-12-15 17:24:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 31/42] i2c: rk3x: Handle a spurious start completion interrupt flag

From: Ondrej Jirman <[email protected]>

[ Upstream commit 02fe0fbd8a21e183687925c3a266ae27dda9840f ]

In a typical read transfer, start completion flag is being set after
read finishes (notice ipd bit 4 being set):

trasnfer poll=0
i2c start
rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10
i2c read
rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b
i2c stop
rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 33

This causes I2C transfer being aborted in polled mode from a stop completion
handler:

trasnfer poll=1
i2c start
rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10
i2c read
rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 0
rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b
i2c stop
rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 13
i2c stop
rk3x-i2c fdd40000.i2c: unexpected irq in STOP: 0x10

Clearing the START flag after read fixes the issue without any obvious
side effects.

This issue was dicovered on RK3566 when adding support for powering
off the RK817 PMIC.

Signed-off-by: Ondrej Jirman <[email protected]>
Reviewed-by: John Keeping <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/i2c/busses/i2c-rk3x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 819ab4ee517e1..02ddb237f69af 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -423,8 +423,8 @@ static void rk3x_i2c_handle_read(struct rk3x_i2c *i2c, unsigned int ipd)
if (!(ipd & REG_INT_MBRF))
return;

- /* ack interrupt */
- i2c_writel(i2c, REG_INT_MBRF, REG_IPD);
+ /* ack interrupt (read also produces a spurious START flag, clear it too) */
+ i2c_writel(i2c, REG_INT_MBRF | REG_INT_START, REG_IPD);

/* Can only handle a maximum of 32 bytes at a time */
if (len > 32)
--
2.33.0




2021-12-15 17:24:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 33/42] drm/amdgpu: cancel the correct hrtimer on exit

From: Flora Cui <[email protected]>

[ Upstream commit 3e467e478ed3a9701bb588d648d6e0ccb82ced09 ]

Signed-off-by: Flora Cui <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index ce982afeff913..ac9a8cd21c4b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -504,8 +504,8 @@ static int amdgpu_vkms_sw_fini(void *handle)
int i = 0;

for (i = 0; i < adev->mode_info.num_crtc; i++)
- if (adev->mode_info.crtcs[i])
- hrtimer_cancel(&adev->mode_info.crtcs[i]->vblank_timer);
+ if (adev->amdgpu_vkms_output[i].vblank_hrtimer.function)
+ hrtimer_cancel(&adev->amdgpu_vkms_output[i].vblank_hrtimer);

kfree(adev->mode_info.bios_hardcoded_edid);
kfree(adev->amdgpu_vkms_output);
--
2.33.0




2021-12-15 17:24:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 38/42] drm/amdkfd: process_info lock not needed for svm

From: Philip Yang <[email protected]>

[ Upstream commit 3abfe30d803e62cc75dec254eefab3b04d69219b ]

process_info->lock is used to protect kfd_bo_list, vm_list_head, n_vms
and userptr valid/inval list, svm_range_restore_work and
svm_range_set_attr don't access those, so do not need to take
process_info lock. This will avoid potential circular locking issue.

Signed-off-by: Philip Yang <[email protected]>
Reviewed-by: Felix Kuehling <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 9 ---------
1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 179080329af89..5a674235ae41a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1565,7 +1565,6 @@ svm_range_list_lock_and_flush_work(struct svm_range_list *svms,
static void svm_range_restore_work(struct work_struct *work)
{
struct delayed_work *dwork = to_delayed_work(work);
- struct amdkfd_process_info *process_info;
struct svm_range_list *svms;
struct svm_range *prange;
struct kfd_process *p;
@@ -1585,12 +1584,10 @@ static void svm_range_restore_work(struct work_struct *work)
* the lifetime of this thread, kfd_process and mm will be valid.
*/
p = container_of(svms, struct kfd_process, svms);
- process_info = p->kgd_process_info;
mm = p->mm;
if (!mm)
return;

- mutex_lock(&process_info->lock);
svm_range_list_lock_and_flush_work(svms, mm);
mutex_lock(&svms->lock);

@@ -1643,7 +1640,6 @@ static void svm_range_restore_work(struct work_struct *work)
out_reschedule:
mutex_unlock(&svms->lock);
mmap_write_unlock(mm);
- mutex_unlock(&process_info->lock);

/* If validation failed, reschedule another attempt */
if (evicted_ranges) {
@@ -2974,7 +2970,6 @@ static int
svm_range_set_attr(struct kfd_process *p, uint64_t start, uint64_t size,
uint32_t nattr, struct kfd_ioctl_svm_attribute *attrs)
{
- struct amdkfd_process_info *process_info = p->kgd_process_info;
struct mm_struct *mm = current->mm;
struct list_head update_list;
struct list_head insert_list;
@@ -2993,8 +2988,6 @@ svm_range_set_attr(struct kfd_process *p, uint64_t start, uint64_t size,

svms = &p->svms;

- mutex_lock(&process_info->lock);
-
svm_range_list_lock_and_flush_work(svms, mm);

if (!svm_range_is_valid(mm, start, size)) {
@@ -3070,8 +3063,6 @@ svm_range_set_attr(struct kfd_process *p, uint64_t start, uint64_t size,
mutex_unlock(&svms->lock);
mmap_read_unlock(mm);
out:
- mutex_unlock(&process_info->lock);
-
pr_debug("pasid 0x%x svms 0x%p [0x%llx 0x%llx] done, r=%d\n", p->pasid,
&p->svms, start, start + size - 1, r);

--
2.33.0




2021-12-15 17:24:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 34/42] drm/amdgpu: check atomic flag to differeniate with legacy path

From: Flora Cui <[email protected]>

[ Upstream commit 1053b9c948e614473819a1a5bcaff6d44e680dcf ]

since vkms support atomic KMS interface

Signed-off-by: Flora Cui <[email protected]>
Reviewed-by: Guchun Chen <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 96ca42bcfdbf9..1545884dc703e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3854,7 +3854,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
/* disable all interrupts */
amdgpu_irq_disable_all(adev);
if (adev->mode_info.mode_config_initialized){
- if (!amdgpu_device_has_dc_support(adev))
+ if (!drm_drv_uses_atomic_modeset(adev_to_drm(adev)))
drm_helper_force_disable_all(adev_to_drm(adev));
else
drm_atomic_helper_shutdown(adev_to_drm(adev));
@@ -5130,7 +5130,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
drm_sched_start(&ring->sched, !tmp_adev->asic_reset_res);
}

- if (!amdgpu_device_has_dc_support(tmp_adev) && !job_signaled) {
+ if (!drm_drv_uses_atomic_modeset(adev_to_drm(tmp_adev)) && !job_signaled) {
drm_helper_resume_force_mode(adev_to_drm(tmp_adev));
}

--
2.33.0




2021-12-15 17:24:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 40/42] staging: most: dim2: use device release method

From: Nikita Yushchenko <[email protected]>

commit d445aa402d60014a37a199fae2bba379696b007d upstream.

Commit 723de0f9171e ("staging: most: remove device from interface
structure") moved registration of driver-provided struct device to
the most subsystem. This updated dim2 driver as well.

However, struct device passed to register_device() becomes refcounted,
and must not be explicitly deallocated, but must provide release method
instead. Which is incompatible with managing it via devres.

This patch makes the device structure allocated without devres, adds
device release method, and moves device destruction there.

Fixes: 723de0f9171e ("staging: most: remove device from interface structure")
Signed-off-by: Nikita Yushchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/most/dim2/dim2.c | 55 +++++++++++++++++++++------------------
1 file changed, 30 insertions(+), 25 deletions(-)

--- a/drivers/staging/most/dim2/dim2.c
+++ b/drivers/staging/most/dim2/dim2.c
@@ -726,6 +726,23 @@ static int get_dim2_clk_speed(const char
return -EINVAL;
}

+static void dim2_release(struct device *d)
+{
+ struct dim2_hdm *dev = container_of(d, struct dim2_hdm, dev);
+ unsigned long flags;
+
+ kthread_stop(dev->netinfo_task);
+
+ spin_lock_irqsave(&dim_lock, flags);
+ dim_shutdown();
+ spin_unlock_irqrestore(&dim_lock, flags);
+
+ if (dev->disable_platform)
+ dev->disable_platform(to_platform_device(d->parent));
+
+ kfree(dev);
+}
+
/*
* dim2_probe - dim2 probe handler
* @pdev: platform device structure
@@ -746,7 +763,7 @@ static int dim2_probe(struct platform_de

enum { MLB_INT_IDX, AHB0_INT_IDX };

- dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev)
return -ENOMEM;

@@ -758,25 +775,27 @@ static int dim2_probe(struct platform_de
"microchip,clock-speed", &clock_speed);
if (ret) {
dev_err(&pdev->dev, "missing dt property clock-speed\n");
- return ret;
+ goto err_free_dev;
}

ret = get_dim2_clk_speed(clock_speed, &dev->clk_speed);
if (ret) {
dev_err(&pdev->dev, "bad dt property clock-speed\n");
- return ret;
+ goto err_free_dev;
}

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dev->io_base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(dev->io_base))
- return PTR_ERR(dev->io_base);
+ if (IS_ERR(dev->io_base)) {
+ ret = PTR_ERR(dev->io_base);
+ goto err_free_dev;
+ }

of_id = of_match_node(dim2_of_match, pdev->dev.of_node);
pdata = of_id->data;
ret = pdata && pdata->enable ? pdata->enable(pdev) : 0;
if (ret)
- return ret;
+ goto err_free_dev;

dev->disable_platform = pdata ? pdata->disable : NULL;

@@ -867,24 +886,19 @@ static int dim2_probe(struct platform_de
dev->most_iface.request_netinfo = request_netinfo;
dev->most_iface.driver_dev = &pdev->dev;
dev->most_iface.dev = &dev->dev;
- dev->dev.init_name = "dim2_state";
+ dev->dev.init_name = dev->name;
dev->dev.parent = &pdev->dev;
+ dev->dev.release = dim2_release;

- ret = most_register_interface(&dev->most_iface);
- if (ret) {
- dev_err(&pdev->dev, "failed to register MOST interface\n");
- goto err_stop_thread;
- }
-
- return 0;
+ return most_register_interface(&dev->most_iface);

-err_stop_thread:
- kthread_stop(dev->netinfo_task);
err_shutdown_dim:
dim_shutdown();
err_disable_platform:
if (dev->disable_platform)
dev->disable_platform(pdev);
+err_free_dev:
+ kfree(dev);

return ret;
}
@@ -898,17 +912,8 @@ err_disable_platform:
static int dim2_remove(struct platform_device *pdev)
{
struct dim2_hdm *dev = platform_get_drvdata(pdev);
- unsigned long flags;

most_deregister_interface(&dev->most_iface);
- kthread_stop(dev->netinfo_task);
-
- spin_lock_irqsave(&dim_lock, flags);
- dim_shutdown();
- spin_unlock_irqrestore(&dim_lock, flags);
-
- if (dev->disable_platform)
- dev->disable_platform(pdev);

return 0;
}



2021-12-15 17:24:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 39/42] tracing: Fix a kmemleak false positive in tracing_map

From: Chen Jun <[email protected]>

[ Upstream commit f25667e5980a4333729cac3101e5de1bb851f71a ]

Doing the command:
echo 'hist:key=common_pid.execname,common_timestamp' > /sys/kernel/debug/tracing/events/xxx/trigger

Triggers many kmemleak reports:

unreferenced object 0xffff0000c7ea4980 (size 128):
comm "bash", pid 338, jiffies 4294912626 (age 9339.324s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000f3469921>] kmem_cache_alloc_trace+0x4c0/0x6f0
[<0000000054ca40c3>] hist_trigger_elt_data_alloc+0x140/0x178
[<00000000633bd154>] tracing_map_init+0x1f8/0x268
[<000000007e814ab9>] event_hist_trigger_func+0xca0/0x1ad0
[<00000000bf8520ed>] trigger_process_regex+0xd4/0x128
[<00000000f549355a>] event_trigger_write+0x7c/0x120
[<00000000b80f898d>] vfs_write+0xc4/0x380
[<00000000823e1055>] ksys_write+0x74/0xf8
[<000000008a9374aa>] __arm64_sys_write+0x24/0x30
[<0000000087124017>] do_el0_svc+0x88/0x1c0
[<00000000efd0dcd1>] el0_svc+0x1c/0x28
[<00000000dbfba9b3>] el0_sync_handler+0x88/0xc0
[<00000000e7399680>] el0_sync+0x148/0x180
unreferenced object 0xffff0000c7ea4980 (size 128):
comm "bash", pid 338, jiffies 4294912626 (age 9339.324s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000f3469921>] kmem_cache_alloc_trace+0x4c0/0x6f0
[<0000000054ca40c3>] hist_trigger_elt_data_alloc+0x140/0x178
[<00000000633bd154>] tracing_map_init+0x1f8/0x268
[<000000007e814ab9>] event_hist_trigger_func+0xca0/0x1ad0
[<00000000bf8520ed>] trigger_process_regex+0xd4/0x128
[<00000000f549355a>] event_trigger_write+0x7c/0x120
[<00000000b80f898d>] vfs_write+0xc4/0x380
[<00000000823e1055>] ksys_write+0x74/0xf8
[<000000008a9374aa>] __arm64_sys_write+0x24/0x30
[<0000000087124017>] do_el0_svc+0x88/0x1c0
[<00000000efd0dcd1>] el0_svc+0x1c/0x28
[<00000000dbfba9b3>] el0_sync_handler+0x88/0xc0
[<00000000e7399680>] el0_sync+0x148/0x180

The reason is elts->pages[i] is alloced by get_zeroed_page.
and kmemleak will not scan the area alloced by get_zeroed_page.
The address stored in elts->pages will be regarded as leaked.

That is, the elts->pages[i] will have pointers loaded onto it as well, and
without telling kmemleak about it, those pointers will look like memory
without a reference.

To fix this, call kmemleak_alloc to tell kmemleak to scan elts->pages[i]

Link: https://lkml.kernel.org/r/[email protected]

Signed-off-by: Chen Jun <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/trace/tracing_map.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c
index 39bb56d2dcbef..9628b55718468 100644
--- a/kernel/trace/tracing_map.c
+++ b/kernel/trace/tracing_map.c
@@ -15,6 +15,7 @@
#include <linux/jhash.h>
#include <linux/slab.h>
#include <linux/sort.h>
+#include <linux/kmemleak.h>

#include "tracing_map.h"
#include "trace.h"
@@ -307,6 +308,7 @@ static void tracing_map_array_free(struct tracing_map_array *a)
for (i = 0; i < a->n_pages; i++) {
if (!a->pages[i])
break;
+ kmemleak_free(a->pages[i]);
free_page((unsigned long)a->pages[i]);
}

@@ -342,6 +344,7 @@ static struct tracing_map_array *tracing_map_array_alloc(unsigned int n_elts,
a->pages[i] = (void *)get_zeroed_page(GFP_KERNEL);
if (!a->pages[i])
goto free;
+ kmemleak_alloc(a->pages[i], PAGE_SIZE, 1, GFP_KERNEL);
}
out:
return a;
--
2.33.0




2021-12-15 17:24:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 37/42] drm/amd/display: add connector type check for CRC source set

From: Perry Yuan <[email protected]>

[ Upstream commit 2da34b7bb59e1caa9a336e0e20a76b8b6a4abea2 ]

[Why]
IGT bypass test will set crc source as DPRX,and display DM didn`t check
connection type, it run the test on the HDMI connector ,then the kernel
will be crashed because aux->transfer is set null for HDMI connection.
This patch will skip the invalid connection test and fix kernel crash issue.

[How]
Check the connector type while setting the pipe crc source as DPRX or
auto,if the type is not DP or eDP, the crtc crc source will not be set
and report error code to IGT test,IGT will show the this subtest as no
valid crtc/connector combinations found.

116.779714] [IGT] amd_bypass: starting subtest 8bpc-bypass-mode
[ 117.730996] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 117.731001] #PF: supervisor instruction fetch in kernel mode
[ 117.731003] #PF: error_code(0x0010) - not-present page
[ 117.731004] PGD 0 P4D 0
[ 117.731006] Oops: 0010 [#1] SMP NOPTI
[ 117.731009] CPU: 11 PID: 2428 Comm: amd_bypass Tainted: G OE 5.11.0-34-generic #36~20.04.1-Ubuntu
[ 117.731011] Hardware name: AMD CZN/, BIOS AB.FD 09/07/2021
[ 117.731012] RIP: 0010:0x0
[ 117.731015] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[ 117.731016] RSP: 0018:ffffa8d64225bab8 EFLAGS: 00010246
[ 117.731017] RAX: 0000000000000000 RBX: 0000000000000020 RCX: ffffa8d64225bb5e
[ 117.731018] RDX: ffff93151d921880 RSI: ffffa8d64225bac8 RDI: ffff931511a1a9d8
[ 117.731022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 117.731023] CR2: ffffffffffffffd6 CR3: 000000010d5a4000 CR4: 0000000000750ee0
[ 117.731023] PKRU: 55555554
[ 117.731024] Call Trace:
[ 117.731027] drm_dp_dpcd_access+0x72/0x110 [drm_kms_helper]
[ 117.731036] drm_dp_dpcd_read+0xb7/0xf0 [drm_kms_helper]
[ 117.731040] drm_dp_start_crc+0x38/0xb0 [drm_kms_helper]
[ 117.731047] amdgpu_dm_crtc_set_crc_source+0x1ae/0x3e0 [amdgpu]
[ 117.731149] crtc_crc_open+0x174/0x220 [drm]
[ 117.731162] full_proxy_open+0x168/0x1f0
[ 117.731165] ? open_proxy_open+0x100/0x100

BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1546
Reviewed-by: Harry Wentland <[email protected]>
Reviewed-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Perry Yuan <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index cce062adc4391..8a441a22c46ec 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -314,6 +314,14 @@ int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name)
ret = -EINVAL;
goto cleanup;
}
+
+ if ((aconn->base.connector_type != DRM_MODE_CONNECTOR_DisplayPort) &&
+ (aconn->base.connector_type != DRM_MODE_CONNECTOR_eDP)) {
+ DRM_DEBUG_DRIVER("No DP connector available for CRC source\n");
+ ret = -EINVAL;
+ goto cleanup;
+ }
+
}

#if defined(CONFIG_DRM_AMD_SECURE_DISPLAY)
--
2.33.0




2021-12-15 17:24:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 41/42] fuse: make sure reclaim doesnt write the inode

From: Miklos Szeredi <[email protected]>

commit 5c791fe1e2a4f401f819065ea4fc0450849f1818 upstream.

In writeback cache mode mtime/ctime updates are cached, and flushed to the
server using the ->write_inode() callback.

Closing the file will result in a dirty inode being immediately written,
but in other cases the inode can remain dirty after all references are
dropped. This result in the inode being written back from reclaim, which
can deadlock on a regular allocation while the request is being served.

The usual mechanisms (GFP_NOFS/PF_MEMALLOC*) don't work for FUSE, because
serving a request involves unrelated userspace process(es).

Instead do the same as for dirty pages: make sure the inode is written
before the last reference is gone.

- fallocate(2)/copy_file_range(2): these call file_update_time() or
file_modified(), so flush the inode before returning from the call

- unlink(2), link(2) and rename(2): these call fuse_update_ctime(), so
flush the ctime directly from this helper

Reported-by: chenguanyou <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
Cc: Ed Tsai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/fuse/dir.c | 8 ++++++++
fs/fuse/file.c | 15 +++++++++++++++
fs/fuse/fuse_i.h | 1 +
fs/fuse/inode.c | 3 +++
4 files changed, 27 insertions(+)

--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -738,11 +738,19 @@ static int fuse_symlink(struct user_name
return create_new_entry(fm, &args, dir, entry, S_IFLNK);
}

+void fuse_flush_time_update(struct inode *inode)
+{
+ int err = sync_inode_metadata(inode, 1);
+
+ mapping_set_error(inode->i_mapping, err);
+}
+
void fuse_update_ctime(struct inode *inode)
{
if (!IS_NOCMTIME(inode)) {
inode->i_ctime = current_time(inode);
mark_inode_dirty_sync(inode);
+ fuse_flush_time_update(inode);
}
}

--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -1848,6 +1848,17 @@ int fuse_write_inode(struct inode *inode
struct fuse_file *ff;
int err;

+ /*
+ * Inode is always written before the last reference is dropped and
+ * hence this should not be reached from reclaim.
+ *
+ * Writing back the inode from reclaim can deadlock if the request
+ * processing itself needs an allocation. Allocations triggering
+ * reclaim while serving a request can't be prevented, because it can
+ * involve any number of unrelated userspace processes.
+ */
+ WARN_ON(wbc->for_reclaim);
+
ff = __fuse_write_file_get(fi);
err = fuse_flush_times(inode, ff);
if (ff)
@@ -3002,6 +3013,8 @@ out:
if (lock_inode)
inode_unlock(inode);

+ fuse_flush_time_update(inode);
+
return err;
}

@@ -3111,6 +3124,8 @@ out:
inode_unlock(inode_out);
file_accessed(file_in);

+ fuse_flush_time_update(inode_out);
+
return err;
}

--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -1148,6 +1148,7 @@ int fuse_allow_current_process(struct fu

u64 fuse_lock_owner_id(struct fuse_conn *fc, fl_owner_t id);

+void fuse_flush_time_update(struct inode *inode);
void fuse_update_ctime(struct inode *inode);

int fuse_update_attributes(struct inode *inode, struct file *file);
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -118,6 +118,9 @@ static void fuse_evict_inode(struct inod
{
struct fuse_inode *fi = get_fuse_inode(inode);

+ /* Will write inode on close/munmap and in all other dirtiers */
+ WARN_ON(inode->i_state & I_DIRTY_INODE);
+
truncate_inode_pages_final(&inode->i_data);
clear_inode(inode);
if (inode->i_sb->s_flags & SB_ACTIVE) {



2021-12-15 17:24:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 42/42] perf inject: Fix itrace space allowed for new attributes

From: Adrian Hunter <[email protected]>

commit c29d9792607e67ed8a3f6e9db0d96836d885a8c5 upstream.

The space allowed for new attributes can be too small if existing header
information is large. That can happen, for example, if there are very
many CPUs, due to having an event ID per CPU per event being stored in the
header information.

Fix by adding the existing header.data_offset. Also increase the extra
space allowed to 8KiB and align to a 4KiB boundary for neatness.

Signed-off-by: Adrian Hunter <[email protected]>
Cc: Jiri Olsa <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
[Adrian: Backport to v5.15]
Signed-off-by: Adrian Hunter <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/perf/builtin-inject.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -819,7 +819,7 @@ static int __cmd_inject(struct perf_inje
inject->tool.ordered_events = true;
inject->tool.ordering_requires_timestamps = true;
/* Allow space in the header for new attributes */
- output_data_offset = 4096;
+ output_data_offset = roundup(8192 + session->header.data_offset, 4096);
if (inject->strip)
strip_init(inject);
}



2021-12-15 17:25:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 19/42] drm/msm: Fix null ptr access msm_ioctl_gem_submit()

From: Akhil P Oommen <[email protected]>

[ Upstream commit 26d776fd0f79f093a5d0ce1a4c7c7a992bc3264c ]

Fix the below null pointer dereference in msm_ioctl_gem_submit():

26545.260705: Call trace:
26545.263223: kref_put+0x1c/0x60
26545.266452: msm_ioctl_gem_submit+0x254/0x744
26545.270937: drm_ioctl_kernel+0xa8/0x124
26545.274976: drm_ioctl+0x21c/0x33c
26545.278478: drm_compat_ioctl+0xdc/0xf0
26545.282428: __arm64_compat_sys_ioctl+0xc8/0x100
26545.287169: el0_svc_common+0xf8/0x250
26545.291025: do_el0_svc_compat+0x28/0x54
26545.295066: el0_svc_compat+0x10/0x1c
26545.298838: el0_sync_compat_handler+0xa8/0xcc
26545.303403: el0_sync_compat+0x188/0x1c0
26545.307445: Code: d503201f d503201f 52800028 4b0803e8 (b8680008)
26545.318799: Kernel panic - not syncing: Oops: Fatal exception

Signed-off-by: Akhil P Oommen <[email protected]>
Link: https://lore.kernel.org/r/20211118154903.2.I3ae019673a0cc45d83a193a7858748dd03dbb820@changeid
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/msm/msm_gem_submit.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c
index a38f23be497d8..d9aef97eb93ad 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -780,6 +780,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
args->nr_cmds);
if (IS_ERR(submit)) {
ret = PTR_ERR(submit);
+ submit = NULL;
goto out_unlock;
}

--
2.33.0




2021-12-15 17:25:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 22/42] drm/msm/dp: Avoid unpowered AUX xfers that caused crashes

From: Douglas Anderson <[email protected]>

[ Upstream commit d03fcc1de0863b1188ceb867cfa84a578fdc96bc ]

If you happened to try to access `/dev/drm_dp_aux` devices provided by
the MSM DP AUX driver too early at bootup you could go boom. Let's
avoid that by only allowing AUX transfers when the controller is
powered up.

Specifically the crash that was seen (on Chrome OS 5.4 tree with
relevant backports):
Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 0 PID: 3131 Comm: fwupd Not tainted 5.4.144-16620-g28af11b73efb #1
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
Call trace:
dump_backtrace+0x0/0x14c
show_stack+0x20/0x2c
dump_stack+0xac/0x124
panic+0x150/0x390
nmi_panic+0x80/0x94
arm64_serror_panic+0x78/0x84
do_serror+0x0/0x118
do_serror+0xa4/0x118
el1_error+0xbc/0x160
dp_catalog_aux_write_data+0x1c/0x3c
dp_aux_cmd_fifo_tx+0xf0/0x1b0
dp_aux_transfer+0x1b0/0x2bc
drm_dp_dpcd_access+0x8c/0x11c
drm_dp_dpcd_read+0x64/0x10c
auxdev_read_iter+0xd4/0x1c4

I did a little bit of tracing and found that:
* We register the AUX device very early at bootup.
* Power isn't actually turned on for my system until
hpd_event_thread() -> dp_display_host_init() -> dp_power_init()
* You can see that dp_power_init() calls dp_aux_init() which is where
we start allowing AUX channel requests to go through.

In general this patch is a bit of a bandaid but at least it gets us
out of the current state where userspace acting at the wrong time can
fully crash the system.
* I think the more proper fix (which requires quite a bit more
changes) is to power stuff on while an AUX transfer is
happening. This is like the solution we did for ti-sn65dsi86. This
might be required for us to move to populating the panel via the
DP-AUX bus.
* Another fix considered was to dynamically register / unregister. I
tried that at <https://crrev.com/c/3169431/3> but it got
ugly. Currently there's a bug where the pm_runtime() state isn't
tracked properly and that causes us to just keep registering more
and more.

Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Kuogee Hsieh <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Link: https://lore.kernel.org/r/20211109100403.1.I4e23470d681f7efe37e2e7f1a6466e15e9bb1d72@changeid
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/msm/dp/dp_aux.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index eb40d8413bca9..6d36f63c33388 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -33,6 +33,7 @@ struct dp_aux_private {
bool read;
bool no_send_addr;
bool no_send_stop;
+ bool initted;
u32 offset;
u32 segment;

@@ -331,6 +332,10 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
}

mutex_lock(&aux->mutex);
+ if (!aux->initted) {
+ ret = -EIO;
+ goto exit;
+ }

dp_aux_update_offset_and_segment(aux, msg);
dp_aux_transfer_helper(aux, msg, true);
@@ -380,6 +385,8 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
}

aux->cmd_busy = false;
+
+exit:
mutex_unlock(&aux->mutex);

return ret;
@@ -431,8 +438,13 @@ void dp_aux_init(struct drm_dp_aux *dp_aux)

aux = container_of(dp_aux, struct dp_aux_private, dp_aux);

+ mutex_lock(&aux->mutex);
+
dp_catalog_aux_enable(aux->catalog, true);
aux->retry_cnt = 0;
+ aux->initted = true;
+
+ mutex_unlock(&aux->mutex);
}

void dp_aux_deinit(struct drm_dp_aux *dp_aux)
@@ -441,7 +453,12 @@ void dp_aux_deinit(struct drm_dp_aux *dp_aux)

aux = container_of(dp_aux, struct dp_aux_private, dp_aux);

+ mutex_lock(&aux->mutex);
+
+ aux->initted = false;
dp_catalog_aux_enable(aux->catalog, false);
+
+ mutex_unlock(&aux->mutex);
}

int dp_aux_register(struct drm_dp_aux *dp_aux)
--
2.33.0




2021-12-15 17:25:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 20/42] drm/msm/a6xx: Fix uinitialized use of gpu_scid

From: Akhil P Oommen <[email protected]>

[ Upstream commit 9ba873e66ed317a1ff645d5e52c2e72597ff3d18 ]

Avoid a possible uninitialized use of gpu_scid variable to fix the
below smatch warning:
drivers/gpu/drm/msm/adreno/a6xx_gpu.c:1480 a6xx_llc_activate()
error: uninitialized symbol 'gpu_scid'.

Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Akhil P Oommen <[email protected]>
Link: https://lore.kernel.org/r/20211118154903.3.Ie4ac321feb10168af569d9c2b4cf6828bed8122c@changeid
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 267a880811d65..723074aae5b63 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1424,17 +1424,24 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
{
struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
struct msm_gpu *gpu = &adreno_gpu->base;
- u32 gpu_scid, cntl1_regval = 0;
+ u32 cntl1_regval = 0;

if (IS_ERR(a6xx_gpu->llc_mmio))
return;

if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
- gpu_scid = llcc_get_slice_id(a6xx_gpu->llc_slice);
+ u32 gpu_scid = llcc_get_slice_id(a6xx_gpu->llc_slice);

gpu_scid &= 0x1f;
cntl1_regval = (gpu_scid << 0) | (gpu_scid << 5) | (gpu_scid << 10) |
(gpu_scid << 15) | (gpu_scid << 20);
+
+ /* On A660, the SCID programming for UCHE traffic is done in
+ * A6XX_GBIF_SCACHE_CNTL0[14:10]
+ */
+ if (adreno_is_a660_family(adreno_gpu))
+ gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL0, (0x1f << 10) |
+ (1 << 8), (gpu_scid << 10) | (1 << 8));
}

/*
@@ -1471,13 +1478,6 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
}

gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL1, GENMASK(24, 0), cntl1_regval);
-
- /* On A660, the SCID programming for UCHE traffic is done in
- * A6XX_GBIF_SCACHE_CNTL0[14:10]
- */
- if (adreno_is_a660_family(adreno_gpu))
- gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL0, (0x1f << 10) |
- (1 << 8), (gpu_scid << 10) | (1 << 8));
}

static void a6xx_llc_slices_destroy(struct a6xx_gpu *a6xx_gpu)
--
2.33.0




2021-12-15 17:25:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 23/42] KVM: arm64: Save PSTATE early on exit

From: Marc Zyngier <[email protected]>

[ Upstream commit 83bb2c1a01d7127d5adc7d69d7aaa3f7072de2b4 ]

In order to be able to use primitives such as vcpu_mode_is_32bit(),
we need to synchronize the guest PSTATE. However, this is currently
done deep into the bowels of the world-switch code, and we do have
helpers evaluating this much earlier (__vgic_v3_perform_cpuif_access
and handle_aarch32_guest, for example).

Move the saving of the guest pstate into the early fixups, which
cures the first issue. The second one will be addressed separately.

Tested-by: Fuad Tabba <[email protected]>
Reviewed-by: Fuad Tabba <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/arm64/kvm/hyp/include/hyp/switch.h | 6 ++++++
arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 7 ++++++-
2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index a0e78a6027be0..c75e84489f57b 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -416,6 +416,12 @@ static inline bool __hyp_handle_ptrauth(struct kvm_vcpu *vcpu)
*/
static inline bool fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
{
+ /*
+ * Save PSTATE early so that we can evaluate the vcpu mode
+ * early on.
+ */
+ vcpu->arch.ctxt.regs.pstate = read_sysreg_el2(SYS_SPSR);
+
if (ARM_EXCEPTION_CODE(*exit_code) != ARM_EXCEPTION_IRQ)
vcpu->arch.fault.esr_el2 = read_sysreg_el2(SYS_ESR);

diff --git a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
index de7e14c862e6c..7ecca8b078519 100644
--- a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
+++ b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
@@ -70,7 +70,12 @@ static inline void __sysreg_save_el1_state(struct kvm_cpu_context *ctxt)
static inline void __sysreg_save_el2_return_state(struct kvm_cpu_context *ctxt)
{
ctxt->regs.pc = read_sysreg_el2(SYS_ELR);
- ctxt->regs.pstate = read_sysreg_el2(SYS_SPSR);
+ /*
+ * Guest PSTATE gets saved at guest fixup time in all
+ * cases. We still need to handle the nVHE host side here.
+ */
+ if (!has_vhe() && ctxt->__hyp_running_vcpu)
+ ctxt->regs.pstate = read_sysreg_el2(SYS_SPSR);

if (cpus_have_final_cap(ARM64_HAS_RAS_EXTN))
ctxt_sys_reg(ctxt, DISR_EL1) = read_sysreg_s(SYS_VDISR_EL2);
--
2.33.0




2021-12-15 17:25:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 24/42] s390/test_unwind: use raw opcode instead of invalid instruction

From: Ilie Halip <[email protected]>

[ Upstream commit 53ae7230918154d1f4281d7aa3aae9650436eadf ]

Building with clang & LLVM_IAS=1 leads to an error:
arch/s390/lib/test_unwind.c:179:4: error: invalid register pair
" mvcl %%r1,%%r1\n"
^

The test creates an invalid instruction that would trap at runtime, but the
LLVM inline assembler tries to validate it at compile time too.

Use the raw instruction opcode instead.

Reported-by: Nick Desaulniers <[email protected]>
Signed-off-by: Ilie Halip <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Suggested-by: Ulrich Weigand <[email protected]>
Link: https://github.com/ClangBuiltLinux/linux/issues/1421
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christian Borntraeger <[email protected]>
Signed-off-by: Christian Borntraeger <[email protected]>
[[email protected]: use illegal opcode, and update comment]
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/s390/lib/test_unwind.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/s390/lib/test_unwind.c b/arch/s390/lib/test_unwind.c
index ecf327d743a03..c0635cf787e31 100644
--- a/arch/s390/lib/test_unwind.c
+++ b/arch/s390/lib/test_unwind.c
@@ -171,10 +171,11 @@ static noinline int unwindme_func4(struct unwindme *u)
}

/*
- * trigger specification exception
+ * Trigger operation exception; use insn notation to bypass
+ * llvm's integrated assembler sanity checks.
*/
asm volatile(
- " mvcl %%r1,%%r1\n"
+ " .insn e,0x0000\n" /* illegal opcode */
"0: nopr %%r7\n"
EX_TABLE(0b, 0b)
:);
--
2.33.0




2021-12-15 17:25:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 25/42] Revert "tty: serial: fsl_lpuart: drop earlycon entry for i.MX8QXP"

From: Alexander Stein <[email protected]>

[ Upstream commit 4e9679738a918d8a482ac6a2cb2bb871f094bb84 ]

Revert commit b4b844930f27 ("tty: serial: fsl_lpuart: drop earlycon entry
for i.MX8QXP"), because this breaks earlycon support on imx8qm/imx8qxp.
While it is true that for earlycon there is no difference between
i.MX8QXP and i.MX7ULP (for now at least), there are differences
regarding clocks and fixups for wakeup support. For that reason it was
deemed unacceptable to add the imx7ulp compatible to device tree in
order to get earlycon working again.

Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Alexander Stein <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/tty/serial/fsl_lpuart.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index b1e7190ae4836..ac5112def40d1 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -2625,6 +2625,7 @@ OF_EARLYCON_DECLARE(lpuart, "fsl,vf610-lpuart", lpuart_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,ls1021a-lpuart", lpuart32_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,ls1028a-lpuart", ls1028a_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,imx7ulp-lpuart", lpuart32_imx_early_console_setup);
+OF_EARLYCON_DECLARE(lpuart32, "fsl,imx8qxp-lpuart", lpuart32_imx_early_console_setup);
EARLYCON_DECLARE(lpuart, lpuart_early_console_setup);
EARLYCON_DECLARE(lpuart32, lpuart32_early_console_setup);

--
2.33.0




2021-12-15 17:25:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 16/42] ice: fix FDIR init missing when reset VF

From: Yahui Cao <[email protected]>

[ Upstream commit f23ab04dd6f703e282bb2d51fe3ae14f4b88a628 ]

When VF is being reset, ice_reset_vf() will be called and FDIR
resource should be released and initialized again.

Fixes: 1f7ea1cd6a37 ("ice: Enable FDIR Configure for AVF")
Signed-off-by: Yahui Cao <[email protected]>
Tested-by: Konrad Jankowski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
index 8c223beeb6b8a..a78e8f00cf71b 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@ -1569,6 +1569,7 @@ bool ice_reset_all_vfs(struct ice_pf *pf, bool is_vflr)
ice_vc_set_default_allowlist(vf);

ice_vf_fdir_exit(vf);
+ ice_vf_fdir_init(vf);
/* clean VF control VSI when resetting VFs since it should be
* setup only when VF creates its first FDIR rule.
*/
@@ -1695,6 +1696,7 @@ bool ice_reset_vf(struct ice_vf *vf, bool is_vflr)
}

ice_vf_fdir_exit(vf);
+ ice_vf_fdir_init(vf);
/* clean VF control VSI when resetting VF since it should be setup
* only when VF creates its first FDIR rule.
*/
--
2.33.0




2021-12-15 17:25:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.15 21/42] drm/msm/dsi: set default num_data_lanes

From: Philip Chen <[email protected]>

[ Upstream commit cd92cc187c053ab010a1570e2d61d68394a5c725 ]

If "data_lanes" property of the dsi output endpoint is missing in
the DT, num_data_lanes would be 0 by default, which could cause
dsi_host_attach() to fail if dsi->lanes is set to a non-zero value
by the bridge driver.

According to the binding document of msm dsi controller, the
input/output endpoint of the controller is expected to have 4 lanes.
So let's set num_data_lanes to 4 by default.

Signed-off-by: Philip Chen <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Link: https://lore.kernel.org/r/20211030100812.1.I6cd9af36b723fed277d34539d3b2ba4ca233ad2d@changeid
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
index ea641151e77e7..dc85974c78975 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1696,6 +1696,8 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host *msm_host,
if (!prop) {
DRM_DEV_DEBUG(dev,
"failed to find data lane mapping, using default\n");
+ /* Set the number of date lanes to 4 by default. */
+ msm_host->num_data_lanes = 4;
return 0;
}

--
2.33.0




2021-12-15 20:02:10

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/42] 5.15.9-rc1 review


On 15/12/2021 17:20, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.9 release.
> There are 42 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 Fri, 17 Dec 2021 17:20:14 +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.15.9-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.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


No new regressions.

Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
106 tests: 100 pass, 6 fail

Linux version: 5.15.9-rc1-g1388dadc57b7
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04

Test failures: tegra194-p2972-0000: boot.py
tegra194-p2972-0000: tegra-audio-boot-sanity.sh
tegra194-p2972-0000: tegra-audio-hda-playback.sh
tegra194-p3509-0000+p3668-0000: devices
tegra194-p3509-0000+p3668-0000: tegra-audio-boot-sanity.sh
tegra194-p3509-0000+p3668-0000: tegra-audio-hda-playback.sh

Tested-by: Jon Hunter <[email protected]>

Jon

--
nvpublic

2021-12-15 21:52:07

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/42] 5.15.9-rc1 review

On 12/15/21 10:20 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.9 release.
> There are 42 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 Fri, 17 Dec 2021 17:20:14 +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.15.9-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.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

Tested-by: Shuah Khan <[email protected]>

thanks,
-- Shuah


2021-12-15 23:04:03

by Fox Chen

[permalink] [raw]
Subject: RE: [PATCH 5.15 00/42] 5.15.9-rc1 review

On Wed, 15 Dec 2021 18:20:41 +0100, Greg Kroah-Hartman <[email protected]> wrote:
> This is the start of the stable review cycle for the 5.15.9 release.
> There are 42 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 Fri, 17 Dec 2021 17:20:14 +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.15.9-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.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

5.15.9-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)

Tested-by: Fox Chen <[email protected]>


2021-12-15 23:46:21

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/42] 5.15.9-rc1 review

On 12/15/21 9:20 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.9 release.
> There are 42 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 Fri, 17 Dec 2021 17:20:14 +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.15.9-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.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:

Tested-by: Florian Fainelli <[email protected]>
--
Florian

2021-12-16 03:09:14

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/42] 5.15.9-rc1 review

On Wed, 15 Dec 2021 at 22:52, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.15.9 release.
> There are 42 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 Fri, 17 Dec 2021 17:20:14 +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.15.9-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.15.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.

Tested-by: Linux Kernel Functional Testing <[email protected]>

## Build
* kernel: 5.15.9-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: 1388dadc57b7c1ac72c57901d99babdf578e5e73
* git describe: v5.15.8-43-g1388dadc57b7
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.8-43-g1388dadc57b7

## No Test Regressions (compared to v5.15.7-171-ge18bff95c819)

## No Test Fixes (compared to v5.15.7-171-ge18bff95c819)

## Test result summary
total: 99807, pass: 84746, fail: 1229, skip: 12858, xfail: 974

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 259 total, 255 passed, 4 failed
* arm64: 37 total, 37 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 36 total, 36 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 34 total, 30 passed, 4 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 52 total, 48 passed, 4 failed
* riscv: 24 total, 16 passed, 8 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 37 total, 37 passed, 0 failed

## Test suites summary
* fwts
* kselftest-
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance

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

2021-12-16 18:08:33

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.15 00/42] 5.15.9-rc1 review

On Wed, Dec 15, 2021 at 06:20:41PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.9 release.
> There are 42 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 Fri, 17 Dec 2021 17:20:14 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 154 pass: 154 fail: 0
Qemu test results:
total: 480 pass: 480 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter

Subject: Re: [PATCH 5.15 04/42] RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow

Hi, this is your Linux kernel regression tracker speaking.

On 15.12.21 18:20, Greg Kroah-Hartman wrote:
> From: Alaa Hleihel <[email protected]>
>
> [ Upstream commit f0ae4afe3d35e67db042c58a52909e06262b740f ]
>
> For the case of IB_MR_TYPE_DM the mr does doesn't have a umem, even though
> it is a user MR. This causes function mlx5_free_priv_descs() to think that
> it is a kernel MR, leading to wrongly accessing mr->descs that will get
> wrong values in the union which leads to attempt to release resources that
> were not allocated in the first place.

TWIMC, that commit made it into 5.15.y, but is known to cause a
regression in v5.16-rc:

https://lore.kernel.org/lkml/f298db4ec5fdf7a2d1d166ca2f66020fd9397e5c.1640079962.git.leonro@nvidia.com/
https://lore.kernel.org/all/[email protected]/

A fix for mainline was posted, but got stuck afaics:
https://lore.kernel.org/lkml/f298db4ec5fdf7a2d1d166ca2f66020fd9397e5c.1640079962.git.leonro@nvidia.com/

A revert was also discussed, but not performed:
https://lore.kernel.org/all/[email protected]/

Ciao, Thorsten

> For example:
> DMA-API: mlx5_core 0000:08:00.1: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=0 bytes]
> WARNING: CPU: 8 PID: 1021 at kernel/dma/debug.c:961 check_unmap+0x54f/0x8b0
> RIP: 0010:check_unmap+0x54f/0x8b0
> Call Trace:
> debug_dma_unmap_page+0x57/0x60
> mlx5_free_priv_descs+0x57/0x70 [mlx5_ib]
> mlx5_ib_dereg_mr+0x1fb/0x3d0 [mlx5_ib]
> ib_dereg_mr_user+0x60/0x140 [ib_core]
> uverbs_destroy_uobject+0x59/0x210 [ib_uverbs]
> uobj_destroy+0x3f/0x80 [ib_uverbs]
> ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs]
> ? uverbs_finalize_object+0x50/0x50 [ib_uverbs]
> ? lock_acquire+0xc4/0x2e0
> ? lock_acquired+0x12/0x380
> ? lock_acquire+0xc4/0x2e0
> ? lock_acquire+0xc4/0x2e0
> ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]
> ? lock_release+0x28a/0x400
> ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs]
> ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]
> __x64_sys_ioctl+0x7f/0xb0
> do_syscall_64+0x38/0x90
>
> Fix it by reorganizing the dereg flow and mlx5_ib_mr structure:
> - Move the ib_umem field into the user MRs structure in the union as it's
> applicable only there.
> - Function mlx5_ib_dereg_mr() will now call mlx5_free_priv_descs() only
> in case there isn't udata, which indicates that this isn't a user MR.
>
> Fixes: f18ec4223117 ("RDMA/mlx5: Use a union inside mlx5_ib_mr")
> Link: https://lore.kernel.org/r/66bb1dd253c1fd7ceaa9fc411061eefa457b86fb.1637581144.git.leonro@nvidia.com
> Signed-off-by: Alaa Hleihel <[email protected]>
> Signed-off-by: Leon Romanovsky <[email protected]>
> Signed-off-by: Jason Gunthorpe <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> ---
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 6 +++---
> drivers/infiniband/hw/mlx5/mr.c | 26 ++++++++++++--------------
> 2 files changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> index bf20a388eabe1..6204ae2caef58 100644
> --- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
> +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> @@ -641,7 +641,6 @@ struct mlx5_ib_mr {
>
> /* User MR data */
> struct mlx5_cache_ent *cache_ent;
> - struct ib_umem *umem;
>
> /* This is zero'd when the MR is allocated */
> union {
> @@ -653,7 +652,7 @@ struct mlx5_ib_mr {
> struct list_head list;
> };
>
> - /* Used only by kernel MRs (umem == NULL) */
> + /* Used only by kernel MRs */
> struct {
> void *descs;
> void *descs_alloc;
> @@ -675,8 +674,9 @@ struct mlx5_ib_mr {
> int data_length;
> };
>
> - /* Used only by User MRs (umem != NULL) */
> + /* Used only by User MRs */
> struct {
> + struct ib_umem *umem;
> unsigned int page_shift;
> /* Current access_flags */
> int access_flags;
> diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
> index 22e2f4d79743d..69b2ce4c292ae 100644
> --- a/drivers/infiniband/hw/mlx5/mr.c
> +++ b/drivers/infiniband/hw/mlx5/mr.c
> @@ -1911,19 +1911,18 @@ mlx5_alloc_priv_descs(struct ib_device *device,
> return ret;
> }
>
> -static void
> -mlx5_free_priv_descs(struct mlx5_ib_mr *mr)
> +static void mlx5_free_priv_descs(struct mlx5_ib_mr *mr)
> {
> - if (!mr->umem && mr->descs) {
> - struct ib_device *device = mr->ibmr.device;
> - int size = mr->max_descs * mr->desc_size;
> - struct mlx5_ib_dev *dev = to_mdev(device);
> + struct mlx5_ib_dev *dev = to_mdev(mr->ibmr.device);
> + int size = mr->max_descs * mr->desc_size;
>
> - dma_unmap_single(&dev->mdev->pdev->dev, mr->desc_map, size,
> - DMA_TO_DEVICE);
> - kfree(mr->descs_alloc);
> - mr->descs = NULL;
> - }
> + if (!mr->descs)
> + return;
> +
> + dma_unmap_single(&dev->mdev->pdev->dev, mr->desc_map, size,
> + DMA_TO_DEVICE);
> + kfree(mr->descs_alloc);
> + mr->descs = NULL;
> }
>
> int mlx5_ib_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata)
> @@ -1999,7 +1998,8 @@ int mlx5_ib_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata)
> if (mr->cache_ent) {
> mlx5_mr_cache_free(dev, mr);
> } else {
> - mlx5_free_priv_descs(mr);
> + if (!udata)
> + mlx5_free_priv_descs(mr);
> kfree(mr);
> }
> return 0;
> @@ -2086,7 +2086,6 @@ static struct mlx5_ib_mr *mlx5_ib_alloc_pi_mr(struct ib_pd *pd,
> if (err)
> goto err_free_in;
>
> - mr->umem = NULL;
> kfree(in);
>
> return mr;
> @@ -2213,7 +2212,6 @@ static struct ib_mr *__mlx5_ib_alloc_mr(struct ib_pd *pd,
> }
>
> mr->ibmr.device = pd->device;
> - mr->umem = NULL;
>
> switch (mr_type) {
> case IB_MR_TYPE_MEM_REG:


Subject: Re: [PATCH 5.15 04/42] RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow

Hi Greg!

On 01.01.22 11:56, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker speaking.
>
> On 15.12.21 18:20, Greg Kroah-Hartman wrote:
>> From: Alaa Hleihel <[email protected]>
>>
>> [ Upstream commit f0ae4afe3d35e67db042c58a52909e06262b740f ]
>>
>> For the case of IB_MR_TYPE_DM the mr does doesn't have a umem, even though
>> it is a user MR. This causes function mlx5_free_priv_descs() to think that
>> it is a kernel MR, leading to wrongly accessing mr->descs that will get
>> wrong values in the union which leads to attempt to release resources that
>> were not allocated in the first place.
>
> TWIMC, that commit made it into 5.15.y, but is known to cause a
> regression in v5.16-rc:
>
> https://lore.kernel.org/lkml/f298db4ec5fdf7a2d1d166ca2f66020fd9397e5c.1640079962.git.leonro@nvidia.com/
> https://lore.kernel.org/all/[email protected]/
>
> A fix for mainline was posted, but got stuck afaics:
> https://lore.kernel.org/lkml/f298db4ec5fdf7a2d1d166ca2f66020fd9397e5c.1640079962.git.leonro@nvidia.com/
>
> A revert was also discussed, but not performed:
> https://lore.kernel.org/all/[email protected]/

I assume your scripts will catch this, nevertheless FYI:

Below patch was reverted in mainline, as it "is not the full fix and
still causes to call traces". You likely want to revert it from v5.15.y
as well. For details see

4163cb3d1980 ("Revert "RDMA/mlx5: Fix releasing unallocated memory in
dereg MR flow"")

https://git.kernel.org/torvalds/c/4163cb3d1980383220ad7043002b930995dcba33

Ciao, Thorsten

>> For example:
>> DMA-API: mlx5_core 0000:08:00.1: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=0 bytes]
>> WARNING: CPU: 8 PID: 1021 at kernel/dma/debug.c:961 check_unmap+0x54f/0x8b0
>> RIP: 0010:check_unmap+0x54f/0x8b0
>> Call Trace:
>> debug_dma_unmap_page+0x57/0x60
>> mlx5_free_priv_descs+0x57/0x70 [mlx5_ib]
>> mlx5_ib_dereg_mr+0x1fb/0x3d0 [mlx5_ib]
>> ib_dereg_mr_user+0x60/0x140 [ib_core]
>> uverbs_destroy_uobject+0x59/0x210 [ib_uverbs]
>> uobj_destroy+0x3f/0x80 [ib_uverbs]
>> ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs]
>> ? uverbs_finalize_object+0x50/0x50 [ib_uverbs]
>> ? lock_acquire+0xc4/0x2e0
>> ? lock_acquired+0x12/0x380
>> ? lock_acquire+0xc4/0x2e0
>> ? lock_acquire+0xc4/0x2e0
>> ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]
>> ? lock_release+0x28a/0x400
>> ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs]
>> ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]
>> __x64_sys_ioctl+0x7f/0xb0
>> do_syscall_64+0x38/0x90
>>
>> Fix it by reorganizing the dereg flow and mlx5_ib_mr structure:
>> - Move the ib_umem field into the user MRs structure in the union as it's
>> applicable only there.
>> - Function mlx5_ib_dereg_mr() will now call mlx5_free_priv_descs() only
>> in case there isn't udata, which indicates that this isn't a user MR.
>>
>> Fixes: f18ec4223117 ("RDMA/mlx5: Use a union inside mlx5_ib_mr")
>> Link: https://lore.kernel.org/r/66bb1dd253c1fd7ceaa9fc411061eefa457b86fb.1637581144.git.leonro@nvidia.com
>> Signed-off-by: Alaa Hleihel <[email protected]>
>> Signed-off-by: Leon Romanovsky <[email protected]>
>> Signed-off-by: Jason Gunthorpe <[email protected]>
>> Signed-off-by: Sasha Levin <[email protected]>
>> ---
>> drivers/infiniband/hw/mlx5/mlx5_ib.h | 6 +++---
>> drivers/infiniband/hw/mlx5/mr.c | 26 ++++++++++++--------------
>> 2 files changed, 15 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
>> index bf20a388eabe1..6204ae2caef58 100644
>> --- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
>> +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
>> @@ -641,7 +641,6 @@ struct mlx5_ib_mr {
>>
>> /* User MR data */
>> struct mlx5_cache_ent *cache_ent;
>> - struct ib_umem *umem;
>>
>> /* This is zero'd when the MR is allocated */
>> union {
>> @@ -653,7 +652,7 @@ struct mlx5_ib_mr {
>> struct list_head list;
>> };
>>
>> - /* Used only by kernel MRs (umem == NULL) */
>> + /* Used only by kernel MRs */
>> struct {
>> void *descs;
>> void *descs_alloc;
>> @@ -675,8 +674,9 @@ struct mlx5_ib_mr {
>> int data_length;
>> };
>>
>> - /* Used only by User MRs (umem != NULL) */
>> + /* Used only by User MRs */
>> struct {
>> + struct ib_umem *umem;
>> unsigned int page_shift;
>> /* Current access_flags */
>> int access_flags;
>> diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
>> index 22e2f4d79743d..69b2ce4c292ae 100644
>> --- a/drivers/infiniband/hw/mlx5/mr.c
>> +++ b/drivers/infiniband/hw/mlx5/mr.c
>> @@ -1911,19 +1911,18 @@ mlx5_alloc_priv_descs(struct ib_device *device,
>> return ret;
>> }
>>
>> -static void
>> -mlx5_free_priv_descs(struct mlx5_ib_mr *mr)
>> +static void mlx5_free_priv_descs(struct mlx5_ib_mr *mr)
>> {
>> - if (!mr->umem && mr->descs) {
>> - struct ib_device *device = mr->ibmr.device;
>> - int size = mr->max_descs * mr->desc_size;
>> - struct mlx5_ib_dev *dev = to_mdev(device);
>> + struct mlx5_ib_dev *dev = to_mdev(mr->ibmr.device);
>> + int size = mr->max_descs * mr->desc_size;
>>
>> - dma_unmap_single(&dev->mdev->pdev->dev, mr->desc_map, size,
>> - DMA_TO_DEVICE);
>> - kfree(mr->descs_alloc);
>> - mr->descs = NULL;
>> - }
>> + if (!mr->descs)
>> + return;
>> +
>> + dma_unmap_single(&dev->mdev->pdev->dev, mr->desc_map, size,
>> + DMA_TO_DEVICE);
>> + kfree(mr->descs_alloc);
>> + mr->descs = NULL;
>> }
>>
>> int mlx5_ib_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata)
>> @@ -1999,7 +1998,8 @@ int mlx5_ib_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata)
>> if (mr->cache_ent) {
>> mlx5_mr_cache_free(dev, mr);
>> } else {
>> - mlx5_free_priv_descs(mr);
>> + if (!udata)
>> + mlx5_free_priv_descs(mr);
>> kfree(mr);
>> }
>> return 0;
>> @@ -2086,7 +2086,6 @@ static struct mlx5_ib_mr *mlx5_ib_alloc_pi_mr(struct ib_pd *pd,
>> if (err)
>> goto err_free_in;
>>
>> - mr->umem = NULL;
>> kfree(in);
>>
>> return mr;
>> @@ -2213,7 +2212,6 @@ static struct ib_mr *__mlx5_ib_alloc_mr(struct ib_pd *pd,
>> }
>>
>> mr->ibmr.device = pd->device;
>> - mr->umem = NULL;
>>
>> switch (mr_type) {
>> case IB_MR_TYPE_MEM_REG:
>

2022-01-07 10:57:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.15 04/42] RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow

On Fri, Jan 07, 2022 at 06:57:51AM +0100, Thorsten Leemhuis wrote:
> Hi Greg!
>
> On 01.01.22 11:56, Thorsten Leemhuis wrote:
> > Hi, this is your Linux kernel regression tracker speaking.
> >
> > On 15.12.21 18:20, Greg Kroah-Hartman wrote:
> >> From: Alaa Hleihel <[email protected]>
> >>
> >> [ Upstream commit f0ae4afe3d35e67db042c58a52909e06262b740f ]
> >>
> >> For the case of IB_MR_TYPE_DM the mr does doesn't have a umem, even though
> >> it is a user MR. This causes function mlx5_free_priv_descs() to think that
> >> it is a kernel MR, leading to wrongly accessing mr->descs that will get
> >> wrong values in the union which leads to attempt to release resources that
> >> were not allocated in the first place.
> >
> > TWIMC, that commit made it into 5.15.y, but is known to cause a
> > regression in v5.16-rc:
> >
> > https://lore.kernel.org/lkml/f298db4ec5fdf7a2d1d166ca2f66020fd9397e5c.1640079962.git.leonro@nvidia.com/
> > https://lore.kernel.org/all/[email protected]/
> >
> > A fix for mainline was posted, but got stuck afaics:
> > https://lore.kernel.org/lkml/f298db4ec5fdf7a2d1d166ca2f66020fd9397e5c.1640079962.git.leonro@nvidia.com/
> >
> > A revert was also discussed, but not performed:
> > https://lore.kernel.org/all/[email protected]/
>
> I assume your scripts will catch this, nevertheless FYI:
>
> Below patch was reverted in mainline, as it "is not the full fix and
> still causes to call traces". You likely want to revert it from v5.15.y
> as well. For details see
>
> 4163cb3d1980 ("Revert "RDMA/mlx5: Fix releasing unallocated memory in
> dereg MR flow"")
>
> https://git.kernel.org/torvalds/c/4163cb3d1980383220ad7043002b930995dcba33

Thanks for the heads-up, I have now queued this patch up for 5.15.y.

greg k-h