Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
From:   Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
Date:   Tue, 20 Sep 2022 19:58:48 +0200
Message-ID: <CAGzjT4fd3cGh0zKDLUxM4Rce2mh_R9cQcNunBz0iykVHsLAS5g@mail.gmail.com>
Subject: Repost: Clocksource: should the read() function of a clocksource be
 NMI safe?
To:     daniel.lezcano@linaro.org, Thomas Gleixner <tglx@linutronix.de>
Cc:     linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hello all,

The ktime_get_*_fast_ns() functions in kernel/time/timekeeping.c are
listed as NMI safe.

If I am correct, the implementation of these functions uses the read()
function of the currently selected clocksource.

But a potential lockup can occur if this read() function uses a raw
spinlock. A running read() function can be interrupted by an NMI which
also calls the read() function. The NMI handler will then spin forever
in an attempt to lock an already locked raw spinlock.

Is my reasoning correct? Should the read() function of a clocksource
always be NMI safe? This requirement is not documented and I see that
several clocksource drivers (such as drivers/clocksource/i8253.c) are
not NMI safe (they lock a raw spinlock in their read() function).

Regards,
   Jaccon Bastiaansen