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 7BAF4C7EE23 for ; Wed, 24 May 2023 01:49:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F0466B0074; Tue, 23 May 2023 21:49:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 179536B0075; Tue, 23 May 2023 21:49:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01BA1900002; Tue, 23 May 2023 21:49:29 -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 E4A276B0074 for ; Tue, 23 May 2023 21:49:29 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B5BCE80363 for ; Wed, 24 May 2023 01:49:29 +0000 (UTC) X-FDA: 80823466458.22.3454D09 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf16.hostedemail.com (Postfix) with ESMTP id DDB8D180006 for ; Wed, 24 May 2023 01:49:27 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="fL1Ko/Yz"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of hughd@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684892967; 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=qRR20WPPG9GQ+bWld5KX4B7EuAV7QhoHIJ5BRRfzj5g=; b=s6VEN0r7RsEVnAXSJsJsyglcgExNFmqoANUTNm3iAsHlLCsulvEHU02uSl8tSOpU4tVgdJ HQ6TftxileZZ4zz0jpnBqPZDSQ8dH5Q5Yuf8fw9vE5Pz1+nhpeTZNPL4zGglgsnR+ZAvK6 fY/oXtoFEkOQVCIxDYcMAzI6rsUu0Ds= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="fL1Ko/Yz"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of hughd@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684892967; a=rsa-sha256; cv=none; b=leieE45B42BD6UeJqlRXwSBLS5qDjsZcNXhMRpr8jAN6GlpaYsbr+XcvIubKxOq8nCfQpg daZQhHsTLxsuucHW7QBhQhR9ZZoY7jNdnrYG0e4KKCES0/DHoBPXyB/PIkF+Nng4jk4bTS X7HL7uyOlSiuq+049/oTA94rYggatME= Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-ba8253f635cso661605276.0 for ; Tue, 23 May 2023 18:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684892967; x=1687484967; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=qRR20WPPG9GQ+bWld5KX4B7EuAV7QhoHIJ5BRRfzj5g=; b=fL1Ko/YzJ7ADR+5IhbndnTRBOzBniMKv2InrhlDBTKJ8NlYVC/WzojNZzRdjG8LqqI 8LB9Z4sfpXm4DMnyfRFicnIehOON6Mw+FClbq6xhPa9tlrIuXm3Q/2idrYMx02+afzOp 1VCSHU1xv+O9cTuzhmlxGQq1v0D4TgBrAS9dYOJLgo+SzeMAZ7rQLDPNPL9H5vsD1p44 JTB4zFm6Ty/2t/Mm5CpAGXHuXSex52HKZD5bYmtrIhNvgrtjqZinsu17ACzjltY7KKk5 TNaE7Q4HSc79RkqKOj+NGXTgrLKTP+KzqHxsfw06sf9yCgMnslxI0DnH5G6oL7bKwZgq fWlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684892967; x=1687484967; 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=qRR20WPPG9GQ+bWld5KX4B7EuAV7QhoHIJ5BRRfzj5g=; b=aeADF4tGMqtX2cpSOslG1kfS28Wy+cpTAnWLZ9qKmqzykd+c3/8Wn318ZsHF4cNAWp BNiYNsHZPs4X2pVqjYFogvioEB+v+LVCKQxyQAz5M8txB0bO3HQpWlZv3Ml4loaD4n3K 4EMFwjNyMQEKAwX6Bxpa+A9EFmry+YoJofuh8+L+YdSF7tQA8ycas+ZF83b8ctqwS6Gv 6YefBBjTH6IAFiO3fbG2mY135pVwtqbhWY9Nc5WNBryAaBwSxZ8bWrE5dJsALQysXdbP c4cmyP+JKWH5OyFCx5uKTyYp5x651nKDjria5yak9McDZNUWNf8kWWaFwyz8b2yHpe3g DCCg== X-Gm-Message-State: AC+VfDw7I7xlbeUoQ5zAqt4axUxvsQIlRcRH9CCIfKJQLB6pTZRBJvk9 wLsFp8DmZr3AyYpXpMq7B2JUkg== X-Google-Smtp-Source: ACHHUZ7f0TOZQo7Cw+o/qEVNq4B1zvZdBbLM5VJM6QqwwtZu4t36Vxp5CkGSHrwBFYCBff4rw2Ddpw== X-Received: by 2002:a25:385:0:b0:ba8:54c4:3136 with SMTP id 127-20020a250385000000b00ba854c43136mr19398918ybd.52.1684892966804; Tue, 23 May 2023 18:49:26 -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 x7-20020a259a07000000b00b8f6ec5a955sm2395274ybn.49.2023.05.23.18.49.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 May 2023 18:49:26 -0700 (PDT) Date: Tue, 23 May 2023 18:49:14 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Claudio Imbrenda cc: Hugh Dickins , Andrew Morton , Mike Kravetz , Mike Rapoport , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Suren Baghdasaryan , Qi Zheng , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Greg Ungerer , Michal Simek , Thomas Bogendoerfer , Helge Deller , John David Anglin , "Aneesh Kumar K.V" , Michael Ellerman , Alexandre Ghiti , Palmer Dabbelt , Heiko Carstens , Christian Borntraeger , John Paul Adrian Glaubitz , "David S. Miller" , Chris Zankel , Max Filippov , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 15/23] s390: allow pte_offset_map_lock() to fail In-Reply-To: <20230523140056.55b664b1@p-imbrenda> Message-ID: References: <77a5d8c-406b-7068-4f17-23b7ac53bc83@google.com> <94aec8fe-383f-892-dcbf-d4c14e460a7@google.com> <20230517123546.672fb9b0@p-imbrenda> <4a15dbaa-1614-ce-ce1f-f73959cef895@google.com> <20230523140056.55b664b1@p-imbrenda> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Stat-Signature: xfem111dobgijr9houqhskikwpthtpwp X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: DDB8D180006 X-HE-Tag: 1684892967-729339 X-HE-Meta: U2FsdGVkX1+eCXVn/DTY+7d1ZUQy7rZpxZyclf9CEooUH93HYHoEeyx2mrQcvWi94jeWBvEEYNgBx8lNZMPzalUwHAoaT/Z1HBxquug/ySs40X4JAd3p6DxScHh9sf3x19eEdUA7kEufMwlJCcbQsSnt67shKyApJkrOG0x8m61Sjsy4/9A/w6yQ0HYRKlOMwcm0dSUFSEka4+XjmsE+fPRChAdSC6Veitfylbgb+h5Rn3urw9wMajSzI6PHIACL3mx05w9H1h1fsvBJCN8rTn8avNhlyd00U3w8r5DdRXVF8En4eyJEe3nfg1s8g6Y9OLfGazK4QLR75PAsm95Yx4+0g2oIfAxlqLfJZnylrmuQyGOm1r4KsloFp27FSxDw9NEHd+bE5RYJVTJyjZzAOQ6UMDUC32VmmlDwGq3v/m3PXgoQCn0D/DmUAJurhSLVd+UDW/gAj6jV/uR/06vAT1H8/1bHSxkz2QUl/HsBFbBkVSh00XBtE8YjE8dkiPYr0lDKXV91JAbHxKZfK0EAxNq6iN2omwi61exZA2yMN2I3I8X2KheuqEQLlVS+jdKsn0VwnYxIe+IWBkGpyNY4r//XICkGhswSNyQxhcG2lqfi/mTagKwx66zCCU/7ZUskNYBNtIwJyR0ZykN284QD3aE4xOA/VR37rWqlrgi/U+4ShJkITP21HgVaiqB+ZDV6NX8w60TvJD2umAAw9qyn8ahyxL/SrXZc7YBW1JJ65cguQH3GKAmusv4fWY5asc4AtbaqXeHE3DWYiPp8iD4JO1kngi4+TRyJwX8cEwWucmh0RpnYQ8qazEy/CBJcvKyFypSKA6A+R0NyuN4mCBDbOVDhr7lV7Id7QL+zqW1Q3BmuUEOACQSMAVseacN2P7X03kk8ivX/YzVwgiG3z65nPSGaK8F8Ab4oirYnK6zuDIU3chfBOHj/ou0RXnxG8g1/7+6sUKy32ZMPA1Kblal aiYIfMMf X8uHRXlkqLS205gEy3PczFJeNLDK3azzKW0Vk0DD/e/EIzdwTFA29na24/5AwUaCUj+AWFckzM+Xp49uXBdxnc599LPUc6ru0ATGp8vDMBXNKyminPXfZdqG/LAArzcH3cN7av1USxKx3FFmQsBo2iCkVZ3lewkIm9Y920jX/mh8tv1BHQeiZ9Tcj3OUlOGon6biJTeAW0pul+15FdHzow3HZeDMcAR9LZu8GNvZmbaxgqXCAKaoPT8p29Ap961/W2CZXAHiKWG12/mubYZ0IBrqTid6T3iSgKy8vznOIvxunI+k0aZtgWzUZaD6JPxGJzNfeipA5dlhLcLRTcbXJE+3JMywcKvfEHqyRgogFFnNhLAbw0kgNmTXfZDiDzsCd28bankg15NoLKTYZuTUWHDObXogQySg50tix 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 Tue, 23 May 2023, Claudio Imbrenda wrote: > > so if I understand the above correctly, pte_offset_map_lock will only > fail if the whole page table has disappeared, and in that case, it will > never reappear with zero pages, therefore we can safely skip (in that > case just break). if we were to do a continue instead of a break, we > would most likely fail again anyway. Yes, that's the most likely; and you hold mmap_write_lock() there, and VM_NOHUGEPAGE on all vmas, so I think it's the only foreseeable possibility. > > in that case I would still like a small change in your patch: please > write a short (2~3 lines max) comment about why it's ok to do things > that way Sure. But I now see that I've disobeyed you, and gone to 4 lines (but in the comment above the function, so as not to distract from the code itself): is this good wording to you? I needed to research how they were stopped from coming in afterwards, so wanted to put something greppable in there. And, unless I'm misunderstanding, that "after THP was enabled" was always supposed to say "after THP was disabled" (because splitting a huge zero page pmd inserts a a page table full of little zero ptes). Or would you prefer the comment in the commit message instead, or down just above the pte_offset_map_lock() line? It would much better if I could find one place at the mm end, to enforce its end of the contract; but cannot think how to do that. Hugh --- a/arch/s390/mm/gmap.c +++ b/arch/s390/mm/gmap.c @@ -2537,7 +2537,12 @@ static inline void thp_split_mm(struct mm_struct *mm) * Remove all empty zero pages from the mapping for lazy refaulting * - This must be called after mm->context.has_pgste is set, to avoid * future creation of zero pages - * - This must be called after THP was enabled + * - This must be called after THP was disabled. + * + * mm contracts with s390, that even if mm were to remove a page table, + * racing with the loop below and so causing pte_offset_map_lock() to fail, + * it will never insert a page table containing empty zero pages once + * mm_forbids_zeropage(mm) i.e. mm->context.has_pgste is set. */ static int __zap_zero_pages(pmd_t *pmd, unsigned long start, unsigned long end, struct mm_walk *walk)