Re: [PATCH v3] lib: cpu_rmap: avoid flushing all workqueues

From: Ben Hutchings
Date: Wed Jan 02 2013 - 15:29:12 EST


On Sat, 2012-12-29 at 12:36 -0800, Josh Triplett wrote:
> On Sat, Dec 29, 2012 at 11:57:09AM -0800, David Decotigny wrote:
> > In some cases, free_irq_cpu_rmap() is called while holding a lock
> > (eg. rtnl). This can lead to deadlocks, because it invokes
> > flush_scheduled_work() which ends up waiting for whole system
> > workqueue to flush, but some pending works might try to acquire the
> > lock we are already holding.
> >
> > This commit uses reference-counting to replace
> > irq_run_affinity_notifiers(). It also removes
> > irq_run_affinity_notifiers() altogether.
> >
> > Signed-off-by: David Decotigny <decot@xxxxxxxxxxxx>
>
> You might consider adding a cpu_rmap_get to parallel cpu_rmap_put.
>
> Also, why keep free_cpu_rmap around at this point? As far as I can
> tell, it has no callers.
>
> Otherwise, this looks good to me.

I intended to make cpu_rmap usable independently of IRQ notification,
although as you note there have been no other users so far.
free_cpu_rmap() is now effectively an alias for cpu_rmap_put(), and the
latter *does* have a caller. So perhaps cpu_rmap_put() should be extern
and the alias dropped.

Ben.

--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/