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 171C0EB64DA for ; Fri, 30 Jun 2023 19:22:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A14E18E0046; Fri, 30 Jun 2023 15:22:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99D928E000F; Fri, 30 Jun 2023 15:22:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7EF428E0046; Fri, 30 Jun 2023 15:22:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6A7D38E000F for ; Fri, 30 Jun 2023 15:22:58 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2F5D41A0558 for ; Fri, 30 Jun 2023 19:22:58 +0000 (UTC) X-FDA: 80960386836.17.0929277 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf24.hostedemail.com (Postfix) with ESMTP id 2C85618001C for ; Fri, 30 Jun 2023 19:22:55 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=qrvgu39+; spf=pass (imf24.hostedemail.com: domain of hughd@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688152976; 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=UpA/3MkDA4Bbb6eJ6xeemnz64HxyzKE7wrEAQ570pfY=; b=VSxwoysbjtCyFPcfit6E5iZ9G68wkSSpQFYhRq+njLGN7tioBQch9p3TGGBRR5CCrBVcRw aBcKsINvBtrikzYhigJH4GgdaMIFdpt7sxmNB6SFK982SsDNdqKPX2Vf3K80VijH7ITTNv Hx2GRDD8ZXn4KC7anIqhrykjX4sp6io= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688152976; a=rsa-sha256; cv=none; b=uio2feMkHaTvN9hiKjYuyNycNkQzugiZAQ48MzghpNSqqr4WYWwnJ7xaOZOkZtU6QrJkqg ydQELd12Qhdjjw+bCAVfK/5M3+hN23SXtWmJNMWJploWpAQT3aRqK14DE+y9PX8oCWnoLE RhQXNLbghNWwARXBy7lr652IK3y+fyw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=qrvgu39+; spf=pass (imf24.hostedemail.com: domain of hughd@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-be30cbe88b3so2191034276.1 for ; Fri, 30 Jun 2023 12:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688152975; x=1690744975; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=UpA/3MkDA4Bbb6eJ6xeemnz64HxyzKE7wrEAQ570pfY=; b=qrvgu39+Pjzc0ty+cMKIrH7Eni71vn8ej746goZG1tt82sCTsmWg6sBEtMY5CYHkvc xclnmytvO77Jk7WZZk/il6ovWRv1QJV2T5YBR38m1fpA60DTf2h7Xd6BRbHgj9AvET1p tRCXjgGhJ6lxaDD/J1iU2O9lhqpC8W/NCc+eL3bbCVdX54HfuY4wUAcwYj6APMOTcz4G f66Hj1VDT8JxouLBXxbgSCkSfpv2cMeVkvsNVflvvYlmarJ0nMeAwtFB3YcpKUnimWJd M0kxVMaVqi4PmA2kSbzsqFbGlI4UBRtOwklt4JjwKtiq8VRHxGS9MYdDm87KrkMzPwwX AxHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688152975; x=1690744975; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UpA/3MkDA4Bbb6eJ6xeemnz64HxyzKE7wrEAQ570pfY=; b=Oz2za5jfsOSqwhVuoiUubXJbZ8xEYR4DB5jwBXLe2ajXR5SAvYOm365ojSNht2vbqq 6PNESZMvPdOlKEqXpWQ4lmduPySMb1dhssmximlobHy6wxHLjCkCvICL/90607cccGlS eBmi/rWyhvM4YhtKWwLYBFnPYd6KAx1rhlJ0EwGGvqMpttjifI3FtV/XtLqEL76dBBGX 2WxM/XINOdyPIBIHjBsNi0rdg4gcR8wW+c3aCw2oc1S1eu2QTYT9xLJFw5E3RV7VkT92 rQNMcgnUrH4Zx48N9Q+dpjlQ2VwUNGlEbZVZfS1SqYjJKJnXefetmdM5uwCATidjf+0n ZsVQ== X-Gm-Message-State: ABy/qLZDeuqLQ2dlpovql6HEXroOXnHrfHVtRhkCax0hDMbvlCHJR/ib az0zg2mk1XzuSREN1+GkgJYfbQ== X-Google-Smtp-Source: APBJJlEeRudcWa5iit7A1oAKHz4BndX5rtVzOZ4hnmAKD3Z6cXWQLvZ24j/5LxRaPlyEpIMC7jurbQ== X-Received: by 2002:a25:ce04:0:b0:c22:82b1:17ee with SMTP id x4-20020a25ce04000000b00c2282b117eemr3233485ybe.63.1688152975093; Fri, 30 Jun 2023 12:22:55 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id t4-20020a259ac4000000b00bb144da7d68sm2968477ybo.13.2023.06.30.12.22.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jun 2023 12:22:54 -0700 (PDT) Date: Fri, 30 Jun 2023 12:22:43 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Claudio Imbrenda cc: Hugh Dickins , Andrew Morton , Gerald Schaefer , Vasily Gorbik , Mike Kravetz , Mike Rapoport , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Suren Baghdasaryan , Qi Zheng , Yang Shi , Mel Gorman , Peter Xu , Peter Zijlstra , Will Deacon , Yu Zhao , Alistair Popple , Ralph Campbell , Ira Weiny , Steven Price , SeongJae Park , Lorenzo Stoakes , Huang Ying , Naoya Horiguchi , Christophe Leroy , Zack Rusin , Jason Gunthorpe , Axel Rasmussen , Anshuman Khandual , Pasha Tatashin , Miaohe Lin , Minchan Kim , Christoph Hellwig , Song Liu , Thomas Hellstrom , Russell King , "David S. Miller" , Michael Ellerman , "Aneesh Kumar K.V" , Heiko Carstens , Christian Borntraeger , Alexander Gordeev , Jann Horn , Vishal Moola , Vlastimil Babka , linux-arm-kernel@lists.infradead.org, sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page In-Reply-To: <20230630182556.7727ef50@p-imbrenda> Message-ID: <7f6d399b-c47-1faa-f7f6-9932b9811f8c@google.com> References: <54cb04f-3762-987f-8294-91dafd8ebfb0@google.com> <20230630153852.31163592@p-imbrenda> <062b19-4cf1-261-a9bf-9cefd32382fc@google.com> <20230630182556.7727ef50@p-imbrenda> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 2C85618001C X-Rspam-User: X-Stat-Signature: useyrsxytsx3s8dg4t1nfriibfnm83ry X-Rspamd-Server: rspam03 X-HE-Tag: 1688152975-951307 X-HE-Meta: U2FsdGVkX19s86PDFcur8uwfgqElWhQ7Y3IZkYpywuTKIKTVxhDYM0QONNnlI/vyRGMuYhJ6bZP7KUwdhLU/sJP2IRgocCSrLGJv7JcSItMb7029cFCUQQhmpNGRwQbu/lnU/NpzKh289PL28sXQHjE2Q6Yt2PRsjJzWVmvZ3jR8QRCCcvHNuLMEuM42LBicGdj3tWIWYoJCBqFsCOaadZPwa2uS0BB9euUP7h8Tpd7LSHXWcisid0RUDSToKHTD3oAHFT1Ju33dNHUVRQMjzH6wM05JGEMKJguVngj8T9828d5QY4o10VMbx5JnY89ecl0LG3XsZANnbeXOddU0fCP5sETgxaM6ByETlc/blMuqHRzqFw3y/9Gutl1t0kNA4NDX2FaiBuiU3Fqbzg0C1Q9Ww36bd5MGMFMYrxfILWJztBq+X6+wrgFlbofWWIT8frcm8IIpZHjFHPqZ+XMaGSiWR/Sb46ADgYAHsu98Dnt8Bg5s/jsM2+NIuPmhmaj3BoUl1goFnSJLy+CpYzgBSg5s+ooXczwtHGBszbEBWMG7g/eELAEwmZ3fH+s2Cb4oJYk536vfQqFFAwpPaUZMviPR34ZNnTRA+6Vt+kF0rMbGNg7AWkzIl95pZTK6muSd86GFaSxyYh1ngmccZa90VEYruNVgGoQLcaSA9Y1YrVuZGs7/hf/B3lLdfPP3G/lKoi9BsTTfFGBw++9e/vIj1deNOCMzoB3nrGutQJRGCURDKN6aawJt2CDs0wO/KvWPTzHbJdBd7vTqRO2b3+rBsLu2PbcKsyCu3JMCsYd6KrwXWT9zvqc6U6HQoPYRNvRNcqjoKniGj7EJCPJCHkClRfnlbNjyP34dH3HRZUbMDFOWv0tiiX4W4RdWH1++3/ek9PZYYZ8SBcCreM7yftoXnO73g9vFIyIkEiFdIwy2OdAhpFwPgw2ujDF4Ga87o4iWjFR+qANdf+BC5d547N8 6Hf5VUwe IzoqDhT9zevMVSTVPEBS6XF8muVSMx90aMrJXATkeKpsYDvfxb9eRYk6X6E9tvhKp5q1dITGAflXkurR5jk3bH95299YUqZVwLW76KfBTuXM1nZtH+cD2TeKc+Ys1xG4pnQQ2b5hUZITZwuVU2GGt5mz7iqPxlLiv8L9MY8yQn/xTkWXUUfvrK5ZYYy4uNHcAveh0DiAJJ6aJGbRfXOegr32UnRqsrjozuqJsZKfdxvpYIFIF2fztS2qIIYOlqAZWG87Au4aPOeEH0TQOKvcRRJLG6B/Oa0EN2mE9BB8G+aoytwXi0CKEUtsPJNecREh3vkZUYtz0NuSnvCYDviHjbUxJuKFpAE3qNDrBicJVNijyRR62VBcF/TeyC0PuxXBNvBJuhJa0tuYEqDjpUSTI+7/SF/OTDE2Kjqz0Frf9UD452BW4EMyYkpjpLQ3fbQNcGC8QjBleViMo/cnuBQTpB7viiL1LCZmEeQmB0B4D6mRFuSBPmW8mvxoR2UtvCDdUvNgK 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 Fri, 30 Jun 2023, Claudio Imbrenda wrote: > On Fri, 30 Jun 2023 08:28:54 -0700 (PDT) > Hugh Dickins wrote: > > On Fri, 30 Jun 2023, Claudio Imbrenda wrote: > > > On Tue, 20 Jun 2023 00:51:19 -0700 (PDT) > > > Hugh Dickins wrote: > > > > > > [...] > > > > > > > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable) > > > > +{ > > > > + unsigned int bit, mask; > > > > + struct page *page; > > > > + > > > > + page = virt_to_page(pgtable); > > > > + if (mm_alloc_pgste(mm)) { > > > > + call_rcu(&page->rcu_head, pte_free_pgste); > > > > > > so is this now going to be used to free page tables > > > instead of page_table_free_rcu? > > > > No. > > > > All pte_free_defer() is being used for (in this series; and any future > > use beyond this series will have to undertake its own evaluations) is > > for the case of removing an empty page table, which used to map a group > > of PTE mappings of a file, in order to make way for one PMD mapping of > > the huge page which those scattered pages have now been gathered into. > > > > You're worried by that mm_alloc_pgste() block: it's something I didn't > > actually no, but thanks for bringing it up :D > > > have at all in my first draft, then I thought that perhaps the pgste > > case might be able to come this way, so it seemed stupid to leave out > > the handling for it. > > > > I hope that you're implying that should be dead code here? Perhaps, > > that the pgste case corresponds to the case in s390 where THPs are > > absolutely forbidden? That would be good news for us. > > > > Gerald, in his version of this block, added a comment asking: > > /* > > * TODO: Do we need gmap_unlink(mm, pgtable, addr), like in > > * page_table_free_rcu()? > > * If yes -> need addr parameter here, like in pte_free_tlb(). > > */ > > Do you have the answer to that? Neither of us could work it out. > > this is the thing I'm worried about; removing a page table that was > used to map a guest will leave dangling pointers in the gmap that will > cause memory corruption (I actually ran into that problem myself for > another patchseries). > > gmap_unlink() is needed to clean up the pointers before they become > dangling (and also potentially do some TLB purging as needed) That's something I would have expected to be handled already via mmu_notifiers, rather than buried inside the page table freeing. If s390 is the only architecture to go that way, and could instead do it via mmu_notifiers, then I think that will be more easily supported in the long term. But I'm writing from a position of very great ignorance: advising KVM on s390 is many dimensions away from what I'm capable of. > > the point here is: we need that only for page_table_free_rcu(); all > other users of page_table_free() cannot act on guest page tables I might be wrong, but I think that most users of page_table_free() are merely freeing a page table which had to be allocated up front, but was then found unnecessary (maybe a racing task already inserted one): page tables which were never exposed to actual use. > (because we don't allow THP for KVM guests). and that is why > page_table_free() does not do gmap_unlink() currently. But THP collapse does (or did before this series) use it to free a page table which had been exposed to use. The fact that s390 does not allow THP for KVM guests makes page_table_free(), and this new pte_free_defer(), safe for that; but it feels dangerously coincidental. It's easy to imagine a future change being made, which would stumble over this issue. I have imagined that pte_free_defer() will be useful in future, in the freeing of empty page tables: but s390 may pose a problem there - though perhaps no more of a problem than additionally needing to pass a virtual address down the stack. > > > > > > > > > or will it be used instead of page_table_free? > > > > Not always; but yes, this case of removing a page table used > > page_table_free() before; but now, with the lighter locking, needs > > to keep the page table valid until the RCU grace period expires. > > so if I understand correctly your code will, sometimes, under some > circumstances, replace what page_table_free() does, but it will never > replace page_table_free_rcu()? > > because in that case there would be no issues Yes, thanks for confirming: we have no issue here at present, but may do if use of pte_free_defer() is extended to other contexts in future. Would it be appropriate to add a WARN_ON_ONCE around that > > > > + if (mm_alloc_pgste(mm)) { in pte_free_defer()? I ask that somewhat rhetorically: that block disappears in the later version I was working on last night (and will return to shortly), in which pte_free_defer() just sets a bit and calls page_table_free(). But I'd like to understand the possibilities better: does mm_alloc_pgste() correspond 1:1 to KVM guest on s390, or does it cover several different possibilities of which KVM guest is one, or am I just confused to be thinking there's any relationship? Thanks, Hugh > > > > > > > > > this is actually quite important for KVM on s390 > > > > None of us are wanting to break KVM on s390: your guidance appreciated! > > > > Thanks, > > Hugh