public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Siluvery, Arun" <arun.siluvery@intel.com>
To: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: possible struct_mutex race, gtt_space becomes invalid in execbuf under memory pressure
Date: Mon, 18 Nov 2013 15:51:30 +0000	[thread overview]
Message-ID: <1384789888.6058.5.camel@asiluver-linux.isw.intel.com> (raw)

Hi All,

I am running a repetitive test on HSW with max available RAM limited to
1GB (max TOLUD is 1GB) and it fails with NULL pointer dereference in
execbuf ioctl.

Debug showed that the batch_obj->gtt_space which was valid becomes NULL
before it is dispatched. During debug I stored batch_obj->gtt_space
address in execbuf and compared this address whenever an obj is freed in
i915_gem_object_unbind() and found that it is triggered by
i915_gem_fault(). It is freed as it is not yet pinned.

I have artificially incremented the pin_count of this bo to see if it
helps as a workaround but now I am seeing kernel panic with "general
protection fault".

It is not clear to me how i915_gem_fault() is able to acquire
struct_mutex as it is held by execbuf ioctl. It is released if
relocation is done by slow path but that is not the case here.

There are page allocation failures of different orders during the test,
but as the system runs out of memory, low memory killer starts killing
processes to free up space and also i915_gem_evict_everything() is
called to free space, the system recovers from it but is failing
randomly.

It looks like somewhere there is a possibility where struct_mutex is
released during execbuf and the fault handler is able to free the valid
bo because of memory pressure.
Is there any possibility for this to happen?

I really appreciate any suggestions on how to debug further.

regards
Arun

                 reply	other threads:[~2013-11-18 15:52 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1384789888.6058.5.camel@asiluver-linux.isw.intel.com \
    --to=arun.siluvery@intel.com \
    --cc=intel-gfx@lists.freedesktop.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