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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E499FC54791 for ; Wed, 13 Mar 2024 15:27:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38DA280036; Wed, 13 Mar 2024 11:27:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3168B940010; Wed, 13 Mar 2024 11:27:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B7E580036; Wed, 13 Mar 2024 11:27:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 08885940010 for ; Wed, 13 Mar 2024 11:27:37 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D5E194088F for ; Wed, 13 Mar 2024 15:27:36 +0000 (UTC) X-FDA: 81892395312.03.D849013 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf25.hostedemail.com (Postfix) with ESMTP id AFBB8A0011 for ; Wed, 13 Mar 2024 15:27:34 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rCMHhqmA; dmarc=none; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710343655; a=rsa-sha256; cv=none; b=ThrGAVHHvWXmmSMn+ziAbs/3OUrkSJQkoF6NIAoVvH4VZvVcNTyAPFjor3YIIhTrn6rTi/ PEuT02nEbgwiNxmuh9IlTjbM1VXx4X5F3UJorrmx1rwNZKe8Orpw1ehyF6dFEuWX5gKBXN wk+FJeRJMiSK0gpwU2nu4XboEIyxn4A= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rCMHhqmA; dmarc=none; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710343655; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JZTTX1lzt0/hafJHgYp2JSU1P5vs+qQV68xvvxh3r1U=; b=M6pyGE27GZn9L1S8kp5iuH/aJO/pH+n5abcM2iClX9KF/ZD31DSlVdaqez0LzfO7R7Gdk7 n9BXbZuCnqu7HFbNII7UPB+/W/AeggZHMnGALtU21/YP8RHguSyzd/STugq21ERLuOVBAl VMUc9sLimcmVWBD6qIMZVrvWRuK8XLI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=JZTTX1lzt0/hafJHgYp2JSU1P5vs+qQV68xvvxh3r1U=; b=rCMHhqmApBUX7pe5qObSAwGQnP qeNN5DALK7fK7VHfN0Mc8A9KpU2Kv7/OdgKYO1iYL0CBcXAxL0pZirutYICqWIgVYYAj6WX6fZoKq wmsNlAd5krpr5tNJVYSMZ7iSQ6DAIsSricfVl6650a6WutbCv9YN10ZnrYF+MxgW5MFsa0QGB+RAX XyeJabqIP2JNxM2hQMNUpjVKivEzV+fwObiyZEYGLMVwBahjMDpgYyxQ67+gITSJ33iGBqm0djiLC bz7bIysK6GO/Z83NOcVPnumduM7yZEewGhYigjeB5PasQBFF4GLuiViYdjzZkEJHANOE+VJP6Jr1Q Y9W1UDfA==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rkQVw-00000005fje-0NEH; Wed, 13 Mar 2024 15:27:32 +0000 Date: Wed, 13 Mar 2024 15:27:31 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Jane Chu , linux-mm@kvack.org, John Hubbard Subject: Re: Splitting pinned folios Message-ID: References: <57c9e228-9aca-4da6-a714-f175f053ff50@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <57c9e228-9aca-4da6-a714-f175f053ff50@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: AFBB8A0011 X-Stat-Signature: km1wi8y9uk3q5tjos563d7jwggbe1bxw X-HE-Tag: 1710343654-925918 X-HE-Meta: U2FsdGVkX1/3ngbjs8y6gnny9s9jMmIAaG7m82Hh6Wyigsa4DC7UMFBJsBGBkVOUWeUnoXkEHn9K88BWGt7thT5FU27g7e8OdHs7nV2A/7uGBWi5efa5im0cYaqyVUU1KwWciLyFIt3whw1tdiF11Zl0uX1aH5iUUwgDgVvcyOSGoPkTAGSu7oeMCxzAbvg2R3K+eAOaBjQ53sOVQXEcPxJ/5Y2N7xx9tqqtF5KmEpciwrV9+ZdfQaLaSz4NjoUSoRRfeJQDrLdcIfiU6Mw4xwHynMbG5vZY+OCzl32WOFPBO5ZCJ1InUSMsGppRuv3v2zbxDTg2DEXc/5sq120d+R8ttGDpH5Z0ApYUjZ5Wcpx9uaoBLnUgCJn+WJbCp2sqUF0sXabmsrxlaAzjxl0V18xIy+vdugvZj+cnbIBjdn14FmgftWavi31V2fiAIhaT9doaBfuoZebUn4ADT7mMLBM5hWTt5PVDKVho/lYoDMT9w12p+tw6xfb8MFKUka/mfXTfEF9KORZZhhc1zOCzgG3qt8vtMWRrzzOWTzuTVNvxCO6PRrM554haaYRdhrvOWjWya1wsghI4TqWWDv4BDJQf9lvQPOulxd2Iz37tQIzxOZ7h310xBslZZUKw7pKXWmxVVEAw8eWOKJFIYZFcHS/ig3d9G2+fkYX2KQAsLMeqRyZYgnZD6kOgOPN60kzvqOCw6lQl96boPAiHlE8neDc6aXuGcfqhLYyLJ2rLKuGqVR8nWLSmR96QTy5Idxz2ioKujN/sW3JnahBPQaIlcgv0SVAXgrbEeljobp/vQLh7A9X6DHlE08dMYmcSSGhe+So9lqGnnyAPiTW34f+eRXNpNhRmvG63IHSA6OdcK3i5D+wxndxl3VWk5D+d7CtosVVxx610hZt8hVPdtV2qggeWMLT1MXqVMEfjdf1I9776RT9CEKzfV+XLQLv+53AXwgDLZSR7yioDthoVpMy 9Hfu6xj0 R2GbrLbGxCYUeM912C7kPiiJ5/cB5YWXaNzqbVJQ39GB2x6bzGn8RbeIOZ1eFvsr51RtS56ImyXW4DTLli5LlXIdgcF3e8WCIGHCrVdSof3mmQHTOwqBJNB6XQffnY8GrLyk6y2tI5u7OPJssKpr3d8AWDmCoK8C/PRkI 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: List-Subscribe: List-Unsubscribe: On Wed, Mar 13, 2024 at 10:20:46AM +0100, David Hildenbrand wrote: > On 13.03.24 04:16, Matthew Wilcox wrote: > > On Tue, Mar 12, 2024 at 06:23:43PM -0700, Jane Chu wrote: > > > I noticed this recently > > > > OK, this is entirely different, so I'm going to start a new thread ;-) > > > > >  * GUP pin and PG_locked transferred to @page. Rest subpages can be freed if > > >  * they are not mapped. > > >  * > > >  * Returns 0 if the hugepage is split successfully. > > >  * Returns -EBUSY if the page is pinned or if anon_vma disappeared from under > > >  * us. > > >  */ > > > int split_huge_page_to_list(struct page *page, struct list_head *list) > > > { > > > > > > I have a test case with poisoned shmem THP page that was mlocked and > > > > > > GUP pinned (FOLL_LONGTERM|FOLL_WRITE), but the split succeeded. > > > > I'm going to blame John for this! > > The description is wrong. Whoever calls split_huge_page_to_list() must hold > a folio reference. > > That folio reference will be transferred to @page (not the head page) once > split. So @page can be used by the caller after the split succeeded. > > > > There's no reference to pincount > > anywhere in huge_memory.c, so I have no clue how this comment is even > > Each pincount increment/decrement must be paired with a folio refcount > increment. Therefore, no pincount checks are required. I'd forgotten that. Any GUP pin will force failure of split. So I don't know what Jane is seeing. memory_failure() tries to split THPs and outputs an error if it can't. It doesn't try to handle them. It probably should, but that's a subject for a different thread. > In essence: we expect on a folio after completely unmapping it: > * 1 reference from the caller of split_huge_page_to_list() > * pagecache: 1 reference per subpage from the pagecache * 1 reference if the folio has private data (thank you, bufferheads) Oh. Is that the bug? can_split_folio() doesn't know that. This usually isn't a problem because, eg, truncate_inode_partial_folio() will remove the private data before calling split_folio(). But memory-failure doesn't know about that rule ... No, that's not it. shmem doesn't use the folio private flag. It's still a bug, but it's not Jane's bug. Jane, can we have the results of calling dump_page() on the page? > Reading "I have a test case with poisoned shmem THP page that was mlocked > and GUP pinned (FOLL_LONGTERM|FOLL_WRITE), but the split succeeded."