There's no point in comparing SBDF - we can simply compare the struct
pci_dev pointers. If they weren't the same for a given device, we'd have
bigger problems from having stored a stale pointer.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/xen-pciback/vpci.c
+++ b/drivers/xen/xen-pciback/vpci.c
@@ -235,7 +235,6 @@ static int __xen_pcibk_get_pcifront_dev(
 					unsigned int *devfn)
 {
 	struct pci_dev_entry *entry;
-	struct pci_dev *dev = NULL;
 	struct vpci_dev_data *vpci_dev = pdev->pci_dev_data;
 	int found = 0, slot;
 
@@ -244,11 +243,7 @@ static int __xen_pcibk_get_pcifront_dev(
 		list_for_each_entry(entry,
 			    &vpci_dev->dev_list[slot],
 			    list) {
-			dev = entry->dev;
-			if (dev && dev->bus->number == pcidev->bus->number
-				&& pci_domain_nr(dev->bus) ==
-					pci_domain_nr(pcidev->bus)
-				&& dev->devfn == pcidev->devfn) {
+			if (entry->dev == pcidev) {
 				found = 1;
 				*domain = 0;
 				*bus = 0;

On 4/7/21 10:37 AM, Jan Beulich wrote:
> There's no point in comparing SBDF - we can simply compare the struct
> pci_dev pointers. If they weren't the same for a given device, we'd have
> bigger problems from having stored a stale pointer.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

On 09.04.2021 23:45, Boris Ostrovsky wrote:
> 
> On 4/7/21 10:37 AM, Jan Beulich wrote:
>> There's no point in comparing SBDF - we can simply compare the struct
>> pci_dev pointers. If they weren't the same for a given device, we'd have
>> bigger problems from having stored a stale pointer.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> 
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Thanks. As the 1st patch of this series still looks to have an unclear
disposition (unless not getting back a reply on my responses to your
comments means silent agreement), I can't predict yet when I'd be able
to submit v2. Hence I'd like to point out that this patch is
independent of the former two, and hence would need to wait further if
you wanted to apply it. After all this one (unlike the other two) is
merely cleanup, and hence would rather want to go in during a merge
window.

Jan

On 4/12/21 5:50 AM, Jan Beulich wrote:
> On 09.04.2021 23:45, Boris Ostrovsky wrote:
>> On 4/7/21 10:37 AM, Jan Beulich wrote:
>>> There's no point in comparing SBDF - we can simply compare the struct
>>> pci_dev pointers. If they weren't the same for a given device, we'd have
>>> bigger problems from having stored a stale pointer.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Thanks. As the 1st patch of this series still looks to have an unclear
> disposition (unless not getting back a reply on my responses to your
> comments means silent agreement),


TBH I have been struggling with understanding both the original problem (just like you have) and the solution you are proposing (apart from making dev_list[] more compact).


>  I can't predict yet when I'd be able
> to submit v2. Hence I'd like to point out that this patch is
> independent of the former two, and hence would need to wait further if
> you wanted to apply it. After all this one (unlike the other two) is
> merely cleanup, and hence would rather want to go in during a merge
> window.


Given that next Sunday may be when 5.12 is released I think everything but stoppers will have to wait for the merge window.


-boris

On 12.04.2021 18:05, Boris Ostrovsky wrote:
> 
> On 4/12/21 5:50 AM, Jan Beulich wrote:
>> On 09.04.2021 23:45, Boris Ostrovsky wrote:
>>> On 4/7/21 10:37 AM, Jan Beulich wrote:
>>>> There's no point in comparing SBDF - we can simply compare the struct
>>>> pci_dev pointers. If they weren't the same for a given device, we'd have
>>>> bigger problems from having stored a stale pointer.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Thanks. As the 1st patch of this series still looks to have an unclear
>> disposition (unless not getting back a reply on my responses to your
>> comments means silent agreement),
> 
> 
> TBH I have been struggling with understanding both the original problem (just like you have) and the solution you are proposing (apart from making dev_list[] more compact).
> 
> 
>>  I can't predict yet when I'd be able
>> to submit v2. Hence I'd like to point out that this patch is
>> independent of the former two, and hence would need to wait further if
>> you wanted to apply it. After all this one (unlike the other two) is
>> merely cleanup, and hence would rather want to go in during a merge
>> window.
> 
> 
> Given that next Sunday may be when 5.12 is released I think everything but stoppers will have to wait for the merge window.

Oh, I didn't mean it this way. Instead I thought the 3rd patch here could
be pushed to Linus during the merge window, while the other two may be
fine to go his way also during early RCs of 5.13 (giving us some time to
sort what exactly we want to do).

Jan

On 4/13/21 4:09 AM, Jan Beulich wrote:
> On 12.04.2021 18:05, Boris Ostrovsky wrote:
>>
>> Given that next Sunday may be when 5.12 is released I think everything but stoppers will have to wait for the merge window.
> Oh, I didn't mean it this way. Instead I thought the 3rd patch here could
> be pushed to Linus during the merge window, while the other two may be
> fine to go his way also during early RCs of 5.13 (giving us some time to
> sort what exactly we want to do).
>

Ah, yes, that works.


-boris

On 07.04.21 16:37, Jan Beulich wrote:
> There's no point in comparing SBDF - we can simply compare the struct
> pci_dev pointers. If they weren't the same for a given device, we'd have
> bigger problems from having stored a stale pointer.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Pushed to xen/tip.git for-linus-5.13


Juergen