From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750878AbdIEKXm (ORCPT ); Tue, 5 Sep 2017 06:23:42 -0400 Received: from mx2.suse.de ([195.135.220.15]:59001 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750729AbdIEKXj (ORCPT ); Tue, 5 Sep 2017 06:23:39 -0400 Date: Tue, 5 Sep 2017 12:23:36 +0200 From: Michal Hocko To: Thomas Gleixner Cc: Johannes Weiner , Artem Savkov , "Paul E. McKenney" , LKML , linux-mm@kvack.org Subject: Re: possible circular locking dependency mmap_sem/cpu_hotplug_lock.rw_sem Message-ID: <20170905102336.bqxb7tltnt3lphkq@dhcp22.suse.cz> References: <20170807140947.nhfz2gel6wytl6ia@shodan.usersys.redhat.com> <20170830141543.qhipikpog6mkqe5b@dhcp22.suse.cz> <20170830154315.sa57wasw64rvnuhe@dhcp22.suse.cz> <20170904140353.k5mo3f4wela5nxqe@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 05-09-17 10:19:13, Thomas Gleixner wrote: > On Mon, 4 Sep 2017, Michal Hocko wrote: > > > Thomas, Johannes, > > could you double check my thinking here? I will repost the patch to > > Andrew if you are OK with this. > > > + /* > > > + * The only protection from memory hotplug vs. drain_stock races is > > > + * that we always operate on local CPU stock here with IRQ disabled > > > + */ > > > local_irq_save(flags); > > > > > > stock = this_cpu_ptr(&memcg_stock); > > > @@ -1807,26 +1811,27 @@ static void drain_all_stock(struct mem_cgroup *root_memcg) > > > if (!mutex_trylock(&percpu_charge_mutex)) > > > return; > > > /* Notify other cpus that system-wide "drain" is running */ > > > - get_online_cpus(); > > > curcpu = get_cpu(); > > The problem here is that this does only protect you against a CPU being > unplugged, but not against a CPU coming online concurrently. Yes but same as the drain_all_pages we do not have any cpu up specific intialization so there is no specific action to race against AFAICS. > I have no idea > whether that might be a problem, but at least you should put a comment in > which explains why it is not. What about this? --- diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 5c70f47abb3d..ff9b0979ccc3 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1810,7 +1810,12 @@ static void drain_all_stock(struct mem_cgroup *root_memcg) /* If someone's already draining, avoid adding running more workers. */ if (!mutex_trylock(&percpu_charge_mutex)) return; - /* Notify other cpus that system-wide "drain" is running */ + /* + * Notify other cpus that system-wide "drain" is running + * We do not care about races with the cpu hotplug because cpu down + * as well as workers from this path always operate on the local + * per-cpu data. CPU up doesn't touch memcg_stock at all. + */ curcpu = get_cpu(); for_each_online_cpu(cpu) { struct memcg_stock_pcp *stock = &per_cpu(memcg_stock, cpu); -- Michal Hocko SUSE Labs