On Tue, Aug 17, 2021 at 11:39:29AM +0200, Daniel Vetter wrote:
On Mon, Aug 16, 2021 at 06:51:19AM -0700, Matthew Brost wrote:
A small race that could result in incorrect accounting of the number of outstanding G2H. Basically prior to this patch we did not increment the number of outstanding G2H if we encoutered a GT reset while sending a H2G. This was incorrect as the context state had already been updated to anticipate a G2H response thus the counter should be incremented.
Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in buffer") Signed-off-by: Matthew Brost matthew.brost@intel.com Cc: stable@vger.kernel.org
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index 69faa39da178..b5d3972ae164 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -360,11 +360,13 @@ static int guc_submission_send_busy_loop(struct intel_guc *guc, { int err;
- err = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
- if (!err && g2h_len_dw)
if (g2h_len_dw) atomic_inc(&guc->outstanding_submission_g2h);
err = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
I'm majorly confused by the _busy_loop naming scheme, especially here. Like "why do we want to send a busy loop comand to guc, this doesn't make sense".
It seems like you're using _busy_loop as a suffix for "this is ok to be called in atomic context". The linux kernel bikeshed for this is generally _atomic() (or _in_atomic() or something like that). Would be good to rename to make this slightly less confusing.
I'd like to save the bikeshedding for follow ups if we can as we should get the functional fixes in to stablize the stack + clean up the locking to a somewhat sane state ASAP. Everyone has their favorite color of paint...
-Daniel
- if (err == -EBUSY && g2h_len_dw)
atomic_dec(&guc->outstanding_submission_g2h);
Also here is an example of why this really should be owned by the submission code, it wants to increment this here even if the send failed due to -ENODEV (GT reset in flight) as this is an internal counter of how many G2H will need to be scrubbed.
Matt
return err; }
-- 2.32.0
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch