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 BAE14CD1284 for ; Fri, 5 Apr 2024 03:42:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BF9B6B00D6; Thu, 4 Apr 2024 23:42:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 348636B00D7; Thu, 4 Apr 2024 23:42:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E9A66B00D8; Thu, 4 Apr 2024 23:42:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id F12BC6B00D6 for ; Thu, 4 Apr 2024 23:42:52 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A2F9B141084 for ; Fri, 5 Apr 2024 03:42:52 +0000 (UTC) X-FDA: 81974081784.17.270149C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 354D41C0012 for ; Fri, 5 Apr 2024 03:42:50 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BiUkNHHy; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712288571; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GdrhCCARPBrZ0BeKtdp/2ujXMzoo79cn9UM+NnhXtOc=; b=POU+/QhEcKUrHRxnp8INseZvjHPGyE6P5fR4TFHwoV2nGx3t1V4hEvl2BIz+d2DnpvkxPD /xAjSAUD7QwL586iRRewteBGDZpCmJOjUmtB2Hg6VB6d6IITCnDCq5l8Hk5ZRJFvP7Sud+ 2Oe64t2AMcKWNrIGnBWqVCHDA8+JFDI= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BiUkNHHy; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712288571; a=rsa-sha256; cv=none; b=337wrglGg4SGYFidoXQNX/J/SMT6mHoHAItRc7iOfJo3QprJhtjcd4thG00pQxqf9H5ZO+ UOjCbLdvNyOpzjS412XWDA7CkPvlm8mS7YxhFvYV3PZ62TH/Rpg2B3n10rmU1zfo2xjAdk wbuexVcWWIeoUbO+xR1WCsPFLkOTDV0= 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=GdrhCCARPBrZ0BeKtdp/2ujXMzoo79cn9UM+NnhXtOc=; b=BiUkNHHyRubp6ozZi9ENrekA++ yQOYyCgQCr+0Q/os9bqKoxPFMAbMbxNG6VK3KHRf8d5VUDBhQK2d5+yLPqCJMWNEi9A5Np7eRoKb/ DBIczCaUGUP4hAyXgNPEyzczgbll9TcpKdoOXd+GyloI5jB85moOyOiFUm+70vucequYLSfNiLsla ICHIK+mjkvj8DeY0YHxe+itsx+qAUbmLmj20OriZ1nYpu04O7xrCKDWqCrYQ3Hc+/LOOT/Nc628nG LvjTUu+/BGPTLzt1GjKxZsMEhtwzjcQrf4qkNfEQ7hNy60oBEO1E+Qkxv1rZfhKyXuJ6e19bJTSD+ hTAIPaBg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rsaTY-00000009Y3j-2mgL; Fri, 05 Apr 2024 03:42:48 +0000 Date: Fri, 5 Apr 2024 04:42:48 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Janosch Frank , Claudio Imbrenda , Gerald Schaefer , Thomas Huth Subject: Re: [PATCH v1 0/5] s390: page_mapcount(), page_has_private() and PG_arch_1 Message-ID: References: <20240404163642.1125529-1-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240404163642.1125529-1-david@redhat.com> X-Rspamd-Queue-Id: 354D41C0012 X-Rspam-User: X-Stat-Signature: cbarpsn7b63footqpd38ze4nsxqppfb5 X-Rspamd-Server: rspam01 X-HE-Tag: 1712288570-762708 X-HE-Meta: U2FsdGVkX19Dn8p/ryC7WdmO/f3OzjSGVP0UOQBHjb32Yu1ozEPIX5cUyOheHj0fdmgwTIXCIEbfaAwwqU1IfsSXBNAGSyTqlRMuJGwgRNNg3AxwOfJoejh/tEXJXn/uhKxwN0zhLlOUQZa2Y4oGNiyLVofy9njLUBl6TAcqazqQnGZv9ADbiWAkIenzBf3YXjzzY6e19KEBlCSHrnR0Oku8yysf4W9vXG9F6a8i1IF94qHcWXDKn//bq+tylcPug2dotKDbR/G6yBeUuzQiJnSvMH5SRgz16RBM7QeIQ8xX1kZr+hCspxM0hvmetbhmtKbGypoLpEhVkrkAd1O1zhjUzPR03f8+VV6d3wvAbbqWe3FiWhUtTWC+zvD8/tCm0DBGrMxsIjRZmCtSWHdSsM9Tfw7zp9MI+YyZ/q04m/DKXQVnDey5Piboy7h9LMH2Ih7EP63iyfNdQUI0FX2PhkI8/NfB3VovzR6CSmYxD4YCXtFPTOjXWrdPF+v+8GoDCc4n81rY3Q8H2iqzEPYOWyeyKahyk1gUBu9wi/vDjuMkBl3/YUkCik3wTpdz2sw2yhPBSGazneU2GioLNUFCkDy0YzZvqsGvVDGfbqOiw6lDLR8SSEDPHjom7Cr39S/ZxXdhrDqhp8dAeXGz5wzyfZPWlHCcDcwJosa5JY0KfuWkExoztZjofgHn68FLf0PFV/pchBsVe9jfrr4bzcAX7SA4qkfF0NbpqVuPan9qYJTX3o7K3EVylJPkFgwpnE//oDgugLR2esR+C6QHlFr4prlMfU+XUsMlbW0C+GF4+VnQgGfw57PqeonH/AYqUJy3tR4d+KAc76vyvjZ3AniKO9wt4uzQ5cRXCtjxXoYEJLEuo2WTfmW8ESiI2b9mskYHSWejpgghGFA= 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 Thu, Apr 04, 2024 at 06:36:37PM +0200, David Hildenbrand wrote: > On my journey to remove page_mapcount(), I got hooked up on other folio > cleanups that Willy most certainly will enjoy. > > This series removes the s390x usage of: > * page_mapcount() [patches WIP] > * page_has_private() [have patches to remove it] > > ... and makes PG_arch_1 only be set on folio->flags (i.e., never on tail > pages of large folios). > > Further, one "easy" fix upfront. Looks like you didn't see: https://lore.kernel.org/linux-s390/20240322161149.2327518-1-willy@infradead.org/ > ... unfortunately there is one other issue I spotted that I am not > tackling in this series, because I am not 100% sure what we want to > do: the usage of page_ref_freeze()/folio_ref_freeze() in > make_folio_secure() is unsafe. :( > > In make_folio_secure(), we're holding the folio lock, the mmap lock and > the PT lock. So we are protected against concurrent fork(), zap, GUP, > swapin, migration ... The page_ref_freeze()/ folio_ref_freeze() should > also block concurrent GUP-fast very reliably. > > But if the folio is mapped into multiple page tables, we could see > concurrent zapping of the folio, a pagecache folios could get mapped/ > accessed concurrent, we could see fork() sharing the page in another > process, GUP ... trying to adjust the folio refcount while we froze it. > Very bad. Hmmm. Why is that not then a problem for, eg, splitting or migrating? Is it because they unmap first and then try to freeze? > For anonymous folios, it would likely be sufficient to check that > folio_mapcount() == 1. For pagecache folios, that's insufficient, likely > we would have to lock the pagecache. To handle folios mapped into > multiple page tables, we would have to do what > split_huge_page_to_list_to_order() does (temporary migration entries). > > So it's a bit more involved, and I'll have to leave that to s390x folks to > figure out. There are othe reasonable cleanups I think, but I'll have to > focus on other stuff. > > Compile tested, but not runtime tested, I'll appreiate some testing help > from people with UV access and experience. > > Cc: Matthew Wilcox (Oracle) > Cc: Heiko Carstens > Cc: Vasily Gorbik > Cc: Alexander Gordeev > Cc: Christian Borntraeger > Cc: Sven Schnelle > Cc: Janosch Frank > Cc: Claudio Imbrenda > Cc: Gerald Schaefer > Cc: Matthew Wilcox (Oracle) > Cc: Thomas Huth > > David Hildenbrand (5): > s390/uv: don't call wait_on_page_writeback() without a reference > s390/uv: convert gmap_make_secure() to work on folios > s390/uv: convert PG_arch_1 users to only work on small folios > s390/uv: update PG_arch_1 comment > s390/hugetlb: convert PG_arch_1 code to work on folio->flags > > arch/s390/include/asm/page.h | 2 + > arch/s390/kernel/uv.c | 112 ++++++++++++++++++++++------------- > arch/s390/mm/gmap.c | 4 +- > arch/s390/mm/hugetlbpage.c | 8 +-- > 4 files changed, 79 insertions(+), 47 deletions(-) > > -- > 2.44.0 >