4.19.186-rc1 review
Greg Kroah-Hartman
maintainercover 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(-)
Greg Kroah-Hartman
maintainerPATCH 1/18 ARM: dts: am33xx: add aliases for mmc interfaces
From: Mans Rullgard <[email protected]>
[ Upstream commit 9bbce32a20d6a72c767a7f85fd6127babd1410ac ]
Without DT aliases, the numbering of mmc interfaces is unpredictable. Adding them makes it possible to refer to devices consistently. The popular suggestion to use UUIDs obviously doesn't work with a blank device fresh from the factory.
See commit fa2d0aa96941 ("mmc: core: Allow setting slot index via device tree alias") for more discussion.
--- arch/arm/boot/dts/am33xx.dtsi | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/boot/dts/am33xx.dtsi +3 -0
@@ -39,6 +39,9 @@ aliases { ethernet1 = &cpsw_emac1; spi0 = &spi0; spi1 = &spi1; + mmc0 = &mmc1; + mmc1 = &mmc2; + mmc2 = &mmc3; }; cpus {
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 2/18 bus: ti-sysc: Fix warning on unbind if reset is not deasserted
In reply to Greg Kroah-HartmanFrom: Tony Lindgren <[email protected]>
[ Upstream commit a7b5d7c4969aba8d1f04c29048906abaa71fb6a9 ]
We currently get thefollowing on driver unbind if a reset is configured and asserted:
WARNING: CPU: 0 PID: 993 at drivers/reset/core.c:432 reset_control_assert
...
(reset_control_assert) from [<c0fecda8>] (sysc_remove+0x190/0x1e4) (sysc_remove) from [<c0a2bb58>] (platform_remove+0x24/0x3c) (platform_remove) from [<c0a292fc>] (__device_release_driver+0x154/0x214) (__device_release_driver) from [<c0a2a210>] (device_driver_detach+0x3c/0x8c) (device_driver_detach) from [<c0a27d64>] (unbind_store+0x60/0xd4) (unbind_store) from [<c0546bec>] (kernfs_fop_write_iter+0x10c/0x1cc)
Let's fix it by checking the reset status.
--- drivers/bus/ti-sysc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/bus/ti-sysc.c +3 -1
@@ -1814,7 +1814,9 @@ static int sysc_remove(struct platform_device *pdev)pm_runtime_put_sync (&pdev->dev);pm_runtime_disable (&pdev->dev); -reset_control_assert (ddata->rsts); + +if (!reset_control_status (ddata->rsts)) +reset_control_assert (ddata->rsts); unprepare:sysc_unprepare (ddata);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 3/18 platform/x86: intel-hid: Support Lenovo ThinkPad X1 Tablet Gen 2
In reply to Greg Kroah-HartmanFrom: Alban Bedel <[email protected]>
[ Upstream commit 56678a5f44ef5f0ad9a67194bbee2280c6286534 ]
Like a few other system the Lenovo ThinkPad X1 Tablet Gen 2 miss the HEBC method, which prevent the power button from working. Add a quirk to enable the button array on this system family and fix the power button.
--- drivers/platform/x86/intel-hid.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/platform/x86/intel-hid.c +7 -0
@@ -94,6 +94,13 @@ static const struct dmi_system_id button_array_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "HP Spectre x2 Detachable"), }, }, + { + .ident = "Lenovo ThinkPad X1 Tablet Gen 2", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_FAMILY, "ThinkPad X1 Tablet Gen 2"), + }, + }, { } };
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 4/18 net: pxa168_eth: Fix a potential data race in pxa168_eth_remove
In reply to Greg Kroah-HartmanFrom: 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).
--- drivers/net/ethernet/marvell/pxa168_eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/marvell/pxa168_eth.c +1 -1
@@ -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 ; }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 5/18 mISDN: fix crash in fritzpci
In reply to Greg Kroah-HartmanFrom: Tong Zhang <[email protected]>
[ Upstream commit a9f81244d2e33e6dfcef120fefd30c96b3f7cdb0 ]
setup_fritz() in avmfritz.c might fail with -EIO and in this case the isac.type and isac.write_reg is not initialized and remains 0(NULL). A subsequent call to isac_release() will dereference isac->write_reg and crash.
[ 1.737444] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.737809] #PF: supervisor instruction fetch in kernel mode [ 1.738106] #PF: error_code(0x0010) - not-present page [ 1.738378] PGD 0 P4D 0 [ 1.738515] Oops: 0010 [#1] SMP NOPTI [ 1.738711] CPU: 0 PID: 180 Comm: systemd-udevd Not tainted 5.12.0-rc2+ #78 [ 1.739077] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-p rebuilt.qemu.org 04/01/2014 [ 1.739664] RIP: 0010:0x0 [ 1.739807] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [ 1.740200] RSP: 0018:ffffc9000027ba10 EFLAGS: 00010202 [ 1.740478] RAX: 0000000000000000 RBX: ffff888102f41840 RCX: 0000000000000027 [ 1.740853] RDX: 00000000000000ff RSI: 0000000000000020 RDI: ffff888102f41800 [ 1.741226] RBP: ffffc9000027ba20 R08: ffff88817bc18440 R09: ffffc9000027b808 [ 1.741600] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888102f41840 [ 1.741976] R13: 00000000fffffffb R14: ffff888102f41800 R15: ffff8881008b0000 [ 1.742351] FS: 00007fda3a38a8c0(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 [ 1.742774] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.743076] CR2: ffffffffffffffd6 CR3: 00000001021ec000 CR4: 00000000000006f0 [ 1.743452] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1.743828] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1.744206] Call Trace: [ 1.744339] isac_release+0xcc/0xe0 [mISDNipac] [ 1.744582] fritzpci_probe.cold+0x282/0x739 [avmfritz] [ 1.744861] local_pci_probe+0x48/0x80 [ 1.745063] pci_device_probe+0x10f/0x1c0 [ 1.745278] really_probe+0xfb/0x420 [ 1.745471] driver_probe_device+0xe9/0x160 [ 1.745693] device_driver_attach+0x5d/0x70 [ 1.745917] __driver_attach+0x8f/0x150 [ 1.746123] ? device_driver_attach+0x70/0x70 [ 1.746354] bus_for_each_dev+0x7e/0xc0 [ 1.746560] driver_attach+0x1e/0x20 [ 1.746751] bus_add_driver+0x152/0x1f0 [ 1.746957] driver_register+0x74/0xd0 [ 1.747157] ? 0xffffffffc00d8000 [ 1.747334] __pci_register_driver+0x54/0x60 [ 1.747562] AVM_init+0x36/0x1000 [avmfritz] [ 1.747791] do_one_initcall+0x48/0x1d0 [ 1.747997] ? __cond_resched+0x19/0x30 [ 1.748206] ? kmem_cache_alloc_trace+0x390/0x440 [ 1.748458] ? do_init_module+0x28/0x250 [ 1.748669] do_init_module+0x62/0x250 [ 1.748870] load_module+0x23ee/0x26a0 [ 1.749073] __do_sys_finit_module+0xc2/0x120 [ 1.749307] ? __do_sys_finit_module+0xc2/0x120 [ 1.749549] __x64_sys_finit_module+0x1a/0x20 [ 1.749782] do_syscall_64+0x38/0x90
--- drivers/isdn/hardware/mISDN/mISDNipac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/isdn/hardware/mISDN/mISDNipac.c +1 -1
@@ -710,7 +710,7 @@ isac_release(struct isac_hw *isac) {if (isac->type &IPAC_TYPE_ISACX )WriteISAC (isac,ISACX_MASK ,0xff ); -else +else if (isac->type !=0 )WriteISAC (isac,ISAC_MASK ,0xff );if (isac->dch.timer.function !=NULL ) {del_timer (&isac->dch.timer);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 6/18 mac80211: choose first enabled channel for monitor
In reply to Greg Kroah-HartmanFrom: 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.
--- net/mac80211/main.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
net/mac80211/main.c +12 -1
@@ -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) {
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 7/18 drm/msm: Ratelimit invalid-fence message
In reply to Greg Kroah-HartmanFrom: 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.
--- drivers/gpu/drm/msm/msm_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/msm/msm_fence.c +1 -1
@@ -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 ; }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 8/18 platform/x86: thinkpad_acpi: Allow the FnLock LED to change state
In reply to Greg Kroah-HartmanFrom: 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
--- drivers/platform/x86/thinkpad_acpi.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/platform/x86/thinkpad_acpi.c +7 -1
@@ -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 ();
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 9/18 x86/build: Turn off -fcf-protection for realmode targets
In reply to Greg Kroah-HartmanFrom: Arnd Bergmann <[email protected]>
[ Upstream commit 9fcb51c14da2953de585c5c6e50697b8a6e91a7b ]
The new Ubuntu GCC packages turn on -fcf-protection globally, which causes a build failure in the x86 realmode code:
cc1: error: ‘-fcf-protection’ is not compatible with this target
Turn it off explicitly on compilers that understand this option.
--- arch/x86/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/Makefile +1 -1
@@ -34,7 +34,7 @@ M16_CFLAGS := $(call cc-option, -m16, $(CODE16GCC_CFLAGS)) REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os -DDISABLE_BRANCH_PROFILING \ -Wall -Wstrict-prototypes -march=i386 -mregparm=3 \ -fno-strict-aliasing -fomit-frame-pointer -fno-pic \ - -mno-mmx -mno-sse + -mno-mmx -mno-sse $(call cc-option,-fcf-protection=none) REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -ffreestanding) REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -fno-stack-protector)
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 10/18 scsi: target: pscsi: Clean up after failure in pscsi_map_sg()
In reply to Greg Kroah-HartmanFrom: Martin Wilck <[email protected]>
[ Upstream commit 36fa766faa0c822c860e636fe82b1affcd022974 ]
If pscsi_map_sg() fails, make sure to drop references to already allocated bios.
--- drivers/target/target_core_pscsi.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/target/target_core_pscsi.c +8 -0
@@ -970,6 +970,14 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents,return 0 ; fail: +if (bio) +bio_put (bio); +while (req->bio) { + bio = req->bio; + req->bio = bio->bi_next; +bio_put (bio); + } + req->biotail =NULL ;return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE ; }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 11/18 ia64: mca: allocate early mca with GFP_ATOMIC
In reply to Greg Kroah-HartmanFrom: Sergei Trofimovich <[email protected]>
[ Upstream commit f2a419cf495f95cac49ea289318b833477e1a0e2 ]
The sleep warning happens at early boot right at secondary CPU activation bootup:
smp: Bringing up secondary CPUs ...
BUG: sleeping function called from invalid context at mm/page_alloc.c:4942
in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.12.0-rc2-00007-g79e228d0b611-dirty #99
..
Call Trace:
show_stack+0x90/0xc0
dump_stack+0x150/0x1c0
___might_sleep+0x1c0/0x2a0
__might_sleep+0xa0/0x160
__alloc_pages_nodemask+0x1a0/0x600
alloc_page_interleave+0x30/0x1c0
alloc_pages_current+0x2c0/0x340
__get_free_pages+0x30/0xa0
ia64_mca_cpu_init+0x2d0/0x3a0
cpu_init+0x8b0/0x1440
start_secondary+0x60/0x700
start_ap+0x750/0x780
Fixed BSP b0 value from CPU 1As I understand interrupts are not enabled yet and system has a lot of memory. There is little chance to sleep and switch to GFP_ATOMIC should be a no-op.
--- arch/ia64/kernel/mca.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/ia64/kernel/mca.c +1 -1
@@ -1860,7 +1860,7 @@ ia64_mca_cpu_init(void *cpu_data) data =mca_bootmem (); first_time =0 ; }else - data = (void *)__get_free_pages (GFP_KERNEL , + data = (void *)__get_free_pages (GFP_ATOMIC ,get_order (sz));if (!data) panic("Could not allocate MCA memory for cpu %d\n",
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 12/18 ia64: fix format strings for err_inject
In reply to Greg Kroah-HartmanFrom: Sergei Trofimovich <[email protected]>
[ Upstream commit 95d44a470a6814207d52dd6312203b0f4ef12710 ]
Fix warning with %lx / u64 mismatch:
arch/ia64/kernel/err_inject.c: In function 'show_resources':
arch/ia64/kernel/err_inject.c:62:22: warning:
format '%lx' expects argument of type 'long unsigned int',
but argument 3 has type 'u64' {aka 'long long unsigned int'}
62 | return sprintf(buf, "%lx", name[cpu]); \
| ^~~~~~~--- arch/ia64/kernel/err_inject.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
arch/ia64/kernel/err_inject.c +11 -11
@@ -59,7 +59,7 @@ show_##name(struct device *dev, struct device_attribute *attr, \ char *buf) \ { \u32 cpu=dev->id; \ -return sprintf (buf,"%lx\n" , name[cpu]); \ +return sprintf (buf,"%llx\n" , name[cpu]); \ }#define store (name) \
@@ -86,9 +86,9 @@ store_call_start(struct device *dev, struct device_attribute *attr,#ifdef ERR_INJ_DEBUG printk (KERN_DEBUG "pal_mc_err_inject for cpu%d:\n" , cpu); -printk (KERN_DEBUG "err_type_info=%lx,\n" , err_type_info[cpu]); -printk (KERN_DEBUG "err_struct_info=%lx,\n" , err_struct_info[cpu]); -printk (KERN_DEBUG "err_data_buffer=%lx, %lx, %lx.\n" , +printk (KERN_DEBUG "err_type_info=%llx,\n" , err_type_info[cpu]); +printk (KERN_DEBUG "err_struct_info=%llx,\n" , err_struct_info[cpu]); +printk (KERN_DEBUG "err_data_buffer=%llx, %llx, %llx.\n" , err_data_buffer[cpu].data1, err_data_buffer[cpu].data2, err_data_buffer[cpu].data3);
@@ -117,8 +117,8 @@ store_call_start(struct device *dev, struct device_attribute *attr,#ifdef ERR_INJ_DEBUG printk (KERN_DEBUG "Returns: status=%d,\n" , (int )status[cpu]); -printk (KERN_DEBUG "capabilities=%lx,\n" , capabilities[cpu]); -printk (KERN_DEBUG "resources=%lx\n" , resources[cpu]); +printk (KERN_DEBUG "capabilities=%llx,\n" , capabilities[cpu]); +printk (KERN_DEBUG "resources=%llx\n" , resources[cpu]);#endif return size; }
@@ -131,7 +131,7 @@ show_virtual_to_phys(struct device *dev, struct device_attribute *attr, char *buf) {unsigned int cpu=dev->id; -return sprintf (buf,"%lx\n" , phys_addr[cpu]); +return sprintf (buf,"%llx\n" , phys_addr[cpu]); } static ssize_t
@@ -145,7 +145,7 @@ store_virtual_to_phys(struct device *dev, struct device_attribute *attr, ret =get_user_pages_fast (virt_addr,1 ,FOLL_WRITE ,NULL );if (ret<=0 ) {#ifdef ERR_INJ_DEBUG -printk ("Virtual address %lx is not existing.\n" ,virt_addr); +printk ("Virtual address %llx is not existing.\n" , virt_addr);#endif return -EINVAL ; }
@@ -163,7 +163,7 @@ show_err_data_buffer(struct device *dev, {unsigned int cpu=dev->id; -return sprintf (buf,"%lx, %lx, %lx\n" , +return sprintf (buf,"%llx, %llx, %llx\n" , err_data_buffer[cpu].data1, err_data_buffer[cpu].data2, err_data_buffer[cpu].data3);
@@ -178,13 +178,13 @@ store_err_data_buffer(struct device *dev,int ret;#ifdef ERR_INJ_DEBUG -printk ("write err_data_buffer=[%lx,%lx,%lx] on cpu%d\n" , +printk ("write err_data_buffer=[%llx,%llx,%llx] on cpu%d\n" , err_data_buffer[cpu].data1, err_data_buffer[cpu].data2, err_data_buffer[cpu].data3, cpu);#endif - ret=sscanf (buf,"%lx, %lx, %lx" , + ret =sscanf (buf,"%llx, %llx, %llx" , &err_data_buffer[cpu].data1, &err_data_buffer[cpu].data2, &err_data_buffer[cpu].data3);
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 13/18 cifs: revalidate mapping when we open files for SMB1 POSIX
In reply to Greg Kroah-HartmanFrom: Ronnie Sahlberg <[email protected]>
[ Upstream commit cee8f4f6fcabfdf229542926128e9874d19016d5 ]
RHBZ: 1933527
Under SMB1 + POSIX, if an inode is reused on a server after we have read and cached a part of a file, when we then open the new file with the re-cycled inode there is a chance that we may serve the old data out of cache to the application.
This only happens for SMB1 (deprecated) and when posix are used. The simplest solution to avoid this race is to force a revalidate on smb1-posix open.
--- fs/cifs/file.c | 1 + 1 file changed, 1 insertion(+)
fs/cifs/file.c +1 -0
@@ -163,6 +163,7 @@ int cifs_posix_open(char *full_path, struct inode **pinode, goto posix_open_ret; } }else { +cifs_revalidate_mapping (*pinode);cifs_fattr_to_inode (*pinode, &fattr); }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 14/18 cifs: Silently ignore unknown oplock break handle
In reply to Greg Kroah-HartmanFrom: 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 ................
--- fs/cifs/smb2misc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/cifs/smb2misc.c +2 -2
@@ -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
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 15/18 bpf, x86: Validate computation of branch displacements for x86-64
In reply to Greg Kroah-HartmanFrom: Piotr Krysiuk <[email protected]>
commit e4d4d456436bfb2fe412ee2cd489f7658449b098 upstream.
The branch displacement logic in the BPF JIT compilers for x86 assumes that, for any generated branch instruction, the distance cannot increase between optimization passes.
But this assumption can be violated due to how the distances are computed. Specifically, whenever a backward branch is processed in do_jit(), the distance is computed by subtracting the positions in the machine code from different optimization passes. This is because part of addrs[] is already updated for the current optimization pass, before the branch instruction is visited.
And so the optimizer can expand blocks of machine code in some cases.
This can confuse the optimizer logic, where it assumes that a fixed point has been reached for all machine code blocks once the total program size stops changing. And then the JIT compiler can output abnormal machine code containing incorrect branch displacements.
To mitigate this issue, we assert that a fixed point is reached while populating the output image. This rejects any problematic programs. The issue affects both x86-32 and x86-64. We mitigate separately to ease backporting.
--- arch/x86/net/bpf_jit_comp.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
arch/x86/net/bpf_jit_comp.c +10 -1
@@ -1019,7 +1019,16 @@ emit_jmp: }if (image) { -if (unlikely (proglen + ilen > oldproglen)) { +/* +* When populating the image, assert that: +* +* i) We do not write beyond the allocated space, and +* ii) addrs[i] did not change from the prior run, in order +* to validate assumptions made for computing branch +* displacements. +*/ +if (unlikely (proglen + ilen > oldproglen || + proglen + ilen != addrs[i])) {pr_err ("bpf_jit: fatal error\n" );return -EFAULT ; }
Greg Kroah-Hartman
maintainerPATCH 16/18 bpf, x86: Validate computation of branch displacements for x86-32
In reply to Greg Kroah-HartmanFrom: Piotr Krysiuk <[email protected]>
commit 26f55a59dc65ff77cd1c4b37991e26497fc68049 upstream.
The branch displacement logic in the BPF JIT compilers for x86 assumes that, for any generated branch instruction, the distance cannot increase between optimization passes.
But this assumption can be violated due to how the distances are computed. Specifically, whenever a backward branch is processed in do_jit(), the distance is computed by subtracting the positions in the machine code from different optimization passes. This is because part of addrs[] is already updated for the current optimization pass, before the branch instruction is visited.
And so the optimizer can expand blocks of machine code in some cases.
This can confuse the optimizer logic, where it assumes that a fixed point has been reached for all machine code blocks once the total program size stops changing. And then the JIT compiler can output abnormal machine code containing incorrect branch displacements.
To mitigate this issue, we assert that a fixed point is reached while populating the output image. This rejects any problematic programs. The issue affects both x86-32 and x86-64. We mitigate separately to ease backporting.
--- arch/x86/net/bpf_jit_comp32.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
arch/x86/net/bpf_jit_comp32.c +10 -1
@@ -2201,7 +2201,16 @@ notyet: }if (image) { -if (unlikely (proglen + ilen > oldproglen)) { +/* +* When populating the image, assert that: +* +* i) We do not write beyond the allocated space, and +* ii) addrs[i] did not change from the prior run, in order +* to validate assumptions made for computing branch +* displacements. +*/ +if (unlikely (proglen + ilen > oldproglen || + proglen + ilen != addrs[i])) {pr_err ("bpf_jit: fatal error\n" );return -EFAULT ; }
Greg Kroah-Hartman
maintainerPATCH 17/18 init/Kconfig: make COMPILE_TEST depend on !S390
In reply to Greg Kroah-HartmanFrom: Heiko Carstens <[email protected]>
commit 334ef6ed06fa1a54e35296b77b693bcf6d63ee9e upstream.
While allmodconfig and allyesconfig build for s390 there are also various bots running compile tests with randconfig, where PCI is disabled. This reveals that a lot of drivers should actually depend on HAS_IOMEM.
Adding this to each device driver would be a never ending story, therefore just disable COMPILE_TEST for s390.
The reasoning is more or less the same as described in commit bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on !UML").
--- init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
init/Kconfig +1 -1
@@ -66,7 +66,7 @@ config INIT_ENV_ARG_LIMIT config COMPILE_TEST bool "Compile also drivers which will not load" - depends on !UML + depends on !UML && !S390 default n help Some drivers can be compiled on a different platform than they are
Greg Kroah-Hartman
maintainerPATCH 18/18 init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM
In reply to Greg Kroah-HartmanFrom: Masahiro Yamada <[email protected]>
commit ea29b20a828511de3348334e529a3d046a180416 upstream.
I read the commit log of the following two:
- bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on !UML")
- 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390")
Both are talking about HAS_IOMEM dependency missing in many drivers.
So, 'depends on HAS_IOMEM' seems the direct, sensible solution to me.
This does not change the behavior of UML. UML still cannot enable COMPILE_TEST because it does not provide HAS_IOMEM.
The current dependency for S390 is too strong. Under the condition of CONFIG_PCI=y, S390 provides HAS_IOMEM, hence can enable COMPILE_TEST.
I also removed the meaningless 'default n'.
--- init/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
init/Kconfig +1 -2
@@ -66,8 +66,7 @@ config INIT_ENV_ARG_LIMIT config COMPILE_TEST bool "Compile also drivers which will not load" - depends on !UML && !S390 - default n + depends on HAS_IOMEM help Some drivers can be compiled on a different platform than they are intended to be run on. Despite they cannot be loaded there (or even
Quoted 8 lines · Greg Kroah-Hartman
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
Guenter
Quoted 9 lines · Greg Kroah-Hartman
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:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.186-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
Greg Kroah-Hartman
maintainerQuoted 64 lines · Shuah Khan
Quoted 9 lines · Greg Kroah-Hartman
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:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.186-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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_1wmi_bmofsnd_hda_codec_realteksnd_hda_codec_genericsnd_hda_codec_hdmiedac_mce_amdsnd_hda_intelsnd_hda_codeckvm_amdsnd_hda_coreccpsnd_hwdepkvmsnd_pcmsnd_seq_midicrct10dif_pclmulsnd_seq_midi_eventghash_clmulni_intelpcbcsnd_rawmidiath10k_pcisnd_seqath10k_coreaesni_intelathsnd_seq_devicertsx_usb_msbtusbaes_x86_64snd_timercrypto_simdbtrtl cryptd joydev btbcmglue_helpermemstick mac80211 snd btintelinput_ledsbluetooth soundcore cfg80211ecdh_genericvideo wmimac_hidsch_fq_codelparport_pcppdev lp parport drmip_tablesx_tablesautofs4hid_genericrtsx_usb_sdmmcusbhidrtsx_usbhidcrc32_pclmuluasi2c_piix4r8169 ahci realtekusb_storagelibahcigpio_amdptgpio_genericCPU: 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
Quoted 10 lines
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: 00000246ORIG_RAX: ffffffffffffffda
RAX:ffff8d81bf0626c0RBX:ffff8d81b2690400RCX:00000006e8cb49d2
RDX: 0000000000000689 RSI:00000006e8cb49d2RDI: 0000000000000000
RBP:ffffb11e01a77e90R08:00000006e8cb505bR09:0000000000000e29
R10:0000000000000f04R11:ffff8d81bf061528R12: 0000000000000003
R13:ffffffff8df9e860R14:ffffffff8df9e980R15: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
Quoted 10 lines · Greg Kroah-Hartman
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:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.186-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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.
## 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