Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1983359pxb; Mon, 8 Mar 2021 10:55:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJze/XRjjtxXLM4WBqovDDCbann8W51CnRS9Zg/nevX+MRZMeVDDiOvIad1eJJ30FAYjOGHi X-Received: by 2002:a17:906:789:: with SMTP id l9mr16133766ejc.161.1615229745190; Mon, 08 Mar 2021 10:55:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615229745; cv=none; d=google.com; s=arc-20160816; b=rZaF6F145qFRocNylrsXHCd6gKJ5CxZwYMmyNYXXTv25RrvoBr2YMY9NVtvwksAoTy PM4YKnB7/RdM7aazgwh9dZQxl2U7AewP4Kkisq2ML5+v5PzD42X12GOHfQyx3vpZfex+ eRrBL2bku0W/cLm5WEc1lbSRyWtA5IJRIe0II79PhRPH1/26L/PFmTlNl+uEgtL0nLEw N/BlXDeaUQj12DX1//w1wAmzPo+gY8VeOoM03csGMhyKbUApHPg+y4sEZqpCQVOyK+3r COi8AwB0UNhcg3swxUaOjmdKxdE1HNfXLXzDPzhq8uPM2Ankhmap2543292GGRlfjrWs 9YHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :dlp-version:dlp-reaction:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:ironport-sdr:ironport-sdr; bh=I9EKW+WT41lE9AwjTlqTRbm8t4wPwxnAvyM2Is04Zxg=; b=TcPjunNyRw33xZh6pPXi5ZdMKWvN8g+u0oyRp5fhPYSpUSrtgE1iPMDK05qf9FHa1R ATu0pnSm197Rtm2UbY/gtA/LjupY9FGpDX3PCpiI5BpGpYLqs0JI1XVy02hAt1EfP0oq 04GyzpDhVrjgtN1Cz24Vdimo8HoFYaQa8iHaq0pJjJYLHv9dKQ3x2sC8MEmTDGagxxr1 aKe7slJpNWPhiVlhqhwjbitxBO3irgz2oDUsDlUJjp4jjxUmxM+umQ3aK4xYi6ComFfb R+eCz4v66YxfFUYE3asj4Ez6+QFbQwszN2l8+w/VofI8OKGS+3W3yM14ahfLgkZisbkc QmHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p25si7626580edm.297.2021.03.08.10.55.22; Mon, 08 Mar 2021 10:55:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230412AbhCHSyK convert rfc822-to-8bit (ORCPT + 99 others); Mon, 8 Mar 2021 13:54:10 -0500 Received: from mga14.intel.com ([192.55.52.115]:31937 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231249AbhCHSyF (ORCPT ); Mon, 8 Mar 2021 13:54:05 -0500 IronPort-SDR: tC/qCz22UG3Hn4N5z8b9XpRBRAwq/0p2IYCEGWIRK7+znykcoEIawMezX3AutBqpDWHwDi2njr uqNQurRDYoVw== X-IronPort-AV: E=McAfee;i="6000,8403,9917"; a="187449864" X-IronPort-AV: E=Sophos;i="5.81,233,1610438400"; d="scan'208";a="187449864" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2021 10:54:05 -0800 IronPort-SDR: DAukqgs/k/S1fw6lyM65c88NQwWMEYELuHbUA4ffTZ75YDCRt59nM5t8XwGCszEf5RKjgBTPl2 8TtcKU7F8JBw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,233,1610438400"; d="scan'208";a="408333310" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga007.jf.intel.com with ESMTP; 08 Mar 2021 10:54:03 -0800 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 8 Mar 2021 10:54:03 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 8 Mar 2021 10:54:03 -0800 Received: from fmsmsx610.amr.corp.intel.com ([10.18.126.90]) by fmsmsx610.amr.corp.intel.com ([10.18.126.90]) with mapi id 15.01.2106.013; Mon, 8 Mar 2021 10:54:03 -0800 From: "Luck, Tony" To: =?iso-2022-jp?B?SE9SSUdVQ0hJIE5BT1lBKBskQktZOH0hIUQ+TGkbKEIp?= CC: Aili Yao , Oscar Salvador , "david@redhat.com" , "akpm@linux-foundation.org" , "bp@alien8.de" , "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" , "x86@kernel.org" , "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "yangfeng1@kingsoft.com" Subject: RE: [PATCH] mm,hwpoison: return -EBUSY when page already poisoned Thread-Topic: [PATCH] mm,hwpoison: return -EBUSY when page already poisoned Thread-Index: AQHXCnz5ja9ELypBUEatGW66U99st6pnoa2AgAEgN4CAAIHfAIAAAyEAgAAQXwD//9g7gIABDSmAgAALNoCAB2DqAIAAiu0AgABOzQD//+3L0IABObiAgAAiT4CAACi3AIAAmjmAgACgEACAAAHdAIAA0uUAgAQ6cQCAAESgQA== Date: Mon, 8 Mar 2021 18:54:02 +0000 Message-ID: <3690ece2101d428fb9067fcd2a423ff8@intel.com> References: <20210303115710.2e9f8e23@alex-virtual-machine> <20210303163912.3d508e0f@alex-virtual-machine> <1a78e9abdc134e35a5efcbf6b2fd2263@intel.com> <20210304101653.546a9da1@alex-virtual-machine> <20210304121941.667047c3@alex-virtual-machine> <20210304144524.795872d7@alex-virtual-machine> <20210304235720.GA215567@agluck-desk2.amr.corp.intel.com> <20210305093016.40c87375@alex-virtual-machine> <20210305093656.6c262b19@alex-virtual-machine> <20210305221143.GA220893@agluck-desk2.amr.corp.intel.com> <20210308064558.GA3617@hori.linux.bs1.fc.nec.co.jp> In-Reply-To: <20210308064558.GA3617@hori.linux.bs1.fc.nec.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 x-originating-ip: [10.1.200.100] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> So it should be safe to grab and hold a mutex. See patch below. > > The mutex approach looks simpler and safer, so I'm fine with it. Thanks. Is that an "Acked-by:"? >> /** >> * memory_failure - Handle memory failure of a page. >> * @pfn: Page Number of the corrupted page >> @@ -1424,12 +1426,18 @@ int memory_failure(unsigned long pfn, int flags) >> return -ENXIO; >> } >> >> + mutex_lock(&mf_mutex); > > Is it better to take mutex before memory_failure_dev_pagemap() block? > Or we don't have to protect against race for device memory? No races (recovery is only attempted for errors in normal memory). -Tony