From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
Date: Sun, 30 Jun 2013 14:04:56 +0100 [thread overview]
Message-ID: <20130630130456.GI3353@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20130630123741.GJ18285@phenom.ffwll.local>
On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> > + mutex_lock(&dev->struct_mutex);
> > + free = drm_mm_search_free(&priv->linear, size, align, 0);
> > + if (free)
> > + obj->linear = drm_mm_get_block(free, size, align);
> > + mutex_unlock(&dev->struct_mutex);
>
> The two-stage search_free+get_block drm_mm interface is something I'd like
> to remove since it' complicates the interface for no gain. And the
> preallocation trick for atomic contexts is pretty racy as-is. Can you
> please convert this over to the insert_node interfaces which take a
> preallocate drm_mm_node?
Yes and no. This is only racy if it is callable from atomic contexts,
which the above isn't, because it takes a mutex, and the above is the
only place which allocations against that pool are done. Mutexes can't
be taken in atomic contexts. Plus it's using the non-atomic drm_mm_*
interfaces.
However, the insert_node interfaces appear not to solve any kind of race.
All they do is allow the kmalloc to be moved out of this region into
the user of this code sequence, while offering no additional locking or
safety. So the mutex lock around a call to drm_mm_insert_node*() is
still required.
As the kmalloc() happens beneath the mutex lock, another thread can't race
with an allocation in the above code anyway. The *only* reason I'll change
this is that it is nicer to the system not to hold locks while allocating
memory.
next prev parent reply other threads:[~2013-06-30 13:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-29 22:52 [PATCH RFC v4 0/3] Armada DRM driver Russell King - ARM Linux
2013-06-29 22:54 ` [PATCH RFC 2/3] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors Russell King
2013-06-29 22:55 ` [PATCH RFC 3/3] DRM: Armada: support for dma_buf import into gem Russell King
2013-06-29 22:56 ` [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver Russell King
2013-06-30 11:59 ` Daniel Vetter
2013-06-30 12:52 ` Russell King - ARM Linux
2013-06-30 17:29 ` Daniel Vetter
2013-07-02 18:01 ` Ville Syrjälä
2013-07-02 18:23 ` Russell King - ARM Linux
2013-07-02 18:52 ` Ville Syrjälä
2013-07-01 0:01 ` Dave Airlie
2013-07-01 0:17 ` Russell King - ARM Linux
2013-07-01 0:40 ` Dave Airlie
2013-07-01 8:52 ` Sebastian Hesselbarth
2013-07-01 9:42 ` Daniel Vetter
2013-07-01 10:50 ` Sebastian Hesselbarth
2013-07-01 21:26 ` Dave Airlie
2013-07-01 23:33 ` Rob Clark
2013-07-01 21:55 ` Rob Clark
2013-07-01 22:07 ` Sebastian Hesselbarth
2013-06-30 12:37 ` Daniel Vetter
2013-06-30 13:04 ` Russell King - ARM Linux [this message]
2013-06-30 13:41 ` Russell King - ARM Linux
2013-06-30 13:53 ` Russell King - ARM Linux
2013-06-30 16:58 ` Daniel Vetter
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=20130630130456.GI3353@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.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 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).