From: Anna-Maria Behnsen <anna-maria@linutronix.de>
To: "Thomas Gleixner" <tglx@linutronix.de>,
朱恺乾 <zhukaiqian@xiaomi.com>,
"Daniel Lezcano" <daniel.lezcano@linaro.org>,
张嘉伟 <zhangjiawei8@xiaomi.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
王韬 <lingyue@xiaomi.com>, 熊亮 <xiongliang@xiaomi.com>,
"isaacmanjarres@google.com" <isaacmanjarres@google.com>,
"Frederic Weisbecker" <frederic@kernel.org>,
梁伟鹏 <weipengliang@xiaomi.com>, 翁金飞 <wengjinfei@xiaomi.com>
Subject: Re: [PATCH] tick/broadcast: Plug clockevents replacement race
Date: Wed, 25 Sep 2024 11:45:15 +0200 [thread overview]
Message-ID: <87v7ykf4no.fsf@somnus> (raw)
In-Reply-To: <87cymdsu0r.ffs@tglx>
Thomas Gleixner <tglx@linutronix.de> writes:
> 朱恺乾 reported and decoded the following race condition when a broadcast
> device is replaced:
>
> CPUA CPUB
> __tick_broadcast_oneshot_control()
> bc = tick_broadcast_device.evtdev;
> tick_install_broadcast_device(dev)
> clockevents_exchange_device(cur, dev)
> shutdown(cur);
> detach(cur);
> cur->handler = noop;
> tick_broadcast_device.evtdev = dev;
>
> tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device.
>
> If the original broadcast device has a restricted interrupt affinity mask
> and the last CPU in that mask goes offline then the BUG() in
> tick_cleanup_dead_cpu() triggers because the clockevent device is not in
> detached state.
>
> The reason for this is that tick_install_broadcast_device() is not
> serialized vs. tick broadcast operations.
>
> The obvious cure is to serialize tick_install_broadcast_device() with
> tick_broadcast_lock against a concurrent tick broadcast operation.
>
> That requires to split clockevents_exchange_device() into two parts, one
> which does the exchange, shutdown and detach operation and the other which
> drops the module reference count. This is required because the module
> reference cannot be dropped while holding tick_broadcast_lock.
>
> Let clockevents_exchange_device() do both operations as before, but let the
> broadcast device code take the two step approach and do the device
> exchange under tick_broadcast_lock and drop the module reference count
> after releasing it.
>
> Fixes: f8381cba04ba ("[PATCH] tick-management: broadcast functionality")
> Reported-by: 朱恺乾 <zhukaiqian@xiaomi.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> kernel/time/clockevents.c | 33 ++++++++++++++++++++-------------
> kernel/time/tick-broadcast.c | 36 ++++++++++++++++++++++--------------
> kernel/time/tick-internal.h | 2 ++
> 3 files changed, 44 insertions(+), 27 deletions(-)
>
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -557,34 +557,41 @@ void clockevents_handle_noop(struct cloc
[...]
>
> /**
> + * clockevents_exchange_device - release and request clock devices
> + * @old: device to release (can be NULL)
> + * @new: device to request (can be NULL)
> + *
> + * Called from various tick functions with clockevents_lock held and
> + * interrupts disabled.
can you please transform the comment into a lockdep annotation?
Thanks
next prev parent reply other threads:[~2024-09-25 9:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <042520850d394f0bb0004a226db63d0d@xiaomi.com>
2024-06-27 11:26 ` Race condition when replacing the broadcast timer Thomas Gleixner
2024-06-28 1:59 ` [External Mail]Re: " 朱恺乾
2024-06-28 7:22 ` Daniel Lezcano
2024-07-01 2:11 ` 朱恺乾
2024-07-10 20:30 ` Thomas Gleixner
2024-07-29 11:44 ` Thomas Gleixner
2024-08-12 14:19 ` [PATCH] tick/broadcast: Plug clockevents replacement race Thomas Gleixner
2024-09-25 9:45 ` Anna-Maria Behnsen [this message]
2024-10-17 16:16 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v7ykf4no.fsf@somnus \
--to=anna-maria@linutronix.de \
--cc=daniel.lezcano@linaro.org \
--cc=frederic@kernel.org \
--cc=isaacmanjarres@google.com \
--cc=lingyue@xiaomi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=weipengliang@xiaomi.com \
--cc=wengjinfei@xiaomi.com \
--cc=xiongliang@xiaomi.com \
--cc=zhangjiawei8@xiaomi.com \
--cc=zhukaiqian@xiaomi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.