linux-kernel - Re: [RFC][PATCH 1/9] irq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200725115828.GA1006124@gmail.com>
Date:   Sat, 25 Jul 2020 13:58:28 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        will@...nel.org, paulmck@...nel.org, hch@....de, axboe@...nel.dk,
        chris@...is-wilson.co.uk, davem@...emloft.net, kuba@...nel.org,
        fweisbec@...il.com, oleg@...hat.com
Subject: Re: [RFC][PATCH 1/9] irq_work: Cleanup


* Peter Zijlstra <peterz@...radead.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@...radead.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?

Thanks,

	Ingo