Message ID | 158273a2-d1b9-3545-b25d-affca867376c@suse.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | xen-pciback: a fix, a workaround, and some simplification | expand |
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
--- 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;
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>