On Wed, May 06, 2015 at 10:23:26AM -0500, Bjorn Helgaas wrote:
>On Wed, May 6, 2015 at 2:25 AM, Wei Yang <weiyang@xxxxxxxxxxxxxxxxxx> wrote:
>> On Tue, May 05, 2015 at 04:29:05PM -0500, Bjorn Helgaas wrote:
>
>>>It would be useful to mention a way to cause the leak. I suspect writing
>>>to a VF's sysfs "remove" file is the easiest.
>>>
>>
>> Looks a VF don't support the remove now.
>>
>> static umode_t pci_dev_hp_attrs_are_visible(struct kobject *kobj,
>> struct attribute *a, int n)
>> {
>> struct device *dev = container_of(kobj, struct device, kobj);
>> struct pci_dev *pdev = to_pci_dev(dev);
>>
>> if (pdev->is_virtfn)
>> return 0;
>>
>> return a->mode;
>> }
>>
>> static struct attribute_group pci_dev_hp_attr_group = {
>> .attrs = pci_dev_hp_attrs,
>> .is_visible = pci_dev_hp_attrs_are_visible,
>> };
>
>Right, I forgot about this. A VF has no "remove" file, so it can't be
>used to cause the leak.
Hmm, I see this is introduced in commit dfab88beda88, to prevent some memory
leak.
Could we say, if we do the release properly like in this patch, we could
re-enable this "remove"?
--
Richard Yang
Help you, Help me
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
