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 11BDFC47258 for ; Thu, 25 Jan 2024 15:23:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59CDD6B0078; Thu, 25 Jan 2024 10:23:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 54D346B007E; Thu, 25 Jan 2024 10:23:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4153C6B0083; Thu, 25 Jan 2024 10:23:51 -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 312156B0078 for ; Thu, 25 Jan 2024 10:23:51 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id ECF0380E05 for ; Thu, 25 Jan 2024 15:23:50 +0000 (UTC) X-FDA: 81718203420.01.227C973 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by imf28.hostedemail.com (Postfix) with ESMTP id 54E3CC001E for ; Thu, 25 Jan 2024 15:23:49 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Vk4BkduW; spf=pass (imf28.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.221.46 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=1706196229; 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=cCwnsGwjDLUj1wcr1cNotQlTDBa0t+D5vuHqi6KFokE=; b=0LF+WVXBrcVdoO6LQYehz9eygeFxTWlljpWOa6cUnijKVFbB+Oz+8qUPxL+RYx7aZOzFU6 L0dsHl0aSKHJTPmKf/dY2dWFxrpvRAiMzi3r5RR/ft8XlFnctLduYDbgZQwfwB4X4iPrzq 0gcLUp8blndk8nkQsBGjdV5Qj/1MZc0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706196229; a=rsa-sha256; cv=none; b=YWyd+Ju+fEbllxWdTwbjyI8sdM9NeN4BMfu+v7oK5jVRapZW5+w4gBPy8UTnlRSRpInqBa scNWiRwhmB/MglpzEKa1pHmZtzhswsVM3IjfQT7FcUARkQhfQl/Ial2pdnFwUrDlt8t7w8 Obrv7HaNNjkJOJsZhH1DnlMzboVkn84= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Vk4BkduW; spf=pass (imf28.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=lokeshgidra@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-33ad3ee50e4so203874f8f.3 for ; Thu, 25 Jan 2024 07:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706196228; x=1706801028; 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=cCwnsGwjDLUj1wcr1cNotQlTDBa0t+D5vuHqi6KFokE=; b=Vk4BkduWf4sNodg9XMpIrPHZdRmqxvtrmjtBvikF6y3DgawBHKTk+wI8sclrq+0dSq sy8m90cH5jlrgU1v2d+HcTfkCt3ZIEEnJJEG8FjE/115wVhWbfCIbedVXcvz1s3WTQRT 57zY+g5iH7DgwyI/MC4x0o2z27I03WpKd01+Qc/oWLAOoHccOq0Xo/D6DRKgY5E+dlCX C2B+IM/lRM7dbjsL+4foPqPWR2PDmq5qeJzskwn/eY+ZMbRyWkcMH5fHhWuHMC9QCYla YXxdX9+S0Kl9yTcF/0tS5sPb1NRpx7GZsSd1YVKj6TI9nN4r1eITOErmopnt07qVRrCY ti5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706196228; x=1706801028; 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=cCwnsGwjDLUj1wcr1cNotQlTDBa0t+D5vuHqi6KFokE=; b=aQEZzEb39DgyMgQQMoWwoTvLTGcl0NP6lr/XDDRhNACuXUsUQA7z5NjiCdpkZL/8OS nUcT+5uLdrGA94x3zb0hniEoAi4wz1nTMCeSeVO2xVBLamDHcq4aaqkxDT/j+wxURbrB mShHsxts71y2xS9NN7Uk4eO0QUHv8POprdX81IMiz1b8XAdRd5V4eqZb/0w5q6Q6ZrSK WspyL7NK9KaCW8p21PrGTF9V0Lh8vbCaMg8tkHprcsKJCIWNqW+u6G/KzpFclIT1kWhT ytCGrNcZJS7jfCDfbxmTBn8zWwAtKvtO7/TqPIRX31ySqaEsqlCcWx9iTCjkMgD47/Om 0d1Q== X-Gm-Message-State: AOJu0YwEUlW2dsdULsiL1COw2L6KIoryMsmE+rAnM83+rb8MbakF6Yai 3+RDxJnvm0s8M/LOpxvMYgBbTlrFIPAWmLPDCbsP3LbSSABsYRvA8oFVR9LAeJkFKwnAX9KCrkA 59KiCzSoXukzyY4hAHuf4Nrh9kzfC8mJfJmW3 X-Google-Smtp-Source: AGHT+IFi08rY42wm14HBMDfNzjji0oZyypgNb5Y6YBpOzJ8O6tNI9x3HkphWbXELWocDnvuLsf65NBcqM3nXiCUsMCg= X-Received: by 2002:adf:fe46:0:b0:339:359a:1bae with SMTP id m6-20020adffe46000000b00339359a1baemr333444wrs.126.1706196227677; Thu, 25 Jan 2024 07:23:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lokesh Gidra Date: Thu, 25 Jan 2024 07:23:36 -0800 Message-ID: Subject: Re: Synchronization around mmap_changing in userfaultfd To: Mike Rapoport Cc: Peter Xu , David Hildenbrand , Andrea Arcangeli , Suren Baghdasaryan , "open list:MEMORY MANAGEMENT" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: baw33pe99bg7p5rs6se89j45fa8cj154 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 54E3CC001E X-Rspam-User: X-HE-Tag: 1706196229-550801 X-HE-Meta: U2FsdGVkX19J0YeKRbsrBAtE4du4XDTYpzIA0RER21xqJUMIcnK03XzvZJTjzxWUzC9POqKmzijuOUeZTaSKnZ9w3aqCS3sIDBGh9mKNvk6QB/M0Duem54X2WcLSdPxwwmah7BC+LvP6vmn1A56nXkpUSPYkOBTTuq8ox7J00PS+roFrqBItdADs5wuX60j43G10x9cIcYgNLMrfl9g87o0d7cpptkL0iWiuMMf7BVZJ9+Bka0BPiq87FRkSU1aArA41IYBSzQcXGgKbnL8LipsG7qfUf7cSKym3nc/XAk7x/yq8GbzBzqjvUDxbH9WbRS4BOKnbf/LzsYqm9JBc5Edqi1W7XtadOhHBxiPBgwDk++n8FZdFmOK2iDhm7+kwVdaJliPdP9EWtd4y55MHpIpSPVVmQM1fyFE+A96ImUS2xoxyitEXDAdBPFmb0Og4dV69dQUYJWmOPd5xoYGgPxLXz20T2sc2e4DB5OQko3CbvqaDac3scWWPhKrJyV1dIe34tmsj7mcse8lTPwyCYF/oiijD7+3aYB7xGrRJL1aFseKDGckYx04cz6EqnJhMoMLOhMXEP4bIi3xOukqdPrPyjOwL0EouGy4SvDPMhy1XaibHgdGzPmnmoCe2J1gGWBboicXD4BAQwAPL1LpSoS40WEJHWw199HZfxN1ckVeEOi54cK6nobMj1UlkAdvpLGq1lSngDy0vldsBQdBunj0VMuYLm1vDsvYiISds7yJSb1FXOyRKJNxGdEYLLH3wx+6AVtszm5pHKqqU3i6Meg3tLCwOmYkJDfSua+CYopc+lND+grxyUoKhOW8Evrd3CdugIMD0+Hb3BbF5uZT6ZA8DP/qsLS+TbZEhuZhWqNhAWZRj9TgVSQEr/VwAnOmt2HFmGUO4LLg/cvZ94hTxnRIfmkRdeAZUSVsfUciK3DqmsgKsIVHhptgXpxTQfOCyWAvuTuclhHSX+RdC0+1 uK1tnRjt DAgYyA1hH4zgpyBKlzDbQkHDdrwTRuRFIhU4l X-Bogosity: Ham, tests=bogofilter, spamicity=0.001230, 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 Thu, Jan 25, 2024 at 1:19=E2=80=AFAM Mike Rapoport wro= te: > > Hi, > > On Thu, Jan 11, 2024 at 03:32:20PM -0800, Lokesh Gidra wrote: > > Hi, > > > > We have been seeing mmap_lock contention issues while using > > userfaultfd for GC in Android. But now that per-vma locks are being > > used in the kernel, we were hoping to use it in userfaultfd code to > > pin the VMA in COPY/MOVE/ZEROPAGE etc. operations. But while going > > through the code, I noticed that mmap_changing is implicitly protected > > by mmap_lock: > > > > 1) All increments to it (except for userfault_remove) are done with > > mmap_lock in write-mode > > 2) All reads (in copy/move/zeropage etc) are done with mmap_lock in rea= d-mode > > > > I wanted to understand if that's just out of convenience, and > > therefore would it be ok to introduce a read-write semaphore in > > userfaultfd_ctx to achieve the same synchronization: > > > > 1) All increments are done with this semaphore in write-mode > > 2) All operations (copy/move/zeropage etc) are done within the > > critical section of this semaphore in read-mode and checking that > > mmap_changing is 0. > > mmap_changing was added to the existing critical sections that were alrea= dy > protected with mmap_lock, so I didn't see a reason for additional lock to > protect mmap_changing. > > With per-vma locks, your proposal makes perfect sense to me. Thanks so much for confirming. I'll send the patches for review very soon. > > > If this is wrong, then kindly explain why mmap_changing needs to be > > protected with mmap_lock. > > > > > > Thanks, > > Lokesh > > > > -- > Sincerely yours, > Mike.