On Thu, 23 Jan 2020 at 08:51, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
>
> Using a clear page for scratch means that we have relatively benign
> errors in case it is accidentally used, but that can be rather too
> benign for debugging. If we poison the scratch, ideally it quickly
> results in an obvious error.
>
> Suggested-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
[snip]
>
> +static void poison_scratch_page(struct page *page, unsigned long size)
> +{
> + if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
> + return;
> +
> + kunmap_atomic(memset(kmap_atomic(page), POISON_FREE, size));
kmap works for !order-zero?
> +}
> +
> int setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
> {
> unsigned long size;
> @@ -331,6 +339,17 @@ int setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
> if (unlikely(!page))
> goto skip;
>
> + /*
> + * Use a non-zero scratch page for debugging.
> + *
> + * We want a value that should be reasonably obvious
> + * to spot in the error state, while also causing a GPU hang
> + * if executed. We prefer using a clear page in production, so
> + * should it ever be accidentally used, the effect should be
> + * fairly benign.
> + */
> + poison_scratch_page(page, size);
> +
> addr = dma_map_page_attrs(vm->dma,
> page, 0, size,
> PCI_DMA_BIDIRECTIONAL,
> --
> 2.25.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
