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 908EAC47258 for ; Thu, 25 Jan 2024 09:19:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F39478D000C; Thu, 25 Jan 2024 04:19:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EC3328D0015; Thu, 25 Jan 2024 04:19:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D640E8D000C; Thu, 25 Jan 2024 04:19:38 -0500 (EST) 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 BBE5F6B0087 for ; Thu, 25 Jan 2024 04:19:38 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6329C14043B for ; Thu, 25 Jan 2024 09:19:38 +0000 (UTC) X-FDA: 81717285636.25.0FEFCDB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id A496E2001C for ; Thu, 25 Jan 2024 09:19:36 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=I9YFo7iN; spf=pass (imf13.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706174376; a=rsa-sha256; cv=none; b=RXBxhikXEaR9YghVgbYNoG/L4m8EKfIZh4IZ0+jsu3hQnqmks9UqrIXu9Yz/dbnDG8E4hc pyVWKgt14e5Ts8x2CHIbQniFVvSXFveM/m6kZDsQZ4IYC8GMDNyiVNI+f1GYQ+i0iOgX87 6f13uzXA4/tlMy6gDO8rAFrC66TZazA= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=I9YFo7iN; spf=pass (imf13.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706174376; 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=V/4AVvNmslg2nUQC2FVtxRZdWu5w9e1UG41H4csg5jU=; b=3lmTvaSsoV9fCDLyZk8iXTtcnPnUCaNwS3JFhueQT+kPNZe9X1Tv5rXRz75tzFEL5Wez+I tLhN3F9dGtHM/uLZatcOvdOelIOL+TYzNBAJYrbuhWxt9MlMXI4bkiJe5UYIN8yIOi01az KbqT3bg6JOVyZaBLx8QX2TB1P6hRz74= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A58DE6213C; Thu, 25 Jan 2024 09:19:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6C92C433C7; Thu, 25 Jan 2024 09:19:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706174375; bh=NZjc35Qt7S6M9EA5YqS48E2pDOnRCm/XMJiCHMje7Zk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I9YFo7iNX55kzndFdCFVL0wREMxKLdLOvUdq7forIZico2OU2+5ZDmLMuPDMDDjHl p7F02pGLX1rkAacyKVfOINWqzUlBzrBwlKznL2nU3DeneTgMHWHqGnoKejq2NlOZt0 dcE8m+ItaQ7SfheRtcxu6VUudGeJGUEivguz4/CBbQFImTvjrIOtTEowYREkE30TTs TiVVdUgyRlgrxrLRZOVE4bcvnZyp+P9PybQn7mHWkzeOkJ6hVMoH6/YwnHExvV1Z+H cbvJNlmdgOl25PfHaY5VKjkeEzrT3FM7hfOnD+WiVceFLe820A3sfwyKbLSH+B5s4b XCNyJv9uBui/Q== Date: Thu, 25 Jan 2024 11:19:10 +0200 From: Mike Rapoport To: Lokesh Gidra Cc: Peter Xu , David Hildenbrand , Andrea Arcangeli , Suren Baghdasaryan , "open list:MEMORY MANAGEMENT" Subject: Re: Synchronization around mmap_changing in userfaultfd Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A496E2001C X-Stat-Signature: cjfqnw44shghyt6pewhfimczns77nqdi X-Rspam-User: X-HE-Tag: 1706174376-134487 X-HE-Meta: U2FsdGVkX19R+tzv/e3gzELswK6xtlk7Rq2pgZvX65KJEK3q4yQfO4FP+w+P4gL8tc9aXrmM8QVmdJhx1JM8/YYPKpowq0UciuGOkWQwsRQ/i5fy3sPaRrY+7IY+aLKJp6oTUnoacPvyyu3nTg03LqceBjecbSckWVgUC6WILtrTPhaQR1St8sR8m/BzHlydJM4BrSyJ17pBKPa+FV/LHzXoGIstiiCVu9QPuf51TIGgTx1+BMcj37THUWyuULzpPxWi1UGS5g+8txbUAJjTAJ+hFXssdvYz91lgxG9/l95HXG8IOYqRocrKpWiKDwIrh8RBwfr27wwo0+Z2hjuuiG9ESQu9z5cWQkLVXg77+OJkJP3MXlxQ/AbR9xVQ/6YJT/xQAj0m+LkdM1LhYALly2bWX+aJyQ4DcuNvOLWH1nJC4CMQGszvn7cbsoWhGlC2kHiF3BZtajIARtpcLZpEaDJWrQqpCuQEzcVDIjRh0KeL0ja3Ice9AgzRoz2TOXmHU2+ICmIta0nKOpIOgsEk1aH8wa9bR/s3XhYUHlTt01dv2SX67KwzDGwuIMy1I+ASaCLFJ3i6mmlzch4C/Zbh+qOKEEFQZbYJT94hxr2KY3LOnkpinmjFB47mSSiG30jqmqgM8h6Y27eOKui7tw0FCehd24niIfampjiwHXg90Id0YTjisw6c4LZaG18s+0ROqDxzesQ5SpwWWsEG4CsJfKszXpfzELklAxlD8mGRD8X4UBDIpL/mqKTPK3py7s0gc6x8+nNSsTCfVBxsaGDpX6qTxqfIpxvq925Y8lYh606I8HrkXhSdGa6iQi/uVpttqpSXDOu1PFSqM9Dg300TIUgEv4sBHYs5C/tplnhiIqykQiobGcKvgOex9x1kbTHXhTUcHkWQFEftMzKHbMO/W4ilLEaPBk6dtQ+9P5MExtezllr5UqRgqkFXYJbUe8tnddmuTipAF2BL/pE52QI ozijlyPd vPF9y/z+niiYijHf/OBIWzTKCjAE16+KqtFTOq0GweNW+70gB0mWF3QxgYbsGGH8MSGRUIWSIdvMV9LtlgNzEHX6ibMOAFeGAlQRAYOXEOFY6zti/NL5wsKtZ8Py159i/+jiKfvde6xkhQtrbmDonxIr8beH6BXRrlAvCViPzd6us6bpvNZ3muj4tP/bUa3LJW344VNTI0+bI+xCK2pWn5xM8/3rctGYkuARdLNenhey7X04= 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: List-Subscribe: List-Unsubscribe: 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 read-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 already 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. > If this is wrong, then kindly explain why mmap_changing needs to be > protected with mmap_lock. > > > Thanks, > Lokesh > -- Sincerely yours, Mike.