public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: "Li,Rongqing(ACG CCN)" <lirongqing@baidu.com>
To: "Krzysztof Wilczy��ski" <kw@linux.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: 答复: [????] Re: [PATCH] PCI: sysfs: Suppress FW_BUG warning when NUMA node already matches
Date: Mon, 16 Mar 2026 02:20:03 +0000	[thread overview]
Message-ID: <d1dd98ddd0a948e9b785844479712162@baidu.com> (raw)
In-Reply-To: <20260314205407.GB672783@rocinante>


> 
> Hello,
> 
> > The numa_node sysfs interface allows users to manually override a PCI
> > device's NUMA node assignment. Currently, every write triggers a
> > FW_BUG warning and taints the kernel, even when writing the same value
> > that is already set.
> 
> So, this works as intended, then?
> 

I don't know if this is intended, but it feels unreasonable―writing the same value still triggers a FW_BUG warning.

> What makes multiple writes to this sysfs attribute, if you don't mind me
> asking?  Do you have some tool that does this?  Some automation?
> 

I have a tool that triggered this warning, and I will fix my tool.

> Especially, that you seem to be writing the same value over and over.
> 
Not , but a user is allowed to write to this file,  and subsequently will generate a massive amount of kernel logs―is this considered unreasonable? Should we add some rate limit?


> >  	if (node != NUMA_NO_NODE && !node_online(node))
> >  		return -EINVAL;
> >
> > -	add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
> > -	pci_alert(pdev, FW_BUG "Overriding NUMA node to %d.  Contact your
> vendor for updates.",
> > -		  node);
> > +	if (node != dev->numa_node) {
> > +		add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
> > +		pci_alert(pdev, FW_BUG "Overriding NUMA node to %d.  Contact
> your vendor for updates.",
> > +			  node);
> > +		dev->numa_node = node;
> > +	}
> 
> You could invert the check and make it an early return where you just return
> count.  Would save on the new indent level.
> 

Good idle, I will fix this in v2

Thanks

[Li,Rongqing] 

> Thank you!
> 
> 	Krzysztof

  reply	other threads:[~2026-03-16  2:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13  5:08 [PATCH] PCI: sysfs: Suppress FW_BUG warning when NUMA node already matches lirongqing
2026-03-14 20:54 ` Krzysztof Wilczyński
2026-03-16  2:20   ` Li,Rongqing(ACG CCN) [this message]
2026-03-16  3:12     ` 答复: [????] " Krzysztof Wilczy��ski

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=d1dd98ddd0a948e9b785844479712162@baidu.com \
    --to=lirongqing@baidu.com \
    --cc=bhelgaas@google.com \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.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