* [PATCH 4.9 01/13] net: pxa168_eth: Fix a potential data race in pxa168_eth_remove
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 02/13] mISDN: fix crash in fritzpci Greg Kroah-Hartman
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pavel Andrianov, David S. Miller,
Sasha Levin
From: Pavel Andrianov <andrianov@ispras.ru>
[ 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 <andrianov@ispras.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
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 5d5000c8edf1..09cb0ac701e1 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -1571,8 +1571,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
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 4.9 02/13] mISDN: fix crash in fritzpci
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 01/13] net: pxa168_eth: Fix a potential data race in pxa168_eth_remove Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 03/13] mac80211: choose first enabled channel for monitor Greg Kroah-Hartman
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tong Zhang, David S. Miller,
Sasha Levin
From: Tong Zhang <ztong0001@gmail.com>
[ 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
Signed-off-by: Tong Zhang <ztong0001@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/hardware/mISDN/mISDNipac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/mISDN/mISDNipac.c b/drivers/isdn/hardware/mISDN/mISDNipac.c
index 8d338ba366d0..01a1afde5d3c 100644
--- a/drivers/isdn/hardware/mISDN/mISDNipac.c
+++ b/drivers/isdn/hardware/mISDN/mISDNipac.c
@@ -711,7 +711,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);
--
2.30.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 4.9 03/13] mac80211: choose first enabled channel for monitor
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 01/13] net: pxa168_eth: Fix a potential data race in pxa168_eth_remove Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 02/13] mISDN: fix crash in fritzpci Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 04/13] drm/msm: Ratelimit invalid-fence message Greg Kroah-Hartman
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Karthikeyan Kathirvel, Johannes Berg,
Sasha Levin
From: Karthikeyan Kathirvel <kathirve@codeaurora.org>
[ 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 <kathirve@codeaurora.org>
Link: https://lore.kernel.org/r/1615440547-7661-1-git-send-email-kathirve@codeaurora.org
[reword commit message, comment, code cleanups]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
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 e3bbfb20ae82..f31fd21d59ba 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -906,8 +906,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
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 4.9 04/13] drm/msm: Ratelimit invalid-fence message
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 03/13] mac80211: choose first enabled channel for monitor Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 05/13] x86/build: Turn off -fcf-protection for realmode targets Greg Kroah-Hartman
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rob Clark, Douglas Anderson,
Sasha Levin
From: Rob Clark <robdclark@chromium.org>
[ 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 <robdclark@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
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 a9b9b1c95a2e..9dbd17be51f7 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
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 4.9 05/13] x86/build: Turn off -fcf-protection for realmode targets
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 04/13] drm/msm: Ratelimit invalid-fence message Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 06/13] scsi: target: pscsi: Clean up after failure in pscsi_map_sg() Greg Kroah-Hartman
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Ingo Molnar,
Sasha Levin
From: Arnd Bergmann <arnd@arndb.de>
[ 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.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210323124846.1584944-1-arnd@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 9f0099c46c88..9ebbd4892557 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -34,7 +34,7 @@ REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os -D__KERNEL__ \
-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)
--
2.30.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 4.9 06/13] scsi: target: pscsi: Clean up after failure in pscsi_map_sg()
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 05/13] x86/build: Turn off -fcf-protection for realmode targets Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 07/13] ia64: mca: allocate early mca with GFP_ATOMIC Greg Kroah-Hartman
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christoph Hellwig, Lee Duncan,
Martin Wilck, Martin K. Petersen, Sasha Levin
From: Martin Wilck <mwilck@suse.com>
[ Upstream commit 36fa766faa0c822c860e636fe82b1affcd022974 ]
If pscsi_map_sg() fails, make sure to drop references to already allocated
bios.
Link: https://lore.kernel.org/r/20210323212431.15306-2-mwilck@suse.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/target/target_core_pscsi.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/target/target_core_pscsi.c b/drivers/target/target_core_pscsi.c
index ef1c8c158f66..079db0bd3917 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -951,6 +951,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;
}
--
2.30.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 4.9 07/13] ia64: mca: allocate early mca with GFP_ATOMIC
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 06/13] scsi: target: pscsi: Clean up after failure in pscsi_map_sg() Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 08/13] cifs: revalidate mapping when we open files for SMB1 POSIX Greg Kroah-Hartman
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sergei Trofimovich, Andrew Morton,
Linus Torvalds, Sasha Levin
From: Sergei Trofimovich <slyfox@gentoo.org>
[ 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 1
As 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.
Link: https://lkml.kernel.org/r/20210315085045.204414-1-slyfox@gentoo.org
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/ia64/kernel/mca.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index 9509cc73b9c6..64ae9cde8bdb 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -1858,7 +1858,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",
--
2.30.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 4.9 08/13] cifs: revalidate mapping when we open files for SMB1 POSIX
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 07/13] ia64: mca: allocate early mca with GFP_ATOMIC Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 09/13] cifs: Silently ignore unknown oplock break handle Greg Kroah-Hartman
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ronnie Sahlberg,
Paulo Alcantara (SUSE), Steve French, Sasha Levin
From: Ronnie Sahlberg <lsahlber@redhat.com>
[ 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.
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/cifs/file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 24508b69e78b..e2ce90fc504e 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -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);
}
--
2.30.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 4.9 09/13] cifs: Silently ignore unknown oplock break handle
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 08/13] cifs: revalidate mapping when we open files for SMB1 POSIX Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 10/13] bpf, x86: Validate computation of branch displacements for x86-64 Greg Kroah-Hartman
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vincent Whitchurch, Tom Talpey,
Paulo Alcantara (SUSE), Steve French, Sasha Levin
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
[ 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 <vincent.whitchurch@axis.com>
Reviewed-by: Tom Talpey <tom@talpey.com>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/cifs/smb2misc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/cifs/smb2misc.c
+++ b/fs/cifs/smb2misc.c
@@ -651,8 +651,8 @@ smb2_is_valid_oplock_break(char *buffer,
}
}
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 4.9 10/13] bpf, x86: Validate computation of branch displacements for x86-64
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 09/13] cifs: Silently ignore unknown oplock break handle Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 11/13] ALSA: hda/realtek - Fix pincfg for Dell XPS 13 9370 Greg Kroah-Hartman
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Piotr Krysiuk, Daniel Borkmann
From: Piotr Krysiuk <piotras@gmail.com>
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.
Signed-off-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/net/bpf_jit_comp.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -1082,7 +1082,16 @@ common_load:
}
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_compile fatal error\n");
return -EFAULT;
}
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 4.9 11/13] ALSA: hda/realtek - Fix pincfg for Dell XPS 13 9370
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 10/13] bpf, x86: Validate computation of branch displacements for x86-64 Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 12/13] init/Kconfig: make COMPILE_TEST depend on !S390 Greg Kroah-Hartman
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Shih-Yuan Lee (FourDollars),
Takashi Iwai, Sudip Mukherjee
From: "Shih-Yuan Lee (FourDollars)" <sylee@canonical.com>
commit 8df4b0031067758d8b0a3bfde7d35e980d0376d5 upstream
The initial pin configs for Dell headset mode of ALC3271 has changed.
/sys/class/sound/hwC0D0/init_pin_configs: (BIOS 0.1.4)
0x12 0xb7a60130
0x13 0xb8a61140
0x14 0x40000000
0x16 0x411111f0
0x17 0x90170110
0x18 0x411111f0
0x19 0x411111f0
0x1a 0x411111f0
0x1b 0x411111f0
0x1d 0x4087992d
0x1e 0x411111f0
0x21 0x04211020
has changed to ...
/sys/class/sound/hwC0D0/init_pin_configs: (BIOS 0.2.0)
0x12 0xb7a60130
0x13 0x40000000
0x14 0x411111f0
0x16 0x411111f0
0x17 0x90170110
0x18 0x411111f0
0x19 0x411111f0
0x1a 0x411111f0
0x1b 0x411111f0
0x1d 0x4067992d
0x1e 0x411111f0
0x21 0x04211020
Fixes: b4576de87243 ("ALSA: hda/realtek - Fix typo of pincfg for Dell quirk")
Signed-off-by: Shih-Yuan Lee (FourDollars) <sylee@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 1 -
1 file changed, 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6285,7 +6285,6 @@ static const struct snd_hda_pin_quirk al
SND_HDA_PIN_QUIRK(0x10ec0299, 0x1028, "Dell", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE,
ALC225_STANDARD_PINS,
{0x12, 0xb7a60130},
- {0x13, 0xb8a61140},
{0x17, 0x90170110}),
{}
};
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 4.9 12/13] init/Kconfig: make COMPILE_TEST depend on !S390
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 11/13] ALSA: hda/realtek - Fix pincfg for Dell XPS 13 9370 Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 9:53 ` [PATCH 4.9 13/13] init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM Greg Kroah-Hartman
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, kernel test robot, Arnd Bergmann,
Heiko Carstens, Guenter Roeck
From: Heiko Carstens <hca@linux.ibm.com>
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").
Reported-by: kernel test robot <lkp@intel.com>
Suggested-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
init/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -65,7 +65,7 @@ config CROSS_COMPILE
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 4.9 13/13] init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 12/13] init/Kconfig: make COMPILE_TEST depend on !S390 Greg Kroah-Hartman
@ 2021-04-09 9:53 ` Greg Kroah-Hartman
2021-04-09 20:08 ` [PATCH 4.9 00/13] 4.9.266-rc1 review Guenter Roeck
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-09 9:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Masahiro Yamada, Heiko Carstens,
Guenter Roeck, Arnd Bergmann, Kees Cook, Daniel Borkmann,
Johannes Weiner, KP Singh, Nathan Chancellor, Nick Terrell,
Quentin Perret, Valentin Schneider,
Enrico Weigelt, metux IT consult, Andrew Morton, Linus Torvalds
From: Masahiro Yamada <masahiroy@kernel.org>
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'.
Link: https://lkml.kernel.org/r/20210224140809.1067582-1-masahiroy@kernel.org
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: KP Singh <kpsingh@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Quentin Perret <qperret@google.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
init/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -65,8 +65,7 @@ config CROSS_COMPILE
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 4.9 00/13] 4.9.266-rc1 review
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2021-04-09 9:53 ` [PATCH 4.9 13/13] init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM Greg Kroah-Hartman
@ 2021-04-09 20:08 ` Guenter Roeck
2021-04-09 20:34 ` Florian Fainelli
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: Guenter Roeck @ 2021-04-09 20:08 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, stable
On Fri, Apr 09, 2021 at 11:53:20AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.266 release.
> There are 13 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: 163 pass: 163 fail: 0
Qemu test results:
total: 383 pass: 383 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 4.9 00/13] 4.9.266-rc1 review
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2021-04-09 20:08 ` [PATCH 4.9 00/13] 4.9.266-rc1 review Guenter Roeck
@ 2021-04-09 20:34 ` Florian Fainelli
2021-04-09 22:31 ` Shuah Khan
2021-04-10 9:43 ` Naresh Kamboju
16 siblings, 0 replies; 18+ messages in thread
From: Florian Fainelli @ 2021-04-09 20:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, stable
On 4/9/2021 2:53 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.266 release.
> There are 13 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.9.266-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.9.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 <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 4.9 00/13] 4.9.266-rc1 review
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2021-04-09 20:34 ` Florian Fainelli
@ 2021-04-09 22:31 ` Shuah Khan
2021-04-10 9:43 ` Naresh Kamboju
16 siblings, 0 replies; 18+ messages in thread
From: Shuah Khan @ 2021-04-09 22:31 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, stable, Shuah Khan
On 4/9/21 3:53 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.266 release.
> There are 13 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.9.266-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.9.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 <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 4.9 00/13] 4.9.266-rc1 review
2021-04-09 9:53 [PATCH 4.9 00/13] 4.9.266-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2021-04-09 22:31 ` Shuah Khan
@ 2021-04-10 9:43 ` Naresh Kamboju
16 siblings, 0 replies; 18+ messages in thread
From: Naresh Kamboju @ 2021-04-10 9:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, lkft-triage, Pavel Machek, Jon Hunter,
Florian Fainelli, linux-stable
On Fri, 9 Apr 2021 at 15:26, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.9.266 release.
> There are 13 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.9.266-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.9.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 <lkft@linaro.org>
## Build
* kernel: 4.9.266-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.9.y
* git commit: d263ac9a21bc26cb10dee0ee34109289ac518725
* git describe: v4.9.265-14-gd263ac9a21bc
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.265-14-gd263ac9a21bc
## No regressions (compared to v4.9.265)
## No fixes (compared to v4.9.265)
## Test result summary
total: 56309, pass: 46531, fail: 617, skip: 8921, xfail: 240,
## Build Summary
* arm: 96 total, 96 passed, 0 failed
* arm64: 23 total, 23 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 13 total, 13 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 36 total, 36 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: 13 total, 13 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* 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-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* 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
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 18+ messages in thread