From: Andrew Morton <akpm@linux-foundation.org>
To: "Thomas Hellström" <thomas@tungstengraphics.com>
Cc: Dave Airlie <airlied@gmail.com>, Jiri Slaby <jirislaby@gmail.com>,
airlied@linux.ie, dri-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1 repost #1] DRM: don't enable irqs in locking
Date: Tue, 29 Jul 2008 00:31:13 -0700 [thread overview]
Message-ID: <20080729003113.d39851b5.akpm@linux-foundation.org> (raw)
In-Reply-To: <488E2CED.1040207@tungstengraphics.com>
On Mon, 28 Jul 2008 22:32:45 +0200 Thomas Hellstr__m <thomas@tungstengraphics.com> wrote:
> Dave Airlie wrote:
> > On Fri, Jul 25, 2008 at 6:42 PM, Jiri Slaby <jirislaby@gmail.com> wrote:
> >
> >> drm_lock_take(); and drm_lock_free(); are called from
> >> drm_locked_tasklet_func(); which disables interrupts when grabbing its
> >> spinlock.
> >>
> >> Don't allow these locking functions to re-enable interrupts when
> >> the tasklet expects them disabled. I.e. use spin_lock_irqsave instead of
> >> spin_lock_bh (with their unlock opposites).
> >>
> >
> > Hmm this has bounced through 2-3 variations.. Thomas any ideas what
> > the final correct answer is?
> >
> > Dave.
> >
> Hmm,
> Yes, this bug could occur, but the remedy is not to use
> spin_lock_irqsave() for lock_data::spinlock but to avoid calling
> drm_lock_take with the drm_device::tasklet_lock held with irqs disabled.
> I'll see if I can come up with a patch.
>
The code in drivers/gpu/drm/drm_lock.c needs some serious help in the
kerneldoc department.
/**
* Take the heavyweight lock.
*
* \param lock lock pointer.
* \param context locking context.
* \return one if the lock is held, or zero otherwise.
*
* Attempt to mark the lock as held by the given context, via the \p cmpxchg instruction.
*/
The /** leadin specifically introduces a kerneldoc-formatted comment.
Yet that comment uses some strange home-made way of denoting function
arguments.
The comments could quite easily be converted to kerneldoc form, which
would be the best thing to do here.
While you're there, please reformat the comments (drm_idlelock_take(),
mainly) to fit in 80-cols. The code carefully does this, but the block
comments then go and ruin it all.
next prev parent reply other threads:[~2008-07-29 7:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-25 8:42 [PATCH 1/1 repost #1] DRM: don't enable irqs in locking Jiri Slaby
2008-07-25 8:54 ` Dave Airlie
2008-07-28 20:32 ` Thomas Hellström
2008-07-29 7:31 ` Andrew Morton [this message]
2008-07-29 8:16 ` Dave Airlie
2008-08-12 13:22 ` Johannes Engel
2008-08-13 8:16 ` Thomas Hellström
2008-08-13 11:08 ` Johannes Engel
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=20080729003113.d39851b5.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=airlied@gmail.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.sourceforge.net \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas@tungstengraphics.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