Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp862335imu; Fri, 11 Jan 2019 10:19:23 -0800 (PST) X-Google-Smtp-Source: ALg8bN7MMjZY4r+C7nb8iWiMg7LX1+7wdz3OV4hsIlvY9mKalmzRSiuy4aXXcEhXD9QxBAE65nKZ X-Received: by 2002:a65:6392:: with SMTP id h18mr14476255pgv.107.1547230762943; Fri, 11 Jan 2019 10:19:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547230762; cv=none; d=google.com; s=arc-20160816; b=f6Ojs3tlgEN7/BZILNZob5xGoBxkhT442xrO9KP9EVk/ysMnCgWE314bfp4Zs1IOw2 9xQzk3Cy3RWZsCHknYcB8fEMoEh2GmHP4cMy1hupmY9snUmAnbupc2R3o1+Y6tJ8k3qV 7GjL6AjSA4/9Pd8E1gQi8T3sGyVDKRJdOkddaBXiQm1Am9HKb4LbTqJjjaa3X5AzJgZo 1ofY/1wucdDIUYTM/+a69DJmiTCcC1hhgiZBuoh/hyE5CgIGNcFejOjErsfz/Ksax07o +4XDqPHrEwWWa1PZU+6L1hsMqTz3u8mseXBvbMdClBPeZObqXqSWWWrwckiPdqVe7Ttm blew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=koPb3Cpu8WP6Cf9GuZQ1bTqf23Q4mJf5T5BRTALViUY=; b=UR+U2jVMPR3akuxCBCZEDeEpTiMRahMtbyNuDQ7nTc6XpcntZmNDeF8QogKvGm2RQ4 Xwe0USTk8k+ObjBEQPHCAb4s5AD7JaaY9p4XNWl+aQL04ROXgbmw7MQqctUDJKpiOwbM fMHX2vCTgzFyT3rwbQZi07OEjNJXzdcBTJ8sEwvCDCI1vd0JuXR2/tYodhd4P8kdfRcG 3A9CEFfyvDmD0rFEE5ustJV024euSDGu6ww7VN3GBmWdPM3DcBIi31VtTGqG8bGD4t8v /jZuGMURrXXAIutuNMN5tJfd4XCKNSIG5I5UdIERafoCOw5SrV9KSFMyihMNH1EjB8+N Aq6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ATcOZddB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z3si18393019pln.430.2019.01.11.10.19.07; Fri, 11 Jan 2019 10:19:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ATcOZddB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733059AbfAKOXE (ORCPT + 99 others); Fri, 11 Jan 2019 09:23:04 -0500 Received: from mail.kernel.org ([198.145.29.99]:35664 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729349AbfAKOTD (ORCPT ); Fri, 11 Jan 2019 09:19:03 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 772EC2183F; Fri, 11 Jan 2019 14:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547216342; bh=NB9LUEGkDiBXb3kkEIkR2r/RYcmwWQlT+yQnVbpQbxM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ATcOZddBsRfQ3RnuzXjoTN9C41LG2k8zbTfWa31oLAww2RuuFgRpw6yoRFVA4uKsG FaF+X5Y4GPhh0N/LEyYtXVZs3BZbxSfmaAGAsTkLynysYg9guzOuyUvJJ1OfEhiiD6 3e2Oob8SnRdKtlIVfQeipkP23u0fpEIjqmgnV32k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michal Hocko , Oscar Salvador , David Hildenbrand , Naoya Horiguchi , Andrew Morton , Linus Torvalds Subject: [PATCH 4.4 65/88] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined Date: Fri, 11 Jan 2019 15:08:34 +0100 Message-Id: <20190111131056.924629088@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190111131045.137499039@linuxfoundation.org> References: <20190111131045.137499039@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michal Hocko commit b15c87263a69272423771118c653e9a1d0672caa upstream. We have received a bug report that an injected MCE about faulty memory prevents memory offline to succeed on 4.4 base kernel. The underlying reason was that the HWPoison page has an elevated reference count and the migration keeps failing. There are two problems with that. First of all it is dubious to migrate the poisoned page because we know that accessing that memory is possible to fail. Secondly it doesn't make any sense to migrate a potentially broken content and preserve the memory corruption over to a new location. Oscar has found out that 4.4 and the current upstream kernels behave slightly differently with his simply testcase === int main(void) { int ret; int i; int fd; char *array = malloc(4096); char *array_locked = malloc(4096); fd = open("/tmp/data", O_RDONLY); read(fd, array, 4095); for (i = 0; i < 4096; i++) array_locked[i] = 'd'; ret = mlock((void *)PAGE_ALIGN((unsigned long)array_locked), sizeof(array_locked)); if (ret) perror("mlock"); sleep (20); ret = madvise((void *)PAGE_ALIGN((unsigned long)array_locked), 4096, MADV_HWPOISON); if (ret) perror("madvise"); for (i = 0; i < 4096; i++) array_locked[i] = 'd'; return 0; } === + offline this memory. In 4.4 kernels he saw the hwpoisoned page to be returned back to the LRU list kernel: [] dump_trace+0x59/0x340 kernel: [] show_stack_log_lvl+0xea/0x170 kernel: [] show_stack+0x21/0x40 kernel: [] dump_stack+0x5c/0x7c kernel: [] warn_slowpath_common+0x81/0xb0 kernel: [] __pagevec_lru_add_fn+0x14c/0x160 kernel: [] pagevec_lru_move_fn+0xad/0x100 kernel: [] __lru_cache_add+0x6c/0xb0 kernel: [] add_to_page_cache_lru+0x46/0x70 kernel: [] extent_readpages+0xc3/0x1a0 [btrfs] kernel: [] __do_page_cache_readahead+0x177/0x200 kernel: [] ondemand_readahead+0x168/0x2a0 kernel: [] generic_file_read_iter+0x41f/0x660 kernel: [] __vfs_read+0xcd/0x140 kernel: [] vfs_read+0x7a/0x120 kernel: [] kernel_read+0x3b/0x50 kernel: [] do_execveat_common.isra.29+0x490/0x6f0 kernel: [] do_execve+0x28/0x30 kernel: [] call_usermodehelper_exec_async+0xfb/0x130 kernel: [] ret_from_fork+0x55/0x80 And that latter confuses the hotremove path because an LRU page is attempted to be migrated and that fails due to an elevated reference count. It is quite possible that the reuse of the HWPoisoned page is some kind of fixed race condition but I am not really sure about that. With the upstream kernel the failure is slightly different. The page doesn't seem to have LRU bit set but isolate_movable_page simply fails and do_migrate_range simply puts all the isolated pages back to LRU and therefore no progress is made and scan_movable_pages finds same set of pages over and over again. Fix both cases by explicitly checking HWPoisoned pages before we even try to get reference on the page, try to unmap it if it is still mapped. As explained by Naoya: : Hwpoison code never unmapped those for no big reason because : Ksm pages never dominate memory, so we simply didn't have strong : motivation to save the pages. Also put WARN_ON(PageLRU) in case there is a race and we can hit LRU HWPoison pages which shouldn't happen but I couldn't convince myself about that. Naoya has noted the following: : Theoretically no such gurantee, because try_to_unmap() doesn't have a : guarantee of success and then memory_failure() returns immediately : when hwpoison_user_mappings fails. : Or the following code (comes after hwpoison_user_mappings block) also impli= : es : that the target page can still have PageLRU flag. : : /* : * Torn down by someone else? : */ : if (PageLRU(p) && !PageSwapCache(p) && p->mapping =3D=3D NULL) { : action_result(pfn, MF_MSG_TRUNCATED_LRU, MF_IGNORED); : res =3D -EBUSY; : goto out; : } : : So I think it's OK to keep "if (WARN_ON(PageLRU(page)))" block in : current version of your patch. Link: http://lkml.kernel.org/r/20181206120135.14079-1-mhocko@kernel.org Signed-off-by: Michal Hocko Reviewed-by: Oscar Salvador Debugged-by: Oscar Salvador Tested-by: Oscar Salvador Acked-by: David Hildenbrand Acked-by: Naoya Horiguchi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/memory_hotplug.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -32,6 +32,7 @@ #include #include #include +#include #include @@ -1471,6 +1472,21 @@ do_migrate_range(unsigned long start_pfn continue; } + /* + * HWPoison pages have elevated reference counts so the migration would + * fail on them. It also doesn't make any sense to migrate them in the + * first place. Still try to unmap such a page in case it is still mapped + * (e.g. current hwpoison implementation doesn't unmap KSM pages but keep + * the unmap as the catch all safety net). + */ + if (PageHWPoison(page)) { + if (WARN_ON(PageLRU(page))) + isolate_lru_page(page); + if (page_mapped(page)) + try_to_unmap(page, TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS); + continue; + } + if (!get_page_unless_zero(page)) continue; /*