From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 A102534CFCF for ; Thu, 30 Apr 2026 16:52:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777567925; cv=none; b=apOqtGweEaDFABvidQAamuxwuIkoEJ5PsqmJ1i55XScW1DTOI9cnUjhtV1ocGQ5tClP7ZAeWMS0izJox7tALFoxvBLsV3LMfGQ28HFmV2W/vyHWFzoLIK4hxGTynBlGQdB0spZzy6UJG9XXThfeAvj5Z1x9FR4rYEJKcHA3JqME= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777567925; c=relaxed/simple; bh=IxARCr1BqsacoLcWn5yvwiS7Qt+sQBTsSEDWAF9CTBQ=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=P1Zmkqa6iok7BpSgQtHSgXpoMHD2RD4EqC9xyXuyWzRM1qfYOE9C8nR0kUGmaRYBm0ldIRk2ZAAnAq4xtYLAGX8YKNIGhDkBQ0rrsozdtyXyBlIaUkrcdD0x2yUATzsXK9VqfkfhzpkLNdXGqkmbjnn6MppDZNZF6mYO0vR7Sho= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=j+Gyo7gD; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="j+Gyo7gD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1777567924; x=1809103924; h=message-id:date:mime-version:subject:to:references:from: in-reply-to:content-transfer-encoding; bh=IxARCr1BqsacoLcWn5yvwiS7Qt+sQBTsSEDWAF9CTBQ=; b=j+Gyo7gDphXjN/PZq7TStsx3e1Ofbdgs4MBxDQPgi8GO9NYkyBfrOzfx NbSset/PgrVO9l+QaU+hIms9tTGdPfoJhEfJL3BgsRT2bnUKXB4PVSbA5 6JtqaXtO41+IEZCEGnV7j4xCwDo7RxcSFL5HH92WJgWmLWG8jKlpvCuHt c/72quISiCEsmMHVIpzHjmHUbRAm+2T64AB3/7fmyClm9k6GaL2yJZcsu VTu6P+kxLNvkp8JVAnmIbclOHiq2oAtAcSPMERi0WG5P5AES+SqdqyRsU paApv1Bt/7hjntNdggySYYD6TJwA5MvUrkY+NMq2OSA5Imu+h8AvAgO/o w==; X-CSE-ConnectionGUID: YIDc+no+TxiDB6EWsZid3Q== X-CSE-MsgGUID: Z1GgGq0iTeakTI7uATNInw== X-IronPort-AV: E=McAfee;i="6800,10657,11772"; a="88840930" X-IronPort-AV: E=Sophos;i="6.23,208,1770624000"; d="scan'208";a="88840930" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Apr 2026 09:52:03 -0700 X-CSE-ConnectionGUID: w73/2rcuTJSC7b5+rC67Cg== X-CSE-MsgGUID: dZ3t6KxcS/KxZ3znVMJPcA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,208,1770624000"; d="scan'208";a="258221482" Received: from cjhill-mobl.amr.corp.intel.com (HELO [10.125.109.74]) ([10.125.109.74]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Apr 2026 09:52:02 -0700 Message-ID: Date: Thu, 30 Apr 2026 09:52:03 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/6] mm: Make per-VMA locks available in all builds To: Andrew Morton , "Liam R. Howlett" , linux-mm@kvack.org, Lorenzo Stoakes , Shakeel Butt , Suren Baghdasaryan , Vlastimil Babka , LKML References: <20260429181954.F50224AE@davehans-spike.ostc.intel.com> <20260430072053.e0be1b431bcff02831f07e9d@linux-foundation.org> From: Dave Hansen Content-Language: en-US Autocrypt: addr=dave.hansen@intel.com; keydata= xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzUVEYXZpZCBDaHJp c3RvcGhlciBIYW5zZW4gKEludGVsIFdvcmsgQWRkcmVzcykgPGRhdmUuaGFuc2VuQGludGVs LmNvbT7CwXgEEwECACIFAlQ+9J0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGg1 lTBwyZKwLZUP/0dnbhDc229u2u6WtK1s1cSd9WsflGXGagkR6liJ4um3XCfYWDHvIdkHYC1t MNcVHFBwmQkawxsYvgO8kXT3SaFZe4ISfB4K4CL2qp4JO+nJdlFUbZI7cz/Td9z8nHjMcWYF IQuTsWOLs/LBMTs+ANumibtw6UkiGVD3dfHJAOPNApjVr+M0P/lVmTeP8w0uVcd2syiaU5jB aht9CYATn+ytFGWZnBEEQFnqcibIaOrmoBLu2b3fKJEd8Jp7NHDSIdrvrMjYynmc6sZKUqH2 I1qOevaa8jUg7wlLJAWGfIqnu85kkqrVOkbNbk4TPub7VOqA6qG5GCNEIv6ZY7HLYd/vAkVY E8Plzq/NwLAuOWxvGrOl7OPuwVeR4hBDfcrNb990MFPpjGgACzAZyjdmYoMu8j3/MAEW4P0z F5+EYJAOZ+z212y1pchNNauehORXgjrNKsZwxwKpPY9qb84E3O9KYpwfATsqOoQ6tTgr+1BR CCwP712H+E9U5HJ0iibN/CDZFVPL1bRerHziuwuQuvE0qWg0+0SChFe9oq0KAwEkVs6ZDMB2 P16MieEEQ6StQRlvy2YBv80L1TMl3T90Bo1UUn6ARXEpcbFE0/aORH/jEXcRteb+vuik5UGY 5TsyLYdPur3TXm7XDBdmmyQVJjnJKYK9AQxj95KlXLVO38lczsFNBFRjzmoBEACyAxbvUEhd GDGNg0JhDdezyTdN8C9BFsdxyTLnSH31NRiyp1QtuxvcqGZjb2trDVuCbIzRrgMZLVgo3upr MIOx1CXEgmn23Zhh0EpdVHM8IKx9Z7V0r+rrpRWFE8/wQZngKYVi49PGoZj50ZEifEJ5qn/H Nsp2+Y+bTUjDdgWMATg9DiFMyv8fvoqgNsNyrrZTnSgoLzdxr89FGHZCoSoAK8gfgFHuO54B lI8QOfPDG9WDPJ66HCodjTlBEr/Cwq6GruxS5i2Y33YVqxvFvDa1tUtl+iJ2SWKS9kCai2DR 3BwVONJEYSDQaven/EHMlY1q8Vln3lGPsS11vSUK3QcNJjmrgYxH5KsVsf6PNRj9mp8Z1kIG qjRx08+nnyStWC0gZH6NrYyS9rpqH3j+hA2WcI7De51L4Rv9pFwzp161mvtc6eC/GxaiUGuH BNAVP0PY0fqvIC68p3rLIAW3f97uv4ce2RSQ7LbsPsimOeCo/5vgS6YQsj83E+AipPr09Caj 0hloj+hFoqiticNpmsxdWKoOsV0PftcQvBCCYuhKbZV9s5hjt9qn8CE86A5g5KqDf83Fxqm/ vXKgHNFHE5zgXGZnrmaf6resQzbvJHO0Fb0CcIohzrpPaL3YepcLDoCCgElGMGQjdCcSQ+Ci FCRl0Bvyj1YZUql+ZkptgGjikQARAQABwsFfBBgBAgAJBQJUY85qAhsMAAoJEGg1lTBwyZKw l4IQAIKHs/9po4spZDFyfDjunimEhVHqlUt7ggR1Hsl/tkvTSze8pI1P6dGp2XW6AnH1iayn yRcoyT0ZJ+Zmm4xAH1zqKjWplzqdb/dO28qk0bPso8+1oPO8oDhLm1+tY+cOvufXkBTm+whm +AyNTjaCRt6aSMnA/QHVGSJ8grrTJCoACVNhnXg/R0g90g8iV8Q+IBZyDkG0tBThaDdw1B2l asInUTeb9EiVfL/Zjdg5VWiF9LL7iS+9hTeVdR09vThQ/DhVbCNxVk+DtyBHsjOKifrVsYep WpRGBIAu3bK8eXtyvrw1igWTNs2wazJ71+0z2jMzbclKAyRHKU9JdN6Hkkgr2nPb561yjcB8 sIq1pFXKyO+nKy6SZYxOvHxCcjk2fkw6UmPU6/j/nQlj2lfOAgNVKuDLothIxzi8pndB8Jju KktE5HJqUUMXePkAYIxEQ0mMc8Po7tuXdejgPMwgP7x65xtfEqI0RuzbUioFltsp1jUaRwQZ MTsCeQDdjpgHsj+P2ZDeEKCbma4m6Ez/YWs4+zDm1X8uZDkZcfQlD9NldbKDJEXLIjYWo1PH hYepSffIWPyvBMBTW2W5FRjJ4vLRrJSUoEfJuPQ3vW9Y73foyo/qFoURHO48AinGPZ7PC7TF vUaNOTjKedrqHkaOcqB185ahG2had0xnFsDPlx5y In-Reply-To: <20260430072053.e0be1b431bcff02831f07e9d@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ... adding all the cc's back. On 4/30/26 07:20, Andrew Morton wrote: > On Wed, 29 Apr 2026 11:19:54 -0700 Dave Hansen wrote: > >> 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. > > Did you see the AI review? > https://sashiko.dev/#/patchset/20260429181954.F50224AE@davehans-spike.ostc.intel.com I just went through it. There was some absolutely valid stuff in there like a bunch of CONFIG_PER_VMA_LOCK references needing to be cleaned up. It also made some good points about the binder shrinker sites that I think I cleaned up for v2. There are three very valid structural problems that it's concerned about. First is that lock_vma_under_rcu_wait() doesn't use mmap_read_lock_killable(). It probably needs to, or at least there would need to be killable and non-killable variants. That's easy enough to do if folks agree that this is overall something that should go forward. I'd prefer to hand wave it away for the moment, though. Second, it brings up concerns about lock_vma_under_rcu_wait() deadlocks in the face of other per-VMA or mmap_lock holders. This is very valid, but it's inherent for users of mmap_lock. I think it's just a documentation issue. Third, Sashiko is _very_ peeved about the lock_vma_under_rcu_wait() goto loop. Broadly, it's concerned about fairness and livelocks in the face of userspace being able to compel 'goto retry' to happen forever. It's a valid theoretical concern for sure. I'm less convinced that it will be a problem in practice, and I should probably hack together a torture test to see how many retries actually happen. The other way to fix it more robustly would be to acquire the vma reference under the existing mmap_read_lock(). I _think_ it's just a couple extra lines of code, but I haven't done the legwork to flesh out how that would look. But the key questions for this series remain: 1. Should/can per-VMA locking be available in all configs? 2. Is *a* lock_vma_under_rcu_wait() implementation feasible and useful? The implementation in this series is highly imperfect. Is there a chance of a better one or is it just impossible?