[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <C5551D9AAB213A418B7FD5E4A6F30A0702F96E52@ORSMSX106.amr.corp.intel.com>
Date: Tue, 21 Feb 2012 22:03:57 +0000
From: "Rose, Gregory V" <gregory.v.rose@...el.com>
To: David Miller <davem@...emloft.net>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH V2] rtnetlink: Fix problem with buffer allocation
> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Tuesday, February 21, 2012 1:58 PM
> To: Rose, Gregory V
> Cc: netdev@...r.kernel.org
> Subject: Re: [PATCH V2] rtnetlink: Fix problem with buffer allocation
>
> From: Greg Rose <gregory.v.rose@...el.com>
> Date: Tue, 21 Feb 2012 13:51:28 -0800
>
> > Implement a new netlink attribute type IFLA_EXT_MASK. The mask
> > is a 32 bit value that can be used to indicate to the kernel that
> > certain extended ifinfo values are requested by the user application.
> > At this time the only mask value defined is RTEXT_FILTER_VF to
> > indicate that the user wants the ifinfo dump to send information
> > about the VFs belonging to the interface.
> >
> > This patch fixes a bug in which certain applications do not have
> > large enough buffers to accommodate the extra information returned
> > by the kernel with large numbers of SR-IOV virtual functions.
> > Those applications will not send the new netlink attribute with
> > the interface info dump request netlink messages so they will
> > not get unexpectedly large request buffers returned by the kernel.
> >
> > Modifies the rtnl_calcit function to traverse the list of net
> > devices and compute the minimum buffer size that can hold the
> > info dumps of all matching devices based upon the filter passed
> > in via the new netlink attribute filter mask. If no filter
> > mask is sent then the buffer allocation defaults to NLMSG_GOODSIZE.
> >
> > With this change it is possible to add yet to be defined netlink
> > attributes to the dump request which should make it fairly extensible
> > in the future.
> >
> > CC: stable@...r.kernel.org
> > Signed-off-by: Greg Rose <gregory.v.rose@...el.com>
>
> Applied, with the minor change suggested by Eric in that we can
> use the non-RCU list traversal in the calcit function because
> we hold the RTNL always when this is invoked.
Oh good, that saves me a bit of work.
>
> Thanks!
Thanks for working with me on this. I learned a lot about how netlink actually works during the process though at the obvious cost of taking longer to get it done than someone who is more familiar with the net core code than I am. Valuable experience for me and hopefully it will set us up well for future development.
- 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
Powered by blists - more mailing lists