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 D1D37C3DA63 for ; Tue, 23 Jul 2024 14:50:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 557FB6B0082; Tue, 23 Jul 2024 10:50:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 510676B0088; Tue, 23 Jul 2024 10:50:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A77D6B0089; Tue, 23 Jul 2024 10:50:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 16C3B6B0082 for ; Tue, 23 Jul 2024 10:50:23 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C9B3212019D for ; Tue, 23 Jul 2024 14:50:22 +0000 (UTC) X-FDA: 82371303084.06.00D6813 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id 03E70C0021 for ; Tue, 23 Jul 2024 14:50:19 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=iM51JkRe; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721746184; 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:in-reply-to:references:references:dkim-signature; bh=jYWVnpw0/I8x56Kco6vA/ZpE9Ty7o70/Ja2C3Pi/lJI=; b=jH/M7en4Z4kbwKUgmQiRs1DIdYGGBDokWEoUA5/en75xIsX2o6Eq9hwp4TyD5COXR1sFdk 0HP+i7/qtqvS91jKvEcjjucTDPLNbSiwEn4xKUZvgQWaEor02zQqBuc+SI+20bGGsRNCjS xH+mf3K44rxo6SrDB/pVx/rIp0yteu0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=iM51JkRe; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721746184; a=rsa-sha256; cv=none; b=lQXyAlIIOMsGmgOocQuxUDLen474tH/IcE2AekT3yw7R7FeEVJrk+lFUt47xoVHS8qveP4 plkC5s3TG6YTmujlP8bCTOhnZ2lfP/IkIbHjGXu3xE7ogVRu8Sj75+bCBC+gPuQMvwKb/Y gNO86EUun77gSJmjZvLjarHVqJpJez8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=jYWVnpw0/I8x56Kco6vA/ZpE9Ty7o70/Ja2C3Pi/lJI=; b=iM51JkReSoz3OjbOTIJFF8ELeE KC0SaGCqdZSoW4Kd00KCcHD0VPEQtZRUATO38BuYSwL3MtaGW23wxEMOQGxvl/+r/PzI/KNwLDdYG FmmurlUrzqnyjvWFY+O7RrataQ1UOmupaML6s9ZXllZ5ez72yg+4sqbMVUoBc+X2reG8B6ktVbv+t 2n3q0qBO5yHLcnon5aLNLD1+EkqIXK0zZwbvm4nlXKSwQqwKN4gB5rDNbyY7PwsVPEWgM/B4+UDip uQIrS5JGyfV5Uq3HFfcQGhJ8/zEDwc8m2cG0j2MpC4ZAz7TFAqjbNhpoK5jFhfnpql6wQHe3C87v4 EE1rM+Eg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sWGq8-00000006yW4-2hq3; Tue, 23 Jul 2024 14:50:08 +0000 Date: Tue, 23 Jul 2024 15:50:08 +0100 From: Matthew Wilcox To: Alice Ryhl Cc: Miguel Ojeda , Andrew Morton , Alex Gaynor , Wedson Almeida Filho , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH] rust: mm: add abstractions for mm_struct and vm_area_struct Message-ID: References: <20240723-vma-v1-1-32ad5a0118ee@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240723-vma-v1-1-32ad5a0118ee@google.com> X-Stat-Signature: y1xr1wbeewyghhsn6w5riq9rfq6roiz8 X-Rspam-User: X-Rspamd-Queue-Id: 03E70C0021 X-Rspamd-Server: rspam02 X-HE-Tag: 1721746219-644644 X-HE-Meta: U2FsdGVkX19fvde/wWi7FCLKXuu8jYuJhQQIWeLh2iCYNeRQt/qXofohecTB4xVWRGboLEBvGvpOJYYnmUa0QVUPQYWyf6KV7wYdfdAoVFSNxH3oXJeCTwZSQd6jMabZWT6NryQFQXk9cj17GfyFH1ED/DB5pf5Y6LCKjJil6gjEnsjyGEIO5pDj5VCV3PW6ORA+3ZyLOPY1WcYVV7VGFlzNsTO+o794jWfodtmFFaqmxp2qi9Rf4ige4OFQPjUt4hLxo/whVv/vxxl7qbm3+lLnZ2icdV3QYSvqvWAoeC7NNCDchtUzE/UIJtUh6nHnITJSj/dvlMAx/wkKnVBw2CmBIqgEL2fhw+4bI2V8UhkzNKuOcEjMGVccFKtHEF1/DN0XrRqaZjfGD1/h7XEvack7ibF0wPqRLgvTLCq3g+CAj8I1b5Yuh6KD2PltDGMsqQd5hjerxJjFT8RZTAnQlVBOx8SEk15XLb0uK02j9PlnCaC2W2U5AGUniHpPeokmG66z0jnevpY1IcGaIfD4LcJreXEePBSstXjd2CTq6mv1JFwAqZhB83mEO8I3XWdQ+hA2SsGqNMldVRvnfIUtomLcSVQ1Vg9idqjQ24IngjHQ3cThsYedYG/hDVhzRU78uex1HTO3R+KTcRLS19msaOpo9msypngXEEaGLWGh7U2kC8LGImrEOBu5O1zM6lTDN/gUl+0uJnSLII48G4eqN3wmTGgfqg5BD8einIp7XJDYBivAvajyQ8Z5QUxJE7LcxtcIccfMalSNCwH5YKJz9Sx+gmwJ4/De6jhS/NGNBIc/ZvccYBIAISdq9t1U2zEMxqJaEGj2p6G/UFmN7ZKDlhlcfopKiRYSc/rVYX1Fs0qb7W5VVeK9brAe+KL4SWUAiS/5a4G6rFoGc/eGePmmb7MrxsuuHsT2tnqqKEmXY4enjas96ZJo8UlOM7RXtn7EsVMD15j3E3YBSJAp2km n+nZHeLq mPL0sraFq2kub+sHieuu2Qf+OwHbt2gVQuYaFXEG18doILNWECCe80iUQMb+ytH3N3by5VLw74bw7bYZegOCUD5Oa0IXktF5nrB6erjt06maAAnTPQc0lpl+Uwl4IBxK+SRyErXhbmQFctcPZJ4Jz8u+EdGYbczAB3Iyh/RswWUj5anLoBO7UlHTyK3af4IRWXSLvb+lVgNLCcSSw9PaPcffspYZCuY4tkf5cpCD1XHHXam8yTdW++URDN2ZpuNpGAt0+85AiLrHlcZ4jKxzFBk/fjowUOfbO9kmKPxXN/D7H9euGrkEQMGxhp0p3t/QB27lhlJ7uGpQS3xU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jul 23, 2024 at 02:32:03PM +0000, Alice Ryhl wrote: > +// SAFETY: It is safe to call `mmdrop` on another thread than where `mmgrab` was called. If I were reading the documentation, I might want to know if it's safe to call in interrupt context (either soft or hard). ie can mmdrop sleep (if it turns out to be the last owner of the mm). > +/// A wrapper for the kernel's `struct vm_area_struct`. > +/// > +/// It represents an area of virtual memory. > +#[repr(transparent)] > +pub struct Area { > + vma: Opaque, > +} That seems like a very generic name! MMArea? VMA? Certainly when I'm talking to people, I say VMA. struct vm_area_struct is a terrible name and I'd be happy to change it if we could stomach that churn. If I were naming it today, I'd want to call it struct mm_area.