Netdev List
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: hkallweit1@gmail.com
Cc: davem@davemloft.net, andrew+netdev@lunn.ch, edumazet@google.com,
	kuba@kernel.org, horms@kernel.org, gregkh@linuxfoundation.org,
	rafael@kernel.org, dakr@kernel.org, johan@kernel.org,
	pabeni@redhat.com, netdev@vger.kernel.org,
	driver-core@lists.linux.dev
Subject: Re: [PATCH net-next 1/2] sysfs: facilitate creating an empty directory
Date: Mon, 09 Nov 2026 13:48:42 +0000	[thread overview]
Message-ID: <179423212274.994134.387871053470036049@kernel.org> (raw)
In-Reply-To: <340683d8-83f5-415b-b54c-b2916817f860@gmail.com>

Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 2

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] This patch silently reverses the semantics that commit
  a91845b9a872 ("sysfs: Skip empty folders creation") set up on purpose…
- [Low] The kernel-doc for struct attribute_group in
  include/linux/sysfs.h (lines 101-103) still says "@bin_attrs: ...…
- [Low] The comment and debug message on the rewritten check in
  internal_create_group() (fs/sysfs/group.c:144-147) are misleading.

--

sysfs: facilitate creating an empty directory

This patch changes the early return in internal_create_group() so that it
only skips groups with no name and no attrs or bin_attrs. A named group with
both arrays NULL now gets an empty sysfs directory. Callers no longer need an
attribute list that holds only the sentinel entry.

> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index 4e1e4f18a1669..031cb6f36b5b0 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -141,9 +141,10 @@ static int internal_create_group(struct kobject *kobj, int update,
>  	if (unlikely(update && !kobj->sd))
>  		return -EINVAL;
>  
> -	if (!grp->attrs && !grp->bin_attrs) {
> -		pr_debug("sysfs: (bin_)attrs not set by subsystem for group: %s/%s, skipping\n",
> -			 kobj->name, grp->name ?: "");
> +	/* If name is set w/o attributes, create an empty directory */
> +	if (!grp->name && !grp->attrs && !grp->bin_attrs) {

[Severity: Medium]
This reverses behaviour that commit a91845b9a872 ("sysfs: Skip empty
folders creation") added on purpose. Was that intended?

That commit's message covers a group "with a name and without .[bin_]attrs
members". It says sysfs should "just skip the attribute group creation". It
also calls an empty sysfs folder "disturbing".

After this change, a named group with attrs and bin_attrs both NULL always
gets a directory. That applies to sysfs_create_group(), sysfs_create_groups()
and device_add_group(). It also applies to sysfs_update_group() when the
directory doesn't exist yet.

__first_visible() returns 0 when both arrays are NULL. So mode becomes
S_IRWXU | S_IRUGO | S_IXUGO and the code reaches:

    kn = kernfs_create_dir_ns(kobj->sd, grp->name, mode,
                              uid, gid, kobj, NULL);
    if (IS_ERR(kn)) {
        if (PTR_ERR(kn) == -EEXIST)
            sysfs_warn_dup(kobj->sd, grp->name);
        return PTR_ERR(kn);
    }

A name clash used to return 0 quietly. It now returns -EEXIST and calls
sysfs_warn_dup(), and internal_create_groups() then rolls back the whole
group list.

Some named groups are declared with NULL attrs and filled in at run time.
One example is x86_pmu_format_group in arch/x86/events/core.c:

    static struct attribute_group x86_pmu_format_group __ro_after_init = {
        .name = "format",
        .attrs = NULL,
    };

I couldn't find an in-tree user that registers such a group with the arrays
still NULL. The x86 pmu, s390 PAI, amdgpu, i915, arm-cci and
nvmem_populate_sysfs_cells() users all fill the arrays or bail out first.
Even so, the commit message describes this only as changing one check.

Could the commit message reference a91845b9a872 and explain why skipping
empty named groups is no longer wanted? Could it also say whether existing
named groups with runtime-filled attrs were checked?

[Severity: Low]
A named group with both arrays NULL is now a supported construct. However,
the kernel-doc for struct attribute_group in include/linux/sysfs.h still
says:

 * @attrs:	Pointer to NULL terminated list of attributes.
 * @bin_attrs:	Pointer to NULL terminated list of binary attributes.
 *		Either attrs or bin_attrs or both must be provided.

Should this be updated too? It could say that a named group with neither
array creates an empty directory, and only an unnamed one is skipped.

The follow-up change for wireless_group in net/core/net-sysfs.c depends on
this, and it doesn't touch the header either.

> +		pr_debug("sysfs: (bin_)attrs not set by subsystem for group: %s, skipping\n",
> +			 kobj->name);

[Severity: Low]
This isn't a bug, but the new comment describes what happens when the
condition is false. The block below it actually skips an unnamed group that
has no attributes.

The pr_debug() also prints kobj->name after "for group:". grp->name is
always NULL in this branch, so the printed value is the kobject name, not a
group name. The old "%s/%s" format kept the two separate.

There is also a typo in the commit message: "sentinal" should be "sentinel".

>  		return 0;
>  	}
>

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/0a0a7987-abb2-49c8-bc16-3938233ae9c5%40gmail.com

  parent reply	other threads:[~2026-11-09 13:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08 13:44 [PATCH net-next 0/2] sysfs: facilitate creating an empty directory Heiner Kallweit
2026-11-08 13:45 ` [PATCH net-next 1/2] " Heiner Kallweit
2026-11-08 14:06   ` Greg Kroah-Hartman
2026-11-09 13:48   ` netdev-bot+sashiko [this message]
2026-11-08 13:46 ` [PATCH net-next 2/2] net sysfs: simplify creating empty wireless directory Heiner Kallweit
2026-11-08 14:06   ` Greg Kroah-Hartman
2026-11-08 14:12     ` Heiner Kallweit
2026-11-08 14:21       ` Greg Kroah-Hartman
2026-11-08 16:02         ` Heiner Kallweit
2026-11-09 13:48   ` netdev-bot+sashiko
2026-11-08 16:12 ` [PATCH net-next 0/2] sysfs: facilitate creating an empty directory Heiner Kallweit

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=179423212274.994134.387871053470036049@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=dakr@kernel.org \
    --cc=davem@davemloft.net \
    --cc=driver-core@lists.linux.dev \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=johan@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rafael@kernel.org \
    /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