5.15.6-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 153/179 net: mscc: ocelot: dont downgrade timestamping RX filters in SIOCSHWTSTAMP
In reply to Greg Kroah-HartmanFrom: Vladimir Oltean <[email protected]>
[ Upstream commit 8a075464d1e9317ffae0973dfe538a7511291a06 ]
The ocelot driver, when asked to timestamp all receiving packets, 1588 v1 or NTP, says "nah, here's 1588 v2 for you".
According to this discussion:
https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/#24577647
drivers that downgrade from a wider request to a narrower response (or even a response where the intersection with the request is empty) are buggy, and should return -ERANGE instead. This patch fixes that.
--- drivers/net/ethernet/mscc/ocelot.c | 6 ------ 1 file changed, 6 deletions(-)
drivers/net/ethernet/mscc/ocelot.c +0 -6
@@ -1175,12 +1175,6 @@ int ocelot_hwstamp_set(struct ocelot *ocelot, int port, struct ifreq *ifr)switch (cfg.rx_filter) {case HWTSTAMP_FILTER_NONE :break ; -case HWTSTAMP_FILTER_ALL : -case HWTSTAMP_FILTER_SOME : -case HWTSTAMP_FILTER_PTP_V1_L4_EVENT : -case HWTSTAMP_FILTER_PTP_V1_L4_SYNC : -case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ : -case HWTSTAMP_FILTER_NTP_ALL :case HWTSTAMP_FILTER_PTP_V2_L4_EVENT :case HWTSTAMP_FILTER_PTP_V2_L4_SYNC :case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ :
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 154/179 net: mscc: ocelot: correctly report the timestamping RX filters in ethtool
In reply to Greg Kroah-HartmanFrom: Vladimir Oltean <[email protected]>
[ Upstream commit c49a35eedfef08bffd46b53c25dbf9d6016a86ff ]
The driver doesn't support RX timestamping for non-PTP packets, but it declares that it does. Restrict the reported RX filters to PTP v2 over L2 and over L4.
--- drivers/net/ethernet/mscc/ocelot.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/mscc/ocelot.c +4 -1
@@ -1293,7 +1293,10 @@ int ocelot_get_ts_info(struct ocelot *ocelot, int port,SOF_TIMESTAMPING_RAW_HARDWARE ; info->tx_types =BIT (HWTSTAMP_TX_OFF ) |BIT (HWTSTAMP_TX_ON ) |BIT (HWTSTAMP_TX_ONESTEP_SYNC ); - info->rx_filters =BIT (HWTSTAMP_FILTER_NONE ) |BIT (HWTSTAMP_FILTER_ALL ); + info->rx_filters =BIT (HWTSTAMP_FILTER_NONE ) | +BIT (HWTSTAMP_FILTER_PTP_V2_EVENT ) | +BIT (HWTSTAMP_FILTER_PTP_V2_L2_EVENT ) | +BIT (HWTSTAMP_FILTER_PTP_V2_L4_EVENT );return 0 ; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 155/179 locking/rwsem: Make handoff bit handling more consistent
In reply to Greg Kroah-HartmanFrom: Waiman Long <[email protected]>
[ Upstream commit d257cc8cb8d5355ffc43a96bab94db7b5a324803 ]
There are some inconsistency in the way that the handoff bit is being handled in readers and writers that lead to a race condition.
Firstly, when a queue head writer set the handoff bit, it will clear it when the writer is being killed or interrupted on its way out without acquiring the lock. That is not the case for a queue head reader. The handoff bit will simply be inherited by the next waiter.
Secondly, in the out_nolock path of rwsem_down_read_slowpath(), both the waiter and handoff bits are cleared if the wait queue becomes empty. For rwsem_down_write_slowpath(), however, the handoff bit is not checked and cleared if the wait queue is empty. This can potentially make the handoff bit set with empty wait queue.
Worse, the situation in rwsem_down_write_slowpath() relies on wstate, a variable set outside of the critical section containing the ->count manipulation, this leads to race condition where RWSEM_FLAG_HANDOFF can be double subtracted, corrupting ->count.
To make the handoff bit handling more consistent and robust, extract out handoff bit clearing code into the new rwsem_del_waiter() helper function. Also, completely eradicate wstate; always evaluate everything inside the same critical section.
The common function will only use atomic_long_andnot() to clear bits when the wait queue is empty to avoid possible race condition. If the first waiter with handoff bit set is killed or interrupted to exit the slowpath without acquiring the lock, the next waiter will inherit the handoff bit.
While at it, simplify the trylock for loop in rwsem_down_write_slowpath() to make it easier to read.
--- kernel/locking/rwsem.c | 171 ++++++++++++++++++++--------------------- 1 file changed, 85 insertions(+), 86 deletions(-)
kernel/locking/rwsem.c +85 -86
@@ -106,9 +106,9 @@* atomic_long_cmpxchg() will be used to obtain writer lock. * * There are three places where the lock handoff bit may be set or cleared. -* 1) rwsem_mark_wake() for readers. -* 2) rwsem_try_write_lock() for writers. -* 3) Error path of rwsem_down_write_slowpath(). +* 1) rwsem_mark_wake() for readers -- set, clear +* 2) rwsem_try_write_lock() for writers -- set, clear +* 3) rwsem_del_waiter() -- clear * * For all the above cases, wait_lock will be held. A writer must also * be the first one in the wait_list to be eligible for setting the handoff
@@ -335,6 +335,9 @@ struct rwsem_waiter {struct task_struct *task;enum rwsem_waiter_type type;unsigned long timeout; + +/* Writer only, not initialized in reader */ +bool handoff_set; };#define rwsem_first_waiter (sem) \ list_first_entry(&sem->wait_list, struct rwsem_waiter, list)
@@ -345,12 +348,6 @@ enum rwsem_wake_type { RWSEM_WAKE_READ_OWNED /* Waker thread holds the read lock */ }; -enum writer_wait_state { -WRITER_NOT_FIRST ,/* Writer is not first in wait list */ -WRITER_FIRST ,/* Writer is first in wait list */ -WRITER_HANDOFF /* Writer is first & handoff needed */ -}; -/* * The typical HZ value is either 250 or 1000. So set the minimum waiting * time to at least 4ms or 1 jiffy (if it is higher than 4ms) in the wait
@@ -366,6 +363,31 @@ enum writer_wait_state {*/ #define MAX_READERS_WAKEUP 0x100 +static inline void +rwsem_add_waiter (struct rw_semaphore *sem,struct rwsem_waiter *waiter) +{ +lockdep_assert_held (&sem->wait_lock); +list_add_tail (&waiter->list, &sem->wait_list); +/* caller will set RWSEM_FLAG_WAITERS */ +} + +/* +* Remove a waiter from the wait_list and clear flags. +* +* Both rwsem_mark_wake() and rwsem_try_write_lock() contain a full 'copy' of +* this function. Modify with care. +*/ +static inline void +rwsem_del_waiter (struct rw_semaphore *sem,struct rwsem_waiter *waiter) +{ +lockdep_assert_held (&sem->wait_lock); +list_del (&waiter->list); +if (likely (!list_empty (&sem->wait_list))) +return ; + +atomic_long_andnot (RWSEM_FLAG_HANDOFF |RWSEM_FLAG_WAITERS , &sem->count); +} +/* * handle the lock release when processes blocked on it that can now run * - if we come here from up_xxxx(), then the RWSEM_FLAG_WAITERS bit must
@@ -377,6 +399,8 @@ enum writer_wait_state {* preferably when the wait_lock is released * - woken process blocks are discarded from the list after having task zeroed * - writers are only marked woken if downgrading is false +* +* Implies rwsem_del_waiter() for all woken readers. */ static void rwsem_mark_wake(struct rw_semaphore *sem, enum rwsem_wake_type wake_type,
@@ -491,18 +515,25 @@ static void rwsem_mark_wake(struct rw_semaphore *sem, adjustment = woken *RWSEM_READER_BIAS - adjustment;lockevent_cond_inc (rwsem_wake_reader, woken); + + oldcount =atomic_long_read (&sem->count);if (list_empty (&sem->wait_list)) { -/* hit end of list above */ +/* +* Combined with list_move_tail() above, this implies +* rwsem_del_waiter(). +*/ adjustment -=RWSEM_FLAG_WAITERS ; +if (oldcount &RWSEM_FLAG_HANDOFF ) + adjustment -=RWSEM_FLAG_HANDOFF ; + }else if (woken) { +/* +* When we've woken a reader, we no longer need to force +* writers to give up the lock and we can clear HANDOFF. +*/ +if (oldcount &RWSEM_FLAG_HANDOFF ) + adjustment -=RWSEM_FLAG_HANDOFF ; } -/* -* When we've woken a reader, we no longer need to force writers -* to give up the lock and we can clear HANDOFF. -*/ -if (woken && (atomic_long_read (&sem->count) &RWSEM_FLAG_HANDOFF )) - adjustment -=RWSEM_FLAG_HANDOFF ; -if (adjustment)atomic_long_add (adjustment, &sem->count);
@@ -533,12 +564,12 @@ static void rwsem_mark_wake(struct rw_semaphore *sem,* race conditions between checking the rwsem wait list and setting the * sem->count accordingly. * -* If wstate is WRITER_HANDOFF, it will make sure that either the handoff -* bit is set or the lock is acquired with handoff bit cleared. +* Implies rwsem_del_waiter() on success. */ static inline bool rwsem_try_write_lock (struct rw_semaphore *sem, -enum writer_wait_state wstate) +struct rwsem_waiter *waiter) { +bool first =rwsem_first_waiter (sem) == waiter;long count, new;lockdep_assert_held (&sem->wait_lock);
@@ -547,13 +578,19 @@ static inline bool rwsem_try_write_lock(struct rw_semaphore *sem, do { bool has_handoff = !!(count & RWSEM_FLAG_HANDOFF); - if (has_handoff && wstate == WRITER_NOT_FIRST) - return false; + if (has_handoff) { + if (!first) + return false; + + /* First waiter inherits a previously set handoff bit */ + waiter->handoff_set = true; + } new = count; if (count & RWSEM_LOCK_MASK) { - if (has_handoff || (wstate != WRITER_HANDOFF)) + if (has_handoff || (!rt_task(waiter->task) && + !time_after(jiffies, waiter->timeout))) return false; new |= RWSEM_FLAG_HANDOFF;
@@ -570,9 +607,17 @@ static inline bool rwsem_try_write_lock(struct rw_semaphore *sem,* We have either acquired the lock with handoff bit cleared or * set the handoff bit. */ -if (new &RWSEM_FLAG_HANDOFF ) +if (new &RWSEM_FLAG_HANDOFF ) { + waiter->handoff_set = true; +lockevent_inc (rwsem_wlock_handoff);return false; + } +/* +* Have rwsem_try_write_lock() fully imply rwsem_del_waiter() on +* success. +*/ +list_del (&waiter->list);rwsem_set_owner (sem);return true; }
@@ -953,7 +998,7 @@ rwsem_down_read_slowpath(struct rw_semaphore *sem, long count, unsigned int stat } adjustment +=RWSEM_FLAG_WAITERS ; } -list_add_tail (&waiter.list, &sem->wait_list); +rwsem_add_waiter (sem, &waiter);/* we're now waiting on the lock, but no longer actively locking */ count =atomic_long_add_return (adjustment, &sem->count);
@@ -999,11 +1044,7 @@ rwsem_down_read_slowpath(struct rw_semaphore *sem, long count, unsigned int statreturn sem; out_nolock: -list_del (&waiter.list); -if (list_empty (&sem->wait_list)) { -atomic_long_andnot (RWSEM_FLAG_WAITERS |RWSEM_FLAG_HANDOFF , - &sem->count); - } +rwsem_del_waiter (sem, &waiter);raw_spin_unlock_irq (&sem->wait_lock);__set_current_state (TASK_RUNNING );lockevent_inc (rwsem_rlock_fail);
@@ -1017,9 +1058,7 @@ static struct rw_semaphore * rwsem_down_write_slowpath(struct rw_semaphore *sem, int state) { long count; -enum writer_wait_state wstate;struct rwsem_waiter waiter; -struct rw_semaphore *ret = sem;DEFINE_WAKE_Q (wake_q);/* do optimistic spinning and steal lock if possible */
@@ -1035,16 +1074,13 @@ rwsem_down_write_slowpath(struct rw_semaphore *sem, int state) waiter.task = current; waiter.type =RWSEM_WAITING_FOR_WRITE ; waiter.timeout = jiffies +RWSEM_WAIT_TIMEOUT ; + waiter.handoff_set = false;raw_spin_lock_irq (&sem->wait_lock); - -/* account for this before adding a new element to the list */ - wstate =list_empty (&sem->wait_list) ?WRITER_FIRST :WRITER_NOT_FIRST ; - -list_add_tail (&waiter.list, &sem->wait_list); +rwsem_add_waiter (sem, &waiter);/* we're now waiting on the lock */ -if (wstate ==WRITER_NOT_FIRST ) { +if (rwsem_first_waiter (sem) != &waiter) { count =atomic_long_read (&sem->count);/*
@@ -1080,13 +1116,16 @@ rwsem_down_write_slowpath(struct rw_semaphore *sem, int state)/* wait until we successfully acquire the lock */ set_current_state (state);for (;;) { -if (rwsem_try_write_lock (sem, wstate)) { +if (rwsem_try_write_lock (sem, &waiter)) {/* rwsem_try_write_lock() implies ACQUIRE on success */ break ; }raw_spin_unlock_irq (&sem->wait_lock); +if (signal_pending_state (state, current)) + goto out_nolock; +/* * After setting the handoff bit and failing to acquire * the lock, attempt to spin on owner to accelerate lock
@@ -1095,7 +1134,7 @@ rwsem_down_write_slowpath(struct rw_semaphore *sem, int state)* In this case, we attempt to acquire the lock again * without sleeping. */ -if (wstate ==WRITER_HANDOFF ) { +if (waiter.handoff_set) {enum owner_state owner_state;preempt_disable ();
@@ -1106,66 +1145,26 @@ rwsem_down_write_slowpath(struct rw_semaphore *sem, int state) goto trylock_again; } -/* Block until there are no active lockers. */ -for (;;) { -if (signal_pending_state (state, current)) - goto out_nolock; - -schedule (); -lockevent_inc (rwsem_sleep_writer); -set_current_state (state); -/* -* If HANDOFF bit is set, unconditionally do -* a trylock. -*/ -if (wstate ==WRITER_HANDOFF ) -break ; - -if ((wstate ==WRITER_NOT_FIRST ) && - (rwsem_first_waiter (sem) == &waiter)) - wstate =WRITER_FIRST ; - - count =atomic_long_read (&sem->count); -if (!(count &RWSEM_LOCK_MASK )) -break ; - -/* -* The setting of the handoff bit is deferred -* until rwsem_try_write_lock() is called. -*/ -if ((wstate ==WRITER_FIRST ) && (rt_task (current) || -time_after (jiffies, waiter.timeout))) { - wstate =WRITER_HANDOFF ; -lockevent_inc (rwsem_wlock_handoff); -break ; - } - } +schedule (); +lockevent_inc (rwsem_sleep_writer); +set_current_state (state); trylock_again:raw_spin_lock_irq (&sem->wait_lock); }__set_current_state (TASK_RUNNING ); -list_del (&waiter.list);raw_spin_unlock_irq (&sem->wait_lock);lockevent_inc (rwsem_wlock); - -return ret; +return sem; out_nolock:__set_current_state (TASK_RUNNING );raw_spin_lock_irq (&sem->wait_lock); -list_del (&waiter.list); - -if (unlikely (wstate ==WRITER_HANDOFF )) -atomic_long_add (-RWSEM_FLAG_HANDOFF , &sem->count); - -if (list_empty (&sem->wait_list)) -atomic_long_andnot (RWSEM_FLAG_WAITERS , &sem->count); -else +rwsem_del_waiter (sem, &waiter); +if (!list_empty (&sem->wait_list))rwsem_mark_wake (sem,RWSEM_WAKE_ANY , &wake_q);raw_spin_unlock_irq (&sem->wait_lock);wake_up_q (&wake_q);lockevent_inc (rwsem_wlock_fail); -return ERR_PTR (-EINTR ); }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 156/179 perf: Ignore sigtrap for tracepoints destined for other tasks
In reply to Greg Kroah-HartmanFrom: Marco Elver <[email protected]>
[ Upstream commit 73743c3b092277febbf69b250ce8ebbca0525aa2 ]
syzbot reported that the warning in perf_sigtrap() fires, saying that the event's task does not match current:
| WARNING: CPU: 0 PID: 9090 at kernel/events/core.c:6446 perf_pending_event+0x40d/0x4b0 kernel/events/core.c:6513 | Modules linked in: | CPU: 0 PID: 9090 Comm: syz-executor.1 Not tainted 5.15.0-syzkaller #0 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 | RIP: 0010:perf_sigtrap kernel/events/core.c:6446 [inline] | RIP: 0010:perf_pending_event_disable kernel/events/core.c:6470 [inline] | RIP: 0010:perf_pending_event+0x40d/0x4b0 kernel/events/core.c:6513 | ... | Call Trace: | <IRQ> | irq_work_single+0x106/0x220 kernel/irq_work.c:211 | irq_work_run_list+0x6a/0x90 kernel/irq_work.c:242 | irq_work_run+0x4f/0xd0 kernel/irq_work.c:251 | __sysvec_irq_work+0x95/0x3d0 arch/x86/kernel/irq_work.c:22 | sysvec_irq_work+0x8e/0xc0 arch/x86/kernel/irq_work.c:17 | </IRQ> | <TASK> | asm_sysvec_irq_work+0x12/0x20 arch/x86/include/asm/idtentry.h:664 | RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] | RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70 kernel/locking/spinlock.c:194 | ... | coredump_task_exit kernel/exit.c:371 [inline] | do_exit+0x1865/0x25c0 kernel/exit.c:771 | do_group_exit+0xe7/0x290 kernel/exit.c:929 | get_signal+0x3b0/0x1ce0 kernel/signal.c:2820 | arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868 | handle_signal_work kernel/entry/common.c:148 [inline] | exit_to_user_mode_loop kernel/entry/common.c:172 [inline] | exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207 | __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] | syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 | do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86 | entry_SYSCALL_64_after_hwframe+0x44/0xae
On x86 this shouldn't happen, which has arch_irq_work_raise().
The test program sets up a perf event with sigtrap set to fire on the 'sched_wakeup' tracepoint, which fired in ttwu_do_wakeup().
This happened because the 'sched_wakeup' tracepoint also takes a task argument passed on to perf_tp_event(), which is used to deliver the event to that other task.
Since we cannot deliver synchronous signals to other tasks, skip an event if perf_tp_event() is targeted at another task and perf_event_attr::sigtrap is set, which will avoid ever entering perf_sigtrap() for such events.
--- kernel/events/core.c | 3 +++ 1 file changed, 3 insertions(+)
kernel/events/core.c +3 -0
@@ -9729,6 +9729,9 @@ void perf_tp_event(u16 event_type, u64 count, void *record, int entry_size,continue ;if (event->attr.config != entry->type)continue ; +/* Cannot deliver synchronous signal to other task. */ +if (event->attr.sigtrap) +continue ;if (perf_tp_event_match (event, &data, regs))perf_swevent_event (event, count, &data, regs); }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 157/179 sched/scs: Reset task stack state in bringup_cpu()
In reply to Greg Kroah-HartmanFrom: Mark Rutland <[email protected]>
[ Upstream commit dce1ca0525bfdc8a69a9343bc714fbc19a2f04b3 ]
To hot unplug a CPU, the idle task on that CPU calls a few layers of C code before finally leaving the kernel. When KASAN is in use, poisoned shadow is left around for each of the active stack frames, and when shadow call stacks are in use. When shadow call stacks (SCS) are in use the task's saved SCS SP is left pointing at an arbitrary point within the task's shadow call stack.
When a CPU is offlined than onlined back into the kernel, this stale state can adversely affect execution. Stale KASAN shadow can alias new stackframes and result in bogus KASAN warnings. A stale SCS SP is effectively a memory leak, and prevents a portion of the shadow call stack being used. Across a number of hotplug cycles the idle task's entire shadow call stack can become unusable.
We previously fixed the KASAN issue in commit:
e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug")
... by removing any stale KASAN stack poison immediately prior to onlining a CPU.
Subsequently in commit:
f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")
... the refactoring left the KASAN and SCS cleanup in one-time idle thread initialization code rather than something invoked prior to each CPU being onlined, breaking both as above.
We fixed SCS (but not KASAN) in commit:
63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit")
... but as this runs in the context of the idle task being offlined it's potentially fragile.
To fix these consistently and more robustly, reset the SCS SP and KASAN shadow of a CPU's idle task immediately before we online that CPU in bringup_cpu(). This ensures the idle task always has a consistent state when it is running, and removes the need to so so when exiting an idle task.
Whenever any thread is created, dup_task_struct() will give the task a stack which is free of KASAN shadow, and initialize the task's SCS SP, so there's no need to specially initialize either for idle thread within init_idle(), as this was only necessary to handle hotplug cycles.
I've tested this on arm64 with:
* gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK
* clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK
... offlining and onlining CPUS with:
| while true; do | for C in /sys/devices/system/cpu/cpu*/online; do | echo 0 > $C; | echo 1 > $C; | done | done
--- kernel/cpu.c | 7 +++++++ kernel/sched/core.c | 4 ---- 2 files changed, 7 insertions(+), 4 deletions(-)
kernel/cpu.c +7 -0
@@ -31,6 +31,7 @@#include <linux/smpboot.h> #include <linux/relay.h> #include <linux/slab.h> +#include <linux/scs.h> #include <linux/percpu-rwsem.h> #include <linux/cpuset.h>
@@ -587,6 +588,12 @@ static int bringup_cpu(unsigned int cpu)struct task_struct *idle =idle_thread_get (cpu);int ret; +/* +* Reset stale stack state from the last time this CPU was online. +*/ +scs_task_reset (idle); +kasan_unpoison_task_stack (idle); +/* * Some architectures have to walk the irq descriptors to * setup the vector space for the cpu which comes online.
kernel/sched/core.c +0 -4
@@ -8641,9 +8641,6 @@ void __init init_idle(struct task_struct *idle, int cpu) idle->flags |=PF_IDLE |PF_KTHREAD |PF_NO_SETAFFINITY ;kthread_set_per_cpu (idle, cpu); -scs_task_reset (idle); -kasan_unpoison_task_stack (idle); -#ifdef CONFIG_SMP /* * It's possible that init_idle() gets called multiple times on a task,
@@ -8799,7 +8796,6 @@ void idle_task_exit(void)finish_arch_post_lock_switch (); } -scs_task_reset (current);/* finish_cpu(), as ran on the BP, will clean up the active_mm state */ }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 158/179 iommu/rockchip: Fix PAGE_DESC_HI_MASKs for RK3568
In reply to Greg Kroah-HartmanFrom: Alex Bee <[email protected]>
[ Upstream commit f7ff3cff3527ff1e70cad8d2fe7c0c7b6f83120a ]
With the submission of iommu driver for RK3568 a subtle bug was
introduced: PAGE_DESC_HI_MASK1 and PAGE_DESC_HI_MASK2 have to be the other way arround - that leads to random errors, especially when addresses beyond 32 bit are used.
Fix it.
--- drivers/iommu/rockchip-iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/iommu/rockchip-iommu.c +2 -2
@@ -200,8 +200,8 @@ static inline phys_addr_t rk_dte_pt_address(u32 dte)#define DTE_HI_MASK2 GENMASK(7, 4)#define DTE_HI_SHIFT1 24/* shift bit 8 to bit 32 */ #define DTE_HI_SHIFT2 32/* shift bit 4 to bit 36 */ -#define PAGE_DESC_HI_MASK1 GENMASK_ULL(39, 36) -#define PAGE_DESC_HI_MASK2 GENMASK_ULL(35, 32) +#define PAGE_DESC_HI_MASK1 GENMASK_ULL(35, 32) +#define PAGE_DESC_HI_MASK2 GENMASK_ULL(39, 36)static inline phys_addr_t rk_dte_pt_address_v2 (u32 dte) {
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 159/179 iommu/vt-d: Fix unmap_pages support
In reply to Greg Kroah-HartmanFrom: Alex Williamson <[email protected]>
[ Upstream commit 86dc40c7ea9c22f64571e0e45f695de73a0e2644 ]
When supporting only the .map and .unmap callbacks of iommu_ops, the IOMMU driver can make assumptions about the size and alignment used for mappings based on the driver provided pgsize_bitmap. VT-d previously used essentially PAGE_MASK for this bitmap as any power of two mapping was acceptably filled by native page sizes.
However, with the .map_pages and .unmap_pages interface we're now getting page-size and count arguments. If we simply combine these as (page-size * count) and make use of the previous map/unmap functions internally, any size and alignment assumptions are very different.
As an example, a given vfio device assignment VM will often create a 4MB mapping at IOVA pfn [0x3fe00 - 0x401ff]. On a system that does not support IOMMU super pages, the unmap_pages interface will ask to unmap 1024 4KB pages at the base IOVA. dma_pte_clear_level() will recurse down to level 2 of the page table where the first half of the pfn range exactly matches the entire pte level. We clear the pte, increment the pfn by the level size, but (oops) the next pte is on a new page, so we exit the loop an pop back up a level. When we then update the pfn based on that higher level, we seem to assume that the previous pfn value was at the start of the level. In this case the level size is 256K pfns, which we add to the base pfn and get a results of 0x7fe00, which is clearly greater than 0x401ff, so we're done. Meanwhile we never cleared the ptes for the remainder of the range. When the VM remaps this range, we're overwriting valid ptes and the VT-d driver complains loudly, as reported by the user report linked below.
The fix for this seems relatively simple, if each iteration of the loop in dma_pte_clear_level() is assumed to clear to the end of the level pte page, then our next pfn should be calculated from level_pfn rather than our working pfn.
--- drivers/iommu/intel/iommu.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/iommu/intel/iommu.c +2 -4
@@ -1226,13 +1226,11 @@ static struct page *dma_pte_clear_level(struct dmar_domain *domain, int level, pte = &pte[pfn_level_offset (pfn, level)]; do { - unsigned long level_pfn; + unsigned long level_pfn = pfn & level_mask(level); if (!dma_pte_present(pte)) goto next; - level_pfn = pfn & level_mask(level); - /* If range covers entire pagetable, free it */ if (start_pfn <= level_pfn && last_pfn >= level_pfn + level_size(level) - 1) {
@@ -1253,7 +1251,7 @@ static struct page *dma_pte_clear_level(struct dmar_domain *domain, int level, freelist); } next: - pfn +=level_size (level); + pfn = level_pfn +level_size (level); }while (!first_pte_in_page (++pte) && pfn <= last_pfn);if (first_pte)
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 160/179 f2fs: quota: fix potential deadlock
In reply to Greg Kroah-HartmanFrom: Chao Yu <[email protected]>
[ Upstream commit a5c0042200b28fff3bde6fa128ddeaef97990f8d ]
As Yi Zhuang reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=214299
There is potential deadlock during quota data flush as below:
Thread A: Thread B:f2fs_dquot_acquiredown_read(&sbi->quota_sem)
f2fs_write_checkpoint block_operations f2fs_look_all down_write(&sbi->cp_rwsem)
f2fs_quota_writef2fs_write_begin__do_map_lockf2fs_lock_opdown_read(&sbi->cp_rwsem)
__need_flush_qutoa down_write(&sbi->quota_sem)
This patch changes block_operations() to use trylock, if it fails, it means there is potential quota data updater, in this condition, let's flush quota data first and then trylock again to check dirty status of quota data.
The side effect is: in heavy race condition (e.g. multi quota data upaters vs quota data flusher), it may decrease the probability of synchronizing quota data successfully in checkpoint() due to limited retry time of quota flush.
--- fs/f2fs/checkpoint.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/f2fs/checkpoint.c +2 -1
@@ -1162,7 +1162,8 @@ static bool __need_flush_quota(struct f2fs_sb_info *sbi)if (!is_journalled_quota (sbi))return false; -down_write (&sbi->quota_sem); +if (!down_write_trylock (&sbi->quota_sem)) +return true;if (is_sbi_flag_set (sbi,SBI_QUOTA_SKIP_FLUSH )) { ret = false; }else if (is_sbi_flag_set (sbi,SBI_QUOTA_NEED_REPAIR )) {
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 161/179 f2fs: set SBI_NEED_FSCK flag when inconsistent node block found
In reply to Greg Kroah-HartmanFrom: Weichao Guo <[email protected]>
[ Upstream commit 6663b138ded1a59e630c9e605e42aa7fde490cdc ]
Inconsistent node block will cause a file fail to open or read, which could make the user process crashes or stucks. Let's mark SBI_NEED_FSCK flag to trigger a fix at next fsck time. After unlinking the corrupted file, the user process could regenerate a new one and work correctly.
--- fs/f2fs/node.c | 1 + 1 file changed, 1 insertion(+)
fs/f2fs/node.c +1 -0
@@ -1443,6 +1443,7 @@ static struct page *__get_node_page(struct f2fs_sb_info *sbi, pgoff_t nid, nid,nid_of_node (page),ino_of_node (page),ofs_of_node (page),cpver_of_node (page), next_blkaddr_of_node(page)); +set_sbi_flag (sbi,SBI_NEED_FSCK ); err = -EINVAL ; out_err:ClearPageUptodate (page);
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 162/179 riscv: dts: microchip: fix board compatible
In reply to Greg Kroah-HartmanFrom: Krzysztof Kozlowski <[email protected]>
[ Upstream commit fd86dd2a5dc5ff1044423c19fef3907862f591c4 ]
According to bindings, the compatible must include microchip,mpfs. This fixes dtbs_check warning:
arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dt.yaml: /: compatible: ['microchip,mpfs-icicle-kit'] is too short
--- arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts | 2 +- arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts +1 -1
@@ -12,7 +12,7 @@ / { #address-cells = <2>; #size-cells = <2>; model = "Microchip PolarFire-SoC Icicle Kit"; - compatible = "microchip,mpfs-icicle-kit"; + compatible = "microchip,mpfs-icicle-kit", "microchip,mpfs"; aliases { ethernet0 = &emac1;
arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi +2 -2
@@ -6,8 +6,8 @@ / { #address-cells = <2>; #size-cells = <2>; - model = "Microchip MPFS Icicle Kit"; - compatible = "microchip,mpfs-icicle-kit"; + model = "Microchip PolarFire SoC"; + compatible = "microchip,mpfs"; chosen { };
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 163/179 riscv: dts: microchip: drop duplicated MMC/SDHC node
In reply to Greg Kroah-HartmanFrom: Krzysztof Kozlowski <[email protected]>
[ Upstream commit 42a57a47bb0c0f531321a7001972a3ca121409bd ]
Devicetree source is a description of hardware and hardware has only one block @20008000 which can be configured either as eMMC or SDHC. Having two node for different modes is an obscure, unusual and confusing way to configure it. Instead the board file is supposed to customize the block to its needs, e.g. to SDHC mode.
This fixes dtbs_check warning:
arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dt.yaml: sdhc@20008000: $nodename:0: 'sdhc@20008000' does not match '^mmc(@.*)?$'
--- .../microchip/microchip-mpfs-icicle-kit.dts | 11 ++++++- .../boot/dts/microchip/microchip-mpfs.dtsi | 29 ++----------------- 2 files changed, 12 insertions(+), 28 deletions(-)
arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts +10 -1
@@ -56,8 +56,17 @@ &serial3 { status = "okay"; }; -&sdcard { +&mmc { status = "okay"; + + bus-width = <4>; + disable-wp; + cap-sd-highspeed; + card-detect-delay = <200>; + sd-uhs-sdr12; + sd-uhs-sdr25; + sd-uhs-sdr50; + sd-uhs-sdr104; }; &emac0 {
arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi +2 -27
@@ -262,39 +262,14 @@ serial3: serial@20104000 { status = "disabled"; }; - emmc: mmc@20008000 { + /* Common node entry for emmc/sd */ + mmc: mmc@20008000 { compatible = "cdns,sd4hc"; reg = <0x0 0x20008000 0x0 0x1000>; interrupt-parent = <&plic>; interrupts = <88 89>; pinctrl-names = "default"; clocks = <&clkcfg 6>; - bus-width = <4>; - cap-mmc-highspeed; - mmc-ddr-3_3v; - max-frequency = <200000000>; - non-removable; - no-sd; - no-sdio; - voltage-ranges = <3300 3300>; - status = "disabled"; - }; - - sdcard: sdhc@20008000 { - compatible = "cdns,sd4hc"; - reg = <0x0 0x20008000 0x0 0x1000>; - interrupt-parent = <&plic>; - interrupts = <88>; - pinctrl-names = "default"; - clocks = <&clkcfg 6>; - bus-width = <4>; - disable-wp; - cap-sd-highspeed; - card-detect-delay = <200>; - sd-uhs-sdr12; - sd-uhs-sdr25; - sd-uhs-sdr50; - sd-uhs-sdr104; max-frequency = <200000000>; status = "disabled"; };
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 164/179 cifs: nosharesock should not share socket with future sessions
In reply to Greg Kroah-HartmanFrom: Shyam Prasad N <[email protected]>
[ Upstream commit c9f1c19cf7c50949885fa5afdb2cb242d61a7fac ]
Today, when a new mount is done with nosharesock, we ensure that we don't select an existing matching session. However, we don't mark the connection as nosharesock, which means that those could be shared with future sessions.
Fixed it with this commit. Also printing this info in DebugData.
--- fs/cifs/cifs_debug.c | 2 ++ fs/cifs/cifsglob.h | 1 + fs/cifs/connect.c | 8 +++++++- 3 files changed, 10 insertions(+), 1 deletion(-)
fs/cifs/cifs_debug.c +2 -0
@@ -358,6 +358,8 @@ static int cifs_debug_data_proc_show(struct seq_file *m, void *v)seq_printf (m," signed" );if (server->posix_ext_supported)seq_printf (m," posix" ); +if (server->nosharesock) +seq_printf (m," nosharesock" );if (server->rdma)seq_printf (m,"\nRDMA " );
fs/cifs/cifsglob.h +1 -0
@@ -592,6 +592,7 @@ struct TCP_Server_Info {struct list_head pending_mid_q;bool noblocksnd;/* use blocking sendmsg */ bool noautotune;/* do not autotune send buf sizes */ +bool nosharesock;bool tcp_nodelay;unsigned int credits;/* send no more requests at once */ unsigned int max_credits;/* can override large 32000 default at mnt */
fs/cifs/connect.c +7 -1
@@ -1217,7 +1217,13 @@ static int match_server(struct TCP_Server_Info *server, struct smb3_fs_context * {struct sockaddr *addr = (struct sockaddr *)&ctx->dstaddr; -if (ctx->nosharesock) +if (ctx->nosharesock) { + server->nosharesock = true; +return 0 ; + } + +/* this server does not share socket */ +if (server->nosharesock)return 0 ;/* If multidialect negotiation see if existing sessions match one */
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 165/179 ceph: properly handle statfs on multifs setups
In reply to Greg Kroah-HartmanFrom: Jeff Layton <[email protected]>
[ Upstream commit 8cfc0c7ed34f7929ce7e5d7c6eecf4d01ba89a84 ]
ceph_statfs currently stuffs the cluster fsid into the f_fsid field. This was fine when we only had a single filesystem per cluster, but now that we have multiples we need to use something that will vary between them.
Change ceph_statfs to xor each 32-bit chunk of the fsid (aka cluster id) into the lower bits of the statfs->f_fsid. Change the lower bits to hold the fscid (filesystem ID within the cluster).
That should give us a value that is guaranteed to be unique between filesystems within a cluster, and should minimize the chance of collisions between mounts of different clusters.
URL: https://tracker.ceph.com/issues/52812
--- fs/ceph/super.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
fs/ceph/super.c +6 -5
@@ -52,8 +52,7 @@ static int ceph_statfs(struct dentry *dentry, struct kstatfs *buf)struct ceph_fs_client *fsc =ceph_inode_to_client (d_inode (dentry));struct ceph_mon_client *monc = &fsc->client->monc;struct ceph_statfs st; -u64 fsid; -int err; +int i, err;u64 data_pool;if (fsc->mdsc->mdsmap->m_num_data_pg_pools ==1 ) {
@@ -99,12 +98,14 @@ static int ceph_statfs(struct dentry *dentry, struct kstatfs *buf) buf->f_namelen =NAME_MAX ;/* Must convert the fsid, for consistent values across arches */ + buf->f_fsid.val[0 ] =0 ;mutex_lock (&monc->mutex); - fsid =le64_to_cpu (*(__le64 *)(&monc->monmap->fsid)) ^ -le64_to_cpu (*((__le64 *)&monc->monmap->fsid +1 )); +for (i =0 ; i <sizeof (monc->monmap->fsid) /sizeof (__le32) ; ++i) + buf->f_fsid.val[0 ] ^=le32_to_cpu (((__le32 *)&monc->monmap->fsid)[i]);mutex_unlock (&monc->mutex); - buf->f_fsid =u64_to_fsid (fsid); +/* fold the fs_cluster_id into the upper bits */ + buf->f_fsid.val[1 ] = monc->fs_cluster_id;return 0 ; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 166/179 iommu/amd: Clarify AMD IOMMUv2 initialization messages
In reply to Greg Kroah-HartmanFrom: Joerg Roedel <[email protected]>
commit 717e88aad37befedfd531378b632e794e24e9afb upstream.
The messages printed on the initialization of the AMD IOMMUv2 driver have caused some confusion in the past. Clarify the messages to lower the confusion in the future.
--- drivers/iommu/amd/iommu_v2.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/iommu/amd/iommu_v2.c +3 -3
@@ -928,10 +928,8 @@ static int __init amd_iommu_v2_init(void {int ret; -pr_info ("AMD IOMMUv2 driver by Joerg Roedel <[email protected]>\n" ); -if (!amd_iommu_v2_supported ()) { -pr_info ("AMD IOMMUv2 functionality not available on this system\n" ); +pr_info ("AMD IOMMUv2 functionality not available on this system - This is not a bug.\n" );/* * Load anyway to provide the symbols to other modules * which may use AMD IOMMUv2 optionally.
@@ -946,6 +944,8 @@ static int __init amd_iommu_v2_init(voidamd_iommu_register_ppr_notifier (&ppr_nb); +pr_info ("AMD IOMMUv2 loaded and initialized\n" ); +return 0 ; out:
Greg Kroah-Hartman
maintainerPATCH 167/179 vdpa_sim: avoid putting an uninitialized iova_domain
In reply to Greg Kroah-HartmanFrom: Longpeng <[email protected]>
commit bb93ce4b150dde79f58e34103cbd1fe829796649 upstream.
The system will crash if we put an uninitialized iova_domain, this could happen when an error occurs before initializing the iova_domain in vdpasim_create().
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:__cpuhp_state_remove_instance+0x96/0x1c0 ... Call Trace: <TASK> put_iova_domain+0x29/0x220 vdpasim_free+0xd1/0x120 [vdpa_sim] vdpa_release_dev+0x21/0x40 [vdpa] device_release+0x33/0x90 kobject_release+0x63/0x160 vdpasim_create+0x127/0x2a0 [vdpa_sim] vdpasim_net_dev_add+0x7d/0xfe [vdpa_sim_net] vdpa_nl_cmd_dev_add_set_doit+0xe1/0x1a0 [vdpa] genl_family_rcv_msg_doit+0x112/0x140 genl_rcv_msg+0xdf/0x1d0 ...
So we must make sure the iova_domain is already initialized before put it.
In addition, we may get the following warning in this case:
WARNING: ... drivers/iommu/iova.c:344 iova_cache_put+0x58/0x70
So we must make sure the iova_cache_put() is invoked only if the iova_cache_get() is already invoked. Let's fix it together.
--- drivers/vdpa/vdpa_sim/vdpa_sim.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/vdpa/vdpa_sim/vdpa_sim.c +5 -2
@@ -591,8 +591,11 @@ static void vdpasim_free(struct vdpa_devvringh_kiov_cleanup (&vdpasim->vqs[i].in_iov); } -put_iova_domain (&vdpasim->iova); -iova_cache_put (); +if (vdpa_get_dma_dev (vdpa)) { +put_iova_domain (&vdpasim->iova); +iova_cache_put (); + } +kvfree (vdpasim->buffer);if (vdpasim->iommu)vhost_iotlb_free (vdpasim->iommu);
Greg Kroah-Hartman
maintainerPATCH 168/179 vhost/vsock: fix incorrect used length reported to the guest
In reply to Greg Kroah-HartmanFrom: Stefano Garzarella <[email protected]>
commit 49d8c5ffad07ca014cfae72a1b9b8c52b6ad9cb8 upstream.
The "used length" reported by calling vhost_add_used() must be the number of bytes written by the device (using "in" buffers).
In vhost_vsock_handle_tx_kick() the device only reads the guest buffers (they are all "out" buffers), without writing anything, so we must pass 0 as "used length" to comply virtio spec.
--- drivers/vhost/vsock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/vhost/vsock.c +1 -1
@@ -554,7 +554,7 @@ static void vhost_vsock_handle_tx_kick(svirtio_transport_free_pkt (pkt); len +=sizeof (pkt->hdr); -vhost_add_used (vq, head, len); +vhost_add_used (vq, head,0 ); total_len += len; added = true; }while (likely (!vhost_exceeds_weight (vq, ++pkts, total_len)));
Greg Kroah-Hartman
maintainerPATCH 169/179 ksmbd: Fix an error handling path in smb2_sess_setup()
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
commit f8fbfd85f5c95fff477a7c19f576725945891d0c upstream.
All the error handling paths of 'smb2_sess_setup()' end to 'out_err'.
All but the new error handling path added by the commit given in the Fixes tag below.
Fix this error handling path and branch to 'out_err' as well.
--- fs/ksmbd/smb2pdu.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/ksmbd/smb2pdu.c +4 -2
@@ -1700,8 +1700,10 @@ int smb2_sess_setup(struct ksmbd_work *w negblob_off =le16_to_cpu (req->SecurityBufferOffset); negblob_len =le16_to_cpu (req->SecurityBufferLength);if (negblob_off < (offsetof(struct smb2_sess_setup_req , Buffer) -4 ) || - negblob_len < offsetof(struct negotiate_message , NegotiateFlags)) -return -EINVAL ; + negblob_len < offsetof(struct negotiate_message , NegotiateFlags)) { + rc = -EINVAL ; + goto out_err; + } negblob = (struct negotiate_message *)((char *)&req->hdr.ProtocolId + negblob_off);
Greg Kroah-Hartman
maintainerPATCH 170/179 tracing: Check pid filtering when creating events
In reply to Greg Kroah-HartmanFrom: Steven Rostedt (VMware) <[email protected]>
commit 6cb206508b621a9a0a2c35b60540e399225c8243 upstream.
When pid filtering is activated in an instance, all of the events trace files for that instance has the PID_FILTER flag set. This determines whether or not pid filtering needs to be done on the event, otherwise the event is executed as normal.
If pid filtering is enabled when an event is created (via a dynamic event or modules), its flag is not updated to reflect the current state, and the events are not filtered properly.
--- kernel/trace/trace_events.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
kernel/trace/trace_events.c +10 -0
@@ -2678,12 +2678,22 @@ static struct trace_event_file * trace_create_new_event(struct trace_event_call *call, struct trace_array *tr) { + struct trace_pid_list *no_pid_list; +struct trace_pid_list *pid_list;struct trace_event_file *file; file =kmem_cache_alloc (file_cachep,GFP_TRACE );if (!file)return NULL ; + pid_list =rcu_dereference_protected (tr->filtered_pids, +lockdep_is_held (&event_mutex)); + no_pid_list =rcu_dereference_protected (tr->filtered_no_pids, +lockdep_is_held (&event_mutex)); + +if (pid_list || no_pid_list) + file->flags |=EVENT_FILE_FL_PID_FILTER ; + file->event_call = call; file->tr = tr;atomic_set (&file->sm_ref,0 );
Greg Kroah-Hartman
maintainerPATCH 171/179 cifs: nosharesock should be set on new server
In reply to Greg Kroah-HartmanFrom: Shyam Prasad N <[email protected]>
commit b9ad6b5b687e798746024e5fc4574d8fa8bdfade upstream.
Recent fix to maintain a nosharesock state on the server struct caused a regression. It updated this field in the old tcp session, and not the new one.
This caused the multichannel scenario to misbehave.
--- fs/cifs/connect.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
fs/cifs/connect.c +4 -3
@@ -1217,10 +1217,8 @@ static int match_server(struct TCP_Serve {struct sockaddr *addr = (struct sockaddr *)&ctx->dstaddr; -if (ctx->nosharesock) { - server->nosharesock = true; +if (ctx->nosharesock)return 0 ; - }/* this server does not share socket */ if (server->nosharesock)
@@ -1376,6 +1374,9 @@ cifs_get_tcp_session(struct smb3_fs_cont goto out_err; } +if (ctx->nosharesock) + tcp_ses->nosharesock = true; + tcp_ses->ops = ctx->ops; tcp_ses->vals = ctx->vals;cifs_set_net_ns (tcp_ses,get_net (current->nsproxy->net_ns));
Greg Kroah-Hartman
maintainerPATCH 172/179 io_uring: fix soft lockup when call __io_remove_buffers
In reply to Greg Kroah-HartmanFrom: Ye Bin <[email protected]>
commit 1d0254e6b47e73222fd3d6ae95cccbaafe5b3ecf upstream.
I got issue as follows:
[ 567.094140] __io_remove_buffers: [1]start ctx=0xffff8881067bf000 bgid=65533 buf=0xffff8881fefe1680 [ 594.360799] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u32:5:108] [ 594.364987] Modules linked in: [ 594.365405] irq event stamp: 604180238 [ 594.365906] hardirqs last enabled at (604180237): [<ffffffff93fec9bd>] _raw_spin_unlock_irqrestore+0x2d/0x50 [ 594.367181] hardirqs last disabled at (604180238): [<ffffffff93fbbadb>] sysvec_apic_timer_interrupt+0xb/0xc0 [ 594.368420] softirqs last enabled at (569080666): [<ffffffff94200654>] __do_softirq+0x654/0xa9e [ 594.369551] softirqs last disabled at (569080575): [<ffffffff913e1d6a>] irq_exit_rcu+0x1ca/0x250 [ 594.370692] CPU: 2 PID: 108 Comm: kworker/u32:5 Tainted: G L 5.15.0-next-20211112+ #88 [ 594.371891] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 594.373604] Workqueue: events_unbound io_ring_exit_work [ 594.374303] RIP: 0010:_raw_spin_unlock_irqrestore+0x33/0x50 [ 594.375037] Code: 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 55 f5 55 fd 48 89 ef e8 ed a7 56 fd 80 e7 02 74 06 e8 43 13 7b fd fb bf 01 00 00 00 <e8> f8 78 474 [ 594.377433] RSP: 0018:ffff888101587a70 EFLAGS: 00000202 [ 594.378120] RAX: 0000000024030f0d RBX: 0000000000000246 RCX: 1ffffffff2f09106 [ 594.379053] RDX: 0000000000000000 RSI: ffffffff9449f0e0 RDI: 0000000000000001 [ 594.379991] RBP: ffffffff9586cdc0 R08: 0000000000000001 R09: fffffbfff2effcab [ 594.380923] R10: ffffffff977fe557 R11: fffffbfff2effcaa R12: ffff8881b8f3def0 [ 594.381858] R13: 0000000000000246 R14: ffff888153a8b070 R15: 0000000000000000 [ 594.382787] FS: 0000000000000000(0000) GS:ffff888399c00000(0000) knlGS:0000000000000000 [ 594.383851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 594.384602] CR2: 00007fcbe71d2000 CR3: 00000000b4216000 CR4: 00000000000006e0 [ 594.385540] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 594.386474] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 594.387403] Call Trace: [ 594.387738] <TASK> [ 594.388042] find_and_remove_object+0x118/0x160 [ 594.389321] delete_object_full+0xc/0x20 [ 594.389852] kfree+0x193/0x470 [ 594.390275] __io_remove_buffers.part.0+0xed/0x147 [ 594.390931] io_ring_ctx_free+0x342/0x6a2 [ 594.392159] io_ring_exit_work+0x41e/0x486 [ 594.396419] process_one_work+0x906/0x15a0 [ 594.399185] worker_thread+0x8b/0xd80 [ 594.400259] kthread+0x3bf/0x4a0 [ 594.401847] ret_from_fork+0x22/0x30 [ 594.402343] </TASK>
Message from syslogd@localhost at Nov 13 09:09:54 ... kernel:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u32:5:108]
[ 596.793660] __io_remove_buffers: [2099199]start ctx=0xffff8881067bf000 bgid=65533 buf=0xffff8881fefe1680
We can reproduce this issue by follow syzkaller log:
r0 = syz_io_uring_setup(0x401, &(0x7f0000000300), &(0x7f0000003000/0x2000)=nil, &(0x7f0000ff8000/0x4000)=nil, &(0x7f0000000280)=<r1=>0x0, &(0x7f0000000380)=<r2=>0x0) sendmsg$ETHTOOL_MSG_FEATURES_SET(0xffffffffffffffff, &(0x7f0000003080)={0x0, 0x0, &(0x7f0000003040)={&(0x7f0000000040)=ANY=[], 0x18}}, 0x0) syz_io_uring_submit(r1, r2, &(0x7f0000000240)=@IORING_OP_PROVIDE_BUFFERS={0x1f, 0x5, 0x0, 0x401, 0x1, 0x0, 0x100, 0x0, 0x1, {0xfffd}}, 0x0) io_uring_enter(r0, 0x3a2d, 0x0, 0x0, 0x0, 0x0)
The reason above issue is 'buf->list' has 2,100,000 nodes, occupied cpu lead to soft lockup.
To solve this issue, we need add schedule point when do while loop in '__io_remove_buffers'.
After add schedule point we do regression, get follow data.
[ 240.141864] __io_remove_buffers: [1]start ctx=0xffff888170603000 bgid=65533 buf=0xffff8881116fcb00 [ 268.408260] __io_remove_buffers: [1]start ctx=0xffff8881b92d2000 bgid=65533 buf=0xffff888130c83180 [ 275.899234] __io_remove_buffers: [2099199]start ctx=0xffff888170603000 bgid=65533 buf=0xffff8881116fcb00 [ 296.741404] __io_remove_buffers: [1]start ctx=0xffff8881b659c000 bgid=65533 buf=0xffff8881010fe380 [ 305.090059] __io_remove_buffers: [2099199]start ctx=0xffff8881b92d2000 bgid=65533 buf=0xffff888130c83180 [ 325.415746] __io_remove_buffers: [1]start ctx=0xffff8881b92d1000 bgid=65533 buf=0xffff8881a17d8f00 [ 333.160318] __io_remove_buffers: [2099199]start ctx=0xffff8881b659c000 bgid=65533 buf=0xffff8881010fe380
...
--- fs/io_uring.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
fs/io_uring.c +2 -3
@@ -4343,6 +4343,7 @@ static int __io_remove_buffers(struct iokfree (nxt);if (++i == nbufs)return i; +cond_resched (); } i++;kfree (buf);
@@ -9249,10 +9250,8 @@ static void io_destroy_buffers(struct iostruct io_buffer *buf;unsigned long index; -xa_for_each (&ctx->io_buffers, index, buf) { +xa_for_each (&ctx->io_buffers, index, buf)__io_remove_buffers (ctx, buf, index,-1U ); -cond_resched (); - } }static void io_req_cache_free (struct list_head *list)
Greg Kroah-Hartman
maintainerPATCH 173/179 firmware: arm_scmi: Fix type error assignment in voltage protocol
In reply to Greg Kroah-HartmanFrom: Cristian Marussi <[email protected]>
commit 026d9835b62bba34b7e657a0bfb76717822f9319 upstream.
Fix incorrect type assignment error reported by sparse as:
drivers/firmware/arm_scmi/voltage.c:159:42: warning: incorrect type in assignment (different base types) drivers/firmware/arm_scmi/voltage.c:159:42: expected restricted __le32 [usertype] level_index drivers/firmware/arm_scmi/voltage.c:159:42: got unsigned int [usertype] desc_index
--- drivers/firmware/arm_scmi/voltage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/arm_scmi/voltage.c +1 -1
@@ -156,7 +156,7 @@ static int scmi_voltage_descriptors_get(int cnt; cmd->domain_id =cpu_to_le32 (v->id); - cmd->level_index = desc_index; + cmd->level_index =cpu_to_le32 (desc_index); ret = ph->xops->do_xfer (ph, tl);if (ret)break ;
Greg Kroah-Hartman
maintainerPATCH 174/179 firmware: arm_scmi: Fix type error in sensor protocol
In reply to Greg Kroah-HartmanFrom: Cristian Marussi <[email protected]>
commit bd074e5039ee16d71833a67337e2f6bf5d106b3a upstream.
Fix incorrect type error reported by sparse as:
drivers/firmware/arm_scmi/sensors.c:640:28: warning: incorrect type in argument 1 (different base types) drivers/firmware/arm_scmi/sensors.c:640:28: expected unsigned int [usertype] val drivers/firmware/arm_scmi/sensors.c:640:28: got restricted __le32 [usertype]
--- drivers/firmware/arm_scmi/sensors.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/arm_scmi/sensors.c +1 -1
@@ -637,7 +637,7 @@ static int scmi_sensor_config_get(constif (ret)return ret; -put_unaligned_le32 (cpu_to_le32 (sensor_id), t->tx.buf); +put_unaligned_le32 (sensor_id, t->tx.buf); ret = ph->xops->do_xfer (ph, t);if (!ret) {struct sensors_info *si = ph->get_priv (ph);
Greg Kroah-Hartman
maintainerPATCH 175/179 docs: accounting: update delay-accounting.rst reference
In reply to Greg Kroah-HartmanFrom: Mauro Carvalho Chehab <[email protected]>
commit 0f60a29c52b515532e6b11dc6b3c9e5b5f7ff2b4 upstream.
The file name: accounting/delay-accounting.rst
should be, instead: Documentation/accounting/delay-accounting.rst.
Also, there's no need to use doc:foo, as automarkup.py will automatically handle plain text mentions to Documentation/ files.
So, update its cross-reference accordingly.
--- Documentation/admin-guide/sysctl/kernel.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/admin-guide/sysctl/kernel.rst +1 -1
@@ -1099,7 +1099,7 @@ task_delayacct =============== Enables/disables task delay accounting (see -:doc:`accounting/delay-accounting.rst`). Enabling this feature incurs +Documentation/accounting/delay-accounting.rst. Enabling this feature incurs a small amount of overhead in the scheduler but is useful for debugging and performance tuning. It is required by some tools such as iotop.
Greg Kroah-Hartman
maintainerPATCH 176/179 blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()
In reply to Greg Kroah-HartmanFrom: Ming Lei <[email protected]>
commit 2a19b28f7929866e1cec92a3619f4de9f2d20005 upstream.
For avoiding to slow down queue destroy, we don't call blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to cancel dispatch work in blk_release_queue().
However, this way has caused kernel oops[1], reported by Changhui. The log shows that scsi_device can be freed before running blk_release_queue(), which is expected too since scsi_device is released after the scsi disk is closed and the scsi_device is removed.
Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue() and disk_release():
1) when disk_release() is run, the disk has been closed, and any sync dispatch activities have been done, so canceling dispatch work is enough to quiesce filesystem I/O dispatch activity.
2) in blk_cleanup_queue(), we only focus on passthrough request, and passthrough request is always explicitly allocated & freed by its caller, so once queue is frozen, all sync dispatch activity for passthrough request has been done, then it is enough to just cancel dispatch work for avoiding any dispatch activity.
[1] kernel panic log
[12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300 [12622.777186] #PF: supervisor read access in kernel mode [12622.782918] #PF: error_code(0x0000) - not-present page [12622.788649] PGD 0 P4D 0 [12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI [12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1 [12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015 [12622.813321] Workqueue: kblockd blk_mq_run_work_fn [12622.818572] RIP: 0010:sbitmap_get+0x75/0x190 [12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 <48> 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58 [12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202 [12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004 [12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030 [12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334 [12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000 [12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030 [12622.889926] FS: 0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000 [12622.898956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0 [12622.913328] Call Trace: [12622.916055] <TASK> [12622.918394] scsi_mq_get_budget+0x1a/0x110 [12622.922969] __blk_mq_do_dispatch_sched+0x1d4/0x320 [12622.928404] ? pick_next_task_fair+0x39/0x390 [12622.933268] __blk_mq_sched_dispatch_requests+0xf4/0x140 [12622.939194] blk_mq_sched_dispatch_requests+0x30/0x60 [12622.944829] __blk_mq_run_hw_queue+0x30/0xa0 [12622.949593] process_one_work+0x1e8/0x3c0 [12622.954059] worker_thread+0x50/0x3b0 [12622.958144] ? rescuer_thread+0x370/0x370 [12622.962616] kthread+0x158/0x180 [12622.966218] ? set_kthread_struct+0x40/0x40 [12622.970884] ret_from_fork+0x22/0x30 [12622.974875] </TASK> [12622.977309] Modules linked in: scsi_debug rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs sunrpc dm_multipath intel_rapl_msr intel_rapl_common dell_wmi_descriptor sb_edac rfkill video x86_pkg_temp_thermal intel_powerclamp dcdbas coretemp kvm_intel kvm mgag200 irqbypass i2c_algo_bit rapl drm_kms_helper ipmi_ssif intel_cstate intel_uncore syscopyarea sysfillrect sysimgblt fb_sys_fops pcspkr cec mei_me lpc_ich mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter drm fuse xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg ixgbe ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata megaraid_sas ghash_clmulni_intel tg3 wdat_wdt mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_debug]
--- block/blk-core.c | 4 +++- block/blk-mq.c | 13 +++++++++++++ block/blk-mq.h | 2 ++ block/blk-sysfs.c | 10 ---------- block/genhd.c | 2 ++ 5 files changed, 20 insertions(+), 11 deletions(-)
block/blk-core.c +3 -1
@@ -389,8 +389,10 @@ void blk_cleanup_queue(struct request_qublk_queue_flag_set (QUEUE_FLAG_DEAD , q);blk_sync_queue (q); -if (queue_is_mq (q)) +if (queue_is_mq (q)) { +blk_mq_cancel_work_sync (q);blk_mq_exit_queue (q); + }/* * In theory, request pool of sched_tags belongs to request queue.
block/blk-mq.c +13 -0
@@ -4018,6 +4018,19 @@ unsigned int blk_mq_rq_cpu(struct reques }EXPORT_SYMBOL (blk_mq_rq_cpu); +void blk_mq_cancel_work_sync (struct request_queue *q) +{ +if (queue_is_mq (q)) { +struct blk_mq_hw_ctx *hctx; +int i; + +cancel_delayed_work_sync (&q->requeue_work); + +queue_for_each_hw_ctx (q, hctx, i) +cancel_delayed_work_sync (&hctx->run_work); + } +} +static int __init blk_mq_init (void ) {int i;
block/blk-mq.h +2 -0
@@ -129,6 +129,8 @@ extern int blk_mq_sysfs_register(structextern void blk_mq_sysfs_unregister (struct request_queue *q);extern void blk_mq_hctx_kobj_init (struct blk_mq_hw_ctx *hctx); +void blk_mq_cancel_work_sync (struct request_queue *q); +void blk_mq_release (struct request_queue *q); static inline struct blk_mq_ctx *__blk_mq_get_ctx(struct request_queue *q,
block/blk-sysfs.c +0 -10
@@ -805,16 +805,6 @@ static void blk_release_queue(struct kobblk_free_queue_stats (q->stats); -if (queue_is_mq (q)) { -struct blk_mq_hw_ctx *hctx; -int i; - -cancel_delayed_work_sync (&q->requeue_work); - -queue_for_each_hw_ctx (q, hctx, i) -cancel_delayed_work_sync (&hctx->run_work); - } -blk_exit_queue (q);blk_queue_free_zone_bitmaps (q);
block/genhd.c +2 -0
@@ -1086,6 +1086,8 @@ static void disk_release(struct device *might_sleep ();WARN_ON_ONCE (disk_live (disk)); +blk_mq_cancel_work_sync (disk->queue); +disk_release_events (disk);kfree (disk->random);xa_destroy (&disk->part_tbl);
Greg Kroah-Hartman
maintainerPATCH 177/179 block: avoid to quiesce queue in elevator_init_mq
In reply to Greg Kroah-HartmanFrom: Ming Lei <[email protected]>
commit 245a489e81e13dd55ae46d27becf6d5901eb7828 upstream.
elevator_init_mq() is only called before adding disk, when there isn't any FS I/O, only passthrough requests can be queued, so freezing queue plus canceling dispatch work is enough to drain any dispatch activities, then we can avoid synchronize_srcu() in blk_mq_quiesce_queue().
Long boot latency issue can be fixed in case of lots of disks added during booting.
--- block/elevator.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
block/elevator.c +8 -2
@@ -694,12 +694,18 @@ void elevator_init_mq(struct request_queif (!e)return ; +/* +* We are called before adding disk, when there isn't any FS I/O, +* so freezing queue plus canceling dispatch work is enough to +* drain any dispatch activities originated from passthrough +* requests, then no need to quiesce queue which may add long boot +* latency, especially when lots of disks are involved. +*/ blk_mq_freeze_queue (q); -blk_mq_quiesce_queue (q); +blk_mq_cancel_work_sync (q); err =blk_mq_init_sched (q, e); -blk_mq_unquiesce_queue (q);blk_mq_unfreeze_queue (q);if (err) {
Greg Kroah-Hartman
maintainerPATCH 178/179 drm/amdgpu/gfx10: add wraparound gpu counter check for APUs as well
In reply to Greg Kroah-HartmanFrom: Alex Deucher <[email protected]>
commit 244ee398855df2adc7d3ac5702b58424a5f684cc upstream.
Apply the same check we do for dGPUs for APUs as well.
--- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c +13 -2
@@ -7729,8 +7729,19 @@ static uint64_t gfx_v10_0_get_gpu_clock_switch (adev->asic_type) {case CHIP_VANGOGH :case CHIP_YELLOW_CARP : - clock = (uint64_t )RREG32_SOC15 (SMUIO ,0 , mmGOLDEN_TSC_COUNT_LOWER_Vangogh) | - ((uint64_t )RREG32_SOC15 (SMUIO ,0 , mmGOLDEN_TSC_COUNT_UPPER_Vangogh) <<32ULL ); +preempt_disable (); + clock_hi =RREG32_SOC15_NO_KIQ (SMUIO ,0 , mmGOLDEN_TSC_COUNT_UPPER_Vangogh); + clock_lo =RREG32_SOC15_NO_KIQ (SMUIO ,0 , mmGOLDEN_TSC_COUNT_LOWER_Vangogh); + hi_check =RREG32_SOC15_NO_KIQ (SMUIO ,0 , mmGOLDEN_TSC_COUNT_UPPER_Vangogh); +/* The SMUIO TSC clock frequency is 100MHz, which sets 32-bit carry over +* roughly every 42 seconds. +*/ +if (hi_check != clock_hi) { + clock_lo =RREG32_SOC15_NO_KIQ (SMUIO ,0 , mmGOLDEN_TSC_COUNT_LOWER_Vangogh); + clock_hi = hi_check; + } +preempt_enable (); + clock = clock_lo | (clock_hi <<32ULL );break ;default :preempt_disable ();
Greg Kroah-Hartman
maintainerPATCH 179/179 drm/amdgpu/gfx9: switch to golden tsc registers for renoir+
In reply to Greg Kroah-HartmanFrom: Alex Deucher <[email protected]>
commit 53af98c091bc42fd9ec64cfabc40da4e5f3aae93 upstream.
Renoir and newer gfx9 APUs have new TSC register that is not part of the gfxoff tile, so it can be read without needing to disable gfx off.
--- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 46 +++++++++++++++++++++++++--------- 1 file changed, 35 insertions(+), 11 deletions(-)
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +35 -11
@@ -140,6 +140,11 @@ MODULE_FIRMWARE("amdgpu/aldebaran_rlc.bi#define mmTCP_CHAN_STEER_5_ARCT 0x0b0c#define mmTCP_CHAN_STEER_5_ARCT_BASE_IDX 0 +#define mmGOLDEN_TSC_COUNT_UPPER_Renoir 0x0025 +#define mmGOLDEN_TSC_COUNT_UPPER_Renoir_BASE_IDX 1 +#define mmGOLDEN_TSC_COUNT_LOWER_Renoir 0x0026 +#define mmGOLDEN_TSC_COUNT_LOWER_Renoir_BASE_IDX 1 +enum ta_ras_gfx_subblock {/*CPC*/ TA_RAS_BLOCK__GFX_CPC_INDEX_START =0 ,
@@ -4228,19 +4233,38 @@ failed_kiq_read:static uint64_t gfx_v9_0_get_gpu_clock_counter (struct amdgpu_device *adev) { -uint64_t clock; +uint64_t clock, clock_lo, clock_hi, hi_check; -amdgpu_gfx_off_ctrl (adev, false); -mutex_lock (&adev->gfx.gpu_clock_mutex); -if (adev->asic_type ==CHIP_VEGA10 &&amdgpu_sriov_runtime (adev)) { - clock =gfx_v9_0_kiq_read_clock (adev); - }else { -WREG32_SOC15 (GC ,0 , mmRLC_CAPTURE_GPU_CLOCK_COUNT,1 ); - clock = (uint64_t )RREG32_SOC15 (GC ,0 , mmRLC_GPU_CLOCK_COUNT_LSB) | - ((uint64_t )RREG32_SOC15 (GC ,0 , mmRLC_GPU_CLOCK_COUNT_MSB) <<32ULL ); +switch (adev->asic_type) { +case CHIP_RENOIR : +preempt_disable (); + clock_hi =RREG32_SOC15_NO_KIQ (SMUIO ,0 , mmGOLDEN_TSC_COUNT_UPPER_Renoir); + clock_lo =RREG32_SOC15_NO_KIQ (SMUIO ,0 , mmGOLDEN_TSC_COUNT_LOWER_Renoir); + hi_check =RREG32_SOC15_NO_KIQ (SMUIO ,0 , mmGOLDEN_TSC_COUNT_UPPER_Renoir); +/* The SMUIO TSC clock frequency is 100MHz, which sets 32-bit carry over +* roughly every 42 seconds. +*/ +if (hi_check != clock_hi) { + clock_lo =RREG32_SOC15_NO_KIQ (SMUIO ,0 , mmGOLDEN_TSC_COUNT_LOWER_Renoir); + clock_hi = hi_check; + } +preempt_enable (); + clock = clock_lo | (clock_hi <<32ULL ); +break ; +default : +amdgpu_gfx_off_ctrl (adev, false); +mutex_lock (&adev->gfx.gpu_clock_mutex); +if (adev->asic_type ==CHIP_VEGA10 &&amdgpu_sriov_runtime (adev)) { + clock =gfx_v9_0_kiq_read_clock (adev); + }else { +WREG32_SOC15 (GC ,0 , mmRLC_CAPTURE_GPU_CLOCK_COUNT,1 ); + clock = (uint64_t )RREG32_SOC15 (GC ,0 , mmRLC_GPU_CLOCK_COUNT_LSB) | + ((uint64_t )RREG32_SOC15 (GC ,0 , mmRLC_GPU_CLOCK_COUNT_MSB) <<32ULL ); + } +mutex_unlock (&adev->gfx.gpu_clock_mutex); +amdgpu_gfx_off_ctrl (adev, true); +break ; } -mutex_unlock (&adev->gfx.gpu_clock_mutex); -amdgpu_gfx_off_ctrl (adev, true);return clock; }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.6 release. There are 179 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.6 release. There are 179 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
5.15.6-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.6 release. There are 179 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.6 release. There are 179 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.15.6-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: a6dab1fb6f7d0b0357301dcad771ff9d349fd6bc
* git describe: v5.15.5-180-ga6dab1fb6f7d
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.5-180-ga6dab1fb6f7d
## No regressions (compared to v5.15.3)
## No fixes (compared to v5.15.3)
## Test result summary
total: 94184, pass: 79366, fail: 1087, skip: 12763, xfail: 968
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 135 total, 135 passed, 0 failed
* arm64: 37 total, 35 passed, 2 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 36 total, 36 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 34 total, 34 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 45 total, 42 passed, 3 failed
* riscv: 24 total, 24 passed, 0 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 20 total, 20 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 37 total, 37 passed, 0 failed
## Test suites summary
* fwts
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.6 release. There are 179 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
No new regressions.
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
114 tests: 108 pass, 6 failLinux version: 5.15.6-rc1-ga6dab1fb6f7d
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Test failures: tegra194-p2972-0000: boot.py
tegra194-p2972-0000: tegra-audio-boot-sanity.sh
tegra194-p2972-0000: tegra-audio-hda-playback.sh
tegra194-p3509-0000+p3668-0000: devices
tegra194-p3509-0000+p3668-0000: tegra-audio-boot-sanity.sh
tegra194-p3509-0000+p3668-0000: tegra-audio-hda-playback.shJon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 33 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.6 release. There are 179 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
No new regressions.
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail 28 boots: 28 pass, 0 fail 114 tests: 108 pass, 6 failLinux version: 5.15.6-rc1-ga6dab1fb6f7d
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04
Quoted 6 lines
Test failures: tegra194-p2972-0000:
boot.pytegra194-p2972-0000: tegra-audio-boot-sanity.sh tegra194-p2972-0000: tegra-audio-hda-playback.sh tegra194-p3509-0000+p3668-0000: devices tegra194-p3509-0000+p3668-0000: tegra-audio-boot-sanity.sh tegra194-p3509-0000+p3668-0000: tegra-audio-hda-playback.sh
Any word on fixes for these failures?
thanks,
greg k-h
Jon Hunter
maintainerQuoted 34 lines · Greg Kroah-Hartman
Quoted 33 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.6 release. There are 179 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
No new regressions.
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail 28 boots: 28 pass, 0 fail 114 tests: 108 pass, 6 failLinux version: 5.15.6-rc1-ga6dab1fb6f7d
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04
Quoted 8 lines
Quoted 6 lines
Test failures: tegra194-p2972-0000:
boot.pytegra194-p2972-0000: tegra-audio-boot-sanity.sh tegra194-p2972-0000: tegra-audio-hda-playback.sh tegra194-p3509-0000+p3668-0000: devices tegra194-p3509-0000+p3668-0000: tegra-audio-boot-sanity.sh tegra194-p3509-0000+p3668-0000: tegra-audio-hda-playback.shAny word on fixes for these failures?
They are in -next and just waiting for them to hit the mainline. There are 3 fixes in total. The following is now in the mainline, however, I have been waiting for the equivalent MTD fix to hit main, because the above boot.py failure will still occur until both are merged.
commit 5f719948b5d43eb39356e94e8d0b462568915381
Author: Jon Hunter <[email protected]> Date: Mon Nov 15 11:38:13 2021 +0000
mmc: spi: Add device-tree SPI IDs
Jon
Signature · 1 line
nvpublic
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.6 release. There are 179 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000. Anything received after that time might be too late.
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 482 pass: 482 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.6 release. There are 179 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.