Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1678354pxb; Thu, 7 Oct 2021 12:41:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxcyjO+UKwHU31Zp8ICIjiUrPGGorwAnIewzV9EkzBiYsrpbgiedNBaL1IdFO75l7tOBGUr X-Received: by 2002:a17:90a:2a0d:: with SMTP id i13mr6853968pjd.166.1633635701979; Thu, 07 Oct 2021 12:41:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633635701; cv=none; d=google.com; s=arc-20160816; b=YX7S1IUrH9b/ur1Xee4F9oiVTpOI/ctGuFkxrjO1K3xGOUIoyGbevvS5E1+v8wnChM ipEswQ+/mjCSFJgiJ/YcFI4NLoP6p+FKOcXI1Kjrb6mZsNFbS5ecew8kRthMuFU+dQdl W16jx3RtBaLaKMi6YYV6cRe9sAtH7Xpr2fGpShGXue8vDTIWURlwbP/DawmmK/tFbwT7 XKM1KdQ0zErxeLVFPB6NqIJOfhzs8CVTch6FwuShB93EScdK63OElo6x1HCvkQXewI2+ se4XluFpP0RVU3Tn2a+9IdHycvOjFZeEh6acZrauHd7k85SAvITNi0RBTQniTPmiMcr6 h5Fg== 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=2f7G2WKXlw2VVvH2sPBaPxflHdQi/DqI+SXI7iCozBY=; b=Y/8yuYOkAMxjXK77hRUd/W1r6uOVhnWnjtrRjdSql3gbKfi7tdFQWDji0xHuDHcqok pWZ4foRFaIuEEy8kv/CVoGAz5DtJH5XdoxmJ0wpuUNc/zktAcLho60zCFOK12VdT1R1x yeRa8495QJHSDLs2jL20Vs6RgnG7X9TTlu1NpSmfcTrjzd3+F6s/wwpo+UptWoKsJvLy kpJLIj9/my8zDS6ypfYsnGxapuZ+v0hLC3c/ruWUkUzyqp1MmPcR0KlR5ItJ1/a3AKPh ++f9oTjp3eYk0ThxId9UM0dY/mRnO4SlOonRZT5khFiJyQELJi3OAyqZhmeDo1GnAVo9 UGMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dqnJL0pr; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r187si229943pgr.602.2021.10.07.12.41.29; Thu, 07 Oct 2021 12:41:41 -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=@redhat.com header.s=mimecast20190719 header.b=dqnJL0pr; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242481AbhJGQIg (ORCPT + 99 others); Thu, 7 Oct 2021 12:08:36 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:49969 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241776AbhJGQIe (ORCPT ); Thu, 7 Oct 2021 12:08:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633622800; 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=2f7G2WKXlw2VVvH2sPBaPxflHdQi/DqI+SXI7iCozBY=; b=dqnJL0prfXgWYQIQoK/pU5YgSeb/v2fbfGLnAyF30AUtE6Vh8nW9umXp16LNULAHUBhXTe szrw+fDeRgcvblFVKz2Okun4JL4ZxYERgxNSNL8n+Egx8+zNIKhRLblZCTjbfy6g8Haqr6 lEqj66akDoAvrADCJRNAfsj3ha+Y8X4= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-600-9WYIRdrlPzCB0_bTyCZHJQ-1; Thu, 07 Oct 2021 12:06:38 -0400 X-MC-Unique: 9WYIRdrlPzCB0_bTyCZHJQ-1 Received: by mail-qk1-f200.google.com with SMTP id k3-20020a05620a414300b0045e623cd1afso5542647qko.20 for ; Thu, 07 Oct 2021 09:06:37 -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=2f7G2WKXlw2VVvH2sPBaPxflHdQi/DqI+SXI7iCozBY=; b=RJDlXKkKV/CQ/Nk61GGCM/nUj+o+t9TJwhMJ6XSPe/o4iMwypa/AMXZF9S4y9ONeoC 7+qD7MYfpLUCmC92xIFkGoCALT/VOzsOM3cNbewGoqUwFes1ctWLfUMLBYOOGxHhpUgt DoALtLJ1G9Xpa8UEDs8Ckb1Zt2GVr3yXpwmeJWadmk5bzIj+LaaQCOMrZgoczXap0RSW 4Njx5KoX/xkf449H929tIR11DGixGYigDE9c7LjPZ1V0Ru4bcf8jmA2Bv4faMzdEZGX/ K5eGiyyxsV9ATxYz1iWawibaS7VspY9FwKlyu7NAYFhGatumFQtUVehEfbDv/9Mm6t3M ItNg== X-Gm-Message-State: AOAM531yT/lnHfl5n8eAT6JVkUAjWtYlEug5lCRSgnvI+9puSsA2Y1A6 bj7UwU/25/lzX6SDFGBkVTpODXEfWx7FVDrt5INKFWU+4WEjeHGinS8OZx86s3gfVW7oLHVvxzz kIzPuMQeMDolxvav4CURU4Ctn X-Received: by 2002:a05:622a:316:: with SMTP id q22mr5879946qtw.225.1633622797389; Thu, 07 Oct 2021 09:06:37 -0700 (PDT) X-Received: by 2002:a05:622a:316:: with SMTP id q22mr5879906qtw.225.1633622797114; Thu, 07 Oct 2021 09:06:37 -0700 (PDT) Received: from t490s ([2607:fea8:56a2:9100::bed8]) by smtp.gmail.com with ESMTPSA id a16sm13820149qkn.16.2021.10.07.09.06.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Oct 2021 09:06:36 -0700 (PDT) Date: Thu, 7 Oct 2021 12:06:34 -0400 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: <20210930215311.240774-1-shy828301@gmail.com> <20210930215311.240774-3-shy828301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 06, 2021 at 04:57:38PM -0700, Yang Shi wrote: > > For example, I see that both unpoison_memory() and soft_offline_page() will > > call it too, does it mean that we'll also set the bits e.g. even when we want > > to inject an unpoison event too? > > unpoison_memory() should be not a problem since it will just bail out > once THP is met as the comment says: > > /* > * unpoison_memory() can encounter thp only when the thp is being > * worked by memory_failure() and the page lock is not held yet. > * In such case, we yield to memory_failure() and make unpoison fail. > */ But I still think setting the subpage-hwpoison bit hides too deep there, it'll be great we can keep get_hwpoison_page() as simple as a safe version of getting the refcount of the page we want. Or we'd still better touch up the comment above get_hwpoison_page() to show that side effect. > > > And I think we should set the flag for soft offline too, right? The I'm not familiar with either memory failure or soft offline, so far it looks right to me. However.. > soft offline does set the hwpoison flag for the corrupted sub page and > doesn't split file THP, .. I believe this will become not true after your patch 5, right? > so it should be captured by page fault as well. And yes for poison injection. One more thing: besides thp split and page free, do we need to conditionally drop the HasHwpoisoned bit when received an unpoison event? If my understanding is correct, we may need to scan all the subpages there, to make sure HasHwpoisoned bit reflects the latest status for the thp in question. > > But your comment reminds me that get_hwpoison_page() is just called > when !MF_COUNT_INCREASED, so it means MADV_HWPOISON still could > escape. This needs to be covered too. Right, maybe that's also a clue that we shouldn't set the new page flag within get_hwpoison_page(), since get_hwpoison_page() is actually well coupled with MF_COUNT_INCREASED and all of them are only about refcounting of the pages. -- Peter Xu