Re: mm: deadlock between get_online_cpus/pcpu_alloc
From: Michal Hocko
Date: Tue Feb 07 2017 - 08:48:29 EST
On Tue 07-02-17 13:03:50, Mel Gorman wrote:
> On Tue, Feb 07, 2017 at 12:43:27PM +0100, Michal Hocko wrote:
> > > Right. The unbind operation can set a mask that is any allowable CPU and
> > > the final process_work is not done in a context that prevents
> > > preemption.
> > >
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index 3b93879990fd..7af165d308c4 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -2342,7 +2342,14 @@ void drain_local_pages(struct zone *zone)
> > >
> > > static void drain_local_pages_wq(struct work_struct *work)
> > > {
> > > + /*
> > > + * Ordinarily a drain operation is bound to a CPU but may be unbound
> > > + * after a CPU hotplug operation so it's necessary to disable
> > > + * preemption for the drain to stabilise the CPU ID.
> > > + */
> > > + preempt_disable();
> > > drain_local_pages(NULL);
> > > + preempt_enable_no_resched();
> > > }
> > >
> > > /*
> > [...]
> > > @@ -6711,7 +6714,16 @@ static int page_alloc_cpu_dead(unsigned int cpu)
> > > {
> > >
> > > lru_add_drain_cpu(cpu);
> > > +
> > > + /*
> > > + * A per-cpu drain via a workqueue from drain_all_pages can be
> > > + * rescheduled onto an unrelated CPU. That allows the hotplug
> > > + * operation and the drain to potentially race on the same
> > > + * CPU. Serialise hotplug versus drain using pcpu_drain_mutex
> > > + */
> > > + mutex_lock(&pcpu_drain_mutex);
> > > drain_pages(cpu);
> > > + mutex_unlock(&pcpu_drain_mutex);
> >
> > You cannot put sleepable lock inside the preempt disbaled section...
> > We can make it a spinlock right?
> >
>
> The CPU down callback can hold a mutex and at least he SLUB callback
> already does so. That gives
>
> page_alloc_cpu_dead
> mutex_lock
> drain_pages
> mutex_unlock
>
> drain_all_pages
> mutex_lock
> queue workqueue
> drain_local_pages_wq
> preempt_disable
> drain_local_pages
> drain_pages
> preempt_enable
> flush queues
> mutex_unlock
>
> I must be blind or maybe it's rushing between multiple concerns but which
> sleepable lock is of concern?
I thought the cpu hotplug callback was non-preemptible. This is not the
case as mentioned in other reply. The pcpu_drain_mutex in the hotplug
callback is alright. Sorry about the confusion! I am still wondering
whether the lock is really needed. See the other reply.
--
Michal Hocko
SUSE Labs