Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp471278pxy; Wed, 5 May 2021 06:42:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxztXNRG/tq55u/TlQQ6FGVpYn8FzzQvxK3/wHUwTpirk5ev3+Vow7RD4sN/vwPtRmg83+k X-Received: by 2002:a17:90a:5148:: with SMTP id k8mr35219499pjm.1.1620222175727; Wed, 05 May 2021 06:42:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620222175; cv=none; d=google.com; s=arc-20160816; b=nwzfnt5nAZEKNuCMTl+II8QDZlzPm1JST8UQp826LPirZYy1IGwuY60xWerix+E7Uh iWcttv3q6XJNyNLB4mskmszAEHx3Um52cSX8bN2ADmmWFOneX1c09E1pFtkWZhQ4sOLw Rq6NZcCL7MNauZQzmhFH95Ay+o9DLuc8zyFJuMB8VrRZTL9IBr46MfM2qEsNPrrHmXdP hTcDkv708b61n2SXRqT/96tcDhfaiHbDDE+8RJVVy0qaDeOLWZG4VHepDh8PELgNH8P0 fvqFVIcyrGWN9XZ714DZhnqGB3gOr4luRLNGU65MK8i6UunqKYBdiQopzo2VRvukEL5f e2Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=CGLu3gLLUm9em9SOE5qtfKtO5dEYjOb/g2kUV6nMYNc=; b=xIuIHx0+o2pEMORTrikgY/HfT4SMnBkN1vIhswzqXKPwdwZfu8kvv533x1Eu0XaZXl BjZYRLeX0iWO+lvfqd3rafyeKEe7FJzMLybXZwlbLEoRRx1dveA9fpLY8bqF++pnzPp4 JRB98xNtMqdCvfhOG2fhZQKt9U4Yp9Txs68k7RzreRe8CmoqIUjLHtWSDPw49JnePbtX o+seytXHyfV6rjCE74fbrWdep/VYvGcWbxdWUGlb/VekIkAMDQ8j+Z1SM8aRDom/J/x3 BiORVZruEXgKmkbcWoGL1fw2B6GQKGYt85d+6DptQ9T5+O5qtvlZkmm3wZ2H4HPwuNTf iadA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=n6TZpPwG; 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=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q36si6712561pgl.469.2021.05.05.06.42.42; Wed, 05 May 2021 06:42:55 -0700 (PDT) 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; dkim=pass header.i=@suse.com header.s=susede1 header.b=n6TZpPwG; 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=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233574AbhEEN2k (ORCPT + 99 others); Wed, 5 May 2021 09:28:40 -0400 Received: from mx2.suse.de ([195.135.220.15]:52028 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231696AbhEEN2i (ORCPT ); Wed, 5 May 2021 09:28:38 -0400 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=1620221260; 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=CGLu3gLLUm9em9SOE5qtfKtO5dEYjOb/g2kUV6nMYNc=; b=n6TZpPwGis+vpxeyirf9mIIe9mAPXZkRzj2QcW0Hz5S8a6aERcTXnW0gWX6OjUmbWSvICg sOuW3IjuIvAXwuh4UEcJzAbeSDX+UINqNTBFrBFvHxCp2FfeWvlW5URegyu8k6matU4gWH gayQpGv9GqxKKNk/QMUP960Ni5k+AJQ= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id BE25DAE86; Wed, 5 May 2021 13:27:40 +0000 (UTC) Date: Wed, 5 May 2021 15:27:39 +0200 From: Michal Hocko To: David Hildenbrand Cc: 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 , Aili Yao , 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 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0710d8d5-2608-aeed-10c7-50a272604d97@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -- Michal Hocko SUSE Labs