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 55016C433F5 for ; Tue, 2 Nov 2021 03:51:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B327560FC2 for ; Tue, 2 Nov 2021 03:51:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B327560FC2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 36063940016; Mon, 1 Nov 2021 23:51:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 30FB3940014; Mon, 1 Nov 2021 23:51:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D7FE940016; Mon, 1 Nov 2021 23:51:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id 0E05F940014 for ; Mon, 1 Nov 2021 23:51:32 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B52AD1843914D for ; Tue, 2 Nov 2021 03:51:31 +0000 (UTC) X-FDA: 78762615582.08.1ECB330 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id D486350000B0 for ; Tue, 2 Nov 2021 03:51:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=AB5n3/LuEh2928VCurg1CoaRmnjr3rvLQBzfgJuYk64=; b=i2B3uaOzl6E5PPWgRrD2R1JSQK boSK3XI1+/V7bOV7N3LIsuD0VoBv42Kd45inktYeYsqX7H710YuXIgV141GWah6a0ScHomeRewpiN 2wClGB8Ky50+APo0v/J0ziL29R+UgoQpPOS41KgURhjbPMjGoU1BzQlaMDMPKO7GGrZUp8fjB5YrK d+lsNIqbYtz+sLmfFyA1EM7DB2qdZ2jC8TDRm9+iD2cCsf75hc898ywJ8CDRTZOh7E5ZLHALPiSZJ +NwNpCO7r0Kj2zmMVyvCoEK/nSdzR3SJixmSy0ghCKvBzMwaD4/9PBMVvZjp7T9vE9QRrqdc/D81E LTrLljBQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mhknW-004E5Z-Rh; Tue, 02 Nov 2021 03:49:43 +0000 Date: Tue, 2 Nov 2021 03:49:18 +0000 From: Matthew Wilcox To: Yang Shi Cc: Jue Wang , Hugh Dickins , Andrew Morton , "Kirill A. Shutemov" , Linux FS-devel Mailing List , LKML , Linux MM , HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+jIOebtOS5nyk=?= , Oscar Salvador , Peter Xu Subject: Re: [v5 PATCH 6/6] mm: hwpoison: handle non-anonymous THP correctly Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: D486350000B0 X-Stat-Signature: aweft95d6n8jx56mm1suigisqwp9i6zg Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=i2B3uaOz; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam02 X-HE-Tag: 1635825083-8752 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 Mon, Nov 01, 2021 at 01:11:33PM -0700, Yang Shi wrote: > On Mon, Nov 1, 2021 at 12:38 PM Jue Wang wrote: > > > > A related bug but whose fix may belong to a separate series: > > > > split_huge_page fails when invoked concurrently on the same THP page. > > > > It's possible that multiple memory errors on the same THP get consumed > > by multiple threads and come down to split_huge_page path easily. > > Yeah, I think it should be a known problem since the very beginning. > The THP split requires to pin the page and does check if the refcount > is expected or not and freezes the refcount if it is expected. So if > two concurrent paths try to split the same THP, one will fail due to > the pin from the other path, but the other one will succeed. No, they can both fail, if the timing is just right, because they each have a refcount, so neither will succeed.