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 6E0F4C77B73 for ; Fri, 26 May 2023 16:25:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B543900003; Fri, 26 May 2023 12:25:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96564900002; Fri, 26 May 2023 12:25:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 805A1900003; Fri, 26 May 2023 12:25:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 70586900002 for ; Fri, 26 May 2023 12:25:16 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2EB1FAEC80 for ; Fri, 26 May 2023 16:25:16 +0000 (UTC) X-FDA: 80832931032.07.208C663 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf17.hostedemail.com (Postfix) with ESMTP id EE65840012 for ; Fri, 26 May 2023 16:25:13 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bq2TUNhw; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf17.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685118314; 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=PsJszb3Fdl+4KCiTmg2OAMXb15gljPH7bH8CgxNSabY=; b=j4Qpn0wzlZhYLFNIn+74QasJKxId4AYRsOToQ/Hg9lemZ58FIu2E88kP7sp9+N12EFY3cI ULSeHvK0qut3zlwmkykq2wn/ge/9Fm1s+4N8bjhMhw9q1MOqxO+jhEn+thIwJ10Ofs/LRo SPELUY5Hpdr0XJZ0ncqXzCVgLwO9UUk= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bq2TUNhw; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf17.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685118314; a=rsa-sha256; cv=none; b=HYXKokNKezfRTz8GkPScfjB9+XPGcoSI0Ygv+TMN5M/tpaC/BdHwZ2FlCcjeQoERThIjhb 3UHyC4+KPq3QBjbLlNUyTPcT1PaaySurKILSXE9Kn0jP0TDXCAFbCeVumvMjmysCS4JDRY eApZdj9ouvMpQ/A9LX4vx2v1To3hJ14= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1685118313; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PsJszb3Fdl+4KCiTmg2OAMXb15gljPH7bH8CgxNSabY=; b=bq2TUNhw03SGpftD8xkSNyCnL2H1B2ErsL3boM2qkhPuCQ2GDnMyx5lL+VHNsOaakdgfZE BTZUZGBiXz7NKGw1tzoee/qqoLGTmYgHEEIrh/3XzL/DnHcpb4zQ3RXqBTLtxKmXkcKALK QVBoAbTtCN13y8nAXjqI/DhkFx3EIFM= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-275-qhXObh8wNOavvH_2trVqEA-1; Fri, 26 May 2023 12:25:12 -0400 X-MC-Unique: qhXObh8wNOavvH_2trVqEA-1 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-3f6b5f643beso1614381cf.0 for ; Fri, 26 May 2023 09:25:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685118311; x=1687710311; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PsJszb3Fdl+4KCiTmg2OAMXb15gljPH7bH8CgxNSabY=; b=VqBOGwXVZM9qKOr9VYFveaHL8UGhwSclpAcU/UTILrnITgyvUg23z4YYklNYRjfmqY LBr6JRjVRpA18MU5y00/bwA16rvELvJlRAzSsD4kAfEFZn5jsR3k1IA3nL41fU+Cz+R6 3g21Vk/2xxpP+YHRPfwEv2CWpJo1wV+ln9C8G+VzCnKX67IBcqdIW+c5Yrw6SSJByU77 pICAnL2Vz+aZ/S9zPaABqMwYwnTKF4jTBe0KkDd3Dvk1mKzQAwcTXTpXeaueHAXIYN7g xw7ikjX2GFnSRnjwPPg58CPPZGZ5xjWCn9vdZx3gAhk6bwru+kDHS2Lq0WdhwbaknjzN kCjw== X-Gm-Message-State: AC+VfDw93irfskwSAk/03/4+u+65HIvt9uH0MekmKnHb5B6Sc1FnI1Fy NGvaFFzrXYRkW6Ut2KpvsZNxGA0LVMyZSLdz89Eqyl8fSQKDMXcg1z3OJIchPIPS0WXuEMYK3RQ NxlNs1rvfhzg= X-Received: by 2002:a05:6214:5183:b0:625:86ed:8ac8 with SMTP id kl3-20020a056214518300b0062586ed8ac8mr2440709qvb.4.1685118311446; Fri, 26 May 2023 09:25:11 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5e8uegKmA/XAEGaKWCkbZfbcirz0MPWJeTqDxxGlyKLoSTi1jAZy/i5FQlX1uWj6LhW7xDDA== X-Received: by 2002:a05:6214:5183:b0:625:86ed:8ac8 with SMTP id kl3-20020a056214518300b0062586ed8ac8mr2440666qvb.4.1685118311138; Fri, 26 May 2023 09:25:11 -0700 (PDT) Received: from x1n (bras-base-aurron9127w-grc-62-70-24-86-62.dsl.bell.ca. [70.24.86.62]) by smtp.gmail.com with ESMTPSA id nd13-20020a056214420d00b0061b58b07130sm35719qvb.137.2023.05.26.09.25.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 May 2023 09:25:10 -0700 (PDT) Date: Fri, 26 May 2023 12:25:05 -0400 From: Peter Xu To: Hugh Dickins Cc: 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 Message-ID: References: <68a97fbe-5c1e-7ac6-72c-7b9c6290b370@google.com> <49d92b15-3442-4e84-39bd-c77c316bf844@google.com> <8f2131ac-8996-e4b3-2aad-7a4d11bd538f@google.com> MIME-Version: 1.0 In-Reply-To: <8f2131ac-8996-e4b3-2aad-7a4d11bd538f@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: EE65840012 X-Stat-Signature: frdd15bumewrsiimnjr7crc14jdfnx4c X-HE-Tag: 1685118313-58336 X-HE-Meta: U2FsdGVkX1+VpH7/5Xmii2uvt8CjhOqeirZx/UQItvnyHM0sATCV6ytAcUlfQh6pPyU0eJIgCuUeLMe9uY0dGqVrN2XSpGw0GZ8BqNxum+JjteK2oIrTUqVUlivu7IelxMumnLmT4Je3r+CkDH6AcIb3/x4NKJ9kNTxJ4UwJXsCnAay5KTM5HRbluf3Ap8pLKKQAniim0xwtCEl1EMLkzyjZg6RbuR1hi8dUApFgf/kt1sL069WU2UiMPhPIL6Q8Yi2Vf4HnbdkYqy5owYSJnefUOYqmwioXcsrz6YYNLaMsCtx/NtFHshxUhOxkot2yz9FPLTGJPNMsO0a7QzbuBUtzkMSwoZCLnkExchFXKyjJAkqBJq3q6ae2+9YYVctaAetT8EZo0zpfJMTuT60zbGwegGu7AmhyBRrqXIhycqmRBHAFnDJcwUozTjdfUz7l/KDQOoSd28G5a82m0eHqoV4QZM9IENSoSzSP+03mTx4gZwiH2bzTX6n3+HviCt4Ad1YarhQoCFRfekYQ6Ahjpk7zvsTFgmMSlQOWjBtm3gr5FzuzCt4cDP7KIyOnL+m0TCKqXA34bivcNFBw1UkZHlHOXh+RgWbvKqhTpmRywMEeuHAEgqFGgSQl8H9cYY0MvIjMIxZyrRGBuVBowVraFOmEpx77XS+FeDRG8bdk5CKohXDe3OvKD4ZMEnUCN2jAPzjvy90KXv+tEUtM6vQ7Kt1dfCIfhHRXVtP7aH6hHttJ6jw5X/oBv1dpqCkKwgqtJYx8U8gUabhd5+swO0NuYWPvTMXJqcjOFdZvaUePS1BUqS/ipRz/4T36pJGWEuyxYR4RlCqNgd5VdV0lee4lO+I3IBBYIOwRD9zzO0vksc5O3PFFHm6KlRl1WgOqB8T0G65DkjFK7hLZaRYElGpqopPAzZ7mMmRGvLcTxpKWI7M3nq8C/WIuJo1xCId23msiwpdfC2d7R+ReGsb2Ikz 5hdlbseb /zit0GcFewXWzlDmfAjFT5VQhvtHbTvOH/lIMcdedm56o1fVQYTJowERpmZOcIMgHuIzWcsBE098FkY9Opq9vJe13uClKbgRryyREdHiJPj8zsDq6cQdt5ZEUkpzAMmX2SzzfhMJs/eNccTZJ4IfgbKRJZze7mpJjmmmvBjL9zMBboPpgQrvOX8vEwNWjcN82Bdni12ixp4Idtss23KUv0hBsOlZc7o+eTOexxlWjShN9hy6aPi0lY5PHUP607lRJgVh0gIHLHVNYrPzNYGS7w89HhiFv34svfOwii4764EZrX8X95PDSzDxoxjRBS5c8agaWpTe8+1A5uWJpCL5qRlLPBEY18pDB0xdHB9uqLl84F9jlumXrtZaaR2anKOV2ji+ABJg6LolQlSgGfIkMvkIR5G0yb3YBwIhT 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 Thu, May 25, 2023 at 03:06:27PM -0700, Hugh Dickins wrote: > 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.) Thanks. > > > > > 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. I had a feeling that that 2nd -EFAULT there could crash some userapp already if it got returned somewhere, because the userapp shouldn't expect that. IMHO it should also return -EAGAIN, or even -EEXIST because even if user retries, we should highly possibly see that thp again, so the -EEXIST should possibly follow anyway. Not a big deal here I think - if an userapp can trigger that -EFAULT I'd say it's also a user bug because it made two decisions already on resolving page fault for single VA, and it's racy between them.. > > > > > 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). I'm actually still curious how the 3rd series will look like; would love to read it when it comes. Thanks, -- Peter Xu