Messages in this thread |  | | Date | Tue, 6 Sep 2011 06:57:50 -0400 | | From | Mathieu Desnoyers <> | | Subject | Re: [PATCH -mm 4/4] irq_work, Use llist in irq_work |
| |
* Huang Ying (ying.huang@intel.com) wrote: > Use llist in irq_work instead of the lock-less linked list > implementation in irq_work to avoid the code duplication. > > Signed-off-by: Huang Ying <ying.huang@intel.com> > Cc: Peter Zijlstra <peterz@infradead.org> > --- > include/linux/irq_work.h | 15 ++++--- > kernel/irq_work.c | 92 ++++++++++++++++------------------------------- > 2 files changed, 41 insertions(+), 66 deletions(-) > [...] > -static void __irq_work_queue(struct irq_work *entry) > +static void __irq_work_queue(struct irq_work *work) > { > - struct irq_work *next; > - > preempt_disable(); > > - do { > - next = __this_cpu_read(irq_work_list); > - /* Can assign non-atomic because we keep the flags set. */ > - entry->next = next_flags(next, IRQ_WORK_FLAGS); > - } while (this_cpu_cmpxchg(irq_work_list, next, entry) != next); > - > + llist_add(&work->llnode, &__get_cpu_var(irq_work_list)); > /* The list was empty, raise self-interrupt to start processing. */ > - if (!irq_work_next(entry)) > + if (!work->llnode.next)
Hrm. What happens if this function gets delayed between llist_add and "if (!work->llnode.next)" ? It seems like the threads performing llist_del_all would be within its right to free the memory pointed to by work in the meantime.
Thanks,
Mathieu
-- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
|  |