I rushed a last minute correction to cancel_port_requests() to prevent
the snooping of *execlists->active as the inflight array was being
updated, without noticing we iterated the inflight array starting from
active! Oops.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112387
Fixes: 331bf9059157 ("drm/i915/gt: Mark the execlists->active as the primary volatile access")
Signed-off-by: Chris Wilson <email address hidden>
Cc: Mika Kuoppala <email address hidden>
Reviewed-by: Tvrtko Ursulin <email address hidden>
Reviewed-by: Andi Shyti <email address hidden>
Link: https://patchwork<email address hidden>
(cherry picked from commit da0ef77e1e0ccff703efee82406c629d5c4f4bbb)
Signed-off-by: Sultan Alsawaf <email address hidden>
Since we want to do a lockless read of the current active request, and
that request is written to by process_csb also without serialisation, we
need to instruct gcc to take care in reading the pointer itself.
Otherwise, we have observed execlists_active() to report 0x40.
The answer is that as we keep the existing execlists->active pointing
into the array as we copy over that array, the unserialised read may see
a partial pointer value.
Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock")
Signed-off-by: Chris Wilson <email address hidden>
Reviewed-by: Mika Kuoppala <email address hidden>
Link: https://patchwork<email address hidden>
(backported from commit 331bf90591573dfe6c8e892239713ef9702f1396)
[Sultan: enable_timeslice() needs to use the old request pointer]
Signed-off-by: Sultan Alsawaf <email address hidden>
Icelake hit an issue where it missed reporting a completion event and
instead jumped straight to a idle->active event (skipping over the
active->idle and not even hitting the lite-restore preemption).
With inotify, when a watch is set on a directory and on its child, an
event on the child is reported twice, once with wd of the parent watch
and once with wd of the child watch without the filename.
With fanotify, when a watch is set on a directory and on its child, an
event on the child is reported twice, but it has the exact same
information - either an open file descriptor of the child or an encoded
fid of the child.
The reason that the two identical events are not merged is because the
object id used for merging events in the queue is the child inode in one
event and parent inode in the other.
For events with path or dentry data, use the victim inode instead of the
watched inode as the object id for event merging, so that the event
reported on parent will be merged with the event reported on the child.
Link: https://<email address hidden>
Signed-off-by: Amir Goldstein <email address hidden>
Signed-off-by: Jan Kara <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
