From: Thomas Gleixner <tglx@linutronix.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
Tian Tao <tiantao6@hisilicon.com>
Cc: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
"Zhang Rui" <rui.zhang@intel.com>,
"Daniel Lezcano" <daniel.lezcano@linaro.org>,
amitk@kernel.org,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
"Linux PM list" <linux-pm@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] thermal: replace spin_lock_irqsave by spin_lock in hard IRQ
Date: Fri, 23 Oct 2020 23:45:17 +0200 [thread overview]
Message-ID: <877drg62he.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CAMuHMdVcraVpetQwdj7hW5bCum1SUXz14X6NhcVtq3BH3Csyzw@mail.gmail.com>
On Thu, Oct 22 2020 at 14:51, Geert Uytterhoeven wrote:
> On Wed, Oct 21, 2020 at 2:15 PM Tian Tao <tiantao6@hisilicon.com> wrote:
>> The code has been in a irq-disabled context since it is hard IRQ. There
>> is no necessity to do it again.
>>
> Is this also true if CONFIG_PREEMPT_RT=y, and all irq handlers execute
> in the context of special tasks?
On RT or even on mainline with 'threadirqs' on the command line all
interrupts which are not explicitly requested with IRQF_NO_THREAD run
their handlers in thread context. The same applies to soft interrupts.
That means they are subject to the normal scheduler rules and no other
code is going to acquire that lock from hard interrupt context either,
so the irqsave() here is pointless in all cases.
Famous last words...
... unless the driver does magic things like having a hrtimer armed
which expires in hard interrupt context and touches the very same
lock, but that's not the case in this particular driver.
So the change itself is correct, but the change log could do with some
polishing. :)
Thanks,
tglx
next prev parent reply other threads:[~2020-10-23 21:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-21 3:05 [PATCH] thermal: replace spin_lock_irqsave by spin_lock in hard IRQ Tian Tao
2020-10-21 19:42 ` Niklas Söderlund
2020-10-22 12:51 ` Geert Uytterhoeven
2020-10-23 21:45 ` Thomas Gleixner [this message]
2020-10-26 18:28 ` Daniel Lezcano
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=877drg62he.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=amitk@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=niklas.soderlund@ragnatech.se \
--cc=rui.zhang@intel.com \
--cc=tiantao6@hisilicon.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox