All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vinicius Sampaio" <vldsampaio@pm.me>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 3/3] bpf: Avoid redundant min()/max() in cnum signed bounds
Date: Wed, 29 Jul 2026 20:01:08 +0000	[thread overview]
Message-ID: <20260729200108.BA70A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729194932.292368-4-vldsampaio@pm.me>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces multi-line comments that violate the mandatory BPF subsystem comment style (the opening `/*` must be on its own line).
--

--- Patch [3]: [PATCH bpf-next v2 3/3] bpf: Avoid redundant min()/max() in cnum signed bounds ---
commit 7bdc1e04cfe4ef63975bb42ed60ef85f4dddcb77
Author: Vinicius Sampaio <vldsampaio@pm.me>

bpf: Avoid redundant min()/max() in cnum signed bounds

This commit simplifies the smin() and smax() calculations by removing
redundant min and max operations on the non-overflowing branch. It relies on
the fact that when the range does not cross the ST_MAX/ST_MIN boundary, the
base and base + size represent the signed minimum and maximum directly.

> diff --git a/kernel/bpf/cnum_defs.h b/kernel/bpf/cnum_defs.h
> index 09535edbbafc9..95452eefe44a5 100644
> --- a/kernel/bpf/cnum_defs.h
> +++ b/kernel/bpf/cnum_defs.h
> @@ -33,7 +33,11 @@ struct cnum_t FN(from_srange)(st min, st max)
>  	return (struct cnum_t){ .base = base, .size = size };
>  }
>  
> -/* True if this cnum represents two unsigned ranges. */
> +/* True if this cnum represents two unsigned ranges.
> + *
> + * The caller should ensure !is_empty(cnum) holds when calling
> + * this function.
> + */

[Severity: Low]
This isn't a bug, but should the opening '/*' be on its own line to align
with the preferred BPF subsystem multi-line comment style?

[ ... ]

> @@ -57,7 +64,11 @@ ut FN(umax)(struct cnum_t cnum)
>  }
>  EXPORT_SYMBOL_GPL(FN(umax));
>  
> -/* True if this cnum represents two signed ranges. */
> +/* True if this cnum represents two signed ranges.
> + *
> + * The caller should ensure !is_empty(cnum) holds when calling
> + * this function.
> + */

[Severity: Low]
This isn't a bug, but similar to the comment above, would it be better
to place the opening '/*' on its own line here as well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729194932.292368-1-vldsampaio@pm.me?part=3

  reply	other threads:[~2026-07-29 20:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 19:49 [PATCH bpf-next v2 0/3] Simplify min()/max(), contains() and normalize() cnum implementation Vinicius Sampaio
2026-07-29 19:50 ` [PATCH bpf-next v2 1/3] bpf: Simplify cnum contains() implementation Vinicius Sampaio
2026-07-29 20:40   ` bot+bpf-ci
2026-07-29 23:46     ` Vinicius Sampaio
2026-07-29 19:50 ` [PATCH bpf-next v2 2/3] bpf: Simplify cnum normalize() implementation Vinicius Sampaio
2026-07-29 20:57   ` bot+bpf-ci
2026-07-29 23:56     ` Vinicius Sampaio
2026-07-29 19:50 ` [PATCH bpf-next v2 3/3] bpf: Avoid redundant min()/max() in cnum signed bounds Vinicius Sampaio
2026-07-29 20:01   ` sashiko-bot [this message]
2026-07-29 23:58     ` Vinicius Sampaio

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=20260729200108.BA70A1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vldsampaio@pm.me \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.