Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751517AbbLUDNG (ORCPT ); Sun, 20 Dec 2015 22:13:06 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:58059 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751145AbbLUDNF (ORCPT ); Sun, 20 Dec 2015 22:13:05 -0500 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: iamjoonsoo.kim@lge.com X-Original-SENDERIP: 10.177.222.138 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Mon, 21 Dec 2015 12:15:01 +0900 From: Joonsoo Kim To: linux-mm@kvack.org Cc: Andrew Morton , Gu Zheng , Tang Chen , Naoya Horiguchi , Toshi Kani , Mel Gorman , Vlastimil Babka , linux-kernel@vger.kernel.org Subject: [RFC] theoretical race between memory hotplug and pfn iterator Message-ID: <20151221031501.GA32524@js1304-P5Q-DELUXE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1581 Lines: 43 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? 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/