All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>, <linux-mm@kvack.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Gu Zheng <guz.fnst@cn.fujitsu.com>,
	Tang Chen <tangchen@cn.fujitsu.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Toshi Kani <toshi.kani@hpe.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Vlastimil Babka <vbabka@suse.cz>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] theoretical race between memory hotplug and pfn iterator
Date: Mon, 21 Dec 2015 15:00:08 +0800	[thread overview]
Message-ID: <5677A378.6010703@cn.fujitsu.com> (raw)
In-Reply-To: <20151221031501.GA32524@js1304-P5Q-DELUXE>


On 12/21/2015 11:15 AM, Joonsoo Kim wrote:
> Hello, memory-hotplug folks.
>
> I found theoretical problems between memory hotplug and pfn iterator.
> For example, pfn iterator works something like below.
>
> for (pfn = zone_start_pfn; pfn < zone_end_pfn; pfn++) {
>          if (!pfn_valid(pfn))
>                  continue;
>
>          page = pfn_to_page(pfn);
>          /* Do whatever we want */
> }
>
> Sequence of hotplug is something like below.
>
> 1) add memmap (after then, pfn_valid will return valid)
> 2) memmap_init_zone()
>
> So, if pfn iterator runs between 1) and 2), it could access
> uninitialized page information.
>
> This problem could be solved by re-ordering initialization steps.
>
> Hot-remove also has a problem. If memory is hot-removed after
> pfn_valid() succeed in pfn iterator, access to page would cause NULL
> deference because hot-remove frees corresponding memmap. There is no
> guard against free in any pfn iterators.
>
> This problem can be solved by inserting get_online_mems() in all pfn
> iterators but this looks error-prone for future usage. Another idea is
> that delaying free corresponding memmap until synchronization point such
> as system suspend. It will guarantee that there is no running pfn
> iterator. Do any have a better idea?
>
> Btw, I tried to memory-hotremove with QEMU 2.5.5 but it didn't work. I
> followed sequences in doc/memory-hotplug. Do you have any comment on this?

I tried memory hot remove with qemu 2.5.5 and RHEL 7, it works well.
Maybe you can provide more details, such as guest version, err log.

Thanks,
Zhu

>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
> .
>




WARNING: multiple messages have this Message-ID (diff)
From: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>, linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Gu Zheng <guz.fnst@cn.fujitsu.com>,
	Tang Chen <tangchen@cn.fujitsu.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Toshi Kani <toshi.kani@hpe.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] theoretical race between memory hotplug and pfn iterator
Date: Mon, 21 Dec 2015 15:00:08 +0800	[thread overview]
Message-ID: <5677A378.6010703@cn.fujitsu.com> (raw)
In-Reply-To: <20151221031501.GA32524@js1304-P5Q-DELUXE>


On 12/21/2015 11:15 AM, Joonsoo Kim wrote:
> Hello, memory-hotplug folks.
>
> I found theoretical problems between memory hotplug and pfn iterator.
> For example, pfn iterator works something like below.
>
> for (pfn = zone_start_pfn; pfn < zone_end_pfn; pfn++) {
>          if (!pfn_valid(pfn))
>                  continue;
>
>          page = pfn_to_page(pfn);
>          /* Do whatever we want */
> }
>
> Sequence of hotplug is something like below.
>
> 1) add memmap (after then, pfn_valid will return valid)
> 2) memmap_init_zone()
>
> So, if pfn iterator runs between 1) and 2), it could access
> uninitialized page information.
>
> This problem could be solved by re-ordering initialization steps.
>
> Hot-remove also has a problem. If memory is hot-removed after
> pfn_valid() succeed in pfn iterator, access to page would cause NULL
> deference because hot-remove frees corresponding memmap. There is no
> guard against free in any pfn iterators.
>
> This problem can be solved by inserting get_online_mems() in all pfn
> iterators but this looks error-prone for future usage. Another idea is
> that delaying free corresponding memmap until synchronization point such
> as system suspend. It will guarantee that there is no running pfn
> iterator. Do any have a better idea?
>
> Btw, I tried to memory-hotremove with QEMU 2.5.5 but it didn't work. I
> followed sequences in doc/memory-hotplug. Do you have any comment on this?

I tried memory hot remove with qemu 2.5.5 and RHEL 7, it works well.
Maybe you can provide more details, such as guest version, err log.

Thanks,
Zhu

>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
> .
>



--
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>

  reply	other threads:[~2015-12-21  7:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-21  3:15 [RFC] theoretical race between memory hotplug and pfn iterator Joonsoo Kim
2015-12-21  3:15 ` Joonsoo Kim
2015-12-21  7:00 ` Zhu Guihua [this message]
2015-12-21  7:00   ` Zhu Guihua
2015-12-21  7:17   ` Joonsoo Kim
2015-12-21  7:17     ` Joonsoo Kim
2015-12-21  8:00     ` Zhu Guihua
2015-12-21  8:00       ` Zhu Guihua
2015-12-21 12:09       ` Joonsoo Kim
2015-12-21 12:09         ` Joonsoo Kim

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=5677A378.6010703@cn.fujitsu.com \
    --to=zhugh.fnst@cn.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=guz.fnst@cn.fujitsu.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=tangchen@cn.fujitsu.com \
    --cc=toshi.kani@hpe.com \
    --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: 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.