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
| ||
|
Message-ID: <CC28FCDE.36B6C%anirban.chakraborty@qlogic.com> Date: Sun, 15 Jul 2012 23:10:42 -0700 From: Anirban Chakraborty <anirban.chakraborty@...gic.com> To: Jay Vosburgh <fubar@...ibm.com> CC: John Fastabend <john.r.fastabend@...el.com>, David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>, Dept-NX Linux NIC Driver <Dept_NX_Linux_NIC_Driver@...gic.com> Subject: Re: [PATCH net-next] bonding: Support for multi function NIC devices On 7/15/12 10:50 PM, "Jay Vosburgh" <fubar@...ibm.com> wrote: >Anirban Chakraborty <anirban.chakraborty@...gic.com> wrote: >>On 7/15/12 9:39 PM, "John Fastabend" <john.r.fastabend@...el.com> wrote: >[...] >>>Also I'm not sure we need to explicitly block this. It is clear from >>>looking at 'ip' output what the topology is. And in the SR-IOV >>>case would this still work if the functions are direct assigned? How >>>about if I try to bond two stacked devices that are on the same >>>physical link. In both case iirc the bus info wont match up. >>> >>>Seems easier to just call this a configuration error or not if for >>>some reason this is really what someone intended. >>> >>>.John >> >>I agree that for SR-IOV case with VFs assigned directly to the guest, bus >>info won't >>match up. However, I was thinking from the point of view of NIC >>partitioned mode (NPAR), >>and for the use case of SR-IOV VFs assigned to the hypervisor. It would >>be >>nice to >>prevent the user from getting into misconfiguration. > > If I'm understanding correctly, to hit the case you're worried >about here would require assigning multiple VFs from one PF to the same >linux instance as the PF itself, and then bonding those VFs together. > > Heck, there might be some arcane reason that somebody wants to >do that on purpose, or the test may inadvertently prohibit legal >configurations that happen to match the criteria. > > Has this been a real problem in practice? I'm not seeing a >compelling argument for doing this. > > -J The real problem that we have faced so far is the case of NPAR, where multiple physical functions are assigned to the linux host and the customer tried to create a bond of interfaces from the same physical port. In this case, linux host was running without any guest OS and the NICs are used for carrying host traffic only. -Anirban -- 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
Powered by blists - more mailing lists