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 BD15FD64085 for ; Fri, 8 Nov 2024 20:06:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 55974900007; Fri, 8 Nov 2024 15:06:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 509618D0001; Fri, 8 Nov 2024 15:06:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 35C48900007; Fri, 8 Nov 2024 15:06:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 131CA8D0001 for ; Fri, 8 Nov 2024 15:06:08 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A3FA8120F0D for ; Fri, 8 Nov 2024 20:06:07 +0000 (UTC) X-FDA: 82764007494.19.8BF24B9 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf10.hostedemail.com (Postfix) with ESMTP id E3BBFC0015 for ; Fri, 8 Nov 2024 20:05:48 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zOwMrxmQ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of jannh@google.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731096194; a=rsa-sha256; cv=none; b=UXeY3fJEsQeqP4ZtqWygYe9DUr4BMWhdDuzrkfPkDjdngYNdn2k4BcWumE5blmUIzj5Vfu /R75pcapkDgEoY0x6EJcXOu4WggnnVMTnk8gW9sJwswOb0X9wsyN+/j9fHpcmWMGW7Yz0A XCMASl3oGkgZcVVjQYTEr6CXEp3Zetg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zOwMrxmQ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of jannh@google.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731096194; 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=ywmyj2+mwTU628wLUF2xRspDilFf9o3W6NRYN3/t0Co=; b=GahNJSrssSErG0wj6IH9GFruVUsGnQ28ZQBL/Zhm46qYsyYWhTcgKCwKPiR9fucVKiQxVw 98MbvZwbOqfmEYOq1Qgw0OiYhbyJr5qm9GvztOghrA7Dr0qesuOYvrLg7BgBoVmoSCd/PX w50n8XZd7oRzwn39fdR5D+e4KONhQQ4= Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-539e681ba70so3968e87.1 for ; Fri, 08 Nov 2024 12:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731096364; x=1731701164; 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=ywmyj2+mwTU628wLUF2xRspDilFf9o3W6NRYN3/t0Co=; b=zOwMrxmQFRs6mupjQfcR9exAlfkBzKDE24AMgxl0kSW+w05PExLVRgWafjPhoOJvov 06a6E0kbK75zmdgRnhU6AZJgfxhag9+M9N74z9V2VR1E5oPo/IFag2n+DTJ1DIz5AcQR SbvHxohnq4fUOVwyLyyTQHjUGpefwlr0S4Ye5x5m+c7zFKnvopi0EhV9ESc6E3PSoYR/ ClQeoS/3N9aKU4iKesOQ+HbRl+HtMEv74BD2iUOddFzSrxY/MJ6GDpKE/yC3L/dWcd3m Z5Th+oyr0v4tjwJVQhh/8DnMwb2+JW3aYNS2Cncr7B1UE5y4wdQoX3UkWbKvsEtt4hyF 31wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731096364; x=1731701164; 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=ywmyj2+mwTU628wLUF2xRspDilFf9o3W6NRYN3/t0Co=; b=QvVe/ECQ+cu66V86YFqZpDlE1YXdJLB0mDE0eIAulC5zmg70vWco0SxLGW3PZ0q4o3 ZvEMT5Nr5OAN70g9Gb/Ucw3DxpjHVX7CJFubwR2A3X28aAHpTen2uaNelCuJ0vYOuC4N YorrjoGIukCZuCq+AQ6I+NiHEOh3OOJm1NmYMupVj4SG8JCIpiUs7W0uWpiKqUxhawov 4LEcnOTNeYJuyf/wqxgBUOx41JpLh1UiMXYIJLsyEfuVW3FikQqOmyyURvbPJvsiZYyj RTROa+XL0dzHOyW5PgqUyRHAbQGxA73GL79GhyuCEMGQGAmB4Q2qMNmYveqr/Cxn9l8T UZog== X-Forwarded-Encrypted: i=1; AJvYcCV4Nwrk21a+GgI+NjVAPb4/YJwAnZhoDr9J2nNOoZ4Xi+pR+XnwBbl8x+zbFajPqu6Lyz+llbMFAQ==@kvack.org X-Gm-Message-State: AOJu0YyBJXKdUgL2SXGCeP4z8MissWekfLeOv4NigbT0QbcU0ASCCh78 3QQg5OptloatC8pttMdJta8qBeBQiE7XVztnFlJUW+DyfYiIPYqYeAW/vnONC0qyruQDYSuc8o1 xesdb1bWc1IQhCFT1XpgtBjeqNzaxWXDpRBB5 X-Gm-Gg: ASbGncs2fboNhMF0uXd4XA13NkbRBAuBZAoSi75gucRVUHiInO1+8659vMEXmN5m00K efG2eBehVxZ16ytX3CKpqKHFFdqwo9sQytkPL0qX/bW8NqoXYfkGq1KUotXg= X-Google-Smtp-Source: AGHT+IH3kL4lLs0Uipupi9GWt32/5/tNTyCIa5bVmyx6fwQw8gtGwZzBdd1MsiyDybp0ou2acgQ0QsuHTDGC9DKGes0= X-Received: by 2002:ac2:44cf:0:b0:533:49ab:780e with SMTP id 2adb3069b0e04-53d8bd9a3e5mr66025e87.2.1731096363220; Fri, 08 Nov 2024 12:06:03 -0800 (PST) MIME-Version: 1.0 References: <20241010-vma-v6-0-d89039b6f573@google.com> <20241010-vma-v6-1-d89039b6f573@google.com> In-Reply-To: From: Jann Horn Date: Fri, 8 Nov 2024 21:05:27 +0100 Message-ID: Subject: Re: [PATCH v6 1/2] rust: mm: add abstractions for mm_struct and vm_area_struct To: Alice Ryhl Cc: Miguel Ojeda , Matthew Wilcox , Lorenzo Stoakes , Vlastimil Babka , John Hubbard , "Liam R. Howlett" , Andrew Morton , Greg Kroah-Hartman , Arnd Bergmann , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org, Andreas Hindborg , Wedson Almeida Filho Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: din736r36a4uh7djfg5t343wnffm81b5 X-Rspamd-Queue-Id: E3BBFC0015 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1731096348-427780 X-HE-Meta: U2FsdGVkX1/UlqL/SA2IDQ7UEYxZKQmbPZfVHyD/xb+q8eDo6ERrVvL9M6eu9dUdv4mC+IFAYI8nobaVxpJCp2yaDLUx+lk2ekin+xSvCVxm2mwHGMUaATED+pmBtu13YzJVvuoobxYK1f5xfhqjQx42WJJ1KQL1/tzAgF2ff3y+pDpoykA3TO2jh/lOpwVrxcsEJjfooynAUpakJ1Fn0GX/KE8NV5QP7hkZIyFe6UShXU6Um591cYkud2r1VpHcU3mHtUgP6jkoW7W7kqpRiOcZ/nMA4rnBtEXqzXmzoo/dSF00fNfP4KHVCwYa4jN0A40Bh9giHU//QSipPzWNkYLthxO/kbmHcGlr7PiJNp9sqIp4vCBasKGQhGozlpDSqzKGx60o167+6zCbgwDv7Uca9uZV3dLC0KmBz1BnP3MuKJfzyLCZaSMKqNIvGZ+3fHMh1YbZyODCjoZhfWlmmL+v6Bry8ixkfeanQqGwNcdFCouMoU6vhCN8xzHR/vOt+Hfgh9a2lX4l1QB0UJOU3kiTe9SVOSRGj9/ACX3f/guYoDO9+/vvEiPi0MF9nRgTu9I1YRiClpmi6kOKNQxX8vVztRnS7Z2xTXHbX7T+VA3qne1ao+9HIXBDLufgjkOUWd03TQ+DAQSxlHUTJ5RE8GJr+59r7II+d8O6Hvcp4JJeoD0S3SQY8lFOH/L6vgTL5I231E1LD0GThsNQ0wjb4LiyT9naeGUZEDWqPC+JUyId5IFPODi+mZoxV5soR+Q+sZPBULVKOs8nUW9cs/pKUQzA8f3S8qbk8FgplT2j1eIrDw7JPP5luXuRcKND93ls49DW9MyyvwcVmXSNEUUQX7NW0dTxhYLJdYXFxQvtVNiSAHsVjsvH0MVCeAJWi4Q9mRSXQPlgWCZHT4i7dmJ0+X4jY7HwBK5E++/NholJZsk+IVr1utA0mluLs73sxARV6ONXX/atA0tRjvBVZBg BPUhvXmv nBqPQD5iSceYxQYqVoFshaN1u2BWAaFYYjVUfe/FYpTEptMlXgGpB5H+yCDiWh+s59Z/j9uH2sGYRX2EH4iaO+E/iXFv/cBgOuXbUWHkqn2Aa7l6Qyd//REmL7EhIqwgUOi++E1qfAyFZuAKa/j84FoH82sgna8x6Y7QZEQxNSZO6rS0b07q/Q4ujMMyz11CyRRowtYmomncWm8zjQLvJ6I9cOrS0lO9dMGx5JDBnhvzfXai8aHbVujFMS9LxlaOmU75BflXEZZcxYtC8DlSbwvvSwSujtg0Smha9g1GcetKGGVc2AYLFk9ZlhmnkrUg74PfIj1gxg4Xz3dTgNh4kGrU71g== 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 Fri, Nov 8, 2024 at 8:01=E2=80=AFPM Jann Horn wrote: > On Thu, Oct 10, 2024 at 2:56=E2=80=AFPM Alice Ryhl = wrote: > > These abstractions allow you to manipulate vmas. Rust Binder will uses > > these in a few different ways. > > > > In the mmap implementation, a VmAreaNew will be provided to the mmap > > call which allows it to modify the vma in ways that are only okay durin= g > > initial setup. This is the case where the most methods are available. > > > > However, Rust Binder needs to insert and remove pages from the vma as > > time passes. When incoming messages arrive, pages may need to be > > inserted if space is missing, and in this case that is done by using a > > stashed ARef and calling mmget_not_zero followed by mmap_write_lock > > followed by vma_lookup followed by vm_insert_page. In this case, since > > mmap_write_lock is used, the VmAreaMut type will be in use. > > FYI, the way the C binder implementation uses vma_lookup() and > vm_insert_page() is not very idiomatic. The standard way of > implementing binder_alloc_free_page() would be to use something like > unmap_mapping_range() instead of using > vma_lookup()+zap_page_range_single(); though to set that up, you'd > have to create one inode per binder file, maybe with something like > the DRM subsystem's drm_fs_inode_new(). And instead of having > binder_install_single_page(), the standard way would be to let > binder_vm_fault() install PTEs lazily on fault. That way you'd never > have to take mmap locks or grab MM references yourself. Let me know if you think it would be helpful to see a prototype of that in C - I think I can cobble that together, but doing it nicely will require some work to convert at least some of the binder_alloc locking to mutexes, and some more work to switch the ->f_mapping of the binder file or something like that. (I guess modeling that in Rust might be a bit of a pain though...)