* [PATCH 2/3] mii: Convert printks to netdev_info
From: Joe Perches @ 2011-03-02 17:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <7f33dcacd277e127208211d8c3ef11c992408628.1299086044.git.joe@perches.com>
Add a bit more data to the output.
Convert string speeds to integer.
Object size reduced a tiny bit.
$ size drivers/net/mii.o*
text data bss dec hex filename
4155 56 1000 5211 145b drivers/net/mii.o.new
4184 56 1000 5240 1478 drivers/net/mii.o.old
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/tun.c | 83 ++++++++++++++++++++--------------------------------
1 files changed, 32 insertions(+), 51 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index f5e9ac0..55786a0 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -34,8 +34,6 @@
* Modifications for 2.3.99-pre5 kernel.
*/
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
#define DRV_NAME "tun"
#define DRV_VERSION "1.6"
#define DRV_DESCRIPTION "Universal TUN/TAP device driver"
@@ -78,27 +76,11 @@
#ifdef TUN_DEBUG
static int debug;
-#define tun_debug(level, tun, fmt, args...) \
-do { \
- if (tun->debug) \
- netdev_printk(level, tun->dev, fmt, ##args); \
-} while (0)
-#define DBG1(level, fmt, args...) \
-do { \
- if (debug == 2) \
- printk(level fmt, ##args); \
-} while (0)
+#define DBG if(tun->debug)printk
+#define DBG1 if(debug==2)printk
#else
-#define tun_debug(level, tun, fmt, args...) \
-do { \
- if (0) \
- netdev_printk(level, tun->dev, fmt, ##args); \
-} while (0)
-#define DBG1(level, fmt, args...) \
-do { \
- if (0) \
- printk(level fmt, ##args); \
-} while (0)
+#define DBG( a... )
+#define DBG1( a... )
#endif
#define FLT_EXACT_COUNT 8
@@ -223,7 +205,7 @@ static void tun_put(struct tun_struct *tun)
tun_detach(tfile->tun);
}
-/* TAP filtering */
+/* TAP filterting */
static void addr_hash_set(u32 *mask, const u8 *addr)
{
int n = ether_crc(ETH_ALEN, addr) >> 26;
@@ -378,7 +360,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
- tun_debug(KERN_INFO, tun, "tun_net_xmit %d\n", skb->len);
+ DBG(KERN_INFO "%s: tun_net_xmit %d\n", tun->dev->name, skb->len);
/* Drop packet if interface is not attached */
if (!tun->tfile)
@@ -517,7 +499,7 @@ static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
sk = tun->socket.sk;
- tun_debug(KERN_INFO, tun, "tun_chr_poll\n");
+ DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);
poll_wait(file, &tun->wq.wait, wait);
@@ -708,7 +690,7 @@ static ssize_t tun_chr_aio_write(struct kiocb *iocb, const struct iovec *iv,
if (!tun)
return -EBADFD;
- tun_debug(KERN_INFO, tun, "tun_chr_write %ld\n", count);
+ DBG(KERN_INFO "%s: tun_chr_write %ld\n", tun->dev->name, count);
result = tun_get_user(tun, iv, iov_length(iv, count),
file->f_flags & O_NONBLOCK);
@@ -757,7 +739,7 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
else if (sinfo->gso_type & SKB_GSO_UDP)
gso.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else {
- pr_err("unexpected GSO type: "
+ printk(KERN_ERR "tun: unexpected GSO type: "
"0x%x, gso_size %d, hdr_len %d\n",
sinfo->gso_type, gso.gso_size,
gso.hdr_len);
@@ -804,7 +786,7 @@ static ssize_t tun_do_read(struct tun_struct *tun,
struct sk_buff *skb;
ssize_t ret = 0;
- tun_debug(KERN_INFO, tun, "tun_chr_read\n");
+ DBG(KERN_INFO "%s: tun_chr_read\n", tun->dev->name);
add_wait_queue(&tun->wq.wait, &wait);
while (len) {
@@ -1101,7 +1083,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) ||
device_create_file(&tun->dev->dev, &dev_attr_owner) ||
device_create_file(&tun->dev->dev, &dev_attr_group))
- pr_err("Failed to create tun sysfs files\n");
+ printk(KERN_ERR "Failed to create tun sysfs files\n");
sk->sk_destruct = tun_sock_destruct;
@@ -1110,7 +1092,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
goto failed;
}
- tun_debug(KERN_INFO, tun, "tun_set_iff\n");
+ DBG(KERN_INFO "%s: tun_set_iff\n", tun->dev->name);
if (ifr->ifr_flags & IFF_NO_PI)
tun->flags |= TUN_NO_PI;
@@ -1147,7 +1129,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
static int tun_get_iff(struct net *net, struct tun_struct *tun,
struct ifreq *ifr)
{
- tun_debug(KERN_INFO, tun, "tun_get_iff\n");
+ DBG(KERN_INFO "%s: tun_get_iff\n", tun->dev->name);
strcpy(ifr->ifr_name, tun->dev->name);
@@ -1247,7 +1229,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
if (!tun)
goto unlock;
- tun_debug(KERN_INFO, tun, "tun_chr_ioctl cmd %d\n", cmd);
+ DBG(KERN_INFO "%s: tun_chr_ioctl cmd %d\n", tun->dev->name, cmd);
ret = 0;
switch (cmd) {
@@ -1267,8 +1249,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
else
tun->flags &= ~TUN_NOCHECKSUM;
- tun_debug(KERN_INFO, tun, "checksum %s\n",
- arg ? "disabled" : "enabled");
+ DBG(KERN_INFO "%s: checksum %s\n",
+ tun->dev->name, arg ? "disabled" : "enabled");
break;
case TUNSETPERSIST:
@@ -1278,34 +1260,33 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
else
tun->flags &= ~TUN_PERSIST;
- tun_debug(KERN_INFO, tun, "persist %s\n",
- arg ? "enabled" : "disabled");
+ DBG(KERN_INFO "%s: persist %s\n",
+ tun->dev->name, arg ? "enabled" : "disabled");
break;
case TUNSETOWNER:
/* Set owner of the device */
tun->owner = (uid_t) arg;
- tun_debug(KERN_INFO, tun, "owner set to %d\n", tun->owner);
+ DBG(KERN_INFO "%s: owner set to %d\n", tun->dev->name, tun->owner);
break;
case TUNSETGROUP:
/* Set group of the device */
tun->group= (gid_t) arg;
- tun_debug(KERN_INFO, tun, "group set to %d\n", tun->group);
+ DBG(KERN_INFO "%s: group set to %d\n", tun->dev->name, tun->group);
break;
case TUNSETLINK:
/* Only allow setting the type when the interface is down */
if (tun->dev->flags & IFF_UP) {
- tun_debug(KERN_INFO, tun,
- "Linktype set failed because interface is up\n");
+ DBG(KERN_INFO "%s: Linktype set failed because interface is up\n",
+ tun->dev->name);
ret = -EBUSY;
} else {
tun->dev->type = (int) arg;
- tun_debug(KERN_INFO, tun, "linktype set to %d\n",
- tun->dev->type);
+ DBG(KERN_INFO "%s: linktype set to %d\n", tun->dev->name, tun->dev->type);
ret = 0;
}
break;
@@ -1337,8 +1318,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
case SIOCSIFHWADDR:
/* Set hw address */
- tun_debug(KERN_DEBUG, tun, "set hw address: %pM\n",
- ifr.ifr_hwaddr.sa_data);
+ DBG(KERN_DEBUG "%s: set hw address: %pM\n",
+ tun->dev->name, ifr.ifr_hwaddr.sa_data);
ret = dev_set_mac_address(tun->dev, &ifr.ifr_hwaddr);
break;
@@ -1452,7 +1433,7 @@ static int tun_chr_fasync(int fd, struct file *file, int on)
if (!tun)
return -EBADFD;
- tun_debug(KERN_INFO, tun, "tun_chr_fasync %d\n", on);
+ DBG(KERN_INFO "%s: tun_chr_fasync %d\n", tun->dev->name, on);
if ((ret = fasync_helper(fd, file, on, &tun->fasync)) < 0)
goto out;
@@ -1474,7 +1455,7 @@ static int tun_chr_open(struct inode *inode, struct file * file)
{
struct tun_file *tfile;
- DBG1(KERN_INFO, "tunX: tun_chr_open\n");
+ DBG1(KERN_INFO "tunX: tun_chr_open\n");
tfile = kmalloc(sizeof(*tfile), GFP_KERNEL);
if (!tfile)
@@ -1495,7 +1476,7 @@ static int tun_chr_close(struct inode *inode, struct file *file)
if (tun) {
struct net_device *dev = tun->dev;
- tun_debug(KERN_INFO, tun, "tun_chr_close\n");
+ DBG(KERN_INFO "%s: tun_chr_close\n", dev->name);
__tun_detach(tun);
@@ -1626,18 +1607,18 @@ static int __init tun_init(void)
{
int ret = 0;
- pr_info("%s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
- pr_info("%s\n", DRV_COPYRIGHT);
+ printk(KERN_INFO "tun: %s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
+ printk(KERN_INFO "tun: %s\n", DRV_COPYRIGHT);
ret = rtnl_link_register(&tun_link_ops);
if (ret) {
- pr_err("Can't register link_ops\n");
+ printk(KERN_ERR "tun: Can't register link_ops\n");
goto err_linkops;
}
ret = misc_register(&tun_miscdev);
if (ret) {
- pr_err("Can't register misc device %d\n", TUN_MINOR);
+ printk(KERN_ERR "tun: Can't register misc device %d\n", TUN_MINOR);
goto err_misc;
}
return 0;
--
1.7.4.2.g597a6.dirty
^ permalink raw reply related
* [PATCH 1/3] tun: Convert logging messages to pr_<level> and tun_debug
From: Joe Perches @ 2011-03-02 17:18 UTC (permalink / raw)
To: netdev
Use the current logging forms with pr_fmt.
Convert DBG macro to tun_debug, use netdev_printk as well.
Add printf verification when TUN_DEBUG not defined.
Miscellaneous comment typo fix.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/tun.c | 83 ++++++++++++++++++++++++++++++++--------------------
1 files changed, 51 insertions(+), 32 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 55786a0..f5e9ac0 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -34,6 +34,8 @@
* Modifications for 2.3.99-pre5 kernel.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#define DRV_NAME "tun"
#define DRV_VERSION "1.6"
#define DRV_DESCRIPTION "Universal TUN/TAP device driver"
@@ -76,11 +78,27 @@
#ifdef TUN_DEBUG
static int debug;
-#define DBG if(tun->debug)printk
-#define DBG1 if(debug==2)printk
+#define tun_debug(level, tun, fmt, args...) \
+do { \
+ if (tun->debug) \
+ netdev_printk(level, tun->dev, fmt, ##args); \
+} while (0)
+#define DBG1(level, fmt, args...) \
+do { \
+ if (debug == 2) \
+ printk(level fmt, ##args); \
+} while (0)
#else
-#define DBG( a... )
-#define DBG1( a... )
+#define tun_debug(level, tun, fmt, args...) \
+do { \
+ if (0) \
+ netdev_printk(level, tun->dev, fmt, ##args); \
+} while (0)
+#define DBG1(level, fmt, args...) \
+do { \
+ if (0) \
+ printk(level fmt, ##args); \
+} while (0)
#endif
#define FLT_EXACT_COUNT 8
@@ -205,7 +223,7 @@ static void tun_put(struct tun_struct *tun)
tun_detach(tfile->tun);
}
-/* TAP filterting */
+/* TAP filtering */
static void addr_hash_set(u32 *mask, const u8 *addr)
{
int n = ether_crc(ETH_ALEN, addr) >> 26;
@@ -360,7 +378,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
- DBG(KERN_INFO "%s: tun_net_xmit %d\n", tun->dev->name, skb->len);
+ tun_debug(KERN_INFO, tun, "tun_net_xmit %d\n", skb->len);
/* Drop packet if interface is not attached */
if (!tun->tfile)
@@ -499,7 +517,7 @@ static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
sk = tun->socket.sk;
- DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);
+ tun_debug(KERN_INFO, tun, "tun_chr_poll\n");
poll_wait(file, &tun->wq.wait, wait);
@@ -690,7 +708,7 @@ static ssize_t tun_chr_aio_write(struct kiocb *iocb, const struct iovec *iv,
if (!tun)
return -EBADFD;
- DBG(KERN_INFO "%s: tun_chr_write %ld\n", tun->dev->name, count);
+ tun_debug(KERN_INFO, tun, "tun_chr_write %ld\n", count);
result = tun_get_user(tun, iv, iov_length(iv, count),
file->f_flags & O_NONBLOCK);
@@ -739,7 +757,7 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
else if (sinfo->gso_type & SKB_GSO_UDP)
gso.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else {
- printk(KERN_ERR "tun: unexpected GSO type: "
+ pr_err("unexpected GSO type: "
"0x%x, gso_size %d, hdr_len %d\n",
sinfo->gso_type, gso.gso_size,
gso.hdr_len);
@@ -786,7 +804,7 @@ static ssize_t tun_do_read(struct tun_struct *tun,
struct sk_buff *skb;
ssize_t ret = 0;
- DBG(KERN_INFO "%s: tun_chr_read\n", tun->dev->name);
+ tun_debug(KERN_INFO, tun, "tun_chr_read\n");
add_wait_queue(&tun->wq.wait, &wait);
while (len) {
@@ -1083,7 +1101,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) ||
device_create_file(&tun->dev->dev, &dev_attr_owner) ||
device_create_file(&tun->dev->dev, &dev_attr_group))
- printk(KERN_ERR "Failed to create tun sysfs files\n");
+ pr_err("Failed to create tun sysfs files\n");
sk->sk_destruct = tun_sock_destruct;
@@ -1092,7 +1110,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
goto failed;
}
- DBG(KERN_INFO "%s: tun_set_iff\n", tun->dev->name);
+ tun_debug(KERN_INFO, tun, "tun_set_iff\n");
if (ifr->ifr_flags & IFF_NO_PI)
tun->flags |= TUN_NO_PI;
@@ -1129,7 +1147,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
static int tun_get_iff(struct net *net, struct tun_struct *tun,
struct ifreq *ifr)
{
- DBG(KERN_INFO "%s: tun_get_iff\n", tun->dev->name);
+ tun_debug(KERN_INFO, tun, "tun_get_iff\n");
strcpy(ifr->ifr_name, tun->dev->name);
@@ -1229,7 +1247,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
if (!tun)
goto unlock;
- DBG(KERN_INFO "%s: tun_chr_ioctl cmd %d\n", tun->dev->name, cmd);
+ tun_debug(KERN_INFO, tun, "tun_chr_ioctl cmd %d\n", cmd);
ret = 0;
switch (cmd) {
@@ -1249,8 +1267,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
else
tun->flags &= ~TUN_NOCHECKSUM;
- DBG(KERN_INFO "%s: checksum %s\n",
- tun->dev->name, arg ? "disabled" : "enabled");
+ tun_debug(KERN_INFO, tun, "checksum %s\n",
+ arg ? "disabled" : "enabled");
break;
case TUNSETPERSIST:
@@ -1260,33 +1278,34 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
else
tun->flags &= ~TUN_PERSIST;
- DBG(KERN_INFO "%s: persist %s\n",
- tun->dev->name, arg ? "enabled" : "disabled");
+ tun_debug(KERN_INFO, tun, "persist %s\n",
+ arg ? "enabled" : "disabled");
break;
case TUNSETOWNER:
/* Set owner of the device */
tun->owner = (uid_t) arg;
- DBG(KERN_INFO "%s: owner set to %d\n", tun->dev->name, tun->owner);
+ tun_debug(KERN_INFO, tun, "owner set to %d\n", tun->owner);
break;
case TUNSETGROUP:
/* Set group of the device */
tun->group= (gid_t) arg;
- DBG(KERN_INFO "%s: group set to %d\n", tun->dev->name, tun->group);
+ tun_debug(KERN_INFO, tun, "group set to %d\n", tun->group);
break;
case TUNSETLINK:
/* Only allow setting the type when the interface is down */
if (tun->dev->flags & IFF_UP) {
- DBG(KERN_INFO "%s: Linktype set failed because interface is up\n",
- tun->dev->name);
+ tun_debug(KERN_INFO, tun,
+ "Linktype set failed because interface is up\n");
ret = -EBUSY;
} else {
tun->dev->type = (int) arg;
- DBG(KERN_INFO "%s: linktype set to %d\n", tun->dev->name, tun->dev->type);
+ tun_debug(KERN_INFO, tun, "linktype set to %d\n",
+ tun->dev->type);
ret = 0;
}
break;
@@ -1318,8 +1337,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
case SIOCSIFHWADDR:
/* Set hw address */
- DBG(KERN_DEBUG "%s: set hw address: %pM\n",
- tun->dev->name, ifr.ifr_hwaddr.sa_data);
+ tun_debug(KERN_DEBUG, tun, "set hw address: %pM\n",
+ ifr.ifr_hwaddr.sa_data);
ret = dev_set_mac_address(tun->dev, &ifr.ifr_hwaddr);
break;
@@ -1433,7 +1452,7 @@ static int tun_chr_fasync(int fd, struct file *file, int on)
if (!tun)
return -EBADFD;
- DBG(KERN_INFO "%s: tun_chr_fasync %d\n", tun->dev->name, on);
+ tun_debug(KERN_INFO, tun, "tun_chr_fasync %d\n", on);
if ((ret = fasync_helper(fd, file, on, &tun->fasync)) < 0)
goto out;
@@ -1455,7 +1474,7 @@ static int tun_chr_open(struct inode *inode, struct file * file)
{
struct tun_file *tfile;
- DBG1(KERN_INFO "tunX: tun_chr_open\n");
+ DBG1(KERN_INFO, "tunX: tun_chr_open\n");
tfile = kmalloc(sizeof(*tfile), GFP_KERNEL);
if (!tfile)
@@ -1476,7 +1495,7 @@ static int tun_chr_close(struct inode *inode, struct file *file)
if (tun) {
struct net_device *dev = tun->dev;
- DBG(KERN_INFO "%s: tun_chr_close\n", dev->name);
+ tun_debug(KERN_INFO, tun, "tun_chr_close\n");
__tun_detach(tun);
@@ -1607,18 +1626,18 @@ static int __init tun_init(void)
{
int ret = 0;
- printk(KERN_INFO "tun: %s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
- printk(KERN_INFO "tun: %s\n", DRV_COPYRIGHT);
+ pr_info("%s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
+ pr_info("%s\n", DRV_COPYRIGHT);
ret = rtnl_link_register(&tun_link_ops);
if (ret) {
- printk(KERN_ERR "tun: Can't register link_ops\n");
+ pr_err("Can't register link_ops\n");
goto err_linkops;
}
ret = misc_register(&tun_miscdev);
if (ret) {
- printk(KERN_ERR "tun: Can't register misc device %d\n", TUN_MINOR);
+ pr_err("Can't register misc device %d\n", TUN_MINOR);
goto err_misc;
}
return 0;
--
1.7.4.2.g597a6.dirty
^ permalink raw reply related
* [PATCH 3/3] eql: Convert printks to pr_<level> and netdev_<level>
From: Joe Perches @ 2011-03-02 17:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <7f33dcacd277e127208211d8c3ef11c992408628.1299086044.git.joe@perches.com>
Add pr_fmt
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/eql.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/eql.c b/drivers/net/eql.c
index 0cb1cf9..ffda358 100644
--- a/drivers/net/eql.c
+++ b/drivers/net/eql.c
@@ -111,6 +111,8 @@
* Sorry, I had to rewrite most of this for 2.5.x -DaveM
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/capability.h>
#include <linux/module.h>
#include <linux/kernel.h>
@@ -204,8 +206,8 @@ static int eql_open(struct net_device *dev)
equalizer_t *eql = netdev_priv(dev);
/* XXX We should force this off automatically for the user. */
- printk(KERN_INFO "%s: remember to turn off Van-Jacobson compression on "
- "your slave devices.\n", dev->name);
+ netdev_info(dev,
+ "remember to turn off Van-Jacobson compression on your slave devices\n");
BUG_ON(!list_empty(&eql->queue.all_slaves));
@@ -591,7 +593,7 @@ static int __init eql_init_module(void)
{
int err;
- printk(version);
+ pr_info(version);
dev_eql = alloc_netdev(sizeof(equalizer_t), "eql", eql_setup);
if (!dev_eql)
--
1.7.4.2.g597a6.dirty
^ permalink raw reply related
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-02 17:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Fabio Checconi, David Miller, Luigi Rizzo, netdev
In-Reply-To: <1299082728.2920.18.camel@edumazet-laptop>
Le mercredi 02 mars 2011 à 17:18 +0100, Eric Dumazet a écrit :
> Le mercredi 02 mars 2011 à 08:11 -0800, Stephen Hemminger a écrit :
>
> > I put the iproute2 code into the repository in the experimental branch.
> >
>
> Thanks
>
> It seems as soon as packets are dropped, qdisc is frozen (no more
> packets dequeued)
>
> Hmm...
>
It seems class deletes are buggy.
After one "tc class del dev $ETH classid 11:1 ..."
a "tc -s -d qdisc show dev $ETH" triggers an Oops
[ 414.517709] general protection fault: 0000 [#1] SMP
[ 414.517894] last sysfs file: /sys/devices/virtual/net/gre34/ifindex
[ 414.517956] CPU 3
[ 414.517995] Modules linked in: sch_qfq sch_cbq ip_gre gre dummy ipmi_devintf ipmi_si ipmi_msghandler dm_mod video tg3 libphy sg [last unloaded: ip_tables]
[ 414.518663]
[ 414.518717] Pid: 4692, comm: tc Not tainted 2.6.38-rc5-02726-gd486b8c-dirty #554 HP ProLiant BL460c G6
[ 414.518905] RIP: 0010:[<ffffffff8145118e>] [<ffffffff8145118e>] tc_fill_qdisc+0xbe/0x300
[ 414.519025] RSP: 0018:ffff88011a123878 EFLAGS: 00010283
[ 414.519085] RAX: a00e6660ffffffff RBX: 0000000000000002 RCX: 0000000000000024
[ 414.519149] RDX: ffff880078683334 RSI: 0000000000000000 RDI: ffff88007867b400
[ 414.519212] RBP: ffff88011a123928 R08: ffff880078683000 R09: 0000000000000002
[ 414.519276] R10: 00000000000001f0 R11: 00000000000001e0 R12: ffff88007867b400
[ 414.519340] R13: ffff88011cb1779c R14: ffff880078683324 R15: 0000000000001254
[ 414.519405] FS: 0000000000000000(0000) GS:ffff88007fc40000(0063) knlGS:00000000f77778e0
[ 414.519486] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 414.519553] CR2: 00000000005ffc80 CR3: 0000000078087000 CR4: 00000000000006e0
[ 414.519616] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 414.519680] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 414.519744] Process tc (pid: 4692, threadinfo ffff88011a122000, task ffff88011a1715d0)
[ 414.519823] Stack:
[ 414.519876] ffff88011bbfb570 000000004d6e7c8e ffff880078683324 0000000000000000
[ 414.520095] ffff88011cb1789c ffff88007867b400 ffff8800786832bc 0000000400000003
[ 414.520312] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 414.520531] Call Trace:
[ 414.520602] [<ffffffff81451469>] tc_dump_qdisc_root+0x99/0x100
[ 414.520666] [<ffffffff81452680>] tc_dump_qdisc+0x80/0x100
[ 414.520729] [<ffffffff8146a50b>] netlink_dump+0x6b/0x1e0
[ 414.520791] [<ffffffff810f5d16>] ? kmem_cache_alloc_trace+0xb6/0x100
[ 414.520855] [<ffffffff8146d2ef>] netlink_dump_start+0x16f/0x190
[ 414.520918] [<ffffffff81452600>] ? tc_dump_qdisc+0x0/0x100
[ 414.520981] [<ffffffff81443b36>] rtnetlink_rcv_msg+0xb6/0x270
[ 414.521043] [<ffffffff81443a80>] ? rtnetlink_rcv_msg+0x0/0x270
[ 414.521106] [<ffffffff8146b609>] netlink_rcv_skb+0x99/0xc0
[ 414.521167] [<ffffffff81443a65>] rtnetlink_rcv+0x25/0x40
[ 414.521229] [<ffffffff8146b379>] netlink_unicast+0x2a9/0x2b0
[ 414.521292] [<ffffffff8142c3e3>] ? memcpy_fromiovec+0x63/0x80
[ 414.521354] [<ffffffff8146c30d>] netlink_sendmsg+0x24d/0x390
[ 414.521418] [<ffffffff81421510>] sock_sendmsg+0xc0/0xf0
[ 414.521482] [<ffffffff810b699a>] ? unlock_page+0x2a/0x40
[ 414.521545] [<ffffffff81421262>] ? move_addr_to_kernel+0x62/0x70
[ 414.521608] [<ffffffff8144d59f>] ? verify_compat_iovec+0x8f/0x100
[ 414.521685] [<ffffffff814222b0>] sys_sendmsg+0x180/0x300
[ 414.521747] [<ffffffff810d682c>] ? __pte_alloc+0xdc/0x100
[ 414.521809] [<ffffffff810d6992>] ? handle_mm_fault+0x142/0x1c0
[ 414.521872] [<ffffffff81569594>] ? do_page_fault+0x274/0x490
[ 414.521935] [<ffffffff81421f41>] ? sys_getsockname+0xa1/0xb0
[ 414.521997] [<ffffffff81421909>] ? sys_recvmsg+0x49/0x80
[ 414.522059] [<ffffffff8144d164>] compat_sys_sendmsg+0x14/0x20
[ 414.522121] [<ffffffff8144e08d>] compat_sys_socketcall+0x19d/0x1f0
[ 414.522185] [<ffffffff8102d640>] sysenter_dispatch+0x7/0x2e
[ 414.522246] Code: 06 49 8d 56 10 45 89 7e 0c 66 41 89 46 04 8b 85 58 ff ff ff 41 c6 46 10 00 41 89 46 08 c6 42 01 00 66 c7 42 02 00 00 49 8b 45 68 <48> 8b 00 8b 80 c0 00 00 00 89 42 04 8b 85 5c ff ff ff 89 42 0c
[ 414.524636] RIP [<ffffffff8145118e>] tc_fill_qdisc+0xbe/0x300
[ 414.524734] RSP <ffff88011a123878>
[ 414.524799] ---[ end trace 513a4307e5c34d00 ]---
^ permalink raw reply
* Re: [PATCH (sh-2.6) 1/4] clksource: Generic timer infrastructure
From: Peppe CAVALLARO @ 2011-03-02 17:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Stuart MENEFY, Arnd Bergmann, linux-sh@vger.kernel.org,
netdev@vger.kernel.org, John Stultz, linux-kernel@vger.kernel.org,
linux@arm.linux.org.uk
In-Reply-To: <alpine.LFD.2.00.1103011630080.2701@localhost6.localdomain6>
Hello and many thanks to All for your feedback.
On 3/1/2011 5:48 PM, Thomas Gleixner wrote:
>
> On Tue, 1 Mar 2011, Stuart Menefy wrote:
> > On 24/02/11 17:20, Arnd Bergmann wrote:
> > > On Tuesday 22 February 2011, Peppe CAVALLARO wrote:
> > >> From: Stuart Menefy <stuart.menefy@st.com>
> > >>
> > >> Many devices targeted at the embedded market provide a number of
> > >> generic timers which are capable of generating interrupts at a
> > >> requested rate. These can then be used in the implementation of
> drivers
> > >> for other peripherals which require a timer interrupt, without having
> > >> to provide an additional timer as part of that peripheral.
>
> Why can't you just use an hrtimer and be done with it? Just because
> there is some extra hardware in the chip?
>
> > If anything this duplicates clockevents. The main reason for not using
> > clockevents was that nobody else does! Currently clockevents are
> > used strictly for time keeping within the kernel, and most architectures
> > only register those which are intended to be used for this purpose.
> > We felt a bit nervous about adding code to register all the device's
> timers
> > as clockevents, and having the network device driver pick up one of
> those
> > for its own use.
>
> We had this discussion before and there was never an real outcome as
> it turned out that hrtimers provide enough abstraction for this kind
> of problems.
>
> > True. The intent was that this would be a third interface onto timer
> > hardware, alongside clocksources and clockevents.
> >
> > > I don't know if this could also be merged with the clocksource
> infrastructure,
> > > but your code currently doesn't do that.
> >
> > It would probably be clockevent rather than clocksource, but it
> could be if
> > people felt that was a better way to go.
>
> If we get some reasonable explanation why an extra timer interrupt is
> solving a specific problem better than hrtimers we can do that, but
> that needs more thought than picking the first available clockevent
> from a list. If we come to the conclusion, that we want/need this kind
> of functionality then I really prefer not to create yet another piece
> of infrastructure which deals with timer devices.
>
The initial/main usage of this code was to provide
an interrupt timer to handle the rx/tx processes in
the stmmac Ethernet d.d.
Some Ethernet devices have embedded timer
used for mitigating the number of their DMA interrupts.
So, to be frankly, my first idea was to use an
extra HW (SH4 TMU channel 2), unused on our platforms,
because our MAC hadn't something like that.
I'm not sure if other Ethernet drivers use hrtimer for
handling the whole rx/tx processes (on CC the net-2.6 ML:
please correct me if I'm wrong) and if this could have
impact on the performances or reliability of the network
activity (pkt loss%).
At any rate, I am happy to use the stmmac as experimental
driver to do this kind tests.
Indeed, in the past, on old Kernel (IIRC 2.6.23), I tried to use
the kernel timers but I removed the code from it because
I had noticed packets loss and a strange phenomenon with cyclesoak
(that showed broken sysload % during the heavy network activities).
Let me know how to proceed:
1) experiment with stmmac and hrtimer for handling rx/tx?
2) rework the patches for the Generic Timer Infra?
Best Regards,
Peppe
> Thanks,
>
> tglx
>
^ permalink raw reply
* Re: skb->frag_list != NULL in start_xmit for device without NETIF_F_FRAGLIST
From: Ian Campbell @ 2011-03-02 17:42 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev@vger.kernel.org, Paul Durrant, dev
In-Reply-To: <1299071683.17907.1764.camel@zakaz.uk.xensource.com>
On Wed, 2011-03-02 at 13:14 +0000, Ian Campbell wrote:
> On Wed, 2011-03-02 at 13:12 +0000, Ian Campbell wrote:
> >
> > > I believe that not much has changed in this regard between 2.6.32
> > and net-next.
> >
> > It turns out I cannot reproduce with either 2.6.32 (pvops xen.git) or
> > a more recent ((26.38-rc) kernel. The kernel where we see this is the
> > XCP kernel which is a 2.6.32 based thing derived from SLES11SP1 + XCP
> > specific updates.
>
> Paul reminded me that his XCP system where we see this is running
> openvswitch not bridging (all my own tests were with bridging), is this
> something which could be caused by vswitch at all? I don't see any
> interesting ->frag_list usage in openvswitch.git.
>
> Anyway I'm going to see if I can repro with vswitch.
It seems that was the key.
Using openvswitch.git aae3743bf24cd0e14be726c774a0be49ff0459d7 on top of
2.6.38-rc7 (+ some Xen stuff from linux-next and my netback branch). I
added:
WARN_ONCE(skb_shinfo(skb)->frag_list, "skb %p has a frag list\n", skb)
to netback's start_xmit and saw it trigger (full trace below).
I've added ovs-dev, you guys can see the complete thread at
http://thread.gmane.org/gmane.linux.network/187720 . The gist is that we
are seeing skb's passed to a driver's start_xmit which have a
->frag_list despite not advertising NETIF_F_FRAGLIST. The netback device
has GSO but not TSO enabled.
(aae3743bf24cd0e14be726c774a0be49ff0459d7 is from the end of January but
it does appear to be the current master, I guess it's a recently rebased
+pushed old commit).
Cheers,
Ian.
------------[ cut here ]------------
WARNING: at /local/scratch/ianc/devel/kernels/linux-2.6/drivers/net/xen-netback/interface.c:84 xenvif_start_xmit+0x109/0x120()
Hardware name: PowerEdge 860
skb cfa14c80 has a frag list
Modules linked in: openvswitch_mod
Pid: 0, comm: swapper Not tainted 2.6.38-rc7-x86_32p-xen0-00190-g0716c28-dirty #375
Call Trace:
[<c12bfbf9>] ? xenvif_start_xmit+0x109/0x120
[<c103f17c>] ? warn_slowpath_common+0x6c/0xa0
[<c12bfbf9>] ? xenvif_start_xmit+0x109/0x120
[<c103f22e>] ? warn_slowpath_fmt+0x2e/0x30
[<c12bfbf9>] ? xenvif_start_xmit+0x109/0x120
[<c13500d4>] ? dev_hard_start_xmit+0x2c4/0x5a0
[<c134fe58>] ? dev_hard_start_xmit+0x48/0x5a0
[<c13639ec>] ? sch_direct_xmit+0x12c/0x230
[<c142be5a>] ? _raw_spin_lock+0x3a/0x40
[<c13505de>] ? dev_queue_xmit+0x22e/0x7a0
[<c13503b0>] ? dev_queue_xmit+0x0/0x7a0
[<f8c77ab7>] ? netdev_send+0x17/0x20 [openvswitch_mod]
[<f8c755a0>] ? vport_send+0x40/0x100 [openvswitch_mod]
[<c100790a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c10080f0>] ? xen_restore_fl_direct+0x0/0x17
[<f8c6d70b>] ? execute_actions+0x62b/0x7f0 [openvswitch_mod]
[<c106b0d2>] ? mark_held_locks+0x62/0x80
[<c106b3f2>] ? trace_hardirqs_on_caller+0xa2/0x1f0
[<f8c726b3>] ? flow_used+0x63/0x90 [openvswitch_mod]
[<c1044fb4>] ? local_bh_enable_ip+0xa4/0x110
[<c142c5b5>] ? _raw_spin_unlock_bh+0x25/0x30
[<f8c726b3>] ? flow_used+0x63/0x90 [openvswitch_mod]
[<f8c6f0aa>] ? dp_process_received_packet+0x8a/0x200 [openvswitch_mod]
[<c10450b6>] ? local_bh_enable+0x96/0x110
[<c106b3f2>] ? trace_hardirqs_on_caller+0xa2/0x1f0
[<f8c756ec>] ? vport_receive+0x8c/0xa0 [openvswitch_mod]
[<f8c756a7>] ? vport_receive+0x47/0xa0 [openvswitch_mod]
[<f8c77bcf>] ? netdev_frame_hook+0xaf/0xe0 [openvswitch_mod]
[<c134dff5>] ? __netif_receive_skb+0x185/0x340
[<c134dee2>] ? __netif_receive_skb+0x72/0x340
[<c1008114>] ? check_events+0x8/0xc
[<f8c77b20>] ? netdev_frame_hook+0x0/0xe0 [openvswitch_mod]
[<c134edbb>] ? netif_receive_skb+0xcb/0xe0
[<c134ed0a>] ? netif_receive_skb+0x1a/0xe0
[<c134ef0f>] ? napi_gro_complete+0x3f/0x110
[<c134ef18>] ? napi_gro_complete+0x48/0x110
[<c134f140>] ? dev_gro_receive+0x160/0x280
[<c134f057>] ? dev_gro_receive+0x77/0x280
[<c134f41b>] ? napi_gro_receive+0xcb/0xe0
[<c12aae75>] ? tg3_poll_work+0x5e5/0xda0
[<c106b0d2>] ? mark_held_locks+0x62/0x80
[<c100790a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c100790a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c10080f0>] ? xen_restore_fl_direct+0x0/0x17
[<c1008114>] ? check_events+0x8/0xc
[<c100810b>] ? xen_restore_fl_direct_end+0x0/0x1
[<c100790a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c10080f0>] ? xen_restore_fl_direct+0x0/0x17
[<c11d08f0>] ? xen_swiotlb_unmap_page+0x0/0x20
[<c142c5f1>] ? _raw_spin_unlock_irq+0x31/0x40
[<c12ab714>] ? tg3_poll+0x44/0x1d0
[<c134f5fc>] ? net_rx_action+0xcc/0x1a0
[<c134f5fc>] ? net_rx_action+0xcc/0x1a0
[<c1044dbf>] ? __do_softirq+0x9f/0x170
[<c1044d20>] ? __do_softirq+0x0/0x170
<IRQ> [<c1003640>] ? xen_cpuid+0x0/0xa0
[<c1044b45>] ? irq_exit+0x65/0x90
[<c11c5800>] ? xen_evtchn_do_upcall+0x20/0x30
[<c100bc2f>] ? xen_do_upcall+0x7/0xc
[<c1003640>] ? xen_cpuid+0x0/0xa0
[<c10023a7>] ? hypercall_page+0x3a7/0x1010
[<c10079f2>] ? xen_safe_halt+0x12/0x30
[<c1003640>] ? xen_cpuid+0x0/0xa0
[<c1012d30>] ? default_idle+0x40/0xa0
[<c100a769>] ? cpu_idle+0x59/0xa0
[<c1408d71>] ? rest_init+0xa1/0xb0
[<c1408cd0>] ? rest_init+0x0/0xb0
[<c10080e0>] ? xen_save_fl_direct+0x0/0xd
[<c1613a25>] ? start_kernel+0x37c/0x399
[<c1613467>] ? unknown_bootoption+0x0/0x1f1
[<c16130b7>] ? i386_start_kernel+0xa6/0xe2
[<c161676a>] ? xen_start_kernel+0x5fc/0x6b2
---[ end trace 877717720328b880 ]---
^ permalink raw reply
* Re: [PATCH] via-rhine: do not abort due to invalid MAC address
From: Florian Fainelli @ 2011-03-02 18:01 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev, David S. Miller, Alex G.
In-Reply-To: <20110302163233.GA14491@core.hellgate.ch>
Hello,
On Wednesday 02 March 2011 17:32:33 Roger Luethi wrote:
> From: "Alex G." <mr.nuke.me@gmail.com>
>
> via-rhine drops out of the init code if the hardware provides an invalid
> MAC address. I have several reports of Rhine NICs doing just that. The
> hardware still works, though; continuing the init process gives the user a
> chance to fix the MAC address using "ifconfig ethX hw ether" which appears
> to result in a perfectly useable network adapter.
>
> Most recent report and patch provided by Alex G.
>
> Signed-off-by: "Alex G." <mr.nuke.me@gmail.com>
> Signed-off-by: Roger Luethi <rl@hellgate.ch>
>
> diff --git a/linux-2.6.35.11/drivers/net/via-rhine.c b/via-rhine.c
> index 4930f9d..a1189f4 100644
> --- a/linux-2.6.35.11/drivers/net/via-rhine.c
> +++ b/via-rhine.c
> @@ -766,8 +766,12 @@ static int __devinit rhine_init_one(struct pci_dev
> *pdev,
>
> if (!is_valid_ether_addr(dev->perm_addr)) {
> rc = -EIO;
> - printk(KERN_ERR "Invalid MAC address\n");
> - goto err_out_unmap;
> + printk(KERN_ERR "via-rhine: invalid MAC address: %pM. "
> + "Use ifconfig to configure valid address.\n",
> + dev->dev_addr);
> + /* The device may still be used normally if a valid MAC is
configured
> + * We do not consider this a fatal error, and continue
initialization
> + */
> }
Why not generate a valid random ethernet address using random_ether_addr()
instead?
--
Florian
^ permalink raw reply
* Re: [Lxc-users] Bad checksums and lost packets with macvlan on dummy
From: Patrick McHardy @ 2011-03-02 18:03 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: Eric Dumazet, Andrian Nord, lxc-users, Linux Netdev List
In-Reply-To: <4D6E6A55.6000607@free.fr>
Am 02.03.2011 17:03, schrieb Daniel Lezcano:
> On 03/02/2011 12:03 PM, Patrick McHardy wrote:
>> Am 01.03.2011 21:04, schrieb Daniel Lezcano:
>>> On 03/01/2011 05:51 PM, Patrick McHardy wrote:
>>>>> Patrick, do you have any suggestions to fix this ?
>>>> Since the frames are only looped back locally, I suppose the easiest
>>>> fix would be to mark them with CHECKSUM_UNNECESSARY. Alternatively
>>>> we need to complete the checksum manually, similar to what
>>>> dev_hard_start_xmit() does.
>>> That sounds very simple to fix, maybe too much simple :)
>>>
>>> I did the following change:
>>>
>>> --- linux-next.orig/drivers/net/macvlan.c
>>> +++ linux-next/drivers/net/macvlan.c
>>> @@ -222,6 +222,7 @@ static int macvlan_queue_xmit(struct sk_
>>>
>>> if (vlan->mode == MACVLAN_MODE_BRIDGE) {
>>> const struct ethhdr *eth = (void *)skb->data;
>>> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>>>
>>> /* send to other bridge ports directly */
>>> if (is_multicast_ether_addr(eth->h_dest)) {
>>>
>>>
>>> and that fixed the problem. Do you think it is acceptable ?
>> The only problem I see is if the packets are bridged to a
>> different networking device (or redirected using the mirred
>> action), in this case the checksum will not be completed.
>> This would be a very strange setup though and probably wouldn't
>> be using dummy as lower device, so I'm not sure we have to
>> worry about this case.
>
> I am not sure to get it, do you say the patch is correct ?
Its correct with a short-coming that doesn't seem to matter.
> If my understanding is correct, the packet will be flagged
> CHECKSUM_UNNECESSARY only for the macvlan devices, right ?
Only for packets bridged between macvlan devices. A setup like
the following would cause problems:
br0
|
.----------.
| |
macvlan0 macvlan1 eth0
| |
-------.-------
dummy0
In this case packets sent from macvlan0 will show up on
eth0 with incorrect setups. However this setup doesn't
seem realistic to me, you would simply use eth0 instead
of dummy0.
> By the way, this problem occurs for any lower device with offloading
> capabilities with a macvlan port in bridge mode.
True. This doesn't affect outgoing packets since their checksum
will be completed in dev_hard_start_xmit(), but it affects
packets bridged between macvlans.
As I said, the full solution would be to complete the checksum
for CHECKSUM_PARTIAL packets when bridging between macvlans.
^ permalink raw reply
* [PATCH] iproute2: add support of flag XFRM_STATE_ALIGN4
From: Nicolas Dichtel @ 2011-03-02 18:08 UTC (permalink / raw)
To: Stephen Hemminger, netdev
[-- Attachment #1: Type: text/plain, Size: 56 bytes --]
Hi,
please find the patch enclosed.
Regards,
Nicolas
[-- Attachment #2: 0001-iproute2-add-support-of-flag-XFRM_STATE_ALIGN4.patch --]
[-- Type: text/x-patch, Size: 1850 bytes --]
>From 61fafffaa53ac1bcf1a2a93e6637517c4eb2ac93 Mon Sep 17 00:00:00 2001
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 1 Feb 2011 07:29:54 -0500
Subject: [PATCH] iproute2: add support of flag XFRM_STATE_ALIGN4
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
ip/ipxfrm.c | 1 +
ip/xfrm_state.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/ip/ipxfrm.c b/ip/ipxfrm.c
index a276c0b..0c7aaad 100644
--- a/ip/ipxfrm.c
+++ b/ip/ipxfrm.c
@@ -854,6 +854,7 @@ void xfrm_state_info_print(struct xfrm_usersa_info *xsinfo,
XFRM_FLAG_PRINT(fp, flags, XFRM_STATE_WILDRECV, "wildrecv");
XFRM_FLAG_PRINT(fp, flags, XFRM_STATE_ICMP, "icmp");
XFRM_FLAG_PRINT(fp, flags, XFRM_STATE_AF_UNSPEC, "af-unspec");
+ XFRM_FLAG_PRINT(fp, flags, XFRM_STATE_ALIGN4, "align4");
if (flags)
fprintf(fp, "%x", flags);
}
diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
index 94acd66..8ac3437 100644
--- a/ip/xfrm_state.c
+++ b/ip/xfrm_state.c
@@ -84,7 +84,7 @@ static void usage(void)
//fprintf(stderr, "REQID - number(default=0)\n");
fprintf(stderr, "FLAG-LIST := [ FLAG-LIST ] FLAG\n");
- fprintf(stderr, "FLAG := [ noecn | decap-dscp | nopmtudisc | wildrecv | icmp | af-unspec ]\n");
+ fprintf(stderr, "FLAG := [ noecn | decap-dscp | nopmtudisc | wildrecv | icmp | af-unspec | align4 ]\n");
fprintf(stderr, "ENCAP := ENCAP-TYPE SPORT DPORT OADDR\n");
fprintf(stderr, "ENCAP-TYPE := espinudp | espinudp-nonike\n");
@@ -216,6 +216,8 @@ static int xfrm_state_flag_parse(__u8 *flags, int *argcp, char ***argvp)
*flags |= XFRM_STATE_ICMP;
else if (strcmp(*argv, "af-unspec") == 0)
*flags |= XFRM_STATE_AF_UNSPEC;
+ else if (strcmp(*argv, "align4") == 0)
+ *flags |= XFRM_STATE_ALIGN4;
else {
PREV_ARG(); /* back track */
break;
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] via-rhine: do not abort due to invalid MAC address
From: Alex G. @ 2011-03-02 18:11 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Roger Luethi, netdev, David S. Miller
In-Reply-To: <201103021901.39849.florian@openwrt.org>
On 03/02/2011 08:01 PM, Florian Fainelli wrote:
>
> Why not generate a valid random ethernet address using random_ether_addr()
> instead?
That would confuse ifcfg-* scripts that specify HWETHER, and probably
users as well. It might even stump udev.
An "ifconfig ethX hw ether xx:xx:xx:xx:xx:xx" in network scripts allows
udev to use the consistent "bad" MAC to assign a consistent ethX number,
and allows the networking scripts to use the consistent "new good" MAC.
It works as a stand-alone interface, as a WAN port hosting ppp0, and
even in bonding, all consistently.
Alex
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Patrick McHardy @ 2011-03-02 18:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, Fabio Checconi, David Miller, Luigi Rizzo,
netdev
In-Reply-To: <1299087087.2920.27.camel@edumazet-laptop>
Am 02.03.2011 18:31, schrieb Eric Dumazet:
> Le mercredi 02 mars 2011 à 17:18 +0100, Eric Dumazet a écrit :
>> Le mercredi 02 mars 2011 à 08:11 -0800, Stephen Hemminger a écrit :
>>
>>> I put the iproute2 code into the repository in the experimental branch.
>>>
>>
>> Thanks
>>
>> It seems as soon as packets are dropped, qdisc is frozen (no more
>> packets dequeued)
>>
>> Hmm...
>>
>
> It seems class deletes are buggy.
>
> After one "tc class del dev $ETH classid 11:1 ..."
>
> a "tc -s -d qdisc show dev $ETH" triggers an Oops
What classes and filters did you have before issuing that command?
^ permalink raw reply
* Re: [Lxc-users] Bad checksums and lost packets with macvlan on dummy
From: Daniel Lezcano @ 2011-03-02 18:33 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, Andrian Nord, lxc-users, Linux Netdev List
In-Reply-To: <4D6E8686.3000109@trash.net>
On 03/02/2011 07:03 PM, Patrick McHardy wrote:
> Am 02.03.2011 17:03, schrieb Daniel Lezcano:
>> On 03/02/2011 12:03 PM, Patrick McHardy wrote:
>>> Am 01.03.2011 21:04, schrieb Daniel Lezcano:
>>>> On 03/01/2011 05:51 PM, Patrick McHardy wrote:
>>>>>> Patrick, do you have any suggestions to fix this ?
>>>>> Since the frames are only looped back locally, I suppose the easiest
>>>>> fix would be to mark them with CHECKSUM_UNNECESSARY. Alternatively
>>>>> we need to complete the checksum manually, similar to what
>>>>> dev_hard_start_xmit() does.
>>>> That sounds very simple to fix, maybe too much simple :)
>>>>
>>>> I did the following change:
>>>>
>>>> --- linux-next.orig/drivers/net/macvlan.c
>>>> +++ linux-next/drivers/net/macvlan.c
>>>> @@ -222,6 +222,7 @@ static int macvlan_queue_xmit(struct sk_
>>>>
>>>> if (vlan->mode == MACVLAN_MODE_BRIDGE) {
>>>> const struct ethhdr *eth = (void *)skb->data;
>>>> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>>>>
>>>> /* send to other bridge ports directly */
>>>> if (is_multicast_ether_addr(eth->h_dest)) {
>>>>
>>>>
>>>> and that fixed the problem. Do you think it is acceptable ?
>>> The only problem I see is if the packets are bridged to a
>>> different networking device (or redirected using the mirred
>>> action), in this case the checksum will not be completed.
>>> This would be a very strange setup though and probably wouldn't
>>> be using dummy as lower device, so I'm not sure we have to
>>> worry about this case.
>> I am not sure to get it, do you say the patch is correct ?
> Its correct with a short-coming that doesn't seem to matter.
>
>> If my understanding is correct, the packet will be flagged
>> CHECKSUM_UNNECESSARY only for the macvlan devices, right ?
> Only for packets bridged between macvlan devices. A setup like
> the following would cause problems:
>
> br0
> |
> .----------.
> | |
> macvlan0 macvlan1 eth0
> | |
> -------.-------
> dummy0
>
> In this case packets sent from macvlan0 will show up on
> eth0 with incorrect setups. However this setup doesn't
> seem realistic to me, you would simply use eth0 instead
> of dummy0.
Ok, I understand. thanks for the clarification.
>> By the way, this problem occurs for any lower device with offloading
>> capabilities with a macvlan port in bridge mode.
> True. This doesn't affect outgoing packets since their checksum
> will be completed in dev_hard_start_xmit(), but it affects
> packets bridged between macvlans.
One last question. In the case of broadcast packets with maclvan in
bridge mode.
We will have the packets going through each macvlan port and also to the
lower-device, right ?
For the latter, don't we have a problem if the packet is flagged
CHECKSUM_UNNECESSARY ?
Shouldn't we restore the ip_summed field before sending through
dev_queue_xmit ?
---
drivers/net/macvlan.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux-next/drivers/net/macvlan.c
===================================================================
--- linux-next.orig/drivers/net/macvlan.c
+++ linux-next/drivers/net/macvlan.c
@@ -222,10 +222,13 @@ static int macvlan_queue_xmit(struct sk_
if (vlan->mode == MACVLAN_MODE_BRIDGE) {
const struct ethhdr *eth = (void *)skb->data;
+ __u8 ip_summed = skb->ip_summed;
+ skb->ip_summed; = CHECKSUM_UNNECESSARY;
/* send to other bridge ports directly */
if (is_multicast_ether_addr(eth->h_dest)) {
macvlan_broadcast(skb, port, dev,
MACVLAN_MODE_BRIDGE);
+ skb->ip_summed = ip_summed;
goto xmit_world;
}
^ permalink raw reply
* [PATCH] e1000: fix race condition while driver unload/reset using kref count
From: prasanna.panchamukhi @ 2011-03-02 18:46 UTC (permalink / raw)
To: bruce.w.allan, jeffrey.t.kirsher, jesse.brandeburg,
jeffrey.e.pieper
Cc: e1000-devel, netdev, prasanna.panchamukhi
This race conditions occurs with reentrant e1000_down(), which gets
called by multiple threads while driver unload or reset.
This patch fixes the race condition when one thread tries to destroy
the memory allocated for tx buffer_info, while another thread still
happen to access tx buffer_info.
This patch fixes the above race condition using kref count.
Signed-off-by: Prasanna S. Panchamukhi <prasanna.panchamukhi@riverbed.com>
---
drivers/net/e1000/e1000.h | 2 +
drivers/net/e1000/e1000_main.c | 41 +++++++++++++++++++++++++++++++++++++--
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index a881dd0..36f55b3 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -168,6 +168,8 @@ struct e1000_tx_ring {
unsigned int next_to_clean;
/* array of buffer information structs */
struct e1000_buffer *buffer_info;
+ spinlock_t bufinfo_lock; /* protect access to buffer_info */
+ struct kref bufinfo_refcount; /* refcount access to buffer info */
u16 tdh;
u16 tdt;
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index beec573..336d3e1 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1531,6 +1531,8 @@ setup_tx_desc_die:
txdr->next_to_use = 0;
txdr->next_to_clean = 0;
+ spin_lock_init(&txdr->bufinfo_lock);
+ kref_init(&txdr->bufinfo_refcount);
return 0;
}
@@ -1880,6 +1882,22 @@ static void e1000_configure_rx(struct e1000_adapter *adapter)
ew32(RCTL, rctl);
}
+/*
+ * Free tx buffer info resources, only when no other thread is
+ * accessing it. Access to buffer_info is refcounted by bufinfo_refcount,
+ * hence memory allocated must be destroyed when bufinfo_refcount
+ * becomes zero. This routine gets executed when bufinfo_refcount
+ * becomes zero.
+ */
+static void e1000_free_tx_buffer_info(struct kref *ref)
+{
+ struct e1000_tx_ring *tx_ring =
+ container_of(ref, struct e1000_tx_ring, bufinfo_refcount);
+
+ vfree(tx_ring->buffer_info);
+ tx_ring->buffer_info = NULL;
+}
+
/**
* e1000_free_tx_resources - Free Tx Resources per Queue
* @adapter: board private structure
@@ -1895,8 +1913,9 @@ static void e1000_free_tx_resources(struct e1000_adapter *adapter,
e1000_clean_tx_ring(adapter, tx_ring);
- vfree(tx_ring->buffer_info);
- tx_ring->buffer_info = NULL;
+ spin_lock(&tx_ring->bufinfo_lock);
+ kref_put(&tx_ring->bufinfo_refcount, e1000_free_tx_buffer_info);
+ spin_unlock(&tx_ring->bufinfo_lock);
dma_free_coherent(&pdev->dev, tx_ring->size, tx_ring->desc,
tx_ring->dma);
@@ -1954,8 +1973,20 @@ static void e1000_clean_tx_ring(struct e1000_adapter *adapter,
unsigned long size;
unsigned int i;
- /* Free all the Tx ring sk_buffs */
+ spin_lock(&tx_ring->bufinfo_lock);
+ /*
+ * Check buffer_info is not NULL, and
+ * increment the refcount to prevent
+ * the buffer getting freed underneath.
+ */
+ if (tx_ring->buffer_info == NULL) {
+ spin_unlock(&tx_ring->bufinfo_lock);
+ return;
+ }
+ kref_get(&tx_ring->bufinfo_refcount);
+ spin_unlock(&tx_ring->bufinfo_lock);
+ /* Free all the Tx ring sk_buffs */
for (i = 0; i < tx_ring->count; i++) {
buffer_info = &tx_ring->buffer_info[i];
e1000_unmap_and_free_tx_resource(adapter, buffer_info);
@@ -1968,6 +1999,10 @@ static void e1000_clean_tx_ring(struct e1000_adapter *adapter,
memset(tx_ring->desc, 0, tx_ring->size);
+ spin_lock(&tx_ring->bufinfo_lock);
+ kref_put(&tx_ring->bufinfo_refcount, e1000_free_tx_buffer_info);
+ spin_unlock(&tx_ring->bufinfo_lock);
+
tx_ring->next_to_use = 0;
tx_ring->next_to_clean = 0;
tx_ring->last_tx_tso = 0;
--
1.7.0.4
^ permalink raw reply related
* Re: [net-next-2.6 PATCH 02/10] ethtool: add ntuple flow specifier to network flow classifier
From: Ben Hutchings @ 2011-03-02 18:50 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Alexander Duyck, davem, jeffrey.t.kirsher, netdev
In-Reply-To: <AANLkTi=P0v1+h=TjC2j5k0zM-2BF22tbaoGpKBAjNd7-@mail.gmail.com>
On Fri, 2011-02-25 at 21:30 -0800, Alexander Duyck wrote:
> On Fri, Feb 25, 2011 at 5:00 PM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> > On Fri, 2011-02-25 at 15:32 -0800, Alexander Duyck wrote:
[...]
> >> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> >> index aac3e2e..3d1f8e0 100644
> >> --- a/include/linux/ethtool.h
> >> +++ b/include/linux/ethtool.h
> >> @@ -378,10 +378,25 @@ struct ethtool_usrip4_spec {
> >> };
> >>
> >> /**
> >> + * struct ethtool_ntuple_spec_ext - flow spec extension for ntuple in nfc
> >> + * @unused: space unused by extension
> >> + * @vlan_etype: EtherType for vlan tagged packet to match
> >> + * @vlan_tci: VLAN tag to match
> >> + * @data: Driver-dependent data to match
> >> + */
> >> +struct ethtool_ntuple_spec_ext {
> >> + __be32 unused[15];
> >> + __be16 vlan_etype;
> >> + __be16 vlan_tci;
> >> + __be32 data[2];
> >> +};
> > [...]
> >
> > This is a really nasty way to reclaim space in the union.
> >
> > Let's name the union, shrink it and insert the extra fields that way:
> >
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -377,27 +377,43 @@ struct ethtool_usrip4_spec {
> > __u8 proto;
> > };
> >
> > +union ethtool_flow_union {
> > + struct ethtool_tcpip4_spec tcp_ip4_spec;
> > + struct ethtool_tcpip4_spec udp_ip4_spec;
> > + struct ethtool_tcpip4_spec sctp_ip4_spec;
> > + struct ethtool_ah_espip4_spec ah_ip4_spec;
> > + struct ethtool_ah_espip4_spec esp_ip4_spec;
> > + struct ethtool_usrip4_spec usr_ip4_spec;
> > + struct ethhdr ether_spec;
> > + __u8 hdata[52];
> > +};
> > +
> > +struct ethtool_flow_ext {
> > + __be16 vlan_etype;
> > + __be16 vlan_tci;
> > + __be32 data[2];
> > + __u32 reserved[2];
> > +};
> > +
>
> Any chance of getting the reserved fields moved to the top of the
> structure? My only concern is that we might end up with a flow spec
> larger than 52 bytes at some point and moving the reserved fields to
> the front might give us a little more wiggle room future
> compatibility.
[...]
OK, so how about this:
/**
* union ethtool_flow_union - flow spec type-specific fields
* @tcp_ip4_spec: TCP/IPv4 fields to match
* @udp_ip4_spec: UDP/IPv4 fields to match
* @sctp_ip4_spec: SCTP/IPv4 fields to match
* @ah_ip4_spec: AH/IPv4 fields to match
* @esp_ip4_spec: ESP/IPv4 fields to match
* @usr_ip4_spec: User-defined IPv4 fields to match
* @ether_spec: Ethernet fields to match
*
* Note: The size of this union may shrink in future to allow for
* expansion in &struct ethtool_flow_ext.
*/
union ethtool_flow_union {
struct ethtool_tcpip4_spec tcp_ip4_spec;
struct ethtool_tcpip4_spec udp_ip4_spec;
struct ethtool_tcpip4_spec sctp_ip4_spec;
struct ethtool_ah_espip4_spec ah_ip4_spec;
struct ethtool_ah_espip4_spec esp_ip4_spec;
struct ethtool_usrip4_spec usr_ip4_spec;
struct ethhdr ether_spec;
__u8 hdata[60];
};
/**
* struct ethtool_flow_ext - flow spec common extension fields
* @vlan_etype: EtherType for vlan tagged packet to match
* @vlan_tci: VLAN tag to match
* @data: Driver-dependent data to match
*
* Note: Additional fields may be inserted before @vlan_etype in future,
* but the offset of the existing fields within the containing structure
* (&struct ethtool_rx_flow_spec) will be stable.
*/
struct ethtool_flow_ext {
__be16 vlan_etype;
__be16 vlan_tci;
__be32 data[2];
};
Please can you check that these definitions won't affect the size of
struct ethtool_rx_flow_spec on i386 or x86-64?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: source route ignored in favor of local interface
From: Ben Greear @ 2011-03-02 18:55 UTC (permalink / raw)
To: Joe Buehler; +Cc: Chris Friesen, netdev
In-Reply-To: <4D6D49AE.2030303@cox.net>
On 03/01/2011 11:31 AM, Joe Buehler wrote:
>> If you really want to modify things, have you looked at your ip rules?
>> "ip ru" will dump them. Typically it looks something like
>>
>> 0: from all lookup local
>> 32766: from all lookup main
>> 32767: from all lookup default
>>
>> The last item in each row is the name of the routing table. As you can
>> see, the first rule is for local interfaces, and a later rule deals with
>> the main and default routing tables.
>>
>> You could move the local lookup to rule 1 and add in a new rule 0
>> specifically dealing with your situation.
>
> We have tried some variations on modifications to ip rules, but the
> kernel appears to treat rule 0 specially -- it cannot be deleted, for
> example. This results in the enforcing of local interfaces before
> source routes -- surely something that should be a policy decision, not
> hard-coded.
>
> Let me rephrase and ask: Does anyone know how to replace the priority 0
> rule?
You can do this on more modern kernels (2.6.36 and later definately works..not sure
about earlier).
ip rule add pref 512 lookup local
ip rule del pref 0 lookup local
Thanks,
Ben
>
> Joe Buehler
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: [net-next-2.6 PATCH 02/10] ethtool: add ntuple flow specifier to network flow classifier
From: Dimitrios Michailidis @ 2011-03-02 19:11 UTC (permalink / raw)
To: Ben Hutchings, Alexander Duyck
Cc: Alexander Duyck, davem, jeffrey.t.kirsher, netdev
In-Reply-To: <1299091805.2664.16.camel@bwh-desktop>
Ben Hutchings wrote:
> /**
> * struct ethtool_flow_ext - flow spec common extension fields
> * @vlan_etype: EtherType for vlan tagged packet to match
> * @vlan_tci: VLAN tag to match
> * @data: Driver-dependent data to match
> *
> * Note: Additional fields may be inserted before @vlan_etype in future,
> * but the offset of the existing fields within the containing structure
> * (&struct ethtool_rx_flow_spec) will be stable.
> */
> struct ethtool_flow_ext {
> __be16 vlan_etype;
> __be16 vlan_tci;
> __be32 data[2];
> };
I am wondering about the semantics of these vlan_* fields. Is vlan_etype the
Ethertype in the VLAN header or the type after it? Specifically, I am wondering
whether these fields are limited to VLANs or can work with general Ethertypes and the
2 bytes after them.
^ permalink raw reply
* RE: [net-next-2.6 PATCH 02/10] ethtool: add ntuple flow specifier to network flow classifier
From: Ben Hutchings @ 2011-03-02 19:27 UTC (permalink / raw)
To: Dimitrios Michailidis
Cc: Alexander Duyck, Alexander Duyck, davem, jeffrey.t.kirsher,
netdev
In-Reply-To: <8A71B368A89016469F72CD08050AD334091C1FAB@maui.asicdesigners.com>
On Wed, 2011-03-02 at 11:11 -0800, Dimitrios Michailidis wrote:
> Ben Hutchings wrote:
> > /**
> > * struct ethtool_flow_ext - flow spec common extension fields
> > * @vlan_etype: EtherType for vlan tagged packet to match
> > * @vlan_tci: VLAN tag to match
> > * @data: Driver-dependent data to match
> > *
> > * Note: Additional fields may be inserted before @vlan_etype in future,
> > * but the offset of the existing fields within the containing structure
> > * (&struct ethtool_rx_flow_spec) will be stable.
> > */
> > struct ethtool_flow_ext {
> > __be16 vlan_etype;
> > __be16 vlan_tci;
> > __be32 data[2];
> > };
>
> I am wondering about the semantics of these vlan_* fields. Is vlan_etype the
> Ethertype in the VLAN header or the type after it?
It would be the the type in the VLAN tag. The nested ethertype is
normally implied by flow_type to be ETH_P_IP.
This does leave the question of what this would mean:
struct ethtool_rx_flow_spec fs = {
.flow_type = ... | FLOW_EXT,
...
.h_ext.vlan_tci = htons(0x1234),
.m_ext.vlan_etype = 0xffff,
};
This says the TCI must be == 0x1234 but the type can be anything. But
the type surely has to be be one assigned for use in VLAN tags. Should
we leave it to the driver/hardware to determine what those valid types
are, or should we reject this as valid?
> Specifically, I am wondering
> whether these fields are limited to VLANs or can work with general Ethertypes and the
> 2 bytes after them.
If you set flow_type = ETHER_FLOW you can then specify any combination
of Ethernet header fields to match in {h_u,m_u}.ether_spec. However, so
far only sfc implements it and it only allows matching on the
destination MAC address.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 0/2] netfilter: netfilter fixes for 2.6.38
From: David Miller @ 2011-03-02 19:29 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1299066981-14058-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Wed, 2 Mar 2011 12:56:19 +0100
> the following patches fix two IPVS/netfilter bugs:
>
> - incorrect locking in __ip_vs_update_dest(), from Julian
>
> - a potential oops when binding or unbinding an invalid address family
> through nfnetlink_log, from Jan
>
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Pulled, thanks a lot Patrick.
^ permalink raw reply
* Re: [PATCH 00/13] netfilter: netfilter update
From: David Miller @ 2011-03-02 19:30 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1299067973-15977-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Wed, 2 Mar 2011 13:12:40 +0100
> following is a netfilter update for net-next, containing:
>
> - minor cleanups and bugfixes
>
> - a fix for a bridge netfilter information leak, from Vasiliy Kulikov
>
> - IPVS timer fixes, from Tinggong Wang
>
> - conversion of the IPVS hash table to hlists, from Changli
>
> - TCP conntrack improvements, from Pablo
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master
Also pulled, thanks!
^ permalink raw reply
* Re: [PATCH] via-rhine: do not abort due to invalid MAC address
From: David Miller @ 2011-03-02 19:36 UTC (permalink / raw)
To: mr.nuke.me; +Cc: florian, rl, netdev
In-Reply-To: <4D6E883C.2000800@gmail.com>
From: "Alex G." <mr.nuke.me@gmail.com>
Date: Wed, 02 Mar 2011 20:11:08 +0200
> On 03/02/2011 08:01 PM, Florian Fainelli wrote:
>>
>> Why not generate a valid random ethernet address using random_ether_addr()
>> instead?
>
> That would confuse ifcfg-* scripts that specify HWETHER, and probably
> users as well. It might even stump udev.
If the ethernet address reported by the card is garbage, every single
ethernet driver that tried to handle this case uses a random ethernet
address.
There is no reason to choose a different strategy for this driver.
Also registering a network device with an invalid ethernet address can
cause all kinds of serious issues, let's say dhcp brings the device
up and emits DHCP requests with illegal MAC addresses in the header
because of this problem.
You therefore simply cannot leave crap in there.
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Jake Edge @ 2011-03-02 19:39 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, mjt, arnd, mirqus, netdev, Ben Hutchings,
David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm
In-Reply-To: <20110301213313.GA6507@albatros>
I am probably missing something, but shouldn't the existing
MODULE_ALIASes stay?
Vasiliy Kulikov <segoon@openwall.com> writes:
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 6613edf..d1d0e2c 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -1765,4 +1765,4 @@ module_exit(ipgre_fini);
> MODULE_LICENSE("GPL");
> MODULE_ALIAS_RTNL_LINK("gre");
> MODULE_ALIAS_RTNL_LINK("gretap");
> -MODULE_ALIAS("gre0");
> +MODULE_ALIAS_NETDEV("gre0");
that is, instead of replacing MODULE_ALIAS("gre0") with the NETDEV
version, don't you want both for backward compatibility?
(if so, same goes for the other two)
jake
--
Jake Edge - jake@lwn.net - http://lwn.net
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Vasiliy Kulikov @ 2011-03-02 19:43 UTC (permalink / raw)
To: Jake Edge
Cc: linux-kernel, mjt, arnd, mirqus, netdev, Ben Hutchings,
David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm
In-Reply-To: <m34o7ltipi.fsf@lwn.net>
On Wed, Mar 02, 2011 at 12:39 -0700, Jake Edge wrote:
> > @@ -1765,4 +1765,4 @@ module_exit(ipgre_fini);
> > MODULE_LICENSE("GPL");
> > MODULE_ALIAS_RTNL_LINK("gre");
> > MODULE_ALIAS_RTNL_LINK("gretap");
> > -MODULE_ALIAS("gre0");
> > +MODULE_ALIAS_NETDEV("gre0");
>
> that is, instead of replacing MODULE_ALIAS("gre0") with the NETDEV
> version, don't you want both for backward compatibility?
The networking script will run with CAP_NET_ADMIN, this would request
netdev-gre0 and load ip_gre.
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Jake Edge @ 2011-03-02 19:49 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, mjt, arnd, mirqus, netdev, Ben Hutchings,
David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm
In-Reply-To: <20110302194354.GA31043@albatros>
On Wed, 2 Mar 2011 22:43:54 +0300 Vasiliy Kulikov wrote:
> On Wed, Mar 02, 2011 at 12:39 -0700, Jake Edge wrote:
> > > @@ -1765,4 +1765,4 @@ module_exit(ipgre_fini);
> > > MODULE_LICENSE("GPL");
> > > MODULE_ALIAS_RTNL_LINK("gre");
> > > MODULE_ALIAS_RTNL_LINK("gretap");
> > > -MODULE_ALIAS("gre0");
> > > +MODULE_ALIAS_NETDEV("gre0");
> >
> > that is, instead of replacing MODULE_ALIAS("gre0") with the NETDEV
> > version, don't you want both for backward compatibility?
>
> The networking script will run with CAP_NET_ADMIN, this would request
> netdev-gre0 and load ip_gre.
and on systems that today use CAP_SYS_MODULE (or really the full set of
capabilities cuz they are running as root)? won't those try to load
gre0 and fail because that alias doesn't exist?
jake
--
Jake Edge - LWN - jake@lwn.net - http://lwn.net
^ permalink raw reply
* Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0
From: "Oleg A. Arkhangelsky" @ 2011-03-02 19:50 UTC (permalink / raw)
To: Changli Gao; +Cc: Patrick McHardy, netfilter-devel, netdev, Paul E McKenney
In-Reply-To: <AANLkTikkz23221ZSiat8N5tnE_bkHN=1EUNQTDdnC30L@mail.gmail.com>
02.03.2011, 17:37, "Changli Gao" <xiaosuo@gmail.com>:
> t should be NULL here, as offsetof(struct nf_conn, dst.protonum) == 0x36.
> We should free the nf_ct_extend with call_rcu(), since nat ext is
> referenced in the rcu read context.
Yes, I think the problem is triggered when nf_conntrack_free() is called by
different CPU during net->ipv4.nat_bysource hash traversal. Extensions
framework doesn't have any SLAB_DESTROY_BY_RCU magic.
I'm not sure, but couldn't this problem be introduced by:
ea781f197d6a835cbb93a0bf88ee1696296ed8aa
netfilter: nf_conntrack: use SLAB_DESTROY_BY_RCU and get rid of call_rcu()
?
--
wbr, Oleg.
^ permalink raw reply
* Re: [PATCH] iproute2: add support of flag XFRM_STATE_ALIGN4
From: Stephen Hemminger @ 2011-03-02 19:50 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4D6E87AF.8090204@6wind.com>
On Wed, 02 Mar 2011 19:08:47 +0100
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Hi,
>
> please find the patch enclosed.
>
>
> Regards,
> Nicolas
applied to net-next branch.
--
^ 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