From: Joe Perches <joe@perches.com>
To: Tom Rix <trix@redhat.com>,
jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
rodrigo.vivi@intel.com, tvrtko.ursulin@linux.intel.com,
airlied@linux.ie, daniel@ffwll.ch
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/i915: change node clearing from memset to initialization
Date: Sat, 16 Apr 2022 11:33:34 -0700 [thread overview]
Message-ID: <26839195c315eebcd1148d2a3de6a0df9e42dd1c.camel@perches.com> (raw)
In-Reply-To: <20220416172325.1039795-1-trix@redhat.com>
On Sat, 2022-04-16 at 13:23 -0400, Tom Rix wrote:
> In insert_mappable_node(), the parameter node is
> cleared late in node's use with memset.
> insert_mappable_node() is a singleton, called only
> from i915_gem_gtt_prepare() which itself is only
> called by i915_gem_gtt_pread() and
> i915_gem_gtt_pwrite_fast() where the definition of
> node originates.
>
> Instead of using memset, initialize node to 0 at it's
> definitions.
trivia: /it's/its/
Only reason _not_ to do this is memset is guaranteed to
zero any padding that might go to userspace.
But it doesn't seem there is any padding anyway nor is
the struct available to userspace.
So this seems fine though it might increase overall code
size a tiny bit.
I do have a caveat: see below:
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
[]
> @@ -328,7 +327,6 @@ static struct i915_vma *i915_gem_gtt_prepare(struct drm_i915_gem_object *obj,
> goto err_ww;
> } else if (!IS_ERR(vma)) {
> node->start = i915_ggtt_offset(vma);
> - node->flags = 0;
Why is this unneeded?
from: drm_mm_insert_node_in_range which can set node->flags
__set_bit(DRM_MM_NODE_ALLOCATED_BIT, &node->flags);
next prev parent reply other threads:[~2022-04-16 18:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-16 17:23 Tom Rix
2022-04-16 18:33 ` Joe Perches [this message]
2022-04-16 20:48 ` Tom Rix
2022-04-16 21:04 ` Joe Perches
2022-04-16 22:25 ` Tom Rix
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=26839195c315eebcd1148d2a3de6a0df9e42dd1c.camel@perches.com \
--to=joe@perches.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=trix@redhat.com \
--cc=tvrtko.ursulin@linux.intel.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
all inboxes | Powered by JetHome®