From: Thomas Gleixner <tglx@linutronix.de>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
David Airlie <airlied@linux.ie>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/fence: Do not use TIMER_IRQSAFE
Date: Thu, 28 Feb 2019 11:50:43 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.21.1902281136260.1821@nanos.tec.linutronix.de> (raw)
In-Reply-To: <155134918155.5847.17130320586410453868@skylake-alporthouse-com>
On Thu, 28 Feb 2019, Chris Wilson wrote:
> Quoting Thomas Gleixner (2019-02-28 10:09:26)
> > On Thu, 28 Feb 2019, Chris Wilson wrote:
> > > It may not be the best of api, but it's the only one available for the
> > > driver to use...
> >
> > The comment in the header files says clearly:
> >
> > * Note: The irq disabled callback execution is a special case for
> > * workqueue locking issues. It's not meant for executing random crap
> > * with interrupts disabled. Abuse is monitored!
> >
> > So what's so special in drm that you need to call del_timer_sync() from
> > interrupt context?
>
> There's no protection against fence signaling from inside interrupt
> context, and a lot of pressure to do so.
Whatever that means that still does not justify to pick something which is
clearly stated not to be for general usage without talking to the people
who added that restriction.
I looked at that code and it's so well commented that's it's utterly
obvious how all this is connected and why this is the only way to solve the
problem. Oh well..
Thanks,
tglx
prev parent reply other threads:[~2019-02-28 10:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 16:28 [PATCH] drm/i915/fence: Do not use TIMER_IRQSAFE Sebastian Andrzej Siewior
2019-02-12 19:10 ` ✗ Fi.CI.BAT: failure for " Patchwork
2019-02-26 16:00 ` [PATCH] " Sebastian Andrzej Siewior
2019-02-28 10:00 ` [Intel-gfx] " Chris Wilson
2019-02-28 10:00 ` Chris Wilson
2019-02-28 10:09 ` Thomas Gleixner
2019-02-28 10:19 ` Chris Wilson
2019-02-28 10:19 ` Chris Wilson
2019-02-28 10:50 ` Thomas Gleixner [this message]
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=alpine.DEB.2.21.1902281136260.1821@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=airlied@linux.ie \
--cc=bigeasy@linutronix.de \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
/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.