Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp7058813ybi; Thu, 1 Aug 2019 02:35:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqzRUzA196XEss8xVo7Vv5w8XrLyY5J/6h+iNnwh4w2wwtcLD+M8gNyubF8ALNWRxOakhw6g X-Received: by 2002:a17:90a:bf02:: with SMTP id c2mr7662480pjs.73.1564652112830; Thu, 01 Aug 2019 02:35:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564652112; cv=none; d=google.com; s=arc-20160816; b=ze/OqD3WTEIOPe7HCT36nlsE7p54/fZ+RG9ISDbpm45YUsqo755mwiOZOgryc32ccx GA5UfsUNuKSZekLDO2CR0FtEaAS+mOpPJ39iCjIp3nypkAqGCXPCjnWi/zUYYbJeqLOB yp0lzczdSfdOndhMP0VzQ8SWEKTf5HPzJmvs4W6ljGV4A8D8P8xoBPbLfBLomWOh3hjc vxGdcUMr0yaidmtOGi4qKMSFlxTjCWKZBTztpoO0worXLlgQYWK8P8UyIxWGtzx1L/jn v91UbOxIdm0yBOZkPDG5huuQUPRXtTu9eCY8mslVrOTgD5Yk+9a2FlfWBwBQYJjhVYEs qpSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-id:content-language:accept-language:in-reply-to:references :message-id:date:thread-index:thread-topic:subject:cc:to:from; bh=7thpPaiDq68+c1khWHKAfUKR/3gORsNizSDx97HNfGc=; b=sw2R3wvD7+Jy87VBVuyd4/11aVVKyIDaekiXTXsEh3oIjjI9LtfX/2f79U0oHmrWKg KNhlG41soAukA2NKNSSVmJU3DarhRsyR9L1Hz6ZaBJFIy7fH/o1Ygb/g6h01nhZ2q0uT pJLDMCfw/WVZapMUL9PPqupshC/5k4cQJuQv8IcroygXvvQ9fC94d1n4xQa5fHEUJI+z T/DsKonZGzv+/rrSjidRe8/3Vhyh6uhehbTNyi1VU8blaUJxY2eTej1WTv50qtcP11kj pobCUe54Qhi9lOsCYW/rACVZXfGY/67mRToSmwkDnork6MzuXhIgFV/zcpw7SrBoQGPI NL8A== ARC-Authentication-Results: i=1; mx.google.com; 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 k15si41339714pgj.216.2019.08.01.02.34.57; Thu, 01 Aug 2019 02:35:12 -0700 (PDT) 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; 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 S1731011AbfHAIT0 convert rfc822-to-8bit (ORCPT + 99 others); Thu, 1 Aug 2019 04:19:26 -0400 Received: from tyo161.gate.nec.co.jp ([114.179.232.161]:38845 "EHLO tyo161.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727956AbfHAIT0 (ORCPT ); Thu, 1 Aug 2019 04:19:26 -0400 Received: from mailgate01.nec.co.jp ([114.179.233.122]) by tyo161.gate.nec.co.jp (8.15.1/8.15.1) with ESMTPS id x718JDMC025230 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Aug 2019 17:19:13 +0900 Received: from mailsv02.nec.co.jp (mailgate-v.nec.co.jp [10.204.236.94]) by mailgate01.nec.co.jp (8.15.1/8.15.1) with ESMTP id x718JD2t023372; Thu, 1 Aug 2019 17:19:13 +0900 Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv02.nec.co.jp (8.15.1/8.15.1) with ESMTP id x718Isjq021046; Thu, 1 Aug 2019 17:19:13 +0900 Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.147] [10.38.151.147]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-7316139; Thu, 1 Aug 2019 17:17:39 +0900 Received: from BPXM23GP.gisp.nec.co.jp ([10.38.151.215]) by BPXC19GP.gisp.nec.co.jp ([10.38.151.147]) with mapi id 14.03.0439.000; Thu, 1 Aug 2019 17:17:38 +0900 From: Naoya Horiguchi To: Jane Chu CC: "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-nvdimm@lists.01.org" Subject: Re: [PATCH v3 2/2] mm/memory-failure: Poison read receives SIGKILL instead of SIGBUS if mmaped more than once Thread-Topic: [PATCH v3 2/2] mm/memory-failure: Poison read receives SIGKILL instead of SIGBUS if mmaped more than once Thread-Index: AQHVQzSPZWUqS0z8rU+q1hsF+rBObKblZd+A Date: Thu, 1 Aug 2019 08:17:37 +0000 Message-ID: <20190801081737.GA31767@hori.linux.bs1.fc.nec.co.jp> References: <1564092101-3865-1-git-send-email-jane.chu@oracle.com> <1564092101-3865-3-git-send-email-jane.chu@oracle.com> In-Reply-To: <1564092101-3865-3-git-send-email-jane.chu@oracle.com> Accept-Language: en-US, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.125.150] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <372749A4D6FFC14982F5FD30BC1E06A7@gisp.nec.co.jp> Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 25, 2019 at 04:01:41PM -0600, Jane Chu wrote: > Mmap /dev/dax more than once, then read the poison location using address > from one of the mappings. The other mappings due to not having the page > mapped in will cause SIGKILLs delivered to the process. SIGKILL succeeds > over SIGBUS, so user process looses the opportunity to handle the UE. > > Although one may add MAP_POPULATE to mmap(2) to work around the issue, > MAP_POPULATE makes mapping 128GB of pmem several magnitudes slower, so > isn't always an option. > > Details - > > ndctl inject-error --block=10 --count=1 namespace6.0 > > ./read_poison -x dax6.0 -o 5120 -m 2 > mmaped address 0x7f5bb6600000 > mmaped address 0x7f3cf3600000 > doing local read at address 0x7f3cf3601400 > Killed > > Console messages in instrumented kernel - > > mce: Uncorrected hardware memory error in user-access at edbe201400 > Memory failure: tk->addr = 7f5bb6601000 > Memory failure: address edbe201: call dev_pagemap_mapping_shift > dev_pagemap_mapping_shift: page edbe201: no PUD > Memory failure: tk->size_shift == 0 > Memory failure: Unable to find user space address edbe201 in read_poison > Memory failure: tk->addr = 7f3cf3601000 > Memory failure: address edbe201: call dev_pagemap_mapping_shift > Memory failure: tk->size_shift = 21 > Memory failure: 0xedbe201: forcibly killing read_poison:22434 because of failure to unmap corrupted page > => to deliver SIGKILL > Memory failure: 0xedbe201: Killing read_poison:22434 due to hardware memory corruption > => to deliver SIGBUS > > Signed-off-by: Jane Chu > Suggested-by: Naoya Horiguchi > --- > mm/memory-failure.c | 22 +++++++++++++--------- > 1 file changed, 13 insertions(+), 9 deletions(-) > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index 51d5b20..f668c88 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -199,7 +199,6 @@ struct to_kill { > struct task_struct *tsk; > unsigned long addr; > short size_shift; > - char addr_valid; > }; > > /* > @@ -318,22 +317,27 @@ static void add_to_kill(struct task_struct *tsk, struct page *p, > } > > tk->addr = page_address_in_vma(p, vma); > - tk->addr_valid = 1; > if (is_zone_device_page(p)) > tk->size_shift = dev_pagemap_mapping_shift(p, vma); > else > tk->size_shift = compound_order(compound_head(p)) + PAGE_SHIFT; > > /* > - * In theory we don't have to kill when the page was > - * munmaped. But it could be also a mremap. Since that's > - * likely very rare kill anyways just out of paranoia, but use > - * a SIGKILL because the error is not contained anymore. > + * Send SIGKILL if "tk->addr == -EFAULT". Also, as > + * "tk->size_shift" is always non-zero for !is_zone_device_page(), > + * so "tk->size_shift == 0" effectively checks no mapping on > + * ZONE_DEVICE. Indeed, when a devdax page is mmapped N times > + * to a process' address space, it's possible not all N VMAs > + * contain mappings for the page, but at least one VMA does. > + * Only deliver SIGBUS with payload derived from the VMA that > + * has a mapping for the page. > */ > - if (tk->addr == -EFAULT || tk->size_shift == 0) { > + if (tk->addr == -EFAULT) { ^ (sorry nitpicking...) there's a trailing whitespace. Otherwise looks good to me. Acked-by: Naoya Horiguchi > pr_info("Memory failure: Unable to find user space address %lx in %s\n", > page_to_pfn(p), tsk->comm); > - tk->addr_valid = 0; > + } else if (tk->size_shift == 0) { > + kfree(tk); > + return; > } > > get_task_struct(tsk); > @@ -361,7 +365,7 @@ static void kill_procs(struct list_head *to_kill, int forcekill, bool fail, > * make sure the process doesn't catch the > * signal and then access the memory. Just kill it. > */ > - if (fail || tk->addr_valid == 0) { > + if (fail || tk->addr == -EFAULT) { > pr_err("Memory failure: %#lx: forcibly killing %s:%d because of failure to unmap corrupted page\n", > pfn, tk->tsk->comm, tk->tsk->pid); > do_send_sig_info(SIGKILL, SEND_SIG_PRIV, > -- > 1.8.3.1 > >