[v14,0/8] Rust support for mm_struct, vm_area_struct, and mmap

Message

Alice Ryhl Feb. 13, 2025, 11:03 a.m. UTC

This updates the vm_area_struct support to use the approach we discussed
at LPC where there are several different Rust wrappers for
vm_area_struct depending on the kind of access you have to the vma. Each
case allows a different set of operations on the vma.

MM folks, what do you prefer I do for the MAINTAINERS file? Would you
prefer that I add these files under MEMORY MANAGEMENT, or would you like
a separate entry similar to the BLOCK LAYER DEVICE DRIVER API [RUST]
entry? Or something else?

Signed-off-by: Alice Ryhl <[e-mail]>
---
Changes in v14:
- Rename VmArea* to Vma* as suggested by Liam.
- Update a few comments in patch 02.
- Link to v13: https://lore.kernel.org/r/[e-mail]

Changes in v13:
- Rebase on v6.14-rc1.
- Remove casts that are now unnecessary due to improved Rust/C integer
  type mappings.
- Link to v12: https://lore.kernel.org/r/[e-mail]

Changes in v12:
- Add additional documentation to modules at the top of mm.rs and virt.rs.
- Explain why the name Mm is used in commit message of patch 1.
- Expand zap_page_range_single with docs suggested by Lorenzo.
- Update safety comment in vm_insert_page
- Mention that VmAreaMixedMap is identical to VmAreaRef except for VM_MIXEDMAP.
- Update docs for as_mixedmap_vma.
- Add additional docs for VmAreaNew struct.
- Rename `get_read` -> `readable` and equivalent for write/exec.
- Use mut pointers for `from_raw` for VMAs.
- Update safety comment for fops_mmap.
- Add additional docs for MiscDevice::mmap.
- Don't introduce and immediately delete mmgrab_current.
- Reduce active_pid_ns comment at Andreas's suggestion and link to get_pid_ns.
- Fix documentation test in rust/kernel/task.rs.
- Fix warning about unused variables in lock_vma_under_rcu when
  CONFIG_PER_VMA_LOCK=n.
- Fix minor typos.
- Link to v11: https://lore.kernel.org/r/[e-mail]

Changes in v11:
- Add accessor for the vm_mm field of vm_area_struct.
- Pass the file to MiscDevice::mmap for consistency with
  https://lore.kernel.org/r/[e-mail]
- Link to v10: https://lore.kernel.org/r/[e-mail]

Changes in v10:
- Update docs for `set_io`.
- Check address in `zap_page_range_single`.
- Completely redo the last patch.
- Link to v9: https://lore.kernel.org/r/[e-mail]

Changes in v9:
- Be more explicit about VmAreaNew being used with f_ops->mmap().
- Point out that clearing VM_MAYWRITE is irreversible.
- Use __vm_flags to set the flags.
- Use as_ and into_ prefixes for conversions.
- Update lock_vma_under_rcu docs and commit msg
- Mention that VmAreaRef::end is exclusive.
- Reword docs for zap_page_range_single.
- Minor fixes to flag docs.
- Add way to access current->mm without a refcount increment.
- Link to v8: https://lore.kernel.org/r/[e-mail]

Changes in v8:
- Split series into more commits to ease review.
- Improve read locks based on Lorenzo's doc: either the mmap or vma lock
  can be used.
- Get rid of mmap write lock because it's possible to avoid the need for
  it.
- Do not allow invalid flag combinations on VmAreaNew.
- Link to v7: https://lore.kernel.org/r/[e-mail]

Changes in v7:
- Make the mmap read/write lock guards respect strict owner semantics.
- Link to v6: https://lore.kernel.org/r/[e-mail]

Changes in v6:
- Introduce VmArea{Ref,Mut,New} distinction.
- Add a second patchset for miscdevice.
- Rebase on char-misc-next (currently on v6.12-rc2).
- Link to v5: https://lore.kernel.org/r/[e-mail]

Changes in v5:
- Rename VmArea::from_raw_vma to from_raw.
- Use Pin for mutable VmArea references.
- Go through `ARef::from` in `mmgrab_current`.
- Link to v4: https://lore.kernel.org/r/[e-mail]

Changes in v4:
- Pull out ARef::into_raw into a separate patch.
- Update invariants and struct documentation.
- Rename from_raw_mm to from_raw.
- Link to v3: https://lore.kernel.org/r/[e-mail]

Changes in v3:
- Reorder entries in mm.rs.
- Use ARef for mmput_async helper.
- Clarify that VmArea requires you to hold the mmap read or write lock.
- Link to v2: https://lore.kernel.org/r/[e-mail]

Changes in v2:
- mm.rs is redesigned from scratch making use of AsRef
- Add notes about whether destructors may sleep
- Rename Area to VmArea
- Link to v1: https://lore.kernel.org/r/[e-mail]

---
Alice Ryhl (8):
      mm: rust: add abstraction for struct mm_struct
      mm: rust: add vm_area_struct methods that require read access
      mm: rust: add vm_insert_page
      mm: rust: add lock_vma_under_rcu
      mm: rust: add mmput_async support
      mm: rust: add VmaNew for f_ops->mmap()
      rust: miscdevice: add mmap support
      task: rust: rework how current is accessed

 rust/helpers/helpers.c    |   1 +
 rust/helpers/mm.c         |  50 +++++
 rust/kernel/lib.rs        |   1 +
 rust/kernel/miscdevice.rs |  44 +++++
 rust/kernel/mm.rs         | 341 +++++++++++++++++++++++++++++++++
 rust/kernel/mm/virt.rs    | 471 ++++++++++++++++++++++++++++++++++++++++++++++
 rust/kernel/task.rs       | 247 ++++++++++++------------
 7 files changed, 1037 insertions(+), 118 deletions(-)
---
base-commit: a64dcfb451e254085a7daee5fe51bf22959d52d3
change-id: 20240723-vma-f80119f9fb35

Best regards,

Comments

Lorenzo Stoakes Feb. 13, 2025, 11:14 a.m. UTC | #1

Andrew - this series has significant review and all feedback has been
addressed, I believe the procedure for rust things is that, where possible,
the maintainers for the subsystem generally take series (though of course,
it is entirely maintained and managed by rust people).

Would it be possible to take this, or do you need anything else here?

Thanks!

On Thu, Feb 13, 2025 at 11:03:59AM +0000, Alice Ryhl wrote:
> This updates the vm_area_struct support to use the approach we discussed
> at LPC where there are several different Rust wrappers for
> vm_area_struct depending on the kind of access you have to the vma. Each
> case allows a different set of operations on the vma.
>
> MM folks, what do you prefer I do for the MAINTAINERS file? Would you
> prefer that I add these files under MEMORY MANAGEMENT, or would you like
> a separate entry similar to the BLOCK LAYER DEVICE DRIVER API [RUST]
> entry? Or something else?

This is one for Andrew to decide, but to me it seems most logical to add a
new entry like 'MEMORY MANAGEMENT [RUST]'.

And I think it'd be ideal to do so with this imminently landing, not sure
if we ought to merge as part of the series or separately - again, one for
Andrew to opine on :)

Thanks for all the hard work Alice and co, this is great!

>
> Signed-off-by: Alice Ryhl <[e-mail]>
> ---
> Changes in v14:
> - Rename VmArea* to Vma* as suggested by Liam.
> - Update a few comments in patch 02.
> - Link to v13: https://lore.kernel.org/r/[e-mail]
>
> Changes in v13:
> - Rebase on v6.14-rc1.
> - Remove casts that are now unnecessary due to improved Rust/C integer
>   type mappings.
> - Link to v12: https://lore.kernel.org/r/[e-mail]
>
> Changes in v12:
> - Add additional documentation to modules at the top of mm.rs and virt.rs.
> - Explain why the name Mm is used in commit message of patch 1.
> - Expand zap_page_range_single with docs suggested by Lorenzo.
> - Update safety comment in vm_insert_page
> - Mention that VmAreaMixedMap is identical to VmAreaRef except for VM_MIXEDMAP.
> - Update docs for as_mixedmap_vma.
> - Add additional docs for VmAreaNew struct.
> - Rename `get_read` -> `readable` and equivalent for write/exec.
> - Use mut pointers for `from_raw` for VMAs.
> - Update safety comment for fops_mmap.
> - Add additional docs for MiscDevice::mmap.
> - Don't introduce and immediately delete mmgrab_current.
> - Reduce active_pid_ns comment at Andreas's suggestion and link to get_pid_ns.
> - Fix documentation test in rust/kernel/task.rs.
> - Fix warning about unused variables in lock_vma_under_rcu when
>   CONFIG_PER_VMA_LOCK=n.
> - Fix minor typos.
> - Link to v11: https://lore.kernel.org/r/[e-mail]
>
> Changes in v11:
> - Add accessor for the vm_mm field of vm_area_struct.
> - Pass the file to MiscDevice::mmap for consistency with
>   https://lore.kernel.org/r/[e-mail]
> - Link to v10: https://lore.kernel.org/r/[e-mail]
>
> Changes in v10:
> - Update docs for `set_io`.
> - Check address in `zap_page_range_single`.
> - Completely redo the last patch.
> - Link to v9: https://lore.kernel.org/r/[e-mail]
>
> Changes in v9:
> - Be more explicit about VmAreaNew being used with f_ops->mmap().
> - Point out that clearing VM_MAYWRITE is irreversible.
> - Use __vm_flags to set the flags.
> - Use as_ and into_ prefixes for conversions.
> - Update lock_vma_under_rcu docs and commit msg
> - Mention that VmAreaRef::end is exclusive.
> - Reword docs for zap_page_range_single.
> - Minor fixes to flag docs.
> - Add way to access current->mm without a refcount increment.
> - Link to v8: https://lore.kernel.org/r/[e-mail]
>
> Changes in v8:
> - Split series into more commits to ease review.
> - Improve read locks based on Lorenzo's doc: either the mmap or vma lock
>   can be used.
> - Get rid of mmap write lock because it's possible to avoid the need for
>   it.
> - Do not allow invalid flag combinations on VmAreaNew.
> - Link to v7: https://lore.kernel.org/r/[e-mail]
>
> Changes in v7:
> - Make the mmap read/write lock guards respect strict owner semantics.
> - Link to v6: https://lore.kernel.org/r/[e-mail]
>
> Changes in v6:
> - Introduce VmArea{Ref,Mut,New} distinction.
> - Add a second patchset for miscdevice.
> - Rebase on char-misc-next (currently on v6.12-rc2).
> - Link to v5: https://lore.kernel.org/r/[e-mail]
>
> Changes in v5:
> - Rename VmArea::from_raw_vma to from_raw.
> - Use Pin for mutable VmArea references.
> - Go through `ARef::from` in `mmgrab_current`.
> - Link to v4: https://lore.kernel.org/r/[e-mail]
>
> Changes in v4:
> - Pull out ARef::into_raw into a separate patch.
> - Update invariants and struct documentation.
> - Rename from_raw_mm to from_raw.
> - Link to v3: https://lore.kernel.org/r/[e-mail]
>
> Changes in v3:
> - Reorder entries in mm.rs.
> - Use ARef for mmput_async helper.
> - Clarify that VmArea requires you to hold the mmap read or write lock.
> - Link to v2: https://lore.kernel.org/r/[e-mail]
>
> Changes in v2:
> - mm.rs is redesigned from scratch making use of AsRef
> - Add notes about whether destructors may sleep
> - Rename Area to VmArea
> - Link to v1: https://lore.kernel.org/r/[e-mail]
>
> ---
> Alice Ryhl (8):
>       mm: rust: add abstraction for struct mm_struct
>       mm: rust: add vm_area_struct methods that require read access
>       mm: rust: add vm_insert_page
>       mm: rust: add lock_vma_under_rcu
>       mm: rust: add mmput_async support
>       mm: rust: add VmaNew for f_ops->mmap()
>       rust: miscdevice: add mmap support
>       task: rust: rework how current is accessed
>
>  rust/helpers/helpers.c    |   1 +
>  rust/helpers/mm.c         |  50 +++++
>  rust/kernel/lib.rs        |   1 +
>  rust/kernel/miscdevice.rs |  44 +++++
>  rust/kernel/mm.rs         | 341 +++++++++++++++++++++++++++++++++
>  rust/kernel/mm/virt.rs    | 471 ++++++++++++++++++++++++++++++++++++++++++++++
>  rust/kernel/task.rs       | 247 ++++++++++++------------
>  7 files changed, 1037 insertions(+), 118 deletions(-)
> ---
> base-commit: a64dcfb451e254085a7daee5fe51bf22959d52d3
> change-id: 20240723-vma-f80119f9fb35
>
> Best regards,
> --
> Alice Ryhl <[e-mail]>
>

Miguel Ojeda Feb. 13, 2025, 11:32 a.m. UTC | #2

On Thu, Feb 13, 2025 at 12:14 PM Lorenzo Stoakes
<[e-mail]> wrote:
>
> the maintainers for the subsystem generally take series (though of course,
> it is entirely maintained and managed by rust people).

Just in case: I am not sure what "rust people" means here, but if you
meant the Rust subsystem, then it is not the case. Maintenance depends
on what the subsystem wants to do (including how to handle patches,
but also the actual maintenance), who steps up to maintain it, whether
the subsystem wants new co-maintainers or sub-maintainers, etc.

    https://rust-for-linux.com/rust-kernel-policy#how-is-rust-introduced-in-a-subsystem
    https://rust-for-linux.com/rust-kernel-policy#who-maintains-rust-code-in-the-kernel

That is why the cover letter asks about the `MAINTAINERS` file.

I hope that clarifies.

Cheers,
Miguel

Lorenzo Stoakes Feb. 13, 2025, 11:50 a.m. UTC | #3

On Thu, Feb 13, 2025 at 12:32:27PM +0100, Miguel Ojeda wrote:
> On Thu, Feb 13, 2025 at 12:14 PM Lorenzo Stoakes
> <[e-mail]> wrote:
> >
> > the maintainers for the subsystem generally take series (though of course,
> > it is entirely maintained and managed by rust people).
>
> Just in case: I am not sure what "rust people" means here, but if you
> meant the Rust subsystem, then it is not the case. Maintenance depends
> on what the subsystem wants to do (including how to handle patches,
> but also the actual maintenance), who steps up to maintain it, whether
> the subsystem wants new co-maintainers or sub-maintainers, etc.
>
>     https://rust-for-linux.com/rust-kernel-policy#how-is-rust-introduced-in-a-subsystem
>     https://rust-for-linux.com/rust-kernel-policy#who-maintains-rust-code-in-the-kernel
>
> That is why the cover letter asks about the `MAINTAINERS` file.

Right, I don't mean the rust subsystem, I mean designated rust
maintainers. The point being that this won't add workload to Andrew, nor
require him nor other mm C people to understand rust.

As stated, I agree we need to add an entry to MAINTAINERS for this, which
is why I explicitly chased this up.

>
> I hope that clarifies.
>
> Cheers,
> Miguel

Alice Ryhl Feb. 13, 2025, 11:53 a.m. UTC | #4

On Thu, Feb 13, 2025 at 12:50 PM Lorenzo Stoakes
<[e-mail]> wrote:
>
> On Thu, Feb 13, 2025 at 12:32:27PM +0100, Miguel Ojeda wrote:
> > On Thu, Feb 13, 2025 at 12:14 PM Lorenzo Stoakes
> > <[e-mail]> wrote:
> > >
> > > the maintainers for the subsystem generally take series (though of course,
> > > it is entirely maintained and managed by rust people).
> >
> > Just in case: I am not sure what "rust people" means here, but if you
> > meant the Rust subsystem, then it is not the case. Maintenance depends
> > on what the subsystem wants to do (including how to handle patches,
> > but also the actual maintenance), who steps up to maintain it, whether
> > the subsystem wants new co-maintainers or sub-maintainers, etc.
> >
> >     https://rust-for-linux.com/rust-kernel-policy#how-is-rust-introduced-in-a-subsystem
> >     https://rust-for-linux.com/rust-kernel-policy#who-maintains-rust-code-in-the-kernel
> >
> > That is why the cover letter asks about the `MAINTAINERS` file.
>
> Right, I don't mean the rust subsystem, I mean designated rust
> maintainers. The point being that this won't add workload to Andrew, nor
> require him nor other mm C people to understand rust.
>
> As stated, I agree we need to add an entry to MAINTAINERS for this, which
> is why I explicitly chased this up.

I am happy to be listed as a maintainer of this code.

Alice

Lorenzo Stoakes Feb. 13, 2025, 11:56 a.m. UTC | #5

On Thu, Feb 13, 2025 at 12:53:51PM +0100, Alice Ryhl wrote:
> On Thu, Feb 13, 2025 at 12:50 PM Lorenzo Stoakes
> <[e-mail]> wrote:
> >
> > On Thu, Feb 13, 2025 at 12:32:27PM +0100, Miguel Ojeda wrote:
> > > On Thu, Feb 13, 2025 at 12:14 PM Lorenzo Stoakes
> > > <[e-mail]> wrote:
> > > >
> > > > the maintainers for the subsystem generally take series (though of course,
> > > > it is entirely maintained and managed by rust people).
> > >
> > > Just in case: I am not sure what "rust people" means here, but if you
> > > meant the Rust subsystem, then it is not the case. Maintenance depends
> > > on what the subsystem wants to do (including how to handle patches,
> > > but also the actual maintenance), who steps up to maintain it, whether
> > > the subsystem wants new co-maintainers or sub-maintainers, etc.
> > >
> > >     https://rust-for-linux.com/rust-kernel-policy#how-is-rust-introduced-in-a-subsystem
> > >     https://rust-for-linux.com/rust-kernel-policy#who-maintains-rust-code-in-the-kernel
> > >
> > > That is why the cover letter asks about the `MAINTAINERS` file.
> >
> > Right, I don't mean the rust subsystem, I mean designated rust
> > maintainers. The point being that this won't add workload to Andrew, nor
> > require him nor other mm C people to understand rust.
> >
> > As stated, I agree we need to add an entry to MAINTAINERS for this, which
> > is why I explicitly chased this up.
>
> I am happy to be listed as a maintainer of this code.

And based on my highly positive interactions with you and your clear depth
of knowledge in rust + endlessly patient interactions with us mm C folk I
for one am absolutely happy to endorse this + ack any such change to
MAINTAINERS :)

>
> Alice
>

Miguel Ojeda Feb. 13, 2025, 12:03 p.m. UTC | #6

On Thu, Feb 13, 2025 at 12:50 PM Lorenzo Stoakes
<[e-mail]> wrote:
>
> Right, I don't mean the rust subsystem, I mean designated rust
> maintainers. The point being that this won't add workload to Andrew, nor
> require him nor other mm C people to understand rust.

Sounds good, and apologies for being pedantic, but given the recent
discussions, I thought I should clarify just in case others read it
differently.

In the same vein, one more quick thing (that you probably didn't mean
in this way, but still, I think it is better I add the note, sorry): I
don't think it is true that it will not add workload to Andrew or MM
in general. It always adds some workload, even if the maintainers
don't handle the patches at all, since they may still need to perform
a small change in something Rust related due to another change they
need to do, or perhaps at least contact the Rust sub-maintainer to do
it for them, etc.

    https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers

Cheers,
Miguel

Lorenzo Stoakes Feb. 13, 2025, 12:16 p.m. UTC | #7

On Thu, Feb 13, 2025 at 01:03:04PM +0100, Miguel Ojeda wrote:
> On Thu, Feb 13, 2025 at 12:50 PM Lorenzo Stoakes
> <[e-mail]> wrote:
> >
> > Right, I don't mean the rust subsystem, I mean designated rust
> > maintainers. The point being that this won't add workload to Andrew, nor
> > require him nor other mm C people to understand rust.
>
> Sounds good, and apologies for being pedantic, but given the recent
> discussions, I thought I should clarify just in case others read it
> differently.
>
> In the same vein, one more quick thing (that you probably didn't mean
> in this way, but still, I think it is better I add the note, sorry): I
> don't think it is true that it will not add workload to Andrew or MM
> in general. It always adds some workload, even if the maintainers
> don't handle the patches at all, since they may still need to perform
> a small change in something Rust related due to another change they
> need to do, or perhaps at least contact the Rust sub-maintainer to do
> it for them, etc.
>
>     https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers
>
> Cheers,
> Miguel

Ack, for the record I'm happy to help with any work that might come up.

Liam R. Howlett Feb. 13, 2025, 7:46 p.m. UTC | #8

* Lorenzo Stoakes <[e-mail]> [250213 07:16]:
> On Thu, Feb 13, 2025 at 01:03:04PM +0100, Miguel Ojeda wrote:
> > On Thu, Feb 13, 2025 at 12:50 PM Lorenzo Stoakes
> > <[e-mail]> wrote:
> > >
> > > Right, I don't mean the rust subsystem, I mean designated rust
> > > maintainers. The point being that this won't add workload to Andrew, nor
> > > require him nor other mm C people to understand rust.
> >
> > Sounds good, and apologies for being pedantic, but given the recent
> > discussions, I thought I should clarify just in case others read it
> > differently.
> >
> > In the same vein, one more quick thing (that you probably didn't mean
> > in this way, but still, I think it is better I add the note, sorry): I
> > don't think it is true that it will not add workload to Andrew or MM
> > in general. It always adds some workload, even if the maintainers
> > don't handle the patches at all, since they may still need to perform
> > a small change in something Rust related due to another change they
> > need to do, or perhaps at least contact the Rust sub-maintainer to do
> > it for them, etc.
> >
> >     https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers
> >
> > Cheers,
> > Miguel
> 
> Ack, for the record I'm happy to help with any work that might come up.

Ack, here too.

Without the drama, I'm not sure how we'd feel so alive :P

Can I be added to whatever list so I can be Cc'ed on the changes on your
side?

Thanks,
Liam

Liam R. Howlett Feb. 13, 2025, 7:47 p.m. UTC | #9

* Alice Ryhl <[e-mail]> [250213 06:04]:
> This updates the vm_area_struct support to use the approach we discussed
> at LPC where there are several different Rust wrappers for
> vm_area_struct depending on the kind of access you have to the vma. Each
> case allows a different set of operations on the vma.
> 
> MM folks, what do you prefer I do for the MAINTAINERS file? Would you
> prefer that I add these files under MEMORY MANAGEMENT, or would you like
> a separate entry similar to the BLOCK LAYER DEVICE DRIVER API [RUST]
> entry? Or something else?
> 
> Signed-off-by: Alice Ryhl <[e-mail]>

Acked-by: Liam R. Howlett <[e-mail]>

Thanks for doing this.

> ---
> Changes in v14:
> - Rename VmArea* to Vma* as suggested by Liam.
> - Update a few comments in patch 02.
> - Link to v13: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v13:
> - Rebase on v6.14-rc1.
> - Remove casts that are now unnecessary due to improved Rust/C integer
>   type mappings.
> - Link to v12: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v12:
> - Add additional documentation to modules at the top of mm.rs and virt.rs.
> - Explain why the name Mm is used in commit message of patch 1.
> - Expand zap_page_range_single with docs suggested by Lorenzo.
> - Update safety comment in vm_insert_page
> - Mention that VmAreaMixedMap is identical to VmAreaRef except for VM_MIXEDMAP.
> - Update docs for as_mixedmap_vma.
> - Add additional docs for VmAreaNew struct.
> - Rename `get_read` -> `readable` and equivalent for write/exec.
> - Use mut pointers for `from_raw` for VMAs.
> - Update safety comment for fops_mmap.
> - Add additional docs for MiscDevice::mmap.
> - Don't introduce and immediately delete mmgrab_current.
> - Reduce active_pid_ns comment at Andreas's suggestion and link to get_pid_ns.
> - Fix documentation test in rust/kernel/task.rs.
> - Fix warning about unused variables in lock_vma_under_rcu when
>   CONFIG_PER_VMA_LOCK=n.
> - Fix minor typos.
> - Link to v11: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v11:
> - Add accessor for the vm_mm field of vm_area_struct.
> - Pass the file to MiscDevice::mmap for consistency with
>   https://lore.kernel.org/r/[e-mail]
> - Link to v10: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v10:
> - Update docs for `set_io`.
> - Check address in `zap_page_range_single`.
> - Completely redo the last patch.
> - Link to v9: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v9:
> - Be more explicit about VmAreaNew being used with f_ops->mmap().
> - Point out that clearing VM_MAYWRITE is irreversible.
> - Use __vm_flags to set the flags.
> - Use as_ and into_ prefixes for conversions.
> - Update lock_vma_under_rcu docs and commit msg
> - Mention that VmAreaRef::end is exclusive.
> - Reword docs for zap_page_range_single.
> - Minor fixes to flag docs.
> - Add way to access current->mm without a refcount increment.
> - Link to v8: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v8:
> - Split series into more commits to ease review.
> - Improve read locks based on Lorenzo's doc: either the mmap or vma lock
>   can be used.
> - Get rid of mmap write lock because it's possible to avoid the need for
>   it.
> - Do not allow invalid flag combinations on VmAreaNew.
> - Link to v7: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v7:
> - Make the mmap read/write lock guards respect strict owner semantics.
> - Link to v6: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v6:
> - Introduce VmArea{Ref,Mut,New} distinction.
> - Add a second patchset for miscdevice.
> - Rebase on char-misc-next (currently on v6.12-rc2).
> - Link to v5: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v5:
> - Rename VmArea::from_raw_vma to from_raw.
> - Use Pin for mutable VmArea references.
> - Go through `ARef::from` in `mmgrab_current`.
> - Link to v4: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v4:
> - Pull out ARef::into_raw into a separate patch.
> - Update invariants and struct documentation.
> - Rename from_raw_mm to from_raw.
> - Link to v3: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v3:
> - Reorder entries in mm.rs.
> - Use ARef for mmput_async helper.
> - Clarify that VmArea requires you to hold the mmap read or write lock.
> - Link to v2: https://lore.kernel.org/r/[e-mail]
> 
> Changes in v2:
> - mm.rs is redesigned from scratch making use of AsRef
> - Add notes about whether destructors may sleep
> - Rename Area to VmArea
> - Link to v1: https://lore.kernel.org/r/[e-mail]
> 
> ---
> Alice Ryhl (8):
>       mm: rust: add abstraction for struct mm_struct
>       mm: rust: add vm_area_struct methods that require read access
>       mm: rust: add vm_insert_page
>       mm: rust: add lock_vma_under_rcu
>       mm: rust: add mmput_async support
>       mm: rust: add VmaNew for f_ops->mmap()
>       rust: miscdevice: add mmap support
>       task: rust: rework how current is accessed
> 
>  rust/helpers/helpers.c    |   1 +
>  rust/helpers/mm.c         |  50 +++++
>  rust/kernel/lib.rs        |   1 +
>  rust/kernel/miscdevice.rs |  44 +++++
>  rust/kernel/mm.rs         | 341 +++++++++++++++++++++++++++++++++
>  rust/kernel/mm/virt.rs    | 471 ++++++++++++++++++++++++++++++++++++++++++++++
>  rust/kernel/task.rs       | 247 ++++++++++++------------
>  7 files changed, 1037 insertions(+), 118 deletions(-)
> ---
> base-commit: a64dcfb451e254085a7daee5fe51bf22959d52d3
> change-id: 20240723-vma-f80119f9fb35
> 
> Best regards,
> -- 
> Alice Ryhl <[e-mail]>
>

Miguel Ojeda Feb. 13, 2025, 7:52 p.m. UTC | #10

On Thu, Feb 13, 2025 at 1:16 PM Lorenzo Stoakes
<[e-mail]> wrote:
>
> Ack, for the record I'm happy to help with any work that might come up.

Thanks a lot Lorenzo and Liam! Very much appreciated.

Cheers,
Miguel

Alice Ryhl Feb. 14, 2025, 11:56 a.m. UTC | #11

On Thu, Feb 13, 2025 at 8:46 PM Liam R. Howlett <[e-mail]> wrote:
>
> * Lorenzo Stoakes <[e-mail]> [250213 07:16]:
> > On Thu, Feb 13, 2025 at 01:03:04PM +0100, Miguel Ojeda wrote:
> > > On Thu, Feb 13, 2025 at 12:50 PM Lorenzo Stoakes
> > > <[e-mail]> wrote:
> > > >
> > > > Right, I don't mean the rust subsystem, I mean designated rust
> > > > maintainers. The point being that this won't add workload to Andrew, nor
> > > > require him nor other mm C people to understand rust.
> > >
> > > Sounds good, and apologies for being pedantic, but given the recent
> > > discussions, I thought I should clarify just in case others read it
> > > differently.
> > >
> > > In the same vein, one more quick thing (that you probably didn't mean
> > > in this way, but still, I think it is better I add the note, sorry): I
> > > don't think it is true that it will not add workload to Andrew or MM
> > > in general. It always adds some workload, even if the maintainers
> > > don't handle the patches at all, since they may still need to perform
> > > a small change in something Rust related due to another change they
> > > need to do, or perhaps at least contact the Rust sub-maintainer to do
> > > it for them, etc.
> > >
> > >     https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers
> > >
> > > Cheers,
> > > Miguel
> >
> > Ack, for the record I'm happy to help with any work that might come up.
>
> Ack, here too.
>
> Without the drama, I'm not sure how we'd feel so alive :P
>
> Can I be added to whatever list so I can be Cc'ed on the changes on your
> side?

I'm happy to format the entries whichever way you all prefer, but for
example it could be a new MAINTAINERS entry below MEMORY MAPPING along
these lines:

MEMORY MANAGEMENT/MAPPING [RUST]
M: Alice Ryhl <[e-mail]>
R: Lorenzo Stoakes <[e-mail]>
R: Liam R. Howlett <[e-mail]>
L: [e-mail]
L: [e-mail]
S: Maintained
F: rust/helpers/mm.c
F: rust/kernel/mm.rs
F: rust/kernel/mm/

Alice

Lorenzo Stoakes Feb. 14, 2025, 12:20 p.m. UTC | #12

On Fri, Feb 14, 2025 at 12:56:29PM +0100, Alice Ryhl wrote:
> On Thu, Feb 13, 2025 at 8:46 PM Liam R. Howlett <[e-mail]> wrote:
> >
> > * Lorenzo Stoakes <[e-mail]> [250213 07:16]:
> > > On Thu, Feb 13, 2025 at 01:03:04PM +0100, Miguel Ojeda wrote:
> > > > On Thu, Feb 13, 2025 at 12:50 PM Lorenzo Stoakes
> > > > <[e-mail]> wrote:
> > > > >
> > > > > Right, I don't mean the rust subsystem, I mean designated rust
> > > > > maintainers. The point being that this won't add workload to Andrew, nor
> > > > > require him nor other mm C people to understand rust.
> > > >
> > > > Sounds good, and apologies for being pedantic, but given the recent
> > > > discussions, I thought I should clarify just in case others read it
> > > > differently.
> > > >
> > > > In the same vein, one more quick thing (that you probably didn't mean
> > > > in this way, but still, I think it is better I add the note, sorry): I
> > > > don't think it is true that it will not add workload to Andrew or MM
> > > > in general. It always adds some workload, even if the maintainers
> > > > don't handle the patches at all, since they may still need to perform
> > > > a small change in something Rust related due to another change they
> > > > need to do, or perhaps at least contact the Rust sub-maintainer to do
> > > > it for them, etc.
> > > >
> > > >     https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers
> > > >
> > > > Cheers,
> > > > Miguel
> > >
> > > Ack, for the record I'm happy to help with any work that might come up.
> >
> > Ack, here too.
> >
> > Without the drama, I'm not sure how we'd feel so alive :P
> >
> > Can I be added to whatever list so I can be Cc'ed on the changes on your
> > side?
>
> I'm happy to format the entries whichever way you all prefer, but for
> example it could be a new MAINTAINERS entry below MEMORY MAPPING along
> these lines:
>
> MEMORY MANAGEMENT/MAPPING [RUST]

I think a general:

MEMORY MANAGEMENT [RUST]

works better here as it ought to (at least for the time being) cover off all
rust mm stuff.

> M: Alice Ryhl <[e-mail]>

I wonder if we should have Andrew as a co-maintainer here so people also
send to Andrew also for merge? (and obviously as the mm maintainer he may
have commentary).

> R: Lorenzo Stoakes <[e-mail]>

Am happy to be a reviewer this is fine!

> R: Liam R. Howlett <[e-mail]>

I am sure Liam is also, but of course he can comment himself :)

> L: [e-mail]
> L: [e-mail]
> S: Maintained

Probably need these here too if Andrew is taking in his tree:

W:	http://www.linux-mm.org
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

> F: rust/helpers/mm.c
> F: rust/kernel/mm.rs
> F: rust/kernel/mm/
>
> Alice

But in general with tweaks I am happy for this to be added to MAINTAINERS
_personally_, am I but a minor figure however, it is up to Andrew
ultimately :)

Liam R. Howlett Feb. 14, 2025, 4:09 p.m. UTC | #13

* Lorenzo Stoakes <[e-mail]> [250214 07:20]:
> On Fri, Feb 14, 2025 at 12:56:29PM +0100, Alice Ryhl wrote:
> > On Thu, Feb 13, 2025 at 8:46 PM Liam R. Howlett <[e-mail]> wrote:
> > >
> > > * Lorenzo Stoakes <[e-mail]> [250213 07:16]:
> > > > On Thu, Feb 13, 2025 at 01:03:04PM +0100, Miguel Ojeda wrote:
> > > > > On Thu, Feb 13, 2025 at 12:50 PM Lorenzo Stoakes
> > > > > <[e-mail]> wrote:
> > > > > >
> > > > > > Right, I don't mean the rust subsystem, I mean designated rust
> > > > > > maintainers. The point being that this won't add workload to Andrew, nor
> > > > > > require him nor other mm C people to understand rust.
> > > > >
> > > > > Sounds good, and apologies for being pedantic, but given the recent
> > > > > discussions, I thought I should clarify just in case others read it
> > > > > differently.
> > > > >
> > > > > In the same vein, one more quick thing (that you probably didn't mean
> > > > > in this way, but still, I think it is better I add the note, sorry): I
> > > > > don't think it is true that it will not add workload to Andrew or MM
> > > > > in general. It always adds some workload, even if the maintainers
> > > > > don't handle the patches at all, since they may still need to perform
> > > > > a small change in something Rust related due to another change they
> > > > > need to do, or perhaps at least contact the Rust sub-maintainer to do
> > > > > it for them, etc.
> > > > >
> > > > >     https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers
> > > > >
> > > > > Cheers,
> > > > > Miguel
> > > >
> > > > Ack, for the record I'm happy to help with any work that might come up.
> > >
> > > Ack, here too.
> > >
> > > Without the drama, I'm not sure how we'd feel so alive :P
> > >
> > > Can I be added to whatever list so I can be Cc'ed on the changes on your
> > > side?
> >
> > I'm happy to format the entries whichever way you all prefer, but for
> > example it could be a new MAINTAINERS entry below MEMORY MAPPING along
> > these lines:
> >
> > MEMORY MANAGEMENT/MAPPING [RUST]
> 
> I think a general:
> 
> MEMORY MANAGEMENT [RUST]
> 
> works better here as it ought to (at least for the time being) cover off all
> rust mm stuff.
> 
> > M: Alice Ryhl <[e-mail]>
> 
> I wonder if we should have Andrew as a co-maintainer here so people also
> send to Andrew also for merge? (and obviously as the mm maintainer he may
> have commentary).

Indeed, FWIU each subsystem is doing something different with some
taking no responsibility/effort while others are involved.

The mm space has been a very good citizen in both methods (merging with
cover letters, code quality, etc) and in code (always on top of syzbot,
bugs).  I think it is important to strive to keep this functioning.

This will become more important once we have more than just wrappers,
but I think we should talk about what this will need to look like before
it actually happens.  ie: unstable rust branch tracking unstable c
branch with build emails, etc?  Early days yet, though.

> 
> > R: Lorenzo Stoakes <[e-mail]>
> 
> Am happy to be a reviewer this is fine!
> 
> > R: Liam R. Howlett <[e-mail]>
> 
> I am sure Liam is also, but of course he can comment himself :)

Yes, please add me here.

> 
> > L: [e-mail]
> > L: [e-mail]
> > S: Maintained
> 
> Probably need these here too if Andrew is taking in his tree:
> 
> W:	http://www.linux-mm.org
> T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

This is a good question.

I am unclear how the branching/merging happens.  When do we need to
start (at lest) building the rust side?  We've been doing a lot of work
in the modularization/interface level to try and integrate more isolated
testing, as well as the locking changes.

Do you have build bots that will tell us when things are broken?

...

Thanks,
Liam

Miguel Ojeda Feb. 14, 2025, 6:04 p.m. UTC | #14

On Fri, Feb 14, 2025 at 5:10 PM Liam R. Howlett <[e-mail]> wrote:
>
> This will become more important once we have more than just wrappers,
> but I think we should talk about what this will need to look like before
> it actually happens.  ie: unstable rust branch tracking unstable c
> branch with build emails, etc?  Early days yet, though.

Like an equivalent to the `mm-unstable` one? Would patches only be
promoted if they pass the Rust build etc.?

(Sorry, I don't mind to interfere -- just trying to understand how it
would work, since I may be able to use as an example later on for
other subsystems etc.)

> I am unclear how the branching/merging happens.  When do we need to
> start (at lest) building the rust side?  We've been doing a lot of work
> in the modularization/interface level to try and integrate more isolated
> testing, as well as the locking changes.
>
> Do you have build bots that will tell us when things are broken?

If you mean on the Rust side, I just wrote some context on another thread:

    https://lore.kernel.org/rust-for-linux/CANiq72=Yy8e=[e-mail]/

The important bit is:

    I regularly test different combinations (branches, configs, compiler
    versions, and so on) to catch mainly toolchain issues and so on, and
    keep things as clean as I can. Others use regularly the Rust support
    for their different use cases, thus more testing happens on different
    environments. In other words, things generally work just fine.

    However, our testing is not meant to catch every issue everywhere.
    Like for anything else in the kernel, whoever maintains a branch with
    a particular Rust feature needs to set up proper testing for that
    particular feature and relevant configs.

I hope that clarifies.

Moreover, there are some bots available that support Rust, e.g.
Intel's 0-day bot. I am happy to put you in contact with them to see
what they can do for your branches.

Cheers,
Miguel

Liam R. Howlett Feb. 14, 2025, 6:19 p.m. UTC | #15

* Miguel Ojeda <[e-mail]> [250214 13:05]:
> On Fri, Feb 14, 2025 at 5:10 PM Liam R. Howlett <[e-mail]> wrote:
> >
> > This will become more important once we have more than just wrappers,
> > but I think we should talk about what this will need to look like before
> > it actually happens.  ie: unstable rust branch tracking unstable c
> > branch with build emails, etc?  Early days yet, though.
> 
> Like an equivalent to the `mm-unstable` one? Would patches only be
> promoted if they pass the Rust build etc.?
> 
> (Sorry, I don't mind to interfere -- just trying to understand how it
> would work, since I may be able to use as an example later on for
> other subsystems etc.)

I don't know, but I would think if it means Linus won't take things then
we should do our best to know as soon as possible.

> 
> > I am unclear how the branching/merging happens.  When do we need to
> > start (at lest) building the rust side?  We've been doing a lot of work
> > in the modularization/interface level to try and integrate more isolated
> > testing, as well as the locking changes.
> >
> > Do you have build bots that will tell us when things are broken?
> 
> If you mean on the Rust side, I just wrote some context on another thread:
> 
>     https://lore.kernel.org/rust-for-linux/CANiq72=Yy8e=[e-mail]/
> 
> The important bit is:
> 
>     I regularly test different combinations (branches, configs, compiler
>     versions, and so on) to catch mainly toolchain issues and so on, and
>     keep things as clean as I can. Others use regularly the Rust support
>     for their different use cases, thus more testing happens on different
>     environments. In other words, things generally work just fine.
> 
>     However, our testing is not meant to catch every issue everywhere.
>     Like for anything else in the kernel, whoever maintains a branch with
>     a particular Rust feature needs to set up proper testing for that
>     particular feature and relevant configs.
> 
> I hope that clarifies.
> 
> Moreover, there are some bots available that support Rust, e.g.
> Intel's 0-day bot. I am happy to put you in contact with them to see
> what they can do for your branches.

Thanks.  I don't know how the majority of the mm people feel about this
stuff or what efforts we should make.

I don't want to hijack this patch set with my questions and I should do
more research on it.  I do think we need more discussions about it.

Thanks,
Liam