On Fri, 2012-12-28 at 13:14 -0800, Eric Dumazet wrote:
[...]
> > +/**
> > + * reclaim_cpu_rmap - internal reclaiming helper called from kref_put
> > + * @ref: kref to struct cpu_rmap
> > + */
> > +static void reclaim_cpu_rmap(struct kref *ref)
>
> Could be named cpu_rmap_free()
>
> (and alloc_cpu
On Fri, 2012-12-28 at 13:44 -0800, David Decotigny wrote:
> Thanks,
>
> Ok for the cpu_rmap_put helper. Will do this in v3 of this patch.
>
> Your comments suggest more refactoring, which might be better in the
> form of 1 or 2 additional patches that:
> - rename alloc_cpu_rmap & co according to
Thanks,
Ok for the cpu_rmap_put helper. Will do this in v3 of this patch.
Your comments suggest more refactoring, which might be better in the
form of 1 or 2 additional patches that:
- rename alloc_cpu_rmap & co according to new conventions (cpu_rmap_*)
- remove the cpu_rmap sub-API altogether,
On Fri, 2012-12-28 at 11:03 -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 mig
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 us
5 matches
Mail list logo
