From: Finn Thain <fthain@telegraphics.com.au>
To: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"geert@linux-m68k.org" <geert@linux-m68k.org>,
"funaho@jurai.org" <funaho@jurai.org>,
"philb@gnu.org" <philb@gnu.org>,
"corbet@lwn.net" <corbet@lwn.net>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-m68k@lists.linux-m68k.org"
<linux-m68k@lists.linux-m68k.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform
Date: Thu, 18 Feb 2021 16:30:20 +1100 (AEDT) [thread overview]
Message-ID: <28d4b91d-1774-a8a-df97-7ac9b365c2@telegraphics.com.au> (raw)
In-Reply-To: <0c0ea8eca77c45ea89f2d4432580211c@hisilicon.com>
On Wed, 17 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > >
> > > So what is really confusing and a pain to me is that: For years
> > > people like me have been writing device drivers with the idea that
> > > irq handlers run with interrupts disabled after those commits in
> > > genirq. So I don't need to care about if some other IRQs on the same
> > > cpu will jump out to access the data the current IRQ handler is
> > > accessing.
> > >
> > > but it turns out the assumption is not true on some platform. So
> > > should I start to program devices driver with the new idea
> > > interrupts can actually come while irqhandler is running?
> > >
> > > That's the question which really bothers me.
> > >
> >
> > That scenario seems a little contrived to me (drivers for two or more
> > devices sharing state through their interrupt handlers). Is it real? I
> > suppose every platform has its quirks. The irq lock in
> > sonic_interrupt() is only there because of a platform quirk (the same
> > device can trigger either of two IRQs). Anyway, no-one expects all
> > drivers to work on all platforms; I don't know why it bothers you so
> > much when platforms differ.
>
> Basically, we wrote drivers with the assumption that this driver will be
> cross-platform. (Of course there are some drivers which can only work on
> one platform, for example, if the IP of the device is only used in one
> platform as an internal component of a specific SoC.)
>
> So once a device has two or more interrupts, we need to consider one
> interrupt might preempt another one on m68k on the same cpu if we also
> want to support this driver on m68k. this usually doesn't matter on
> other platforms.
>
When users show up who desire to run your drivers on their platform, you
can expect them to bring patches and a MAINTAINERS file entry. AFAIK,
Linux development has always worked that way.
Besides, not all m68k platforms implement priority masking. So there's no
problem with portability to m68k per se.
> on the other hand, there are more than 400 irqs_disabled() in kernel, I
> am really not sure if they are running with the knowledge that the true
> irqs_disabled() actually means some interrupts are off and some others
> are still open on m68k.
Firstly, use of irqs_disabled() is considered an antipattern by some
developers. Please see,
https://lore.kernel.org/linux-scsi/X8pfD5XtLoOygdez@lx-t490/
and
commit e6b6be53ec91 ("Merge branch 'net-in_interrupt-cleanup-and-fixes'")
This means that the differences in semantics between the irqs_disabled()
implementations on various architectures are moot.
Secondly, the existence of irqs_disabled() call sites does not imply a
flaw in your drivers nor in the m68k interrupt scheme. The actual semantic
differences are immaterial at many (all?) of these call sites.
> Or they are running with the assumption that the true irqs_disabled()
> means IRQ is totally quiet? If the latter is true, those drivers might
> fail to work on m68k as well.
>
Yes it's possible, and that was my fear too back in 2017 when I raised the
same question with the m68k maintainer. But I never found any code making
that assumption. If you know of such a bug, do tell. So far, your fears
remain unfounded.
> Thanks
> Barry
>
next prev parent reply other threads:[~2021-02-18 5:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-12 1:18 [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform Song Bao Hua (Barry Song)
2021-02-12 22:34 ` Arnd Bergmann
2021-02-12 23:00 ` Song Bao Hua (Barry Song)
2021-02-12 23:05 ` Arnd Bergmann
2021-02-12 23:46 ` Song Bao Hua (Barry Song)
2021-02-13 16:32 ` Arnd Bergmann
2021-02-13 22:18 ` Song Bao Hua (Barry Song)
2021-02-13 23:18 ` Song Bao Hua (Barry Song)
2021-02-14 5:10 ` Finn Thain
2021-02-15 13:06 ` Andy Shevchenko
2021-02-15 22:22 ` Finn Thain
2021-02-17 22:41 ` Song Bao Hua (Barry Song)
2021-02-18 5:30 ` Finn Thain [this message]
2021-02-18 11:19 ` Arnd Bergmann
2021-02-18 12:30 ` Geert Uytterhoeven
2021-02-18 13:59 ` Arnd Bergmann
2021-02-18 15:38 ` Geert Uytterhoeven
2021-02-18 22:11 ` Michael Schmitz
2021-02-19 8:10 ` Geert Uytterhoeven
2021-02-19 22:30 ` Brad Boyer
2021-02-20 6:32 ` Finn Thain
2021-02-20 7:08 ` Brad Boyer
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=28d4b91d-1774-a8a-df97-7ac9b365c2@telegraphics.com.au \
--to=fthain@telegraphics.com.au \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=corbet@lwn.net \
--cc=funaho@jurai.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=mingo@redhat.com \
--cc=philb@gnu.org \
--cc=song.bao.hua@hisilicon.com \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).