On 2024-11-05, Petr Mladek wrote:
> Observation:
>
> + CON_ENABLED is not needed for the original purpose. Only enabled
> consoles are added into @console_list.
>
> + CON_ENABLED is still used to explicitely block the console driver
> during suspend by console_stop()/console_start() in
lbacks, to make sure it won't try to write to the framebuffer
> while the graphic driver is suspended.
>
> Signed-off-by: Jocelyn Falempe
Reviewed-by: John Ogness
n on the kernel command line with:
> drm_client_lib.default=log or drm_client_lib.default=fbdev
>
> Signed-off-by: Jocelyn Falempe
Reviewed-by: John Ogness # console API
On 2024-11-04, Petr Mladek wrote:
> I wonder whether console_start()/console_stop() should really
> manipulate CON_ENABLE flag. It might be historical solution when
> @console_suspended was a global variable.
>
> But it has changed with the commit 9e70a5e109a4a2336 ("printk: Add
> per-console susp
On 2024-11-04, Jocelyn Falempe wrote:
> I looked at what serial drivers are doing, because they can also have
> their clock gated in suspend.
>
> Would calling console_stop() in the suspend and console_start() in
> resume work ?
Yes. That is what it is for.
John Ogness
it as a module, then a userspace
>application will be more appropriate than this module.
>
> Signed-off-by: Jocelyn Falempe
Reviewed-by: John Ogness # console API
On 2024-09-06, John Ogness wrote:
> Your device_lock()/device_unlock() callbacks probably just need to
> lock/unlock your mutex @drm_log_lock.
Sorry, forgot to mention that the device_lock() callback must also
disable migration. Since you are using a mutex, you will need to
manually do t
utbuf, wctxt->len).
Please let me know if you run into any issues. We probably should write
a document "HOWTO write an NBCON console driver".
John Ogness
On 2024-08-01, John Ogness wrote:
> On 2024-08-01, Jocelyn Falempe wrote:
>> I think I can also register one console for each drm driver, which
>> will simplify drm_log even further. (currently it would mean having a
>> circular buffer and work function for each driver which
On 2024-08-01, Jocelyn Falempe wrote:
> I think I can also register one console for each drm driver, which
> will simplify drm_log even further. (currently it would mean having a
> circular buffer and work function for each driver which is a bit too
> much).
Indeed.
> Do you know if there is a c
se the console must
be able to print directly in NMI context and must not defer. But
write_atomic() is optional, so you should be fine there.
Disclaimer: Only in PREEMPT_RT patchset at the moment.
John Ogness
ite_thread() may be the callback you are interested
instead. Note that for CON_NBCON, write_atomic() is optional,
write_thread() is mandatory.
Disclaimer: All of this currently only available in the PREEMPT_RT
patchset. So until it hits mainline, semantics may yet change.
John Ogness
/bcache/bset.c:bch_dump_bucket()
from commit cafe56359144("bcache: A block layer cache")
These should also be removed. Although Kent should verify that the
console lock is not providing some sort of necessary side-effect
synchronization.
John Ogness
gt; Reported-by: syzbot+6cebc1af246fe020a...@syzkaller.appspotmail.com
> References:
> https://lore.kernel.org/dri-devel/26c1ff061cd0d...@google.com/
> Signed-off-by: Daniel Vetter
> Fixes: a8f354284304 ("bcachefs: bch2_print_string_as_lines()")
Reviewed-by: John Ogness
lines in between.
There is no way to guarantee a contiguous ringbuffer block using
multiple printk() calls.
The console_lock usage should be removed.
John Ogness
t. I would pass 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
ve/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
s when the panic occurs 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" th
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.
driver
ng 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
tty 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
Re
make 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
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
>
tty 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 Ognes
se, also
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.kern
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. console_set_flag
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? */
tty 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 Ognes
y of 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
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)
>> +console_force_prefe
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
tty 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
---
driv
er before 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:
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 critical
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/crash
Since kthread printers do 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
test framework is going to
>> do its own buffering to 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
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
example, 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
ven if the trylock fails. It only
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 n
44 matches
Mail list logo
