From: Michal Hocko <mhocko@kernel.org> To: Mel Gorman <mgorman@techsingularity.net> Cc: Vlastimil Babka <vbabka@suse.cz>, Dmitry Vyukov <dvyukov@google.com>, Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>, Peter Zijlstra <peterz@infradead.org>, syzkaller <syzkaller@googlegroups.com>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: mm: deadlock between get_online_cpus/pcpu_alloc Date: Tue, 7 Feb 2017 17:41:30 +0100 [thread overview] Message-ID: <20170207164130.GY5065@dhcp22.suse.cz> (raw) In-Reply-To: <20170207162224.elnrlgibjegswsgn@techsingularity.net> On Tue 07-02-17 16:22:24, Mel Gorman wrote: > On Tue, Feb 07, 2017 at 04:34:59PM +0100, Michal Hocko wrote: > > > But we do not care about the whole cpu hotplug code. The only part we > > > really do care about is the race inside drain_pages_zone and that will > > > run in an atomic context on the specific CPU. > > > > > > You are absolutely right that using the mutex is safe as well but the > > > hotplug path is already littered with locks and adding one more to the > > > picture doesn't sound great to me. So I would really like to not use a > > > lock if that is possible and safe (with a big fat comment of course). > > > > And with the full changelog. I hope I haven't missed anything this time. > > --- > > From 8c6af3116520251cc4ec2213f0a4ed2544bb4365 Mon Sep 17 00:00:00 2001 > > From: Michal Hocko <mhocko@suse.com> > > Date: Tue, 7 Feb 2017 16:08:35 +0100 > > Subject: [PATCH] mm, page_alloc: do not depend on cpu hotplug locks inside the > > allocator > > > > <SNIP> > > > > Reported-by: Dmitry Vyukov <dvyukov@google.com> > > Signed-off-by: Michal Hocko <mhocko@suse.com> > > Not that I can think of. It's almost identical to the diff I posted with > the exception of the mutex in the cpu hotplug teardown path. I agree that > in the current implementation that it should be unnecessary even if I > thought it would be more robust against any other hotplug churn. I am always nervous when seeing hotplug locks being used in low level code. It has bitten us several times already and those deadlocks are quite hard to spot when reviewing the code and very rare to hit so they tend to live for a long time. > Acked-by: Mel Gorman <mgorman@techsingularity.net> Thanks! I will wait for Tejun to confirm my assumptions are correct and post the patch to Andrew if there are no further problems spotted. Btw. this will also get rid of another lockdep report which seem to be false possitive though http://lkml.kernel.org/r/20170203145548.GC19325@dhcp22.suse.cz -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Mel Gorman <mgorman@techsingularity.net> Cc: Vlastimil Babka <vbabka@suse.cz>, Dmitry Vyukov <dvyukov@google.com>, Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>, Peter Zijlstra <peterz@infradead.org>, syzkaller <syzkaller@googlegroups.com>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: mm: deadlock between get_online_cpus/pcpu_alloc Date: Tue, 7 Feb 2017 17:41:30 +0100 [thread overview] Message-ID: <20170207164130.GY5065@dhcp22.suse.cz> (raw) In-Reply-To: <20170207162224.elnrlgibjegswsgn@techsingularity.net> On Tue 07-02-17 16:22:24, Mel Gorman wrote: > On Tue, Feb 07, 2017 at 04:34:59PM +0100, Michal Hocko wrote: > > > But we do not care about the whole cpu hotplug code. The only part we > > > really do care about is the race inside drain_pages_zone and that will > > > run in an atomic context on the specific CPU. > > > > > > You are absolutely right that using the mutex is safe as well but the > > > hotplug path is already littered with locks and adding one more to the > > > picture doesn't sound great to me. So I would really like to not use a > > > lock if that is possible and safe (with a big fat comment of course). > > > > And with the full changelog. I hope I haven't missed anything this time. > > --- > > From 8c6af3116520251cc4ec2213f0a4ed2544bb4365 Mon Sep 17 00:00:00 2001 > > From: Michal Hocko <mhocko@suse.com> > > Date: Tue, 7 Feb 2017 16:08:35 +0100 > > Subject: [PATCH] mm, page_alloc: do not depend on cpu hotplug locks inside the > > allocator > > > > <SNIP> > > > > Reported-by: Dmitry Vyukov <dvyukov@google.com> > > Signed-off-by: Michal Hocko <mhocko@suse.com> > > Not that I can think of. It's almost identical to the diff I posted with > the exception of the mutex in the cpu hotplug teardown path. I agree that > in the current implementation that it should be unnecessary even if I > thought it would be more robust against any other hotplug churn. I am always nervous when seeing hotplug locks being used in low level code. It has bitten us several times already and those deadlocks are quite hard to spot when reviewing the code and very rare to hit so they tend to live for a long time. > Acked-by: Mel Gorman <mgorman@techsingularity.net> Thanks! I will wait for Tejun to confirm my assumptions are correct and post the patch to Andrew if there are no further problems spotted. Btw. this will also get rid of another lockdep report which seem to be false possitive though http://lkml.kernel.org/r/20170203145548.GC19325@dhcp22.suse.cz -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-02-07 16:41 UTC|newest] Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-01-29 12:44 mm: deadlock between get_online_cpus/pcpu_alloc Dmitry Vyukov 2017-01-29 12:44 ` Dmitry Vyukov 2017-01-29 17:22 ` Vlastimil Babka 2017-01-29 17:22 ` Vlastimil Babka 2017-01-30 15:48 ` Dmitry Vyukov 2017-01-30 15:48 ` Dmitry Vyukov 2017-02-06 19:13 ` Dmitry Vyukov 2017-02-06 19:13 ` Dmitry Vyukov 2017-02-06 22:05 ` Mel Gorman 2017-02-06 22:05 ` Mel Gorman 2017-02-07 8:48 ` Michal Hocko 2017-02-07 8:48 ` Michal Hocko 2017-02-07 9:23 ` Vlastimil Babka 2017-02-07 9:23 ` Vlastimil Babka 2017-02-07 9:46 ` Mel Gorman 2017-02-07 9:46 ` Mel Gorman 2017-02-07 9:53 ` Michal Hocko 2017-02-07 9:53 ` Michal Hocko 2017-02-07 10:42 ` Mel Gorman 2017-02-07 10:42 ` Mel Gorman 2017-02-07 11:13 ` Mel Gorman 2017-02-07 11:13 ` Mel Gorman 2017-02-07 9:43 ` Mel Gorman 2017-02-07 9:43 ` Mel Gorman 2017-02-07 9:49 ` Vlastimil Babka 2017-02-07 9:49 ` Vlastimil Babka 2017-02-07 10:05 ` Michal Hocko 2017-02-07 10:05 ` Michal Hocko 2017-02-07 10:28 ` Mel Gorman 2017-02-07 10:28 ` Mel Gorman 2017-02-07 10:35 ` Michal Hocko 2017-02-07 10:35 ` Michal Hocko 2017-02-07 11:34 ` Mel Gorman 2017-02-07 11:34 ` Mel Gorman 2017-02-07 11:43 ` Michal Hocko 2017-02-07 11:43 ` Michal Hocko 2017-02-07 11:54 ` Vlastimil Babka 2017-02-07 11:54 ` Vlastimil Babka 2017-02-07 12:08 ` Michal Hocko 2017-02-07 12:08 ` Michal Hocko 2017-02-07 12:37 ` Michal Hocko 2017-02-07 12:37 ` Michal Hocko 2017-02-07 12:43 ` Vlastimil Babka 2017-02-07 12:43 ` Vlastimil Babka 2017-02-07 12:48 ` Michal Hocko 2017-02-07 12:48 ` Michal Hocko 2017-02-07 13:57 ` Vlastimil Babka 2017-02-07 13:57 ` Vlastimil Babka 2017-02-07 13:58 ` Mel Gorman 2017-02-07 13:58 ` Mel Gorman 2017-02-07 14:19 ` Michal Hocko 2017-02-07 14:19 ` Michal Hocko 2017-02-07 15:34 ` Michal Hocko 2017-02-07 15:34 ` Michal Hocko 2017-02-07 16:22 ` Mel Gorman 2017-02-07 16:22 ` Mel Gorman 2017-02-07 16:41 ` Michal Hocko [this message] 2017-02-07 16:41 ` Michal Hocko 2017-02-07 16:55 ` Christoph Lameter 2017-02-07 16:55 ` Christoph Lameter 2017-02-07 22:25 ` Thomas Gleixner 2017-02-07 22:25 ` Thomas Gleixner 2017-02-08 7:35 ` Michal Hocko 2017-02-08 7:35 ` Michal Hocko 2017-02-08 12:02 ` Thomas Gleixner 2017-02-08 12:02 ` Thomas Gleixner 2017-02-08 12:21 ` Michal Hocko 2017-02-08 12:21 ` Michal Hocko 2017-02-08 12:26 ` Mel Gorman 2017-02-08 12:26 ` Mel Gorman 2017-02-08 13:23 ` Thomas Gleixner 2017-02-08 13:23 ` Thomas Gleixner 2017-02-08 14:03 ` Mel Gorman 2017-02-08 14:03 ` Mel Gorman 2017-02-08 14:11 ` Peter Zijlstra 2017-02-08 14:11 ` Peter Zijlstra 2017-02-08 15:11 ` Christoph Lameter 2017-02-08 15:11 ` Christoph Lameter 2017-02-08 15:21 ` Michal Hocko 2017-02-08 15:21 ` Michal Hocko 2017-02-08 16:17 ` Christoph Lameter 2017-02-08 16:17 ` Christoph Lameter 2017-02-08 17:46 ` Thomas Gleixner 2017-02-08 17:46 ` Thomas Gleixner 2017-02-09 3:15 ` Christoph Lameter 2017-02-09 3:15 ` Christoph Lameter 2017-02-09 11:42 ` Thomas Gleixner 2017-02-09 11:42 ` Thomas Gleixner 2017-02-09 14:00 ` Christoph Lameter 2017-02-09 14:00 ` Christoph Lameter 2017-02-09 14:53 ` Thomas Gleixner 2017-02-09 14:53 ` Thomas Gleixner 2017-02-09 15:42 ` Christoph Lameter 2017-02-09 15:42 ` Christoph Lameter 2017-02-09 16:12 ` Thomas Gleixner 2017-02-09 16:12 ` Thomas Gleixner 2017-02-09 17:22 ` Christoph Lameter 2017-02-09 17:22 ` Christoph Lameter 2017-02-09 17:40 ` Thomas Gleixner 2017-02-09 17:40 ` Thomas Gleixner 2017-02-09 19:15 ` Michal Hocko 2017-02-09 19:15 ` Michal Hocko 2017-02-10 17:58 ` Christoph Lameter 2017-02-10 17:58 ` Christoph Lameter 2017-02-08 15:06 ` Christoph Lameter 2017-02-08 15:06 ` Christoph Lameter 2017-02-07 17:03 ` Tejun Heo 2017-02-07 17:03 ` Tejun Heo 2017-02-07 20:16 ` Michal Hocko 2017-02-07 20:16 ` Michal Hocko 2017-02-07 13:03 ` Mel Gorman 2017-02-07 13:03 ` Mel Gorman 2017-02-07 13:48 ` Michal Hocko 2017-02-07 13:48 ` Michal Hocko 2017-02-07 11:24 ` Tetsuo Handa 2017-02-07 11:24 ` Tetsuo Handa 2017-02-07 8:43 ` Michal Hocko 2017-02-07 8:43 ` Michal Hocko 2017-02-07 21:53 ` Thomas Gleixner 2017-02-07 21:53 ` Thomas Gleixner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170207164130.GY5065@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=cl@linux.com \ --cc=dvyukov@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=mingo@kernel.org \ --cc=peterz@infradead.org \ --cc=syzkaller@googlegroups.com \ --cc=tglx@linutronix.de \ --cc=tj@kernel.org \ --cc=vbabka@suse.cz \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.