* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Oleg Nesterov @ 2010-12-08 13:47 UTC (permalink / raw)
To: Florian Mickler
Cc: Ingo Molnar, Américo Wang, Dave Chinner, Eric Dumazet,
linux-kernel, netdev
In-Reply-To: <20101208134116.GA16923@redhat.com>
On 12/08, Oleg Nesterov wrote:
>
> On 12/08, Florian Mickler wrote:
> >
> > [ ccing Ingo and Oleg ] as suggested
>
> Well. Of course I can't explain this bug. But, looking at this email
> I do not see amything strange in exit/schedule/etc.
>
> > > >> > > > This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
> > > >> > > >
> > > >> > > > root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
> > > >> > > > root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
> > > >> > > > root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
>
> That is. ip is a zombie.
And. I do not know if this matters or not, but "the command 'ip link
set tap0 up' hanging as a zombie" does not look right.
This was spawned by
> >> > > > if [ -n "$1" ];then
> >> > > > /usr/bin/sudo /sbin/ip link set $1 up
> >> > > > sleep 0.5s
> >> > > > /usr/bin/sudo /usr/sbin/brctl addif $switch $1
> >> > > > exit 0
> >> > > > fi
The command does not hang. But it forks the child with pid == 3012,
this child exits.
Oleg.
^ permalink raw reply
* Re: [v3 PATCH 1/2] bonding: sync netpoll code with bridge
From: Neil Horman @ 2010-12-08 13:57 UTC (permalink / raw)
To: Amerigo Wang
Cc: linux-kernel, Jiri Pirko, netdev, David S. Miller,
Eric W. Biederman, Herbert Xu, bonding-devel, Jay Vosburgh,
Stephen Hemminger
In-Reply-To: <20101208075208.5792.45247.sendpatchset@localhost.localdomain>
On Wed, Dec 08, 2010 at 02:52:08AM -0500, Amerigo Wang wrote:
> From: Amerigo Wang <amwang@redhat.com>
> Date: Thu, 2 Dec 2010 21:31:19 +0800
> Subject: [v3 PATCH 1/2] bonding: sync netpoll code with bridge
>
> V3: remove an useless #ifdef.
>
> This patch unifies the netpoll code in bonding with netpoll code in bridge,
> thanks to Herbert that code is much cleaner now.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: Neil Horman <nhorman@redhat.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Jay Vosburgh <fubar@us.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: Jiri Pirko <jpirko@redhat.com>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>
>
> ---
>
> drivers/net/bonding/bond_main.c | 155 ++++++++++++++++++++++++--------------
> drivers/net/bonding/bonding.h | 20 +++++
> 2 files changed, 118 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 0273ad0..7fafe06 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -59,7 +59,6 @@
> #include <linux/uaccess.h>
> #include <linux/errno.h>
> #include <linux/netdevice.h>
> -#include <linux/netpoll.h>
> #include <linux/inetdevice.h>
> #include <linux/igmp.h>
> #include <linux/etherdevice.h>
> @@ -449,15 +448,11 @@ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb,
> }
>
> skb->priority = 1;
> -#ifdef CONFIG_NET_POLL_CONTROLLER
> - if (unlikely(bond->dev->priv_flags & IFF_IN_NETPOLL)) {
> - struct netpoll *np = bond->dev->npinfo->netpoll;
> - slave_dev->npinfo = bond->dev->npinfo;
> + if (unlikely(netpoll_tx_running(slave_dev))) {
> slave_dev->priv_flags |= IFF_IN_NETPOLL;
> - netpoll_send_skb_on_dev(np, skb, slave_dev);
> + bond_netpoll_send_skb(bond_get_slave_by_dev(bond, slave_dev), skb);
> slave_dev->priv_flags &= ~IFF_IN_NETPOLL;
> } else
> -#endif
> dev_queue_xmit(skb);
>
> return 0;
> @@ -1310,63 +1305,113 @@ static void bond_detach_slave(struct bonding *bond, struct slave *slave)
> }
>
> #ifdef CONFIG_NET_POLL_CONTROLLER
> -/*
> - * You must hold read lock on bond->lock before calling this.
> - */
> -static bool slaves_support_netpoll(struct net_device *bond_dev)
> +static inline int slave_enable_netpoll(struct slave *slave)
> {
> - struct bonding *bond = netdev_priv(bond_dev);
> - struct slave *slave;
> - int i = 0;
> - bool ret = true;
> + struct netpoll *np;
> + int err = 0;
>
> - bond_for_each_slave(bond, slave, i) {
> - if ((slave->dev->priv_flags & IFF_DISABLE_NETPOLL) ||
> - !slave->dev->netdev_ops->ndo_poll_controller)
> - ret = false;
> + np = kmalloc(sizeof(*np), GFP_KERNEL);
> + err = -ENOMEM;
> + if (!np)
> + goto out;
> +
> + np->dev = slave->dev;
> + err = __netpoll_setup(np);
Setting up our own netpoll instance on each slave worries me a bit. The
implication here is that, by doing so, some frames will get entirely processed
by the slave. Most notably arp frames. That means anything that gets queued up
to the arp_tx queue in __netpoll_rx will get processed during that poll event,
and responded to with the mac of the slave device, rather than with the mac of
the bond device, which isn't always what you want. I think if you go with this
route, you'll need to add code to netpoll_poll_dev, right before the call to
service_arp_queue, to check if IFF_SLAVE is set in priv_flags, and move the list
to the master device, or some such.
It also seems like you'll want to zero out the other fields in the netpoll
structure. Leaving garbage in them will be bad. Most notably here I'm looking
at the rx_hook field. If its non-null we're going to add a bogus pointer to the
rx_np list and call off into space at some point.
> + if (err) {
> + kfree(np);
> + goto out;
> }
> - return i != 0 && ret;
> + slave->np = np;
> +out:
> + return err;
> +}
> +static inline void slave_disable_netpoll(struct slave *slave)
> +{
> + struct netpoll *np = slave->np;
> +
> + if (!np)
> + return;
> +
> + slave->np = NULL;
> + synchronize_rcu_bh();
> + __netpoll_cleanup(np);
> + kfree(np);
> +}
> +static inline bool slave_dev_support_netpoll(struct net_device *slave_dev)
> +{
> + if (slave_dev->priv_flags & IFF_DISABLE_NETPOLL)
> + return false;
> + if (!slave_dev->netdev_ops->ndo_poll_controller)
> + return false;
> + return true;
> }
>
> static void bond_poll_controller(struct net_device *bond_dev)
> {
> - struct bonding *bond = netdev_priv(bond_dev);
> +}
> +
> +static void __bond_netpoll_cleanup(struct bonding *bond)
> +{
> struct slave *slave;
> int i;
>
> - bond_for_each_slave(bond, slave, i) {
> - if (slave->dev && IS_UP(slave->dev))
> - netpoll_poll_dev(slave->dev);
> - }
> + bond_for_each_slave(bond, slave, i)
> + if (slave->dev)
Why are you checking slave->dev here? If the dev pointer has been set to NULL
here it would seem we're not holding on to dev long enough. If we enabled
netpoll with a dev pointer and lost it somewhere along the way, we're going to
leak that struct netpoll memory that we allocated.
> + slave_disable_netpoll(slave);
> }
> -
> static void bond_netpoll_cleanup(struct net_device *bond_dev)
> {
> struct bonding *bond = netdev_priv(bond_dev);
> +
> + read_lock(&bond->lock);
> + __bond_netpoll_cleanup(bond);
> + read_unlock(&bond->lock);
> +}
> +
> +static int bond_netpoll_setup(struct net_device *dev, struct netpoll_info *ni)
> +{
> + struct bonding *bond = netdev_priv(dev);
> struct slave *slave;
> - const struct net_device_ops *ops;
> - int i;
> + int i, err = 0;
>
> read_lock(&bond->lock);
> - bond_dev->npinfo = NULL;
> bond_for_each_slave(bond, slave, i) {
> - if (slave->dev) {
> - ops = slave->dev->netdev_ops;
> - if (ops->ndo_netpoll_cleanup)
> - ops->ndo_netpoll_cleanup(slave->dev);
> - else
> - slave->dev->npinfo = NULL;
> + if (!slave->dev)
> + continue;
> + err = slave_enable_netpoll(slave);
> + if (err) {
> + __bond_netpoll_cleanup(bond);
> + break;
> }
> }
> read_unlock(&bond->lock);
> + return err;
> }
>
> -#else
> +static struct netpoll_info *bond_netpoll_info(struct bonding *bond)
> +{
> + return bond->dev->npinfo;
> +}
>
> +#else
> +static inline int slave_enable_netpoll(struct slave *slave)
> +{
> + return 0;
> +}
> +static inline void slave_disable_netpoll(struct slave *slave)
> +{
> +}
> static void bond_netpoll_cleanup(struct net_device *bond_dev)
> {
> }
> -
> +static int bond_netpoll_setup(struct net_device *dev, struct netpoll_info *ni)
> +{
> + return 0;
> +}
> +static struct netpoll_info *bond_netpoll_info(struct bonding *bond)
> +{
> + return NULL;
> +}
> #endif
>
> /*---------------------------------- IOCTL ----------------------------------*/
> @@ -1804,17 +1849,19 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> bond_set_carrier(bond);
>
> #ifdef CONFIG_NET_POLL_CONTROLLER
> - if (slaves_support_netpoll(bond_dev)) {
> - bond_dev->priv_flags &= ~IFF_DISABLE_NETPOLL;
> - if (bond_dev->npinfo)
> - slave_dev->npinfo = bond_dev->npinfo;
> - } else if (!(bond_dev->priv_flags & IFF_DISABLE_NETPOLL)) {
> - bond_dev->priv_flags |= IFF_DISABLE_NETPOLL;
> - pr_info("New slave device %s does not support netpoll\n",
> - slave_dev->name);
> - pr_info("Disabling netpoll support for %s\n", bond_dev->name);
> + slave_dev->npinfo = bond_netpoll_info(bond);
> + if (slave_dev->npinfo) {
> + if (slave_enable_netpoll(new_slave)) {
> + read_unlock(&bond->lock);
> + pr_info("Error, %s: master_dev is using netpoll, "
> + "but new slave device does not support netpoll.\n",
> + bond_dev->name);
> + res = -EBUSY;
> + goto err_close;
> + }
> }
> #endif
> +
> read_unlock(&bond->lock);
>
> res = bond_create_slave_symlinks(bond_dev, slave_dev);
> @@ -2016,17 +2063,7 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
>
> netdev_set_master(slave_dev, NULL);
>
> -#ifdef CONFIG_NET_POLL_CONTROLLER
> - read_lock_bh(&bond->lock);
> -
> - if (slaves_support_netpoll(bond_dev))
> - bond_dev->priv_flags &= ~IFF_DISABLE_NETPOLL;
> - read_unlock_bh(&bond->lock);
> - if (slave_dev->netdev_ops->ndo_netpoll_cleanup)
> - slave_dev->netdev_ops->ndo_netpoll_cleanup(slave_dev);
> - else
> - slave_dev->npinfo = NULL;
> -#endif
> + slave_disable_netpoll(slave);
>
> /* close slave before restoring its mac address */
> dev_close(slave_dev);
> @@ -2061,6 +2098,7 @@ static int bond_release_and_destroy(struct net_device *bond_dev,
>
> ret = bond_release(bond_dev, slave_dev);
> if ((ret == 0) && (bond->slave_cnt == 0)) {
> + bond_dev->priv_flags |= IFF_DISABLE_NETPOLL;
Why are you setting IFF_DISABLE_NETPOLL here? That seems unnecessecary
> pr_info("%s: destroying bond %s.\n",
> bond_dev->name, bond_dev->name);
> unregister_netdevice(bond_dev);
> @@ -2138,6 +2176,8 @@ static int bond_release_all(struct net_device *bond_dev)
>
> netdev_set_master(slave_dev, NULL);
>
> + slave_disable_netpoll(slave);
> +
> /* close slave before restoring its mac address */
> dev_close(slave_dev);
>
> @@ -4670,6 +4710,7 @@ static const struct net_device_ops bond_netdev_ops = {
> .ndo_vlan_rx_add_vid = bond_vlan_rx_add_vid,
> .ndo_vlan_rx_kill_vid = bond_vlan_rx_kill_vid,
> #ifdef CONFIG_NET_POLL_CONTROLLER
> + .ndo_netpoll_setup = bond_netpoll_setup,
> .ndo_netpoll_cleanup = bond_netpoll_cleanup,
> .ndo_poll_controller = bond_poll_controller,
> #endif
> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
> index ad3ae46..c4f6a94 100644
> --- a/drivers/net/bonding/bonding.h
> +++ b/drivers/net/bonding/bonding.h
> @@ -21,6 +21,7 @@
> #include <linux/kobject.h>
> #include <linux/cpumask.h>
> #include <linux/in6.h>
> +#include <linux/netpoll.h>
> #include "bond_3ad.h"
> #include "bond_alb.h"
>
> @@ -203,6 +204,9 @@ struct slave {
> u16 queue_id;
> struct ad_slave_info ad_info; /* HUGE - better to dynamically alloc */
> struct tlb_slave_info tlb_info;
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + struct netpoll *np;
> +#endif
> };
>
> /*
> @@ -324,6 +328,22 @@ static inline unsigned long slave_last_rx(struct bonding *bond,
> return slave->dev->last_rx;
> }
>
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +static inline void bond_netpoll_send_skb(const struct slave *slave,
> + struct sk_buff *skb)
> +{
> + struct netpoll *np = slave->np;
> +
> + if (np)
> + netpoll_send_skb(np, skb);
> +}
> +#else
> +static inline void bond_netpoll_send_skb(const struct slave *slave,
> + struct sk_buff *skb)
> +{
> +}
> +#endif
> +
> static inline void bond_set_slave_inactive_flags(struct slave *slave)
> {
> struct bonding *bond = netdev_priv(slave->dev->master);
> --
> 1.7.1
>
^ permalink raw reply
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Oleg Nesterov @ 2010-12-08 14:08 UTC (permalink / raw)
To: Florian Mickler
Cc: Ingo Molnar, Américo Wang, Dave Chinner, Eric Dumazet,
linux-kernel, netdev
In-Reply-To: <20101208134712.GB16923@redhat.com>
On 12/08, Oleg Nesterov wrote:
>
> On 12/08, Oleg Nesterov wrote:
> >
> > On 12/08, Florian Mickler wrote:
> > >
> > > [ ccing Ingo and Oleg ] as suggested
> >
> > Well. Of course I can't explain this bug. But, looking at this email
> > I do not see amything strange in exit/schedule/etc.
> >
> > > > >> > > > This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
> > > > >> > > >
> > > > >> > > > root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
> > > > >> > > > root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
> > > > >> > > > root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
> >
> > That is. ip is a zombie.
>
> And. I do not know if this matters or not, but "the command 'ip link
> set tap0 up' hanging as a zombie" does not look right.
>
> This was spawned by
>
> > >> > > > if [ -n "$1" ];then
> > >> > > > /usr/bin/sudo /sbin/ip link set $1 up
> > >> > > > sleep 0.5s
> > >> > > > /usr/bin/sudo /usr/sbin/brctl addif $switch $1
> > >> > > > exit 0
> > >> > > > fi
>
> The command does not hang. But it forks the child with pid == 3012,
> this child exits.
Damn, sorry for noise, forgot to mention...
The parent's trace (pid == 3011) can be more useful. Say, if it
hangs in do_wait(), then the kernel is obviously wrong.
Oleg.
^ permalink raw reply
* [PATCH 0/3] xfrm: ESP Traffic Flow Confidentiality padding (v3)
From: Martin Willi @ 2010-12-08 14:37 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
The following patchset adds Traffic Flow Confidentiality padding. The
first patch introduces a new Netlink XFRM attribute to configure TFC via
userspace. Patch two and three implement the padding logic in IPv4 and
IPv6 ESP. Padding is always done using the RFC4303 format an is clamped
to the PMTU.
Changes from v2:
- Remove unused flag field in attribute, use a plain u32 as attribute payload
- Reject installation of TFC padding on non-tunnel SAs
Martin Willi (3):
xfrm: Add Traffic Flow Confidentiality padding XFRM attribute
xfrm: Traffic Flow Confidentiality for IPv4 ESP
xfrm: Traffic Flow Confidentiality for IPv6 ESP
include/linux/xfrm.h | 1 +
include/net/xfrm.h | 1 +
net/ipv4/esp4.c | 32 ++++++++++++++++++++++++--------
net/ipv6/esp6.c | 32 ++++++++++++++++++++++++--------
net/xfrm/xfrm_user.c | 19 +++++++++++++++++--
5 files changed, 67 insertions(+), 18 deletions(-)
^ permalink raw reply
* [PATCH 2/3] xfrm: Traffic Flow Confidentiality for IPv4 ESP
From: Martin Willi @ 2010-12-08 14:37 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
In-Reply-To: <1291819071-17538-1-git-send-email-martin@strongswan.org>
Add TFC padding to all packets smaller than the boundary configured
on the xfrm state. If the boundary is larger than the PMTU, limit
padding to the PMTU.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
net/ipv4/esp4.c | 32 ++++++++++++++++++++++++--------
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 14ca1f1..e42a905 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -23,6 +23,8 @@ struct esp_skb_cb {
#define ESP_SKB_CB(__skb) ((struct esp_skb_cb *)&((__skb)->cb[0]))
+static u32 esp4_get_mtu(struct xfrm_state *x, int mtu);
+
/*
* Allocate an AEAD request structure with extra space for SG and IV.
*
@@ -117,25 +119,35 @@ static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
int blksize;
int clen;
int alen;
+ int plen;
+ int tfclen;
int nfrags;
/* skb is pure payload to encrypt */
err = -ENOMEM;
- /* Round to block size */
- clen = skb->len;
-
esp = x->data;
aead = esp->aead;
alen = crypto_aead_authsize(aead);
+ tfclen = 0;
+ if (x->tfcpad) {
+ struct xfrm_dst *dst = (struct xfrm_dst *)skb_dst(skb);
+ u32 padto;
+
+ padto = min(x->tfcpad, esp4_get_mtu(x, dst->child_mtu_cached));
+ if (skb->len < padto)
+ tfclen = padto - skb->len;
+ }
blksize = ALIGN(crypto_aead_blocksize(aead), 4);
- clen = ALIGN(clen + 2, blksize);
+ clen = ALIGN(skb->len + 2 + tfclen, blksize);
if (esp->padlen)
clen = ALIGN(clen, esp->padlen);
+ plen = clen - skb->len - tfclen;
- if ((err = skb_cow_data(skb, clen - skb->len + alen, &trailer)) < 0)
+ err = skb_cow_data(skb, tfclen + plen + alen, &trailer);
+ if (err < 0)
goto error;
nfrags = err;
@@ -150,13 +162,17 @@ static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
/* Fill padding... */
tail = skb_tail_pointer(trailer);
+ if (tfclen) {
+ memset(tail, 0, tfclen);
+ tail += tfclen;
+ }
do {
int i;
- for (i=0; i<clen-skb->len - 2; i++)
+ for (i = 0; i < plen - 2; i++)
tail[i] = i + 1;
} while (0);
- tail[clen - skb->len - 2] = (clen - skb->len) - 2;
- tail[clen - skb->len - 1] = *skb_mac_header(skb);
+ tail[plen - 2] = plen - 2;
+ tail[plen - 1] = *skb_mac_header(skb);
pskb_put(skb, trailer, clen - skb->len + alen);
skb_push(skb, -skb_network_offset(skb));
--
1.7.1
^ permalink raw reply related
* [PATCH 3/3] xfrm: Traffic Flow Confidentiality for IPv6 ESP
From: Martin Willi @ 2010-12-08 14:37 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
In-Reply-To: <1291819071-17538-1-git-send-email-martin@strongswan.org>
Add TFC padding to all packets smaller than the boundary configured
on the xfrm state. If the boundary is larger than the PMTU, limit
padding to the PMTU.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
net/ipv6/esp6.c | 32 ++++++++++++++++++++++++--------
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index ee9b93b..1b5c982 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -49,6 +49,8 @@ struct esp_skb_cb {
#define ESP_SKB_CB(__skb) ((struct esp_skb_cb *)&((__skb)->cb[0]))
+static u32 esp6_get_mtu(struct xfrm_state *x, int mtu);
+
/*
* Allocate an AEAD request structure with extra space for SG and IV.
*
@@ -140,6 +142,8 @@ static int esp6_output(struct xfrm_state *x, struct sk_buff *skb)
int blksize;
int clen;
int alen;
+ int plen;
+ int tfclen;
int nfrags;
u8 *iv;
u8 *tail;
@@ -148,18 +152,26 @@ static int esp6_output(struct xfrm_state *x, struct sk_buff *skb)
/* skb is pure payload to encrypt */
err = -ENOMEM;
- /* Round to block size */
- clen = skb->len;
-
aead = esp->aead;
alen = crypto_aead_authsize(aead);
+ tfclen = 0;
+ if (x->tfcpad) {
+ struct xfrm_dst *dst = (struct xfrm_dst *)skb_dst(skb);
+ u32 padto;
+
+ padto = min(x->tfcpad, esp6_get_mtu(x, dst->child_mtu_cached));
+ if (skb->len < padto)
+ tfclen = padto - skb->len;
+ }
blksize = ALIGN(crypto_aead_blocksize(aead), 4);
- clen = ALIGN(clen + 2, blksize);
+ clen = ALIGN(skb->len + 2 + tfclen, blksize);
if (esp->padlen)
clen = ALIGN(clen, esp->padlen);
+ plen = clen - skb->len - tfclen;
- if ((err = skb_cow_data(skb, clen - skb->len + alen, &trailer)) < 0)
+ err = skb_cow_data(skb, tfclen + plen + alen, &trailer);
+ if (err < 0)
goto error;
nfrags = err;
@@ -174,13 +186,17 @@ static int esp6_output(struct xfrm_state *x, struct sk_buff *skb)
/* Fill padding... */
tail = skb_tail_pointer(trailer);
+ if (tfclen) {
+ memset(tail, 0, tfclen);
+ tail += tfclen;
+ }
do {
int i;
- for (i=0; i<clen-skb->len - 2; i++)
+ for (i = 0; i < plen - 2; i++)
tail[i] = i + 1;
} while (0);
- tail[clen-skb->len - 2] = (clen - skb->len) - 2;
- tail[clen - skb->len - 1] = *skb_mac_header(skb);
+ tail[plen - 2] = plen - 2;
+ tail[plen - 1] = *skb_mac_header(skb);
pskb_put(skb, trailer, clen - skb->len + alen);
skb_push(skb, -skb_network_offset(skb));
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3] xfrm: Add Traffic Flow Confidentiality padding XFRM attribute
From: Martin Willi @ 2010-12-08 14:37 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
In-Reply-To: <1291819071-17538-1-git-send-email-martin@strongswan.org>
The XFRMA_TFCPAD attribute for XFRM state installation configures
Traffic Flow Confidentiality by padding ESP packets to a specified
length.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
include/linux/xfrm.h | 1 +
include/net/xfrm.h | 1 +
net/xfrm/xfrm_user.c | 19 +++++++++++++++++--
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index b971e38..930fdd2 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -283,6 +283,7 @@ enum xfrm_attr_type_t {
XFRMA_KMADDRESS, /* struct xfrm_user_kmaddress */
XFRMA_ALG_AUTH_TRUNC, /* struct xfrm_algo_auth */
XFRMA_MARK, /* struct xfrm_mark */
+ XFRMA_TFCPAD, /* __u32 */
__XFRMA_MAX
#define XFRMA_MAX (__XFRMA_MAX - 1)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index bcfb6b2..bdcade7 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -143,6 +143,7 @@ struct xfrm_state {
struct xfrm_id id;
struct xfrm_selector sel;
struct xfrm_mark mark;
+ u32 tfcpad;
u32 genid;
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 8bae6b2..8eb8895 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -148,7 +148,8 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
!attrs[XFRMA_ALG_AUTH_TRUNC]) ||
attrs[XFRMA_ALG_AEAD] ||
attrs[XFRMA_ALG_CRYPT] ||
- attrs[XFRMA_ALG_COMP])
+ attrs[XFRMA_ALG_COMP] ||
+ attrs[XFRMA_TFCPAD])
goto out;
break;
@@ -165,6 +166,9 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
attrs[XFRMA_ALG_CRYPT]) &&
attrs[XFRMA_ALG_AEAD])
goto out;
+ if (attrs[XFRMA_TFCPAD] &&
+ p->mode != XFRM_MODE_TUNNEL)
+ goto out;
break;
case IPPROTO_COMP:
@@ -172,7 +176,8 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
attrs[XFRMA_ALG_AEAD] ||
attrs[XFRMA_ALG_AUTH] ||
attrs[XFRMA_ALG_AUTH_TRUNC] ||
- attrs[XFRMA_ALG_CRYPT])
+ attrs[XFRMA_ALG_CRYPT] ||
+ attrs[XFRMA_TFCPAD])
goto out;
break;
@@ -186,6 +191,7 @@ static int verify_newsa_info(struct xfrm_usersa_info *p,
attrs[XFRMA_ALG_CRYPT] ||
attrs[XFRMA_ENCAP] ||
attrs[XFRMA_SEC_CTX] ||
+ attrs[XFRMA_TFCPAD] ||
!attrs[XFRMA_COADDR])
goto out;
break;
@@ -439,6 +445,9 @@ static struct xfrm_state *xfrm_state_construct(struct net *net,
goto error;
}
+ if (attrs[XFRMA_TFCPAD])
+ x->tfcpad = nla_get_u32(attrs[XFRMA_TFCPAD]);
+
if (attrs[XFRMA_COADDR]) {
x->coaddr = kmemdup(nla_data(attrs[XFRMA_COADDR]),
sizeof(*x->coaddr), GFP_KERNEL);
@@ -688,6 +697,9 @@ static int copy_to_user_state_extra(struct xfrm_state *x,
if (x->encap)
NLA_PUT(skb, XFRMA_ENCAP, sizeof(*x->encap), x->encap);
+ if (x->tfcpad)
+ NLA_PUT_U32(skb, XFRMA_TFCPAD, x->tfcpad);
+
if (xfrm_mark_put(skb, &x->mark))
goto nla_put_failure;
@@ -2122,6 +2134,7 @@ static const struct nla_policy xfrma_policy[XFRMA_MAX+1] = {
[XFRMA_MIGRATE] = { .len = sizeof(struct xfrm_user_migrate) },
[XFRMA_KMADDRESS] = { .len = sizeof(struct xfrm_user_kmaddress) },
[XFRMA_MARK] = { .len = sizeof(struct xfrm_mark) },
+ [XFRMA_TFCPAD] = { .type = NLA_U32 },
};
static struct xfrm_link {
@@ -2301,6 +2314,8 @@ static inline size_t xfrm_sa_len(struct xfrm_state *x)
l += nla_total_size(sizeof(*x->calg));
if (x->encap)
l += nla_total_size(sizeof(*x->encap));
+ if (x->tfcpad)
+ l += nla_total_size(sizeof(x->tfcpad));
if (x->security)
l += nla_total_size(sizeof(struct xfrm_user_sec_ctx) +
x->security->ctx_len);
--
1.7.1
^ permalink raw reply related
* Polling on sockets in kernel space and struct file
From: Martin Sustrik @ 2010-12-08 14:33 UTC (permalink / raw)
To: netdev; +Cc: Martin Lucina
Hi all,
As part of implementing a new experimental protocol family, we are
trying to create a socket in kernel. This seems to be easy, just use
sock_create_kern(). However, the socket returned by this function does
not have associated file structure; thus it cannot be polled on using
poll_initwait() and friends.
We have tried to create the appropriate struct file using sock_map_fd(),
but this has two problems:
1) We do not want our internal socket to be visible in the process
context, i.e. it should not have a file descriptor.
2) During process exit, we get a kernel BUG from iput() in fs/inode.c:1260.
We then tried another approach using anon_inode_getfile() to get a
struct file, but this still produces the problem 2) above.
Any help/advice on how to proceed would be appreciated; for reference
our work in progress can be seen at
http://github.com/sustrik/linux-2.6/blob/sp-v2.6.36/net/sp/af_sp.c
Thanks,
Martin
^ permalink raw reply
* Re: Polling on sockets in kernel space and struct file
From: Eric Dumazet @ 2010-12-08 15:02 UTC (permalink / raw)
To: Martin Sustrik; +Cc: netdev, Martin Lucina
In-Reply-To: <4CFF9757.3070100@250bpm.com>
Le mercredi 08 décembre 2010 à 15:33 +0100, Martin Sustrik a écrit :
> Hi all,
>
> As part of implementing a new experimental protocol family, we are
> trying to create a socket in kernel. This seems to be easy, just use
> sock_create_kern(). However, the socket returned by this function does
> not have associated file structure; thus it cannot be polled on using
> poll_initwait() and friends.
>
> We have tried to create the appropriate struct file using sock_map_fd(),
> but this has two problems:
>
> 1) We do not want our internal socket to be visible in the process
> context, i.e. it should not have a file descriptor.
>
> 2) During process exit, we get a kernel BUG from iput() in fs/inode.c:1260.
>
you could call sock_map_fd() then :
int fd = sock_map_fd(sock, flags);
struct file *file = NULL;
if (fd != -1) {
file = fget(fd);
sys_close(fd); /* still racy */
}
if (file) ...
Take a look at net/9p/trans_fd.c
> We then tried another approach using anon_inode_getfile() to get a
> struct file, but this still produces the problem 2) above.
>
> Any help/advice on how to proceed would be appreciated; for reference
> our work in progress can be seen at
>
> http://github.com/sustrik/linux-2.6/blob/sp-v2.6.36/net/sp/af_sp.c
^ permalink raw reply
* rndis gadget: Inconsistent locking
From: Neil Jones @ 2010-12-08 15:03 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
Hi,
Im getting another lockdep warning when using the RNDIS gadget:
WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
Modules linked in: g_ether
Call trace:
[<40003bf8>] _show_stack+0x68/0x7c
[<40003c20>] _dump_stack+0x14/0x28
[<40013c3c>] _warn_slowpath_common+0x5c/0x7c
[<40013c74>] _warn_slowpath_null+0x18/0x2c
[<4001b17c>] ___local_bh_disable+0xc0/0xd0
[<4001b1a0>] _local_bh_disable+0x14/0x28
[<402e57f8>] __raw_spin_lock_bh+0x18/0x54
[<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
[<402580c4>] _dev_get_stats+0xb8/0xc0
[<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
[<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
[<401d66fc>] _dwc_otg_request_done+0xd8/0x220
[<401d928c>] _ep0_complete_request+0x3f4/0x578
[<401d95bc>] _handle_ep0+0x1ac/0x146c
[<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
[<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
[<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
[<40054cf4>] _handle_IRQ_event+0x4c/0x184
[<40057b4c>] _handle_level_irq+0xac/0x15c
[<4000b204>] _metag_soc_irq_demux+0xac/0xb4
[<40002dd4>] _do_IRQ+0x4c/0x78
[<40004000>] _trigger_handler+0x38/0xac
[<40000b18>] ___TBIBoingVec+0xc/0x10
[<40003588>] _cpu_idle+0x54/0x78
no locks held by swapper/0.
---[ end trace 77ac3cfee0ae5b25 ]---
It
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [PATCH 1/5] sysfs: Introducing binary attributes for struct class
From: Greg KH @ 2010-12-08 15:06 UTC (permalink / raw)
To: Jiri Kosina
Cc: Stefan Achatz, Randy Dunlap, linux-doc, linux-kernel, linux-input,
netdev
In-Reply-To: <alpine.LNX.2.00.1012081432230.14806@pobox.suse.cz>
On Wed, Dec 08, 2010 at 02:33:14PM +0100, Jiri Kosina wrote:
> On Fri, 26 Nov 2010, Stefan Achatz wrote:
>
> > Added dev_bin_attrs to struct class similar to existing dev_attrs.
> >
> > Signed-off-by: Stefan Achatz <erazor_de@users.sourceforge.net>
>
> Greg, just to make sure (as you have stated your Ack in a thread belonging
> to different thread) -- I can add your Acked-by: to this patch and take it
> through my tree with the rest of the roccat patchset, is that correct?
Yes you can.
thanks,
greg k-h
^ permalink raw reply
* Re: rndis gadget: Inconsistent locking
From: Neil Jones @ 2010-12-08 15:11 UTC (permalink / raw)
To: linux-usb, netdev
In-Reply-To: <AANLkTik=Uui7Xk9ZfFvQQKj94ZJUJ_n+bZbTQXbe+08i@mail.gmail.com>
Sorry, stupid gmail...
Hi,
Im getting another lockdep warning when using the RNDIS gadget:
WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
Modules linked in: g_ether
Call trace:
[<40003bf8>] _show_stack+0x68/0x7c
[<40003c20>] _dump_stack+0x14/0x28
[<40013c3c>] _warn_slowpath_common+0x5c/0x7c
[<40013c74>] _warn_slowpath_null+0x18/0x2c
[<4001b17c>] ___local_bh_disable+0xc0/0xd0
[<4001b1a0>] _local_bh_disable+0x14/0x28
[<402e57f8>] __raw_spin_lock_bh+0x18/0x54
[<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
[<402580c4>] _dev_get_stats+0xb8/0xc0
[<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
[<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
[<401d66fc>] _dwc_otg_request_done+0xd8/0x220
[<401d928c>] _ep0_complete_request+0x3f4/0x578
[<401d95bc>] _handle_ep0+0x1ac/0x146c
[<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
[<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
[<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
[<40054cf4>] _handle_IRQ_event+0x4c/0x184
[<40057b4c>] _handle_level_irq+0xac/0x15c
[<4000b204>] _metag_soc_irq_demux+0xac/0xb4
[<40002dd4>] _do_IRQ+0x4c/0x78
[<40004000>] _trigger_handler+0x38/0xac
[<40000b18>] ___TBIBoingVec+0xc/0x10
[<40003588>] _cpu_idle+0x54/0x78
no locks held by swapper/0.
---[ end trace 77ac3cfee0ae5b25 ]---
It looks like we are calling spin_lock_bh in the completion function
which is running in hard_irq, I think the driver should defer handling
this msg (and maybe all requests) to a workqueue?
Cheers
Neil
On Wed, Dec 8, 2010 at 3:03 PM, Neil Jones <neiljay@gmail.com> wrote:
> Hi,
>
> Im getting another lockdep warning when using the RNDIS gadget:
>
> WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
> Modules linked in: g_ether
>
> Call trace:
> [<40003bf8>] _show_stack+0x68/0x7c
> [<40003c20>] _dump_stack+0x14/0x28
> [<40013c3c>] _warn_slowpath_common+0x5c/0x7c
> [<40013c74>] _warn_slowpath_null+0x18/0x2c
> [<4001b17c>] ___local_bh_disable+0xc0/0xd0
> [<4001b1a0>] _local_bh_disable+0x14/0x28
> [<402e57f8>] __raw_spin_lock_bh+0x18/0x54
> [<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
> [<402580c4>] _dev_get_stats+0xb8/0xc0
> [<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
> [<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
> [<401d66fc>] _dwc_otg_request_done+0xd8/0x220
> [<401d928c>] _ep0_complete_request+0x3f4/0x578
> [<401d95bc>] _handle_ep0+0x1ac/0x146c
> [<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
> [<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
> [<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
> [<40054cf4>] _handle_IRQ_event+0x4c/0x184
> [<40057b4c>] _handle_level_irq+0xac/0x15c
> [<4000b204>] _metag_soc_irq_demux+0xac/0xb4
> [<40002dd4>] _do_IRQ+0x4c/0x78
> [<40004000>] _trigger_handler+0x38/0xac
> [<40000b18>] ___TBIBoingVec+0xc/0x10
> [<40003588>] _cpu_idle+0x54/0x78
>
> no locks held by swapper/0.
> ---[ end trace 77ac3cfee0ae5b25 ]---
>
> It
>
^ permalink raw reply
* Re: Polling on sockets in kernel space and struct file
From: Martin Lucina @ 2010-12-08 15:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Martin Sustrik, netdev
In-Reply-To: <1291820573.2883.56.camel@edumazet-laptop>
Hi Eric,
oddly enough our BUG at fs/inode.c seems to have gone away; may be a race
of some sort...
> you could call sock_map_fd() then :
>
>
> int fd = sock_map_fd(sock, flags);
> struct file *file = NULL;
>
> if (fd != -1) {
> file = fget(fd);
> sys_close(fd); /* still racy */
> }
>
> if (file) ...
>
> Take a look at net/9p/trans_fd.c
Interesting approach.
We're currently doing the following -- we add this function to
net/socket.c:
int sock_map_anon(struct socket *sock, const char *name, int flags)
{
struct file *newfile;
newfile = anon_inode_getfile(name, &socket_file_ops, sock, flags);
sock->file = newfile;
return 0;
}
and then call it instead of sock_map_fd() from our sock_create():
/* Create peer socket and associated file structure */
rc = sock_create_kern(PF_INET, SOCK_STREAM, IPPROTO_TCP, &sp->peer);
if (rc < 0)
goto out;
rc = sock_map_anon(sp->peer, "[sp]", 0);
if (rc < 0)
goto out_release;
Is this a valid approach to achieve the same thing?
It's not clear what, if anything special we need to do to correctly release
the anonymous inode when we are releasing our socket... is
sock_release(sp->peer) sufficient?
Also, I see in 9p/trans_fd.c that it's using get_file() to increment the
file refcount; do we need to do this for all sockets/files we create in
kernel space or is this only for the sys_close() hack?
Thanks,
-mato
^ permalink raw reply
* Re: [PATCH] ss: Change "do now" to "do not" in ss(8), -n option
From: Stephen Hemminger @ 2010-12-08 15:55 UTC (permalink / raw)
To: Petr Sabata; +Cc: netdev
In-Reply-To: <1291816149-15782-1-git-send-email-psabata@redhat.com>
On Wed, 8 Dec 2010 14:49:09 +0100
Petr Sabata <psabata@redhat.com> wrote:
> A small typo fix.
>
> ---
> man/man8/ss.8 | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/man/man8/ss.8 b/man/man8/ss.8
> index f261cf2..b309df2 100644
> --- a/man/man8/ss.8
> +++ b/man/man8/ss.8
> @@ -26,7 +26,7 @@ Show summary of options.
> Output version information.
> .TP
> .B \-n, \-\-numeric
> -Do now try to resolve service names.
> +Do not try to resolve service names.
> .TP
> .B \-r, \-\-resolve
> Try to resolve numeric address/ports.
applied
--
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-12-03
From: David Miller @ 2010-12-08 16:14 UTC (permalink / raw)
To: linville; +Cc: linux-kernel, netdev, linux-wireless
In-Reply-To: <20101203201602.GE2348@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 3 Dec 2010 15:16:02 -0500
> This is a batch of fixes intended for 2.6.37. There are a number of
> small fixes that speak for themselves. Also included are a small patch
> for ar9170 to advertise Wi-Fi Peer-to-peer capability -- not truly a
> fix, but helpful for those developing the related userland bits and
> harmless to everyone else. There are also some endian related patches
> for ath9k from Felix that are a bit large, but they mostly just refactor
> some tables in order to fix an endian problem that can result in invalid
> regulatory settings on some boxes.
>
> Also includes are some Bluetooth patches via Gustavo Padovan:
>
> "Here goes 3 simple patches intended to 2.6.37. First one is from myself
> and fix some trivial return values. Then we also have a fix from Stefan
> Seyfried on btusb to avoid emitting an err when we USB is autosupended.
> Last, a patch from Bala Shanmugam that fix the firmware loading process
> for the ath3k driver."
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Vladislav Zolotarov @ 2010-12-08 16:24 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1283870637.2270.10.camel@achroite.uk.solarflarecom.com>
> > It's a bit worse than that. Currently one can only append filters, not
> > insert at a given position, as ethtool_rx_ntuple doesn't have an index
> > field. For devices that use TCAMs, where position matters, it's quite an
> > obstacle. It also means one cannot modify an existing filter by specifying
> > a new filter for the same index.
>
> It looks like drivers for devices that use TCAMs should implement the
> RXNFC interface instead.
>
Ben, from ethtool manpage it sounds like RXNFC option defines the way
the RSS hash should be calculated, while SRXNTUPLE is meant to control
the destination Rx queue for a stream specified by a filter/filters. The
semantics for a specification of the steam is also quite different. For
instance, how do u define a rule to drop all packets with source IP
address 192.168.10.200 by means of RXNFC? While with SRXNTUPLE it's
straight forward. So, if I understood the semantics of both interfaces
correctly, there is a very limited range of functionality where they may
replace one another. Pls., correct me if I'm wrong.
I also agree with Dimitris: what we have here is an offload of some
Netfilter functionality to HW. Regardless the HW implementation (TCAM or
not) if it's allowed to configure more than one rule for the same
protocol the ordering of filtering rules is important: for instance if u
change the order of applying the rules in the example below the result
of the filtering for the traffic with both VLAN 4 and destination port
3000 will be different.
ethtool -U ethX flow-type tcp4 vlan 4 action 0
ethtool -U ethX flow-type tcp4 dst-port 3000 action 3
By the way it's also unclear from the ethtool man page if it's allowed
to configure more than one rule for the same protocol. If it's not then
the above example is void... ;) However, if we want to define a proper
filtering interface I think we shouldn't restrict the driver
implementation from defining a set of rules for the same protocol,
allowing not to though.
So, I think that attaching an index to each rule could be a good idea -
this would allow us both inserting rules at the desired positions in the
filtering rule table and editing the existing rules.
It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
last in general may override the decision made based on the hash result.
So, it sounds like applying rules of SRXNTUPLE should come before
applying the RSS logic and only if there was no match RSS should be
applied to that frame. Do I get it right?
Pls., comment.
thanks,
vlad
^ permalink raw reply
* Re: [34/44] Limit sysctl_tcp_mem and sysctl_udp_mem initializers to prevent integer overflows.
From: David Miller @ 2010-12-08 16:25 UTC (permalink / raw)
To: eric.dumazet
Cc: gregkh, torvalds, linux-kernel, stable, stable-review, akpm, alan,
holt, w, netdev, linux-sctp, kuznet, pekkas, jmorris, yoshfuji,
kaber, vladislav.yasevich, sri
In-Reply-To: <1291787445.5324.64.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 08 Dec 2010 06:50:45 +0100
> Le mardi 07 décembre 2010 à 20:16 -0800, Greg KH a écrit :
>> On Tue, Dec 07, 2010 at 05:22:34PM -0800, Linus Torvalds wrote:
>> > On Tue, Dec 7, 2010 at 4:04 PM, Greg KH <gregkh@suse.de> wrote:
>> > >
>> > > From: Robin Holt <holt@sgi.com>
>> > >
>> > > [ Problem was fixed differently upstream. -DaveM ]
>> >
>> > Gaah. I'd really like to see more of a description for things like
>> > this. A commit ID for the alternate fix, or at least a few words about
>> > the different fix or reason why upstream doesn't need the stable
>> > commit.
>>
>> I'll let David confirm this, he's the one who sent it to me :)
>
> upstream uses commit 8d987e5c7510 (net: avoid limits overflow)
>
> This commit is a bit more untrusive for stable kernels :
>
> It depends on :
> a9febbb4bd13 (sysctl: min/max bounds are optional)
> 27b3d80a7b6a (sysctl: fix min/max handling in __do_proc_doulongvec_minmax())
Yep, this is the case. Greg, you can add a reference to:
a9febbb4bd13
27b3d80a7b6a
8d987e5c7510
in my "[ ... ]" in the commit message to clear this up.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: David Miller @ 2010-12-08 16:39 UTC (permalink / raw)
To: vladz; +Cc: bhutchings, dm, peter.p.waskiewicz.jr, netdev
In-Reply-To: <1291825443.31064.193.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 8 Dec 2010 18:24:03 +0200
> I also agree with Dimitris: what we have here is an offload of some
> Netfilter functionality to HW. Regardless the HW implementation (TCAM or
> not) if it's allowed to configure more than one rule for the same
> protocol the ordering of filtering rules is important: for instance if u
> change the order of applying the rules in the example below the result
> of the filtering for the traffic with both VLAN 4 and destination port
> 3000 will be different.
It's not the same, this whole ordering thing you expect in netfilter
land is simply not present in these hardware implementations.
The hardware does a parallel TCAM match lookup, and whatever matches
is used.
Some hardware does link-level protocol lookups first, then L3/L4 later
in the RX path right before computing the hash and selecting an RX
queue.
There really is no ordering available, so let's not pretend it can be
used "just like" netfilter rules.
As per the difference between the various ethtool facilities, this
just represents the fact that whats available to offload differs
per device. The best we can do is encapsulate commonality as best
as we can, but each interface essentially represents what one
major chipset provides.
^ permalink raw reply
* Re: [PATCH net-2.6] CAIF: Fix U5500 compile error for shared memory driver
From: David Miller @ 2010-12-08 16:40 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, kim.xx.lilliestierna
In-Reply-To: <1291144282-2908-1-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Tue, 30 Nov 2010 20:11:22 +0100
> From: Kim Lilliestierna XX <kim.xx.lilliestierna@stericsson.com>
>
> Rearrange pr_fmt so it compiles.
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
From: David Miller @ 2010-12-08 16:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: lkml20101129, greearb, linux-kernel, netdev, jesse, stable
In-Reply-To: <1291200914.2856.546.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 01 Dec 2010 11:55:14 +0100
Greg/-stable, please integrate this patch from Eric into 2.6.36 if you
haven't already done so.
Thanks!
> [PATCH v2 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used.
>
> Normally hardware accelerated vlan packets are quickly dropped if
> there is no corresponding vlan device configured. The one exception
> is promiscuous mode, where we allow all of these packets through so
> they can be picked up by tcpdump. However, this behavior causes a
> crash if we actually try to receive these packets. This fixes that
> crash by ignoring packets with vids not corresponding to a configured
> device in the vlan hwaccel routines and then dropping them before they
> get to consumers in the network stack.
>
> Reported-by: Ben Greear <greearb@candelatech.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Tested-by: Michael Leun <lkml20101129@newton.leun.net>
> ---
> v2: survives to tcpdump :)
>
> net/core/dev.c | 10 ++++++++++
> net/8021q/vlan_core.c | 3 +++
> 2 files changed, 13 insertions(+)
>
> --- linux-2.6.36/net/core/dev.c.orig
> +++ linux-2.6.36/net/core/dev.c
> @@ -2891,6 +2891,15 @@
> ncls:
> #endif
>
> + /* If we got this far with a hardware accelerated VLAN tag, it means
> + * that we were put in promiscuous mode but nobody is interested in
> + * this vid. Drop the packet now to prevent it from getting propagated
> + * to other parts of the stack that won't know how to deal with packets
> + * tagged in this manner.
> + */
> + if (unlikely(vlan_tx_tag_present(skb)))
> + goto bypass;
> +
> /* Handle special case of bridge or macvlan */
> rx_handler = rcu_dereference(skb->dev->rx_handler);
> if (rx_handler) {
> @@ -2927,6 +2936,7 @@
> }
> }
>
> +bypass:
> if (pt_prev) {
> ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
> } else {
> --- linux-2.6.36/net/8021q/vlan_core.c.orig
> +++ linux-2.6.36/net/8021q/vlan_core.c
> @@ -43,6 +43,9 @@
> struct net_device *dev = skb->dev;
> struct vlan_rx_stats *rx_stats;
>
> + if (unlikely(!is_vlan_dev(dev)))
> + return 0;
> +
> skb->dev = vlan_dev_info(dev)->real_dev;
> netif_nit_deliver(skb);
>
>
>
^ permalink raw reply
* Re: [net-next-2.6 PATCH] enic: Bug Fix: Pass napi reference to the isr that services receive queue
From: David Miller @ 2010-12-08 16:52 UTC (permalink / raw)
To: vkolluri; +Cc: netdev, roprabhu, dwang2
In-Reply-To: <20101202070833.4213.8072.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Wed, 01 Dec 2010 23:08:33 -0800
> From: Vasanthy Kolluri <vkolluri@cisco.com>
>
> Pass reference to napi instead of enic device to the isr that services receive queue.
>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>
This is a pretty simple and real bug fix, so I'd rather you resubmit this
targetted for net-2.6 instead of net-next-2.6
It won't apply as-is to net-2.6 because the enic driver version number
is different there.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] atm: lanai: use kernel's '%pM' format option to print MAC
From: David Miller @ 2010-12-08 16:53 UTC (permalink / raw)
To: andy.shevchenko; +Cc: linux-kernel, netdev, chas, linux-atm-general
In-Reply-To: <1291293908-29180-2-git-send-email-andy.shevchenko@gmail.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Thu, 2 Dec 2010 14:45:08 +0200
> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] arcvmac submit #4a.
From: David Miller @ 2010-12-08 17:00 UTC (permalink / raw)
To: andreas.fenkart; +Cc: netdev
In-Reply-To: <1291296112-27784-1-git-send-email-andreas.fenkart@streamunlimited.com>
From: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
Date: Thu, 2 Dec 2010 14:21:52 +0100
>
> Signed-off-by: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
Generates many warnings on 64-bit platforms, also doesn't build on any
platform because it uses interfaces we removed a long time ago
(multicast count and list).
If you want anyone to take your submission seriously, at the very
least you should at least test the build against current sources
before submitting.
drivers/net/arcvmac.c: In function ‘vmac_ioctl’:
drivers/net/arcvmac.c:333: warning: passing argument 2 of ‘phy_mii_ioctl’ from incompatible pointer type
include/linux/phy.h:511: note: expected ‘struct ifreq *’ but argument is of type ‘struct mii_ioctl_data *’
drivers/net/arcvmac.c: In function ‘vmacether_get_drvinfo’:
drivers/net/arcvmac.c:344: warning: format ‘%x’ expects type ‘unsigned int’, but argument 4 has type ‘resource_size_t’
drivers/net/arcvmac.c: In function ‘alloc_buffers_unlocked’:
drivers/net/arcvmac.c:966: warning: cast from pointer to integer of different size
drivers/net/arcvmac.c:966: warning: cast from pointer to integer of different size
drivers/net/arcvmac.c: In function ‘create_multicast_filter’:
drivers/net/arcvmac.c:1260: error: ‘struct net_device’ has no member named ‘mc_count’
drivers/net/arcvmac.c:1264: error: ‘struct net_device’ has no member named ‘mc_list’
drivers/net/arcvmac.c:1264: error: dereferencing pointer to incomplete type
drivers/net/arcvmac.c:1265: error: dereferencing pointer to incomplete type
drivers/net/arcvmac.c: In function ‘vmac_set_multicast_list’:
drivers/net/arcvmac.c:1293: error: ‘struct net_device’ has no member named ‘mc_count’
drivers/net/arcvmac.c: In function ‘vmac_probe’:
drivers/net/arcvmac.c:1438: warning: format ‘%08x’ expects type ‘unsigned int’, bu
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: add slcan driver for serial/USB-serial CAN adapters
From: David Miller @ 2010-12-08 17:04 UTC (permalink / raw)
To: socketcan-fJ+pQTUTwRTk1uMJSBkQmQ
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
alan-qBU/x9rampVanCEyBjwyrvXRex20P6io
In-Reply-To: <4CF80857.1000903-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
From: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Date: Thu, 02 Dec 2010 21:57:59 +0100
> This patch adds support for serial/USB-serial CAN adapters implementing the
> LAWICEL ASCII protocol for CAN frame transport over serial lines.
>
> The driver implements the SLCAN line discipline and is heavily based on the
> slip.c driver. Therefore the code style remains similar to slip.c to be able
> to apply changes of the SLIP driver to the SLCAN driver easily.
>
> For more details see the slcan Kconfig entry.
>
> Signed-off-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] New jhash function
From: David Miller @ 2010-12-08 17:09 UTC (permalink / raw)
To: kadlec; +Cc: linux-kernel, netdev, netfilter-devel, torvalds, rusty
In-Reply-To: <1291379941-31565-1-git-send-email-kadlec@blackhole.kfki.hu>
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date: Fri, 3 Dec 2010 13:38:59 +0100
> The current jhash.h implements the lookup2() hash function by Bob Jenkins.
> However, lookup2() is outdated as Bob wrote a new hash function called
> lookup3(). There is a longer comparison of those two and other hash
> functions at http://burtleburtle.net/bob/hash/doobs.html.
>
> Please consider applying the following patches.
Patch #1 is already in the net-next-2.6 tree, and as long as there are
no major objections to the general crowd (including Rusty et al.) I am
happy to put patch #2 into my tree as well.
Rusty, does the current version of patch #2 look good to you?
Thanks!
^ 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