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 5CDF4C433EF for ; Thu, 14 Oct 2021 23:32:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F2191610E8 for ; Thu, 14 Oct 2021 23:32:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F2191610E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 160726B006C; Thu, 14 Oct 2021 19:32:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 11007900002; Thu, 14 Oct 2021 19:32:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F18676B0072; Thu, 14 Oct 2021 19:32:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0192.hostedemail.com [216.40.44.192]) by kanga.kvack.org (Postfix) with ESMTP id DECDA6B006C for ; Thu, 14 Oct 2021 19:32:56 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8C74C1844CAC9 for ; Thu, 14 Oct 2021 23:32:56 +0000 (UTC) X-FDA: 78696645552.05.F4770BD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 04961B0000AE for ; Thu, 14 Oct 2021 23:32:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634254375; 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=ZP8SCmWhinsseT0tp+2aieN8jcGMf8lc14k0qLDaWm8=; b=AUO4ltM3A9HXEkz28c0QcV/QrQT+BDj91hdktwbHiMlTg/tF7fCGWHI1Ajwbz4PoRCIEHR gZDMaJdS6QSWttpyeY/JalS+djfQoYpjYCdB9UQe41cYSEU9IO+MyUWKxrDsUKnoXnFBps VQZgu9mtEExytPMJYLcOa913Xt5kQlk= Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-462-7xhwX_c9NWiw5Z7ri-5feQ-1; Thu, 14 Oct 2021 19:32:54 -0400 X-MC-Unique: 7xhwX_c9NWiw5Z7ri-5feQ-1 Received: by mail-pf1-f200.google.com with SMTP id j2-20020a056a00174200b0044d39a43c9bso4247197pfc.22 for ; Thu, 14 Oct 2021 16:32:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZP8SCmWhinsseT0tp+2aieN8jcGMf8lc14k0qLDaWm8=; b=PSUbwnJPooNbxeQxWbivU7u1O7VKf5D7d024VdeDGK27aKGNHrCTWqcDCAQHUO075X FtQXoObFDppQVXH8zyy+HJpNDhYNaVYX0KyD1CaDSpf0HqMKULUzgc3jZwejOHhVIv2K CoSNAteeHrwvw82UmvRzwqSL7ziZUWWJe/M6O7uistBN/IByd8d/1movBxIFb5md+Fqa 57KXy24R/p0UlG1umjJeRv1mZeGyD+SU1ye3j2526LdQ3tYfPjXJ5gzxQqFhqpjTsRqz njkjRL7JxX4Yp+ewfpoW0nc2wVPN7q/vyyIRYy6mpBc+8HOZfOztQmgKHWEOpDH8Y8YO rR0Q== X-Gm-Message-State: AOAM532tY+Au1dbqJWRyEGJuLZp/D8Ffrw4CkuxA9U5/2VUmF70l5XQs 3mcMYVmmBZ4p46R4BBfJfc8pSP0Xr4u4W2xfnHM2QGw6hwCvqS4x/djFAd40UidEx3rUYCLeDm1 G3BLSVdWgRMw= X-Received: by 2002:a17:903:2304:b0:13f:2457:11dd with SMTP id d4-20020a170903230400b0013f245711ddmr7769792plh.57.1634254372922; Thu, 14 Oct 2021 16:32:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyY0hpZ6BiVdnXclPKsGbq+0iJv6Y0KHCT1YVugxwer2zWJ6N9SUgmF8imhcDscSZzJwvWK4Q== X-Received: by 2002:a17:903:2304:b0:13f:2457:11dd with SMTP id d4-20020a170903230400b0013f245711ddmr7769756plh.57.1634254372606; Thu, 14 Oct 2021 16:32:52 -0700 (PDT) Received: from t490s ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id d67sm3273534pfd.151.2021.10.14.16.32.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 16:32:51 -0700 (PDT) Date: Fri, 15 Oct 2021 07:32:45 +0800 From: Peter Xu To: Naoya Horiguchi 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: References: <20211004115001.1544259-1-naoya.horiguchi@linux.dev> <20211014133644.GA2023135@u2004> MIME-Version: 1.0 In-Reply-To: <20211014133644.GA2023135@u2004> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 04961B0000AE X-Stat-Signature: snn9g6iwkgz58oi6cnzzn8tx5b59k34z Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AUO4ltM3; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf19.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-HE-Tag: 1634254374-558915 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 Thu, Oct 14, 2021 at 10:36:44PM +0900, Naoya Horiguchi wrote: > 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(). Sounds good, thanks. > > 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. I see. We don't have anything like soft-online a page, do we? I also don't know whether hwpoison can be used in any other form besides testing the hwpoison code path. E.g. logically it can be used to forbid accessing a physical page for any reason then recover using unhwpoison? Uffd has the SIGBUS mode that can do similar thing to the virtual address space, so any access to some page will generate a SIGBUS. While hwpoison is phsical address space based from that pov, and just like uffd it doesn't need to change vma layout which should be a good property unlike mprotect(). But I totally have no clue on all these... so it's just wild idea. Anyway, agreed on above, even if it's applicable it should be a separate patch. Thanks, -- Peter Xu