[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200605150207.GA9599@lenoir>
Date: Fri, 5 Jun 2020 17:02:08 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: tglx@...utronix.de, linux-kernel@...r.kernel.org, x86@...nel.org,
cai@....pw, mgorman@...hsingularity.net, sfr@...b.auug.org.au,
linux@...ck-us.net
Subject: Re: [RFC][PATCH 5/7] irq_work, smp: Allow irq_work on
call_single_queue
On Fri, Jun 05, 2020 at 11:37:04AM +0200, Peter Zijlstra wrote:
> On Fri, May 29, 2020 at 03:36:41PM +0200, Peter Zijlstra wrote:
> > Maybe I can anonymous-union my way around it, dunno. I'll think about
> > it. I'm certainly not proud of this. But at least the BUILD_BUG_ON()s
> > should catch the more blatant breakage here.
>
> How's this then? Differently ugly, but at least it compiles with that
> horrible struct randomization junk enabled.
>
> ---
> include/linux/irq_work.h | 28 ++++++-------------
> include/linux/sched.h | 4 +-
> include/linux/smp.h | 25 ++++++-----------
> include/linux/smp_types.h | 66 ++++++++++++++++++++++++++++++++++++++++++++++
> kernel/sched/core.c | 6 ++--
> kernel/smp.c | 18 ------------
> 6 files changed, 89 insertions(+), 58 deletions(-)
>
> --- a/include/linux/irq_work.h
> +++ b/include/linux/irq_work.h
> @@ -2,7 +2,7 @@
> #ifndef _LINUX_IRQ_WORK_H
> #define _LINUX_IRQ_WORK_H
>
> -#include <linux/llist.h>
> +#include <linux/smp_types.h>
>
> /*
> * An entry can be in one of four states:
> @@ -13,26 +13,16 @@
> * busy NULL, 2 -> {free, claimed} : callback in progress, can be claimed
> */
>
> -/* flags share CSD_FLAG_ space */
> -
> -#define IRQ_WORK_PENDING BIT(0)
> -#define IRQ_WORK_BUSY BIT(1)
> -
> -/* Doesn't want IPI, wait for tick: */
> -#define IRQ_WORK_LAZY BIT(2)
> -/* Run hard IRQ context, even on RT */
> -#define IRQ_WORK_HARD_IRQ BIT(3)
> -
> -#define IRQ_WORK_CLAIMED (IRQ_WORK_PENDING | IRQ_WORK_BUSY)
> -
> -/*
> - * structure shares layout with single_call_data_t.
> - */
> struct irq_work {
> - struct llist_node llnode;
> - atomic_t flags;
> + union {
> + struct __call_single_node node;
> + struct {
> + struct llist_node llnode;
> + atomic_t flags;
> + };
> + };
So why not just embed struct __call_single_node in
struct irq_work and struct __call_single_data ?
Is the point of that anonymous second union layer to
shorten the lines while accessing members?
Thanks.
Powered by blists - more mailing lists