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 AA897C433EF for ; Wed, 13 Oct 2021 03:41:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4F53F604DC for ; Wed, 13 Oct 2021 03:41:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4F53F604DC 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 BBEBE6B006C; Tue, 12 Oct 2021 23:41:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B6EE96B0071; Tue, 12 Oct 2021 23:41:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A36606B0072; Tue, 12 Oct 2021 23:41:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id 941F36B006C for ; Tue, 12 Oct 2021 23:41:52 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 364B42C590 for ; Wed, 13 Oct 2021 03:41:52 +0000 (UTC) X-FDA: 78690015264.16.312F8CE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf04.hostedemail.com (Postfix) with ESMTP id D921F50000AE for ; Wed, 13 Oct 2021 03:41:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634096511; 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=P9QQpHMzPqOGAUAgrM92CQtjCHKsEXKEq2E7CGbFGTs=; b=FCGuTLXqaKbORxt68jvecb+cOY8K6lYUomVBsY6I8aRuTVdXAKYOVV/9hZcWslkth17u8h mwHnlIVuwKrF+bAdDP5E9Zugx4bOpR9c1P6UuA/1VYkyfekeUMozPbgfhzR3ti4/ok/5Vy f3S0sZsWjgaGRGIbtbpJhLWDt0U4CV0= Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-292-bGTNZomFOpKNOJBYxLmbdw-1; Tue, 12 Oct 2021 23:41:50 -0400 X-MC-Unique: bGTNZomFOpKNOJBYxLmbdw-1 Received: by mail-pj1-f70.google.com with SMTP id my5-20020a17090b4c8500b001a0bf4025c1so1014369pjb.8 for ; Tue, 12 Oct 2021 20:41:49 -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=P9QQpHMzPqOGAUAgrM92CQtjCHKsEXKEq2E7CGbFGTs=; b=L55fhsaQ7tDBnGCb9hQkgrivMthetEg94F3fDfvpTUx+ZnZ010A60Be7eMFHPsbVGw y8Fe7fu9tNKmGGzB5QpvGzQ5KTj2CRhWWpp72h8eXEnKc+asU/s7Xl/6CYDr2Gu2sJ3X E36Ucsa+wjCJQyeVPOqCcMQIz3NZRNhqQz5gJkSovrJSumBje7p706wL0Ee/YmV5DnGD rG/glRWNrJ00l5MfOUze+wH9uVvFZZAIyat+QBX2dAynBjwngqOT6PbVDEipBELHQcZv MRgGVqWWKzCm4JnO4gGWV7T6ulMjM0hk+953cZ9/ZCz5YqlpLLSM/hpSr6LdZdKmlU9C KrHA== X-Gm-Message-State: AOAM531jBV+QYBnf3nFwTO1GbIyctfdUtOU6IDmb4EGo84RZ1TrzoXzY accBadVhXwNMGvimOw3xqU62UlOgBgFiKCqjNahUZy3Rk54yjc6/wM5TcYv65isogdcqukdOYcW 7BmM6GIKGAvA= X-Received: by 2002:a62:1b92:0:b0:3eb:3f92:724 with SMTP id b140-20020a621b92000000b003eb3f920724mr35757522pfb.3.1634096508717; Tue, 12 Oct 2021 20:41:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwTsSrRU70L24zyehCxjIOcnI0fW5T3TZ6w598G0eEchUTE4T6Elozl+lg8k4lS16yUUCus6A== X-Received: by 2002:a62:1b92:0:b0:3eb:3f92:724 with SMTP id b140-20020a621b92000000b003eb3f920724mr35757499pfb.3.1634096508378; Tue, 12 Oct 2021 20:41:48 -0700 (PDT) Received: from t490s ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id v13sm12837847pgt.7.2021.10.12.20.41.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 20:41:47 -0700 (PDT) Date: Wed, 13 Oct 2021 11:41:40 +0800 From: Peter Xu To: Yang Shi Cc: HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+jIOebtOS5nyk=?= , Hugh Dickins , "Kirill A. Shutemov" , Matthew Wilcox , Oscar Salvador , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Subject: Re: [v3 PATCH 2/5] mm: filemap: check if THP has hwpoisoned subpage for PMD page fault Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: D921F50000AE X-Stat-Signature: u1nqzrj7jsy18o7jwuc7admexnwqawy5 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FCGuTLXq; spf=none (imf04.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam06 X-HE-Tag: 1634096511-813649 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 Tue, Oct 12, 2021 at 08:27:06PM -0700, Yang Shi wrote: > > But this also reminded me that shouldn't we be with the page lock already > > during the process of "setting hwpoison-subpage bit, split thp, clear > > hwpoison-subpage bit"? If it's only the small window that needs protection, > > while when looking up the shmem pagecache we always need to take the page lock > > too, then it seems already safe even without the extra bit? Hmm? > > I don't quite get your point. Do you mean memory_failure()? If so the > answer is no, outside the page lock. And the window may be indefinite > since file THP doesn't get split before this series and the split may > fail even after this series. What I meant is that we could extend the page_lock in try_to_split_thp_page() to cover setting hwpoison-subpage too (and it of course covers the clearing if thp split succeeded, as that's part of the split process). But yeah it's a good point that the split may fail, so the extra bit seems still necessary. Maybe that'll be something worth mentioning in the commit message too? The commit message described very well on the overhead of looping over 512 pages, however the reader can easily overlook the real reason for needing this bit - IMHO it's really for the thp split failure case, as we could also mention that if thp split won't fail, page lock should be suffice (imho). We could also mention about why soft offline does not need that extra bit, which seems not obvious as well, so imho good material for commit messages. Sorry to have asked for a lot of commit message changes; I hope they make sense. Thanks, -- Peter Xu