Nicolas de Pesloüan | 1 Jan 01:09 2012
Picon

Re: [PATCH] bonding: fix error handling if slave is busy (v2)

Le 01/01/2012 00:26, Stephen Hemminger a écrit :
> If slave device already has a receive handler registered, then the
> error unwind of bonding device enslave function is broken.
>
> The following will leave a pointer to freed memory in the slave
> device list, causing a later kernel panic.
> # modprobe dummy
> # ip li add dummy0-1 link dummy0 type macvlan
> # modprobe bonding
> # echo +dummy0>/sys/class/net/bond0/bonding/slaves
>
> The fix is to detach the slave (which removes it from the list)
> in the unwind path.
>
> Signed-off-by: Stephen Hemminger<shemminger <at> vyatta.com>

Thanks Stephen.

Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian <at> free.fr>

> ---
> v2 - need to keep original err_close for other unwind
>
> --- a/drivers/net/bonding/bond_main.c	2011-12-30 14:20:03.171823181 -0800
> +++ b/drivers/net/bonding/bond_main.c	2011-12-31 15:20:16.493379415 -0800
>  <at>  <at>  -1822,7 +1822,7  <at>  <at>  int bond_enslave(struct net_device *bond
>   				 "but new slave device does not support netpoll.\n",
>   				 bond_dev->name);
>   			res = -EBUSY;
> -			goto err_close;
(Continue reading)

Stephen Hemminger | 1 Jan 01:13 2012

Re: [PATCH] bonding: fix error handling if slave is busy (v2)

On Sun, 01 Jan 2012 01:09:50 +0100
Nicolas de Pesloüan <nicolas.2p.debian <at> gmail.com> wrote:

> Le 01/01/2012 00:26, Stephen Hemminger a écrit :
> > If slave device already has a receive handler registered, then the
> > error unwind of bonding device enslave function is broken.
> >
> > The following will leave a pointer to freed memory in the slave
> > device list, causing a later kernel panic.
> > # modprobe dummy
> > # ip li add dummy0-1 link dummy0 type macvlan
> > # modprobe bonding
> > # echo +dummy0>/sys/class/net/bond0/bonding/slaves
> >
> > The fix is to detach the slave (which removes it from the list)
> > in the unwind path.
> >
> > Signed-off-by: Stephen Hemminger<shemminger <at> vyatta.com>
> 
> Thanks Stephen.
> 
> Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian <at> free.fr>

The locking in bond driver is a tangled web.

Would be cleaner to get rid of bond->lock altogether.
Slave add/delete should be protected by RTNL, and the lookup should
be converted to RCU.  The problem is that bonding driver implements
own form of circular list to handle round-robin etc.

(Continue reading)

Nicolas de Pesloüan | 1 Jan 01:28 2012
Picon

Re: [PATCH] bonding: fix error handling if slave is busy (v2)

Le 01/01/2012 01:13, Stephen Hemminger a écrit :
> On Sun, 01 Jan 2012 01:09:50 +0100
> Nicolas de Pesloüan<nicolas.2p.debian <at> gmail.com>  wrote:
>
>> Le 01/01/2012 00:26, Stephen Hemminger a écrit :
>>> If slave device already has a receive handler registered, then the
>>> error unwind of bonding device enslave function is broken.
>>>
>>> The following will leave a pointer to freed memory in the slave
>>> device list, causing a later kernel panic.
>>> # modprobe dummy
>>> # ip li add dummy0-1 link dummy0 type macvlan
>>> # modprobe bonding
>>> # echo +dummy0>/sys/class/net/bond0/bonding/slaves
>>>
>>> The fix is to detach the slave (which removes it from the list)
>>> in the unwind path.
>>>
>>> Signed-off-by: Stephen Hemminger<shemminger <at> vyatta.com>
>>
>> Thanks Stephen.
>>
>> Reviewed-by: Nicolas de Pesloüan<nicolas.2p.debian <at> free.fr>
>
> The locking in bond driver is a tangled web.
>
> Would be cleaner to get rid of bond->lock altogether.
> Slave add/delete should be protected by RTNL, and the lookup should
> be converted to RCU.  The problem is that bonding driver implements
> own form of circular list to handle round-robin etc.
(Continue reading)

John A. Sullivan III | 1 Jan 03:30 2012

tc filter mask for ACK packets off?

Hello, all.  I've been noticing that virtually all the documentation
says we should prioritize ACK only packets and that they can be
identified with match u8 0x10 0xff.  However, isn't the actual flag
field only 6 bits longs and the first two belong to a previous 6 bit
reserved field?
If that is true, if ever those bits are set, our filters will
unnecessarily break.  Shouldn't it be match u8 0x10 0x3f? Then again,
I'm very new at this.  Thanks - John

John A. Sullivan III | 1 Jan 03:30 2012

tc filter mask for ACK packets off?

Hello, all.  I've been noticing that virtually all the documentation
says we should prioritize ACK only packets and that they can be
identified with match u8 0x10 0xff.  However, isn't the actual flag
field only 6 bits longs and the first two belong to a previous 6 bit
reserved field?
If that is true, if ever those bits are set, our filters will
unnecessarily break.  Shouldn't it be match u8 0x10 0x3f? Then again,
I'm very new at this.  Thanks - John

Bjarke Istrup Pedersen | 1 Jan 13:09 2012
Picon

Re: [PATCH 1/1] via-rhine: Fix hanging with high CPU load on low-end broads.

2011/12/31 Francois Romieu <romieu <at> fr.zoreil.com>:
> Bjarke Istrup Pedersen <gurligebis <at> gentoo.org> :
> [...]
>> Also tried connect a machine to one of the ports, and copying a large
>> file across (something that before could make it lock up within 15
>> secords) - also worked without any problems - CPU usage around 15%
>> (mostly "top" using that), so thats not bad at all.
>>
>> Is there any other testcases that I should try out?
>
> Same thing + random ethtool link management commands.
> Same thing + random cable unplug/plug.
> Same thing + pktgen facing the lan interface.
>
> Everything at the same time.

I tried messing around with plugging cables and playing with ethtool
at the same time, while there was alot of trafic, which went fine :)
Happy new year btw :)

/Bjarke

> --
> Ueimor
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
(Continue reading)

pablo | 1 Jan 17:22 2012

[PATCH] netfilter: nfnetlink_acct: fix nfnl_acct_get operation

From: Pablo Neira Ayuso <pablo <at> netfilter.org>

The get operation was not sending the message that was built to
user-space. This patch also includes the appropriate handling for
the return value of netlink_unicast().

Moreover, fix error codes on error (for example, for non-existing
entry was uncorrect).

Signed-off-by: Pablo Neira Ayuso <pablo <at> netfilter.org>
---
 net/netfilter/nfnetlink_acct.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/net/netfilter/nfnetlink_acct.c b/net/netfilter/nfnetlink_acct.c
index 362ab6c..11ba013 100644
--- a/net/netfilter/nfnetlink_acct.c
+++ b/net/netfilter/nfnetlink_acct.c
 <at>  <at>  -166,7 +166,7  <at>  <at>  static int
 nfnl_acct_get(struct sock *nfnl, struct sk_buff *skb,
 	     const struct nlmsghdr *nlh, const struct nlattr * const tb[])
 {
-	int ret = 0;
+	int ret = -ENOENT;
 	struct nf_acct *cur;
 	char *acct_name;

 <at>  <at>  -186,17 +186,26  <at>  <at>  nfnl_acct_get(struct sock *nfnl, struct sk_buff *skb,
 			continue;

(Continue reading)

pablo | 1 Jan 17:22 2012

[PATCH] fix for nfacct infrastructure in net-next

From: Pablo Neira Ayuso <pablo <at> netfilter.org>

Hi Dave,

Please, pull the following fix for the nfacct infrastructure already
in your net-next tree.

You can pull it from:

git://1984.lsi.us.es/net-net nf-next

Thanks!

Pablo Neira Ayuso (1):
  netfilter: nfnetlink_acct: fix nfnl_acct_get operation

 net/netfilter/nfnetlink_acct.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

--

-- 
1.7.7.3

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pablo Neira Ayuso | 1 Jan 17:23 2012

Re: [PATCH] fix for nfacct infrastructure in net-next

On Sun, Jan 01, 2012 at 05:22:24PM +0100, pablo <at> netfilter.org wrote:
> From: Pablo Neira Ayuso <pablo <at> netfilter.org>
> 
> Hi Dave,
> 
> Please, pull the following fix for the nfacct infrastructure already
> in your net-next tree.
> 
> You can pull it from:
> 
> git://1984.lsi.us.es/net-net nf-next
                       ^^^^^^^
I meant to say net-next, of course.

Sorry.
Bjarke Istrup Pedersen | 1 Jan 22:15 2012
Picon

Re: [PATCH 1/1] via-rhine: Fix hanging with high CPU load on low-end broads.

2011/12/31 Francois Romieu <romieu <at> fr.zoreil.com>:
> Bjarke Istrup Pedersen <gurligebis <at> gentoo.org> :
> [...]
>> Also tried connect a machine to one of the ports, and copying a large
>> file across (something that before could make it lock up within 15
>> secords) - also worked without any problems - CPU usage around 15%
>> (mostly "top" using that), so thats not bad at all.
>>
>> Is there any other testcases that I should try out?
>
> Same thing + random ethtool link management commands.
> Same thing + random cable unplug/plug.
> Same thing + pktgen facing the lan interface.
>
> Everything at the same time.

Btw. - I have split up the via-rhine.c file (with all the changes you
have sent me) into via-rhine.c and via-rhine.h , like it should be :-)
I'll send it shortly after this mail - could you incorporate it into your work?

/Bjarke

> --
> Ueimor
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
(Continue reading)


Gmane