Linux Serial subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mohamed Osama" <mohamed.osama189110@gmail.com>
Cc: gary@garyguo.net, ojeda@kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH v2 2/5] rust: mem: add DropGuard
Date: Sat, 26 Sep 2026 16:46:53 +0000	[thread overview]
Message-ID: <20260926164654.43A501F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260926163551.52371-3-mohamed.osama189110@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] rust: DropGuard duplicates ScopeGuard without justification
- [Low] rust: vertical import style violation in mem.rs
--

commit 5eee6691ffc9502aec33891dcbc8c9eb698eb03a
Author: Mohamed Osama <mohamed.osama189110@gmail.com>

rust: mem: add DropGuard

This commit introduces DropGuard to the Rust kernel memory module to run a
cleanup callback upon dropping. It provides a scope guard API that includes
a dismiss method to take ownership without running the cleanup.

> diff --git a/rust/kernel/mem.rs b/rust/kernel/mem.rs
> index f2d4cdf87d00b..17807c8e67ac0 100644
> --- a/rust/kernel/mem.rs
> +++ b/rust/kernel/mem.rs
> @@ -4,6 +4,95 @@
>  
>  use crate::prelude::*;
>  
> +use core::{
> +    mem::ManuallyDrop,
> +    ops::{Deref, DerefMut},
> +};

[Severity: Low]
Is this a regression in code style? The Rust subsystem guide requires one
import per line without nested braces for non-vendored crates, but nested
groups are used here for the core module imports.

> +
> +/// Wraps a value and runs a closure when dropped.
> +///
> +/// This is useful for running cleanup code when leaving a scope.
> +///
> +/// The [`DropGuard::dismiss`] function can be used to take ownership of the wrapped
> +/// value without running the cleanup function.
> +#[doc(alias = "ScopeGuard")]
> +#[doc(alias = "defer")]
> +pub struct DropGuard<T, F>
> +where
> +    F: FnOnce(T),

[Severity: Medium]
Does this introduce an API regression by duplicating the functionality of the
existing kernel::types::ScopeGuard? Both handle scope guarding via closures
and provide a dismiss method.

The commit message mentions an upstream Rust DropGuard interface, but this
does not seem to exist in standard Rust. If the intention is to avoid Option
overhead in ScopeGuard by using ManuallyDrop, could the existing ScopeGuard
be refactored instead to prevent unnecessary code duplication and API
fragmentation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926163551.52371-1-mohamed.osama189110@gmail.com?part=2

  reply	other threads:[~2026-09-26 16:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-26 16:35 [PATCH v2 0/5] rust: add DropGuard Mohamed Osama
2026-09-26 16:35 ` [PATCH v2 1/5] rust: add DropGuard KUnit test configuration Mohamed Osama
2026-09-26 16:41   ` sashiko-bot
2026-09-26 16:35 ` [PATCH v2 2/5] rust: mem: add DropGuard Mohamed Osama
2026-09-26 16:46   ` sashiko-bot [this message]
2026-09-26 16:35 ` [PATCH v2 3/5] rust: block: gen_disk: use DropGuard Mohamed Osama
2026-09-26 16:42   ` sashiko-bot
2026-09-26 16:35 ` [PATCH v2 4/5] rust: serdev: " Mohamed Osama
2026-09-26 16:41   ` sashiko-bot
2026-09-26 16:35 ` [PATCH v2 5/5] rust: sync: lock: " Mohamed Osama
2026-09-26 16:41   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260926164654.43A501F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=gary@garyguo.net \
    --cc=linux-serial@vger.kernel.org \
    --cc=mohamed.osama189110@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox