s it as an
argument in both variants. Just a suggestion.
John Ogness
e->planes[i].state = old_plane_state;
> plane->state = new_plane_state;
> }
> + drm_panic_unlock(state->dev);
Is there a reason irqsave/irqrestore variants are not used? Maybe this
code path is too hot?
By leaving interrupts enabled, there is the risk that a panic from
within any interrupt handler may block the drm panic handler.
John Ogness
e/irqrestore variants? By
leaving interrupts enabled, there is the risk that a panic from any
interrupt handler may block the drm panic handler.
John Ogness
in NMI
> context, but I don't know how to simulate that. The goal would be to
> find early if a panic notifier tries to sleep, or do other things that
> are not allowed in a panic context.
Maybe with a new boot argument "unknown_nmi_fake_panic" that triggers
the fake panic instea
tps://lore.kernel.org/lkml/20230119225351.71657-1-0070472...@gmail.com
Signed-off-by: John Ogness
---
I just realized that the nouveau driver style prefers to scope
variables used only in loops.
v3: Define @lret within the for-loop.
drivers/gpu/drm/nouveau/nouveau_gem.c | 18 --
1 file ch
tps://lore.kernel.org/lkml/20230119225351.71657-1-0070472...@gmail.com
Signed-off-by: John Ogness
---
The original report was actually a patch that needed fixing.
Since nobody has stepped up to fix this regression correctly,
I'm posting the v2.
This is a real regression introduced in 6.3-rc1.
drivers/gpu
being translated. Or
perhaps a new variable should be introduced to separate the return value
of dma_resv_wait_timeout() from the return value of this function.
Either way, this is an important fix for 6.3-rc!
John Ogness
ty console, it is assumed the pointer is still valid after
releasing the console_sem. This assumption is incorrect and unsafe.
Make the hack safe by introducing a new function
console_force_preferred_locked() and perform the full operation
under the console_list_lock.
Signed-off-by: John Ogness
Reviewe
the console the
head of the console list.
John Ogness
[0]
https://lore.kernel.org/lkml/20221114162932.141883-1-john.ogn...@linutronix.de
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/log/?h=srcunmisafe.2022.11.09a
John Ogness (38):
printk: Prepare for SRCU
Hi,
After more detailed runtime testing I discovered that I didn't re-insert
the console to the correct place in the list. More below...
On 2022-11-14, John Ogness wrote:
> diff --git a/include/linux/console.h b/include/linux/console.h
> index f716e1dd9eaf..9cea254b34b8 100644
> ---
ty console, it is assumed the pointer is still valid after
releasing the console_sem. This assumption is incorrect and unsafe.
Make the hack safe by introducing a new function
console_force_preferred_locked() and perform the full operation
under the console_list_lock.
Signed-off-by: John Ogness
--
lso
take the console_lock to guarantee safe access to console->seq.
- In console_force_preferred_locked() use hlist_del_rcu() instead of
hlist_del_init_rcu() so that there is never a window where the
console can be viewed as unregistered.
John Ogness
[0]
https://lore.kernel.or
On 2022-11-10, Petr Mladek wrote:
+ /* Only the new head can have CON_CONSDEV set. */
+ WRITE_ONCE(cur_pref_con->flags, cur_pref_con->flags & ~CON_CONSDEV);
>>>
>>> As mentioned in the reply for 7th patch, I would prefer to hide this
>>> WRITE_ONCE into a wrapper, e.g.
On 2022-11-10, Petr Mladek wrote:
>> +void console_force_preferred_locked(struct console *con)
>> +{
>> +struct console *cur_pref_con;
>> +
>> +if (!console_is_registered_locked(con))
>> +return;
>> +
>> +cur_pref_con = console_first();
>> +
>> +/* Already preferred?
ty console, it is assumed the pointer is still valid after
releasing the console_sem. This assumption is incorrect and unsafe.
Make the hack safe by introducing a new function
console_force_preferred_locked() and perform the full operation
under the console_list_lock.
Signed-off-by: John Ogness
--
the enabled boot consoles
- add comments and lockdep assertion to
unregister_console_locked() because it is not clear from the
name which lock is implied
- dropped patches that caused unnecessary churn in the series
John Ogness
[0]
https://lore.kernel.org/lkml/20221019145600.1282823-1-john
On 2022-10-27, Petr Mladek wrote:
>> -if (c) {
>> -unregister_console(c);
>> -c->flags |= CON_CONSDEV;
>> -c->flags &= ~CON_PRINTBUFFER; /* don't print again */
>> -register_console(c);
>> -}
>> +if (c)
>> +
Since the console_lock is not being used for anything other than
safe console list traversal, use srcu console list iteration instead.
Signed-off-by: John Ogness
---
drivers/video/fbdev/xen-fbfront.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev
ty console, it is assumed the pointer is still valid after
releasing the console_sem. This assumption is incorrect and unsafe.
Make the hack safe by introducing a new function
console_force_preferred() to perform the full operation under
the console_list_lock.
Signed-off-by: John Ogness
---
drivers/v
fore adding
to list
- unregister_console: fix ENODEV return value if the console is
not registered
- console_stop: synchronize srcu
- printk_late_init: use _safe variant of iteration
- __pr_flush: use srcu instead of relying on console_lock for
list iteration
John Ogness
[0] https://lor
On 2022-02-15, Sebastian Siewior wrote:
>> From: Jiri Kosina
>>
>> drm_fb_helper_damage() is acquiring spinlock_t (helper->damage_lock),
>> while it can be called from contexts where raw_spinlock_t is held (e.g.
>> console_owner lock obtained on vprintk_emit() codepath).
>>
>> As the
On 2021-11-10, Sultan Alsawaf wrote:
> On Wed, Nov 10, 2021 at 11:13:37AM +0106, John Ogness wrote:
>> Even after we introduce kthread printers, there will still be
>> situations where direct printing is used: booting (before kthreads
>> exist) and shutdown/suspend/c
not yet exist (hoping to get them in for
5.17), I am not sure how we should address the reported bug for existing
kernels.
John Ogness
ell.
I do not know if this is a good channel for reporting this, so please
let me know if I should report it somewhere else. Also let me know if
you need any additional information from me.
John Ogness
ng some
Kconfig settings from that subsystem. Headers exist to make information
available to external code. Kconfig (particularly for a subsystem) exist
to configure that subsystem.
But my feeling on this may be misguided. Is it generally accepted in the
kernel tha
keep the related messages together.
>>
>> The lockless ringbuffer might make handling of related (partial)
>> lines worse or better. It might justify KUnit's extra buffering
>> or it might allow to get rid of it.
>
> Thanks for CC'ing me on the printk ringbuffer t
On 2019-03-14, John Ogness wrote:
> On 2019-03-14, Daniel Vetter wrote:
>> That's why we came up with the trylock + immediate bail out design if
>> that fails. Plus really only render the oops int whatever is the
>> current display buffer, so that we don't have to do any hw
you may have
functions without a return value taking spinlocks. But now those
functions could fail.
John Ogness
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
makes sense to do this if the driver has a chance of being
successful. Ignoring locks is a serious issue. I personally am quite
unhappy that the serial drivers do this, which was part of my motivation
for the new printk design I'm working on.
If the driver is not capable of doing something usef
29 matches
Mail list logo
