From: Lorenzo Pieralisi <lpieralisi@kernel.org>
Sent: Wednesday, May 10, 2023 1:23 AM
To: Dexuan Cui <decui@microsoft.com>
...
On Wed, Apr 19, 2023 at 07:40:37PM -0700, Dexuan Cui wrote:

quoted

Commit 414428c5da1c ("PCI: hv: Lock PCI bus on device eject") added
pci_lock_rescan_remove() and pci_unlock_rescan_remove() in
create_root_hv_pci_bus() and in hv_eject_device_work() to address the
race between create_root_hv_pci_bus() and hv_eject_device_work(), but it
turns that grabing the pci_rescan_remove_lock mutex is not enough:
refer to the earlier fix "PCI: hv: Add a per-bus mutex state_lock".

This is meaningless for a commit log reader, there is nothing to
refer to.

Correct. Because patch 5
[PATCH v3 5/6] PCI: hv: Add a per-bus mutex state_lock
has not been in any upstream tree, so I don't have a commit id yet.
 

quoted

Now with hbus->state_lock and other fixes, the race is resolved, so

"other fixes" is meaningless too.

Ditto. 
 

Explain the problem and how you fix it (this patch should be split
because the Subject does not represent what you are doing precisely,
see below).

Ok, I will better explain the boot time issue.

quoted

remove pci_{lock,unlock}_rescan_remove() in create_root_hv_pci_bus():
this removes the serialization in hv_pci_probe() and hence allows
async-probing (PROBE_PREFER_ASYNCHRONOUS) to work.

Add the async-probing flag to hv_pci_drv.

Adding the asynchronous probing should be a separate patch and
I don't think you should send it to stable kernels straight away
because a) it is not a fix b) it can trigger further regressions.

Agreed. I'll remove the line "Cc: stable".

quoted

pci_{lock,unlock}_rescan_remove() in hv_eject_device_work() and in
hv_pci_remove() are still kept: according to the comment before
drivers/pci/probe.c: static DEFINE_MUTEX(pci_rescan_remove_lock),
"PCI device removal routines should always be executed under this mutex".

This patch should be split, first thing is to fix and document what
you are changing for pci_{lock,unlock}_rescan_remove() then add
asynchronous probing.

Lorenzo

Ok, I'll split this patch into two.

Thanks for reviewing the patch. 
Can you please give an "Acked-by" or "Reviewed-by" to patch 1~5 
if they look good to you? The first 5 patches have been there for a
while, and they already got Michael's Reviewed-by. 

I hope the first 5 patches can go through the hyperv-fixes branch in
the hyperv tree
https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/log/?h=hyperv-fixes
since they are specific to Hyper-V.

After the first 5 patches are in, I can refer to the commit IDs, and I
will split this patch (patch 6).

Thanks,
Dexuan