As the rings may be processed and their requests deallocated in a
different order to the natural retirement during a reset,
/* Whilst this request exists, batch_obj will be on the
* active_list, and so will hold the active reference. Only when this
* request is retired will the the batch_obj be moved onto the
* inactive_list and lose its active reference. Hence we do not need
* to explicitly hold another reference here.
*/
is violated, and the batch_obj may be dereferenced after it had been
freed on another ring. This can be simply avoided by processing the
status update prior to deallocating any requests.
Fixes regression (a possible OOPS following a GPU hang) from
commit aa60c664e6df502578454621c3a9b1f087ff8d25
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Wed Jun 12 15:13:20 2013 +0300
drm/i915: find guilty batch buffer on ring resets
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Add the code comment Chris supplied.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Whilst looking up the objects required for an execbuffer, an untimely
allocation failure in creating the vma results in the object being
unreferenced from two lists. The ownership during the lookup is meant to
be moved from the list of objects being looked to the vma, and this
double unreference upon error results in a use-after-free.
Fixes regression from
commit 27173f1f95db5e74ceb35fe9a2f2f348ea11bac9
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Wed Aug 14 11:38:36 2013 +0200
drm/i915: Convert execbuf code to use vmas
Based on the fix by Ben Widawsky.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: stable@vger.kernel.org
[danvet: Bikeshed the crucial comment above the ownership transfer as
discussed on irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These four patches fix a few issues discovered since the initial merge,
which have been reviewed by Rob Clark and Thierry Reding.
* 'drm-tda998x-3.12-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox:
DRM: Armada: prime refcounting bug fix
DRM: Armada: fix printing of phys_addr_t/dma_addr_t
DRM: Armada: destroy framebuffer after helper
DRM: Armada: implement lastclose() for fbhelper
Just a bunch of regression fixes plus a few patches for long-standing
issues in gem corner-cases that we've hunted down in the past weeks. Since
apparently people hit those in the wild (and we also have nice igts for
them) I've opted for -fixes and cc: stable.
There's 1-2 things oustanding on top of this where I'm still waiting on
confirmation from testing, but nothing really scary.
* tag 'drm-intel-fixes-2013-12-11' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: don't update the dri1 breadcrumb with modesetting
drm/i915: Repeat eviction search after idling the GPU
drm/i915: Fix use-after-free in do_switch
drm/i915: fix pm init ordering
drm/i915: Hold mutex across i915_gem_release
drm/i915: Skip clock checks on BDW
drm/i915: Do not clobber config status after a forced restore of hw state
drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
As promised bdw fixes come separate for now. Just a few minior things.
* 'bdw-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell
drm/i915/bdw: Limit GTT to 2GB
drm/i915/bdw: Add comment about gen8 HWS PGA
drm/i915/bdw: Free correct number of ppgtt pages
drm/i915/bdw: Do gen6 style reset for gen8
drm/i915/bdw: GEN8 backlight support
drm/i915/bdw: Add BDW to ULT macro
The update is horribly racy since it doesn't protect at all against
concurrent closing of the master fd. And it can't really since that
requires us to grab a mutex.
Instead of jumping through hoops and offloading this to a worker
thread just block this bit of code for the modesetting driver.
Note that the race is fairly easy to hit since we call the breadcrumb
function for any interrupt. So the vblank interrupt (which usually
keeps going for a bit) is enough. But even if we'd block this and only
update the breadcrumb for user interrupts from the CS we could hit
this race with kms/gem userspace: If a non-master is waiting somewhere
(and hence has interrupts enabled) and the master closes its fd
(probably due to crashing).
v2: Add a code comment to explain why fixing this for real isn't
really worth it. Also improve the commit message a bit.
v3: Fix the spelling in the comment.
Reported-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Cc: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commit 011c2282c74d changed the way refcounting on imported dma_bufs
works, and this hadn't been spotted while forward-porting Armada.
Reflect the changes in that commit into the Armada driver.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
These can be 64-bit quantities, so fix them up appropriately.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Destroy the framebuffer only after the helper, since the helper may
still be referencing the framebufer at this point.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Call drm_fb_helper_restore_fbdev_mode() upon last close so that in the
event of the X server crashing, we have some kind of mode restored.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
With the advent of hw context support, we gained some objects that are
pinned for the duration of their request. That is we can make aperture
space available by idling the GPU and in the process performing a
context switch back to the always-pinned default context. As such, we
should not conclude that there is no space in the aperture for the
current object until we have unpinned any such context objects.
Note that we also have the problem of outstanding pageflips preventing
eviction of their framebuffer objects to resolve.
Testcase: igt/gem_ctx_exec/eviction
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72507
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: lu hua <huax.lu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Userspace uses this to workaround overcommit issues
by flushing the command stream early.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
So apparently under ridiculous amounts of memory pressure we can get
into trouble in do_switch when we try to move the old hw context
backing storage object onto the active lists.
With list debugging enabled that usually results in us chasing a
poisoned pointer - which means we've hit upon a vma that has been
removed from all lrus with list_del (and then deallocated, so it's a
real use-after free).
Ian Lister has done some great callchain chasing and noticed that we
can reenter do_switch:
i915_gem_do_execbuffer()
i915_switch_context()
do_switch()
from = ring->last_context;
i915_gem_object_pin()
i915_gem_object_bind_to_gtt()
ret = drm_mm_insert_node_in_range_generic();
// If the above call fails then it will try i915_gem_evict_something()
// If that fails it will call i915_gem_evict_everything() ...
i915_gem_evict_everything()
i915_gpu_idle()
i915_switch_context(DEFAULT_CONTEXT)
Like with everything else where the shrinker or eviction code can
invalidate pointers we need to reload relevant state.
Note that there's no need to recheck whether a context switch is still
required because:
- Doing a switch to the same context is harmless (besides wasting a
bit of energy).
- This can only happen with the default context. But since that one's
pinned we'll never call down into evict_everything under normal
circumstances. Note that there's a little driver bringup fun
involved namely that we could recourse into do_switch for the
initial switch. Atm we're fine since we assign the context pointer
only after the call to do_switch at driver load or resume time. And
in the gpu reset case we skip the entire setup sequence (which might
be a bug on its own, but definitely not this one here).
Cc'ing stable since apparently ChromeOS guys are seeing this in the
wild (and not just on artificial stress tests), see the reference.
Note that in upstream code doesn't calle evict_everything directly
from evict_something, that's an extension in this product branch. But
we can still hit upon this bug (and apparently we do, see the linked
backtraces). I've noticed this while trying to construct a testcase
for this bug and utterly failed to provoke it. It looks like we need
to driver the system squarly into the lowmem wall and provoke the
shrinker to evict the context object by doing the last-ditch
evict_everything call.
Aside: There's currently no means to get a badly-fragmenting hw
context object away from a bad spot in the upstream code. We should
fix this by at least adding some code to evict_something to handle hw
contexts.
References: https://code.google.com/p/chromium/issues/detail?id=248191
Reported-by: Ian Lister <ian.lister@intel.com>
Cc: Ian Lister <ian.lister@intel.com>
Cc: stable@vger.kernel.org
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Bloomfield, Jon <jon.bloomfield@intel.com>
Tested-by: Rafael Barbalho <rafael.barbalho@intel.com>
Reviewed-by: Ian Lister <ian.lister@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Shovel a bit more of the the code into the setup function, and call
it earlier. Otherwise lockdep is unhappy since we cancel the delayed
resume work before it's initialized.
While at it also shovel the pc8 setup code into the same functions.
I wanted to also ditch the header declaration of the hws pc8 functions,
but for unfathomable reasons that stuff is in intel_display.c instead
of intel_pm.c.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71980
Tested-by: Guo Jinxian <jinxianx.guo@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some additional fixes for 3.13. Regression fixes for audio and hw_i2c,
vram fix for some SI PX cards, race fix in the hwmon code, and a few other
odds and ends.
* 'drm-fixes-3.13' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon/atom: fix bus probes when hw_i2c is set (v2)
drm/radeon: fix null pointer dereference in dce6+ audio code
drm/radeon: fixup bad vram size on SI
drm/radeon: fix VGT_GS_INSTANCE_CNT register
drm/radeon: Fix a typo in Cayman and Evergreen registers
drm/radeon/dpm: simplify state adjust logic for NI
drm/radeon: add radeon_vm_bo_update trace point
drm/radeon: add VMID allocation trace point
drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups
drm/radeon: program DCE2 audio dto just like DCE3
drm/radeon: fix typo in fetching mpll params
Ensure the side-by-side (half) flag is added to any existing flags when
adding modes from 3D_Structure_ALL.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some boards seem to have garbage in the upper
16 bits of the vram size register. Check for
this and clamp the size properly. Fixes
boards reporting bogus amounts of vram.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Just flushing out my pile of bugfixes, most of them for regressions/cc:
stable. Nothing really serious going on.
For outstanding issues we still have the S4 fun due to the hsw S4
duct-tape pending (seems like I need to switch into angry maintainer mode
on that one). And there's the mode merging revert to make my g33 work
again still pending for drm core. For that one I don't have any more clue
(and it looks like no one else has a good idea either). And apparently the
locking WARN fix in here also needs to be replicated for boot, still
confirming that one though.
* tag 'drm-intel-fixes-2013-12-02' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Pin pages whilst allocating for dma-buf vmap()
drm/i915: MI_PREDICATE_RESULT_2 is HSW only
drm/i915: Make the DERRMR SRM target global GTT
drm/i915: use the correct force_wake function at the PC8 code
drm/i915: Fix pipe CSC post offset calculation
drm/i915: Simplify DP vs. eDP detection
drm/i915: Check VBT for eDP ports on VLV
drm/i915: use crtc_htotal in watermark calculations to match fastboot v2
drm/i915: Pin relocations for the duration of constructing the execbuffer
drm/i915: take mode config lock around crtc disable at suspend
drm/i915: Prefer setting PTE cache age to 3
drm/i915/ddi: set sink to power down mode on dp disable
This assortment of patches fix a few build and sparse warnings and make
sure to always return -EFAULT on copy_from_user() failures. Finally the
upcasting from struct drm_crtc to struct tegra_dc is made safer to
prevent potential segmentation faults.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJSnaLrAAoJEN0jrNd/PrOhm+YP/jXPCBWuyMzbw6Sld0U9gs7c
xjxBuH7CwU5CCEA1OzBoQOf5ANrlbZ7rnbNoJzqPktss1TWADhBs8Yvn/SsOClwe
L+5yiVZ21pKXPOXpX2e4NlIrNqyq+USb+Ve3SfhNoWIcZyIjKosy66sQJBijo5ap
Kz+EpFcGjYePt3zhyIR4JOEtfjJd0gk2e72MBPFUtnteS9ecNt+ZGZaTse27xVn3
ogyvef7Vp2r097OO5QS9PnohPQffJMmU36dzfzzKIcvn7vg+3xuO7sZdzdEvErHh
eNXXJoFIpUA1xbrmrNLl0HcnCkwun+nrpEd29ceszqd0Pspz6TUdTj6Og5vjbCrZ
LhVBZQydTpQQoMmI9l12GmePvEhjgWDc68bRCjhuIlRa84+nXWglJ29cgrvEdBJA
/V1dRE1WAL+TkBK83LcjiwihrM/KKqILjgl8ta6D6Jyi0JGEjUQBY2JEYedt2/T6
y9nhZ8pwI/rbROS71AXWgMjHoKhS/D939jwCMo+3bLjn2Vi4QyyDJeahbVsiGNze
kUCcKVvWh3eJNSZYEnpWPNFQaFDxZhFPtr+kPCG9AB1w3yji/dluEOe8r/pUvHnn
KK87Jfcu8UaiusILW/k6h9skZAPbC/t8I9S50JgSeO1jDVMN8lqlv1IP32cGFVXm
j9ZbTEyeJN8VFVMs5r2E
=Du68
-----END PGP SIGNATURE-----
Merge tag 'drm/for-3.13-rc3' of git://anongit.freedesktop.org/tegra/linux into drm-fixes
drm/tegra: Fixes for v3.13-rc3
This assortment of patches fix a few build and sparse warnings and make
sure to always return -EFAULT on copy_from_user() failures. Finally the
upcasting from struct drm_crtc to struct tegra_dc is made safer to
prevent potential segmentation faults.
* tag 'drm/for-3.13-rc3' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: return -EFAULT if copy_from_user() fails
gpu: host1x: Fix a few sparse warnings
drm/tegra: Force cast to __iomem to make sparse happy
drm/tegra: Make tegra_drm_driver static
drm/tegra: Fix address space mismatches
drm/tegra: Tightly bind RGB output to DC
drm/tegra: Make CRTC upcasting safer
gpu: host1x: Silence a few warnings with LPAE=y
5dc9e1e8 was a bit over-ambitious, and accidentially removed handling
for imported prime buffers.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix some pageflip, oopses and some better clock support for some chipsets
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nv50/disp: min/max are reversed in nv50_crtc_gamma_set()
drm/nouveau/sw: fix oops if gpu has its display block disabled
drm/nouveau: unreference fence after syncing
drm/nouveau/kms: send timestamp data for correct head in flip completion events
drm/nouveau/clk: Add support for NVAA/NVAC
drm/nouveau/fifo: Hook up pause and resume for NV50 and NV84+
drm/nv10/plane: some chipsets don't support NV12
drm/nv10/plane: add downscaling restrictions
drm/nv10/plane: fix format computation
drm/nv04-nv30/clk: provide an empty domain list
Some user-space apps expects to find them there.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Also request kernel ttm_buffer objects for buffer objects that obviously
aren't visible to user-space, and save some device address space.
The accounting was broken in a couple of ways:
1) We did not differentiate between user dma buffers and kernel dma buffers.
2) The ttm_bo_acc_size function is broken in that it
a) Doesn't take into account the size of the optional dma address array,
b) Doesn't take into account the fact that drivers typically embed the
ttm_tt structure.
This needs to be fixed in ttm, but meanwhile provide a vmwgfx-specific
function to do the job.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Allocation was duplicating code. Comments were missing.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Failure to do this would make the drm_mode_get_crtc ioctl return
without crtc mode info, indicating that no mode was set.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Inorder to serialise the closing of the file descriptor and its
subsequent release of client requests with i915_gem_free_request(), we
need to hold the struct_mutex in i915_gem_release(). Failing to do so
has the potential to trigger an OOPS, later with a use-after-free.
Testcase: igt/gem_close_race
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70874
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71029
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't have clock state readout support for DDI, so skip the pipe
config clock checks on all DDI platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We call intel_modeset_setup_hw_state() along two paths, driver
load/resume and after a lid event notification. During initialisation of
the driver, it is imperative that we reset the config state. This
correctly sets up the initial connector statuses and prepares the
hardware for a thorough probing. However, during a lid event, we only
want to undo the damage caused by the bios by resetting our last known
mode. In this cirumstance, we do not want to clobber our desired state.
In order to try and keep sanity between the config state and our own
tracking, do the drm_mode_config_reset() first along the load/resume
paths before reading out the hw state and apply any definite known
corrections.
v2: "As discussed on irc I don't think we should force the connector
state to anything here: Imo connector->status should reflect what we
believe to be the true output connection state, whereas connector->encoder
reflects whether this connector is wired up to a pipe. And since we no
longer reject modeset on disconnected connectors and never nuked the pipe
if the connector gets disconnected there's no reason for that - such policy
is userspace's job.
This regression has been introduced in
commit 2e9388923e83bc4e2726f170a984621f1d582e77
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Oct 11 20:08:24 2012 +0200
drm/i915/crt: explicitly set up HOTPLUG_BITS on resume"
so sayeth Daniel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org (v3.8 and later)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some lower level things get angry if we don't have modeset locks
during intel_modeset_setup_hw_state(). Actually the resume and
lid_notify codepaths alreday hold the locks, but the init codepath
doesn't, so fix that.
Note: This slipped through since we only disable pipes if the
plane/pipe linking doesn't match. Which is only relevant on older
gen3 mobile machines, if the BIOS fails to set up our preferred
linking.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Tested-and-reported-by: Paul Bolle <pebolle@tiscali.nl>
[danvet: Add note now that I could confirm my theory with the log
files Paul Bolle provided.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We should be taking the minimum here instead of the max. It could lead
to a buffer overflow.
Fixes: 438d99e3b175 ('drm/nvd0/disp: initial crtc object implementation')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
a/drm/nv50_display.c b/drm/nv50_display.c
index f8e66c08b11a..4e384a2f99c3 100644
Otherwise none of the format checks pass, since the width was still in
16.16 encoding.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
copy_from_user() returns the number of bytes remaining if it fails, but
we want to return -EFAULT here.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The fbdev screen memory pointer is annotated __iomem, so cast the kernel
virtual address to that address space to make the warning go away.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Previously the association to a DC was done via the encoder's .crtc
field. That has the disadvantage that when an encoder is detached from
its CRTC, that field is set to NULL, leading to situations where it is
impossible to access the DC registers required by the RGB output.
However, the coupling between DC and RGB output is really fixed on
Tegra. While they can be detached logically in DRM, the RGB output can
rely on the DC's existence.
Signed-off-by: Thierry Reding <treding@nvidia.com>
When upcasting a NULL CRTC object, propagate the NULL pointer instead of
some invalid pointer. This allows subsequent code to check that the cast
object is valid.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This register was incorrect for evergreen and cayman.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
