2022-04-19 08:36:14

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 00/63] 5.4.190-rc1 review

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

Responses should be made by Wed, 20 Apr 2022 12:11: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.4.190-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Duoming Zhou <[email protected]>
ax25: Fix UAF bugs in ax25 timers

Duoming Zhou <[email protected]>
ax25: Fix NULL pointer dereferences in ax25 timers

Duoming Zhou <[email protected]>
ax25: fix NPD bug in ax25_disconnect

Duoming Zhou <[email protected]>
ax25: fix UAF bug in ax25_send_control()

Duoming Zhou <[email protected]>
ax25: Fix refcount leaks caused by ax25_cb_del()

Duoming Zhou <[email protected]>
ax25: fix UAF bugs of net_device caused by rebinding operation

Duoming Zhou <[email protected]>
ax25: fix reference count leaks of ax25_dev

Duoming Zhou <[email protected]>
ax25: add refcount in ax25_dev to avoid UAF bugs

Chao Gao <[email protected]>
dma-direct: avoid redundant memory sync for swiotlb

Martin Povišer <[email protected]>
i2c: pasemi: Wait for write xfers to finish

Nadav Amit <[email protected]>
smp: Fix offline cpu check in flush_smp_call_function_queue()

Mikulas Patocka <[email protected]>
dm integrity: fix memory corruption when tag_size is less than digest size

Nathan Chancellor <[email protected]>
ARM: davinci: da850-evm: Avoid NULL pointer dereference

Paul Gortmaker <[email protected]>
tick/nohz: Use WARN_ON_ONCE() to prevent console saturation

Rei Yamamoto <[email protected]>
genirq/affinity: Consider that CPUs on nodes can be unbalanced

Melissa Wen <[email protected]>
drm/amd/display: don't ignore alpha property on pre-multiplied mode

Nicolas Dichtel <[email protected]>
ipv6: fix panic when forwarding a pkt with no in6 dev

Fabio M. De Francesco <[email protected]>
ALSA: pcm: Test for "silence" field in struct "pcm_format_data"

Tim Crawford <[email protected]>
ALSA: hda/realtek: Add quirk for Clevo PD50PNT

Naohiro Aota <[email protected]>
btrfs: mark resumed async balance as writing

Nathan Chancellor <[email protected]>
btrfs: remove unused variable in btrfs_{start,write}_dirty_block_groups()

Toke Høiland-Jørgensen <[email protected]>
ath9k: Fix usage of driver-private space in tx_info

Toke Høiland-Jørgensen <[email protected]>
ath9k: Properly clear TX status area before reporting to mac80211

Jason A. Donenfeld <[email protected]>
gcc-plugins: latent_entropy: use /dev/urandom

Oliver Upton <[email protected]>
KVM: Don't create VM debugfs files outside of the VM directory

Patrick Wang <[email protected]>
mm: kmemleak: take a full lowmem check in kmemleak_*_phys()

Juergen Gross <[email protected]>
mm, page_alloc: fix build_zonerefs_node()

Borislav Petkov <[email protected]>
perf/imx_ddr: Fix undefined behavior due to shift overflowing the constant

Duoming Zhou <[email protected]>
drivers: net: slip: fix NPD bug in sl_tx_timeout()

Chandrakanth patil <[email protected]>
scsi: megaraid_sas: Target with invalid LUN ID is deleted during scan

Alexey Galakhov <[email protected]>
scsi: mvsas: Add PCI ID of RocketRaid 2640

Kefeng Wang <[email protected]>
powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit

Roman Li <[email protected]>
drm/amd/display: Fix allocate_mst_payload assert on resume

Marcin Kozlowski <[email protected]>
net: usb: aqc111: Fix out-of-bounds accesses in RX fixup

Steve Capper <[email protected]>
tlb: hugetlb: Add more sizes to tlb_remove_huge_tlb_entry

Joey Gouly <[email protected]>
arm64: alternatives: mark patch_alternative() as `noinstr`

Jonathan Bakker <[email protected]>
regulator: wm8994: Add an off-on delay for WM8994 variant

Leo Ruan <[email protected]>
gpu: ipu-v3: Fix dev_dbg frequency output

Christian Lamparter <[email protected]>
ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

Randy Dunlap <[email protected]>
net: micrel: fix KS8851_MLL Kconfig

Tyrel Datwyler <[email protected]>
scsi: ibmvscsis: Increase INITIAL_SRP_LIMIT to 1024

Xiaoguang Wang <[email protected]>
scsi: target: tcmu: Fix possible page UAF

Michael Kelley <[email protected]>
Drivers: hv: vmbus: Prevent load re-ordering when reading ring buffer

QintaoShen <[email protected]>
drm/amdkfd: Check for potential null return of kmalloc_array()

Tushar Patel <[email protected]>
drm/amdkfd: Fix Incorrect VMIDs passed to HWS

Leo (Hanghong) Ma <[email protected]>
drm/amd/display: Update VTEM Infopacket definition

Charlene Liu <[email protected]>
drm/amd/display: fix audio format not updated after edid updated

Aurabindo Pillai <[email protected]>
drm/amd: Add USBC connector ID

Harshit Mogalapalli <[email protected]>
cifs: potential buffer overflow in handling symlinks

Lin Ma <[email protected]>
nfc: nci: add flush_workqueue to prevent uaf

Athira Rajeev <[email protected]>
testing/selftests/mqueue: Fix mq_perf_tests to free the allocated cpu set

Petr Malat <[email protected]>
sctp: Initialize daddr on peeled off socket

Karsten Graul <[email protected]>
net/smc: Fix NULL pointer dereference in smc_pnet_find_ib()

Stephen Boyd <[email protected]>
drm/msm/dsi: Use connector directly in msm_dsi_manager_connector_init()

Rameshkumar Sundaram <[email protected]>
cfg80211: hold bss_lock while updating nontrans_list

Benedikt Spranger <[email protected]>
net/sched: taprio: Check if socket flags are valid

Dinh Nguyen <[email protected]>
net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link

Marcelo Ricardo Leitner <[email protected]>
net/sched: fix initialization order when updating chain 0 head

Vadim Pasternak <[email protected]>
mlxsw: i2c: Fix initialization error flow

Linus Torvalds <[email protected]>
gpiolib: acpi: use correct format characters

Guillaume Nault <[email protected]>
veth: Ensure eth header is in skb's linear part

Vlad Buslov <[email protected]>
net/sched: flower: fix parsing of ethertype following VLAN header

Miaoqian Lin <[email protected]>
memory: atmel-ebi: Fix missing of_node_put in atmel_ebi_probe


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

Diffstat:

Makefile | 4 +-
arch/arm/mach-davinci/board-da850-evm.c | 4 +-
arch/arm64/kernel/alternative.c | 6 +--
arch/powerpc/include/asm/page.h | 6 ++-
drivers/ata/libata-core.c | 3 ++
drivers/gpio/gpiolib-acpi.c | 4 +-
drivers/gpu/drm/amd/amdgpu/ObjectID.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 11 ++----
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 2 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4 +-
.../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 14 ++++---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 14 ++++---
.../amd/display/modules/info_packet/info_packet.c | 5 ++-
drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +-
drivers/gpu/ipu-v3/ipu-di.c | 5 ++-
drivers/hv/ring_buffer.c | 11 +++++-
drivers/i2c/busses/i2c-pasemi.c | 6 +++
drivers/md/dm-integrity.c | 7 +++-
drivers/memory/atmel-ebi.c | 23 ++++++++---
drivers/net/ethernet/mellanox/mlxsw/i2c.c | 1 +
drivers/net/ethernet/micrel/Kconfig | 1 +
drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c | 8 ----
drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h | 4 ++
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 13 +++----
drivers/net/slip/slip.c | 2 +-
drivers/net/usb/aqc111.c | 9 ++++-
drivers/net/veth.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 33 ++++++++++------
drivers/perf/fsl_imx8_ddr_perf.c | 2 +-
drivers/regulator/wm8994-regulator.c | 42 +++++++++++++++++++--
drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 2 +-
drivers/scsi/megaraid/megaraid_sas.h | 3 ++
drivers/scsi/megaraid/megaraid_sas_base.c | 7 ++++
drivers/scsi/mvsas/mv_init.c | 1 +
drivers/target/target_core_user.c | 3 +-
fs/btrfs/block-group.c | 4 --
fs/btrfs/volumes.c | 2 +
fs/cifs/link.c | 3 ++
include/asm-generic/tlb.h | 10 +++--
include/net/ax25.h | 12 ++++++
include/net/flow_dissector.h | 2 +
kernel/dma/direct.c | 3 +-
kernel/irq/affinity.c | 5 ++-
kernel/smp.c | 2 +-
kernel/time/tick-sched.c | 2 +-
mm/kmemleak.c | 8 ++--
mm/page_alloc.c | 2 +-
net/ax25/af_ax25.c | 38 +++++++++++++++----
net/ax25/ax25_dev.c | 28 +++++++++++---
net/ax25/ax25_route.c | 13 ++++++-
net/ax25/ax25_subr.c | 20 +++++++---
net/core/flow_dissector.c | 1 +
net/ipv6/ip6_output.c | 2 +-
net/nfc/nci/core.c | 4 ++
net/sched/cls_api.c | 2 +-
net/sched/cls_flower.c | 18 ++++++---
net/sched/sch_taprio.c | 3 +-
net/sctp/socket.c | 2 +-
net/smc/smc_pnet.c | 5 ++-
net/wireless/scan.c | 2 +
scripts/gcc-plugins/latent_entropy_plugin.c | 44 +++++++++++++---------
sound/core/pcm_misc.c | 2 +-
sound/pci/hda/patch_realtek.c | 1 +
tools/testing/selftests/mqueue/mq_perf_tests.c | 25 ++++++++----
virt/kvm/kvm_main.c | 10 ++++-
68 files changed, 386 insertions(+), 161 deletions(-)



2022-04-19 08:38:16

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 50/63] tick/nohz: Use WARN_ON_ONCE() to prevent console saturation

From: Paul Gortmaker <[email protected]>

commit 40e97e42961f8c6cc7bd5fe67cc18417e02d78f1 upstream.

While running some testing on code that happened to allow the variable
tick_nohz_full_running to get set but with no "possible" NOHZ cores to
back up that setting, this warning triggered:

if (unlikely(tick_do_timer_cpu == TICK_DO_TIMER_NONE))
WARN_ON(tick_nohz_full_running);

The console was overwhemled with an endless stream of one WARN per tick
per core and there was no way to even see what was going on w/o using a
serial console to capture it and then trace it back to this.

Change it to WARN_ON_ONCE().

Fixes: 08ae95f4fd3b ("nohz_full: Allow the boot CPU to be nohz_full")
Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/time/tick-sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -131,7 +131,7 @@ static void tick_sched_do_timer(struct t
*/
if (unlikely(tick_do_timer_cpu == TICK_DO_TIMER_NONE)) {
#ifdef CONFIG_NO_HZ_FULL
- WARN_ON(tick_nohz_full_running);
+ WARN_ON_ONCE(tick_nohz_full_running);
#endif
tick_do_timer_cpu = cpu;
}


2022-04-19 08:45:10

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 20/63] drm/amdkfd: Check for potential null return of kmalloc_array()

From: QintaoShen <[email protected]>

[ Upstream commit ebbb7bb9e80305820dc2328a371c1b35679f2667 ]

As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference.
Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion.

Signed-off-by: QintaoShen <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_events.c b/drivers/gpu/drm/amd/amdkfd/kfd_events.c
index d674d4b3340f..adbb2fec2e0f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_events.c
@@ -532,6 +532,8 @@ static struct kfd_event_waiter *alloc_event_waiters(uint32_t num_events)
event_waiters = kmalloc_array(num_events,
sizeof(struct kfd_event_waiter),
GFP_KERNEL);
+ if (!event_waiters)
+ return NULL;

for (i = 0; (event_waiters) && (i < num_events) ; i++) {
init_wait(&event_waiters[i].wait);
--
2.35.1



2022-04-19 09:50:36

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 55/63] dma-direct: avoid redundant memory sync for swiotlb

From: Chao Gao <[email protected]>

commit 9e02977bfad006af328add9434c8bffa40e053bb upstream.

When we looked into FIO performance with swiotlb enabled in VM, we found
swiotlb_bounce() is always called one more time than expected for each DMA
read request.

It turns out that the bounce buffer is copied to original DMA buffer twice
after the completion of a DMA request (one is done by in
dma_direct_sync_single_for_cpu(), the other by swiotlb_tbl_unmap_single()).
But the content in bounce buffer actually doesn't change between the two
rounds of copy. So, one round of copy is redundant.

Pass DMA_ATTR_SKIP_CPU_SYNC flag to swiotlb_tbl_unmap_single() to
skip the memory copy in it.

This fix increases FIO 64KB sequential read throughput in a guest with
swiotlb=force by 5.6%.

Fixes: 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code")
Reported-by: Wang Zhaoyang1 <[email protected]>
Reported-by: Gao Liang <[email protected]>
Signed-off-by: Chao Gao <[email protected]>
Reviewed-by: Kevin Tian <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/dma/direct.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -306,7 +306,8 @@ void dma_direct_unmap_page(struct device
dma_direct_sync_single_for_cpu(dev, addr, size, dir);

if (unlikely(is_swiotlb_buffer(phys)))
- swiotlb_tbl_unmap_single(dev, phys, size, size, dir, attrs);
+ swiotlb_tbl_unmap_single(dev, phys, size, size, dir,
+ attrs | DMA_ATTR_SKIP_CPU_SYNC);
}
EXPORT_SYMBOL(dma_direct_unmap_page);



2022-04-19 10:47:29

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 21/63] Drivers: hv: vmbus: Prevent load re-ordering when reading ring buffer

From: Michael Kelley <[email protected]>

[ Upstream commit b6cae15b5710c8097aad26a2e5e752c323ee5348 ]

When reading a packet from a host-to-guest ring buffer, there is no
memory barrier between reading the write index (to see if there is
a packet to read) and reading the contents of the packet. The Hyper-V
host uses store-release when updating the write index to ensure that
writes of the packet data are completed first. On the guest side,
the processor can reorder and read the packet data before the write
index, and sometimes get stale packet data. Getting such stale packet
data has been observed in a reproducible case in a VM on ARM64.

Fix this by using virt_load_acquire() to read the write index,
ensuring that reads of the packet data cannot be reordered
before it. Preventing such reordering is logically correct, and
with this change, getting stale data can no longer be reproduced.

Signed-off-by: Michael Kelley <[email protected]>
Reviewed-by: Andrea Parri (Microsoft) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Wei Liu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/hv/ring_buffer.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 9a03b163cbbd..59f1e64908b1 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -378,7 +378,16 @@ int hv_ringbuffer_read(struct vmbus_channel *channel,
static u32 hv_pkt_iter_avail(const struct hv_ring_buffer_info *rbi)
{
u32 priv_read_loc = rbi->priv_read_index;
- u32 write_loc = READ_ONCE(rbi->ring_buffer->write_index);
+ u32 write_loc;
+
+ /*
+ * The Hyper-V host writes the packet data, then uses
+ * store_release() to update the write_index. Use load_acquire()
+ * here to prevent loads of the packet data from being re-ordered
+ * before the read of the write_index and potentially getting
+ * stale data.
+ */
+ write_loc = virt_load_acquire(&rbi->ring_buffer->write_index);

if (write_loc >= priv_read_loc)
return write_loc - priv_read_loc;
--
2.35.1



2022-04-19 11:26:38

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 32/63] powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit

From: Kefeng Wang <[email protected]>

[ Upstream commit ffa0b64e3be58519ae472ea29a1a1ad681e32f48 ]

mpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000.

Because of the way __pa() works we have:
__pa(0x8000000000000000) == 0, and therefore
virt_to_pfn(0x8000000000000000) == 0, and therefore
virt_addr_valid(0x8000000000000000) == true

Which is wrong, virt_addr_valid() should be false for vmalloc space.
In fact all vmalloc addresses that alias with a valid PFN will return
true from virt_addr_valid(). That can cause bugs with hardened usercopy
as described below by Kefeng Wang:

When running ethtool eth0 on 64-bit Book3E, a BUG occurred:

usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!
kernel BUG at mm/usercopy.c:99
...
usercopy_abort+0x64/0xa0 (unreliable)
__check_heap_object+0x168/0x190
__check_object_size+0x1a0/0x200
dev_ethtool+0x2494/0x2b20
dev_ioctl+0x5d0/0x770
sock_do_ioctl+0xf0/0x1d0
sock_ioctl+0x3ec/0x5a0
__se_sys_ioctl+0xf0/0x160
system_call_exception+0xfc/0x1f0
system_call_common+0xf8/0x200

The code shows below,

data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));
copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))

The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true
on 64-bit Book3E, which leads to the panic.

As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va
and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in
the virt_addr_valid() for 64-bit, also add upper limit check to make
sure the virt is below high_memory.

Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start
of lowmem, high_memory is the upper low virtual address, the check is
suitable for 32-bit, this will fix the issue mentioned in commit
602946ec2f90 ("powerpc: Set max_mapnr correctly") too.

On 32-bit there is a similar problem with high memory, that was fixed in
commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that
commit breaks highmem and needs to be reverted.

We can't easily fix __pa(), we have code that relies on its current
behaviour. So for now add extra checks to virt_addr_valid().

For 64-bit Book3S the extra checks are not necessary, the combination of
virt_to_pfn() and pfn_valid() should yield the correct result, but they
are harmless.

Signed-off-by: Kefeng Wang <[email protected]>
Reviewed-by: Christophe Leroy <[email protected]>
[mpe: Add additional change log detail]
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/powerpc/include/asm/page.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 6ba5adb96a3b..0d8f9246ce15 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -132,7 +132,11 @@ static inline bool pfn_valid(unsigned long pfn)
#define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr))
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)

-#define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr))
+#define virt_addr_valid(vaddr) ({ \
+ unsigned long _addr = (unsigned long)vaddr; \
+ _addr >= PAGE_OFFSET && _addr < (unsigned long)high_memory && \
+ pfn_valid(virt_to_pfn(_addr)); \
+})

/*
* On Book-E parts we need __va to parse the device tree and we can't
--
2.35.1



2022-04-19 11:41:17

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 19/63] drm/amdkfd: Fix Incorrect VMIDs passed to HWS

From: Tushar Patel <[email protected]>

[ Upstream commit b7dfbd2e601f3fee545bc158feceba4f340fe7cf ]

Compute-only GPUs have more than 8 VMIDs allocated to KFD. Fix
this by passing correct number of VMIDs to HWS

v2: squash in warning fix (Alex)

Signed-off-by: Tushar Patel <[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_drv.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 11 +++--------
2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index e8e172010416..ffd754713522 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -633,7 +633,7 @@ MODULE_PARM_DESC(sched_policy,
* Maximum number of processes that HWS can schedule concurrently. The maximum is the
* number of VMIDs assigned to the HWS, which is also the default.
*/
-int hws_max_conc_proc = 8;
+int hws_max_conc_proc = -1;
module_param(hws_max_conc_proc, int, 0444);
MODULE_PARM_DESC(hws_max_conc_proc,
"Max # processes HWS can execute concurrently when sched_policy=0 (0 = no concurrency, #VMIDs for KFD = Maximum(default))");
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index ad9483b9eea3..60ee1a832112 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -609,15 +609,10 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
- kfd->vm_info.first_vmid_kfd + 1;

/* Verify module parameters regarding mapped process number*/
- if ((hws_max_conc_proc < 0)
- || (hws_max_conc_proc > kfd->vm_info.vmid_num_kfd)) {
- dev_err(kfd_device,
- "hws_max_conc_proc %d must be between 0 and %d, use %d instead\n",
- hws_max_conc_proc, kfd->vm_info.vmid_num_kfd,
- kfd->vm_info.vmid_num_kfd);
+ if (hws_max_conc_proc >= 0)
+ kfd->max_proc_per_quantum = min((u32)hws_max_conc_proc, kfd->vm_info.vmid_num_kfd);
+ else
kfd->max_proc_per_quantum = kfd->vm_info.vmid_num_kfd;
- } else
- kfd->max_proc_per_quantum = hws_max_conc_proc;

/* Allocate global GWS that is shared by all KFD processes */
if (hws_gws_support && amdgpu_amdkfd_alloc_gws(kfd->kgd,
--
2.35.1



2022-04-19 13:58:48

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 46/63] ALSA: pcm: Test for "silence" field in struct "pcm_format_data"

From: Fabio M. De Francesco <[email protected]>

commit 2f7a26abb8241a0208c68d22815aa247c5ddacab upstream.

Syzbot reports "KASAN: null-ptr-deref Write in
snd_pcm_format_set_silence".[1]

It is due to missing validation of the "silence" field of struct
"pcm_format_data" in "pcm_formats" array.

Add a test for valid "pat" and, if it is not so, return -EINVAL.

[1] https://lore.kernel.org/lkml/[email protected]/

Reported-and-tested-by: [email protected]
Signed-off-by: Fabio M. De Francesco <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/core/pcm_misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/core/pcm_misc.c
+++ b/sound/core/pcm_misc.c
@@ -423,7 +423,7 @@ int snd_pcm_format_set_silence(snd_pcm_f
return 0;
width = pcm_formats[(INT)format].phys; /* physical width */
pat = pcm_formats[(INT)format].silence;
- if (! width)
+ if (!width || !pat)
return -EINVAL;
/* signed or 1 byte data */
if (pcm_formats[(INT)format].signd == 1 || width <= 8) {


2022-04-19 14:23:09

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 53/63] smp: Fix offline cpu check in flush_smp_call_function_queue()

From: Nadav Amit <[email protected]>

commit 9e949a3886356fe9112c6f6f34a6e23d1d35407f upstream.

The check in flush_smp_call_function_queue() for callbacks that are sent
to offline CPUs currently checks whether the queue is empty.

However, flush_smp_call_function_queue() has just deleted all the
callbacks from the queue and moved all the entries into a local list.
This checks would only be positive if some callbacks were added in the
short time after llist_del_all() was called. This does not seem to be
the intention of this check.

Change the check to look at the local list to which the entries were
moved instead of the queue from which all the callbacks were just
removed.

Fixes: 8d056c48e4862 ("CPU hotplug, smp: flush any pending IPI callbacks before CPU offline")
Signed-off-by: Nadav Amit <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -222,7 +222,7 @@ static void flush_smp_call_function_queu

/* There shouldn't be any pending callbacks on an offline CPU. */
if (unlikely(warn_cpu_offline && !cpu_online(smp_processor_id()) &&
- !warned && !llist_empty(head))) {
+ !warned && entry != NULL)) {
warned = true;
WARN(1, "IPI on offline CPU %d\n", smp_processor_id());



2022-04-19 14:27:25

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 08/63] net/sched: taprio: Check if socket flags are valid

From: Benedikt Spranger <[email protected]>

[ Upstream commit e8a64bbaaad1f6548cec5508297bc6d45e8ab69e ]

A user may set the SO_TXTIME socket option to ensure a packet is send
at a given time. The taprio scheduler has to confirm, that it is allowed
to send a packet at that given time, by a check against the packet time
schedule. The scheduler drop the packet, if the gates are closed at the
given send time.

The check, if SO_TXTIME is set, may fail since sk_flags are part of an
union and the union is used otherwise. This happen, if a socket is not
a full socket, like a request socket for example.

Add a check to verify, if the union is used for sk_flags.

Fixes: 4cfd5779bd6e ("taprio: Add support for txtime-assist mode")
Signed-off-by: Benedikt Spranger <[email protected]>
Reviewed-by: Kurt Kanzenbach <[email protected]>
Acked-by: Vinicius Costa Gomes <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/sched/sch_taprio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index b268e6130451..4c26f7fb32b3 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -427,7 +427,8 @@ static int taprio_enqueue(struct sk_buff *skb, struct Qdisc *sch,
if (unlikely(!child))
return qdisc_drop(skb, sch, to_free);

- if (skb->sk && sock_flag(skb->sk, SOCK_TXTIME)) {
+ /* sk_flags are only safe to use on full sockets. */
+ if (skb->sk && sk_fullsock(skb->sk) && sock_flag(skb->sk, SOCK_TXTIME)) {
if (!is_valid_interval(skb, sch))
return qdisc_drop(skb, sch, to_free);
} else if (TXTIME_ASSIST_IS_ENABLED(q->flags)) {
--
2.35.1



2022-04-19 15:51:13

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 61/63] ax25: fix NPD bug in ax25_disconnect

From: Duoming Zhou <[email protected]>

commit 7ec02f5ac8a5be5a3f20611731243dc5e1d9ba10 upstream.

The ax25_disconnect() in ax25_kill_by_device() is not
protected by any locks, thus there is a race condition
between ax25_disconnect() and ax25_destroy_socket().
when ax25->sk is assigned as NULL by ax25_destroy_socket(),
a NULL pointer dereference bug will occur if site (1) or (2)
dereferences ax25->sk.

ax25_kill_by_device() | ax25_release()
ax25_disconnect() | ax25_destroy_socket()
... |
if(ax25->sk != NULL) | ...
... | ax25->sk = NULL;
bh_lock_sock(ax25->sk); //(1) | ...
... |
bh_unlock_sock(ax25->sk); //(2)|

This patch moves ax25_disconnect() into lock_sock(), which can
synchronize with ax25_destroy_socket() in ax25_release().

Fail log:
===============================================================
BUG: kernel NULL pointer dereference, address: 0000000000000088
...
RIP: 0010:_raw_spin_lock+0x7e/0xd0
...
Call Trace:
ax25_disconnect+0xf6/0x220
ax25_device_event+0x187/0x250
raw_notifier_call_chain+0x5e/0x70
dev_close_many+0x17d/0x230
rollback_registered_many+0x1f1/0x950
unregister_netdevice_queue+0x133/0x200
unregister_netdev+0x13/0x20
...

Signed-off-by: Duoming Zhou <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
[OP: backport to 5.4: adjust context]
Signed-off-by: Ovidiu Panait <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ax25/af_ax25.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -102,8 +102,8 @@ again:
dev_put(ax25_dev->dev);
ax25_dev_put(ax25_dev);
}
- release_sock(sk);
ax25_disconnect(s, ENETUNREACH);
+ release_sock(sk);
spin_lock_bh(&ax25_list_lock);
sock_put(sk);
/* The entry could have been deleted from the


2022-04-19 18:40:35

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 41/63] ath9k: Properly clear TX status area before reporting to mac80211

From: Toke Høiland-Jørgensen <[email protected]>

commit 037250f0a45cf9ecf5b52d4b9ff8eadeb609c800 upstream.

The ath9k driver was not properly clearing the status area in the
ieee80211_tx_info struct before reporting TX status to mac80211. Instead,
it was manually filling in fields, which meant that fields introduced later
were left as-is.

Conveniently, mac80211 actually provides a helper to zero out the status
area, so use that to make sure we zero everything.

The last commit touching the driver function writing the status information
seems to have actually been fixing an issue that was also caused by the
area being uninitialised; but it only added clearing of a single field
instead of the whole struct. That is now redundant, though, so revert that
commit and use it as a convenient Fixes tag.

Fixes: cc591d77aba1 ("ath9k: Make sure to zero status.tx_time before reporting TX status")
Reported-by: Bagas Sanjaya <[email protected]>
Cc: <[email protected]>
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Tested-by: Bagas Sanjaya <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ath/ath9k/xmit.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2509,6 +2509,8 @@ static void ath_tx_rc_status(struct ath_
struct ath_hw *ah = sc->sc_ah;
u8 i, tx_rateindex;

+ ieee80211_tx_info_clear_status(tx_info);
+
if (txok)
tx_info->status.ack_signal = ts->ts_rssi;

@@ -2551,9 +2553,6 @@ static void ath_tx_rc_status(struct ath_
}

tx_info->status.rates[tx_rateindex].count = ts->ts_longretry + 1;
-
- /* we report airtime in ath_tx_count_airtime(), don't report twice */
- tx_info->status.tx_time = 0;
}

static void ath_tx_processq(struct ath_softc *sc, struct ath_txq *txq)


2022-04-20 00:44:29

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/63] 5.4.190-rc1 review

Hi!

> This is the start of the stable review cycle for the 5.4.190 release.
> There are 63 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.

I see that AUTOSEL patches from Apr 11 are in this series, but patches
from Apr 6 are not. Is there story behind that?

Best regards,
Pavel

Apr 6:

4.9 1/7] gfs2: assign rgrp glock before compute_bitstructs
4.9 2/7] um: Cleanup syscall_handler_t definition/cast, fix warning
4.9 3/7] um: port_user: Improve error handling when port-helper is not found
4.9 4/7] Input: add bounds checking to input_set_capability()
4.9 5/7] MIPS: lantiq: check the return value of kzalloc()
4.9 6/7] drbd: remove usage of list iterator variable after loop
4.9 7/7] ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame()

4.19 05/11] Input: stmfts - fix reference leak in stmfts_input_open
4.19 06/11] crypto: stm32 - fix reference leak in stm32_crc_remove
4.19 10/11] nilfs2: fix lockdep warnings in page operations for btree nodes
4.19 11/11] nilfs2: fix lockdep warnings during disk space reclamation

5.10 02/25] rtc: fix use-after-free on device removal
5.10 03/25] rtc: pcf2127: fix bug when reading alarm registers
5.10 08/25] nvme-pci: add quirks for Samsung X5 SSDs
5.10 09/25] gfs2: Disable page faults during lockless buffered reads
5.10 10/25] rtc: sun6i: Fix time overflow handling
5.10 12/25] crypto: x86/chacha20 - Avoid spurious jumps to other functions
5.10 13/25] ALSA: hda/realtek: Enable headset mic on Lenovo P360
5.10 14/25] s390/pci: improve zpci_dev reference counting
5.10 15/25] vhost_vdpa: don't setup irq offloading when irq_num < 0
5.10 16/25] tools/virtio: compile with -pthread
5.10 17/25] nvme-multipath: fix hang when disk goes live over reconnect
5.10 18/25] rtc: mc146818-lib: Fix the AltCentury for AMD platforms
5.10 19/25] fs: fix an infinite loop in iomap_fiemap
5.10 22/25] platform/chrome: cros_ec_debugfs: detach log reader wq from devm

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (2.25 kB)
signature.asc (201.00 B)
Download all attachments

2022-04-20 13:06:46

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/63] 5.4.190-rc1 review



On 4/18/2022 5:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.190 release.
> There are 63 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 20 Apr 2022 12:11: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.4.190-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.4.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

2022-04-20 13:07:28

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/63] 5.4.190-rc1 review

On Mon, 18 Apr 2022 at 18:13, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.4.190 release.
> There are 63 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 20 Apr 2022 12:11: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.4.190-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.4.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.4.190-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.4.y
* git commit: ab55553793398bae2b33694dbbf1b3529c5ac2db
* git describe: v5.4.189-64-gab5555379339
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.189-64-gab5555379339

## Test Regressions (compared to v5.4.188-468-g60d6fdc40ea0)
No test regressions found.

## Metric Regressions (compared to v5.4.188-468-g60d6fdc40ea0)
No metric regressions found.

## Test Fixes (compared to v5.4.188-468-g60d6fdc40ea0)
No test fixes found.

## Metric Fixes (compared to v5.4.188-468-g60d6fdc40ea0)
No metric fixes found.

## Test result summary
total: 88726, pass: 73874, fail: 888, skip: 12818, xfail: 1146

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 290 total, 290 passed, 0 failed
* arm64: 40 total, 34 passed, 6 failed
* i386: 19 total, 19 passed, 0 failed
* mips: 37 total, 37 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 60 total, 54 passed, 6 failed
* riscv: 27 total, 27 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 40 total, 40 passed, 0 failed

## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* 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-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* 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
* perf/Zstd-perf.data-compression
* rcutorture
* ssuite
* v4l2-compliance
* vdso

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

2022-04-20 15:13:25

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 31/63] drm/amd/display: Fix allocate_mst_payload assert on resume

From: Roman Li <[email protected]>

[ Upstream commit f4346fb3edf7720db3f7f5e1cab1f667cd024280 ]

[Why]
On resume we do link detection for all non-MST connectors.
MST is handled separately. However the condition for telling
if connector is on mst branch is not enough for mst hub case.
Link detection for mst branch link leads to mst topology reset.
That causes assert in dc_link_allocate_mst_payload()

[How]
Use link type as indicator for mst link.

Reviewed-by: Wayne Lin <[email protected]>
Acked-by: Alex Hung <[email protected]>
Signed-off-by: Roman Li <[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/amdgpu_dm/amdgpu_dm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c5231c50c412..de33864af70b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1210,7 +1210,8 @@ static int dm_resume(void *handle)
* this is the case when traversing through already created
* MST connectors, should be skipped
*/
- if (aconnector->mst_port)
+ if (aconnector->dc_link &&
+ aconnector->dc_link->type == dc_connection_mst_branch)
continue;

mutex_lock(&aconnector->hpd_lock);
--
2.35.1



2022-04-20 20:17:26

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 12/63] sctp: Initialize daddr on peeled off socket

From: Petr Malat <[email protected]>

[ Upstream commit 8467dda0c26583547731e7f3ea73fc3856bae3bf ]

Function sctp_do_peeloff() wrongly initializes daddr of the original
socket instead of the peeled off socket, which makes getpeername()
return zeroes instead of the primary address. Initialize the new socket
instead.

Fixes: d570ee490fb1 ("[SCTP]: Correctly set daddr for IPv6 sockets during peeloff")
Signed-off-by: Petr Malat <[email protected]>
Acked-by: Marcelo Ricardo Leitner <[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/sctp/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 565aa77fe5cb..c76b40322ac7 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -5682,7 +5682,7 @@ int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id, struct socket **sockp)
* Set the daddr and initialize id to something more random and also
* copy over any ip options.
*/
- sp->pf->to_sk_daddr(&asoc->peer.primary_addr, sk);
+ sp->pf->to_sk_daddr(&asoc->peer.primary_addr, sock->sk);
sp->pf->copy_ip_options(sk, sock->sk);

/* Populate the fields of the newsk from the oldsk and migrate the
--
2.35.1



2022-04-21 10:19:26

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/63] 5.4.190-rc1 review

On 4/18/22 6:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.190 release.
> There are 63 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 20 Apr 2022 12:11: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.4.190-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.4.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

2022-04-21 20:18:39

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/63] 5.4.190-rc1 review

Hi Greg,

On Mon, Apr 18, 2022 at 02:12:57PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.190 release.
> There are 63 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 20 Apr 2022 12:11:14 +0000.
> Anything received after that time might be too late.

Build test:
mips (gcc version 11.2.1 20220314): 65 configs -> no failure
arm (gcc version 11.2.1 20220314): 107 configs -> no new failure
arm64 (gcc version 11.2.1 20220314): 2 configs -> no failure
x86_64 (gcc version 11.2.1 20220314): 4 configs -> no failure

Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]

[1]. https://openqa.qa.codethink.co.uk/tests/1033


Tested-by: Sudip Mukherjee <[email protected]>

--
Regards
Sudip

2022-04-22 07:56:44

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.4 54/63] i2c: pasemi: Wait for write xfers to finish

From: Martin Povišer <[email protected]>

commit bd8963e602c77adc76dbbbfc3417c3cf14fed76b upstream.

Wait for completion of write transfers before returning from the driver.
At first sight it may seem advantageous to leave write transfers queued
for the controller to carry out on its own time, but there's a couple of
issues with it:

* Driver doesn't check for FIFO space.

* The queued writes can complete while the driver is in its I2C read
transfer path which means it will get confused by the raising of
XEN (the 'transaction ended' signal). This can cause a spurious
ENODATA error due to premature reading of the MRXFIFO register.

Adding the wait fixes some unreliability issues with the driver. There's
some efficiency cost to it (especially with pasemi_smb_waitready doing
its polling), but that will be alleviated once the driver receives
interrupt support.

Fixes: beb58aa39e6e ("i2c: PA Semi SMBus driver")
Signed-off-by: Martin Povišer <[email protected]>
Reviewed-by: Sven Peter <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/busses/i2c-pasemi.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/drivers/i2c/busses/i2c-pasemi.c
+++ b/drivers/i2c/busses/i2c-pasemi.c
@@ -137,6 +137,12 @@ static int pasemi_i2c_xfer_msg(struct i2

TXFIFO_WR(smbus, msg->buf[msg->len-1] |
(stop ? MTXFIFO_STOP : 0));
+
+ if (stop) {
+ err = pasemi_smb_waitready(smbus);
+ if (err)
+ goto reset_out;
+ }
}

return 0;


2022-04-22 14:42:45

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/63] 5.4.190-rc1 review

On Mon, Apr 18, 2022 at 02:12:57PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.190 release.
> There are 63 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 20 Apr 2022 12:11:14 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 449 pass: 449 fail: 0

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

Guenter