January 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 1c0908d8e441 ("rtmutex: Add acquire semantics for rtmutex lock acquisition slow path") ee042be16cb4 ("locking: Apply contention tracepoints in the slow path") d257cc8cb8d5 ("locking/rwsem: Make handoff bit handling more consistent") 7cdacc5f52d6 ("locking/rwsem: Disable preemption for spinning region") 616be87eac9f ("locking/rwbase: Extract __rwbase_write_trylock()") add461325ec5 ("locking/rtmutex: Extend the rtmutex core to support ww_mutex") 1c143c4b65da ("locking/rtmutex: Provide the spin/rwlock core lock function") e17ba59b7e8e ("locking/rtmutex: Guard regular sleeping locks specific functions") 7980aa397cc0 ("locking/rtmutex: Use rt_mutex_wake_q_head") c014ef69b3ac ("locking/rtmutex: Add wake_state to rt_mutex_waiter") 42254105dfe8 ("locking/rwsem: Add rtmutex based R/W semaphore implementation") 943f0edb754f ("locking/rt: Add base code for RT rw_semaphore and rwlock") ebbdc41e90ff ("locking/rtmutex: Provide rt_mutex_slowlock_locked()") 830e6acc8a1c ("locking/rtmutex: Split out the inner parts of 'struct rtmutex'") 531ae4b06a73 ("locking/rtmutex: Split API from implementation") 785159301bed ("locking/rtmutex: Convert macros to inlines") b41cda037655 ("locking/rtmutex: Set proper wait context for lockdep") 2f064a59a11f ("sched: Change task_struct::state") d6c23bb3a2ad ("sched: Add get_current_state()") b03fbd4ff24c ("sched: Introduce task_is_running()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1c0908d8e441631f5b8ba433523cf39339ee2ba0 Mon Sep 17 00:00:00 2001 From: Mel Gorman <mgorman(a)techsingularity.net> Date: Fri, 2 Dec 2022 10:02:23 +0000 Subject: [PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition slow path Jan Kara reported the following bug triggering on 6.0.5-rt14 running dbench on XFS on arm64. kernel BUG at fs/inode.c:625! Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP CPU: 11 PID: 6611 Comm: dbench Tainted: G E 6.0.0-rt14-rt+ #1 pc : clear_inode+0xa0/0xc0 lr : clear_inode+0x38/0xc0 Call trace: clear_inode+0xa0/0xc0 evict+0x160/0x180 iput+0x154/0x240 do_unlinkat+0x184/0x300 __arm64_sys_unlinkat+0x48/0xc0 el0_svc_common.constprop.4+0xe4/0x2c0 do_el0_svc+0xac/0x100 el0_svc+0x78/0x200 el0t_64_sync_handler+0x9c/0xc0 el0t_64_sync+0x19c/0x1a0 It also affects 6.1-rc7-rt5 and affects a preempt-rt fork of 5.14 so this is likely a bug that existed forever and only became visible when ARM support was added to preempt-rt. The same problem does not occur on x86-64 and he also reported that converting sb->s_inode_wblist_lock to raw_spinlock_t makes the problem disappear indicating that the RT spinlock variant is the problem. Which in turn means that RT mutexes on ARM64 and any other weakly ordered architecture are affected by this independent of RT. Will Deacon observed: "I'd be more inclined to be suspicious of the slowpath tbh, as we need to make sure that we have acquire semantics on all paths where the lock can be taken. Looking at the rtmutex code, this really isn't obvious to me -- for example, try_to_take_rt_mutex() appears to be able to return via the 'takeit' label without acquire semantics and it looks like we might be relying on the caller's subsequent _unlock_ of the wait_lock for ordering, but that will give us release semantics which aren't correct." Sebastian Andrzej Siewior prototyped a fix that does work based on that comment but it was a little bit overkill and added some fences that should not be necessary. The lock owner is updated with an IRQ-safe raw spinlock held, but the spin_unlock does not provide acquire semantics which are needed when acquiring a mutex. Adds the necessary acquire semantics for lock owner updates in the slow path acquisition and the waiter bit logic. It successfully completed 10 iterations of the dbench workload while the vanilla kernel fails on the first iteration. [ bigeasy(a)linutronix.de: Initial prototype fix ] Fixes: 700318d1d7b38 ("locking/rtmutex: Use acquire/release semantics") Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") Reported-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20221202100223.6mevpbl7i6x5udfd@techsingularity.n… diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 7779ee8abc2a..010cf4e6d0b8 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -89,15 +89,31 @@ static inline int __ww_mutex_check_kill(struct rt_mutex *lock, * set this bit before looking at the lock. */ -static __always_inline void -rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) +static __always_inline struct task_struct * +rt_mutex_owner_encode(struct rt_mutex_base *lock, struct task_struct *owner) { unsigned long val = (unsigned long)owner; if (rt_mutex_has_waiters(lock)) val |= RT_MUTEX_HAS_WAITERS; - WRITE_ONCE(lock->owner, (struct task_struct *)val); + return (struct task_struct *)val; +} + +static __always_inline void +rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) +{ + /* + * lock->wait_lock is held but explicit acquire semantics are needed + * for a new lock owner so WRITE_ONCE is insufficient. + */ + xchg_acquire(&lock->owner, rt_mutex_owner_encode(lock, owner)); +} + +static __always_inline void rt_mutex_clear_owner(struct rt_mutex_base *lock) +{ + /* lock->wait_lock is held so the unlock provides release semantics. */ + WRITE_ONCE(lock->owner, rt_mutex_owner_encode(lock, NULL)); } static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) @@ -106,7 +122,8 @@ static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) ((unsigned long)lock->owner & ~RT_MUTEX_HAS_WAITERS); } -static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) +static __always_inline void +fixup_rt_mutex_waiters(struct rt_mutex_base *lock, bool acquire_lock) { unsigned long owner, *p = (unsigned long *) &lock->owner; @@ -172,8 +189,21 @@ static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) * still set. */ owner = READ_ONCE(*p); - if (owner & RT_MUTEX_HAS_WAITERS) - WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + if (owner & RT_MUTEX_HAS_WAITERS) { + /* + * See rt_mutex_set_owner() and rt_mutex_clear_owner() on + * why xchg_acquire() is used for updating owner for + * locking and WRITE_ONCE() for unlocking. + * + * WRITE_ONCE() would work for the acquire case too, but + * in case that the lock acquisition failed it might + * force other lockers into the slow path unnecessarily. + */ + if (acquire_lock) + xchg_acquire(p, owner & ~RT_MUTEX_HAS_WAITERS); + else + WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + } } /* @@ -208,6 +238,13 @@ static __always_inline void mark_rt_mutex_waiters(struct rt_mutex_base *lock) owner = *p; } while (cmpxchg_relaxed(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner); + + /* + * The cmpxchg loop above is relaxed to avoid back-to-back ACQUIRE + * operations in the event of contention. Ensure the successful + * cmpxchg is visible. + */ + smp_mb__after_atomic(); } /* @@ -1243,7 +1280,7 @@ static int __sched __rt_mutex_slowtrylock(struct rt_mutex_base *lock) * try_to_take_rt_mutex() sets the lock waiters bit * unconditionally. Clean this up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); return ret; } @@ -1604,7 +1641,7 @@ static int __sched __rt_mutex_slowlock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit * unconditionally. We might have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); trace_contention_end(lock, ret); @@ -1719,7 +1756,7 @@ static void __sched rtlock_slowlock_locked(struct rt_mutex_base *lock) * try_to_take_rt_mutex() sets the waiter bit unconditionally. * We might have to fix that up: */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); debug_rt_mutex_free_waiter(&waiter); trace_contention_end(lock, 0); diff --git a/kernel/locking/rtmutex_api.c b/kernel/locking/rtmutex_api.c index 900220941caa..cb9fdff76a8a 100644 --- a/kernel/locking/rtmutex_api.c +++ b/kernel/locking/rtmutex_api.c @@ -267,7 +267,7 @@ void __sched rt_mutex_init_proxy_locked(struct rt_mutex_base *lock, void __sched rt_mutex_proxy_unlock(struct rt_mutex_base *lock) { debug_rt_mutex_proxy_unlock(lock); - rt_mutex_set_owner(lock, NULL); + rt_mutex_clear_owner(lock); } /** @@ -382,7 +382,7 @@ int __sched rt_mutex_wait_proxy_lock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); raw_spin_unlock_irq(&lock->wait_lock); return ret; @@ -438,7 +438,7 @@ bool __sched rt_mutex_cleanup_proxy_lock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, false); raw_spin_unlock_irq(&lock->wait_lock);

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 1c0908d8e441 ("rtmutex: Add acquire semantics for rtmutex lock acquisition slow path") ee042be16cb4 ("locking: Apply contention tracepoints in the slow path") d257cc8cb8d5 ("locking/rwsem: Make handoff bit handling more consistent") 7cdacc5f52d6 ("locking/rwsem: Disable preemption for spinning region") 616be87eac9f ("locking/rwbase: Extract __rwbase_write_trylock()") add461325ec5 ("locking/rtmutex: Extend the rtmutex core to support ww_mutex") 1c143c4b65da ("locking/rtmutex: Provide the spin/rwlock core lock function") e17ba59b7e8e ("locking/rtmutex: Guard regular sleeping locks specific functions") 7980aa397cc0 ("locking/rtmutex: Use rt_mutex_wake_q_head") c014ef69b3ac ("locking/rtmutex: Add wake_state to rt_mutex_waiter") 42254105dfe8 ("locking/rwsem: Add rtmutex based R/W semaphore implementation") 943f0edb754f ("locking/rt: Add base code for RT rw_semaphore and rwlock") ebbdc41e90ff ("locking/rtmutex: Provide rt_mutex_slowlock_locked()") 830e6acc8a1c ("locking/rtmutex: Split out the inner parts of 'struct rtmutex'") 531ae4b06a73 ("locking/rtmutex: Split API from implementation") 785159301bed ("locking/rtmutex: Convert macros to inlines") b41cda037655 ("locking/rtmutex: Set proper wait context for lockdep") 2f064a59a11f ("sched: Change task_struct::state") d6c23bb3a2ad ("sched: Add get_current_state()") b03fbd4ff24c ("sched: Introduce task_is_running()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1c0908d8e441631f5b8ba433523cf39339ee2ba0 Mon Sep 17 00:00:00 2001 From: Mel Gorman <mgorman(a)techsingularity.net> Date: Fri, 2 Dec 2022 10:02:23 +0000 Subject: [PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition slow path Jan Kara reported the following bug triggering on 6.0.5-rt14 running dbench on XFS on arm64. kernel BUG at fs/inode.c:625! Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP CPU: 11 PID: 6611 Comm: dbench Tainted: G E 6.0.0-rt14-rt+ #1 pc : clear_inode+0xa0/0xc0 lr : clear_inode+0x38/0xc0 Call trace: clear_inode+0xa0/0xc0 evict+0x160/0x180 iput+0x154/0x240 do_unlinkat+0x184/0x300 __arm64_sys_unlinkat+0x48/0xc0 el0_svc_common.constprop.4+0xe4/0x2c0 do_el0_svc+0xac/0x100 el0_svc+0x78/0x200 el0t_64_sync_handler+0x9c/0xc0 el0t_64_sync+0x19c/0x1a0 It also affects 6.1-rc7-rt5 and affects a preempt-rt fork of 5.14 so this is likely a bug that existed forever and only became visible when ARM support was added to preempt-rt. The same problem does not occur on x86-64 and he also reported that converting sb->s_inode_wblist_lock to raw_spinlock_t makes the problem disappear indicating that the RT spinlock variant is the problem. Which in turn means that RT mutexes on ARM64 and any other weakly ordered architecture are affected by this independent of RT. Will Deacon observed: "I'd be more inclined to be suspicious of the slowpath tbh, as we need to make sure that we have acquire semantics on all paths where the lock can be taken. Looking at the rtmutex code, this really isn't obvious to me -- for example, try_to_take_rt_mutex() appears to be able to return via the 'takeit' label without acquire semantics and it looks like we might be relying on the caller's subsequent _unlock_ of the wait_lock for ordering, but that will give us release semantics which aren't correct." Sebastian Andrzej Siewior prototyped a fix that does work based on that comment but it was a little bit overkill and added some fences that should not be necessary. The lock owner is updated with an IRQ-safe raw spinlock held, but the spin_unlock does not provide acquire semantics which are needed when acquiring a mutex. Adds the necessary acquire semantics for lock owner updates in the slow path acquisition and the waiter bit logic. It successfully completed 10 iterations of the dbench workload while the vanilla kernel fails on the first iteration. [ bigeasy(a)linutronix.de: Initial prototype fix ] Fixes: 700318d1d7b38 ("locking/rtmutex: Use acquire/release semantics") Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") Reported-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20221202100223.6mevpbl7i6x5udfd@techsingularity.n… diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 7779ee8abc2a..010cf4e6d0b8 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -89,15 +89,31 @@ static inline int __ww_mutex_check_kill(struct rt_mutex *lock, * set this bit before looking at the lock. */ -static __always_inline void -rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) +static __always_inline struct task_struct * +rt_mutex_owner_encode(struct rt_mutex_base *lock, struct task_struct *owner) { unsigned long val = (unsigned long)owner; if (rt_mutex_has_waiters(lock)) val |= RT_MUTEX_HAS_WAITERS; - WRITE_ONCE(lock->owner, (struct task_struct *)val); + return (struct task_struct *)val; +} + +static __always_inline void +rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) +{ + /* + * lock->wait_lock is held but explicit acquire semantics are needed + * for a new lock owner so WRITE_ONCE is insufficient. + */ + xchg_acquire(&lock->owner, rt_mutex_owner_encode(lock, owner)); +} + +static __always_inline void rt_mutex_clear_owner(struct rt_mutex_base *lock) +{ + /* lock->wait_lock is held so the unlock provides release semantics. */ + WRITE_ONCE(lock->owner, rt_mutex_owner_encode(lock, NULL)); } static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) @@ -106,7 +122,8 @@ static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) ((unsigned long)lock->owner & ~RT_MUTEX_HAS_WAITERS); } -static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) +static __always_inline void +fixup_rt_mutex_waiters(struct rt_mutex_base *lock, bool acquire_lock) { unsigned long owner, *p = (unsigned long *) &lock->owner; @@ -172,8 +189,21 @@ static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) * still set. */ owner = READ_ONCE(*p); - if (owner & RT_MUTEX_HAS_WAITERS) - WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + if (owner & RT_MUTEX_HAS_WAITERS) { + /* + * See rt_mutex_set_owner() and rt_mutex_clear_owner() on + * why xchg_acquire() is used for updating owner for + * locking and WRITE_ONCE() for unlocking. + * + * WRITE_ONCE() would work for the acquire case too, but + * in case that the lock acquisition failed it might + * force other lockers into the slow path unnecessarily. + */ + if (acquire_lock) + xchg_acquire(p, owner & ~RT_MUTEX_HAS_WAITERS); + else + WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + } } /* @@ -208,6 +238,13 @@ static __always_inline void mark_rt_mutex_waiters(struct rt_mutex_base *lock) owner = *p; } while (cmpxchg_relaxed(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner); + + /* + * The cmpxchg loop above is relaxed to avoid back-to-back ACQUIRE + * operations in the event of contention. Ensure the successful + * cmpxchg is visible. + */ + smp_mb__after_atomic(); } /* @@ -1243,7 +1280,7 @@ static int __sched __rt_mutex_slowtrylock(struct rt_mutex_base *lock) * try_to_take_rt_mutex() sets the lock waiters bit * unconditionally. Clean this up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); return ret; } @@ -1604,7 +1641,7 @@ static int __sched __rt_mutex_slowlock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit * unconditionally. We might have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); trace_contention_end(lock, ret); @@ -1719,7 +1756,7 @@ static void __sched rtlock_slowlock_locked(struct rt_mutex_base *lock) * try_to_take_rt_mutex() sets the waiter bit unconditionally. * We might have to fix that up: */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); debug_rt_mutex_free_waiter(&waiter); trace_contention_end(lock, 0); diff --git a/kernel/locking/rtmutex_api.c b/kernel/locking/rtmutex_api.c index 900220941caa..cb9fdff76a8a 100644 --- a/kernel/locking/rtmutex_api.c +++ b/kernel/locking/rtmutex_api.c @@ -267,7 +267,7 @@ void __sched rt_mutex_init_proxy_locked(struct rt_mutex_base *lock, void __sched rt_mutex_proxy_unlock(struct rt_mutex_base *lock) { debug_rt_mutex_proxy_unlock(lock); - rt_mutex_set_owner(lock, NULL); + rt_mutex_clear_owner(lock); } /** @@ -382,7 +382,7 @@ int __sched rt_mutex_wait_proxy_lock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); raw_spin_unlock_irq(&lock->wait_lock); return ret; @@ -438,7 +438,7 @@ bool __sched rt_mutex_cleanup_proxy_lock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, false); raw_spin_unlock_irq(&lock->wait_lock);

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 1c0908d8e441 ("rtmutex: Add acquire semantics for rtmutex lock acquisition slow path") ee042be16cb4 ("locking: Apply contention tracepoints in the slow path") d257cc8cb8d5 ("locking/rwsem: Make handoff bit handling more consistent") 7cdacc5f52d6 ("locking/rwsem: Disable preemption for spinning region") 616be87eac9f ("locking/rwbase: Extract __rwbase_write_trylock()") add461325ec5 ("locking/rtmutex: Extend the rtmutex core to support ww_mutex") 1c143c4b65da ("locking/rtmutex: Provide the spin/rwlock core lock function") e17ba59b7e8e ("locking/rtmutex: Guard regular sleeping locks specific functions") 7980aa397cc0 ("locking/rtmutex: Use rt_mutex_wake_q_head") c014ef69b3ac ("locking/rtmutex: Add wake_state to rt_mutex_waiter") 42254105dfe8 ("locking/rwsem: Add rtmutex based R/W semaphore implementation") 943f0edb754f ("locking/rt: Add base code for RT rw_semaphore and rwlock") ebbdc41e90ff ("locking/rtmutex: Provide rt_mutex_slowlock_locked()") 830e6acc8a1c ("locking/rtmutex: Split out the inner parts of 'struct rtmutex'") 531ae4b06a73 ("locking/rtmutex: Split API from implementation") 785159301bed ("locking/rtmutex: Convert macros to inlines") b41cda037655 ("locking/rtmutex: Set proper wait context for lockdep") 2f064a59a11f ("sched: Change task_struct::state") d6c23bb3a2ad ("sched: Add get_current_state()") b03fbd4ff24c ("sched: Introduce task_is_running()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1c0908d8e441631f5b8ba433523cf39339ee2ba0 Mon Sep 17 00:00:00 2001 From: Mel Gorman <mgorman(a)techsingularity.net> Date: Fri, 2 Dec 2022 10:02:23 +0000 Subject: [PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition slow path Jan Kara reported the following bug triggering on 6.0.5-rt14 running dbench on XFS on arm64. kernel BUG at fs/inode.c:625! Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP CPU: 11 PID: 6611 Comm: dbench Tainted: G E 6.0.0-rt14-rt+ #1 pc : clear_inode+0xa0/0xc0 lr : clear_inode+0x38/0xc0 Call trace: clear_inode+0xa0/0xc0 evict+0x160/0x180 iput+0x154/0x240 do_unlinkat+0x184/0x300 __arm64_sys_unlinkat+0x48/0xc0 el0_svc_common.constprop.4+0xe4/0x2c0 do_el0_svc+0xac/0x100 el0_svc+0x78/0x200 el0t_64_sync_handler+0x9c/0xc0 el0t_64_sync+0x19c/0x1a0 It also affects 6.1-rc7-rt5 and affects a preempt-rt fork of 5.14 so this is likely a bug that existed forever and only became visible when ARM support was added to preempt-rt. The same problem does not occur on x86-64 and he also reported that converting sb->s_inode_wblist_lock to raw_spinlock_t makes the problem disappear indicating that the RT spinlock variant is the problem. Which in turn means that RT mutexes on ARM64 and any other weakly ordered architecture are affected by this independent of RT. Will Deacon observed: "I'd be more inclined to be suspicious of the slowpath tbh, as we need to make sure that we have acquire semantics on all paths where the lock can be taken. Looking at the rtmutex code, this really isn't obvious to me -- for example, try_to_take_rt_mutex() appears to be able to return via the 'takeit' label without acquire semantics and it looks like we might be relying on the caller's subsequent _unlock_ of the wait_lock for ordering, but that will give us release semantics which aren't correct." Sebastian Andrzej Siewior prototyped a fix that does work based on that comment but it was a little bit overkill and added some fences that should not be necessary. The lock owner is updated with an IRQ-safe raw spinlock held, but the spin_unlock does not provide acquire semantics which are needed when acquiring a mutex. Adds the necessary acquire semantics for lock owner updates in the slow path acquisition and the waiter bit logic. It successfully completed 10 iterations of the dbench workload while the vanilla kernel fails on the first iteration. [ bigeasy(a)linutronix.de: Initial prototype fix ] Fixes: 700318d1d7b38 ("locking/rtmutex: Use acquire/release semantics") Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") Reported-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20221202100223.6mevpbl7i6x5udfd@techsingularity.n… diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 7779ee8abc2a..010cf4e6d0b8 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -89,15 +89,31 @@ static inline int __ww_mutex_check_kill(struct rt_mutex *lock, * set this bit before looking at the lock. */ -static __always_inline void -rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) +static __always_inline struct task_struct * +rt_mutex_owner_encode(struct rt_mutex_base *lock, struct task_struct *owner) { unsigned long val = (unsigned long)owner; if (rt_mutex_has_waiters(lock)) val |= RT_MUTEX_HAS_WAITERS; - WRITE_ONCE(lock->owner, (struct task_struct *)val); + return (struct task_struct *)val; +} + +static __always_inline void +rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) +{ + /* + * lock->wait_lock is held but explicit acquire semantics are needed + * for a new lock owner so WRITE_ONCE is insufficient. + */ + xchg_acquire(&lock->owner, rt_mutex_owner_encode(lock, owner)); +} + +static __always_inline void rt_mutex_clear_owner(struct rt_mutex_base *lock) +{ + /* lock->wait_lock is held so the unlock provides release semantics. */ + WRITE_ONCE(lock->owner, rt_mutex_owner_encode(lock, NULL)); } static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) @@ -106,7 +122,8 @@ static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) ((unsigned long)lock->owner & ~RT_MUTEX_HAS_WAITERS); } -static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) +static __always_inline void +fixup_rt_mutex_waiters(struct rt_mutex_base *lock, bool acquire_lock) { unsigned long owner, *p = (unsigned long *) &lock->owner; @@ -172,8 +189,21 @@ static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) * still set. */ owner = READ_ONCE(*p); - if (owner & RT_MUTEX_HAS_WAITERS) - WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + if (owner & RT_MUTEX_HAS_WAITERS) { + /* + * See rt_mutex_set_owner() and rt_mutex_clear_owner() on + * why xchg_acquire() is used for updating owner for + * locking and WRITE_ONCE() for unlocking. + * + * WRITE_ONCE() would work for the acquire case too, but + * in case that the lock acquisition failed it might + * force other lockers into the slow path unnecessarily. + */ + if (acquire_lock) + xchg_acquire(p, owner & ~RT_MUTEX_HAS_WAITERS); + else + WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + } } /* @@ -208,6 +238,13 @@ static __always_inline void mark_rt_mutex_waiters(struct rt_mutex_base *lock) owner = *p; } while (cmpxchg_relaxed(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner); + + /* + * The cmpxchg loop above is relaxed to avoid back-to-back ACQUIRE + * operations in the event of contention. Ensure the successful + * cmpxchg is visible. + */ + smp_mb__after_atomic(); } /* @@ -1243,7 +1280,7 @@ static int __sched __rt_mutex_slowtrylock(struct rt_mutex_base *lock) * try_to_take_rt_mutex() sets the lock waiters bit * unconditionally. Clean this up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); return ret; } @@ -1604,7 +1641,7 @@ static int __sched __rt_mutex_slowlock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit * unconditionally. We might have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); trace_contention_end(lock, ret); @@ -1719,7 +1756,7 @@ static void __sched rtlock_slowlock_locked(struct rt_mutex_base *lock) * try_to_take_rt_mutex() sets the waiter bit unconditionally. * We might have to fix that up: */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); debug_rt_mutex_free_waiter(&waiter); trace_contention_end(lock, 0); diff --git a/kernel/locking/rtmutex_api.c b/kernel/locking/rtmutex_api.c index 900220941caa..cb9fdff76a8a 100644 --- a/kernel/locking/rtmutex_api.c +++ b/kernel/locking/rtmutex_api.c @@ -267,7 +267,7 @@ void __sched rt_mutex_init_proxy_locked(struct rt_mutex_base *lock, void __sched rt_mutex_proxy_unlock(struct rt_mutex_base *lock) { debug_rt_mutex_proxy_unlock(lock); - rt_mutex_set_owner(lock, NULL); + rt_mutex_clear_owner(lock); } /** @@ -382,7 +382,7 @@ int __sched rt_mutex_wait_proxy_lock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); raw_spin_unlock_irq(&lock->wait_lock); return ret; @@ -438,7 +438,7 @@ bool __sched rt_mutex_cleanup_proxy_lock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, false); raw_spin_unlock_irq(&lock->wait_lock);

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 1c0908d8e441 ("rtmutex: Add acquire semantics for rtmutex lock acquisition slow path") ee042be16cb4 ("locking: Apply contention tracepoints in the slow path") d257cc8cb8d5 ("locking/rwsem: Make handoff bit handling more consistent") 7cdacc5f52d6 ("locking/rwsem: Disable preemption for spinning region") 616be87eac9f ("locking/rwbase: Extract __rwbase_write_trylock()") add461325ec5 ("locking/rtmutex: Extend the rtmutex core to support ww_mutex") 1c143c4b65da ("locking/rtmutex: Provide the spin/rwlock core lock function") e17ba59b7e8e ("locking/rtmutex: Guard regular sleeping locks specific functions") 7980aa397cc0 ("locking/rtmutex: Use rt_mutex_wake_q_head") c014ef69b3ac ("locking/rtmutex: Add wake_state to rt_mutex_waiter") 42254105dfe8 ("locking/rwsem: Add rtmutex based R/W semaphore implementation") 943f0edb754f ("locking/rt: Add base code for RT rw_semaphore and rwlock") ebbdc41e90ff ("locking/rtmutex: Provide rt_mutex_slowlock_locked()") 830e6acc8a1c ("locking/rtmutex: Split out the inner parts of 'struct rtmutex'") 531ae4b06a73 ("locking/rtmutex: Split API from implementation") 785159301bed ("locking/rtmutex: Convert macros to inlines") b41cda037655 ("locking/rtmutex: Set proper wait context for lockdep") 2f064a59a11f ("sched: Change task_struct::state") d6c23bb3a2ad ("sched: Add get_current_state()") b03fbd4ff24c ("sched: Introduce task_is_running()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1c0908d8e441631f5b8ba433523cf39339ee2ba0 Mon Sep 17 00:00:00 2001 From: Mel Gorman <mgorman(a)techsingularity.net> Date: Fri, 2 Dec 2022 10:02:23 +0000 Subject: [PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition slow path Jan Kara reported the following bug triggering on 6.0.5-rt14 running dbench on XFS on arm64. kernel BUG at fs/inode.c:625! Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP CPU: 11 PID: 6611 Comm: dbench Tainted: G E 6.0.0-rt14-rt+ #1 pc : clear_inode+0xa0/0xc0 lr : clear_inode+0x38/0xc0 Call trace: clear_inode+0xa0/0xc0 evict+0x160/0x180 iput+0x154/0x240 do_unlinkat+0x184/0x300 __arm64_sys_unlinkat+0x48/0xc0 el0_svc_common.constprop.4+0xe4/0x2c0 do_el0_svc+0xac/0x100 el0_svc+0x78/0x200 el0t_64_sync_handler+0x9c/0xc0 el0t_64_sync+0x19c/0x1a0 It also affects 6.1-rc7-rt5 and affects a preempt-rt fork of 5.14 so this is likely a bug that existed forever and only became visible when ARM support was added to preempt-rt. The same problem does not occur on x86-64 and he also reported that converting sb->s_inode_wblist_lock to raw_spinlock_t makes the problem disappear indicating that the RT spinlock variant is the problem. Which in turn means that RT mutexes on ARM64 and any other weakly ordered architecture are affected by this independent of RT. Will Deacon observed: "I'd be more inclined to be suspicious of the slowpath tbh, as we need to make sure that we have acquire semantics on all paths where the lock can be taken. Looking at the rtmutex code, this really isn't obvious to me -- for example, try_to_take_rt_mutex() appears to be able to return via the 'takeit' label without acquire semantics and it looks like we might be relying on the caller's subsequent _unlock_ of the wait_lock for ordering, but that will give us release semantics which aren't correct." Sebastian Andrzej Siewior prototyped a fix that does work based on that comment but it was a little bit overkill and added some fences that should not be necessary. The lock owner is updated with an IRQ-safe raw spinlock held, but the spin_unlock does not provide acquire semantics which are needed when acquiring a mutex. Adds the necessary acquire semantics for lock owner updates in the slow path acquisition and the waiter bit logic. It successfully completed 10 iterations of the dbench workload while the vanilla kernel fails on the first iteration. [ bigeasy(a)linutronix.de: Initial prototype fix ] Fixes: 700318d1d7b38 ("locking/rtmutex: Use acquire/release semantics") Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") Reported-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20221202100223.6mevpbl7i6x5udfd@techsingularity.n… diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 7779ee8abc2a..010cf4e6d0b8 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -89,15 +89,31 @@ static inline int __ww_mutex_check_kill(struct rt_mutex *lock, * set this bit before looking at the lock. */ -static __always_inline void -rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) +static __always_inline struct task_struct * +rt_mutex_owner_encode(struct rt_mutex_base *lock, struct task_struct *owner) { unsigned long val = (unsigned long)owner; if (rt_mutex_has_waiters(lock)) val |= RT_MUTEX_HAS_WAITERS; - WRITE_ONCE(lock->owner, (struct task_struct *)val); + return (struct task_struct *)val; +} + +static __always_inline void +rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) +{ + /* + * lock->wait_lock is held but explicit acquire semantics are needed + * for a new lock owner so WRITE_ONCE is insufficient. + */ + xchg_acquire(&lock->owner, rt_mutex_owner_encode(lock, owner)); +} + +static __always_inline void rt_mutex_clear_owner(struct rt_mutex_base *lock) +{ + /* lock->wait_lock is held so the unlock provides release semantics. */ + WRITE_ONCE(lock->owner, rt_mutex_owner_encode(lock, NULL)); } static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) @@ -106,7 +122,8 @@ static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) ((unsigned long)lock->owner & ~RT_MUTEX_HAS_WAITERS); } -static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) +static __always_inline void +fixup_rt_mutex_waiters(struct rt_mutex_base *lock, bool acquire_lock) { unsigned long owner, *p = (unsigned long *) &lock->owner; @@ -172,8 +189,21 @@ static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) * still set. */ owner = READ_ONCE(*p); - if (owner & RT_MUTEX_HAS_WAITERS) - WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + if (owner & RT_MUTEX_HAS_WAITERS) { + /* + * See rt_mutex_set_owner() and rt_mutex_clear_owner() on + * why xchg_acquire() is used for updating owner for + * locking and WRITE_ONCE() for unlocking. + * + * WRITE_ONCE() would work for the acquire case too, but + * in case that the lock acquisition failed it might + * force other lockers into the slow path unnecessarily. + */ + if (acquire_lock) + xchg_acquire(p, owner & ~RT_MUTEX_HAS_WAITERS); + else + WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + } } /* @@ -208,6 +238,13 @@ static __always_inline void mark_rt_mutex_waiters(struct rt_mutex_base *lock) owner = *p; } while (cmpxchg_relaxed(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner); + + /* + * The cmpxchg loop above is relaxed to avoid back-to-back ACQUIRE + * operations in the event of contention. Ensure the successful + * cmpxchg is visible. + */ + smp_mb__after_atomic(); } /* @@ -1243,7 +1280,7 @@ static int __sched __rt_mutex_slowtrylock(struct rt_mutex_base *lock) * try_to_take_rt_mutex() sets the lock waiters bit * unconditionally. Clean this up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); return ret; } @@ -1604,7 +1641,7 @@ static int __sched __rt_mutex_slowlock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit * unconditionally. We might have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); trace_contention_end(lock, ret); @@ -1719,7 +1756,7 @@ static void __sched rtlock_slowlock_locked(struct rt_mutex_base *lock) * try_to_take_rt_mutex() sets the waiter bit unconditionally. * We might have to fix that up: */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); debug_rt_mutex_free_waiter(&waiter); trace_contention_end(lock, 0); diff --git a/kernel/locking/rtmutex_api.c b/kernel/locking/rtmutex_api.c index 900220941caa..cb9fdff76a8a 100644 --- a/kernel/locking/rtmutex_api.c +++ b/kernel/locking/rtmutex_api.c @@ -267,7 +267,7 @@ void __sched rt_mutex_init_proxy_locked(struct rt_mutex_base *lock, void __sched rt_mutex_proxy_unlock(struct rt_mutex_base *lock) { debug_rt_mutex_proxy_unlock(lock); - rt_mutex_set_owner(lock, NULL); + rt_mutex_clear_owner(lock); } /** @@ -382,7 +382,7 @@ int __sched rt_mutex_wait_proxy_lock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); raw_spin_unlock_irq(&lock->wait_lock); return ret; @@ -438,7 +438,7 @@ bool __sched rt_mutex_cleanup_proxy_lock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, false); raw_spin_unlock_irq(&lock->wait_lock);

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Possible dependencies: 1c0908d8e441 ("rtmutex: Add acquire semantics for rtmutex lock acquisition slow path") ee042be16cb4 ("locking: Apply contention tracepoints in the slow path") d257cc8cb8d5 ("locking/rwsem: Make handoff bit handling more consistent") 7cdacc5f52d6 ("locking/rwsem: Disable preemption for spinning region") 616be87eac9f ("locking/rwbase: Extract __rwbase_write_trylock()") add461325ec5 ("locking/rtmutex: Extend the rtmutex core to support ww_mutex") 1c143c4b65da ("locking/rtmutex: Provide the spin/rwlock core lock function") e17ba59b7e8e ("locking/rtmutex: Guard regular sleeping locks specific functions") 7980aa397cc0 ("locking/rtmutex: Use rt_mutex_wake_q_head") c014ef69b3ac ("locking/rtmutex: Add wake_state to rt_mutex_waiter") 42254105dfe8 ("locking/rwsem: Add rtmutex based R/W semaphore implementation") 943f0edb754f ("locking/rt: Add base code for RT rw_semaphore and rwlock") ebbdc41e90ff ("locking/rtmutex: Provide rt_mutex_slowlock_locked()") 830e6acc8a1c ("locking/rtmutex: Split out the inner parts of 'struct rtmutex'") 531ae4b06a73 ("locking/rtmutex: Split API from implementation") 785159301bed ("locking/rtmutex: Convert macros to inlines") b41cda037655 ("locking/rtmutex: Set proper wait context for lockdep") 2f064a59a11f ("sched: Change task_struct::state") d6c23bb3a2ad ("sched: Add get_current_state()") b03fbd4ff24c ("sched: Introduce task_is_running()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1c0908d8e441631f5b8ba433523cf39339ee2ba0 Mon Sep 17 00:00:00 2001 From: Mel Gorman <mgorman(a)techsingularity.net> Date: Fri, 2 Dec 2022 10:02:23 +0000 Subject: [PATCH] rtmutex: Add acquire semantics for rtmutex lock acquisition slow path Jan Kara reported the following bug triggering on 6.0.5-rt14 running dbench on XFS on arm64. kernel BUG at fs/inode.c:625! Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP CPU: 11 PID: 6611 Comm: dbench Tainted: G E 6.0.0-rt14-rt+ #1 pc : clear_inode+0xa0/0xc0 lr : clear_inode+0x38/0xc0 Call trace: clear_inode+0xa0/0xc0 evict+0x160/0x180 iput+0x154/0x240 do_unlinkat+0x184/0x300 __arm64_sys_unlinkat+0x48/0xc0 el0_svc_common.constprop.4+0xe4/0x2c0 do_el0_svc+0xac/0x100 el0_svc+0x78/0x200 el0t_64_sync_handler+0x9c/0xc0 el0t_64_sync+0x19c/0x1a0 It also affects 6.1-rc7-rt5 and affects a preempt-rt fork of 5.14 so this is likely a bug that existed forever and only became visible when ARM support was added to preempt-rt. The same problem does not occur on x86-64 and he also reported that converting sb->s_inode_wblist_lock to raw_spinlock_t makes the problem disappear indicating that the RT spinlock variant is the problem. Which in turn means that RT mutexes on ARM64 and any other weakly ordered architecture are affected by this independent of RT. Will Deacon observed: "I'd be more inclined to be suspicious of the slowpath tbh, as we need to make sure that we have acquire semantics on all paths where the lock can be taken. Looking at the rtmutex code, this really isn't obvious to me -- for example, try_to_take_rt_mutex() appears to be able to return via the 'takeit' label without acquire semantics and it looks like we might be relying on the caller's subsequent _unlock_ of the wait_lock for ordering, but that will give us release semantics which aren't correct." Sebastian Andrzej Siewior prototyped a fix that does work based on that comment but it was a little bit overkill and added some fences that should not be necessary. The lock owner is updated with an IRQ-safe raw spinlock held, but the spin_unlock does not provide acquire semantics which are needed when acquiring a mutex. Adds the necessary acquire semantics for lock owner updates in the slow path acquisition and the waiter bit logic. It successfully completed 10 iterations of the dbench workload while the vanilla kernel fails on the first iteration. [ bigeasy(a)linutronix.de: Initial prototype fix ] Fixes: 700318d1d7b38 ("locking/rtmutex: Use acquire/release semantics") Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") Reported-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20221202100223.6mevpbl7i6x5udfd@techsingularity.n… diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 7779ee8abc2a..010cf4e6d0b8 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -89,15 +89,31 @@ static inline int __ww_mutex_check_kill(struct rt_mutex *lock, * set this bit before looking at the lock. */ -static __always_inline void -rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) +static __always_inline struct task_struct * +rt_mutex_owner_encode(struct rt_mutex_base *lock, struct task_struct *owner) { unsigned long val = (unsigned long)owner; if (rt_mutex_has_waiters(lock)) val |= RT_MUTEX_HAS_WAITERS; - WRITE_ONCE(lock->owner, (struct task_struct *)val); + return (struct task_struct *)val; +} + +static __always_inline void +rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) +{ + /* + * lock->wait_lock is held but explicit acquire semantics are needed + * for a new lock owner so WRITE_ONCE is insufficient. + */ + xchg_acquire(&lock->owner, rt_mutex_owner_encode(lock, owner)); +} + +static __always_inline void rt_mutex_clear_owner(struct rt_mutex_base *lock) +{ + /* lock->wait_lock is held so the unlock provides release semantics. */ + WRITE_ONCE(lock->owner, rt_mutex_owner_encode(lock, NULL)); } static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) @@ -106,7 +122,8 @@ static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) ((unsigned long)lock->owner & ~RT_MUTEX_HAS_WAITERS); } -static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) +static __always_inline void +fixup_rt_mutex_waiters(struct rt_mutex_base *lock, bool acquire_lock) { unsigned long owner, *p = (unsigned long *) &lock->owner; @@ -172,8 +189,21 @@ static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) * still set. */ owner = READ_ONCE(*p); - if (owner & RT_MUTEX_HAS_WAITERS) - WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + if (owner & RT_MUTEX_HAS_WAITERS) { + /* + * See rt_mutex_set_owner() and rt_mutex_clear_owner() on + * why xchg_acquire() is used for updating owner for + * locking and WRITE_ONCE() for unlocking. + * + * WRITE_ONCE() would work for the acquire case too, but + * in case that the lock acquisition failed it might + * force other lockers into the slow path unnecessarily. + */ + if (acquire_lock) + xchg_acquire(p, owner & ~RT_MUTEX_HAS_WAITERS); + else + WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + } } /* @@ -208,6 +238,13 @@ static __always_inline void mark_rt_mutex_waiters(struct rt_mutex_base *lock) owner = *p; } while (cmpxchg_relaxed(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner); + + /* + * The cmpxchg loop above is relaxed to avoid back-to-back ACQUIRE + * operations in the event of contention. Ensure the successful + * cmpxchg is visible. + */ + smp_mb__after_atomic(); } /* @@ -1243,7 +1280,7 @@ static int __sched __rt_mutex_slowtrylock(struct rt_mutex_base *lock) * try_to_take_rt_mutex() sets the lock waiters bit * unconditionally. Clean this up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); return ret; } @@ -1604,7 +1641,7 @@ static int __sched __rt_mutex_slowlock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit * unconditionally. We might have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); trace_contention_end(lock, ret); @@ -1719,7 +1756,7 @@ static void __sched rtlock_slowlock_locked(struct rt_mutex_base *lock) * try_to_take_rt_mutex() sets the waiter bit unconditionally. * We might have to fix that up: */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); debug_rt_mutex_free_waiter(&waiter); trace_contention_end(lock, 0); diff --git a/kernel/locking/rtmutex_api.c b/kernel/locking/rtmutex_api.c index 900220941caa..cb9fdff76a8a 100644 --- a/kernel/locking/rtmutex_api.c +++ b/kernel/locking/rtmutex_api.c @@ -267,7 +267,7 @@ void __sched rt_mutex_init_proxy_locked(struct rt_mutex_base *lock, void __sched rt_mutex_proxy_unlock(struct rt_mutex_base *lock) { debug_rt_mutex_proxy_unlock(lock); - rt_mutex_set_owner(lock, NULL); + rt_mutex_clear_owner(lock); } /** @@ -382,7 +382,7 @@ int __sched rt_mutex_wait_proxy_lock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); raw_spin_unlock_irq(&lock->wait_lock); return ret; @@ -438,7 +438,7 @@ bool __sched rt_mutex_cleanup_proxy_lock(struct rt_mutex_base *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, false); raw_spin_unlock_irq(&lock->wait_lock);

2 years, 2 months

1
0
0 0

Re: Patch "powerpc/msi: Fix deassociation of MSI descriptors" has been added to the 4.9-stable tree

by Marc Zyngier

On Mon, 02 Jan 2023 03:37:32 +0000, Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > powerpc/msi: Fix deassociation of MSI descriptors > > to the 4.9-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > powerpc-msi-fix-deassociation-of-msi-descriptors.patch > and it can be found in the queue-4.9 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 760aa3717faf046c8d5bdc27c226179d192b7ddf > Author: Marc Zyngier <maz(a)kernel.org> > Date: Sat Dec 17 10:46:44 2022 +0000 > > powerpc/msi: Fix deassociation of MSI descriptors > > [ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ] Again[1], please drop this from all stable branches, as it has no purpose before 6.2. If I wanted it backported, I would have earmarked it as a stable candidate. M. [1] https://lore.kernel.org/all/86fsczbypl.wl-maz@kernel.org/ -- Without deviation from the norm, progress is not possible.

2 years, 2 months

2
1
0 0

[PATCH v2 1/1] Revert "usb: ulpi: defer ulpi_register on ulpi_read_id timeout"

by Ferry Toth

This reverts commit 8a7b31d545d3a15f0e6f5984ae16f0ca4fd76aac. This patch results in some qemu test failures, specifically xilinx-zynq-a9 machine and zynq-zc702 as well as zynq-zed devicetree files, when trying to boot from USB drive. Fixes: 8a7b31d545d3 ("usb: ulpi: defer ulpi_register on ulpi_read_id timeout") Reported-by: Guenter Roeck <linux(a)roeck-us.net> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/lkml/20221220194334.GA942039@roeck-us.net/ Signed-off-by: Ferry Toth <ftoth(a)exalondelft.nl> --- drivers/usb/common/ulpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c index 60e8174686a1..d7c8461976ce 100644 --- a/drivers/usb/common/ulpi.c +++ b/drivers/usb/common/ulpi.c @@ -207,7 +207,7 @@ static int ulpi_read_id(struct ulpi *ulpi) /* Test the interface */ ret = ulpi_write(ulpi, ULPI_SCRATCH, 0xaa); if (ret < 0) - return ret; + goto err; ret = ulpi_read(ulpi, ULPI_SCRATCH); if (ret < 0) -- 2.37.2

2 years, 2 months

2
1
0 0

Re: KASAN: use-after-free Read in tc_chain_fill_node

by syzbot

This bug is marked as fixed by commit: net: core: netlink: add helper refcount dec and lock function net: sched: add helper function to take reference to Qdisc net: sched: extend Qdisc with rcu net: sched: rename qdisc_destroy() to qdisc_put() net: sched: use Qdisc rcu API instead of relying on rtnl lock But I can't find it in the tested trees[1] for more than 90 days. Is it a correct commit? Please update it by replying: #syz fix: exact-commit-title Until then the bug is still considered open and new crashes with the same signature are ignored. Kernel: Linux 4.19 Dashboard link: https://syzkaller.appspot.com/bug?extid=5f229e48cccc804062c0 --- [1] I expect the commit to be present in: 1. linux-4.19.y branch of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

2 years, 2 months

1
0
0 0

stable-rc/queue/4.19 baseline: 113 runs, 16 regressions (v4.19.269-368-gd949983eb12c)

by kernelci.org bot

stable-rc/queue/4.19 baseline: 113 runs, 16 regressions (v4.19.269-368-gd949983eb12c) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ meson-gxl-s905x-libretech-cc | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.19/kernel/v4.19.26… Test: baseline Tree: stable-rc Branch: queue/4.19 Describe: v4.19.269-368-gd949983eb12c URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: d949983eb12c3591ea6ebcb994e90c9883938eab Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ meson-gxl-s905x-libretech-cc | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b27876e9b12f0c994eee19 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b27876e9b12f0c994eee1a failing since 258 days (last pass: v4.19.238-22-gb215381f8cf05, first fail: v4.19.238-32-g4d86c9395c31a) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b2793504731c1dbf4eee19 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2793504731c1dbf4eee1a failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b27a25a6068f27664eee2f Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b27a25a6068f27664eee30 failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b2786a41eb02b7b34eee22 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2786a41eb02b7b34eee23 failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b278a7192fd4e3c04eee19 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b278a7192fd4e3c04eee1a failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b2794904731c1dbf4eee1d Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2794904731c1dbf4eee1e failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b27a9dcbc9a3a0f04eee39 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b27a9dcbc9a3a0f04eee3a failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b2788c41eb02b7b34eee40 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2788c41eb02b7b34eee41 failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b278a8192fd4e3c04eee1c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b278a8192fd4e3c04eee1d failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b278bd192fd4e3c04eee22 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b278bd192fd4e3c04eee23 failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b27971169034b69e4eee23 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b27971169034b69e4eee24 failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b27869682abbf9be4eee41 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b27869682abbf9be4eee42 failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b278a6e9b12f0c994eee34 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b278a6e9b12f0c994eee35 failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b2795d169034b69e4eee1c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2795d169034b69e4eee1d failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b2795ed86aa097674eee19 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2795ed86aa097674eee1a failing since 236 days (last pass: v4.19.241-58-g8b40d487da7e, first fail: v4.19.241-83-g0ec5709aa1da) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b2787d41eb02b7b34eee3a Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.269-368-gd949983eb… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2787d41eb02b7b34eee3b failing since 160 days (last pass: v4.19.230-58-gbd840138c177, first fail: v4.19.253-43-g91137b502cfbd)

2 years, 2 months

1
0
0 0

stable-rc/queue/4.14 baseline: 104 runs, 17 regressions (v4.14.302-265-g637760492f234)

by kernelci.org bot

stable-rc/queue/4.14 baseline: 104 runs, 17 regressions (v4.14.302-265-g637760492f234) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ meson-gxl-s905x-libretech-cc | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.14/kernel/v4.14.30… Test: baseline Tree: stable-rc Branch: queue/4.14 Describe: v4.14.302-265-g637760492f234 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 637760492f234c48997e3edea1027fb576097992 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ meson-gxl-s905x-libretech-cc | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b27401e3f5e2837b4eee19 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b27401e3f5e2837b4eee1a failing since 258 days (last pass: v4.14.275-277-gda5c0b6bebbb1, first fail: v4.14.275-284-gdf8ec5b4383b9) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b272182f010b642c4eee33 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b272182f010b642c4eee34 failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b273f865fe3740644eee22 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b273f865fe3740644eee23 failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b271d37ddf7708f74eee28 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b271d37ddf7708f74eee29 failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b273a4bcd12ffe3b4eee1b Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b273a4bcd12ffe3b4eee1c failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b2725594027924f04eee19 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2725594027924f04eee1a failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b273d13531610dab4eee31 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b273d13531610dab4eee32 failing since 236 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b27202692d5ae0e54eee38 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b27202692d5ae0e54eee39 failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b2741d6965d5ae294eee42 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2741d6965d5ae294eee43 failing since 236 days (last pass: v4.14.277-54-gfa6de16ffc4e, first fail: v4.14.277-75-g7a298ff98d4a) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b2722c2bfcbb56764eee34 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2722c2bfcbb56764eee35 failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b273d03531610dab4eee2e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b273d03531610dab4eee2f failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b271ecb77afc58a94eee2d Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b271ecb77afc58a94eee2e failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b2739faa76fd97484eee19 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2739faa76fd97484eee1a failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b272540a743da24b4eee3b Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b272540a743da24b4eee3c failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b2740ce3f5e2837b4eee41 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b2740ce3f5e2837b4eee42 failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63b271e7b77afc58a94eee1e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b271e7b77afc58a94eee1f failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/63b273a0aa76fd97484eee1e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.302-265-g637760492… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63b273a0aa76fd97484eee1f failing since 160 days (last pass: v4.14.267-41-g23609abc0d54, first fail: v4.14.289-19-g8ed326806c84)

2 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2023