May 2021 - Linux-stable-mirror

by holsten

Good day Kindly assist us with the pricing of product self priming pump using the (Product code:Model Number:HT75061-21) Qty 30x pieces Quotation shall be submitted to below email Address for immediate attention Kind Regards, Ibrahim Bakker Area Procurement officer Tel: +31(0)108082036 Fax: +31(0)108082037 Email: IbrahimBakker(a)dutchmail.com or info(a)unilevgrprotterdam.nl

3 years, 7 months

1
0
0 0

[PATCH v2 1/2] x86/sev-es: Move sev_es_put_ghcb() in prep for follow on patch

by Tom Lendacky

Move the location of sev_es_put_ghcb() in preparation for an update to it in a follow-on patch. This will better highlight the changes being made to the function. No functional change. Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler") Cc: stable(a)vger.kernel.org Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com> --- arch/x86/kernel/sev.c | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c index 9578c82832aa..45e212675811 100644 --- a/arch/x86/kernel/sev.c +++ b/arch/x86/kernel/sev.c @@ -221,24 +221,6 @@ static __always_inline struct ghcb *sev_es_get_ghcb(struct ghcb_state *state) return ghcb; } -static __always_inline void sev_es_put_ghcb(struct ghcb_state *state) -{ - struct sev_es_runtime_data *data; - struct ghcb *ghcb; - - data = this_cpu_read(runtime_data); - ghcb = &data->ghcb_page; - - if (state->ghcb) { - /* Restore GHCB from Backup */ - *ghcb = *state->ghcb; - data->backup_ghcb_active = false; - state->ghcb = NULL; - } else { - data->ghcb_active = false; - } -} - /* Needed in vc_early_forward_exception */ void do_early_exception(struct pt_regs *regs, int trapnr); @@ -461,6 +443,24 @@ static enum es_result vc_slow_virt_to_phys(struct ghcb *ghcb, struct es_em_ctxt /* Include code shared with pre-decompression boot stage */ #include "sev-shared.c" +static __always_inline void sev_es_put_ghcb(struct ghcb_state *state) +{ + struct sev_es_runtime_data *data; + struct ghcb *ghcb; + + data = this_cpu_read(runtime_data); + ghcb = &data->ghcb_page; + + if (state->ghcb) { + /* Restore GHCB from Backup */ + *ghcb = *state->ghcb; + data->backup_ghcb_active = false; + state->ghcb = NULL; + } else { + data->ghcb_active = false; + } +} + void noinstr __sev_es_nmi_complete(void) { struct ghcb_state state; -- 2.31.0

3 years, 7 months

3
5
0 0

[PATCH] platform/chrome: cros_ec_proto: Send command again when timeout occurs

by Patryk Duda

Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it hasn't initialized SPI yet. This can happen because FPMCU is restarted during system boot and kernel can send message in short window eg. between sysjump to RW and SPI initialization. Cc: <stable(a)vger.kernel.org> # 4.4+ Signed-off-by: Patryk Duda <pdk(a)semihalf.com> --- Fingerprint MCU is rebooted during system startup by AP firmware (coreboot). During cold boot kernel can query FPMCU in a window just after jump to RW section of firmware but before SPI is initialized. The window was shortened to <1ms, but it can't be eliminated completly. Communication with FPMCU (and all devices based on EC) is bi-directional. When kernel sends message, EC will send EC_SPI* status codes. When EC is not able to process command one of bytes will be eg. EC_SPI_NOT_READY. This mechanism won't work when SPI is not initailized on EC side. In fact, buffer is filled with 0xFF bytes, so from kernel perspective device is not responding. To avoid this problem, we can query device once again. We are already waiting EC_MSG_DEADLINE_MS for response, so we can send command immediately. Best regards, Patryk drivers/platform/chrome/cros_ec_proto.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c index aa7f7aa77297..3384631d21e2 100644 --- a/drivers/platform/chrome/cros_ec_proto.c +++ b/drivers/platform/chrome/cros_ec_proto.c @@ -279,6 +279,18 @@ static int cros_ec_host_command_proto_query(struct cros_ec_device *ec_dev, msg->insize = sizeof(struct ec_response_get_protocol_info); ret = send_command(ec_dev, msg); + /* + * Send command once again when timeout occurred. + * Fingerprint MCU (FPMCU) is restarted during system boot which + * introduces small window in which FPMCU won't respond for any + * messages sent by kernel. There is no need to wait before next + * attempt because we waited at least EC_MSG_DEADLINE_MS. + */ + if (ret == -ETIMEDOUT) { + dev_warn(ec_dev->dev, + "Timeout to get response from EC. Retrying.\n"); + ret = send_command(ec_dev, msg); + } if (ret < 0) { dev_dbg(ec_dev->dev, -- 2.31.1.751.gd2f1c929bd-goog

3 years, 7 months

2
1
0 0

[PATCH] ALSA: dice: fix stream format for TC Electronic Konnekt Live at high sampling transfer frequency

by Takashi Sakamoto

At high sampling transfer frequency, TC Electronic Konnekt Live transfers/receives 6 audio data frames in multi bit linear audio data channel of data block in CIP payload. Current hard-coded stream format is wrong. Cc: <stable(a)vger.kernel.org> Fixes: f1f0f330b1d0 ("ALSA: dice: add parameters of stream formats for models produced by TC Electronic") Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/dice/dice-tcelectronic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/firewire/dice/dice-tcelectronic.c b/sound/firewire/dice/dice-tcelectronic.c index a8875d24ba2a..43a3bcb15b3d 100644 --- a/sound/firewire/dice/dice-tcelectronic.c +++ b/sound/firewire/dice/dice-tcelectronic.c @@ -38,8 +38,8 @@ static const struct dice_tc_spec konnekt_24d = { }; static const struct dice_tc_spec konnekt_live = { - .tx_pcm_chs = {{16, 16, 16}, {0, 0, 0} }, - .rx_pcm_chs = {{16, 16, 16}, {0, 0, 0} }, + .tx_pcm_chs = {{16, 16, 6}, {0, 0, 0} }, + .rx_pcm_chs = {{16, 16, 6}, {0, 0, 0} }, .has_midi = true, }; -- 2.27.0

3 years, 7 months

2
1
0 0

[PATCH AUTOSEL 5.4 1/2] ptrace: make ptrace() fail if the tracee changed its pid unexpectedly

by Sasha Levin

From: Oleg Nesterov <oleg(a)redhat.com> [ Upstream commit dbb5afad100a828c97e012c6106566d99f041db6 ] Suppose we have 2 threads, the group-leader L and a sub-theread T, both parked in ptrace_stop(). Debugger tries to resume both threads and does ptrace(PTRACE_CONT, T); ptrace(PTRACE_CONT, L); If the sub-thread T execs in between, the 2nd PTRACE_CONT doesn not resume the old leader L, it resumes the post-exec thread T which was actually now stopped in PTHREAD_EVENT_EXEC. In this case the PTHREAD_EVENT_EXEC event is lost, and the tracer can't know that the tracee changed its pid. This patch makes ptrace() fail in this case until debugger does wait() and consumes PTHREAD_EVENT_EXEC which reports old_pid. This affects all ptrace requests except the "asynchronous" PTRACE_INTERRUPT/KILL. The patch doesn't add the new PTRACE_ option to not complicate the API, and I _hope_ this won't cause any noticeable regression: - If debugger uses PTRACE_O_TRACEEXEC and the thread did an exec and the tracer does a ptrace request without having consumed the exec event, it's 100% sure that the thread the ptracer thinks it is targeting does not exist anymore, or isn't the same as the one it thinks it is targeting. - To some degree this patch adds nothing new. In the scenario above ptrace(L) can fail with -ESRCH if it is called after the execing sub-thread wakes the leader up and before it "steals" the leader's pid. Test-case: #include <stdio.h> #include <unistd.h> #include <signal.h> #include <sys/ptrace.h> #include <sys/wait.h> #include <errno.h> #include <pthread.h> #include <assert.h> void *tf(void *arg) { execve("/usr/bin/true", NULL, NULL); assert(0); return NULL; } int main(void) { int leader = fork(); if (!leader) { kill(getpid(), SIGSTOP); pthread_t th; pthread_create(&th, NULL, tf, NULL); for (;;) pause(); return 0; } waitpid(leader, NULL, WSTOPPED); ptrace(PTRACE_SEIZE, leader, 0, PTRACE_O_TRACECLONE | PTRACE_O_TRACEEXEC); waitpid(leader, NULL, 0); ptrace(PTRACE_CONT, leader, 0,0); waitpid(leader, NULL, 0); int status, thread = waitpid(-1, &status, 0); assert(thread > 0 && thread != leader); assert(status == 0x80137f); ptrace(PTRACE_CONT, thread, 0,0); /* * waitid() because waitpid(leader, &status, WNOWAIT) does not * report status. Why ???? * * Why WEXITED? because we have another kernel problem connected * to mt-exec. */ siginfo_t info; assert(waitid(P_PID, leader, &info, WSTOPPED|WEXITED|WNOWAIT) == 0); assert(info.si_pid == leader && info.si_status == 0x0405); /* OK, it sleeps in ptrace(PTRACE_EVENT_EXEC == 0x04) */ assert(ptrace(PTRACE_CONT, leader, 0,0) == -1); assert(errno == ESRCH); assert(leader == waitpid(leader, &status, WNOHANG)); assert(status == 0x04057f); assert(ptrace(PTRACE_CONT, leader, 0,0) == 0); return 0; } Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> Reported-by: Simon Marchi <simon.marchi(a)efficios.com> Acked-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Acked-by: Pedro Alves <palves(a)redhat.com> Acked-by: Simon Marchi <simon.marchi(a)efficios.com> Acked-by: Jan Kratochvil <jan.kratochvil(a)redhat.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- kernel/ptrace.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/kernel/ptrace.c b/kernel/ptrace.c index 79de1294f8eb..eb4d04cb3aaf 100644 --- a/kernel/ptrace.c +++ b/kernel/ptrace.c @@ -169,6 +169,21 @@ void __ptrace_unlink(struct task_struct *child) spin_unlock(&child->sighand->siglock); } +static bool looks_like_a_spurious_pid(struct task_struct *task) +{ + if (task->exit_code != ((PTRACE_EVENT_EXEC << 8) | SIGTRAP)) + return false; + + if (task_pid_vnr(task) == task->ptrace_message) + return false; + /* + * The tracee changed its pid but the PTRACE_EVENT_EXEC event + * was not wait()'ed, most probably debugger targets the old + * leader which was destroyed in de_thread(). + */ + return true; +} + /* Ensure that nothing can wake it up, even SIGKILL */ static bool ptrace_freeze_traced(struct task_struct *task) { @@ -179,7 +194,8 @@ static bool ptrace_freeze_traced(struct task_struct *task) return ret; spin_lock_irq(&task->sighand->siglock); - if (task_is_traced(task) && !__fatal_signal_pending(task)) { + if (task_is_traced(task) && !looks_like_a_spurious_pid(task) && + !__fatal_signal_pending(task)) { task->state = __TASK_TRACED; ret = true; } -- 2.30.2

3 years, 7 months

3
3
0 0

5.10.37 won't boot on my system, but 5.10.36 with same config does

by Charles Wright

I see a couple of other posts with same issue. https://www.reddit.com/r/voidlinux/comments/nchtph/kernel_51037_1_boot_prob… https://forums.gentoo.org/viewtopic-p-8610756.html

3 years, 7 months

5
11
0 0

[PATCH] bcache: avoid oversized read request in cache missing code path

by colyli＠suse.de

From: Coly Li <colyli(a)suse.de> In the cache missing code path of cached device, if a proper location from the internal B+ tree is matched for a cache miss range, function cached_dev_cache_miss() will be called in cache_lookup_fn() in the following code block, [code block 1] 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode 527 ? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529 : INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors); Here s->d->cache_miss() is the call backfunction pointer initialized as cached_dev_cache_miss(), the last parameter 'sectors' is an important hint to calculate the size of read request to backing device of the missing cache data. Current calculation in above code block may generate oversized value of 'sectors', which consequently may trigger 2 different potential kernel panics by BUG() or BUG_ON() as listed below, 1) BUG_ON() inside bch_btree_insert_key(), [code block 2] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() inside biovec_slab(), [code block 3] 51 default: 52 BUG(); 53 return NULL; All the above panics are original from cached_dev_cache_miss() by the oversized parameter 'sectors'. Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate the size of data read from backing device for the cache missing. This size is stored in s->insert_bio_sectors by the following lines of code, [code block 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Then the actual key inserting to the internal B+ tree is generated and stored in s->iop.replace_key by the following lines of code, [code block 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insert_bio_sectors, 913 s->insert_bio_sectors); The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from the above code block. And the bio sending to backing device for the missing data is allocated with hint from s->insert_bio_sectors by the following lines of code, [code block 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); The oversized parameter 'sectors' may trigger panic 2) by BUG() from the agove code block. Now let me explain how the panics happen with the oversized 'sectors'. In code block 5, replace_key is generated by macro KEY(). From the definition of macro KEY(), [code block 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \ 74 .low = (offset) \ 75 }) Here 'size' is 16bits width embedded in 64bits member 'high' of struct bkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" is very probably to be larger than (1<<16) - 1, which makes the bkey size calculation in code block 5 is overflowed. In one bug report the value of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors' results the overflowed s->insert_bio_sectors in code block 4, then makes size field of s->iop.replace_key to be 0 in code block 5. Then the 0- sized s->iop.replace_key is inserted into the internal B+ tree as cache missing check key (a special key to detect and avoid a racing between normal write request and cache missing read request) as, [code block 8] 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key); Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey size check BUG_ON() in code block 2, and causes the kernel panic 1). Another kernel panic is from code block 6, is from the oversized value s->insert_bio_sectors resulted by the oversized 'sectors'. From a bug report the result of "DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS)" from code block 6 can be 344, 282, 946, 342 and many other values which larther than BIO_MAX_VECS (a.k.a 256). When calling bio_alloc_bioset() with such larger-than-256 value as the 2nd parameter, this value will eventually be sent to biovec_slab() as parameter 'nr_vecs' in following code path, bio_alloc_bioset() ==> bvec_alloc() ==> biovec_slab() Because parameter 'nr_vecs' is larger-than-256 value, the panic by BUG() in code block 3 is triggered inside biovec_slab(). >From the above analysis, it is obvious that in order to avoid the kernel panics in code block 2 and code block 3, the calculated 'sectors' in code block 1 should not generate overflowed value in code block 5 and code block 6. To avoid overflow in code block 5, the maximum 'sectors' value should be equal or less than (1 << KEY_SIZE_BITS) - 1. And to avoid overflow in code block 6, the maximum 'sectors' value should be euqal or less than BIO_MAX_VECS * PAGE_SECTORS. Considering the kernel page size can be variable, a reasonable maximum limitation of 'sectors' in code block 1 should be smaller on from "(1 << KEY_SIZE_BITS) - 1" and "BIO_MAX_VECS * PAGE_SECTORS". In this patch, a local variable inside cache_lookup_fn() is added as, max_cache_miss_size = min_t(uint32_t, (1 << KEY_SIZE_BITS) - 1, BIO_MAX_VECS * PAGE_SECTORS); Then code block 1 uses max_cache_miss_size to limit the maximum value of 'sectors' calculation as, 533 unsigned int sectors = KEY_INODE(k) == s->iop.inode 534 ? min_t(uint64_t, max_cache_miss_size, 535 KEY_START(k) - bio->bi_iter.bi_sector) 536 : max_cache_miss_size; Now the calculated 'sectors' value sent into cached_dev_cache_miss() won't trigger neither of the above kernel panics. Current problmatic code can be partially found since Linux v5.13-rc1, therefore all maintained stable kernels should try to apply this fix. Reported-by: Diego Ercolani <diego.ercolani(a)gmail.com> Reported-by: Jan Szubiak <jan.szubiak(a)linuxpolska.pl> Reported-by: Marco Rebhan <me(a)dblsaiko.net> Reported-by: Matthias Ferdinand <bcache(a)mfedv.net> Reported-by: Thorsten Knabe <linux(a)thorsten-knabe.de> Reported-by: Victor Westerhuis <victor(a)westerhu.is> Reported-by: Vojtech Pavlik <vojtech(a)suse.cz> Signed-off-by: Coly Li <colyli(a)suse.de> Cc: stable(a)vger.kernel.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Kent Overstreet <kent.overstreet(a)gmail.com> --- drivers/md/bcache/request.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c index 29c231758293..90fa9ac47661 100644 --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -515,18 +515,25 @@ static int cache_lookup_fn(struct btree_op *op, struct btree *b, struct bkey *k) struct search *s = container_of(op, struct search, op); struct bio *n, *bio = &s->bio.bio; struct bkey *bio_key; - unsigned int ptr; + unsigned int ptr, max_cache_miss_size; if (bkey_cmp(k, &KEY(s->iop.inode, bio->bi_iter.bi_sector, 0)) <= 0) return MAP_CONTINUE; + /* + * Make sure the cache missing size won't exceed the restrictions of + * max bkey size and max bio's bi_max_vecs. + */ + max_cache_miss_size = min_t(uint32_t, + (1 << KEY_SIZE_BITS) - 1, BIO_MAX_VECS * PAGE_SECTORS); + if (KEY_INODE(k) != s->iop.inode || KEY_START(k) > bio->bi_iter.bi_sector) { unsigned int bio_sectors = bio_sectors(bio); unsigned int sectors = KEY_INODE(k) == s->iop.inode - ? min_t(uint64_t, INT_MAX, + ? min_t(uint64_t, max_cache_miss_size, KEY_START(k) - bio->bi_iter.bi_sector) - : INT_MAX; + : max_cache_miss_size; int ret = s->d->cache_miss(b, s, bio, sectors); if (ret != MAP_CONTINUE) @@ -547,7 +554,7 @@ static int cache_lookup_fn(struct btree_op *op, struct btree *b, struct bkey *k) if (KEY_DIRTY(k)) s->read_dirty_data = true; - n = bio_next_split(bio, min_t(uint64_t, INT_MAX, + n = bio_next_split(bio, min_t(uint64_t, max_cache_miss_size, KEY_OFFSET(k) - bio->bi_iter.bi_sector), GFP_NOIO, &s->d->bio_split); -- 2.26.2

3 years, 7 months

2
1
0 0

stable-rc/linux-5.4.y baseline: 129 runs, 4 regressions (v5.4.119-142-gd406e11dbc13)

by kernelci.org bot

stable-rc/linux-5.4.y baseline: 129 runs, 4 regressions (v5.4.119-142-gd406e11dbc13) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+--------------+----------+---------------------+------------ hifive-unleashed-a00 | riscv | lab-baylibre | gcc-8 | defconfig | 1 qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-broonie | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.119-… Test: baseline Tree: stable-rc Branch: linux-5.4.y Describe: v5.4.119-142-gd406e11dbc13 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: d406e11dbc1324e375ab1f7c4669abc3cbd994f4 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+--------------+----------+---------------------+------------ hifive-unleashed-a00 | riscv | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/60a30862eb59d390a7b3afa2 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (riscv64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.119-142-gd406e11db… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.119-142-gd406e11db… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-5-g2f114cc7… * baseline.login: https://kernelci.org/test/case/id/60a30862eb59d390a7b3afa3 failing since 178 days (last pass: v5.4.77-152-ga3746663c3479, first fail: v5.4.78) platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+--------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/60a30707fde5acb21cb3afaa Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.119-142-gd406e11db… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.119-142-gd406e11db… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-5-g2f114cc7… * baseline.login: https://kernelci.org/test/case/id/60a30707fde5acb21cb3afab failing since 184 days (last pass: v5.4.77-44-g28fe0e171c204, first fail: v5.4.77-46-ga3e34830d912) platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+--------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-broonie | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/60a306d5b9b2d3a8d4b3afaa Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.119-142-gd406e11db… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.119-142-gd406e11db… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-5-g2f114cc7… * baseline.login: https://kernelci.org/test/case/id/60a306d5b9b2d3a8d4b3afab failing since 184 days (last pass: v5.4.77-44-g28fe0e171c204, first fail: v5.4.77-46-ga3e34830d912) platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+--------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/60a306f32a094259a1b3afba Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.119-142-gd406e11db… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.119-142-gd406e11db… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-5-g2f114cc7… * baseline.login: https://kernelci.org/test/case/id/60a306f32a094259a1b3afbb failing since 184 days (last pass: v5.4.77-44-g28fe0e171c204, first fail: v5.4.77-46-ga3e34830d912)

3 years, 7 months

1
0
0 0

stable-rc/linux-4.9.y baseline: 84 runs, 4 regressions (v4.9.268-224-g447e9f3db5ba)

by kernelci.org bot

stable-rc/linux-4.9.y baseline: 84 runs, 4 regressions (v4.9.268-224-g447e9f3db5ba) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+--------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-broonie | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1 r8a7795-salvator-x | arm64 | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.268-… Test: baseline Tree: stable-rc Branch: linux-4.9.y Describe: v4.9.268-224-g447e9f3db5ba URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 447e9f3db5ba1753207fb9ad6586c102e9d6216b Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+--------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/60a304c2563e1a2cbab3afb2 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.9.y/v4.9.268-224-g447e9f3db… HTML log: https://storage.kernelci.org//stable-rc/linux-4.9.y/v4.9.268-224-g447e9f3db… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-5-g2f114cc7… * baseline.login: https://kernelci.org/test/case/id/60a304c2563e1a2cbab3afb3 failing since 184 days (last pass: v4.9.243-17-g9c24315b745a0, first fail: v4.9.243-26-g7b603f689c1c) platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+--------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-broonie | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/60a304ccd53cb8171cb3af9e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.9.y/v4.9.268-224-g447e9f3db… HTML log: https://storage.kernelci.org//stable-rc/linux-4.9.y/v4.9.268-224-g447e9f3db… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-5-g2f114cc7… * baseline.login: https://kernelci.org/test/case/id/60a304ccd53cb8171cb3af9f failing since 184 days (last pass: v4.9.243-17-g9c24315b745a0, first fail: v4.9.243-26-g7b603f689c1c) platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+--------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/60a304c8d53cb8171cb3af98 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.9.y/v4.9.268-224-g447e9f3db… HTML log: https://storage.kernelci.org//stable-rc/linux-4.9.y/v4.9.268-224-g447e9f3db… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-5-g2f114cc7… * baseline.login: https://kernelci.org/test/case/id/60a304c8d53cb8171cb3af99 failing since 184 days (last pass: v4.9.243-17-g9c24315b745a0, first fail: v4.9.243-26-g7b603f689c1c) platform | arch | lab | compiler | defconfig | regressions ---------------------+-------+--------------+----------+---------------------+------------ r8a7795-salvator-x | arm64 | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/60a305ceb2b24d0cdfb3af9d Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.9.y/v4.9.268-224-g447e9f3db… HTML log: https://storage.kernelci.org//stable-rc/linux-4.9.y/v4.9.268-224-g447e9f3db… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-5-g2f114cc7… * baseline.login: https://kernelci.org/test/case/id/60a305ceb2b24d0cdfb3af9e failing since 180 days (last pass: v4.9.243-17-g9c24315b745a0, first fail: v4.9.243-79-gd3e70b39d31a)

3 years, 7 months

1
0
0 0

✅ PASS: Test report for kernel 5.11.22-rc1 (stable, 6d09fa39)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 6d09fa399bd5 - Linux 5.11.22-rc1 The results of these automated tests are provided below. Overall result: PASSED Merge: OK Compile: OK Tests: OK All kernel binaries, config files, and logs are available for download here: https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefi… Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: aarch64: make options: make -j24 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: make -j24 INSTALL_MOD_STRIP=1 targz-pkg s390x: make options: make -j24 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: make -j24 INSTALL_MOD_STRIP=1 targz-pkg Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ selinux-policy: serge-testsuite ✅ storage: software RAID testing ✅ Storage: swraid mdadm raid_module test 🚧 ✅ xfstests - btrfs 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ Storage blktests 🚧 ✅ Storage block - filesystem fio test 🚧 ✅ Storage block - queue scheduler test 🚧 ✅ Storage nvme - tcp 🚧 ✅ Storage: lvm device-mapper test 🚧 ✅ stress: stress-ng Host 2: ✅ Boot test ✅ ACPI table test ✅ ACPI enabled test ✅ LTP ✅ CIFS Connectathon ✅ POSIX pjd-fstest suites ✅ Loopdev Sanity ✅ jvm - jcstress tests ✅ Memory: fork_mem ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking socket: fuzz ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func - local ✅ Networking route_func - forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking cki netfilter test ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns - transport ✅ Networking ipsec: basic netns - tunnel ✅ Libkcapi AF_ALG test ✅ pciutils: update pci ids test ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ trace: ftrace/tracer 🚧 ❌ xarray-idr-radixtree-test 🚧 ✅ i2c: i2cdetect sanity 🚧 ✅ Firmware test suite 🚧 ✅ Memory function: kaslr 🚧 ✅ audit: audit testsuite test ppc64le: Host 1: ✅ Boot test ✅ LTP ✅ CIFS Connectathon ✅ POSIX pjd-fstest suites ✅ Loopdev Sanity ✅ jvm - jcstress tests ✅ Memory: fork_mem ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking socket: fuzz ✅ Networking route: pmtu ✅ Networking route_func - local ✅ Networking route_func - forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking cki netfilter test ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns - tunnel ✅ Libkcapi AF_ALG test ✅ pciutils: update pci ids test ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ trace: ftrace/tracer 🚧 ❌ xarray-idr-radixtree-test 🚧 ✅ Memory function: kaslr 🚧 ✅ audit: audit testsuite test Host 2: ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ selinux-policy: serge-testsuite ✅ storage: software RAID testing ✅ Storage: swraid mdadm raid_module test 🚧 ✅ xfstests - btrfs 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ Storage blktests 🚧 ✅ Storage block - filesystem fio test 🚧 ✅ Storage block - queue scheduler test 🚧 ✅ Storage nvme - tcp 🚧 ✅ Storage: lvm device-mapper test s390x: Host 1: ✅ Boot test ✅ LTP ✅ CIFS Connectathon ✅ POSIX pjd-fstest suites ✅ Loopdev Sanity ✅ jvm - jcstress tests ✅ Memory: fork_mem ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking route: pmtu ✅ Networking route_func - local ✅ Networking route_func - forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking cki netfilter test ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns - transport ✅ Networking ipsec: basic netns - tunnel ✅ Libkcapi AF_ALG test ✅ trace: ftrace/tracer 🚧 ❌ xarray-idr-radixtree-test 🚧 ✅ Memory function: kaslr 🚧 ✅ audit: audit testsuite test Host 2: ✅ Boot test ✅ selinux-policy: serge-testsuite ✅ Storage: swraid mdadm raid_module test 🚧 ✅ Storage blktests 🚧 ✅ Storage nvme - tcp 🚧 ✅ stress: stress-ng x86_64: Host 1: ✅ Boot test ✅ ACPI table test ✅ LTP ✅ CIFS Connectathon ✅ POSIX pjd-fstest suites ✅ Loopdev Sanity ✅ jvm - jcstress tests ✅ Memory: fork_mem ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking socket: fuzz ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func - local ✅ Networking route_func - forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking cki netfilter test ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns - transport ✅ Networking ipsec: basic netns - tunnel ✅ Libkcapi AF_ALG test ✅ pciutils: sanity smoke test ✅ pciutils: update pci ids test ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ trace: ftrace/tracer 🚧 ❌ xarray-idr-radixtree-test 🚧 ✅ i2c: i2cdetect sanity 🚧 ✅ Firmware test suite 🚧 ✅ Memory function: kaslr 🚧 ✅ audit: audit testsuite test Host 2: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ⚡⚡⚡ Boot test ⚡⚡⚡ xfstests - ext4 ⚡⚡⚡ xfstests - xfs ⚡⚡⚡ xfstests - nfsv4.2 ⚡⚡⚡ selinux-policy: serge-testsuite ⚡⚡⚡ power-management: cpupower/sanity test ⚡⚡⚡ storage: software RAID testing ⚡⚡⚡ Storage: swraid mdadm raid_module test 🚧 ⚡⚡⚡ CPU: Idle Test 🚧 ⚡⚡⚡ xfstests - btrfs 🚧 ⚡⚡⚡ xfstests - cifsv3.11 🚧 ⚡⚡⚡ IPMI driver test 🚧 ⚡⚡⚡ IPMItool loop stress test 🚧 ⚡⚡⚡ Storage blktests 🚧 ⚡⚡⚡ Storage block - filesystem fio test 🚧 ⚡⚡⚡ Storage block - queue scheduler test 🚧 ⚡⚡⚡ Storage nvme - tcp 🚧 ⚡⚡⚡ Storage: lvm device-mapper test 🚧 ⚡⚡⚡ stress: stress-ng Host 3: ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ xfstests - nfsv4.2 ✅ selinux-policy: serge-testsuite ✅ power-management: cpupower/sanity test ✅ storage: software RAID testing ✅ Storage: swraid mdadm raid_module test 🚧 ✅ CPU: Idle Test 🚧 ❌ xfstests - btrfs 🚧 ✅ xfstests - cifsv3.11 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ Storage blktests 🚧 ✅ Storage block - filesystem fio test 🚧 ✅ Storage block - queue scheduler test 🚧 ✅ Storage nvme - tcp 🚧 ✅ Storage: lvm device-mapper test 🚧 ✅ stress: stress-ng Test sources: https://gitlab.com/cki-project/kernel-tests 💚 Pull requests are welcome for new tests or improvements to existing tests! Aborted tests ------------- Tests that didn't complete running successfully are marked with ⚡⚡⚡. If this was caused by an infrastructure issue, we try to mark that explicitly in the report. Waived tests ------------ If the test run included waived tests, they are marked with 🚧. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed. Testing timeout --------------- We aim to provide a report within reasonable timeframe. Tests that haven't finished running yet are marked with ⏱.

3 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2021