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 8D41BC48260 for ; Tue, 13 Feb 2024 19:31:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B6126B007B; Tue, 13 Feb 2024 14:31:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1646F6B0085; Tue, 13 Feb 2024 14:31:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 005726B008A; Tue, 13 Feb 2024 14:31:15 -0500 (EST) 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 E05A46B007B for ; Tue, 13 Feb 2024 14:31:15 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 38031140CA5 for ; Tue, 13 Feb 2024 19:31:15 +0000 (UTC) X-FDA: 81787774110.28.6BB2FFC Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf23.hostedemail.com (Postfix) with ESMTP id 8E3F314001D for ; Tue, 13 Feb 2024 19:31:13 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zZAFEFux; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707852673; a=rsa-sha256; cv=none; b=q+QvMsOG5MpBf+fXji6n4BDGbavDsw5/a8oiKnvmuCAuhWjVTJNBVunBNvQOi0rJItT/C3 2E7lzArH+S/gFoYtv3ZBxCw5lahVkPtrQMDVqXMxwj2iFPirzN7Yo6do8032TGXO84vdF+ 7VPSiFrf1mXovi3zj3+sBKj2sutLS10= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zZAFEFux; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707852673; 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=Tw2rowHIbPAqoJMrxrzUcDB4F9+J8tItAzgiEGHiSEg=; b=L9ATcAzCSqP7ADtXANMukAjsKdodqpKoGq92ev/wn4uVUoH9p58EQxAnW0Tk1P58G26fnd iOk6DO9SdpxXWP0Lgk0VAgO6gBWrf202oUsR9HGb8fQQZhYkvKvJRJ3ycAnvJI6rS59nuN AAvXs6pjg7R4oaa6l2waLOQu3I912m8= Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-dcbf82cdf05so1675215276.2 for ; Tue, 13 Feb 2024 11:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707852672; x=1708457472; 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=Tw2rowHIbPAqoJMrxrzUcDB4F9+J8tItAzgiEGHiSEg=; b=zZAFEFuxkc6pPk2CfRUgCvMazhhGiH4Adn0Fd8iLkhuzO3E7XGo0nx/5viapNSU0Vq gKCpsFF8+/6uvk8IV/OfxDA6GPDLvvLSZyvRahO1e3r5437kVJRs9nSuo3z1d/Kx+tm5 pl/qJph+eGJswMQBnjqSDVUCl1vT1p3gbATUtwsqhmxSUFyZZT8SanQTbWXpayM9c6Yn 8eRe6sVkHufRDdXD+cgf8X+WX0Td8zdZl/nh04JathoYpgY8Radhqowj2vTOojr+sg1g k8+WpExvasoLZL7F4Q66mAZ+JtdSLBlCm/4+OXqlfK0CdzCq36SdyeRB0Zqbt92fOSfk kuKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707852672; x=1708457472; 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=Tw2rowHIbPAqoJMrxrzUcDB4F9+J8tItAzgiEGHiSEg=; b=PxkLEiSEiThzUEwni+wJbb0pUdO0LgD596iT8RA+AXag2RBarrZ3s3+MC/YntOUnvj 9voxtMYJ79TNiZWwV2LbOKv+xnkz6Xdws/MaHlJdJboNm6atfx9l7h4kmxligPa/lBYO HLWiW/IQDPUEGLX7TaIctDf0QCeeGzoyJorVcvduvL2tndXQxw4b2VDwwkoJBJxyLqEG v7rX0qfFoEDuSlofrL3hUWEGbCYfdud/ZtuGF0pYIi391vXxuMT+En3GwwI5De0c+YIX fTbbseQh8/tyS1vGM/wwwbh9+dETREX3vj4N2qisn4iZPJwJFTjdA4fuTdwsSlOYBHs8 IyQQ== X-Forwarded-Encrypted: i=1; AJvYcCVYKpQNR5V3ob2Us69TbOAhQeE0v49/f0vHObns7xUqVSywVHSQValQFSzNN+YoE2ELCt3mDTS4yxX/aanB9jCDPGc= X-Gm-Message-State: AOJu0YzduyDFE0g6L26/rWoc4GnMBWkzOc/C8rTnxtR/4+c5J7qvrHcI z8+he0XDxI9ZrzE2pGCE7SuS2acbQ78LrbjxA0/WfzVk9pwz6xYtkAgQN0G7VT90JVtNPCQfqby pR7tHHvusRJWR1bYeDOb+1kvhkL+sqw89GNHF X-Google-Smtp-Source: AGHT+IH1xmQOWfh9dLSe7wwpBx5E+EKefS15CBVT4ddX57A9DakP6t15fuP5oCCtN0RM9L0M2M+VsoHEc/lviqBqInA= X-Received: by 2002:a5b:b92:0:b0:dc7:4bc5:72cf with SMTP id l18-20020a5b0b92000000b00dc74bc572cfmr277658ybq.14.1707852672365; Tue, 13 Feb 2024 11:31:12 -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: <20240213192744.5fqwrlqz5bbvqtf5@revolver> From: Suren Baghdasaryan Date: Tue, 13 Feb 2024 11:30:59 -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: 8E3F314001D X-Stat-Signature: swytqf1n33fs56pjo7k6863w63q7ccjb X-HE-Tag: 1707852673-615980 X-HE-Meta: U2FsdGVkX1/8Jekp8drdVNai15HFbCtvloQ60ZU9Y2qL+g5Rkdz9Uw1yKWVe+3zWK1uXq91x7LbkAt/HoXcRG/hmAWTcA7W7EchwROp2VNPf1pin5f9eBV7q2sO1nh5kmIXCDJL4UaJJpb01wgNrofvBMKrKM7Lf+x2xwNbewLYy+ax9wpQEVnj4oUC1ycrRQ8XIAkvUNFI1fcmrylgXYbzuzbJFhH9LAPvvxlsrY+vmH3gY1TqxgvF6K5sEw98od3NS4xQ8QZisthposGapNcFeU2khRwHt8B7DAAQwt4GvqKTGjyiE9xcpTLiPmfsiJ9gfxsBaa9e+Ct1UWaKoPMPnUqbFez2ZjxjKxBMeoLX+QNM5ta3j2JxetgPeYMz0wI8urhrbgdrwZ2XXioHhHB7q4oANZqGZ4EzyL0bipXz+1KbPhhXsyTOCafxYkLnCj0znRPsDijQs8VjKplcFzyFPw9bwnu6tYPZiPqKOH7qVLFwrj8u8NvZJmos5YgUbsaXrBeErqJR+mLeMFrY24GQaXTnLgzd0bZMcdo1C1KPqAGOFjmtpOVRaMD/IIiXgYqC9c2XWoy7RuCLd9gLCNkJRUC3DvbjmsZxbeW0PeL0C8cCErCQns98pS7Laae3kRNxI1e2YUk66r193US78lfTQZkN9SIRyLRlsXQS9Ot+TuklFHXQIG2B2tEjkYYjExaPB+o0Iyl3LaqfEYSanqZnBtpyDiHMAX+slx4vMhBczgfd77zUqZm62zZzeNvpSfdUd4vahWYtRQLF9xT+Gp9NCHbGDHVDG0rAoS40nWhCA7W4B7VXj0914EG/HtuiM+2bTEduu/QB/McY54j8f2k00ZiVs/mM46SE9aoDVeQGh+uu0/wx6ANBHeImHOhKdsc1ovkfPvZVEWnqCm8yJ/wSFU2e32tOVVmek8Earh30TeWJADpO0a62lDzs7Gc+u8F+yyB6OOK72VsyWzgw n0g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.002721, 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: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 c= aused > > > > many iterations of this patch set and that clean up didn't seem as = 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. > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >