[Intel-gfx] [PATCH 1/5] drm/i915: Mark up unlocked update of i915_request.hwsp_seqno
Chris Wilson
chris at chris-wilson.co.uk
Mon Mar 9 14:10:25 UTC 2020
Quoting Mika Kuoppala (2020-03-09 14:03:01)
> Chris Wilson <chris at chris-wilson.co.uk> writes:
>
> > During i915_request_retire() we decouple the i915_request.hwsp_seqno
> > from the intel_timeline so that it may be freed before the request is
> > released. However, we need to warn the compiler that the pointer may
> > update under its nose.
> >
> > [ 171.438899] BUG: KCSAN: data-race in i915_request_await_dma_fence [i915] / i915_request_retire [i915]
> > [ 171.438920]
> > [ 171.438932] write to 0xffff8881e7e28ce0 of 8 bytes by task 148 on cpu 2:
> > [ 171.439174] i915_request_retire+0x1ea/0x660 [i915]
> > [ 171.439408] retire_requests+0x7a/0xd0 [i915]
> > [ 171.439640] engine_retire+0xa1/0xe0 [i915]
> > [ 171.439657] process_one_work+0x3b1/0x690
> > [ 171.439671] worker_thread+0x80/0x670
> > [ 171.439685] kthread+0x19a/0x1e0
> > [ 171.439701] ret_from_fork+0x1f/0x30
> > [ 171.439721]
> > [ 171.439739] read to 0xffff8881e7e28ce0 of 8 bytes by task 696 on cpu 1:
> > [ 171.439990] i915_request_await_dma_fence+0x162/0x520 [i915]
> > [ 171.440230] i915_request_await_object+0x2fe/0x470 [i915]
> > [ 171.440467] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
> > [ 171.440704] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> > [ 171.440722] drm_ioctl_kernel+0xe4/0x120
> > [ 171.440736] drm_ioctl+0x297/0x4c7
> > [ 171.440750] ksys_ioctl+0x89/0xb0
> > [ 171.440766] __x64_sys_ioctl+0x42/0x60
> > [ 171.440788] do_syscall_64+0x6e/0x2c0
> > [ 171.440802] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_request.h | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h
> > index d4bae16b4785..6020d5b2a3df 100644
> > --- a/drivers/gpu/drm/i915/i915_request.h
> > +++ b/drivers/gpu/drm/i915/i915_request.h
> > @@ -396,7 +396,9 @@ static inline bool i915_seqno_passed(u32 seq1, u32 seq2)
> >
> > static inline u32 __hwsp_seqno(const struct i915_request *rq)
> > {
> > - return READ_ONCE(*rq->hwsp_seqno);
> > + const u32 *hwsp = READ_ONCE(rq->hwsp_seqno);
> > +
> > + return READ_ONCE(*hwsp);
>
> This is good enough for decouple. But good enough for hardware
> might be different thing.
>
> I am paranoid enough to wanting an rmb(), before the final
> read once.
What? [That pointer is nothing to do with HW; it's a pointer to a
pointer to HW.]
> and clflush after.
No. We want to keep the cached read around. If you are paranoid, you
would put the clflush very carefully in the interrupt signalling.
> If the hardware can't guarantee coherency in csb, why
> would it in the different region in hwsp.
It's the order of the writes that's the problem in icl. There's no such
sequence here.
-Chris
More information about the Intel-gfx
mailing list