Received-SPF: pass (google.com: domain of linux-kernel+bounces-204891-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Thu, 6 Jun 2024 14:32:20 -0400
From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Suren Baghdasaryan <surenb@google.com>,
        Andrii Nakryiko <andrii@kernel.org>, linux-fsdevel@vger.kernel.org,
        brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
        linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
        gregkh@linuxfoundation.org, linux-mm@kvack.org, rppt@kernel.org
Subject: Re: [PATCH v3 4/9] fs/procfs: use per-VMA RCU-protected locking in
 PROCMAP_QUERY API
Message-ID: <7rm3izyq2vjp5evdjc7c6z4crdd3oerpiknumdnmmemwyiwx7t@hleldw7iozi3>
Mail-Followup-To: "Liam R. Howlett" <Liam.Howlett@oracle.com>, 
	Andrii Nakryiko <andrii.nakryiko@gmail.com>, Suren Baghdasaryan <surenb@google.com>, 
	Andrii Nakryiko <andrii@kernel.org>, linux-fsdevel@vger.kernel.org, brauner@kernel.org, 
	viro@zeniv.linux.org.uk, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, 
	bpf@vger.kernel.org, gregkh@linuxfoundation.org, linux-mm@kvack.org, rppt@kernel.org
References: <20240605002459.4091285-1-andrii@kernel.org>
 <20240605002459.4091285-5-andrii@kernel.org>
 <CAJuCfpFp38X-tbiRAqS36zXG_ho2wyoRas0hCFLo07pN1noSmg@mail.gmail.com>
 <CAEf4BzYv0Ys+NpMMuXBYEVwAaOow=oBgUhBwen7g=68_5qKznQ@mail.gmail.com>
 <ue44yftirugr6u4ewl5cvgatpqnheuho7rgax3jyg6ox5vruyq@7k6harvobd2q>
 <CAEf4Bzaac0Di+mCfrxRVsZT0sfWWoOJi6ByW0XA5YEh1h7dwuw@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEf4Bzaac0Di+mCfrxRVsZT0sfWWoOJi6ByW0XA5YEh1h7dwuw@mail.gmail.com>
User-Agent: NeoMutt/20231103
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?us-ascii?Q?nLkB++4CCXSaP4Y/ww66KZaLVki18NFBKA2/67B9J3Pz7lOOA9FyROcLmsO+?=
 =?us-ascii?Q?noaG6JIfFdb8D5DKGqWEGCrg3jbcqrC4trmHD1YDNXSXrqSpDkQzbuh6SBUD?=
 =?us-ascii?Q?hmTj3CBRJ7DAdKb3JMxTSwh3/HA8GCgy8tiBhdBnlKI+vw9EsEvmLJerxpBn?=
 =?us-ascii?Q?s91ybXX2CWWVu5FjEHsGbZNUeujsvt4gS5yxqVKR1255mGkPgr24u15gbG4a?=
 =?us-ascii?Q?fPlDVg9NdQ3UyP+m7dnFbyXQvXQGC+WyMh/O+UZ3IDO2zlz3v0RzpTykTB74?=
 =?us-ascii?Q?1K7gPw736MLQPadzFuzQ4INHXZOo6fKc87VwIZQW0YPp2ieAFgOJdaMggD3Z?=
 =?us-ascii?Q?KLL85EdU3tNdTMxhYsSvvd44VKL41v4JnkReYg68BgXDcn/shVef5lTLAqVl?=
 =?us-ascii?Q?WTOWv9qxiN67g3Cpx8ALGGrhitkcxAqyIlBnX78viHCpDVx8WALU//fM9+qa?=
 =?us-ascii?Q?ahCix9ix7OVEdclQdoM+fcT8dDByLsUaZbptAlXWB0CDb3smj1jwUUu6Ar5t?=
 =?us-ascii?Q?cSbfj4FQfz6uEtLVLAWec9bjH/Vv5IzaJTMb65D1OtQx1zcttRmBZAJKOp5B?=
 =?us-ascii?Q?cBdhsYubbfVztGbBgh1ty9kcO+tApBR4AziTfJ8aeexGrl5PAUv+8R6P4rpw?=
 =?us-ascii?Q?jqUpbAlh6jJWfAI+8R5NS5ctpllz71cr/lWCFYTf7aFdl14fUQlijzR0bi0D?=
 =?us-ascii?Q?nJTvU9T+FxF27Ejuj4Tl6LMnhQl3LuLLFu6kUOsG+WxzmEpqm19gfz9UBFQX?=
 =?us-ascii?Q?c3uCm6x4gYiqk+YdSlMfUVxI8biDygwlZl7eIc7xvIcLtqkeJZ0QMgbmRLtP?=
 =?us-ascii?Q?HjbXnTBXcyLPGLI+xF2acyC2/XCWuRMAzN+53HbFL4463fllYrAKzQkESobK?=
 =?us-ascii?Q?oSReE8RjAfoOe0RZ5cWeI1HxiHWIk24Y5mS9AUUVAGmiQaLYBnLjgIL9zwG8?=
 =?us-ascii?Q?ivCqMZQR8Z+R/vG38mM2aVTGqLcAS+XC1UWwJsCi8zYkN4CpcwZu0ZaH0WGT?=
 =?us-ascii?Q?4GH+YCyxKKehzSGfFdbs77xDIpWS1WMsQTc/771PcpT/msjxTw49qqHgkbL1?=
 =?us-ascii?Q?VrCWZcyDB/6GdgOfXOdF3zESPfQtxznGTcVpaSdfYV4M5UUe5Y2S+uBvkpTt?=
 =?us-ascii?Q?xBM0FqdIBpyME1W2ADomidLGqDdpvkKXctyZ7ZwCzhar1MOC1opfhyaSqO6Q?=
 =?us-ascii?Q?AGrgSfS5bOS1JS7jZG17WtyPO4UtHueRGrrXkCH+g1RkY1TQaDElZqKdqMTq?=
 =?us-ascii?Q?Lk6U/4pcrYf3yLcts/WTgbxrvA5XkILUzjuU0k4mHT4jrfE3UTQwOmHWGgKB?=
 =?us-ascii?Q?ohqJecjYpMWC38ZPt9H521Ok9iTsrchFlwUh+M4Fuj8NHq5BiLQmXmaTCCGL?=
 =?us-ascii?Q?VbOYk3+7ITSArWiNBv1rS8yhmrYT234Q6EEzoUhftB34vJj7ww/ABHuIByAo?=
 =?us-ascii?Q?wXaioYPDv8sg3l8NBgWgM6Wgju7qahItpCEHBoyBgdpUl4UN7b5shX5PiUb5?=
 =?us-ascii?Q?o9b2hGcCv7a2xqxK2isOSkVfofkVdEfeL9YnDJQcJLCu8S/Dfkn5hqSzPlkt?=
 =?us-ascii?Q?GUbNE6w/RZVwcStc4I0bSr4TF87kCsefRw0FnM+C?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	lA1Wh32qWzSszZwH7CrVlsy0v2uR00Us1JdigxjJLnlF4DX8xnwaSyYyOk9bIr/y2S+VW2Ofywfh6uEKct8HIMTx9drXiOquXfzXcxTrWPUO7DvXHa6uEF+OOnJ0ldCuubTdkTzkWdUlmx7f3pQ6BAGTBplxv6rQUvR6Dy9KfQt9L5ZsgbiCs3IOz+55S5yXeoaqQO6tGCpyGAtOsjKXSDNuctJAW+E7ocML/zY7iaKBYBcQidMPgkdL3oYjpIHvCgEs0ejHUFoFUML7tF2L8Bmf0hUGmwvjx2atw7MIkGHHDmDhhL/CCnlesRXP+U2rXV0bSGjNfnWRKtoejXLqNczAlB85PYznc3sMwBK+SI5CidkSm9pAThgBWWiMMVjXDROgPaMhkvBCT+zk0r8etAX2r5HXfNxPa/eG+cwmZF2/GsGVVKjaoE3NFOwjA1u/mxB9VEWRAfoZYRAbQ+O7aysBH9+knUNYaysD5t0Aq5ahz/kUP9cxTt7+qGKQZvvsxGEVMjsKnVYW9VNQuL+nVmIxfUt8HOuyHmbLACdI7AEE8sHSNV4U7CJ5g17KYqmTOWkPt/FZKJ0z7a6GS0p259L/0CpVbv0tfeytc2GAESg=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 02fbe869-ee6b-4dab-d2cd-08dc86570188
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7933.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2024 18:32:22.7097
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Eeu4XymBhAUfzY9SAedRhxpw+fFoQCFDoufP1ksi34ss7AM7eM+DtpBIglTfmZ9Iifcnyx0oE3eftlHCptvcNw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4419
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16
 definitions=2024-06-06_14,2024-06-06_02,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 adultscore=0
 phishscore=0 suspectscore=0 bulkscore=0 spamscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000
 definitions=main-2406060128
X-Proofpoint-ORIG-GUID: SwA5s9mgP81oLeAY5CY00b18BLaOWQCr
X-Proofpoint-GUID: SwA5s9mgP81oLeAY5CY00b18BLaOWQCr

* Andrii Nakryiko <andrii.nakryiko@gmail.com> [240606 14:09]:

...

> > > Liam, any objections to this? The whole point of this patch set is to
> > > add a new API, not all the CONFIG_PER_VMA_LOCK gotchas. My
> > > implementation is structured in a way that should be easily amenable
> > > to CONFIG_PER_VMA_LOCK changes, but if there are a few more subtle
> > > things that need to be figured for existing text-based
> > > /proc/<pid>/maps anyways, I think it would be best to use mmap_lock
> > > for now for this new API, and then adopt the same final
> > > CONFIG_PER_VMA_LOCK-aware solution.
> >
> > The reason I was hoping to have the new interface use the per-vma
> > locking from the start is to ensure the guarantees that we provide to
> > the users would not change.  We'd also avoid shifting to yet another
> > mmap_lock users.
> >
> 
> Yep, it's completely understandable. And you see that I changed the
> structure quite a lot to abstract away mmap_lock vs vm_lock details.
> I'm afraid anon_vma_name() is quite an obstacle, unfortunately, and
> seems like it should be addressed first, but I'm just not qualified
> enough to do this.
> 
> > I also didn't think it would complicate your series too much, so I
> > understand why you want to revert to the old locking semantics.  I'm
> > fine with you continuing with the series on the old lock.  Thanks for
> > trying to make this work.
> >
> 
> I'm happy to keep the existing structure of the code, and
> (intentionally) all the CONFIG_PER_VMA_LOCK logic is in separate
> patches, so it's easy to do. I'd love to help adopt a per-VMA lock
> once all the pieces are figured out. Hopefully anon_vma_name() is the
> last one remaining :) So please keep me cc'ed on relevant patches.
> 
> As I mentioned, I just don't feel like I would be able to solve the
> anon_vma_name() problem, but of course I wouldn't want to be
> completely blocked by it as well.
> 

Absolutely.  Thanks for trying.  To be clear, I'm fine with you dropping
the per-vma locking from this interface as well.

Thanks,
Liam