2021-04-09 10:00:07

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 00/18] 4.19.186-rc1 review

This is the start of the stable review cycle for the 4.19.186 release.
There are 18 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 Sun, 11 Apr 2021 09:52:52 +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/v4.x/stable-review/patch-4.19.186-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-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Masahiro Yamada <[email protected]>
init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM

Heiko Carstens <[email protected]>
init/Kconfig: make COMPILE_TEST depend on !S390

Piotr Krysiuk <[email protected]>
bpf, x86: Validate computation of branch displacements for x86-32

Piotr Krysiuk <[email protected]>
bpf, x86: Validate computation of branch displacements for x86-64

Vincent Whitchurch <[email protected]>
cifs: Silently ignore unknown oplock break handle

Ronnie Sahlberg <[email protected]>
cifs: revalidate mapping when we open files for SMB1 POSIX

Sergei Trofimovich <[email protected]>
ia64: fix format strings for err_inject

Sergei Trofimovich <[email protected]>
ia64: mca: allocate early mca with GFP_ATOMIC

Martin Wilck <[email protected]>
scsi: target: pscsi: Clean up after failure in pscsi_map_sg()

Arnd Bergmann <[email protected]>
x86/build: Turn off -fcf-protection for realmode targets

Esteve Varela Colominas <[email protected]>
platform/x86: thinkpad_acpi: Allow the FnLock LED to change state

Rob Clark <[email protected]>
drm/msm: Ratelimit invalid-fence message

Karthikeyan Kathirvel <[email protected]>
mac80211: choose first enabled channel for monitor

Tong Zhang <[email protected]>
mISDN: fix crash in fritzpci

Pavel Andrianov <[email protected]>
net: pxa168_eth: Fix a potential data race in pxa168_eth_remove

Alban Bedel <[email protected]>
platform/x86: intel-hid: Support Lenovo ThinkPad X1 Tablet Gen 2

Tony Lindgren <[email protected]>
bus: ti-sysc: Fix warning on unbind if reset is not deasserted

Mans Rullgard <[email protected]>
ARM: dts: am33xx: add aliases for mmc interfaces


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

Diffstat:

Makefile | 4 ++--
arch/arm/boot/dts/am33xx.dtsi | 3 +++
arch/ia64/kernel/err_inject.c | 22 +++++++++++-----------
arch/ia64/kernel/mca.c | 2 +-
arch/x86/Makefile | 2 +-
arch/x86/net/bpf_jit_comp.c | 11 ++++++++++-
arch/x86/net/bpf_jit_comp32.c | 11 ++++++++++-
drivers/bus/ti-sysc.c | 4 +++-
drivers/gpu/drm/msm/msm_fence.c | 2 +-
drivers/isdn/hardware/mISDN/mISDNipac.c | 2 +-
drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
drivers/platform/x86/intel-hid.c | 7 +++++++
drivers/platform/x86/thinkpad_acpi.c | 8 +++++++-
drivers/target/target_core_pscsi.c | 8 ++++++++
fs/cifs/file.c | 1 +
fs/cifs/smb2misc.c | 4 ++--
init/Kconfig | 3 +--
net/mac80211/main.c | 13 ++++++++++++-
18 files changed, 82 insertions(+), 27 deletions(-)



2021-04-09 10:00:13

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 14/18] cifs: Silently ignore unknown oplock break handle

From: Vincent Whitchurch <[email protected]>

[ Upstream commit 219481a8f90ec3a5eed9638fb35609e4b1aeece7 ]

Make SMB2 not print out an error when an oplock break is received for an
unknown handle, similar to SMB1. The debug message which is printed for
these unknown handles may also be misleading, so fix that too.

The SMB2 lease break path is not affected by this patch.

Without this, a program which writes to a file from one thread, and
opens, reads, and writes the same file from another thread triggers the
below errors several times a minute when run against a Samba server
configured with "smb2 leases = no".

CIFS: VFS: \\192.168.0.1 No task to wake, unknown frame received! NumMids 2
00000000: 424d53fe 00000040 00000000 00000012 .SMB@...........
00000010: 00000001 00000000 ffffffff ffffffff ................
00000020: 00000000 00000000 00000000 00000000 ................
00000030: 00000000 00000000 00000000 00000000 ................

Signed-off-by: Vincent Whitchurch <[email protected]>
Reviewed-by: Tom Talpey <[email protected]>
Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/cifs/smb2misc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c
index 7d875a47d022..7177720e822e 100644
--- a/fs/cifs/smb2misc.c
+++ b/fs/cifs/smb2misc.c
@@ -738,8 +738,8 @@ smb2_is_valid_oplock_break(char *buffer, struct TCP_Server_Info *server)
}
}
spin_unlock(&cifs_tcp_ses_lock);
- cifs_dbg(FYI, "Can not process oplock break for non-existent connection\n");
- return false;
+ cifs_dbg(FYI, "No file id matched, oplock break ignored\n");
+ return true;
}

void
--
2.30.2



2021-04-09 10:00:47

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 04/18] net: pxa168_eth: Fix a potential data race in pxa168_eth_remove

From: Pavel Andrianov <[email protected]>

[ Upstream commit 0571a753cb07982cc82f4a5115e0b321da89e1f3 ]

pxa168_eth_remove() firstly calls unregister_netdev(),
then cancels a timeout work. unregister_netdev() shuts down a device
interface and removes it from the kernel tables. If the timeout occurs
in parallel, the timeout work (pxa168_eth_tx_timeout_task) performs stop
and open of the device. It may lead to an inconsistent state and memory
leaks.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Pavel Andrianov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
index ff2fea0f8b75..0d6a4e47e7a5 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -1564,8 +1564,8 @@ static int pxa168_eth_remove(struct platform_device *pdev)

mdiobus_unregister(pep->smi_bus);
mdiobus_free(pep->smi_bus);
- unregister_netdev(dev);
cancel_work_sync(&pep->tx_timeout_task);
+ unregister_netdev(dev);
free_netdev(dev);
return 0;
}
--
2.30.2



2021-04-09 10:01:00

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 07/18] drm/msm: Ratelimit invalid-fence message

From: Rob Clark <[email protected]>

[ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ]

We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't lose the kernel traces leading up to this.

Signed-off-by: Rob Clark <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/msm/msm_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c
index 349c12f670eb..6c11be79574e 100644
--- a/drivers/gpu/drm/msm/msm_fence.c
+++ b/drivers/gpu/drm/msm/msm_fence.c
@@ -56,7 +56,7 @@ int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence,
int ret;

if (fence > fctx->last_fence) {
- DRM_ERROR("%s: waiting on invalid fence: %u (of %u)\n",
+ DRM_ERROR_RATELIMITED("%s: waiting on invalid fence: %u (of %u)\n",
fctx->name, fence, fctx->last_fence);
return -EINVAL;
}
--
2.30.2



2021-04-09 10:01:08

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 06/18] mac80211: choose first enabled channel for monitor

From: Karthikeyan Kathirvel <[email protected]>

[ Upstream commit 041c881a0ba8a75f71118bd9766b78f04beed469 ]

Even if the first channel from sband channel list is invalid
or disabled mac80211 ends up choosing it as the default channel
for monitor interfaces, making them not usable.

Fix this by assigning the first available valid or enabled
channel instead.

Signed-off-by: Karthikeyan Kathirvel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[reword commit message, comment, code cleanups]
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/mac80211/main.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 68db2a356443..f44d00f35fe7 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -931,8 +931,19 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
continue;

if (!dflt_chandef.chan) {
+ /*
+ * Assign the first enabled channel to dflt_chandef
+ * from the list of channels
+ */
+ for (i = 0; i < sband->n_channels; i++)
+ if (!(sband->channels[i].flags &
+ IEEE80211_CHAN_DISABLED))
+ break;
+ /* if none found then use the first anyway */
+ if (i == sband->n_channels)
+ i = 0;
cfg80211_chandef_create(&dflt_chandef,
- &sband->channels[0],
+ &sband->channels[i],
NL80211_CHAN_NO_HT);
/* init channel we're on */
if (!local->use_chanctx && !local->_oper_chandef.chan) {
--
2.30.2



2021-04-09 10:01:14

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 08/18] platform/x86: thinkpad_acpi: Allow the FnLock LED to change state

From: Esteve Varela Colominas <[email protected]>

[ Upstream commit 3d677f12ea3a2097a16ded570623567403dea959 ]

On many recent ThinkPad laptops, there's a new LED next to the ESC key,
that indicates the FnLock status.
When the Fn+ESC combo is pressed, FnLock is toggled, which causes the
Media Key functionality to change, making it so that the media keys
either perform their media key function, or function as an F-key by
default. The Fn key can be used the access the alternate function at any
time.

With the current linux kernel, the LED doens't change state if you press
the Fn+ESC key combo. However, the media key functionality *does*
change. This is annoying, since the LED will stay on if it was on during
bootup, and it makes it hard to keep track what the current state of the
FnLock is.

This patch calls an ACPI function, that gets the current media key
state, when the Fn+ESC key combo is pressed. Through testing it was
discovered that this function causes the LED to update correctly to
reflect the current state when this function is called.

The relevant ACPI calls are the following:
\_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key state, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled.
\_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key state, sending a 1 will enable FnLock mode, and a 0 will disable it.

Relevant discussion:
https://bugzilla.kernel.org/show_bug.cgi?id=207841
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015

Signed-off-by: Esteve Varela Colominas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/platform/x86/thinkpad_acpi.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index a6e69f2495d2..559698640fe2 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -4102,13 +4102,19 @@ static bool hotkey_notify_6xxx(const u32 hkey,

case TP_HKEY_EV_KEY_NUMLOCK:
case TP_HKEY_EV_KEY_FN:
- case TP_HKEY_EV_KEY_FN_ESC:
/* key press events, we just ignore them as long as the EC
* is still reporting them in the normal keyboard stream */
*send_acpi_ev = false;
*ignore_acpi_ev = true;
return true;

+ case TP_HKEY_EV_KEY_FN_ESC:
+ /* Get the media key status to foce the status LED to update */
+ acpi_evalf(hkey_handle, NULL, "GMKS", "v");
+ *send_acpi_ev = false;
+ *ignore_acpi_ev = true;
+ return true;
+
case TP_HKEY_EV_TABLET_CHANGED:
tpacpi_input_send_tabletsw();
hotkey_tablet_mode_notify_change();
--
2.30.2



2021-04-09 20:17:10

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/18] 4.19.186-rc1 review

On Fri, Apr 09, 2021 at 11:53:28AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.186 release.
> There are 18 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 Sun, 11 Apr 2021 09:52:52 +0000.
> Anything received after that time might be too late.
>

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

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

Guenter

2021-04-09 20:57:19

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/18] 4.19.186-rc1 review

On 4/9/21 3:53 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.186 release.
> There are 18 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 Sun, 11 Apr 2021 09:52:52 +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/v4.x/stable-review/patch-4.19.186-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-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

I am seeing a new warn - will debug later on today and let you know
what I find:


WARNING: CPU: 9 PID: 0 at drivers/net/wireless/ath/ath10k/htt_rx.c:46
ath10k_htt_rx_pop_paddr+0xde/0x100 [ath10k_core]
Modules linked in: cmac algif_hash algif_skcipher af_alg bnep arc4
nls_iso8859_1 wmi_bmof snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_codec_hdmi edac_mce_amd snd_hda_intel snd_hda_codec kvm_amd
snd_hda_core ccp snd_hwdep kvm snd_pcm snd_seq_midi crct10dif_pclmul
snd_seq_midi_event ghash_clmulni_intel pcbc snd_rawmidi ath10k_pci
snd_seq ath10k_core aesni_intel ath snd_seq_device rtsx_usb_ms btusb
aes_x86_64 snd_timer crypto_simd btrtl cryptd joydev btbcm glue_helper
memstick mac80211 snd btintel input_leds bluetooth soundcore cfg80211
ecdh_generic video wmi mac_hid sch_fq_codel parport_pc ppdev lp parport
drm ip_tables x_tables autofs4 hid_generic rtsx_usb_sdmmc usbhid
rtsx_usb hid crc32_pclmul uas i2c_piix4 r8169 ahci realtek usb_storage
libahci gpio_amdpt gpio_generic
CPU: 9 PID: 0 Comm: swapper/9 Not tainted 4.19.186-rc1+ #24
Hardware name: LENOVO 90Q30008US/3728, BIOS O4ZKT1CA 09/16/2020
RIP: 0010:ath10k_htt_rx_pop_paddr+0xde/0x100 [ath10k_core]
Code: 02 00 00 48 85 c9 74 30 4c 8b 49 28 4d 85 c9 74 1e 48 8b 30 45 31
c0 b9 02 00 00 00 e8 9b 27 ca cc 4c 89 e0 4c 8b 65 f8 c9 c3 <0f> 0b 45
31 e4 4c 89 e0 4c 8b 65 f8 c9 c3 48 8b 0d 1d df 4c cd eb
RSP: 0018:ffff8d81bf043da0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8d81927b2150 RCX: ffff8d81b8c01580
RDX: 0000000000000008 RSI: 00000000ff708a80 RDI: ffff8d81b8c01e78
RBP: ffff8d81bf043da8 R08: 0000000000200000 R09: 0000000000000000
R10: ffffdd1f0f40f300 R11: 000ffffffffff000 R12: ffff8d81b8c02068
R13: ffff8d81b8c01580 R14: ffff8d81927b2148 R15: ffff8d81b8c01580
FS: 0000000000000000(0000) GS:ffff8d81bf040000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055a2c99a2000 CR3: 00000003de8d4000 CR4: 0000000000340ee0
Call Trace:
<IRQ>
ath10k_htt_txrx_compl_task+0x58d/0xe70 [ath10k_core]
ath10k_pci_napi_poll+0x52/0x110 [ath10k_pci]
net_rx_action+0x13c/0x350
__do_softirq+0xd4/0x2ae
irq_exit+0x9c/0xe0
do_IRQ+0x86/0xe0
common_interrupt+0xf/0xf
</IRQ>
RIP: 0010:cpuidle_enter_state+0x10b/0x2c0
Code: ff e8 f9 68 85 ff 80 7d c7 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02
0f 85 97 01 00 00 31 ff e8 6c 5d 8b ff fb 66 0f 1f 44 00 00 <48> b8 ff
ff ff ff f3 01 00 00 4c 2b 7d c8 ba ff ff ff 7f 49 39 c7
RSP: 0018:ffffb11e01a77e50 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffda
RAX: ffff8d81bf0626c0 RBX: ffff8d81b2690400 RCX: 00000006e8cb49d2
RDX: 0000000000000689 RSI: 00000006e8cb49d2 RDI: 0000000000000000
RBP: ffffb11e01a77e90 R08: 00000006e8cb505b R09: 0000000000000e29
R10: 0000000000000f04 R11: ffff8d81bf061528 R12: 0000000000000003
R13: ffffffff8df9e860 R14: ffffffff8df9e980 R15: 00000006e8cb505b
cpuidle_enter+0x17/0x20

thanks,
-- Shuah

2021-04-10 09:08:49

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/18] 4.19.186-rc1 review

On Fri, 9 Apr 2021 at 15:27, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.186 release.
> There are 18 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 Sun, 11 Apr 2021 09:52:52 +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/v4.x/stable-review/patch-4.19.186-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-4.19.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: 4.19.186-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.19.y
* git commit: 6aba908ea95f2196c499c922cfae662412d5040a
* git describe: v4.19.185-19-g6aba908ea95f
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.185-19-g6aba908ea95f

## No regressions (compared to v4.19.185)

## No fixes (compared to v4.19.185)

## Test result summary
total: 67843, pass: 55043, fail: 1811, skip: 10773, xfail: 216,

## Build Summary
* arm: 96 total, 96 passed, 0 failed
* arm64: 24 total, 24 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 14 total, 13 passed, 1 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 39 total, 39 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 15 total, 14 passed, 1 failed

## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest-
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* 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-vsyscall-mode-native-
* kselftest-vsyscall-mode-none-
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* 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
* perf
* rcutorture
* ssuite
* v4l2-compliance

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

2021-04-10 11:25:28

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/18] 4.19.186-rc1 review

On Fri, Apr 09, 2021 at 02:55:16PM -0600, Shuah Khan wrote:
> On 4/9/21 3:53 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.186 release.
> > There are 18 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 Sun, 11 Apr 2021 09:52:52 +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/v4.x/stable-review/patch-4.19.186-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-4.19.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> I am seeing a new warn - will debug later on today and let you know
> what I find:
>
>
> WARNING: CPU: 9 PID: 0 at drivers/net/wireless/ath/ath10k/htt_rx.c:46
> ath10k_htt_rx_pop_paddr+0xde/0x100 [ath10k_core]
> Modules linked in: cmac algif_hash algif_skcipher af_alg bnep arc4
> nls_iso8859_1 wmi_bmof snd_hda_codec_realtek snd_hda_codec_generic
> snd_hda_codec_hdmi edac_mce_amd snd_hda_intel snd_hda_codec kvm_amd
> snd_hda_core ccp snd_hwdep kvm snd_pcm snd_seq_midi crct10dif_pclmul
> snd_seq_midi_event ghash_clmulni_intel pcbc snd_rawmidi ath10k_pci snd_seq
> ath10k_core aesni_intel ath snd_seq_device rtsx_usb_ms btusb aes_x86_64
> snd_timer crypto_simd btrtl cryptd joydev btbcm glue_helper memstick
> mac80211 snd btintel input_leds bluetooth soundcore cfg80211 ecdh_generic
> video wmi mac_hid sch_fq_codel parport_pc ppdev lp parport drm ip_tables
> x_tables autofs4 hid_generic rtsx_usb_sdmmc usbhid rtsx_usb hid crc32_pclmul
> uas i2c_piix4 r8169 ahci realtek usb_storage libahci gpio_amdpt gpio_generic
> CPU: 9 PID: 0 Comm: swapper/9 Not tainted 4.19.186-rc1+ #24
> Hardware name: LENOVO 90Q30008US/3728, BIOS O4ZKT1CA 09/16/2020
> RIP: 0010:ath10k_htt_rx_pop_paddr+0xde/0x100 [ath10k_core]
> Code: 02 00 00 48 85 c9 74 30 4c 8b 49 28 4d 85 c9 74 1e 48 8b 30 45 31 c0
> b9 02 00 00 00 e8 9b 27 ca cc 4c 89 e0 4c 8b 65 f8 c9 c3 <0f> 0b 45 31 e4 4c
> 89 e0 4c 8b 65 f8 c9 c3 48 8b 0d 1d df 4c cd eb
> RSP: 0018:ffff8d81bf043da0 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff8d81927b2150 RCX: ffff8d81b8c01580
> RDX: 0000000000000008 RSI: 00000000ff708a80 RDI: ffff8d81b8c01e78
> RBP: ffff8d81bf043da8 R08: 0000000000200000 R09: 0000000000000000
> R10: ffffdd1f0f40f300 R11: 000ffffffffff000 R12: ffff8d81b8c02068
> R13: ffff8d81b8c01580 R14: ffff8d81927b2148 R15: ffff8d81b8c01580
> FS: 0000000000000000(0000) GS:ffff8d81bf040000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055a2c99a2000 CR3: 00000003de8d4000 CR4: 0000000000340ee0
> Call Trace:
> <IRQ>
> ath10k_htt_txrx_compl_task+0x58d/0xe70 [ath10k_core]
> ath10k_pci_napi_poll+0x52/0x110 [ath10k_pci]
> net_rx_action+0x13c/0x350
> __do_softirq+0xd4/0x2ae
> irq_exit+0x9c/0xe0
> do_IRQ+0x86/0xe0
> common_interrupt+0xf/0xf
> </IRQ>
> RIP: 0010:cpuidle_enter_state+0x10b/0x2c0
> Code: ff e8 f9 68 85 ff 80 7d c7 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f
> 85 97 01 00 00 31 ff e8 6c 5d 8b ff fb 66 0f 1f 44 00 00 <48> b8 ff ff ff ff
> f3 01 00 00 4c 2b 7d c8 ba ff ff ff 7f 49 39 c7
> RSP: 0018:ffffb11e01a77e50 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffda
> RAX: ffff8d81bf0626c0 RBX: ffff8d81b2690400 RCX: 00000006e8cb49d2
> RDX: 0000000000000689 RSI: 00000006e8cb49d2 RDI: 0000000000000000
> RBP: ffffb11e01a77e90 R08: 00000006e8cb505b R09: 0000000000000e29
> R10: 0000000000000f04 R11: ffff8d81bf061528 R12: 0000000000000003
> R13: ffffffff8df9e860 R14: ffffffff8df9e980 R15: 00000006e8cb505b
> cpuidle_enter+0x17/0x20
>

Odd, there's no ath10k changes in here, only one wireless core change.
Bisection would be great if you can do that, thanks!

greg k-h