From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F770C433FE for ; Thu, 14 Oct 2021 13:36:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4006761151 for ; Thu, 14 Oct 2021 13:36:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4006761151 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.dev Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 81BBC900003; Thu, 14 Oct 2021 09:36:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CA8E900002; Thu, 14 Oct 2021 09:36:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E108900003; Thu, 14 Oct 2021 09:36:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id 5ADF6900002 for ; Thu, 14 Oct 2021 09:36:57 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 04B9E2DEC8 for ; Thu, 14 Oct 2021 13:36:57 +0000 (UTC) X-FDA: 78695143674.07.1F7D7DD Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by imf04.hostedemail.com (Postfix) with ESMTP id C40FC50000A4 for ; Thu, 14 Oct 2021 13:36:55 +0000 (UTC) Date: Thu, 14 Oct 2021 22:36:44 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1634218614; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GQEUoO1u0vnESEeOSyCqC/9jXyzKonfBs4bm0m0IrIU=; b=kkMPpY6BessB7KtmtM82BpZwLoSFMJHb4d5Vxg9ykIxJEbcNVvMayrbUscmNT88kVFVoqa ar3+THmLsUNjOC3yzA/eKX9OwCYnq6cKp5sxUQ1yAtxrPRokrZxrav8d2Hem/riwKWlK38 BUVD/mphWSgkvEpqevkLpEIv31AqRVY= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Naoya Horiguchi To: Peter Xu Cc: linux-mm@kvack.org, Andrew Morton , Alistair Popple , Mike Kravetz , Konstantin Khlebnikov , Bin Wang , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] mm, pagemap: expose hwpoison entry Message-ID: <20211014133644.GA2023135@u2004> References: <20211004115001.1544259-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: naoya.horiguchi@linux.dev X-Rspamd-Queue-Id: C40FC50000A4 X-Stat-Signature: 4a79w4u7n736igotuqybgszd6ebryhiz Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=kkMPpY6B; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf04.hostedemail.com: domain of naoya.horiguchi@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=naoya.horiguchi@linux.dev X-Rspamd-Server: rspam02 X-HE-Tag: 1634218615-800143 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: On Wed, Oct 13, 2021 at 10:49:04AM +0800, Peter Xu wrote: > Hi, Naoya, > > On Mon, Oct 04, 2021 at 08:50:01PM +0900, Naoya Horiguchi wrote: > > +static inline struct page *hwpoison_entry_to_page(swp_entry_t entry) > > +{ > > + struct page *p = pfn_to_page(swp_offset(entry)); > > + > > + WARN_ON(!PageHWPoison(p)); > > + return p; > > +} > > This is more a pure question.. > > I'm wondering whether that WARN_ON() could trigger. > > IOW, what if we poison an anonymous page and then unpoison it? Thanks for the good question, this could trigger WARN for unpoisoned pages. The impact is limited because the caller of unpoison should know that that happens in testing workload, but maybe there's no good reason to prevent from it. So I'll drop this WARN_ON(). > Will there be a > hwpoison swap entry leftover in the ptes that it used to map? Yes it will, unpoison never affects exisiting hwpoison swap entries. > Will it crash > the program when the page is accessed? Reading hwpoison_entry_to_page() via pagemap interface should not crash because it just reads the page's metadata. The process with the hwpoison swap entry still receives SIGBUS when doing page fault (irrespective of doing unpoison or not) on the error address. > > I had a feeling that when handling the page fault in do_swap_page before we > SIGBUS the program, we should double-check the PageHWPoison on the pfn page, > but I could be missing something.. The double-checking seems to allow processes to detect that the hwpoison page is unpoisoned, some test programs could benefit from it. But maybe it could be done independent of this patch. Personally, I only use unpoison in cleanup phase of each test case, and each test case newly starts test processes, so reusing error pages with unpoison can be avoided. Thanks, Naoya Horiguchi