netdev - RE: [RFC V2 PATCH] rtnetlink: Fix problem with buffer allocation

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: <C5551D9AAB213A418B7FD5E4A6F30A0702F8C7D6@ORSMSX106.amr.corp.intel.com>
Date:	Tue, 14 Feb 2012 21:41:57 +0000
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	David Miller <davem@...emloft.net>
CC:	"bhutchings@...arflare.com" <bhutchings@...arflare.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [RFC V2 PATCH] rtnetlink: Fix problem with buffer allocation

> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Tuesday, February 14, 2012 1:32 PM
> To: Rose, Gregory V
> Cc: bhutchings@...arflare.com; netdev@...r.kernel.org
> Subject: Re: [RFC V2 PATCH] rtnetlink: Fix problem with buffer allocation
> 
> From: "Rose, Gregory V" <gregory.v.rose@...el.com>
> Date: Tue, 14 Feb 2012 21:27:59 +0000
> 
> > That's a real sticky problem.  When the dump request comes in we
> > don't know how big the required buffer might actually get.  That's
> > why we used to have the min_ifinfo_dump_size.  However there were
> > problems with that also so Dave asked me to get rid of it.  The only
> > thing I could come up with just allocating a really big buffer.  If
> > someone could point out to me how to get a maximum ifinfo dump size
> > before rtnl_dump_ifinfo starts filtering through the matching
> > interfaces then that would really help.  But at the point the dump
> > request comes in we don't know beforehand how to calculate the info
> > dump size because if_nlmsg_size() requires a pointer to a netdevice.
> 
> Two quick ideas:
> 
> 1) Have a first pass which iterates over the devices and calculates
>    the maximum of all if_nlmsg_size() calculations over those devices
>    then uses that for the dump buffer allocation size.
> 
> 2) Replace min_ifinfo_dump_size() with an array of sizes, one for
>    each combination of extended features.  The only concern with this
>    one is that whilst it's practical to do this now with only 1 or
>    a few feature bits, in the future it may be a lot less practical.

The second item sort of matches what I said in the last reply.  Base the buffer allocation size on the maximum possible for the given extension which as I said, is up to 255 VFs for the case under immediate consideration.

The first one seems like a good idea but I wonder what the effect would be on a system with a large number of interfaces.

- Greg


--
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