From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (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 41CD12C029F for ; Wed, 29 Apr 2026 18:19:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777486797; cv=none; b=txQL7a65miuM69U67bDXEnyHowNj/Dz9fy69WhnZovh8NsZn56px1EJX6fxq/qj/2gC8Ix3PCAiJ0RSIfHqRNq9213ZGROdaGw2dKhwWlrhTJlZIuOrB75b9Uv1k9jgSyPO5qqUhytbfCawjMu5kAdssqIlE0AlC5CPo6yL/cz4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777486797; c=relaxed/simple; bh=FRX2vTZUe64OsKYGu7BHSC2xvcn/OhBeOoXDiuqiV40=; h=Subject:To:Cc:From:Date:Message-Id; b=GzAvoltHsSVMftjiG1yoqGNiytVQoKA2d3D4dNB7V2afxZTReK2AcGeluIFiZ1T6qd2eR1lrOieRApMEYZbKHnqXh9UIIoK/fcr7pu2VuFYY4+QsSDYLZskC6+w56m+EVmTJvMRBHesHBXzlsBPpJLTUTYMnnQHx2q9fDGGra1Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Wrt5xDUy; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Wrt5xDUy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1777486795; x=1809022795; h=subject:to:cc:from:date:message-id; bh=FRX2vTZUe64OsKYGu7BHSC2xvcn/OhBeOoXDiuqiV40=; b=Wrt5xDUyRu8RqCh4nKccvUD4zc21bHoF2/1gegtRHo+aQIES3UHtkIhd HO0beNFcXi/YgsZir7cW7DVWW3InGpknQ1tBTzNraxpW86dZXOO0XiYqe wBItL049Ku13wflVNpnIDNVD82U+pZyLOF8yHy/ulyYDkYkJk4u6EjKMv wgMwBs91RD8KC052eSDC/8Ytl1T2/Pz4OeBGQqdtHVmzU/WAQePbD+W6d MiNt3dC2BMm0sTQhE93eQOhzmESFRaLBUM2v9H2KuJEuu5d8VcSB8A6pj jWR1zKFSEZAiqU217FGl0JBNctx/FC5MnJlCjAFZ1Zp6uM8wnM1O0Dz7J Q==; X-CSE-ConnectionGUID: Pi7LpyzhT5iCCyTZs9ydYg== X-CSE-MsgGUID: F7Yo+wSEQdiptU5Gc7+Mcw== X-IronPort-AV: E=McAfee;i="6800,10657,11771"; a="95990080" X-IronPort-AV: E=Sophos;i="6.23,206,1770624000"; d="scan'208";a="95990080" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2026 11:19:55 -0700 X-CSE-ConnectionGUID: 4E88rhIvQyqOMtF10HSDlA== X-CSE-MsgGUID: WI2E2GjrTc6nlh8D7ggCYg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,206,1770624000"; d="scan'208";a="239336379" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by fmviesa005.fm.intel.com with ESMTP; 29 Apr 2026 11:19:54 -0700 Subject: [PATCH 0/6] mm: Make per-VMA locks available in all builds To: linux-kernel@vger.kernel.org Cc: Dave Hansen , Andrew Morton , "Liam R. Howlett" , linux-mm@kvack.org, Lorenzo Stoakes , Shakeel Butt , Suren Baghdasaryan , Vlastimil Babka From: Dave Hansen Date: Wed, 29 Apr 2026 11:19:54 -0700 Message-Id: <20260429181954.F50224AE@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: tl;dr: I hope I'm not missing something big here. The basic observastion here is that forcing code to account for per-VMA lock failure adds a lot of complexity. This series theorizes that with a some Kconfig changes and a new helper, many callers can avoid writing code that falls back to mmap_lock. -- When working on some x86 shadow stack code, it was a real pain to avoid causing recursive locking problems with mmap_lock. One way to avoid those was to avoid mmap_lock and use per-VMA locks instead. They are great, but they are not available in all configs which makes them unusable in generic code, or if you want to completely avoid mmap_lock. Make per-VMA locks available in all configs. Right now, they are only available on select architectures when SMP and MMU are enabled. But all of the primitives that per-VMA locks are built on (RCU, maple trees, refcounts) work just fine without SMP or MMU. Their only real downside is that they make VMAs a wee bit bigger on !MMU and !SMP builds. The upside is much cleaner code, lower complexity and less #ifdeffery. Building on top of universally-available per-VMA locks, introduce a new helper. Since the new API does not require callers to have a fallback to mmap_lock, it's much easier to use. Callers could potentially replace this very common kernel idiom: mmap_read_lock(mm); vma = vma_lookup() // fiddle with vma mmap_read_unlock(mm); with: vma = lock_vma_under_rcu_wait(mm, address); // fiddle with vma vma_end_read(vma); Which avoids mmap_lock entirely in the fast path. Things I think needs more discussion: * The new helper has a horrible name. Suggestions are very welcome. * I'm not very confident that this approach completely avoids the deadlock issues that arise from touching userspace while holding mm-related locks. * Can the helper avoid the goto, maybe by taking the VMA refcount while holding mmap_lock? * mm_struct and vm_area_struct "bloat" I've included a couple patches where I think the new helper really makes the code nicer. I'm keeping the cc list on the short side for now because I'm not actually proposing that we go ahead and do the ipv4 changes, for example. Cc: Suren Baghdasaryan Cc: Andrew Morton Cc: "Liam R. Howlett" Cc: Lorenzo Stoakes Cc: Vlastimil Babka Cc: Shakeel Butt Cc: linux-mm@kvack.org arch/arm/Kconfig | 1 arch/arm64/Kconfig | 1 arch/loongarch/Kconfig | 1 arch/powerpc/platforms/powernv/Kconfig | 1 arch/powerpc/platforms/pseries/Kconfig | 1 arch/riscv/Kconfig | 1 arch/s390/Kconfig | 1 arch/x86/Kconfig | 2 - arch/x86/kernel/shstk.c | 47 +++++++++++------------------- drivers/android/binder_alloc.c | 39 ++++++------------------- fs/proc/internal.h | 2 - fs/proc/task_mmu.c | 51 --------------------------------- include/linux/mm.h | 12 ------- include/linux/mm_types.h | 7 ---- include/linux/mmap_lock.h | 50 +------------------------------- kernel/fork.c | 2 - mm/Kconfig | 13 -------- mm/mmap_lock.c | 45 +++++++++++++++++++++++++++-- net/ipv4/tcp.c | 31 +++++--------------- 19 files changed, 82 insertions(+), 226 deletions(-)