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
| ||
|
Date: Mon, 30 Jan 2012 11:58:00 -0500 (EST) From: David Miller <davem@...emloft.net> To: gregory.v.rose@...el.com Cc: david.vrabel@...rix.com, netdev@...r.kernel.org, steweg@...il.com Subject: Re: Regression: "rtnetlink: Compute and store minimum ifinfo dump size" breaks glibc's getifaddrs() From: "Rose, Gregory V" <gregory.v.rose@...el.com> Date: Mon, 30 Jan 2012 16:50:58 +0000 > Maybe we should have 'ip link show' just display the number of VFs > and then have a new 'ip' tool syntax along the lines of 'ip link > show eth(x) vf (n)' where eth(x) is the PF and n is the number of > the VF. Then it could show all relevant information for just that > VF. Scripts could parse the number of VFs from the first call to > 'ip link show' and then loop to show the details of each VF. > > Just an idea... maybe there are other ones out there but it's just > getting ridiculous how much data has to be transferred back and > forth during the basic 'ip link show' command when the interface as > subordinate VFs now that we're getting to devices with up to 256 > VFs. The fix is almost certainly that we need to require that the application turn on the publishing of features it is interested in. The inet_diag sockets do something like this, wherein you set bits in some flags of the request saying what attributes you want to see. It seems clear that we must, at this point, turn off VF attributes by default. Could you do some work on this? If you don't have the time I'll look into it, because we'll need to backport this to -stable too. Thanks. -- 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