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 737DDC47077 for ; Thu, 11 Jan 2024 23:32:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D9D836B008A; Thu, 11 Jan 2024 18:32:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D4E2C6B0092; Thu, 11 Jan 2024 18:32:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C16086B0095; Thu, 11 Jan 2024 18:32:34 -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 B06146B008A for ; Thu, 11 Jan 2024 18:32:34 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 85D37A1D7C for ; Thu, 11 Jan 2024 23:32:34 +0000 (UTC) X-FDA: 81668631828.23.389DF84 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf04.hostedemail.com (Postfix) with ESMTP id DB69A40003 for ; Thu, 11 Jan 2024 23:32:32 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=QKtVuf5e; spf=pass (imf04.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.221.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=1705015952; 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: references:dkim-signature; bh=A9eqyOy18My10ISgD18oqLRigzPl+pTIxC9ZYY4zycc=; b=1pP5PN3L92JrSixa+Wh5YeVky3IjbyzOsaW6m/7bmpWzxJ3AX6PiTFp2PSxdPbMs1pP7qc AcHvSs4xbhK5hDiXXgHrc5L2d8F18df8IS6yTdxGd5RgD6dgbc/RRfBDWjD60SRcwC1+k4 ITRekIx2A/voYuXJbexUGKX3qMl37h8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705015953; a=rsa-sha256; cv=none; b=LYFNgOAev+KcIX/l6nrWU0h4zrrqxqecHDxuWLvh/q/CJtgqN4PGVd7Hfb63Lba45cDAyt /KL5waPD/9ZY7FHEmcZ28Y8jsnRYVJBl2Hqpp7zwn3dhVzchRMns/9WXcMDJj/6Jt1frRA CbCDJpO/gK/33Zj5abV9wdrr9iR78BE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=QKtVuf5e; spf=pass (imf04.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=lokeshgidra@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-33674f60184so5551771f8f.1 for ; Thu, 11 Jan 2024 15:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705015951; x=1705620751; darn=kvack.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=A9eqyOy18My10ISgD18oqLRigzPl+pTIxC9ZYY4zycc=; b=QKtVuf5eAUZwmMGGOG3a00B2fBfCJwxQf6Hdcr0tpNaD0a63dIfr7xEr75bmy3CVIB jUKvUJDvXGuRY2u3LET3ILx/koN9s/qOkZCuGOL7qulE0vCKb3MI89FtgyiGxyIRchqn 7xL9N3Cq9ARuB6LOdepJj0KLG3RQ1X+b0s9t6BvJjBu6JDBfSh9SmhZvPIWTpt2TxbBR Ig1s5dTieg/0kpVE3y2/k+s0N4TR+P6TqrFseyusMIFvdxvbszt+zanjQ97jQtQsV+xN lm66kyCVOeMKy85ifH4F7Cqeqo1wYRb007TRQ9aWHUV1HEJ15fmH/ZN0IOM3paDT5lDw 5vrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705015951; x=1705620751; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=A9eqyOy18My10ISgD18oqLRigzPl+pTIxC9ZYY4zycc=; b=FApmrIX3rR1SNI9AM917Y7iP4bJ5u4wo8bewda0ntTUMJ/XmPffkMoBS3iz9LNppsI w61r98zd2+TmyRq11D9HwYzrDwgtTl8H5qmFHoXt2MWc+/Teu+nYjGAsPJVDEx8Aj+9S mZGu230HRIyJbR5eSlmseiNCz7G5PPGHjIbzYSHNt0iLRluuZboCExU6bH4olGY822X2 2/4sb7K8bu6v9gQOL0t74NAq3Hbyy5mb8dsK/sRRuA9g27Cx5RWzeU2ecTmdIxdMmsDl JDP6aL0Z8iBjAjZxKDUmHsBYgUZKgYsBxY82wk7rfmxjNoZSSPFJPKva7D4ESFgKwPl3 D2pw== X-Gm-Message-State: AOJu0YxGVSi9pXP2S6Qk7dvu6TCYijqJNO7l8k+c3ZWsqBBW6ao7aaju 0IowtjIREh8C+EZvkB6p9TjZu4xo6G/m5f3isEfr2YqjYEiK X-Google-Smtp-Source: AGHT+IEqKubCJunp6hV7i/7LAH1/bU+qi/WMAOACnCj8VQH13zvGLCjlsXRN3QP7GN838Y+M+8e/uOp6Odk/s/69coY= X-Received: by 2002:a5d:5111:0:b0:336:8c5c:fb78 with SMTP id s17-20020a5d5111000000b003368c5cfb78mr206451wrt.83.1705015951235; Thu, 11 Jan 2024 15:32:31 -0800 (PST) MIME-Version: 1.0 From: Lokesh Gidra Date: Thu, 11 Jan 2024 15:32:20 -0800 Message-ID: Subject: Synchronization around mmap_changing in userfaultfd To: Peter Xu , David Hildenbrand , Andrea Arcangeli Cc: Suren Baghdasaryan , "open list:MEMORY MANAGEMENT" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 6sam5q8mrin8ra58iut4cj68cnpkobgw X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DB69A40003 X-Rspam-User: X-HE-Tag: 1705015952-480918 X-HE-Meta: U2FsdGVkX18n3lZqnEgw++fwO94CtahoUL3HUbOAXDCSvwU2RlwWr6tnZb9N8akbM55Ddtj80wry7M125aDoXS3zUh2G3/La6KuIn3V43fm4FQJWzEK9YwaDEhxdGXz+SUEYAl67SELH1HgDoTOWjhskBoD28PR6qbkOI1P/ByvDv7+V+VKiGrHfDCWJ+jUe+DnnzFwcjsBW36in2KURofkj/IbvNf164xGvvNRQiEamgDJhJp4mOk89OJJ70c6qbegHgQe4FLuBQTnzQ+3pAYXu1xcwo/sQJt5Rml2O0QNxU5pCMT+YH7rw4LG9TzxxO9vwc1n7rg6/sLCZz6jU0TH9Kc7JT3f5txgaMAablMz4iXT0v3RH72EyplbUEauB5HCafCLNerrJBM/gDd7p9uNQ6phWCRDRRv8PnfLswgdTSdIByRhIJqf382Uol7wrfzpgyT9n8ZNAovFRxuH1C1E1Au+E0ReYTm0Dqieht6EEcDQAr5JgwA/4CKcuFvpSD/p3zW6xfH7dxhYyOXpK4TdyewO91VZZjTsUCbr4yV0jqMjKs7bWuv3iOkJEct1hhbHhIxLp9+ChYD/KX5ZDIaerXBJo4PL3uEfwT4nO0a2RnVCedh13TjSfV5YqZh+uVUaXQzjibiPOOn068PVvtb7AaroUOWqhbgWZzMYQC8ssgtv4QpOfTDOpFtNsMlxsFAk5NiF82vISp4WH3clpvWPLxhRSOuYaxHvkT3WehyZysQiHvw7zPtHoSUFBFmvNlEy5POLRJovZwCok3uiE68HQmCjzmqsaIwfTF58V03nH8unp6V9A5VOd78iIUaBXRx45jnDOGFJUhJLAqarPXc9DNWlg/w3YpkhZtkf+wCH/qNlg5n7BEViT636WZkXotRrZ8Z5rW+kZQsPMlLWalQDB95V94xGwvdJNvbC2jEv+3qEENtOQxxj5SJJz4JGmsr6fvYeQDTB0qYZkFVB Zf6X9Yw/ e2xk2Eb5mzaSrSsiPs2NJjcW/XWoKEZOtJw+QvrCJopiXxkaPvjYX2C3Jyq+UXB/dXA2CgoVGxQ9si5jYF1bs8Q7IbiOJ4RBfRBkwG/42auDLYQeYmTUz9mJd+0FE00krPnZENEyvV/CZ1mlOQhRYDTFTpxP/5P/shTh30cFA8VV3iLMBmKV5wcs+BEIQFpWIlxb80jzy2gCw5FUCpJsVdIN6/FFmNRKKcgXODzG6j7At3zIdA9JxU3wQiluLN0l9Rt85b4OVsuq2ZHE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.377988, 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, 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. If this is wrong, then kindly explain why mmap_changing needs to be protected with mmap_lock. Thanks, Lokesh