From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B000570830 for ; Sun, 2 Aug 2026 07:40:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785656433; cv=none; b=laQXQCgBf6Ik3Tedj4n+C95fPBCrw83153olDSIAepBC56OT8Hn4Eg5F8cn41DBFYOjymnCU6LdRG/s+0AYuJLwbhe0HOnZjDfddqeKU7+eFh+2YTm8S92ma9hkoePPTi/8ijrz6KF1aFczcCGF5UfsEWCSQ3HLyVPeNVt+tuIE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785656433; c=relaxed/simple; bh=0qGa4jiKTszf6AgoJctOmEdiIyLMzlDkhqiYSz1Koj0=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=BS2mBzHPtJFw6gzcsxAsU0BLFaF7gldKB3G4QeCwNRd/1mEH0qKOh6qRCHez+X11sDShpqqQj82HHdTlnqsUm+5Mfwl8lTzG6cXs4kkBF1BTQoNCUchQPZb5g7yaWzcet72k79ITnFoIr0o9Xrc+kBDLxONPcnF6y2ACrfva728= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RXe5/6cc; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RXe5/6cc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A61EF1F00AC4; Sun, 2 Aug 2026 07:40:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785656432; bh=46jnfdwMlaNGY+WPjRsEyPBfOheE1oNJe3QEnsupnCk=; h=From:To:Cc:Subject:Date; b=RXe5/6ccLygZW7M8ERjzrGvEej+jrQdq6ny54rod4vAmYz2OQqbcb/EKy0q5fC/v/ e17Uvg16pRJrAeyKJ8NhtBIC8s2Rkkip407p/Bp5oJd1Gp1AcgRHoSbLd/HQO7Cvp7 SE5fTt6PDfxYsIihDlUBVIs6FP0TQpDgViMCS2hIk1ZhybI1v7cs/tDNm07jBBN201 0cVx6iqEqpRvgahrMOIMUF1aHhnrAjWdzUmvNT8gHOMK+8U00SFQDRGfRxzfrzTwYB a9Azh5+Yp4oxVMXGM4gTwyhFB+mnWgFo/QHeep6CojMG+HPRK/EklnyD9jaZTxxn/D JWgEe1I5S0b0Q== From: "Barry Song (Xiaomi)" To: akpm@linux-foundation.org, linux-mm@kvack.org Cc: x86@kernel.org, linux-arm-kernel@lists.infradead.org, surenb@google.com, liam@infradead.org, ljs@kernel.org, vbabka@kernel.org, shakeel.butt@linux.dev, david@kernel.org, linux-kernel@vger.kernel.org, zhanghongru@xiaomi.com, willy@infradead.org, zhangbo56@xiaomi.com, "Barry Song (Xiaomi)" Subject: [RFC PATCH v1 0/2] mm: use VMA lock for kernel faults on user addresses Date: Sun, 2 Aug 2026 15:40:16 +0800 Message-Id: <20260802074018.73887-1-baohua@kernel.org> X-Mailer: git-send-email 2.39.3 (Apple Git-146) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Right now, kernel faults on user addresses, such as those from copy_from_user() and copy_to_user(), unconditionally fall back to the mmap_lock path. This patchset switches them to the per-VMA lock path for three reasons: 1. These faults are common. On a typical Ubuntu system, hundreds of kernel faults on user addresses occur every second in python3, apt-esm-hook, package-data-do, teamviewerd, bash, scudo, cscope, gnome-shell, systemd, and many other applications. Handling these faults under mmap_lock unnecessarily increases lock contention. 2. It removes one obstacle to simplifying filemap_fault(). Matthew has proposed removing the page fault retry path and performing I/O while holding locks [1]. Based on that approach, Hongru has already reported regressions caused by performing I/O under mmap_lock for kernel faults on user addresses [2]. This patchset removes that obstacle. Another source of I/O under mmap_lock is GUP, which also relies on mmap_lock today and has been reported by Hongru to exhibit similar regressions [2]. It appears Rik van Riel may be addressing this separately [3]. 3. The current implementation is inconsistent. Although kernel faults on user addresses always fall back to mmap_lock, arch/*/mm/fault.c still performs !user_mode checks in the per-VMA lock path, making that code effectively dead. As an RFC, this patchset demonstrates the approach on x86 and arm64 only. Other architectures will need to be updated as well. [1] https://lore.kernel.org/linux-mm/20260625195040.2508362-1-willy@infradead.org/ [2] https://lore.kernel.org/linux-mm/20260712132759.2030823-1-zhanghongru@xiaomi.com/ [3] https://lore.kernel.org/linux-mm/20260724222934.1463812-1-riel@surriel.com/ Barry Song (Xiaomi) (2): x86/mm: use VMA lock for kernel faults on user addresses arm64/mm: use VMA lock for kernel faults on user addresses arch/arm64/mm/fault.c | 4 +++- arch/x86/mm/fault.c | 3 --- 2 files changed, 3 insertions(+), 4 deletions(-) -- 2.39.3 (Apple Git-146)