From patchwork Tue Aug 7 13:37:54 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oscar Salvador X-Patchwork-Id: 10558719 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D01D115E9 for ; Tue, 7 Aug 2018 13:38:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BE37329E0E for ; Tue, 7 Aug 2018 13:38:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B18FB29E12; Tue, 7 Aug 2018 13:38:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3CA6429E0E for ; Tue, 7 Aug 2018 13:38:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53DB56B0008; Tue, 7 Aug 2018 09:38:23 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 4C4E46B000A; Tue, 7 Aug 2018 09:38:23 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38E896B000C; Tue, 7 Aug 2018 09:38:23 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by kanga.kvack.org (Postfix) with ESMTP id CC5BF6B0008 for ; Tue, 7 Aug 2018 09:38:22 -0400 (EDT) Received: by mail-wr1-f69.google.com with SMTP id v2-v6so13426350wrr.10 for ; Tue, 07 Aug 2018 06:38:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id; bh=ziiB6gTLMB/9gD7iUir7Jkrz77ZVyEAUugNoYTMtqI4=; b=BEAOitaUKrL1NgS5lwpQgnPwN1Pk0uKYP83LnyPoHMPVfuToLCnWvItTR5WDp03X5C eYQi7rE0o15Lb4TxX9zPxFOaoPoiTNhWSaPJvjvbNioj+wOkHBic/GDpFIP02J520+SF XsTSsMbhPh7rJ38/NN44lA9LMX4nfzVx3DHHfqGG+M7Qk0MN9o9utJRjjLPSYgK5idAe UUma9GDxb3SAAwoNDnrT8nUPW+OVMFXcAZlK5O6fWPGElpkQZiFjCmU5zELyrod4hSm4 Z0YBE1GhU8KbV1fqhxkOTzDYZShP7lwH6nqXJCXu6JRxed5kCx8+knHdvoXVFaYguvBN P2Ww== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=osalvador.vilardaga@gmail.com X-Gm-Message-State: AOUpUlHEejNLXp+n5OksmxqiF+KqbQheGWJHDmwDO7ukT7I4vI7PVRkz e++pwUZBq4t90N8cD4krPLzZUOfyUrfcgG32ulmzSbKPFuL/RmjNdi+Dc3sMHdWwpdTKzi0Xe3m BF7i8L3DmR3sXSepZifNrl/UvGN+gAywQZnkAupd02b+idtxu88bY/VK44i5jELIsHmitYAAcZv xOsIL/f7+Kxtcy5wuKE/QXypMpZnFVk3diLArjOCNOPEGNj5TrW1ko3aSKZffmbNBqVjXeJTPH7 1Yez8SYggrvnuRXY9I4gNk7llKQOeAMCdEcDXQbQKjEM/yZLR7X0vX8pztIzt1nk4NdGMRVi6Wx 0WTpCR3a1Zjwwii/i7c3ljWsdh3yKjghgRDotVY/uM05u0AsQze/KekN5xhrvV/wMHAhT0ypzQ= = X-Received: by 2002:a5d:69ca:: with SMTP id s10-v6mr12303264wrw.77.1533649102374; Tue, 07 Aug 2018 06:38:22 -0700 (PDT) X-Received: by 2002:a5d:69ca:: with SMTP id s10-v6mr12303240wrw.77.1533649101580; Tue, 07 Aug 2018 06:38:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533649101; cv=none; d=google.com; s=arc-20160816; b=YDpzDo7ecEHLpUhdabD0F75DnxH+6Wqdp9YpGCPpnHnbJhuiZLVBygWLa3fN+pgl/h KoQ8Fns49hjkO+HqcfM7a7QDTm7xIF1lLcaCwl8DUUvzIJt1Od3vn7YyKiY54gSrvtYU 0sp+lmXOMLMGh9TU0HOOT+Uk6ROk7qsZwi1Npb/Qo5cjouKDDa2ui8ivaWfbWYN1Ra0u d7ElcqB5fl2bB5NqvpQOdq1FIP0VhsGhUbbAvBCI4pEOi0dQQThx1TQ7iByuRYV/raT6 J2BSlPa4fPSJ0jR4YxlYS2QeXGEKEg48CzPU1xdYGTsiK1SMZyalS1Tuhgek56SxmO45 spqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from:arc-authentication-results; bh=ziiB6gTLMB/9gD7iUir7Jkrz77ZVyEAUugNoYTMtqI4=; b=IMpSbALfu3MRnBnuT6h2zghgm+bsKqvTz4ZhfuWGROydlCd5ECyMF8j812QQjEbN3A gCuurnTMP3ur37NWa2yQ3MLJ2Ddrg5VebXbjaaxkc1V28Dt2H9YRUruL7k/vD3yUqqiD 5vX4oWhdwSqPZtMYVRxuAI607OXOYXCkJXNzzNfbZGDdOCE06uJZX9gOI2L+9y0/bpB2 6tgfPBMn1ziAqLpTPD9qND6rkoMk8xTWjlPuPFbhNUjWVVZHpGtXxsE233zy9lCY+1zW ryXHysL5p7WTvC3C1D2eCfki5ZBuH5iifDrr8SM16M34wZ8Mv3mrbQa0AumLYuAvJ7+G weKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=osalvador.vilardaga@gmail.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id g17-v6sor588431wrp.51.2018.08.07.06.38.21 for (Google Transport Security); Tue, 07 Aug 2018 06:38:21 -0700 (PDT) Received-SPF: pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; spf=pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=osalvador.vilardaga@gmail.com X-Google-Smtp-Source: AAOMgpf7fANP11lgrtFRUP6qFhGyNJ80bMVAfpO2UeBXljkJsx2B6Nn95d1BiwfehPXjAcyBCp1u1Q== X-Received: by 2002:adf:dd07:: with SMTP id a7-v6mr13300491wrm.2.1533649101248; Tue, 07 Aug 2018 06:38:21 -0700 (PDT) Received: from techadventures.net (techadventures.net. [62.201.165.239]) by smtp.gmail.com with ESMTPSA id f17-v6sm1015503wrs.1.2018.08.07.06.38.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 06:38:20 -0700 (PDT) Received: from d104.suse.de (charybdis-ext.suse.de [195.135.221.2]) by techadventures.net (Postfix) with ESMTPA id A6174124545; Tue, 7 Aug 2018 15:38:19 +0200 (CEST) From: osalvador@techadventures.net To: akpm@linux-foundation.org Cc: mhocko@suse.com, dan.j.williams@intel.com, pasha.tatashin@oracle.com, jglisse@redhat.com, david@redhat.com, yasu.isimatu@gmail.com, logang@deltatee.com, dave.jiang@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador Subject: [RFC PATCH 0/3] Do not touch pages in remove_memory path Date: Tue, 7 Aug 2018 15:37:54 +0200 Message-Id: <20180807133757.18352-1-osalvador@techadventures.net> X-Mailer: git-send-email 2.13.6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP From: Oscar Salvador This tries to fix [1], which was reported by David Hildenbrand, and also does some cleanups/refactoring. I am sending this as RFC to see if the direction I am going is right before spending more time into it. And also to gather feedback about hmm/zone_device stuff. The code compiles and I tested it successfully with normal memory-hotplug operations. Here we go: With the following scenario: 1) We add memory 2) We do not online it 3) We remove the memory an invalid access is being made to those pages. The reason is that the pages are initialized in online_pages() path: / online_pages | move_pfn_range ONLINE | move_pfn_range_to_zone PAGES | ... | memmap_init_zone But depending on our policy about onlining the pages by default, we might not online them right after having added the memory, and so, those pages might be left unitialized. This is a problem because we access those pages in arch_remove_memory: ... if (altmap) page += vmem_altmap_offset(altmap); zone = page_zone(page); ... So we are accessing unitialized data basically. Currently, we need to have the zone from arch_remove_memory to all the way down because 1) we call __remove_zone zo shrink spanned pages from pgdat/zone 2) we get the pgdat from the zone Number 1 can be fixed by moving __remove_zone back to offline_pages(), where it should be. This, besides fixing the bug, will make the code more consistent because all the reveserse operations from online_pages() will be made in offline_pages(). Number 2 can be fixed by passing nid instead of zone. The tricky part of all this is the hmm code and the zone_device stuff. Fixing the calls to arch_remove_memory in the arch code is easy, but arch_remove_memory is being used in: kernel/memremap.c: devm_memremap_pages_release() mm/hmm.c: hmm_devmem_release() I did my best to get my head around this, but my knowledge in that area is 0, so I am pretty sure I did not get it right. The thing is: devm_memremap_pages(), which is the counterpart of devm_memremap_pages_release(), calls arch_add_memory(), and then calls move_pfn_range_to_zone() (to ZONE_DEVICE). So it does not go through online_pages(). So there I call shrink_pages() (it does pretty much as __remove_zone) before calling to arch_remove_memory. But as I said, I do now if that is right. [1] https://patchwork.kernel.org/patch/10547445/ Oscar Salvador (3): mm/memory_hotplug: Add nid parameter to arch_remove_memory mm/memory_hotplug: Create __shrink_pages and move it to offline_pages mm/memory_hotplug: Refactor shrink_zone/pgdat_span arch/ia64/mm/init.c | 6 +- arch/powerpc/mm/mem.c | 13 +-- arch/s390/mm/init.c | 2 +- arch/sh/mm/init.c | 6 +- arch/x86/mm/init_32.c | 6 +- arch/x86/mm/init_64.c | 10 +-- include/linux/memory_hotplug.h | 8 +- kernel/memremap.c | 9 +- mm/hmm.c | 6 +- mm/memory_hotplug.c | 190 +++++++++++++++++++++-------------------- mm/sparse.c | 4 +- 11 files changed, 127 insertions(+), 133 deletions(-)