rtnetlink: Fix problem with buffer allocation
Subsystems (2)
RFC PATCH v3 1/1 rtnetlink: Fix problem with buffer allocation
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.
---
include/linux/if_link.h | 1 + include/linux/rtnetlink.h | 3 ++ include/net/rtnetlink.h | 2 + net/core/rtnetlink.c | 84 ++++++++++++++++++++++++++++++++++----------- 4 files changed, 68 insertions(+), 22 deletions(-)
include/linux/if_link.h +1 -0
@@ -137,6 +137,7 @@ enum {IFLA_AF_SPEC ,IFLA_GROUP ,/* Group the device belongs to */ IFLA_NET_NS_FD , +IFLA_EXT_MASK ,/* Extended info mask, VFs, etc */ __IFLA_MAX };
include/linux/rtnetlink.h +3 -0
@@ -602,6 +602,9 @@ struct tcamsg {#define TCA_ACT_TAB 1/* attr type must be >=1 */ #define TCAA_MAX 1 +/* New extended info filters for IFLA_EXT_MASK */ +#define RTEXT_FILTER_VF (1 << 0) +/* End of information exported to user level */ #ifdef __KERNEL__
include/net/rtnetlink.h +1 -1
@@ -6,7 +6,7 @@typedef int (*rtnl_doit_func )(struct sk_buff *,struct nlmsghdr *,void *);typedef int (*rtnl_dumpit_func )(struct sk_buff *,struct netlink_callback *); -typedef u16 (*rtnl_calcit_func )(struct sk_buff *); +typedef u16 (*rtnl_calcit_func )(struct sk_buff *,struct nlmsghdr *); extern int __rtnl_register(int protocol, int msgtype, rtnl_doit_func, rtnl_dumpit_func,
net/core/rtnetlink.c +63 -21
197 lines not on this page · raw message
David Miller
maintainerFrom: Greg Rose <[email protected]>
Date: Thu, 16 Feb 2012 15:52:18 -0800
net/core/rtnetlink.c static int rtnl_getlink(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg) · line 1919
Quoted 3 lines
net/core/rtnetlink.c +3
-0+for (h =0 ; h <NETDEV_HASHENTRIES ; h++) { + head = &net->dev_index_head[h]; +hlist_for_each_entry_rcu (dev, node, head, index_hlist) {
list_for_each_entry_rcu(dev, &net->dev_base_head, dev_list)
Quoted 7 lines
-----Original Message-----
From: David Miller [mailto:[email protected]]
Sent: Sunday, February 19, 2012 9:55 PM
To: Rose, Gregory V
Cc: [email protected]
Subject: Re: [RFC V3 PATCH] rtnetlink: Fix problem with buffer allocation
Quoted 8 lines
From: Greg Rose <[email protected]>
Date: Thu, 16 Feb 2012 15:52:18 -0800net/core/rtnetlink.c static int rtnl_getlink(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg) · line 1919
Quoted 3 lines
net/core/rtnetlink.c +3
-0+for (h =0 ; h <NETDEV_HASHENTRIES ; h++) { + head = &net->dev_index_head[h]; +hlist_for_each_entry_rcu (dev, node, head, index_hlist) {
list_for_each_entry_rcu(dev, &net->dev_base_head, dev_list)
OK, I'll fix that up.
- Greg
Quoted 19 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Rose, Gregory V
Sent: Tuesday, February 21, 2012 8:15 AM
To: David Miller
Cc: [email protected]
Subject: RE: [RFC V3 PATCH] rtnetlink: Fix problem with buffer allocationQuoted 6 lines
-----Original Message-----
From: David Miller [mailto:[email protected]]
Sent: Sunday, February 19, 2012 9:55 PM
To: Rose, Gregory V
Cc: [email protected]
Subject: Re: [RFC V3 PATCH] rtnetlink: Fix problem with bufferallocation
Quoted 4 lines
From: Greg Rose <[email protected]>
Date: Thu, 16 Feb 2012 15:52:18 -0800
Quoted 7 lines
Quoted 5 lines
net/core/rtnetlink.c static int rtnl_getlink(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg) · line 1919
Quoted 3 lines
net/core/rtnetlink.c +3
-0+for (h =0 ; h <NETDEV_HASHENTRIES ; h++) { + head = &net->dev_index_head[h]; +hlist_for_each_entry_rcu (dev, node, head, index_hlist) {
list_for_each_entry_rcu(dev, &net->dev_base_head, dev_list)OK, I'll fix that up.
Having seen no other review comments on this RFC or the related iproute2 RFC I'll go ahead and work with Jeff Kirsher to get these patches pushed for application.
- Greg
David Miller
maintainerFrom: "Rose, Gregory V" <[email protected]>
Date: Tue, 21 Feb 2012 17:46:27 +0000
Quoted 3 lines
Having seen no other review comments on this RFC or the related iproute2 RFC I'll go ahead and work with Jeff Kirsher to get these patches pushed for application.
What do you mean by this? Simply repost this patch with the fix I asked for, and do it ASAP.
These are not Intel device driver specific changes, there is absolutely no need to get Jeff involved at all. It can only make things take more time and add more red tape to the process of getting this urgent fix propagated.
I've been extremely patient allowing you to take more than a week or two to code up this fix for something which causes very serious regressions for users, don't add any new things that will consume even more time.
Quoted 22 lines
-----Original Message-----
From: David Miller [mailto:[email protected]]
Sent: Tuesday, February 21, 2012 11:49 AM
To: Rose, Gregory V
Cc: [email protected]
Subject: Re: [RFC V3 PATCH] rtnetlink: Fix problem with buffer allocationFrom: "Rose, Gregory V" <[email protected]>
Date: Tue, 21 Feb 2012 17:46:27 +0000Quoted 3 lines
Having seen no other review comments on this RFC or the related iproute2 RFC I'll go ahead and work with Jeff Kirsher to get these patches pushed for application.
What do you mean by this? Simply repost this patch with the fix I asked for, and do it ASAP.
These are not Intel device driver specific changes, there is absolutely no need to get Jeff involved at all. It can only make things take more time and add more red tape to the process of getting this urgent fix propagated.
Quoted 4 lines
I've been extremely patient allowing you to take more than a week or two to code up this fix for something which causes very serious regressions for users, don't add any new things that will consume even more time.
OK, I'll post it ASAP.
- Greg