Messages in this thread | | | Date | Fri, 5 Jun 2020 17:02:08 +0200 | From | Frederic Weisbecker <> | 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.
| |