* [PATCH] can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo()
@ 2009-11-07 9:53 Wolfgang Grandegger
2009-11-08 8:46 ` David Miller
0 siblings, 1 reply; 5+ messages in thread
From: Wolfgang Grandegger @ 2009-11-07 9:53 UTC (permalink / raw)
To: Linux Netdev List; +Cc: SocketCAN Core Mailing List
On older kernels, e.g. 2.6.27, a WARN_ON dump in rtmsg_ifinfo()
is thrown when the CAN device is registered due to insufficient
skb space, as reported by various users. This patch adds the
rtnl_link_ops "get_size" to fix the problem. I think this patch
is required for more recent kernels as well, even if no WARN_ON
dumps are triggered. Maybe we also need "get_xstats_size" for
the CAN xstats.
Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
---
drivers/net/can/dev.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
Index: net-next-2.6/drivers/net/can/dev.c
===================================================================
--- net-next-2.6.orig/drivers/net/can/dev.c
+++ net-next-2.6/drivers/net/can/dev.c
@@ -637,6 +637,22 @@ static int can_changelink(struct net_dev
return 0;
}
+static size_t can_get_size(const struct net_device *dev)
+{
+ struct can_priv *priv = netdev_priv(dev);
+ size_t size;
+
+ size = nla_total_size(sizeof(u32)); /* IFLA_CAN_STATE */
+ size += sizeof(struct can_ctrlmode); /* IFLA_CAN_CTRLMODE */
+ size += nla_total_size(sizeof(u32)); /* IFLA_CAN_RESTART_MS */
+ size += sizeof(struct can_bittiming); /* IFLA_CAN_BITTIMING */
+ size += sizeof(struct can_clock); /* IFLA_CAN_CLOCK */
+ if (priv->bittiming_const) /* IFLA_CAN_BITTIMING_CONST */
+ size += sizeof(struct can_bittiming_const);
+
+ return size;
+}
+
static int can_fill_info(struct sk_buff *skb, const struct net_device *dev)
{
struct can_priv *priv = netdev_priv(dev);
@@ -687,6 +703,7 @@ static struct rtnl_link_ops can_link_ops
.setup = can_setup,
.newlink = can_newlink,
.changelink = can_changelink,
+ .get_size = can_get_size,
.fill_info = can_fill_info,
.fill_xstats = can_fill_xstats,
};
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo()
2009-11-07 9:53 [PATCH] can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo() Wolfgang Grandegger
@ 2009-11-08 8:46 ` David Miller
[not found] ` <20091108.004602.213063654.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: David Miller @ 2009-11-08 8:46 UTC (permalink / raw)
To: wg; +Cc: netdev, socketcan-core
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Sat, 07 Nov 2009 10:53:13 +0100
> On older kernels, e.g. 2.6.27, a WARN_ON dump in rtmsg_ifinfo()
> is thrown when the CAN device is registered due to insufficient
> skb space, as reported by various users. This patch adds the
> rtnl_link_ops "get_size" to fix the problem. I think this patch
> is required for more recent kernels as well, even if no WARN_ON
> dumps are triggered. Maybe we also need "get_xstats_size" for
> the CAN xstats.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Applied to net-2.6, thanks Wolfgang.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo()
[not found] ` <20091108.004602.213063654.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
@ 2009-11-08 9:30 ` Wolfgang Grandegger
2009-11-10 11:24 ` Patrick McHardy
0 siblings, 1 reply; 5+ messages in thread
From: Wolfgang Grandegger @ 2009-11-08 9:30 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
David Miller wrote:
> From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
> Date: Sat, 07 Nov 2009 10:53:13 +0100
>
>> On older kernels, e.g. 2.6.27, a WARN_ON dump in rtmsg_ifinfo()
>> is thrown when the CAN device is registered due to insufficient
>> skb space, as reported by various users. This patch adds the
>> rtnl_link_ops "get_size" to fix the problem. I think this patch
>> is required for more recent kernels as well, even if no WARN_ON
>> dumps are triggered. Maybe we also need "get_xstats_size" for
>> the CAN xstats.
>>
>> Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>
> Applied to net-2.6, thanks Wolfgang.
Thanks, the commit message included some questions. What is the rule
using the rtnl_link_ops "get_size" or "get_xstats_size". Are these
mandatory if the corresponding fill functions are used?
Wolfgang.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo()
2009-11-08 9:30 ` Wolfgang Grandegger
@ 2009-11-10 11:24 ` Patrick McHardy
[not found] ` <4AF94D74.4040606-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Patrick McHardy @ 2009-11-10 11:24 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: David Miller, netdev, socketcan-core
Wolfgang Grandegger wrote:
> David Miller wrote:
>> From: Wolfgang Grandegger <wg@grandegger.com>
>> Date: Sat, 07 Nov 2009 10:53:13 +0100
>>
>>> On older kernels, e.g. 2.6.27, a WARN_ON dump in rtmsg_ifinfo()
>>> is thrown when the CAN device is registered due to insufficient
>>> skb space, as reported by various users. This patch adds the
>>> rtnl_link_ops "get_size" to fix the problem. I think this patch
>>> is required for more recent kernels as well, even if no WARN_ON
>>> dumps are triggered. Maybe we also need "get_xstats_size" for
>>> the CAN xstats.
>>>
>>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>> Applied to net-2.6, thanks Wolfgang.
>
> Thanks, the commit message included some questions. What is the rule
> using the rtnl_link_ops "get_size" or "get_xstats_size". Are these
> mandatory if the corresponding fill functions are used?
Yes. You also need a get_xstats_size() function.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo()
[not found] ` <4AF94D74.4040606-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
@ 2009-11-10 19:45 ` Wolfgang Grandegger
0 siblings, 0 replies; 5+ messages in thread
From: Wolfgang Grandegger @ 2009-11-10 19:45 UTC (permalink / raw)
To: Patrick McHardy
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, David Miller
Patrick McHardy wrote:
> Wolfgang Grandegger wrote:
>> David Miller wrote:
>>> From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>>> Date: Sat, 07 Nov 2009 10:53:13 +0100
>>>
>>>> On older kernels, e.g. 2.6.27, a WARN_ON dump in rtmsg_ifinfo()
>>>> is thrown when the CAN device is registered due to insufficient
>>>> skb space, as reported by various users. This patch adds the
>>>> rtnl_link_ops "get_size" to fix the problem. I think this patch
>>>> is required for more recent kernels as well, even if no WARN_ON
>>>> dumps are triggered. Maybe we also need "get_xstats_size" for
>>>> the CAN xstats.
>>>>
>>>> Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>>> Applied to net-2.6, thanks Wolfgang.
>> Thanks, the commit message included some questions. What is the rule
>> using the rtnl_link_ops "get_size" or "get_xstats_size". Are these
>> mandatory if the corresponding fill functions are used?
>
> Yes. You also need a get_xstats_size() function.
Thanks for clarification. I will provide a patch a.s.a.p.
Wolfgang.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-11-10 19:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-07 9:53 [PATCH] can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo() Wolfgang Grandegger
2009-11-08 8:46 ` David Miller
[not found] ` <20091108.004602.213063654.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2009-11-08 9:30 ` Wolfgang Grandegger
2009-11-10 11:24 ` Patrick McHardy
[not found] ` <4AF94D74.4040606-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
2009-11-10 19:45 ` Wolfgang Grandegger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).