BPF List
 help / color / mirror / Atom feed
From: Shung-Hsi Yu <shung-hsi.yu@suse.com>
To: Vinicius Sampaio <vldsampaio@pm.me>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
	 john.fastabend@gmail.com, andrii@kernel.org,
	martin.lau@linux.dev, eddyz87@gmail.com,  song@kernel.org,
	yonghong.song@linux.dev, kpsingh@kernel.org, sdf@fomichev.me,
	 haoluo@google.com, jolsa@kernel.org, tangyazhou518@outlook.com,
	 shenghaoyuan0928@163.com
Subject: Re: [PATCH bpf-next 2/2] bpf: Avoid redundant min()/max() in cnum signed bounds
Date: Wed, 29 Jul 2026 15:59:02 +0800	[thread overview]
Message-ID: <ammvMH-I4088A3AX@u94a> (raw)
In-Reply-To: <20260728015601.1567098-3-vldsampaio@pm.me>

On Tue, Jul 28, 2026 at 01:57:18AM +0000, Vinicius Sampaio wrote:
> This patch simplifies the smin() and smax() calculation by removing the
> integer min and max calculation on the non-overflowing branch. This is a
> valid simplification because when the arc does not cross the signed
> ST_MAX/ST_MIN boundary, the signed order of the endpoints is preserved,
> so base is the signed minimum and base + size is the signed maximum.
> Therefore, the min()/max() calls are redundant.
[...]
> --- a/kernel/bpf/cnum_defs.h
> +++ b/kernel/bpf/cnum_defs.h
> @@ -44,6 +44,9 @@ static inline bool FN(urange_overflow)(struct cnum_t cnum)
>   * cnum{T}_umin / cnum{T}_umax query an unsigned range represented by this cnum.
>   * If cnum represents a range crossing the UT_MAX/0 boundary, the unbound range
>   * [0..UT_MAX] is returned.
> + *
> + * The empty cnum doesn't produce any meaningful value, so you should avoid
> + * calling cnum{T}_umin / cnum{T}_umax with it.
>   */
>  ut FN(umin)(struct cnum_t cnum)
>  {
> @@ -67,19 +70,18 @@ static inline bool FN(srange_overflow)(struct cnum_t cnum)
>   * cnum{T}_smin / cnum{T}_smax query a signed range represented by this cnum.
>   * If cnum represents a range crossing the ST_MAX/ST_MIN boundary, the unbound range
>   * [ST_MIN..ST_MAX] is returned.
> + *
> + * The empty cnum doesn't produce any meaningful value, so you should avoid
> + * calling cnum{T}_smin / cnum{T}_smax with it.

Nit: if we are adding these it would perhaps be helpful to add similar
comment to {u,s}range_overflow as well. AFAICT
{u,s}{min,max,range_overflow} should be the only cnum function that is
not expected to take on an empty cnum.

Thought I'd prefer something along the lines of

  caller should ensure !is_empty(cnum) holds when calling

>   */
>  st FN(smin)(struct cnum_t cnum)
>  {
> -	return FN(srange_overflow)(cnum)
> -	       ? ST_MIN
> -	       : min((st)cnum.base, (st)(cnum.base + cnum.size));
> +	return FN(srange_overflow)(cnum) ? ST_MIN : (st)cnum.base;
>  }
>  
>  st FN(smax)(struct cnum_t cnum)
>  {
> -	return FN(srange_overflow)(cnum)
> -	       ? ST_MAX
> -	       : max((st)cnum.base, (st)(cnum.base + cnum.size));
> +	return FN(srange_overflow)(cnum) ? ST_MAX : (st)(cnum.base + cnum.size);
>  }

Acked-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>

  reply	other threads:[~2026-07-29  7:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  1:56 [PATCH bpf-next 0/2] Simplify min()/max(), contains() and fix normalize() cnum implementation Vinicius Sampaio
2026-07-28  1:56 ` [PATCH bpf-next 1/2] bpf: Simplify cnum contains() and normalize() implementation Vinicius Sampaio
2026-07-29  6:29   ` Shung-Hsi Yu
2026-07-29 19:15     ` Vinicius Sampaio
2026-07-28  1:57 ` [PATCH bpf-next 2/2] bpf: Avoid redundant min()/max() in cnum signed bounds Vinicius Sampaio
2026-07-29  7:59   ` Shung-Hsi Yu [this message]
2026-07-29 19:21     ` 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=ammvMH-I4088A3AX@u94a \
    --to=shung-hsi.yu@suse.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@fomichev.me \
    --cc=shenghaoyuan0928@163.com \
    --cc=song@kernel.org \
    --cc=tangyazhou518@outlook.com \
    --cc=vldsampaio@pm.me \
    --cc=yonghong.song@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