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 1AD54C4829A for ; Tue, 13 Feb 2024 19:37:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 959546B0098; Tue, 13 Feb 2024 14:37:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E2F46B009B; Tue, 13 Feb 2024 14:37:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 784396B009D; Tue, 13 Feb 2024 14:37:08 -0500 (EST) 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 5C8856B0098 for ; Tue, 13 Feb 2024 14:37:08 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 29A0E160CF6 for ; Tue, 13 Feb 2024 19:37:08 +0000 (UTC) X-FDA: 81787788936.26.46497EC Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf25.hostedemail.com (Postfix) with ESMTP id 4D418A0003 for ; Tue, 13 Feb 2024 19:37:06 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Ted7pX8p; spf=pass (imf25.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=lokeshgidra@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=1707853026; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=di/4NnCIukfz7My68Fc8zeRyDvoUNBZ0RwAPGewxckI=; b=EQMExN3hzYs5syxpm7yqvdZMLzzBCmwS75mhvF3nYeBYjv2lFu7zumzhcSGTvR0itEhAAA OR1ZRSFquFlihggFUDg0H7quxpeoaMBfKUoNqZn8ePpy4ieSAbse6GDLrNfRY22NA0sUut IwZ3EVzeYkUSb5WKIzvPzmEHItwPVAI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Ted7pX8p; spf=pass (imf25.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=lokeshgidra@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707853026; a=rsa-sha256; cv=none; b=hc3Uk3t8v4KmSOAKAiXJ0umyQvBdEgOMTrwr8kR4hV1oXBSRCaTrs9ZVfMOQXdwz0ZVaOK s/R25iZowxA0R6Ihw3ciDuwCCpcrHasm77pY14MJyVMlhLKq8kD9XgIT7qPteaRofflJAZ RgNn+BmVU+hJotjB0/SIZqdgYb1wHb4= Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-410e820a4feso394595e9.1 for ; Tue, 13 Feb 2024 11:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707853025; x=1708457825; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=di/4NnCIukfz7My68Fc8zeRyDvoUNBZ0RwAPGewxckI=; b=Ted7pX8pvxuoYZ/WBaX5JSBmziCuQJttxHtabTfwUB+lvhxXWnjXWMU4toqjWyGsxj XseRMzSAVd0NvqD1tawJr1pYjg1cmk+in3ssU9LnqJ05XH8MILTr5aOY3+ujLVcqDb+b LJ0AggVZu4VYx7Bj5gsi8EFFNW5sU2cAkbI9decGySMREgWAhVXqGcmk9Gm9d0MUkShz H4eVhoUTA71dG6H413/Yidb9OQ52jxjgYznLPyX/jhDOf6Najr8ByhqcRirs3cJNd65G 7Pf+P1GBJBIzWnm6MFdCYshJCeDRpEcukLV2QfvvlMAqDxHc4Pe5V7pmFathyqJAZV/7 BrGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707853025; x=1708457825; h=content-transfer-encoding:cc: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=di/4NnCIukfz7My68Fc8zeRyDvoUNBZ0RwAPGewxckI=; b=v2RpkhqHa9FbgTZh6e25FSA6GYTDMnKP1aJx8Iz4oKxvND5g7Ic0qHjpZP7m/bLFy4 cdrvdQTB3TLS6k3kLHwaEtJqzc30a4uKQ22VyNNdOIeZQsEY+/PWr5RyEh1DaeX8XloD 0FR19FVZCgaZGGLtomkhoOZKpo0Po78hXZhaTadoxTT3HFXT9N1cn8JzaHIUQYDBWEPM 6l7vHRf6seQODh5r7d7Bwz+foJZydodQ95SSlFtW9ms29Y8y/HrLGpS2BeJFoi6rXWgq 2Rzz5K3L5edU6ZYHDDRjUcKlD/BG7MnnPmrC9cFj+Z8x/B5hkvLieXG0H7/x1y0ytFs0 FFbA== X-Forwarded-Encrypted: i=1; AJvYcCWbX1hRQ82OXw/UTTj7nq8T8GagDq4MOdBptN0MtT6FuuHLYshzIR0XkYcvaFkFb0FWQtY5RCC6YrEm1+vjR08aR4E= X-Gm-Message-State: AOJu0YzPE11zeyB1DN9guIR9IWAWI7QtSlSCk0k9O42dXNO/EKrPHBUu f+NiKfgn9f1FwwinRw5eZRBfDIhz/4uoiyTSBQlI5w/SPB0SqJ9Vj9i2mUsHx7x8eLyRZj21pL4 +AwUlKT8uNAxVdQFutgJM56j2PUCF1BQKOeSW X-Google-Smtp-Source: AGHT+IF/X0BETIZY0DVItf74GRHk+a/+RMMSZBAlSw2R6aVsGAmjD3msuAjj/xJbHNp5zhWUpY5vNmKVyF9bPKq3C3w= X-Received: by 2002:adf:e946:0:b0:33c:e084:aaf9 with SMTP id m6-20020adfe946000000b0033ce084aaf9mr448611wrn.4.1707853024662; Tue, 13 Feb 2024 11:37:04 -0800 (PST) MIME-Version: 1.0 References: <20240213001920.3551772-1-lokeshgidra@google.com> <20240213001920.3551772-4-lokeshgidra@google.com> <20240213033307.zbhrpjigco7vl56z@revolver> <20240213170609.s3queephdyxzrz7j@revolver> <20240213184905.tp4i2ifbglfzlwi6@revolver> <20240213192744.5fqwrlqz5bbvqtf5@revolver> In-Reply-To: From: Lokesh Gidra Date: Tue, 13 Feb 2024 11:36:52 -0800 Message-ID: Subject: Re: [PATCH v5 3/3] userfaultfd: use per-vma locks in userfaultfd operations To: Suren Baghdasaryan Cc: "Liam R. Howlett" , 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-Rspamd-Queue-Id: 4D418A0003 X-Rspam-User: X-Stat-Signature: au8mpst68pfp8qdbd743oabuwnnpih4j X-Rspamd-Server: rspam01 X-HE-Tag: 1707853026-139406 X-HE-Meta: U2FsdGVkX18piCKb0xW6RwDJ04c5OeOzQTZanEWmQDR4J7aj6WUy/UbLvWK5RXcF+mX7rtr+AsicTTfeOnRMYirtcCcqR4c7eE6lMMKitwBkKKqbq0A9mo2maplYj7wm4VxGrcUHqFwXWR9Tm+GXIJcuGq3CjpqhRJNTSHxsMlYKIO85HnDUEYhGBaED6bICEu8Pb3c3QNkJU8c+0URCUv/MuDyfNXK/k2dyZI38Bsv+VluGSUB6lYJTT7S/JMgzOyxJWhoThLjKXKEtix6ZDK2hF91AMMsR/Ap1kncspdpWZkIRJzrrXtbGnGKJ+YmCpC7HIkfchHcDtlOfK4DV7vI6m4/iqjtSoBjAzSu13m3O2cWkk3pSsMgUwxQuKXV45e1xTjGawO/Z14Vz/gnwMKQgNNVJigd3nbXAnm1To4DmGxwDwdqs0gZGfwobLZOw2YpWcX6AXOCLRc71S9aVgPoVSFITFIf6BkWXyLjjuUaBZUIMldBHOxxijy8d/LuiGxueP/E3UoV9V9sYiHw2+YIkn8IpuCLbhOkKLQDlswU/WkQIw8ScDEtkLzkjsMDsKiw5ICvBtyDKAabd4jivPZh7Vgayg264i4RT5GUd2jUrakBsyw+2BTaVZhIFjOHdht67nbuZPwOBWxPIl7gdosdyiES88LrYFop70UGKiTqjzRiq3faM+j/OFx/144u7p3yWd9vXonKHQSvtiOTzYjiqici8MewOUs0EgDP70SVB65EYSRTFufof7PwKHw/JW6KmIGIlz035ByjGDJ4BUIshZ7z89wBQbdZe8t+m6r6dwCxDPDLt4Rr9h5qu36vnD1uaNJmKLfSY+nZ7CViRJS62btL0ystMSZY8GcFRo2UWV68UjWJpQQQ8ZuBsl3S9um+5oy8jcUJJZaDvCtCaXUnbDwMciCATdfuxhPYqJUBScmaI885rF9M1rPzLLb0K9b9Ces9vJWxG8wvr6Xl ym/i2zXU YJUVCSt9xRJZj2J0LV5dVk84BjaxYbqvk/Fkc3Y2tssXYy5PxU7o8P6sImAgAi7eh9g2d3UA+Q83ReuCf3oMrBKDtStLiKEK5aZhAkMp4goPY+Oa1WkhqILjHLGAwkzvtO4dLmufK8Qa3+nu5kcfORc/qcZe8wnTiyzikBYRtszf4Rt9G4agO1ZIN9huNwRPIPjt1cC+KnbZneUQEhIxOOwrYKk9oPGnycMh4s5qq0NIErxZuFOW0u/EztAMhDGF4efJe8vEpPM2AzCB5iYKL+x2CbML8S0H8CtmD4QuUaFkGXgBFeb6dep9KF5udzzfdtYnB X-Bogosity: Ham, tests=bogofilter, spamicity=0.000065, 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:31=E2=80=AFAM Suren Baghdasaryan wrote: > > On Tue, Feb 13, 2024 at 11:27=E2=80=AFAM Liam R. Howlett > wrote: > > > > * Lokesh Gidra [240213 14:18]: > > ... > > > > > > > We could use something like uffd_prepare(), uffd_complete() but I > > > > > thought of those names rather late in the cycle, but I've already= caused > > > > > many iterations of this patch set and that clean up didn't seem a= s vital > > > > > as simplicity and clarity of the locking code. > > > > > > I anyway have to send another version to fix the error handling that > > > you reported earlier. I can take care of this in that version. > > > > > > mfill_atomic...() functions (annoyingly) have to sometimes unlock and > > > relock. Using prepare/complete in that context seems incompatible. > > > > > > > > > > > Maybe lock_vma_for_uffd()/unlock_vma_for_uffd()? Whatever name is > > > > better I'm fine with it but all these #ifdef's sprinkled around don= 't > > > > contribute to the readability. > > > > > > I'll wait for an agreement on this because I too don't like using so > > > many ifdef's either. > > > > > > Since these functions are supposed to have prototype depending on > > > mfill/move, how about the following names: > > > > > > uffd_lock_mfill_vma()/uffd_unlock_mfill_vma() > > > uffd_lock_move_vmas()/uffd_unlock_move_vmas() > > > > > > Of course, I'm open to other suggestions as well. > > > > > > > I'm happy with those if you remove the vma/vmas from the name. > > Sounds good to me. > Sure. I'll do that: 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() ? > > > > -- > > To unsubscribe from this group and stop receiving emails from it, send = an email to kernel-team+unsubscribe@android.com. > >