* Re: netfilter 02/02: xt_connlimit: fix regression caused by zero family value
From: David Miller @ 2009-11-07 2:08 UTC (permalink / raw)
To: kaber; +Cc: jengelh, netfilter-devel, netdev
In-Reply-To: <4AF43782.50604@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 06 Nov 2009 15:49:38 +0100
> Jan Engelhardt wrote:
>> On Thursday 2009-11-05 19:23, Patrick McHardy wrote:
>>> netfilter: xt_connlimit: fix regression caused by zero family value
>>>
>>> Commit v2.6.28-rc1~7172~1092~2 was slightly incomplete; not all
>>> instances of par->match->family were changed to par->family.
>>>
>>> Netfilter bugzilla #610.
>>
>> Hold it.
>> git would never output ~7172~1092~2 because ~8266 would be much simpler.
>>
>> I originally wrote "Commit v2.6.28-rc1~717^2~109^2~2", but one of your
>> programs seems to eat commit messages or more.
>
> Indeed, my email client displays ^2 as ², which cut and paste transforms
> to 2 :)
Ok, so I'll apply Jan's fixed up version, thanks!
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-11-06
From: David Miller @ 2009-11-07 2:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20091106204034.GI2782@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 6 Nov 2009 15:40:34 -0500
> Three more intended for 2.6.32, two oops fixes and a revert of a patch
> that traded one bug for another. One of the oops fixes reorders some
> cancel_delayed_work_sync calls and the other does some bit testing to
> avoid scheduling work after a device has been removed.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
^ permalink raw reply
* TC-HTB issue : low throughput
From: Jean Tourrilhes @ 2009-11-07 2:43 UTC (permalink / raw)
To: netdev
Hi,
I'm playing with a TC-HTB. I'm noticing that the throughput is
low. As the LARTC mailing list seems to be dead, I would welcome
suggestions...
The example below may seem contrived, but I reduced it to
a simple testcase to make it easier to reproduce.
System :
------
Debian Lenny with 2.6.30.9
Quad Core 2.5 GHz Q9300
Intel 1Gb/s NIC, e1000e driver
Setup :
-----
# brctl addbr br0
# brctl addif br0 eth5.33
# brctl addif br0 eth6.34
# brctl addif br0 eth7.38
#iptables -A FORWARD -t mangle -s 10.10.32.38 -j CLASSIFY --set-class 1:2
#tc qdisc add dev eth6.34 root handle 1: htb default 3
#tc class add dev eth6.34 parent 1: classid 1:1 htb rate 1000mbit ceil 1000mbit
#tc class add dev eth6.34 parent 1:1 classid 1:2 htb rate 3kbit ceil 1000mbit prio 1
#tc class add dev eth6.34 parent 1:1 classid 1:3 htb rate 3kbit ceil 1000mbit prio 2
Topology :
--------
Four PCs with Linux :
10.10.10.32 on br0
10.10.10.33 connected to eth5.33 (sender)
10.10.10.38 connected to eth7.38 (sender)
10.10.10.34 connected to eth6.34 (receiver)
Behaviour :
---------
If I set only qdisc 1: and class 1:1, but *NOT* 1:2 and 1:3 :
Each host independantly : ~935 Mb/s
Both host together, for 10.10.10.38 : ~527 Mb/s ;
Both host together, for 10.10.10.33 : ~443 Mb/s
If I add classes 1:2 and 1:3 :
Each host independantly : ~170 Mb/s.
Both host together, for 10.10.10.38 : ~106 Mb/s ;
Both host together, for 10.10.10.33 : ~135 Mb/s
So, not only performance did drop significantely, but
prioritisation did not happen as expected.
Weird detail :
------------
I've noticed that /sbin/tc calculates a very low burst
value. This is due to the content of /proc/net/psched. I'm wondering
if the burst calculation is what causes the issue here.
However, I tried with "burst 50kb" and saw no difference...
Dump of TC
----------
# tc -s class show dev eth6.34
class htb 1:1 root rate 1000Mbit ceil 1000Mbit burst 1375b cburst 1375b
Sent 770653596 bytes 509070 pkt (dropped 0, overlimits 0 requeues 0)
rate 82776Kbit 6835pps backlog 0b 0p requeues 0
lended: 509026 borrowed: 0 giants: 0
tokens: 11 ctokens: 11
class htb 1:2 parent 1:1 prio 1 rate 3000bit ceil 1000Mbit burst 1599b cburst 13
75b
Sent 369190389 bytes 243876 pkt (dropped 3239, overlimits 0 requeues 0)
rate 44781Kbit 3698pps backlog 0b 0p requeues 0
lended: 20 borrowed: 243856 giants: 0
tokens: -1384355 ctokens: 11
class htb 1:3 parent 1:1 prio 2 rate 3000bit ceil 1000Mbit burst 1599b cburst 13
75b
Sent 401463207 bytes 265194 pkt (dropped 3005, overlimits 0 requeues 0)
rate 37996Kbit 3137pps backlog 0b 0p requeues 0
lended: 24 borrowed: 265170 giants: 0
tokens: -3719389 ctokens: 11
# tc -s qdisc show dev eth6.34
qdisc htb 1: root r2q 10 default 3 direct_packets_stat 0
Sent 770653852 bytes 509071 pkt (dropped 6244, overlimits 25973 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
Thanks in advance for any help...
Jean
^ permalink raw reply
* Re: [PATCH 1/2] be2net: fix to set proper flow control on resume
From: David Miller @ 2009-11-07 4:26 UTC (permalink / raw)
To: ajitk; +Cc: netdev
In-Reply-To: <20091106120445.GA19181@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Fri, 6 Nov 2009 17:36:59 +0530
> If be2 goes into suspend after a user changes the flow control settings,
> we are not programming them back after resume. This patch takes care of it.
> We now get the flow control settings before going to suspend mode and
> then apply them during resume.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH 2/2] be2net: Bug fix to send config commands to hardware after netdev_register
From: David Miller @ 2009-11-07 4:26 UTC (permalink / raw)
To: ajitk; +Cc: netdev
In-Reply-To: <20091106120720.GA19198@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Fri, 6 Nov 2009 17:37:32 +0530
> Sending config commands to be2 hardware before netdev_register is
> completed, is sometimes causing the async link notification to arrive
> even before the driver is ready to handle it. The commands for vlan
> config and flow control settings can infact wait till be_open.
> This patch takes care of that.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH] ems_usb: Fix byte order issues on big endian machines
From: David Miller @ 2009-11-07 4:26 UTC (permalink / raw)
To: haas; +Cc: netdev, socketcan-core
In-Reply-To: <20091104154824.18199.15573.stgit@localhost.localdomain>
From: Sebastian Haas <haas@ems-wuensche.com>
Date: Wed, 04 Nov 2009 16:48:24 +0100
> CPC-USB is using a ARM7 core with little endian byte order. The "id" field
> in can_msg needs byte order conversion from/to CPU byte order.
>
> Signed-off-by: Sebastian Haas <haas@ems-wuensche.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH 1/1] NET: cassini, fix lock imbalance
From: David Miller @ 2009-11-07 4:26 UTC (permalink / raw)
To: jirislaby; +Cc: netdev, linux-kernel
In-Reply-To: <1257498869-4374-1-git-send-email-jirislaby@gmail.com>
From: Jiri Slaby <jirislaby@gmail.com>
Date: Fri, 6 Nov 2009 10:14:29 +0100
> Stanse found that one error path in cas_open omits to unlock pm_mutex.
> Fix that.
>
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH 7/13] macsonic: fix crash on PowerBook 520
From: David Miller @ 2009-11-07 4:27 UTC (permalink / raw)
To: fthain; +Cc: geert, tsbogend, netdev, linux-m68k
In-Reply-To: <alpine.OSX.2.00.0911031448060.483@silk.local>
From: Finn Thain <fthain@telegraphics.com.au>
Date: Wed, 4 Nov 2009 00:42:40 +1100 (EST)
> No-one seems to know where the PowerBook 500 series store their ethernet
> MAC addresses. So, rather than crash, use a MAC address from the SONIC
> CAM. Failing that, generate a random one.
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Applied to net-2.6
^ permalink raw reply
* Re: [net-2.6 PATCH 1/3] ixgbe: Fix gso_max_size for 82599 when DCB is enabled
From: David Miller @ 2009-11-07 4:34 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou, peter.p.waskiewicz.jr
In-Reply-To: <20091106225526.28063.83720.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 06 Nov 2009 14:55:38 -0800
> From: Yi Zou <yi.zou@intel.com>
>
> The 32k gso_max_size when DCB is enabled is for 82598 only, not for 82599.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/3] ixgbe: Fix checking TFCS register for TXOFF status when DCB is enabled
From: David Miller @ 2009-11-07 4:34 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou, peter.p.waskiewicz.jr
In-Reply-To: <20091106225559.28063.467.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 06 Nov 2009 14:56:00 -0800
> From: Yi Zou <yi.zou@intel.com>
>
> When DCB is enabled, the ixgbe_check_tx_hang() should check the corresponding
> TC's TXOFF in TFCS based on the TC that the tx ring belongs to. Adds a
> function to map from the tx_ring hw reg_idx to the correspodning TC and read
> TFCS accordingly.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 3/3] ixgbe: fix traffic hangs on Tx with ioatdma loaded
From: David Miller @ 2009-11-07 4:34 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, donald.c.skidmore, peter.p.waskiewicz.jr
In-Reply-To: <20091106225620.28063.96209.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 06 Nov 2009 14:56:20 -0800
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> When ioatdma was loaded we we were unable to transmit traffic. We weren't
> using the correct registers in ixgbe_update_tx_dca for 82599 systems.
> Likewise in ixgbe_configure_tx() we weren't disabling the arbiter before
> modifying MTQC.
>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: hisax: remove bad udelay call to fix build error on ARM
From: David Miller @ 2009-11-07 4:34 UTC (permalink / raw)
To: tbm; +Cc: isdn, tilman, netdev
In-Reply-To: <20091107005234.GA1678@deprecation.cyrius.com>
From: Martin Michlmayr <tbm@cyrius.com>
Date: Sat, 7 Nov 2009 00:52:34 +0000
> The hisax ISDN driver fails to build on ARM with CONFIG_HISAX_ELSA:
>
> | drivers/built-in.o: In function `modem_set_dial':
> | drivers/isdn/hisax/elsa_ser.c:535: undefined reference to `__bad_udelay'
> | drivers/isdn/hisax/elsa_ser.c:544: undefined reference to `__bad_udelay'
> | drivers/built-in.o: In function `modem_set_init':
> | drivers/isdn/hisax/elsa_ser.c:486: undefined reference to `__bad_udelay'
> | [...]
>
> According to the comment in arch/arm/include/asm/delay.h, __bad_udelay
> is specifically designed on ARM to produce a build failure when udelay
> is called with a value > 2000.
>
> Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Applied to net-2.6
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] qlge: Fix early exit from mbox cmd complete wait.
From: David Miller @ 2009-11-07 4:35 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1257529498-17459-2-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Fri, 6 Nov 2009 09:44:57 -0800
> This line was accidentally left out of the previous commit #
> da03945140a035a2962f7f93e359085596f20499.
>
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Applied, but please provide a text string of the commit's
header line when referencing a commit, don't just provide
the SHA1 ID as that can be not referencable in a -stable
backport.
Here is how I fixed up your commit message so that you can
see how to form it next time, thanks.
qlge: Fix early exit from mbox cmd complete wait.
This line was accidentally left out of the previous commit #
da03945140a035a2962f7f93e359085596f20499 ("qlge: Fix firmware mailbox
command timeout.").
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [net-2.6 PATCH 2/2] qlge: Set PCIe reset type for EEH to fundamental.
From: David Miller @ 2009-11-07 4:35 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1257529498-17459-3-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Fri, 6 Nov 2009 09:44:58 -0800
> This device requires a fundamental reset when recovering from EEH.
>
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Applied.
^ permalink raw reply
* Re: ipip: Fix handling of DF packets when pmtudisc is OFF
From: David Miller @ 2009-11-07 4:36 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20091106203741.GA19736@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 6 Nov 2009 15:37:41 -0500
> ipip: Fix handling of DF packets when pmtudisc is OFF
...
> This patch fixes the problem by performing PMTU discovery for
> all packets with the inner DF bit set, regardless of the PMTU
> discovery setting on the tunnel itself.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The fun never ends :-)
Applied to net-2.6, thanks Herbert.
^ permalink raw reply
* Re: [RFC, PATCH 0/7] net, compat_ioctl: move handlers to net/socket.c
From: David Miller @ 2009-11-07 4:47 UTC (permalink / raw)
To: arnd; +Cc: linux-kernel, hch, netdev
In-Reply-To: <1257530949-9695-1-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 6 Nov 2009 19:09:02 +0100
> This cleans up some of the socket ioctl handling by moving it
> from fs/compat_ioctl.c to net/socket.c. The code is still untested,
> so this is an RFC for now. If you're happy with it, I'll do some
> testing to see if everything still works.
>
> This series is a prerequisite for cleaning up the rest of
> compat_ioctl.c, saving some 30kb of kernel memory in the end.
>
> The first four patches are probably worthwhile independently,
> because they fix some bugs in compat_ioctl handling.
> There is some obvious conflict with the ATM patch I sent
> independently today. That one should probably be worked out
> first.
This looks great, all applied. Please make the fixups recommended
to you in the feedback as followon patches.
Also, I added the following cure after your patch series:
net: compat: No need to define IFHWADDRLEN and IFNAMSIZ twice.
It's defined colloqually in linux/if.h and linux/compat.h
includes that.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/compat.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 8311d2e..224c7a8 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -166,8 +166,6 @@ struct compat_ifmap {
};
struct compat_ifreq {
-#define IFHWADDRLEN 6
-#define IFNAMSIZ 16
union {
char ifrn_name[IFNAMSIZ]; /* if name, e.g. "en0" */
} ifr_ifrn;
--
1.6.5.2
^ permalink raw reply related
* Re: [patch 03/16] net: Replace old style lock initializer
From: David Miller @ 2009-11-07 6:17 UTC (permalink / raw)
To: tglx; +Cc: linux-kernel, mingo, peterz, netdev
In-Reply-To: <20091106223806.519088363@linutronix.de>
From: Thomas Gleixner <tglx@linutronix.de>
Date: Fri, 06 Nov 2009 22:41:15 -0000
> SPIN_LOCK_UNLOCKED is deprecated. Use DEFINE_SPINLOCK instead.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* [PATCH net-next-2.6] rtnetlink: Cleanups
From: Eric Dumazet @ 2009-11-07 6:23 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
Pure cleanups patch
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/rtnetlink.c | 54 +++++++++++++++++------------------------
1 files changed, 23 insertions(+), 31 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 391a62c..e2f3317 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -38,7 +38,6 @@
#include <asm/uaccess.h>
#include <asm/system.h>
-#include <asm/string.h>
#include <linux/inet.h>
#include <linux/netdevice.h>
@@ -53,8 +52,7 @@
#include <net/rtnetlink.h>
#include <net/net_namespace.h>
-struct rtnl_link
-{
+struct rtnl_link {
rtnl_doit_func doit;
rtnl_dumpit_func dumpit;
};
@@ -65,6 +63,7 @@ void rtnl_lock(void)
{
mutex_lock(&rtnl_mutex);
}
+EXPORT_SYMBOL(rtnl_lock);
void __rtnl_unlock(void)
{
@@ -76,16 +75,19 @@ void rtnl_unlock(void)
/* This fellow will unlock it for us. */
netdev_run_todo();
}
+EXPORT_SYMBOL(rtnl_unlock);
int rtnl_trylock(void)
{
return mutex_trylock(&rtnl_mutex);
}
+EXPORT_SYMBOL(rtnl_trylock);
int rtnl_is_locked(void)
{
return mutex_is_locked(&rtnl_mutex);
}
+EXPORT_SYMBOL(rtnl_is_locked);
static struct rtnl_link *rtnl_msg_handlers[NPROTO];
@@ -168,7 +170,6 @@ int __rtnl_register(int protocol, int msgtype,
return 0;
}
-
EXPORT_SYMBOL_GPL(__rtnl_register);
/**
@@ -188,7 +189,6 @@ void rtnl_register(int protocol, int msgtype,
"protocol = %d, message type = %d\n",
protocol, msgtype);
}
-
EXPORT_SYMBOL_GPL(rtnl_register);
/**
@@ -213,7 +213,6 @@ int rtnl_unregister(int protocol, int msgtype)
return 0;
}
-
EXPORT_SYMBOL_GPL(rtnl_unregister);
/**
@@ -230,7 +229,6 @@ void rtnl_unregister_all(int protocol)
kfree(rtnl_msg_handlers[protocol]);
rtnl_msg_handlers[protocol] = NULL;
}
-
EXPORT_SYMBOL_GPL(rtnl_unregister_all);
static LIST_HEAD(link_ops);
@@ -253,7 +251,6 @@ int __rtnl_link_register(struct rtnl_link_ops *ops)
list_add_tail(&ops->list, &link_ops);
return 0;
}
-
EXPORT_SYMBOL_GPL(__rtnl_link_register);
/**
@@ -271,7 +268,6 @@ int rtnl_link_register(struct rtnl_link_ops *ops)
rtnl_unlock();
return err;
}
-
EXPORT_SYMBOL_GPL(rtnl_link_register);
static void __rtnl_kill_links(struct net *net, struct rtnl_link_ops *ops)
@@ -309,7 +305,6 @@ void __rtnl_link_unregister(struct rtnl_link_ops *ops)
}
list_del(&ops->list);
}
-
EXPORT_SYMBOL_GPL(__rtnl_link_unregister);
/**
@@ -322,7 +317,6 @@ void rtnl_link_unregister(struct rtnl_link_ops *ops)
__rtnl_link_unregister(ops);
rtnl_unlock();
}
-
EXPORT_SYMBOL_GPL(rtnl_link_unregister);
static const struct rtnl_link_ops *rtnl_link_ops_get(const char *kind)
@@ -427,12 +421,13 @@ void __rta_fill(struct sk_buff *skb, int attrtype, int attrlen, const void *data
struct rtattr *rta;
int size = RTA_LENGTH(attrlen);
- rta = (struct rtattr*)skb_put(skb, RTA_ALIGN(size));
+ rta = (struct rtattr *)skb_put(skb, RTA_ALIGN(size));
rta->rta_type = attrtype;
rta->rta_len = size;
memcpy(RTA_DATA(rta), data, attrlen);
memset(RTA_DATA(rta) + attrlen, 0, RTA_ALIGN(size) - size);
}
+EXPORT_SYMBOL(__rta_fill);
int rtnetlink_send(struct sk_buff *skb, struct net *net, u32 pid, unsigned group, int echo)
{
@@ -454,6 +449,7 @@ int rtnl_unicast(struct sk_buff *skb, struct net *net, u32 pid)
return nlmsg_unicast(rtnl, skb, pid);
}
+EXPORT_SYMBOL(rtnl_unicast);
void rtnl_notify(struct sk_buff *skb, struct net *net, u32 pid, u32 group,
struct nlmsghdr *nlh, gfp_t flags)
@@ -466,6 +462,7 @@ void rtnl_notify(struct sk_buff *skb, struct net *net, u32 pid, u32 group,
nlmsg_notify(rtnl, skb, pid, group, report, flags);
}
+EXPORT_SYMBOL(rtnl_notify);
void rtnl_set_sk_err(struct net *net, u32 group, int error)
{
@@ -473,6 +470,7 @@ void rtnl_set_sk_err(struct net *net, u32 group, int error)
netlink_set_err(rtnl, 0, group, error);
}
+EXPORT_SYMBOL(rtnl_set_sk_err);
int rtnetlink_put_metrics(struct sk_buff *skb, u32 *metrics)
{
@@ -501,6 +499,7 @@ nla_put_failure:
nla_nest_cancel(skb, mx);
return -EMSGSIZE;
}
+EXPORT_SYMBOL(rtnetlink_put_metrics);
int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
u32 ts, u32 tsage, long expires, u32 error)
@@ -520,14 +519,13 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
}
-
EXPORT_SYMBOL_GPL(rtnl_put_cacheinfo);
static void set_operstate(struct net_device *dev, unsigned char transition)
{
unsigned char operstate = dev->operstate;
- switch(transition) {
+ switch (transition) {
case IF_OPER_UP:
if ((operstate == IF_OPER_DORMANT ||
operstate == IF_OPER_UNKNOWN) &&
@@ -728,6 +726,7 @@ const struct nla_policy ifla_policy[IFLA_MAX+1] = {
[IFLA_NET_NS_PID] = { .type = NLA_U32 },
[IFLA_IFALIAS] = { .type = NLA_STRING, .len = IFALIASZ-1 },
};
+EXPORT_SYMBOL(ifla_policy);
static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
[IFLA_INFO_KIND] = { .type = NLA_STRING },
@@ -932,7 +931,8 @@ static int rtnl_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
goto errout;
}
- if ((err = validate_linkmsg(dev, tb)) < 0)
+ err = validate_linkmsg(dev, tb);
+ if (err < 0)
goto errout;
err = do_setlink(dev, ifm, tb, ifname, 0);
@@ -985,7 +985,8 @@ struct net_device *rtnl_create_link(struct net *net, char *ifname,
unsigned int real_num_queues = 1;
if (ops->get_tx_queues) {
- err = ops->get_tx_queues(net, tb, &num_queues, &real_num_queues);
+ err = ops->get_tx_queues(net, tb, &num_queues,
+ &real_num_queues);
if (err)
goto err;
}
@@ -1026,6 +1027,7 @@ err_free:
err:
return ERR_PTR(err);
}
+EXPORT_SYMBOL(rtnl_create_link);
static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
{
@@ -1059,7 +1061,8 @@ replay:
else
dev = NULL;
- if ((err = validate_linkmsg(dev, tb)) < 0)
+ err = validate_linkmsg(dev, tb);
+ if (err < 0)
return err;
if (tb[IFLA_LINKINFO]) {
@@ -1210,7 +1213,7 @@ static int rtnl_dump_all(struct sk_buff *skb, struct netlink_callback *cb)
if (s_idx == 0)
s_idx = 1;
- for (idx=1; idx<NPROTO; idx++) {
+ for (idx = 1; idx < NPROTO; idx++) {
int type = cb->nlh->nlmsg_type-RTM_BASE;
if (idx < s_idx || idx == PF_PACKET)
continue;
@@ -1277,7 +1280,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
if (nlh->nlmsg_len < NLMSG_LENGTH(sizeof(struct rtgenmsg)))
return 0;
- family = ((struct rtgenmsg*)NLMSG_DATA(nlh))->rtgen_family;
+ family = ((struct rtgenmsg *)NLMSG_DATA(nlh))->rtgen_family;
if (family >= NPROTO)
return -EAFNOSUPPORT;
@@ -1310,7 +1313,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
if (nlh->nlmsg_len > min_len) {
int attrlen = nlh->nlmsg_len - NLMSG_ALIGN(min_len);
- struct rtattr *attr = (void*)nlh + NLMSG_ALIGN(min_len);
+ struct rtattr *attr = (void *)nlh + NLMSG_ALIGN(min_len);
while (RTA_OK(attr, attrlen)) {
unsigned flavor = attr->rta_type;
@@ -1416,14 +1419,3 @@ void __init rtnetlink_init(void)
rtnl_register(PF_UNSPEC, RTM_GETROUTE, NULL, rtnl_dump_all);
}
-EXPORT_SYMBOL(__rta_fill);
-EXPORT_SYMBOL(rtnetlink_put_metrics);
-EXPORT_SYMBOL(rtnl_lock);
-EXPORT_SYMBOL(rtnl_trylock);
-EXPORT_SYMBOL(rtnl_unlock);
-EXPORT_SYMBOL(rtnl_is_locked);
-EXPORT_SYMBOL(rtnl_unicast);
-EXPORT_SYMBOL(rtnl_notify);
-EXPORT_SYMBOL(rtnl_set_sk_err);
-EXPORT_SYMBOL(rtnl_create_link);
-EXPORT_SYMBOL(ifla_policy);
^ permalink raw reply related
* Re: [PATCH net-next-2.6] rtnetlink: Cleanups
From: David Miller @ 2009-11-07 9:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AF51255.909@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 07 Nov 2009 07:23:17 +0100
> Pure cleanups patch
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo()
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
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Pavel Machek @ 2009-11-07 17:30 UTC (permalink / raw)
To: Ivo van Doorn
Cc: Ingo Molnar, Bartlomiej Zolnierkiewicz,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap, Luis Correia,
John W. Linville, Johannes Berg, Jarek Poplawski, Pekka Enberg,
David Miller
In-Reply-To: <200911061858.56816.IvDoorn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi!
> > > So if I want to focus on something different in the kernel, I just send 1 patch,
> > > and a second to claim the maintainership of it even though there is an active
> > > maintainer available?
> >
> > What about listing yourself as a maintainer for a start?
>
> The rt2x00 project is listed as maintainer for everything in the
> drivers/net/wireless/rt2x00 folder.
Yes, but that tells very little. I don't know who the 'rt2x00 project'
is. Perhaps its you? Perhaps its Bart? Maybe its my cat? Please just
list real names of maintainers... Pavel
-- (english)
http://www.livejournal.com/~pavelmachek (cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Luis Correia @ 2009-11-07 18:12 UTC (permalink / raw)
To: Pavel Machek
Cc: Ivo van Doorn, Ingo Molnar, Bartlomiej Zolnierkiewicz,
linux-wireless, linux-kernel, netdev, Randy Dunlap,
John W. Linville, Johannes Berg, Jarek Poplawski, Pekka Enberg,
David Miller
In-Reply-To: <20091107173028.GA1932@ucw.cz>
Pavel,
On Sat, Nov 7, 2009 at 17:30, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> > > So if I want to focus on something different in the kernel, I just send 1 patch,
>> > > and a second to claim the maintainership of it even though there is an active
>> > > maintainer available?
>> >
>> > What about listing yourself as a maintainer for a start?
>>
>> The rt2x00 project is listed as maintainer for everything in the
>> drivers/net/wireless/rt2x00 folder.
>
> Yes, but that tells very little. I don't know who the 'rt2x00 project'
> is. Perhaps its you? Perhaps its Bart? Maybe its my cat? Please just
> list real names of maintainers... Pavel
the answer is (and always was available) here:
http://rt2x00.serialmonkey.com/wiki/index.php/Developers
Luis Correia
rt2x00 project admin
^ permalink raw reply
* Your Email ID has been awarded 1,000,000,00
From: British Telecom Plc @ 2009-11-07 18:16 UTC (permalink / raw)
Your Email ID has been awarded 1,000,000,00 GBP in British Promo
1.Full Name:
2.Full Address:
3.Status:
4.Occupation:
5.Phone Number:
6.Country:
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Ivo van Doorn @ 2009-11-07 18:31 UTC (permalink / raw)
To: Luis Correia
Cc: Pavel Machek, Ingo Molnar, Bartlomiej Zolnierkiewicz,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap, John W. Linville,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <efe7343f0911071012u73317883wc60f5c188bc853e8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Saturday 07 November 2009, Luis Correia wrote:
> Pavel,
>
> On Sat, Nov 7, 2009 at 17:30, Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> wrote:
> > Hi!
> >
> >> > > So if I want to focus on something different in the kernel, I just send 1 patch,
> >> > > and a second to claim the maintainership of it even though there is an active
> >> > > maintainer available?
> >> >
> >> > What about listing yourself as a maintainer for a start?
> >>
> >> The rt2x00 project is listed as maintainer for everything in the
> >> drivers/net/wireless/rt2x00 folder.
> >
> > Yes, but that tells very little. I don't know who the 'rt2x00 project'
> > is. Perhaps its you? Perhaps its Bart? Maybe its my cat? Please just
> > list real names of maintainers... Pavel
>
> the answer is (and always was available) here:
>
> http://rt2x00.serialmonkey.com/wiki/index.php/Developers
True, but I agree with Pavel that the MAINTAINERS file should
be instantly clear about who the maintainer is.
I've already send a patch to add update the entry.
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* CTP: Ethernet configuration testing protocol
From: James Courtier-Dutton @ 2009-11-07 18:16 UTC (permalink / raw)
To: netdev
Hi,
How do I turn off CTP in Linux?
Kind Regards
James
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox