On 2019/10/12 15:40, Greg KH wrote: > On Sat, Oct 12, 2019 at 02:17:26PM +0800, Yunsheng Lin wrote: >> add pci and acpi maintainer >> cc linux-pci@xxxxxxxxxxxxxxx and linux-acpi@xxxxxxxxxxxxxxx >> >> On 2019/10/11 19:15, Peter Zijlstra wrote: >>> On Fri, Oct 11, 2019 at 11:27:54AM +0800, Yunsheng Lin wrote: >>>> But I failed to see why the above is related to making node_to_cpumask_map() >>>> NUMA_NO_NODE aware? >>> >>> Your initial bug is for hns3, which is a PCI device, which really _MUST_ >>> have a node assigned. >>> >>> It not having one, is a straight up bug. We must not silently accept >>> NO_NODE there, ever. >>> >> >> I suppose you mean reporting a lack of affinity when the node of a pcie >> device is not set by "not silently accept NO_NODE". > > If the firmware of a pci device does not provide the node information, > then yes, warn about that. > >> As Greg has asked about in [1]: >> what is a user to do when the user sees the kernel reporting that? >> >> We may tell user to contact their vendor for info or updates about >> that when they do not know about their system well enough, but their >> vendor may get away with this by quoting ACPI spec as the spec >> considering this optional. Should the user believe this is indeed a >> fw bug or a misreport from the kernel? > > Say it is a firmware bug, if it is a firmware bug, that's simple. > >> If this kind of reporting is common pratice and will not cause any >> misunderstanding, then maybe we can report that. > > Yes, please do so, that's the only way those boxes are ever going to get > fixed. And go add the test to the "firmware testing" tool that is based > on Linux that Intel has somewhere, to give vendors a chance to fix this > before they ship hardware. > > This shouldn't be a big deal, we warn of other hardware bugs all the > time. Ok, thanks for clarifying. Will send a patch to catch the case when a pcie device without numa node being set and warn about it. Maybe use dev->bus to verify if it is a pci device? > > thanks, > > greg k-h > > . >
