Re: [Intel-gfx] [PATCH] drm/i915: Don't deref request->ctx inside unlocked print_request()

Quoting Mika Kuoppala (2018-02-28 12:49:00) > Chris Wilson writes: > > > Although we protect the request itself, we don't lock inside > > intel_engine_dump() and so the request maybe retired as we peek into it. > > One consequence is that the request->ctx may be freed

Re: [Intel-gfx] [PATCH] drm/i915: Don't deref request->ctx inside unlocked print_request()

Chris Wilson writes: > Although we protect the request itself, we don't lock inside > intel_engine_dump() and so the request maybe retired as we peek into it. > One consequence is that the request->ctx may be freed before we > dereference it, leading to a

Re: [Intel-gfx] [PATCH] drm/i915: Don't deref request->ctx inside unlocked print_request()

Quoting Mika Kuoppala (2018-02-28 12:32:40) > Chris Wilson writes: > > > Although we protect the request itself, we don't lock inside > > intel_engine_dump() and so the request maybe retired as we peek into it. > > One consequence is that the request->ctx may be freed

Re: [Intel-gfx] [PATCH] drm/i915: Don't deref request->ctx inside unlocked print_request()

Chris Wilson writes: > Although we protect the request itself, we don't lock inside > intel_engine_dump() and so the request maybe retired as we peek into it. > One consequence is that the request->ctx may be freed before we > dereference it, leading to a

[Intel-gfx] [PATCH] drm/i915: Don't deref request->ctx inside unlocked print_request()

Although we protect the request itself, we don't lock inside intel_engine_dump() and so the request maybe retired as we peek into it. One consequence is that the request->ctx may be freed before we dereference it, leading to a use-after-free. Replace the hw_id we are peeking from inside