linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ethan Zhao <haifeng.zhao@linux.intel.com>
To: Hongchen Zhang <zhanghongchen@loongson.cn>,
	Markus Elfring <Markus.Elfring@web.de>,
	Bjorn Helgaas <bhelgaas@google.com>
Cc: Alex Belits <abelits@marvell.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Nitesh Narayan Lal <nitesh@redhat.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	loongarch@lists.linux.dev, stable@vger.kernel.org,
	Huacai Chen <chenhuacai@loongson.cn>
Subject: Re: [PATCH v3] PCI: pci_call_probe: call local_pci_probe() when selected cpu is offline
Date: Wed, 24 Jul 2024 14:40:57 +0800	[thread overview]
Message-ID: <db628499-6faf-43c8-93e5-c24208ca0578@linux.intel.com> (raw)
In-Reply-To: <0052b62b-aafe-e2eb-6d66-4ad0178bdae1@loongson.cn>

On 7/24/2024 11:09 AM, Hongchen Zhang wrote:
> Hi Ethan,
>
> On 2024/7/24 上午10:47, Ethan Zhao wrote:
>> On 7/24/2024 9:58 AM, Hongchen Zhang wrote:
>>> Hi Ethan,
>>> On 2024/7/22 PM 3:39, Ethan Zhao wrote:
>>>>
>>>> On 6/13/2024 3:42 PM, Hongchen Zhang wrote:
>>>>> Call work_on_cpu(cpu, fn, arg) in pci_call_probe() while the argument
>>>>> @cpu is a offline cpu would cause system stuck forever.
>>>>>
>>>>> This can be happen if a node is online while all its CPUs are
>>>>> offline (We can use "maxcpus=1" without "nr_cpus=1" to reproduce it).
>>>>>
>>>>> So, in the above case, let pci_call_probe() call local_pci_probe()
>>>>> instead of work_on_cpu() when the best selected cpu is offline.
>>>>>
>>>>> Fixes: 69a18b18699b ("PCI: Restrict probe functions to 
>>>>> housekeeping CPUs")
>>>>> Cc: <stable@vger.kernel.org>
>>>>> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
>>>>> Signed-off-by: Hongchen Zhang <zhanghongchen@loongson.cn>
>>>>> ---
>>>>> v2 -> v3: Modify commit message according to Markus's suggestion
>>>>> v1 -> v2: Add a method to reproduce the problem
>>>>> ---
>>>>>   drivers/pci/pci-driver.c | 2 +-
>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>>>>> index af2996d0d17f..32a99828e6a3 100644
>>>>> --- a/drivers/pci/pci-driver.c
>>>>> +++ b/drivers/pci/pci-driver.c
>>>>> @@ -386,7 +386,7 @@ static int pci_call_probe(struct pci_driver 
>>>>> *drv, struct pci_dev *dev,
>>>>>           free_cpumask_var(wq_domain_mask);
>>>>>       }
>>>>> -    if (cpu < nr_cpu_ids)
>>>>
>>>> Why not choose the right cpu to callwork_on_cpu() ? the one that is 
>>>> online. Thanks, Ethan
>>> Yes, let housekeeping_cpumask() return online cpu is a good idea, 
>>> but it may be changed by command line. so the simplest way is to 
>>> call local_pci_probe when the best selected cpu is offline.
>>
>> Hmm..... housekeeping_cpumask() should never return offline CPU, so
>> I guess you didn't hit issue with the CPU isolation, but the following
>> code seems not good.
> The issue is the dev node is online but the best selected cpu is 
> offline, so it seems that there is no better way to directly set the 
> cpu to nr_cpu_ids.

I mean where the bug is ? you should debug more about that.
just add one cpu_online(cpu) check there might suggest there
is bug in the cpu selection stage.


if (node < 0 || node >= MAX_NUMNODES || !node_online(node) ||
	    pci_physfn_is_probed(dev)) {
		cpu = nr_cpu_ids; // <----- if you hit here, then local_pci_probe() should be called.
             
	} else {
		cpumask_var_t wq_domain_mask;

		if (!zalloc_cpumask_var(&wq_domain_mask, GFP_KERNEL)) {
			error = -ENOMEM;
			goto out;
		}
		cpumask_and(wq_domain_mask,
			    housekeeping_cpumask(HK_TYPE_WQ),
			    housekeeping_cpumask(HK_TYPE_DOMAIN));

		cpu = cpumask_any_and(cpumask_of_node(node),
				      wq_domain_mask);
		free_cpumask_var(wq_domain_mask);
                 // <----- if you hit here, then work_on_cpu(cpu, local_pci_probe, &ddi) should be called.
                 // do you mean there one offline cpu is selected ?

	}

	if (cpu < nr_cpu_ids)
		error = work_on_cpu(cpu, local_pci_probe, &ddi);
	else
		error = local_pci_probe(&ddi);


Thanks,
Ethan

>>
>> ...
>>
>> if (node < 0 || node >= MAX_NUMNODES || !node_online(node) ||
>>          pci_physfn_is_probed(dev)) {
>>          cpu = nr_cpu_ids;
>>      } else {
>>
>> ....
>>
>> perhaps you could change the logic there and fix it  ?
>>
>> Thanks
>> Ethan
>>
>>
>>
>>>>
>>>>> +    if ((cpu < nr_cpu_ids) && cpu_online(cpu))
>>>>>           error = work_on_cpu(cpu, local_pci_probe, &ddi);
>>>>>       else
>>>>>           error = local_pci_probe(&ddi);
>>>
>>>
>
>

  reply	other threads:[~2024-07-24  6:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13  7:42 [PATCH v3] PCI: pci_call_probe: call local_pci_probe() when selected cpu is offline Hongchen Zhang
2024-07-22  2:11 ` Huacai Chen
2024-07-22  7:39 ` Ethan Zhao
2024-07-24  1:58   ` Hongchen Zhang
2024-07-24  2:47     ` Ethan Zhao
2024-07-24  3:09       ` Hongchen Zhang
2024-07-24  6:40         ` Ethan Zhao [this message]
2024-07-24  7:05           ` Hongchen Zhang
2024-09-13  8:06             ` Huacai Chen

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=db628499-6faf-43c8-93e5-c24208ca0578@linux.intel.com \
    --to=haifeng.zhao@linux.intel.com \
    --cc=Markus.Elfring@web.de \
    --cc=abelits@marvell.com \
    --cc=bhelgaas@google.com \
    --cc=chenhuacai@loongson.cn \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=nitesh@redhat.com \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=zhanghongchen@loongson.cn \
    /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;
as well as URLs for NNTP newsgroup(s).