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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 6344EC43461 for ; Tue, 8 Sep 2020 11:43:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C13482098B for ; Tue, 8 Sep 2020 11:43:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="LRkfQQ8y" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C13482098B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 16AD26B0002; Tue, 8 Sep 2020 07:43:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 11BB56B0037; Tue, 8 Sep 2020 07:43:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0303F6B0055; Tue, 8 Sep 2020 07:43:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0247.hostedemail.com [216.40.44.247]) by kanga.kvack.org (Postfix) with ESMTP id E261D6B0002 for ; Tue, 8 Sep 2020 07:43:51 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9C29C1E1E for ; Tue, 8 Sep 2020 11:43:51 +0000 (UTC) X-FDA: 77239709862.29.error33_040ca30270d4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 6CB8818086CDA for ; Tue, 8 Sep 2020 11:43:51 +0000 (UTC) X-HE-Tag: error33_040ca30270d4 X-Filterd-Recvd-Size: 3798 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Sep 2020 11:43:51 +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=OSVXaZ7xzAGl2y+0kyr1xPePoywMfRGlGnRHQW50WBQ=; b=LRkfQQ8yd07Ax6ojzKhfHj7+0A FTi44s8/UGMuRw82gtO8hdQHFqCf2bzBGN9sMV6OoyMqY7tGLMQgr/2ZR261dJQwQzt0V244x5wIE 87dPrBo1GLe0NP/MRZTu4cuX+bbCj3qcabyq91YmfpvAWezxrztATWfKbS/5bvFQdZXQMLubauv+Y g03mML64IJUg7HVM5QVS/qY16Ae/S2Adys/l28GgaBecNaV5y0bdy7948yiqiZbBdv/G0isiJMBB/ VRXeMhLpPS80RgZVN3e7BacR2RsXsY4UIt8LF64P8v7qADDseQrTeWc171yhVBxDkldyEZ14ow1tf qDMS+w0w==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFc24-0001RH-GR; Tue, 08 Sep 2020 11:43:28 +0000 Date: Tue, 8 Sep 2020 12:43:28 +0100 From: Matthew Wilcox To: "Kirill A. Shutemov" Cc: Christoph Hellwig , darrick.wong@oracle.com, david@fromorbit.com, yukuai3@huawei.com, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: Splitting an iomap_page Message-ID: <20200908114328.GE27537@casper.infradead.org> References: <20200821144021.GV17456@casper.infradead.org> <20200904033724.GH14765@casper.infradead.org> <20200907113324.2uixo4u5elveoysf@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200907113324.2uixo4u5elveoysf@box> X-Rspamd-Queue-Id: 6CB8818086CDA X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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, Sep 07, 2020 at 02:33:24PM +0300, Kirill A. Shutemov wrote: > On Fri, Sep 04, 2020 at 04:37:24AM +0100, Matthew Wilcox wrote: > > Kirill, do I have the handling of split_huge_page() failure correct? > > It seems reasonable to me -- unlock the page and drop the reference, > > hoping that somebody else will not have a reference to the page by the > > next time we try to split it. Or they will split it for us. There's a > > livelock opportunity here, but I'm not sure it's worse than the one in > > a holepunch scenario. > > The worst case scenario is when the page is referenced (directly or > indirectly) by the caller. It this case we would end up with endless loop. > I'm not sure how we can guarantee that this will never happen. I don't see a way for that to happen at the moment. We're pretty careful not to take references on multiple pages at once in these paths. I've fixed the truncate paths to only take one reference per THP too. I was thinking that if livelock becomes a problem, we could (ab)use the THP destructor mechanism somewhat like this: Add [TRANSHUGE_PAGE_SPLIT] = split_transhuge_page, to the compound_page_dtors array. New function split_huge_page_wait() which, if !can_split_huge_page() first checks if the dtor is already set to TRANSHUGE_PAGE_SPLIT. If so, it returns to its caller, reporting failure (so that it will put its reference to the page). Then it sets the dtor to TRANSHUGE_PAGE_SPLIT and sets page refcount to 1. It goes to sleep on the page. split_transhuge_page() first has to check if the refcount went to 0 due to mapcount being reduced. If so, it resets the refcount to 1 and returns to the caller. If not, it freezes the page and wakes the task above which is sleeping in split_huge_page_wait(). It's complicated and I don't love it. But it might solve livelock, should we need to do it. It wouldn't prevent us from an indefinite wait if the caller of split_huge_page_wait() has more than one reference to this page. That's better than a livelock though.