netdev - Re: [PATCH RFC] pci: Control whether VFs are probed on pci_enable

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141209064339.GA1806@mtldesk30>
Date:	Tue, 9 Dec 2014 08:43:39 +0200
From:	Eli Cohen <eli@....mellanox.co.il>
To:	Yuval Mintz <Yuval.Mintz@...gic.com>
Cc:	Eli Cohen <eli@....mellanox.co.il>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	David Miller <davem@...emloft.net>,
	linux-pci <linux-pci@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	"ogerlitz@...lanox.com" <ogerlitz@...lanox.com>,
	"yevgenyp@...lanox.com" <yevgenyp@...lanox.com>,
	Donald Dutile <ddutile@...hat.com>
Subject: Re: [PATCH RFC] pci: Control whether VFs are probed on
 pci_enable_sriov

On Mon, Dec 08, 2014 at 07:25:24PM +0000, Yuval Mintz wrote:
> 
> >Currently the kerenl will call probe for any device for which there is
> >a supporting driver and I did not want to change that.
> 
> But what's next? How will this feature be activated?
> 
> Adding a parameter to pci_enable_sriov() might give developers the false
> impression they can change behavior by passing `0' to this function; 
> But that shouldn't be the method to control this - we should have uniform 
> control of the feature across different drivers, e.g., by an additional sysfs node.

I was planning on using this on mlx5 SRIOV support which is not
available upstream yet. So this could be a driver developer's decision
how to use this. I think adding another sysfs entry to control this
behavior is unnecessary since the administrator has the freedom to
later do any bidnings he wishes to do.

Keeping things as they are today is not so "nice". I mean, I could
fail probe for VFs to avoid them from being initialized at the
hypervisor but there are other questions: which error should I return
and how can I be sure how the bus driver will refer to such failures.

So, maybe the solution I suggested is not the best one but do we agree
that this needs to be addressed this way or another?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html