All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qian Cai <cai@lca.pw>
To: Michal Hocko <mhocko@kernel.org>
Cc: David Hildenbrand <david@redhat.com>,
	linux-kernel@vger.kernel.org,  linux-mm@kvack.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Oscar Salvador <osalvador@suse.de>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v1] mm/memory_hotplug: Don't take the cpu_hotplug_lock
Date: Thu, 26 Sep 2019 09:02:26 -0400	[thread overview]
Message-ID: <1569502946.5576.237.camel@lca.pw> (raw)
In-Reply-To: <20190926115258.GH20255@dhcp22.suse.cz>

On Thu, 2019-09-26 at 13:52 +0200, Michal Hocko wrote:
> On Thu 26-09-19 07:19:27, Qian Cai wrote:
> > 
> > 
> > > On Sep 26, 2019, at 3:26 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > > 
> > > OK, this is using for_each_online_cpu but why is this a problem? Have
> > > you checked what the code actually does? Let's say that online_pages is
> > > racing with cpu hotplug. A new CPU appears/disappears from the online
> > > mask while we are iterating it, right? Let's start with cpu offlining
> > > case. We have two choices, either the cpu is still visible and we update
> > > its local node configuration even though it will disappear shortly which
> > > is ok because we are not touching any data that disappears (it's all
> > > per-cpu). Case when the cpu is no longer there is not really
> > > interesting. For the online case we might miss a cpu but that should be
> > > tolerateable because that is not any different from triggering the
> > > online independently of the memory hotplug. So there has to be a hook
> > > from that code path as well. If there is none then this is buggy
> > > irrespective of the locking.
> > > 
> > > Makes sense?
> > 
> > This sounds to me requires lots of audits and testing. Also, someone who is more
> > familiar with CPU hotplug should review this patch.
> 
> Thomas is on the CC list.
> 
> > Personally, I am no fun of
> > operating on an incorrect CPU mask to begin with, things could go wrong really
> > quickly...
> 
> Do you have any specific arguments? Just think of cpu and memory
> hotplugs being independent operations. There is nothing really
> inherently binding them together. If the cpu_online_mask really needs a
> special treatment here then I would like to hear about that. Handwaving 
> doesn't really helps us.

That is why I said it needs CPU hotplug experts to confirm that things including
if CPU masks are tolerate to this kind of "abuse", or in-depth analysis of each 
calls sites that access CPU masks in both online_pages() and offline_pages() as
well as ideally, more testing data in those areas.

However, many kernel commits were merged with the expectations that people are
going to deal with the aftermath, so I am not going to insist.


  reply	other threads:[~2019-09-26 13:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 14:36 [PATCH v1] mm/memory_hotplug: Don't take the cpu_hotplug_lock David Hildenbrand
2019-09-24 14:48 ` Michal Hocko
2019-09-24 15:01   ` David Hildenbrand
2019-09-24 15:03 ` Qian Cai
2019-09-24 15:11   ` Michal Hocko
2019-09-24 18:54     ` Qian Cai
2019-09-25  7:02       ` David Hildenbrand
2019-09-25 16:01         ` Qian Cai
2019-09-25 17:48           ` Michal Hocko
2019-09-25 18:20             ` Qian Cai
2019-09-25 19:48               ` David Hildenbrand
2019-09-25 20:32                 ` Qian Cai
2019-09-26  7:26                   ` David Hildenbrand
2019-09-26  7:38                     ` Michal Hocko
2019-09-26  7:26               ` Michal Hocko
2019-09-26 11:19                 ` Qian Cai
2019-09-26 11:52                   ` Michal Hocko
2019-09-26 13:02                     ` Qian Cai [this message]
2019-09-26 13:14                       ` David Hildenbrand
2019-09-25 10:03       ` Michal Hocko
2019-09-24 15:23   ` David Hildenbrand
2019-10-02 21:37 ` Qian Cai
2019-10-04  7:42   ` David Hildenbrand

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=1569502946.5576.237.camel@lca.pw \
    --to=cai@lca.pw \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=pasha.tatashin@soleen.com \
    --cc=tglx@linutronix.de \
    /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: link
Be 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.