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 94E6CC48260 for ; Tue, 13 Feb 2024 19:55:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2BED8D000F; Tue, 13 Feb 2024 14:55:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDCC88D000E; Tue, 13 Feb 2024 14:55:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7B4A8D000F; Tue, 13 Feb 2024 14:55:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C41A68D000E for ; Tue, 13 Feb 2024 14:55:26 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 81636140693 for ; Tue, 13 Feb 2024 19:55:26 +0000 (UTC) X-FDA: 81787835052.23.2229F6E Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by imf07.hostedemail.com (Postfix) with ESMTP id 98B4F4001F for ; Tue, 13 Feb 2024 19:55:24 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EiIdfyGv; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=lokeshgidra@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707854124; a=rsa-sha256; cv=none; b=qZcP8DT6f2l6q+B7yIWgqNvAIZngXrUxCC7ecPg7tkQxl6jftbd8CsOcubnwAVlahex82x anrXK4fCaF09L9WdaZaj1eDG8+1bc95nuBJUZkN+/eb7XjuE0FRFvba7wgLPtvu0jCnjDL lrchhCv5gbtx+v2fwH6OrDyn+fFgHVs= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EiIdfyGv; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=lokeshgidra@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707854124; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=K4FCa1V10al25x2H6TCYXD+ZgK9d/r75JguWzXT91NQ=; b=6bAqxx0XowniByuEgdPOM3/RRQK423QxXA+//kfPz6vMB91/9ZATK161LciwYi1hNOblbe 7e/ybkRO8hGTsEQb6Bt1xSmeRF5NcNxTQmYU88ZWIKs5sLNwe51jMvCBPzNvSPzNqb3iVY hetlu+cibKn6f9D3/vPq908PDW2KrTQ= Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-33b401fd72bso3131118f8f.3 for ; Tue, 13 Feb 2024 11:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707854123; x=1708458923; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=K4FCa1V10al25x2H6TCYXD+ZgK9d/r75JguWzXT91NQ=; b=EiIdfyGv62ovdqack9JiEaqkBbpdftawlPk3jPn9pZ2ue+pv5Gt10h0YwreiVy3Ubj +aTFNgxzItosWThvMfEi685QzctpRTdjPywmrH+Vtiw5D4OgNqC/jO8am1/5cS7ZrTig kND/dOL30ZwIa0VltUirq8zR5+iEil1753CNuwlEWSDbQ6Clu971+f8Nbwbw7J9snQPA NrH5HZFFie6u7YpRuw5gilSWeqp6SKQObu3BG7d/uPcoWeva1mk6HP6I3UsOZM+mt5zg EEfZ5b+N+3TR9oySgFrJmKrx65vVFzCkJ8/sN6TNQ97dwcFJPaSEYx3W0aDQZc0Gy/zx kURQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707854123; x=1708458923; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=K4FCa1V10al25x2H6TCYXD+ZgK9d/r75JguWzXT91NQ=; b=bn/vxBIv8GtFkG9M+grp57+8w3VRoWcLbFHuESj2wcQzs4PBhrf9PoPptUHWWed7zX PihLV/Daq4zIh9JIBSEPfYcmmiaq7CusgF2HzUGwwKbuQm7Sp7HN3mNOoKUJvhRAN7nV 32ZP93s9/VhHtDvDV4trqc8ON+eNS2/o5X4Z3Mwimt6S9pGN+txpywP2NNchu8PBtIc1 7Ti9YPvgwa8QBYeedtSL/Gxzl4A8H8zP6AnUuTdsSuhM44ZecaB4Kdd2CIz2Uh61f64q z3CR9KuUddqUT1KxUth5r1hxrfVRMXtaV23+9OmHQ97+BzmgwgnCvSv+6KiPQ/RP0re8 IArw== X-Forwarded-Encrypted: i=1; AJvYcCXTmB2FFVVhtmOrO8bQ1NzOduLQwOTYdvhMgtzhFf8abRrr0bLNqxiUeasuJ/rj6VVNZaJAVtBOgu6w7EpUsdMaY84= X-Gm-Message-State: AOJu0YzZLoyQLsrbQ6HgzdgngfnED5g4sXwLudMs4/YSmMkirMcmcdBX 1tBl2rMMF2yYl702McBdQo/pGss3ZVI1m9lqgnAKlUj6H2BFwmtl6WbFEIeuEYt+8dc8B1qiozM kylwz67kZgXGQj1XQ+Uht4mRtz1jRysha8SLK X-Google-Smtp-Source: AGHT+IFWXIXONMt5zEShnmDZcWhv7RgwcR3a9xWQLu/Tf+5zhkKq9vpvvpAG+xYDdOhe8qKwW8Xr2MTM/tJoxmlie5c= X-Received: by 2002:a5d:6ac5:0:b0:33a:e2d3:c3ec with SMTP id u5-20020a5d6ac5000000b0033ae2d3c3ecmr210990wrw.60.1707854123043; Tue, 13 Feb 2024 11:55:23 -0800 (PST) MIME-Version: 1.0 References: <20240213170609.s3queephdyxzrz7j@revolver> <20240213184905.tp4i2ifbglfzlwi6@revolver> <20240213192744.5fqwrlqz5bbvqtf5@revolver> <20240213195125.yhg5ti6qrchpela6@revolver> In-Reply-To: <20240213195125.yhg5ti6qrchpela6@revolver> From: Lokesh Gidra Date: Tue, 13 Feb 2024 11:55:11 -0800 Message-ID: Subject: Re: [PATCH v5 3/3] userfaultfd: use per-vma locks in userfaultfd operations To: "Liam R. Howlett" , Lokesh Gidra , Suren Baghdasaryan , akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, selinux@vger.kernel.org, kernel-team@android.com, aarcange@redhat.com, peterx@redhat.com, david@redhat.com, axelrasmussen@google.com, bgeffon@google.com, willy@infradead.org, jannh@google.com, kaleshsingh@google.com, ngeoffray@google.com, timmurray@google.com, rppt@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 98B4F4001F X-Stat-Signature: yzwq5d1s66ih3mn7hzz37z671go8wpf4 X-HE-Tag: 1707854124-746554 X-HE-Meta: U2FsdGVkX1+dWtvycdWMQK7Q2roGzbn1vgEq3C1A1hKtTV2RyA53P/EG4zP8Z9MPLAxKHl3DuAwmClfpmOvBIHAN6PKlE6RGzMV5IsApibebJM93kptLD1g/gycnIV8a0kwFcomyZABby24kui2uZ6E8QRLBuNgn62Rm+FJ0a0djaQLW0O18hrHnRqFyCqDlj+eViDkeDNThTBQbL9n7djpEuV0muiR7Eu5wyL0oGvM9tPwpmvnfxdqi3njxuwI16cevVNcPwHe2GaXXYBS2yCDbivd+wtICAA8PREkGs5kHpfIiPWyZYEX9pCgGf+yiqyF6MhO5NcOW+/Lg/1KqYDN+g/S8BBlFkP355hRJAL1pCpezd+BkcjXhwCRe2KF4q64v7OeXxJyDm+xYvvJDofIMVwy4o7N480Q1CQLfsPxxAk3tL51PohJaCQiuKT4w4pwJsKuMQPbKRZsC3SuiQwpzzXLsJ1pGEIlbn8/edMy4lNE5He8cayHnYtaOmyMOKf/WlPgksqDffGsoSDPCn38c9TwnvmUpzFGk1/7Hci72NjvG2azxBXd2OXk774gRi1XlCPFI8RZu7sT1zKKatrn45Sy4lzcV2iV393zKf7tbjKEoHIkbgbctXZCB+a3Vo6M3l286VckKSsipen0AwPbaBntpkXP5ebuoSJVE4TyOODrFBogfJ4I7eRn+KdwIL1lfG5gVp0CGMffi2WkFhTxx3HKA7UddiGrM22CCSLdyHdcxQ5sfzlNhez//8GpWKEWxFOJcY/e3z7bcgfLEQk/WFIUPcmIRLMhKVaM3X3wj8BAAc5BUqnSKCyiZirjIzc7ytf9wy8+ZfGNFzbamZmq6k+uDLhhWX6p4sZFJ9q2HQebdY8Kkhi19jnjwU1kF1k/8FEdhqxrqLXx61vogKrRR97cNogMhEbqK6Do9tVFGUs2GjNkrewNdC6Tv8qUgY82UrGVtaUQxdAJDCYL W38YScgJ Cnvjuf3HQMkIxaAz40fP4XhG2s8Pko+9PPJ8WU72GkNDAc3CVVPTAzNXVMxEcGlCIVT5pWit8uMadRRcpnBjjbQCEMLmVBK6jlIxSXANB8SZh6FBUcAfD7WNEmudzRe2PGma4EWKjZnSlCmCASnaFGw5ST44WN7AGaobob2O9dYURW3WZdZ39oIA3vFP3JWSn/uBMmLyB/hwfCN7NG6tf7yWOwaSBX/xN6O8Kwfh2QF9lqF4F5Nls6+mQWbcL7jnf8DCBLjQ1xOp0A/4WhIeWSKVzOw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000018, 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 Tue, Feb 13, 2024 at 11:51=E2=80=AFAM Liam R. Howlett wrote: > > * Lokesh Gidra [240213 14:37]: > ... > > > Asking to avoid any more iterations: these functions should call the > > currently defined ones or should replace them. For instance, should I > > do the following: > > > > #ifdef CONFIG_PER_VMA_LOCK > > ... uffd_mfill_lock() > > { > > return find_and_lock_dst_vma(...); > > } > > #else > > ...uffd_mfill_lock() > > { > > return lock_mm_and_find_dst_vma(...); > > } > > #endif > > > > or have the function replace > > find_and_lock_dst_vma()/lock_mm_and_find_dst_vma() ? > > Since the two have the same prototype, then you can replace the function > names directly. > > The other side should take the vma and use vma->vm_mm to get the mm to > unlock the mmap_lock in the !CONFIG_PER_VMA_LOCK. That way those > prototypes also match and can use the same names directly. > > move_pages() requires unlocking two VMAs or one, so pass both VMAs > through and do the check in there. This, unfortunately means that one > of the VMAs will not be used in the !CONFIG_PER_VMA_LOCK case. You > could add an assert to ensure src_vma is locked prior to using dst_vma > to unlock the mmap_lock(), to avoid potential bot emails. > Perfect. Will do that and address the other comments you had on v5 as well. Regarding int vs long for 'err' type, I'm assuming you are ok with my explanation and I should keep long? > Thanks, > Liam