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 39E34E6400D for ; Thu, 21 Nov 2024 20:18:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B405C6B0083; Thu, 21 Nov 2024 15:18:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AA1346B0085; Thu, 21 Nov 2024 15:18:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 968066B0088; Thu, 21 Nov 2024 15:18:08 -0500 (EST) 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 7B54A6B0083 for ; Thu, 21 Nov 2024 15:18:08 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2C8A31202E0 for ; Thu, 21 Nov 2024 20:18:08 +0000 (UTC) X-FDA: 82811211126.03.C6B0DEE Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf27.hostedemail.com (Postfix) with ESMTP id D88824000A for ; Thu, 21 Nov 2024 20:17:08 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LGjIbV9C; spf=pass (imf27.hostedemail.com: domain of jannh@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732220135; 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=QsRAQ6t08WPFqqtrK9Y/yi/Kj5TOA65Z3KS9Ukbgptk=; b=WOTMtiVcm4IdK+vqMTcalOhOkeJf0on5dVQV4qNt+Nl9RrzlXfTDc3jdO2S9UNtDi+VOkO 2lbevcnAQIqHAn5AYAyzWaVk0pScmnoeoFLO2kStmO5YXdIr9vV8If5K9M+Cv8e4/ukcxp qXabwilnGwLU1kSrNsSv8wwMStkQLkc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732220135; a=rsa-sha256; cv=none; b=D3g4uvrLv6n+frEFzlvfRkVuE0BRdYjJzmkveAs3PoN7cm76gppy6wXIfH1nUnyGvGCklt AG3cfUVIN/eRNM+cGTjqXmXj2tGfNEmigCvzryWl5fhGMXhCfnIxOeqyjsjviy/Y0qlNSG cnN3cGwgKG+Deq4nmAqAYJ5XgEwfwwE= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LGjIbV9C; spf=pass (imf27.hostedemail.com: domain of jannh@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5d00ecd97beso1906a12.1 for ; Thu, 21 Nov 2024 12:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732220284; x=1732825084; 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=QsRAQ6t08WPFqqtrK9Y/yi/Kj5TOA65Z3KS9Ukbgptk=; b=LGjIbV9CF4KGerUwSlXeBVvbPYUZ0QXZRCeyLH/qNDMiPJ+PcS7z40x526vbks/FSE /uu/hHcZJFTMuoqkLRGRHIH21Mgl/+srMDBzLCKIEQAwmOyV9QUMYuJLu+NDllmIG++x 04tTxLrof9iRRVNadQWX3NWqpxdvmsu9oXdIR8AHqfKRvUlmtBI7wOB2MRJCyGdwxHBq pM2+lWpCwhdMyEL/v9bCNnWUq1Nxe0JjnWKXJWSbr2rHWddSvNKrs0/TORSPHShHXGpP XajXVXR+watUpHeuza3qBvvSk/b/xAT4kF0o/FyuSFsQkmrNlCUXbobmfA+ieuXjmfFW v/iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732220284; x=1732825084; 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=QsRAQ6t08WPFqqtrK9Y/yi/Kj5TOA65Z3KS9Ukbgptk=; b=Q9xaFTZatYKdRcMAsFaLoGhVf4hG3fs/J3pKOjI41ZoBh0e7hLx4CFBd9z3iYXH5ZY anhIjrOFaHnzsGkJcEL8fXg2to0n7QhLoID8c2CJeT9GpyebKohMcGij5ufCcrRZxgg1 DbHL9LEZ2/TLFHY5ULqsNqByHSdpwwWosD6KkVTy0MnX35w/7GEhE8em9GgpuA4IA5x0 2maqjzP0e+gjVOa9d6ysc0G45zA+qnp3HO/D1wvp6q0kJm1vUooJ1IPFkr8QAMhsc/Rh y5SblrWJC3U4SAM/o6j59ut70aAPR3P3YVmBMLH5D0PX7jdj0MvgqwNlcjs10zQBqPYD oU7g== X-Forwarded-Encrypted: i=1; AJvYcCWu04484K8h+orYtntgjkYMbkEjhdCXb0bsfpgiaqU4W4NXAtB1vmo1di2jOh5i0sp2a09dP0UXPw==@kvack.org X-Gm-Message-State: AOJu0Yx0JWbjiTq4Ydjvf8JcUUpaXC2vSO9VjKh84IuRj9R6g5BQtiEv GOULV/ZfDYbXhYvpAt4syMios/kMTXemkpmPkJFTA6mDK+/63saogk4NGMB8IVQIMCCr+/H32q8 Xmn5FklKrIT4CZqgTOPL48R1R+LGSuAw69wqN X-Gm-Gg: ASbGncv3IUuZgUgY1Rx1MQa+sdiW9kIBS+qF2HLhc0oboyOKE8CHrbBqR7ZVP4cw4OL FtX4gjJtTSiS7ui5aiUz3emroYw8WUxLp20cqyhso50owc0JBdW99x0mRxLI= X-Google-Smtp-Source: AGHT+IFvnfJzTTJ/+eR3Vxjo7zD5SinHcpQMhmMje2i6LAznZGVS+bpiK7Ig3Hi4h3GcgmluFEyuti7p0HNlUHLa6I0= X-Received: by 2002:a05:6402:5158:b0:5d0:a5a:6ffc with SMTP id 4fb4d7f45d1cf-5d01e4fe710mr7807a12.6.1732220284214; Thu, 21 Nov 2024 12:18:04 -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: <43a07c04-2985-4999-b6d6-732794906a36@gmail.com> From: Jann Horn Date: Thu, 21 Nov 2024 21:17:28 +0100 Message-ID: Subject: Re: [PATCH v3 2/2] rust: page: Extend support to existing struct page mappings To: Abdiel Janulgue Cc: 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 , Alice Ryhl , 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-Server: rspam12 X-Rspamd-Queue-Id: D88824000A X-Stat-Signature: ez63yqxda8qk9hc3kut9twi981my6tdu X-HE-Tag: 1732220228-919104 X-HE-Meta: U2FsdGVkX19JfI3YDLykGsjR9QCE38jsO1a5/n1Z5bn+ZW3uXL3svYZ7QZND/3Nx8rhw9iyH4pK50C8/wX90Ubp+/esyZq5afzEMqyolZ89Voiklh3ycp39G9d2y8Qs4lV+/AM40DMhKbWbSalLiZPhsaA3CaPY1LZSlSfjrKQXedF7Q615HcrcHuiVM/jSpzZj8q+wZhYw3GhCdyg9Q9hsWI+j6GXfhW57cXY09N+1rJuEbv6g1fSXgyzntlZrhmrCX77LIEmo3gzMibHHjX7DRfgeBpRov0PIY9G9YdqMZzbINoXp5f3p1dHN2g9TWSzpP5haCR4XFwmVX4IGvYrWY8kYI8syIo+NsAmzSOlXpNja/4DeMUUjh8iwG0eq5RhOSpXo2jyi5jpOg+aOXMjmQEhaMEAheI/rpauxPMmucrGkUUGbjbtp5ngrbQj3r+zQ7gf+z7BxU8fgeunaIvCVAqwi/iWiWZbZmSwam2eAfuG686SKB8XD8fpTRYCcLrvoTkO82sE855AkYOExsmpFSaIBjSVQ0vpn3+qhZLV0cNzqApWcWXUJUJ41FRFQpI3sg6LmOur9kTGyVRGoGsQgoeg27zLd6lTlXESOe+c6Mns+qXsssTRL/VaRcfSUXHrEtx4LyJl88R4lAO60HYeHawX5i49kYE+TqUNiD0s+IgXaRiB3av7VGXPagm/1KhrXEMtYkufP4hsZ77A+lCrYITC5uLXvo4qSVo8JkkJBkavBA2yNzuVbbQAl+Uaet/DTUrp5u2yPYAy2YnK0gvuYn/9FlpW9TQ76NqlTPCUNxo4F5EeNe5tvbzcAbgAHQtHW3cpeDfDZsp0+9UblzOKgaX+x9F1rJ/6dxdMufdp/CQOEYBZkmPlUz1pFOT1TH4IdrdRPEZ16Pt7HJtqUmGpL19SbsfSBl7W4C9XRaCkbxXWR4LNDIBTYQx3ac3XKtH3KhrGacGcos/Hl8Zja Xua+KiBd 9v2rIi3ehrIr8d1aB1XZuYgqaK1pV7060Krdt95GCshicsz0oM/URgO/tzoGWie9FqbDaMlrzF5rZiR1AaeOFdjTlYQull7mSc1ybq8a6U5+WSAH82KCkrEA8xQgag0BEjIctu62egQAE8Np3rCBmYr+epMhq0x3BOS9ebgNERSX2yfCu8rL15FK5NDbeDh2ZAhLOTJ1noqOayzcLPxxOukKJZGfcRyo2b1vG32J69jxiL4W0ctP8p5vF++IoaZmqu7DkQ6e9PD0lfLJ6j8VX/jzRreB0yWD7tRr7VthRHelnrw9sB3cKyQJ9vNDJBtUuschb X-Bogosity: Ham, tests=bogofilter, spamicity=0.000045, 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 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 Sel= f> > > > > Sorry, can you explain to me what the semantics of this are? Does this > > 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.md ``` 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? > >> +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 as > > 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?