Re: [Intel-gfx] [PATCH] drm/i915: Prevent negative relocation deltas from wrapping

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 15, 2014 at 02:46:32PM +0200, Daniel Vetter wrote:
> On Thu, May 15, 2014 at 01:17:12PM +0100, Chris Wilson wrote:
> > This is pure evil. Userspace, I'm looking at you SNA, repacks batch
> > buffers on the fly after generation as they are being passed to the
> > kernel for execution. These batches also contain self-referenced
> > relocations as a single buffer encompasses the state commands, kernels,
> > vertices and sampler. During generation the buffers are placed at known
> > offsets within the full batch, and then the relocation deltas (as passed
> > to the kernel) are tweaked as the batch is repacked into a smaller buffer.
> > This means that userspace is passing negative relocations deltas, which
> > subsequently wrap to large values if the batch is at a low address. The
> > GPU hangs when it then tries to use the large value as a base for its
> > address offsets, rather than wrapping back to the real value (as one
> > would hope). As the GPU uses positive offsets from the base, we can
> > treat the relocation address as the minimum address read by the GPU.
> > For the upper bound, we trust that userspace will not read beyond the
> > end of the buffer.
> > 
> > This fixes a GPU hang when it tries to use an address (relocation +
> > offset) greater than the GTT size. The issue would occur quite easily
> > with full-ppgtt as each fd gets its own VM space, so low offsets would
> > often be handed out. However, with the rearrangement of the low GTT due
> > to capturing the BIOS framebuffer, it is already affecting kernels 3.14
> > onwards. I think only IVB+ is susceptible to this bug, but the workaround
> > should only kick in rarely, so it seems sensible to always apply it.
> > 
> > v2: Apply the workaround for LUT-based execbuffers as well and only for
> > IVB+ as my SNB machine seems to be unaffected.
> > 
> > Testcase: igt/gem_bad_reloc
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx
> 
> Do we need to fix this in the kernel? Userspace supplying relocs that
> kinda don't work smells fishy ...

What?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]