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 X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B374C433ED for ; Thu, 6 May 2021 07:06:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CFAD0611EE for ; Thu, 6 May 2021 07:06:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CFAD0611EE Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1E2106B006E; Thu, 6 May 2021 03:06:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16B5A6B0070; Thu, 6 May 2021 03:06:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFF9F8D0001; Thu, 6 May 2021 03:06:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id D01496B006E for ; Thu, 6 May 2021 03:06:17 -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 80B35180AD837 for ; Thu, 6 May 2021 07:06:17 +0000 (UTC) X-FDA: 78109922394.05.3C85CD3 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf15.hostedemail.com (Postfix) with ESMTP id EC294A000396 for ; Thu, 6 May 2021 07:06:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1620284776; h=from:from:reply-to: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=2ZsN+U9xYy8SB6qQBQij2SzxvCN+k/V0YckFGYc2r3w=; b=ffDOAVGcvH2zQvGSxi7ErqNPrJj5pM//Z1w8IoOiMf7JbN0XRZELBXG8ZCVBrEv9p/Qzig sxstkvj7FXtZl1AwHuusfPOP/u3JQ7fMAUER8GLoJjKjwcaUCkFMfNj1p5ed3yenArURyT aX9hDC+G8TKiOPQhbQ+CjXxi0YKn5HM= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id DDEECAFD0; Thu, 6 May 2021 07:06:15 +0000 (UTC) Date: Thu, 6 May 2021 09:06:14 +0200 From: Michal Hocko To: Aili Yao Cc: David Hildenbrand , linux-kernel@vger.kernel.org, Andrew Morton , "Michael S. Tsirkin" , Jason Wang , Alexey Dobriyan , Mike Rapoport , "Matthew Wilcox (Oracle)" , Oscar Salvador , Roman Gushchin , Alex Shi , Steven Price , Mike Kravetz , Jiri Bohac , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Wei Liu , Naoya Horiguchi , linux-hyperv@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, yaoaili126@gmail.com Subject: Re: [PATCH v1 3/7] mm: rename and move page_is_poisoned() Message-ID: References: <20210429122519.15183-1-david@redhat.com> <20210429122519.15183-4-david@redhat.com> <0710d8d5-2608-aeed-10c7-50a272604d97@redhat.com> <20210506085611.1ec21588@alex-virtual-machine> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210506085611.1ec21588@alex-virtual-machine> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: EC294A000396 X-Stat-Signature: m8ba6yj7btd68x85uek5kgj9e3i7t61w Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ffDOAVGc; spf=pass (imf15.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620284770-211122 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 06-05-21 08:56:11, Aili Yao wrote: > On Wed, 5 May 2021 15:27:39 +0200 > Michal Hocko wrote: > > > On Wed 05-05-21 15:17:53, David Hildenbrand wrote: > > > On 05.05.21 15:13, Michal Hocko wrote: > > > > On Thu 29-04-21 14:25:15, David Hildenbrand wrote: > > > > > Commit d3378e86d182 ("mm/gup: check page posion status for coredump.") > > > > > introduced page_is_poisoned(), however, v5 [1] of the patch used > > > > > "page_is_hwpoison()" and something went wrong while upstreaming. Rename the > > > > > function and move it to page-flags.h, from where it can be used in other > > > > > -- kcore -- context. > > > > > > > > > > Move the comment to the place where it belongs and simplify. > > > > > > > > > > [1] https://lkml.kernel.org/r/20210322193318.377c9ce9@alex-virtual-machine > > > > > > > > > > Signed-off-by: David Hildenbrand > > > > > > > > I do agree that being explicit about hwpoison is much better. Poisoned > > > > page can be also an unitialized one and I believe this is the reason why > > > > you are bringing that up. > > > > > > I'm bringing it up because I want to reuse that function as state above :) > > > > > > > > > > > But you've made me look at d3378e86d182 and I am wondering whether this > > > > is really a valid patch. First of all it can leak a reference count > > > > AFAICS. Moreover it doesn't really fix anything because the page can be > > > > marked hwpoison right after the check is done. I do not think the race > > > > is feasible to be closed. So shouldn't we rather revert it? > > > > > > I am not sure if we really care about races here that much here? I mean, > > > essentially we are racing with HW breaking asynchronously. Just because we > > > would be synchronizing with SetPageHWPoison() wouldn't mean we can stop HW > > > from breaking. > > > > Right > > > > > Long story short, this should be good enough for the cases we actually can > > > handle? What am I missing? > > > > I am not sure I follow. My point is that I fail to see any added value > > of the check as it doesn't prevent the race (it fundamentally cannot as > > the page can be poisoned at any time) but the failure path doesn't > > put_page which is incorrect even for hwpoison pages. > > Sorry, I have something to say: > > I have noticed the ref count leak in the previous topic ,but I don't think > it's a really matter. For memory recovery case for user pages, we will keep one > reference to the poison page so the error page will not be freed to buddy allocator. > which can be checked in memory_faulure() function. So what would happen if those pages are hwpoisoned from userspace rather than by HW. And repeatedly so? -- Michal Hocko SUSE Labs