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 5780CC7EE29 for ; Thu, 25 May 2023 22:06:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA12E900004; Thu, 25 May 2023 18:06:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B50C0900002; Thu, 25 May 2023 18:06:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F1DA900004; Thu, 25 May 2023 18:06:34 -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 8C9C6900002 for ; Thu, 25 May 2023 18:06:34 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5006C120E82 for ; Thu, 25 May 2023 22:06:34 +0000 (UTC) X-FDA: 80830162308.26.EB62CBE Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179]) by imf29.hostedemail.com (Postfix) with ESMTP id E019512000D for ; Thu, 25 May 2023 22:06:31 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=ueglYvsj; spf=pass (imf29.hostedemail.com: domain of hughd@google.com designates 209.85.128.179 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=1685052392; 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=UR4x6rXE0bo/ckqm6Jv4R6OAJNwweiidW4Yk75ZB+NQ=; b=A86b0ya3zBijFDZlVWhm8rpJiezST2iH7AMgy1ay797v2PiJmPQfXYsJZC4gML9ZiYWgh7 dgIcxNJTI4pfln9e16Vai1u/UWRZJiCEEJeJ6PFZ30hqVv/b7a+XGGZ6MNQb6VTJFTXuL4 z9OpEa6zhfXTjua7O/hbg+sBnebHyF0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685052392; a=rsa-sha256; cv=none; b=gIPQUqt/GRo6CpRcMd6/jCVZ11HedFOEs0hU9mRfkCpVxFFB8Zd56SITYKzYtG4iqdhxAk IlWcFWnNdPsBX2Gf8bOX+Feq47x7dX4e2dYNgxzQ+7EEGGymOrzgJE1jKTO5uGwPokArlH 2tFA7lcoUkbj1aoU/4fumgkZu0zRrMY= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=ueglYvsj; spf=pass (imf29.hostedemail.com: domain of hughd@google.com designates 209.85.128.179 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-563874afe98so3601767b3.1 for ; Thu, 25 May 2023 15:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1685052391; x=1687644391; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=UR4x6rXE0bo/ckqm6Jv4R6OAJNwweiidW4Yk75ZB+NQ=; b=ueglYvsjHws3Vja2dJ9Cy5bXiw8Uu5eCcGKzAUINwqqmZmuOVZ2tSeTbvZesbRYf5k LVuLldxIO5UaKvQPPHoCfrz+K1HmO1Q7e7lObTL7uAyZBcrrJBIFPfsebZEzoqlSF/NC uNW3Pw2Ws777qnPVwi1s1YRqXXBabl3XW/USHJBSzUo2BMhiUET3eZnBC+Tw6hhTMpvU 9mwXS3U27RpbuNeA3YXCMRCzZnA5avZvcuFZk4xAQR+SUZgnpl0nvx+1bkB9f3Ag+QGc RlClPWHiz9eYf2lBVNbE6HX4hkTPTlwAvH3CPE47ekdt78pxKuEQ18kaQgjAUkc1BGz8 0VrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685052391; x=1687644391; 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=UR4x6rXE0bo/ckqm6Jv4R6OAJNwweiidW4Yk75ZB+NQ=; b=QWbVGTe7HsW5UpFNsOgn8+28AHDhxC07WIdk8PD69Ynpqk8nY7V7YCEuuCZLw45HfK HsCMAP9CTCkWWAxaaCxbULsHBQsaDiZyK5xlYwYYMEMwLoV085gvrIMEH+9mH3nv6gki Fo6uoTefuAL1c6LM93IKMR1N/8cff0iCF2tU6tWyQ5lRV8J9L4JUT8Hje8Ms6OB6A3cm cjatZCK0v8ZU06AC/K6rm9wC+4mUcD87XwyGUzlSS0iAiv5hUr91rX4IxAWVt5msy7t6 HCUgRoHkyP/xFeLRVTbWSb2WCyyD/vw4fHmDiEEQsGPgcqjoU6GRhutp1TdIhQqHzOFe OZIg== X-Gm-Message-State: AC+VfDz0PR3scBrpYhBU4E254eIIpyaHEW+xVvl40IdVtMfJF3w1008u 6tRxu3rmwPAEdZWo6WOyWRqshg== X-Google-Smtp-Source: ACHHUZ5+gq3WKyM1RjGKDETUWUkkI2NTdK1hXriUldQCpOa1eAi5N8VOb1OaskV4/hm/b64oaD8bpA== X-Received: by 2002:a81:9201:0:b0:561:baab:fd22 with SMTP id j1-20020a819201000000b00561baabfd22mr1046488ywg.3.1685052391294; Thu, 25 May 2023 15:06:31 -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 t20-20020a81c254000000b00561949f713fsm648660ywg.39.2023.05.25.15.06.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 May 2023 15:06:30 -0700 (PDT) Date: Thu, 25 May 2023 15:06:27 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Peter Xu cc: Hugh Dickins , Andrew Morton , Mike Kravetz , Mike Rapoport , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Suren Baghdasaryan , Qi Zheng , Yang Shi , Mel Gorman , Peter Zijlstra , Will Deacon , Yu Zhao , Alistair Popple , Ralph Campbell , Ira Weiny , Steven Price , SeongJae Park , Naoya Horiguchi , Christophe Leroy , Zack Rusin , Jason Gunthorpe , Axel Rasmussen , Anshuman Khandual , Pasha Tatashin , Miaohe Lin , Minchan Kim , Christoph Hellwig , Song Liu , Thomas Hellstrom , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 15/31] mm/userfaultfd: allow pte_offset_map_lock() to fail In-Reply-To: Message-ID: <8f2131ac-8996-e4b3-2aad-7a4d11bd538f@google.com> References: <68a97fbe-5c1e-7ac6-72c-7b9c6290b370@google.com> <49d92b15-3442-4e84-39bd-c77c316bf844@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Stat-Signature: tz5gryp6ho3w6rh3qrw77bj1yw3kp7h1 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E019512000D X-Rspam-User: X-HE-Tag: 1685052391-258744 X-HE-Meta: U2FsdGVkX19tNbvaXR8XTM/FMEu0c80UwlmAoDKmLlSh3DcF0OKQgLR+JlraFxltcawzf3sbt6V60nz1DyuSG/xxL9KgEzDE73znaeplX0XOwiiuaom+PO6F2zarVwmt3hwZrfL6+UlnsZokjllgkcCltAz5BRY2C6VRjFGlfdSCAAuRE1fwFbXOKkJhVDTKB1FFPogyOAOktlBTRq8ZR2+LOlpTn/AsE4RAzwHunAZuXeP91pZiO8Q6ISLI1NwXcGCmf0h0VFU8aTbEYnjnhyxOSXJPpVsc3/sd+ISqYKRhHNKorxihc5H84ZQrhVjl5gmKMhVfAjBk56XrbBFNPGr1C3Whk6C2H5tKbUIhQV/WfdIhK6mfQoroAjvc8TqUP1GcD+JD2FQ090yF+YXoKAx42n3J6HHPnPmq55SWG5loBkEji9fM2INSTy7I25x8EXouLFvD5bV+Xw9zTlHmhfbOUNRmLsMU4A5vT4b5A0Nl4C8VWjXNDvgOs7sY6Tzec7TiN8hnUhScQkOtGEuds2i1Jae+G4euYmIdedFebuH2bgfYXMfPq/REU7RYjYG/7vLBZy8DvZfKgTpNC1fZib8oX9It9tGGsh5vfrMRqhLJFO2WjPY4UQON6JB2qCnVBM0Dya+8i6MbCvA2qdhRy1xrHSWPGDO1SeUfTmTEadCgy0k9esL78hzQ1ypKdPEj1Ux06U8M7HS3pkeNysc8OUkIMyIpBoMb3e+g14mw3+HCgiTV+iV6Ugu+BapZeftleuzRC9N+acUxyjTw4MgK1GOAb5Z+MneNl1dqALQJDhvE/G6LTZrPzO8k1nVoep87FA2vwmDgLeN6vG75apWbZc2wn+lpktF4upuguIrvdVd8qXhDqsZ3cSY9xm8Y10UZEOL9giH1kVjwoMaFmC4elUnh0J2PAS2TJzaWtOF445XmCOllfo9X1xyRG0kcfn1Zxd7JzfjX4H+uM7R4VqK KLThXrB9 8uCYENxPl0/RiohoqGZ+yzI7hiaVN1E2KZKBfXczifQtiVGtMO7qb2xWBMulAscobxmvrMnxFkJz0efmYFAfYdT9zmNP+7FGsdyzEQawzPzoEmgx7Zt1NC6rE2x1XsB0FKdy59vOoK5StQiJRvQqVgfkn4BziUKVQeZKiGdvZ+gJKygZeGqRb2bcrFzwKZ7h3zH4nZVj9jE+UCtNBO62URc22kMEPLG94v9kTj1rQV8ARCwEJWA9jwzeB2wNz3zr48hzaknM5CEV1AnuqS56kFlVSlAi92q//6Xw3yo8m7rYnSu4OAXPJ7rDKKvZ9EpwiCXreHeFnTbSvwlkDo2vaUqj5S3zhv2KTSIqS7opG+8RabPBMzxPRg5pRb06fEc8W0Inz2wE3EODNMXy4R//U8ZEWAzeeQOzGCbIu 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 Wed, 24 May 2023, Peter Xu wrote: > On Sun, May 21, 2023 at 10:07:35PM -0700, Hugh Dickins wrote: > > mfill_atomic_install_pte() and mfill_atomic_pte_zeropage() treat > > failed pte_offset_map_lock() as -EFAULT, with no attempt to retry. > > Could you help explain why it should be -EFAULT, not -EAGAIN or -EEXIST? Thanks a lot for looking, Peter. No good justification for -EFAULT: I just grabbed the closest, fairly neutral, error code that I could see already being in use there: but now that you mention -EAGAIN, which I can see being used from mfill_atomic(), yes, that would be ideal - and consistent with how it's already being used. I'll make that change, thanks for suggesting. (And it had bugged me how my fs/userfaultfd.c was electing to retry, but this one electing to fail.) > > IIUC right now if pte existed we have -EEXIST returned as part of the > userfault ABI, no matter whether it's pte or thp. It might or might not correspond to -EEXIST - it might even end up as -EFAULT on a retry after -EAGAIN: I see mfill_atomic() contains both -EEXIST and -EFAULT cases for pmd_trans_huge(). Actually, I could say that the -EFAULT case there corresponds to the -EFAULT in this 15/31 patch, but that would be by coincidence not design: I'm happier with your -EAGAIN suggestion. > > IMHO it may boil down to my limited knowledge on how pte_offset_map_lock() > is used after this part 2 series, and I assume the core changes will be in > your 3rd series (besides this one and the arch one). > > Please shed some light if there's quick answers (IIUC this is for speeding > up collapsing shmem thps, but still no much clue here), or I can also wait > for reading the 3rd part if it'll come soon in any form. It wouldn't be particularly easy to deduce from the third series of patches, rather submerged in implementation details. Just keep in mind that, like in the "old" pmd_trans_unstable() cases, there may be instants at which, when trying to get the lock on a page table, that page table might already have gone, or been replaced by something else e.g. a THP, and a retry necessary at the outer level (if it's important to persist). Hugh