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 533FFE65D31 for ; Fri, 22 Nov 2024 07:56:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB2296B00A2; Fri, 22 Nov 2024 02:55:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C38A96B00A4; Fri, 22 Nov 2024 02:55:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3C3A6B00A6; Fri, 22 Nov 2024 02:55:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7ADFB6B00A2 for ; Fri, 22 Nov 2024 02:55:59 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1F0BA140F3B for ; Fri, 22 Nov 2024 07:55:59 +0000 (UTC) X-FDA: 82812969960.08.AF12C99 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf15.hostedemail.com (Postfix) with ESMTP id 30B8CA0009 for ; Fri, 22 Nov 2024 07:55:01 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="A/elcECN"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732262089; a=rsa-sha256; cv=none; b=b9oCNbcg45xWKat4xYkimoB54bgY9B9lAfQm8ohx9dfKaWFrZAHJ0ZbqwLCL0N24dp3SOR +zwMqWrEGfHf7O4GxNvB+TolZvDkVF6hMnEW7XTribdpl71cX4UvFooVj0YIdiQsWRA2K/ eQJ7qLdD1LLDxdV7GXxC0Ty5YGzhwLI= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="A/elcECN"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732262089; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=z4vKBieIfUnfP5rb/GIVJx7pJ7hMdseAArRaDJN1LAw=; b=ZGgiQSzlX8MwlVbF/Vtz3jAXsrViJGWxOKoAF7la+4caA7vIkTLFjd/yowecotDjez92i8 K4oia8GHGePV5FbcXJTh0kfayA30VZT8U1gmuV2ScOP4MK7bAYtLc0PzEWLcnw9p0qeNs9 yr9QzypO5sPAHAc1xrrzRzkx1W0GK7g= Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-3824709ee03so1310793f8f.2 for ; Thu, 21 Nov 2024 23:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732262156; x=1732866956; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=z4vKBieIfUnfP5rb/GIVJx7pJ7hMdseAArRaDJN1LAw=; b=A/elcECNyl+G7mrhNEtoq0QZ0+sbDfCTmQAulG53qXOrxzHZV2R2MJj5B6lX91FUg/ eni9DJBcnEkNPgSLgA91kxVA6L7cwf6cchXrkrP/UeNpov6x1Y9tjUa1/AGhoEVYXvQP 1j/gMCDWNXJNvTSwNKqmnckIjLmrNRRNQ4y3+6n9Zr9JC3p5IVOFOuj2gXsyA9gdP/Y0 eYupOCK/AfG6dQ2F/undKnx5JaThPASVCjR5ETCqOywegWX7TGGfGPuAjv1P1VxdHXTm D9v8uXPD6VYzH+1XOFLSMcWPtuwKXIp8WLenxfSqGbchri8KTlN8wanjR93m6o6qv/oK 20HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732262156; x=1732866956; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=z4vKBieIfUnfP5rb/GIVJx7pJ7hMdseAArRaDJN1LAw=; b=wuyk1YS+2lSEsraFsu4YP7AVy1Srn3VuXStbccRFWa/pirAc4Hhk5sJIB2hzLtXkkc 7RSZhcDdjXoQAN2ao9Us4iev3r3iyu7JE4jghDjnMH9oJadVbXXw//XHJpRLoyh+/b3W 8KPeWXL/5TiPE1jR9dDaUIiEyr+Vda9MsPmpZjqiQkv07h8pI3vDbdmy2irX9ehpXNCd fDFbqhdZJZZ41oV0YMQ7dWCAaMtL/auMzNz28Vib7OiZw6lwKsaMlIThdY6cD/FhkLpQ M5sFED5os2HZ2H8/MYC/1W8hhtxu0fG9GY6xHImp6Ydh4+hZap2ADQssXz2fa5Wem3bP WQnQ== X-Forwarded-Encrypted: i=1; AJvYcCUs96jNWmKWKyCaaqxXMtFuVa9XO4ZVBpjCONQLuAx1/7QmWSHMp7okB4nyILM/JNE64O+cj/R9wQ==@kvack.org X-Gm-Message-State: AOJu0YxzZFAlr2qFV4/KRLFOMS3IB8njC+QipdAhWMDS/YcAaWDTntW0 yX4nEviKTF5vCHjIpuj+LgiGWDBTZs8bkDZB7rKbB7zq8pRNlbxM/MNX1KptRgvQmN0Y4G2sZcP 8StORO4twNYrHwaeI56GHCqpyXrDHIXdo/K/6 X-Gm-Gg: ASbGncvi6OCuiDCXmOsU+M7I+8QV1rkATLpzpPyA//a4ZHFND9u3F6/e+PYyf7nu2jM R8z0ARs/hgi5uL5S+FVB5EmXmYsiLh2Fw X-Google-Smtp-Source: AGHT+IFkzG3/qxSMU//RMD7jHCtgcpHQJ+DTwGvLNDlSxbRcCSQe+8OMIoK+cYjmebrEz5l80i1lbp8WkF/Cant0Mek= X-Received: by 2002:adf:e18c:0:b0:382:3894:346c with SMTP id ffacd0b85a97d-38260b76c31mr1646813f8f.27.1732262155734; Thu, 21 Nov 2024 23:55:55 -0800 (PST) MIME-Version: 1.0 References: <20241119112408.779243-1-abdiel.janulgue@gmail.com> <20241119112408.779243-3-abdiel.janulgue@gmail.com> <43a07c04-2985-4999-b6d6-732794906a36@gmail.com> In-Reply-To: From: Alice Ryhl Date: Fri, 22 Nov 2024 08:55:42 +0100 Message-ID: Subject: Re: [PATCH v3 2/2] rust: page: Extend support to existing struct page mappings To: Jann Horn Cc: Abdiel Janulgue , rust-for-linux@vger.kernel.org, Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Wedson Almeida Filho , Valentin Obst , open list , Andrew Morton , "open list:MEMORY MANAGEMENT" , airlied@redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 30B8CA0009 X-Rspamd-Server: rspam01 X-Stat-Signature: gf3y6cfgxukio7tiadgdsgjmtto1omds X-HE-Tag: 1732262101-213774 X-HE-Meta: U2FsdGVkX1/y/wa9m1CaVKTbR3vINFxQJyqKYZV9DLkHtUCi4oXsQiX3/6zuem1sDouDf0a+9GKQ5QwTQEf/73XubW47cAco4ZDchtvr5FUpQnbOR62DeyzAMMU+vjv2ZM0TINDxCDLIdnA83lz+buYYG962r6ZU5LOaXSaYIlxAL2S7q8+l5bkGFmd7TalBd+VxTrWOj3g9Iio+ism7udPWjz50EOkO0Fc6jF8tkV3d+JsJIlo1Igqsj77Dx74yhg/Kdv6hHeIU+jmTXlkrEy+xaU5zVYtlOtmDM+flSiAWnFd8P54H5wimna8kxWDBN+Wt3RnoAbG/tZPysrlFpl6F+7OIMRFmuhks76YEcEaf2KTW/aRn0sGGmSpRDWAkGNivkl+LFe3lftQDV2LkJUZqo7rxfInyMVb77+RO6b1BeH/xEOe2LoRYVCtaLHyJdG1dIKML1HwsQj4p0sxOzXiF9RLxv5AkFRoH1ydQNBNrzLovNgBdXw+4crDpjVFJfvn+bHDkqEIEAuueKeCTpheN8V8p5sk//vVQIVNrwasN/iO3sc8RQtN3yMmot3VUqEkZf8mWth417p+K3BfbNkqLmKVMaqBiVkTVsLWLPDkdSRNUChRVn9UF0Pd1EqGzcn5lpJHw4qtLLl9fVtK25pvQTrsbXxbMpuNvLCkkVu8UB0PaFtdZnadeBLqWogmXQ/06SMaazcNErp5Qgt2LXgJnr9Gcxz/iY6EUGkd6b49t0pDKQudBLvJp5Q90R9C6wRXHCTKjOB98Nc5WyQoRqyUM+WLrgg1TuTh2kXrdOB62QUj7LoKohqZbKbdDSg8cPlE97pfkxH+lFArAXovI/jS+uAbdj/8ctJv1SMkE6ZvDxvW7/VpJ4FnZFLcxDQzBw1ysbPkgyH3N/Lb9PiG2dtANKyaRuaprdEOEPbWsNLmLC81hYzvVSaU2dmoecf/3YSVacedkcJusIkRdmyd M/xLCZX+ aiyKOa/Q0YkSIrSKEkm5v1TQp6VJSmzg8r6sRX6JDW4gAi6R1vIjjRGPLm+g9ySRwBANQ+mpuZ9f/DbkCyC7By2CO0UhibXkmv2ugM1aRzuPv/yxqGbsJbPoXcuQ2EfqcVGhkGeFcov/inbz7WucPZudgZctlFTAA4ABT3Q6rL02Tm0Z8FAItxXtxN4dQkiBePbjqMA6XkGc5sXWizkKpZI3cymylFNXErIopvk52qMrumm2B92DEbZLQc4vz0n0I3pIC0VDs7jgO9SfuxfFvlElq2rFNQGCQZoyn+9E4qz7+YO+HIwxBDicGPH7L019qox9Y0wyiKP35+BTRwWXolkCtlw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000302, 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 Thu, Nov 21, 2024 at 9:18=E2=80=AFPM Jann Horn wrote: > > On Wed, Nov 20, 2024 at 11:56=E2=80=AFPM Abdiel Janulgue > wrote: > > On 19/11/2024 19:07, Jann Horn wrote: > > >> + pub fn page_slice_to_page<'a>(page: &PageSlice) -> Result<&'a S= elf> > > > > > > Sorry, can you explain to me what the semantics of this are? Does thi= s > > > create a Page reference that is not lifetime-bound to the PageSlice? > > > > This creates a Page reference that is tied to the lifetime of the `C > > struct page` behind the PageSlice buffer. Basically, it's just a cast > > from the struct page pointer and does not own that resource. > > How is the Page reference tied to the lifetime of the C "struct page"? > > I asked some Rust experts to explain to me what this method signature > expands to, and they added the following to the Rust docs: > > https://github.com/rust-lang/reference/blob/master/src/lifetime-elision.m= d > ``` > fn other_args1<'a>(arg: &str) -> &'a str; // elided > fn other_args2<'a, 'b>(arg: &'b str) -> &'a str; // expanded > ``` > > Basically, my understanding is that since you are explicitly > specifying that the result should have lifetime 'a, but you are not > specifying the lifetime of the parameter, the parameter is given a > separate, unrelated lifetime by the compiler? Am I misunderstanding > how this works, or is that a typo in the method signature? No, you are correct. The signature is wrong and lets the caller pick any lifetime they want, with no relation to the lifetime of the underlying `struct page`. >From a C perspective, what are the lifetime requirements of vmalloc_to_page= ? > > >> +fn to_vec_with_allocator(val: &[u8]) -> Result, AllocError> { > > > Do I understand correctly that this can be used to create a kmalloc > > > allocation whose pages can then basically be passed to > > > page_slice_to_page()? > > > > > > FYI, the page refcount does not protect against UAF of slab > > > allocations through new slab allocations of the same size. In other > > > words: The slab allocator can internally recycle memory without going > > > through the page allocator, and the slab allocator itself does not > > > care about page refcounts. > > > > > > If the Page returned from calling page_slice_to_page() on the slab > > > memory pages returned from to_vec_with_allocator() is purely usable a= s > > > a borrow and there is no way to later grab a refcounted reference to > > > it or pass it into a C function that assumes it can grab a reference > > > to the page, I guess that works. > > > > Yes, I think that is the intent. I appreciate your help in pointing out > > the issues with using refcounts in slab memory pages. As you can see, > > page_slice_to_page() only returns a Page reference (not a refcounted > > Page). Hopefully that addresses your concern? > > Does Rust also prevent safe code from invoking inc_ref() on the > returned Page reference? Normally, the AlwaysRefCounted trait means > that safe code can create an owned reference from a shared reference, > right? In principle, no, you could invoke inc_ref() directly. But the correct way to do it would be to use ARef::from(my_ref) to obtain an actual refcounted reference. Alice