All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: wei.fang@oss.nxp.com
Cc: Frank.Li@kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH v4 net-next 6/9] net: enetc: add helpers to set/clear table bitmap
Date: Wed, 10 Jun 2026 03:27:58 +0000	[thread overview]
Message-ID: <20260610032758.DDA0C1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260609032955.2066089-7-wei.fang@oss.nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The custom ID allocation helpers deceptively use atomic bit operations and needlessly reinvent the kernel's IDA framework.
--

commit f37b0be8d3c2fcb9018ffa7dc02a01123fbb4e22
Author: Wei Fang <wei.fang@nxp.com>

net: enetc: add helpers to set/clear table bitmap

This commit introduces ntmp_lookup_free_eid() and ntmp_clear_eid_bitmap()
to help allocate and manage entry IDs for NTMP index tables. It uses standard
bitmap operations to track which IDs are free and which are in use.

> diff --git a/drivers/net/ethernet/freescale/enetc/ntmp.c b/drivers/net/ethernet/freescale/enetc/ntmp.c
> index 601435966ed1a..9f38f885ebb52 100644
> --- a/drivers/net/ethernet/freescale/enetc/ntmp.c
> +++ b/drivers/net/ethernet/freescale/enetc/ntmp.c
> @@ -47,6 +47,30 @@
>  #define RSST_STSE_DATA_SIZE(n)		((n) * 8)
>  #define RSST_CFGE_DATA_SIZE(n)		(n)
>  
> +u32 ntmp_lookup_free_eid(unsigned long *bitmap, u32 size)
> +{
> +	u32 entry_id;
> +
> +	entry_id = find_first_zero_bit(bitmap, size);
> +	if (entry_id == size)
> +		return NTMP_NULL_ENTRY_ID;
> +
> +	/* Set the bit once we found it */
> +	set_bit(entry_id, bitmap);

[Severity: Low]
Does this mix of non-atomic find_first_zero_bit() followed by an atomic
set_bit() present a misleading concurrency guarantee in ntmp_lookup_free_eid()?

If this allocation happens under an external lock, would it be more efficient
to use the non-atomic __set_bit() here?

Since this implements dynamic integer ID allocation, would the standard kernel
IDA framework (ida_alloc() and ida_free()) be a better fit than managing
custom raw bitmaps?

> +
> +	return entry_id;
> +}
> +EXPORT_SYMBOL_GPL(ntmp_lookup_free_eid);
> +
> +void ntmp_clear_eid_bitmap(unsigned long *bitmap, u32 entry_id)
> +{
> +	if (entry_id == NTMP_NULL_ENTRY_ID)
> +		return;
> +
> +	clear_bit(entry_id, bitmap);

[Severity: Low]
If external locking is guaranteed for these ID management functions, should
ntmp_clear_eid_bitmap() use the non-atomic __clear_bit() instead of clear_bit()?

> +}
> +EXPORT_SYMBOL_GPL(ntmp_clear_eid_bitmap);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609032955.2066089-1-wei.fang@oss.nxp.com?part=6

  reply	other threads:[~2026-06-10  3:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09  3:29 [PATCH v4 net-next 0/9] net: dsa: netc: add bridge mode support wei.fang
2026-06-09  3:29 ` [PATCH v4 net-next 1/9] net: enetc: add interfaces to manage dynamic FDB entries wei.fang
2026-06-09  3:29 ` [PATCH v4 net-next 2/9] net: enetc: add "Update" and "Delete" operations to VLAN filter table wei.fang
2026-06-09  3:29 ` [PATCH v4 net-next 3/9] net: enetc: add interfaces to manage egress treatment table wei.fang
2026-06-09  3:29 ` [PATCH v4 net-next 4/9] net: enetc: add "Update" operation to the egress count table wei.fang
2026-06-09  3:29 ` [PATCH v4 net-next 5/9] net: dsa: netc: initialize the group bitmap of ETT and ECT wei.fang
2026-06-10  3:27   ` sashiko-bot
2026-06-10 10:13     ` Wei Fang (OSS)
2026-06-09  3:29 ` [PATCH v4 net-next 6/9] net: enetc: add helpers to set/clear table bitmap wei.fang
2026-06-10  3:27   ` sashiko-bot [this message]
2026-06-09  3:29 ` [PATCH v4 net-next 7/9] net: dsa: netc: add VLAN filter table and egress treatment management wei.fang
2026-06-10  3:27   ` sashiko-bot
2026-06-10 10:16     ` Wei Fang (OSS)
2026-06-09  3:29 ` [PATCH v4 net-next 8/9] net: dsa: netc: add bridge mode support wei.fang
2026-06-10  3:28   ` sashiko-bot
2026-06-10 10:30     ` Wei Fang (OSS)
2026-06-09  3:29 ` [PATCH v4 net-next 9/9] net: dsa: netc: implement dynamic FDB entry ageing wei.fang

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=20260610032758.DDA0C1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wei.fang@oss.nxp.com \
    /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.