lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 27 Sep 2021 20:26:59 +0530
From:   Kishon Vijay Abraham I <kishon@...com>
To:     Marc Zyngier <maz@...nel.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        <linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        <lokeshvutla@...com>
Subject: Re: [PATCH 1/3] PCI: Add support in pci_walk_bus() to invoke callback
 matching RID

Hi Marc,

On 27/09/21 8:15 pm, Marc Zyngier wrote:
> On Wed, 22 Sep 2021 02:26:09 +0100,
> Kishon Vijay Abraham I <kishon@...com> wrote:
>>
>>>>>> -void pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
>>>>>> -		  void *userdata)
>>>>>> +void __pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
>>>>>> +		    void *userdata, u32 rid, u32 mask)
>>>>>>  {
>>>>>>  	struct pci_dev *dev;
>>>>>>  	struct pci_bus *bus;
>>>>>> @@ -399,13 +401,16 @@ void pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
>>>>>>  		} else
>>>>>>  			next = dev->bus_list.next;
>>>>>>  
>>>>>> +		if (mask != 0xffff && ((pci_dev_id(dev) & mask) != rid))
>>>>>
>>>>> Why the check for the mask? I also wonder whether the mask should apply
>>>>> to the rid as well:
>>>>
>>>> If the mask is set for all 16bits, then there is not going to be two PCIe
>>>> devices which gets the same ITS device ID right? So no need for calculating
>>>> total number of vectors?
>>>
>>> Are we really arguing about the cost of a compare+branch vs some
>>> readability? Or is there an actual correctness issue here?
>>
>> It is for correctness. So existing pci_walk_bus() doesn't invoke cb based on
>> rid. So when we convert to __pci_walk_bus(), existing callers of pci_walk_bus()
>> might not invoke cb for some devices without the check.
>>>
>>>>>
>>>>> 		if ((pci_dev_id(dev) & mask) != (rid & mask))
>>>
>>> Because I think the above expression is a lot more readable (and
>>> likely more correct) than what you are suggesting.
>>
>> That would result in existing pci_walk_bus() behave differently from what was
>> before this patch no?
>>
>> I'm having something like this below
>> 	+#define pci_walk_bus(top, cb, userdata) \
>> 	+	 __pci_walk_bus((top), (cb), (userdata), 0x0, 0xffff)
>>
>> So if we add only "if ((pci_dev_id(dev) & mask) != (rid & mask))",
>> the callback will not be invoked for any devices (other than one
>> with rid = 0)
> 
> But that *is* the bug, isn't it? If you want to parse all the devices,
> a mask of 0 is what you need. The mask defines the bits that you want
> to match against the RID you passed as a parameter. If you don't want
> to check any bit, don't pass any!

Indeed! Thanks for explaining.

Regards,
Kishon

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ