Re: [RFC][PATCH 1/9] irq_work: Cleanup

[Peter Zijlstra <peterz@infradead.org>]

On Sat, Jul 25, 2020 at 01:58:28PM +0200, Ingo Molnar wrote:
> 
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > Get rid of the __call_single_node union and clean up the API a little
> > to avoid external code relying on the structure layout as much.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> >  drivers/gpu/drm/i915/i915_request.c |    4 ++--
> >  include/linux/irq_work.h            |   33 +++++++++++++++++++++------------
> >  include/linux/irqflags.h            |    4 ++--
> >  kernel/bpf/stackmap.c               |    2 +-
> >  kernel/irq_work.c                   |   18 +++++++++---------
> >  kernel/printk/printk.c              |    6 ++----
> >  kernel/rcu/tree.c                   |    3 +--
> >  kernel/time/tick-sched.c            |    6 ++----
> >  kernel/trace/bpf_trace.c            |    2 +-
> >  9 files changed, 41 insertions(+), 37 deletions(-)
> > 
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -196,7 +196,7 @@ __notify_execute_cb(struct i915_request
> >  
> >  	llist_for_each_entry_safe(cb, cn,
> >  				  llist_del_all(&rq->execute_cb),
> > -				  work.llnode)
> > +				  work.node.llist)
> >  		fn(&cb->work);
> >  }
> >  
> > @@ -478,7 +478,7 @@ __await_execution(struct i915_request *r
> >  	 * callback first, then checking the ACTIVE bit, we serialise with
> >  	 * the completed/retired request.
> >  	 */
> > -	if (llist_add(&cb->work.llnode, &signal->execute_cb)) {
> > +	if (llist_add(&cb->work.node.llist, &signal->execute_cb)) {
> >  		if (i915_request_is_active(signal) ||
> >  		    __request_in_flight(signal))
> >  			__notify_execute_cb_imm(signal);
> 
> Hm, so I was looking at picking up some of the low risk bits (patches #1, #2, #4)
> from this series for v5.9, but the above hunk depends non-trivially on the
> linux-next DRM tree, in particular:
> 
>   1d9221e9d395: ("drm/i915: Skip signaling a signaled request")
>   3255e00edb91: ("drm/i915: Remove i915_request.lock requirement for execution callbacks")
>   etc.
> 
> We could add it sans the i915 bits, but then we'd introduce a semantic 
> conflict in linux-next which isn't nice so close to the merge window.
> 
> One solution would be to delay this into the merge window to after the 
> DRM tree gets merged by Linus. Another would be to help out Stephen 
> with the linux-next merge.
> 
> What would be your preference?

The alternative is splitting the above change out into it's own patch
and see if Chris is willing to carry that in the DRM tree. IIRC these
'new' names should already work with the current code.

They're different names for the same field in that giant union thing.