[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o8382j5s.fsf@jogness.linutronix.de>
Date: Tue, 15 Feb 2022 17:29:27 +0106
From: John Ogness <john.ogness@...utronix.de>
To: Sebastian Siewior <bigeasy@...utronix.de>,
Jiri Kosina <jikos@...nel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm: fb-helper: Avoid nesting spinlock_t into
raw_spinlock_t
On 2022-02-15, Sebastian Siewior <bigeasy@...utronix.de> wrote:
>> From: Jiri Kosina <jkosina@...e.cz>
>>
>> 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 sections protected by damage_lock are super-tiny, let's
>> fix this by converting it to raw_spinlock_t in order not to violate
>> PREEMPT_RT-imposed lock nesting rules.
>>
>> This fixes the splat below.
>>
>> =============================
>> [ BUG: Invalid wait context ]
>> 5.17.0-rc4-00002-gd567f5db412e #1 Not tainted
>
> rc4. Is this also the case in the RT tree which includes John's printk
> changes?
In the RT tree, the fbcon's write() callback is only called in
preemptible() contexts. So this is only a mainline issue.
The series I recently posted to LKML [0] should also address this issue
(if/when it gets accepted).
John
[0] https://lore.kernel.org/lkml/20220207194323.273637-1-john.ogness@linutronix.de
Powered by blists - more mailing lists