* 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: bonding: flow control regression [was Re: bridging: flow control regression]
From: Eric Dumazet @ 2010-12-08 13:50 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev, Jay Vosburgh, David S. Miller
In-Reply-To: <20101208132217.GA28040@verge.net.au>
Le mercredi 08 décembre 2010 à 22:22 +0900, Simon Horman a écrit :
> Hi Eric,
>
> do you have any thoughts on this?
>
> I measured the performance impact of your patch on 2.6.37-rc1
> and I can see why early orphaning is a win.
>
> The tests are run over a bond with 3 slaves.
> The bond is in rr-balance mode. Other parameters of interest are:
> MTU=1500
> client,server:tcp_reordering=3(default)
> client:GSO=off,
> client:TSO=off
> server:GRO=off
> server:rx-usecs=3(default)
>
> Without your no early-orphan patch
> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 172.17.60.216 (172.17.60.216) port 0 AF_INET
> Recv Send Send Utilization Service Demand
> Socket Socket Message Elapsed Send Recv Send Recv
> Size Size Size Time Throughput local remote local remote
> bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
>
> 87380 16384 16384 10.00 1621.03 16.31 6.48 1.648 2.621
>
> With your no early-orphan patch
> # netperf -C -c -4 -t TCP_STREAM -H 172.17.60.216
> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 172.17.60.216 (172.17.60.216) port 0 AF_INET
> Recv Send Send Utilization Service Demand
> Socket Socket Message Elapsed Send Recv Send Recv
> Size Size Size Time Throughput local remote local remote
> bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
>
> 87380 16384 16384 10.00 1433.48 9.60 5.45 1.098 2.490
>
It seems strange this makes such big difference with one flow
>
> However in the case of virtualisation I think it is a win to be able to do
> flow control on UDP traffic from guests (using vitio). Am I missing
> something and flow control can be bypassed anyway? If not perhaps making
> the change that your patch makes configurable through proc or ethtool is an
> option?
>
virtio_net start_xmit() does one skb_orphan() anyway, so not doing it
some nano seconds before wont change anything.
Real perf problem is when skb are queued (for example on eth driver TX
ring or qdisc queue), then freed some micro (or milli) seconds later.
Maybe your ethtool suggestion is the way to go, so that we can remove
special "skb_orphans()" that can be done in some drivers : Let core
network stack decide to skb_orphan() itself, not the driver.
^ permalink raw reply
* [PATCH] ss: Change "do now" to "do not" in ss(8), -n option
From: Petr Sabata @ 2010-12-08 13:49 UTC (permalink / raw)
To: netdev; +Cc: Petr Sabata
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.
--
1.7.3.2
^ permalink raw reply related
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Oleg Nesterov @ 2010-12-08 13:41 UTC (permalink / raw)
To: Florian Mickler
Cc: Ingo Molnar, Américo Wang, Dave Chinner, Eric Dumazet,
linux-kernel, netdev
In-Reply-To: <20101208100245.01cf23c5@schatten.dmk.lab>
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.
> > >> > > > In do_exit() with this trace:
> > >> > > >
> > >> > > > [ 1630.782255] ip x ffff88063fcb3600 0 3012 3011 0x00000000
> > >> > > > [ 1630.789121] ffff880631328000 0000000000000046 0000000000000000 ffff880633104380
> > >> > > > [ 1630.796524] 0000000000013600 ffff88062f031fd8 0000000000013600 0000000000013600
> > >> > > > [ 1630.803925] ffff8806313282d8 ffff8806313282e0 ffff880631328000 0000000000013600
> > >> > > > [ 1630.811324] Call Trace:
> > >> > > > [ 1630.813760] [<ffffffff8104a90d>] ? do_exit+0x716/0x724
> > >> > > > [ 1630.818964] [<ffffffff8104a995>] ? do_group_exit+0x7a/0xa4
> > >> > > > [ 1630.824512] [<ffffffff8104a9d1>] ? sys_exit_group+0x12/0x16
> > >> > > > [ 1630.830149] [<ffffffff81009a82>] ? system_call_fastpath+0x16/0x1b
> > >> > > >
> > >> > > > The address comes down to the schedule() call:
> > >> > > >
> > >> > > > (gdb) l *(do_exit+0x716)
> > >> > > > 0xffffffff8104a90d is in do_exit (kernel/exit.c:1034).
> > >> > > > 1029 preempt_disable();
> > >> > > > 1030 exit_rcu();
> > >> > > > 1031 /* causes final put_task_struct in finish_task_switch(). */
> > >> > > > 1032 tsk->state = TASK_DEAD;
> > >> > > > 1033 schedule();
> > >> > > > 1034 BUG();
> > >> > > > 1035 /* Avoid "noreturn function does return". */
> > >> > > > 1036 for (;;)
> > >> > > > 1037 cpu_relax(); /* For when BUG is null */
> > >> > > > 1038 }
Everything is correct. The task is dead, but it wasn't released by its
parent, task_struct (and thus the stack) is still visible.
> > Interesting, the scheduler failed to put the dead task out of
> > run queue, so to me this is likely to be a scheduler bug.
> > I have no idea how sudo can change the behaviour here.
> >
> > Another guess is we need a smp_wmb() before schedule() above.
No, everything looks fine.
For example,
$ perl -le 'print fork || exit; <>'
17436
$ ps 17436
PID TTY STAT TIME COMMAND
17436 pts/22 Z+ 0:00 [perl] <defunct>
$ cat /proc/17436/stack
[<ffffffff8104d3a0>] do_exit+0x6c4/0x6d2
[<ffffffff8104d429>] do_group_exit+0x7b/0xa4
[<ffffffff8104d469>] sys_exit_group+0x17/0x1b
[<ffffffff8100bdb2>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
Oleg.
^ permalink raw reply
* Re: [PATCH 1/5] sysfs: Introducing binary attributes for struct class
From: Jiri Kosina @ 2010-12-08 13:33 UTC (permalink / raw)
To: Stefan Achatz
Cc: Randy Dunlap, Greg Kroah-Hartman, linux-doc, linux-kernel,
linux-input, netdev
In-Reply-To: <1290801449.18750.162.camel@neuromancer>
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?
Thanks.
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: bonding: flow control regression [was Re: bridging: flow control regression]
From: Simon Horman @ 2010-12-08 13:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Jay Vosburgh, David S. Miller
In-Reply-To: <20101106092535.GD5128@verge.net.au>
On Sat, Nov 06, 2010 at 06:25:37PM +0900, Simon Horman wrote:
> On Tue, Nov 02, 2010 at 10:29:45AM +0100, Eric Dumazet wrote:
> > Le mardi 02 novembre 2010 à 17:46 +0900, Simon Horman a écrit :
> >
> > > Thanks Eric, that seems to resolve the problem that I was seeing.
> > >
> > > With your patch I see:
> > >
> > > No bonding
> > >
> > > # netperf -c -4 -t UDP_STREAM -H 172.17.60.216 -l 30 -- -m 1472
> > > UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.17.60.216 (172.17.60.216) port 0 AF_INET
> > > Socket Message Elapsed Messages CPU Service
> > > Size Size Time Okay Errors Throughput Util Demand
> > > bytes bytes secs # # 10^6bits/sec % SU us/KB
> > >
> > > 116736 1472 30.00 2438413 0 957.2 8.52 1.458
> > > 129024 30.00 2438413 957.2 -1.00 -1.000
> > >
> > > With bonding (one slave, the interface used in the test above)
> > >
> > > netperf -c -4 -t UDP_STREAM -H 172.17.60.216 -l 30 -- -m 1472
> > > UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.17.60.216 (172.17.60.216) port 0 AF_INET
> > > Socket Message Elapsed Messages CPU Service
> > > Size Size Time Okay Errors Throughput Util Demand
> > > bytes bytes secs # # 10^6bits/sec % SU us/KB
> > >
> > > 116736 1472 30.00 2438390 0 957.1 8.97 1.535
> > > 129024 30.00 2438390 957.1 -1.00 -1.000
> > >
> >
> >
> > Sure the patch helps when not too many flows are involved, but this is a
> > hack.
> >
> > Say the device queue is 1000 packets, and you run a workload with 2000
> > sockets, it wont work...
> >
> > Or device queue is 1000 packets, one flow, and socket send queue size
> > allows for more than 1000 packets to be 'in flight' (echo 2000000
> > >/proc/sys/net/core/wmem_default) , it wont work too with bonding, only
> > with devices with a qdisc sitting in the first device met after the
> > socket.
>
> True, thanks for pointing that out.
>
> The scenario that I am actually interested in is virtualisation.
> And I believe that your patch helps the vhostnet case (I don't see
> flow control problems with bonding + virtio without vhostnet). However,
> I am unsure if there are also some easy work-arounds to degrade
> flow control in the vhostnet case too.
Hi Eric,
do you have any thoughts on this?
I measured the performance impact of your patch on 2.6.37-rc1
and I can see why early orphaning is a win.
The tests are run over a bond with 3 slaves.
The bond is in rr-balance mode. Other parameters of interest are:
MTU=1500
client,server:tcp_reordering=3(default)
client:GSO=off,
client:TSO=off
server:GRO=off
server:rx-usecs=3(default)
Without your no early-orphan patch
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
172.17.60.216 (172.17.60.216) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
87380 16384 16384 10.00 1621.03 16.31 6.48 1.648 2.621
With your no early-orphan patch
# netperf -C -c -4 -t TCP_STREAM -H 172.17.60.216
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
172.17.60.216 (172.17.60.216) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
87380 16384 16384 10.00 1433.48 9.60 5.45 1.098 2.490
However in the case of virtualisation I think it is a win to be able to do
flow control on UDP traffic from guests (using vitio). Am I missing
something and flow control can be bypassed anyway? If not perhaps making
the change that your patch makes configurable through proc or ethtool is an
option?
^ permalink raw reply
* [patch 1/4] [PATCH] qeth: support ipv6 query arp cache for HiperSockets
From: frank.blaschka @ 2010-12-08 12:57 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Einar Lueck
In-Reply-To: <20101208125757.726629855@de.ibm.com>
[-- Attachment #1: 601-qeth-ipv6-query-arp.diff --]
[-- Type: text/plain, Size: 12515 bytes --]
From: Einar Lueck <elelueck@de.ibm.com>
Function qeth_l3_arp_query now queries for IPv6 addresses, too, if
QETH_QARP_WITH_IPV6 is passed as parameter to the ioctl. HiperSockets
and GuestLAN in HiperSockets mode provide corresponding entries.
Signed-off-by: Einar Lueck <elelueck@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
arch/s390/include/asm/qeth.h | 51 +++++++--
drivers/s390/net/qeth_core_mpc.h | 2
drivers/s390/net/qeth_l3_main.c | 219 +++++++++++++++++++++++++--------------
3 files changed, 187 insertions(+), 85 deletions(-)
--- a/arch/s390/include/asm/qeth.h
+++ b/arch/s390/include/asm/qeth.h
@@ -28,39 +28,70 @@ struct qeth_arp_cache_entry {
__u8 reserved2[32];
} __attribute__ ((packed));
+enum qeth_arp_ipaddrtype {
+ QETHARP_IP_ADDR_V4 = 1,
+ QETHARP_IP_ADDR_V6 = 2,
+};
+struct qeth_arp_entrytype {
+ __u8 mac;
+ __u8 ip;
+} __attribute__((packed));
+
+#define QETH_QARP_MEDIASPECIFIC_BYTES 32
+#define QETH_QARP_MACADDRTYPE_BYTES 1
struct qeth_arp_qi_entry7 {
- __u8 media_specific[32];
- __u8 macaddr_type;
- __u8 ipaddr_type;
+ __u8 media_specific[QETH_QARP_MEDIASPECIFIC_BYTES];
+ struct qeth_arp_entrytype type;
__u8 macaddr[6];
__u8 ipaddr[4];
} __attribute__((packed));
+struct qeth_arp_qi_entry7_ipv6 {
+ __u8 media_specific[QETH_QARP_MEDIASPECIFIC_BYTES];
+ struct qeth_arp_entrytype type;
+ __u8 macaddr[6];
+ __u8 ipaddr[16];
+} __attribute__((packed));
+
struct qeth_arp_qi_entry7_short {
- __u8 macaddr_type;
- __u8 ipaddr_type;
+ struct qeth_arp_entrytype type;
__u8 macaddr[6];
__u8 ipaddr[4];
} __attribute__((packed));
+struct qeth_arp_qi_entry7_short_ipv6 {
+ struct qeth_arp_entrytype type;
+ __u8 macaddr[6];
+ __u8 ipaddr[16];
+} __attribute__((packed));
+
struct qeth_arp_qi_entry5 {
- __u8 media_specific[32];
- __u8 macaddr_type;
- __u8 ipaddr_type;
+ __u8 media_specific[QETH_QARP_MEDIASPECIFIC_BYTES];
+ struct qeth_arp_entrytype type;
__u8 ipaddr[4];
} __attribute__((packed));
+struct qeth_arp_qi_entry5_ipv6 {
+ __u8 media_specific[QETH_QARP_MEDIASPECIFIC_BYTES];
+ struct qeth_arp_entrytype type;
+ __u8 ipaddr[16];
+} __attribute__((packed));
+
struct qeth_arp_qi_entry5_short {
- __u8 macaddr_type;
- __u8 ipaddr_type;
+ struct qeth_arp_entrytype type;
__u8 ipaddr[4];
} __attribute__((packed));
+struct qeth_arp_qi_entry5_short_ipv6 {
+ struct qeth_arp_entrytype type;
+ __u8 ipaddr[16];
+} __attribute__((packed));
/*
* can be set by user if no "media specific information" is wanted
* -> saves a lot of space in user space buffer
*/
#define QETH_QARP_STRIP_ENTRIES 0x8000
+#define QETH_QARP_WITH_IPV6 0x4000
#define QETH_QARP_REQUEST_MASK 0x00ff
/* data sent to user space as result of query arp ioctl */
--- a/drivers/s390/net/qeth_core_mpc.h
+++ b/drivers/s390/net/qeth_core_mpc.h
@@ -333,7 +333,7 @@ struct qeth_arp_query_data {
__u16 request_bits;
__u16 reply_bits;
__u32 no_entries;
- char data;
+ char data; /* only for replies */
} __attribute__((packed));
/* used as parameter for arp_query reply */
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -30,6 +30,7 @@
#include "qeth_l3.h"
+
static int qeth_l3_set_offline(struct ccwgroup_device *);
static int qeth_l3_recover(void *);
static int qeth_l3_stop(struct net_device *);
@@ -2455,22 +2456,46 @@ static int qeth_l3_arp_set_no_entries(st
return rc;
}
-static void qeth_l3_copy_arp_entries_stripped(struct qeth_arp_query_info *qinfo,
- struct qeth_arp_query_data *qdata, int entry_size,
- int uentry_size)
-{
- char *entry_ptr;
- char *uentry_ptr;
- int i;
-
- entry_ptr = (char *)&qdata->data;
- uentry_ptr = (char *)(qinfo->udata + qinfo->udata_offset);
- for (i = 0; i < qdata->no_entries; ++i) {
- /* strip off 32 bytes "media specific information" */
- memcpy(uentry_ptr, (entry_ptr + 32), entry_size - 32);
- entry_ptr += entry_size;
- uentry_ptr += uentry_size;
+static __u32 get_arp_entry_size(struct qeth_card *card,
+ struct qeth_arp_query_data *qdata,
+ struct qeth_arp_entrytype *type, __u8 strip_entries)
+{
+ __u32 rc;
+ __u8 is_hsi;
+
+ is_hsi = qdata->reply_bits == 5;
+ if (type->ip == QETHARP_IP_ADDR_V4) {
+ QETH_CARD_TEXT(card, 4, "arpev4");
+ if (strip_entries) {
+ rc = is_hsi ? sizeof(struct qeth_arp_qi_entry5_short) :
+ sizeof(struct qeth_arp_qi_entry7_short);
+ } else {
+ rc = is_hsi ? sizeof(struct qeth_arp_qi_entry5) :
+ sizeof(struct qeth_arp_qi_entry7);
+ }
+ } else if (type->ip == QETHARP_IP_ADDR_V6) {
+ QETH_CARD_TEXT(card, 4, "arpev6");
+ if (strip_entries) {
+ rc = is_hsi ?
+ sizeof(struct qeth_arp_qi_entry5_short_ipv6) :
+ sizeof(struct qeth_arp_qi_entry7_short_ipv6);
+ } else {
+ rc = is_hsi ?
+ sizeof(struct qeth_arp_qi_entry5_ipv6) :
+ sizeof(struct qeth_arp_qi_entry7_ipv6);
+ }
+ } else {
+ QETH_CARD_TEXT(card, 4, "arpinv");
+ rc = 0;
}
+
+ return rc;
+}
+
+static int arpentry_matches_prot(struct qeth_arp_entrytype *type, __u16 prot)
+{
+ return (type->ip == QETHARP_IP_ADDR_V4 && prot == QETH_PROT_IPV4) ||
+ (type->ip == QETHARP_IP_ADDR_V6 && prot == QETH_PROT_IPV6);
}
static int qeth_l3_arp_query_cb(struct qeth_card *card,
@@ -2479,72 +2504,77 @@ static int qeth_l3_arp_query_cb(struct q
struct qeth_ipa_cmd *cmd;
struct qeth_arp_query_data *qdata;
struct qeth_arp_query_info *qinfo;
- int entry_size;
- int uentry_size;
int i;
+ int e;
+ int entrybytes_done;
+ int stripped_bytes;
+ __u8 do_strip_entries;
- QETH_CARD_TEXT(card, 4, "arpquecb");
+ QETH_CARD_TEXT(card, 3, "arpquecb");
qinfo = (struct qeth_arp_query_info *) reply->param;
cmd = (struct qeth_ipa_cmd *) data;
+ QETH_CARD_TEXT_(card, 4, "%i", cmd->hdr.prot_version);
if (cmd->hdr.return_code) {
- QETH_CARD_TEXT_(card, 4, "qaer1%i", cmd->hdr.return_code);
+ QETH_CARD_TEXT(card, 4, "arpcberr");
+ QETH_CARD_TEXT_(card, 4, "%i", cmd->hdr.return_code);
return 0;
}
if (cmd->data.setassparms.hdr.return_code) {
cmd->hdr.return_code = cmd->data.setassparms.hdr.return_code;
- QETH_CARD_TEXT_(card, 4, "qaer2%i", cmd->hdr.return_code);
+ QETH_CARD_TEXT(card, 4, "setaperr");
+ QETH_CARD_TEXT_(card, 4, "%i", cmd->hdr.return_code);
return 0;
}
qdata = &cmd->data.setassparms.data.query_arp;
- switch (qdata->reply_bits) {
- case 5:
- uentry_size = entry_size = sizeof(struct qeth_arp_qi_entry5);
- if (qinfo->mask_bits & QETH_QARP_STRIP_ENTRIES)
- uentry_size = sizeof(struct qeth_arp_qi_entry5_short);
- break;
- case 7:
- /* fall through to default */
- default:
- /* tr is the same as eth -> entry7 */
- uentry_size = entry_size = sizeof(struct qeth_arp_qi_entry7);
- if (qinfo->mask_bits & QETH_QARP_STRIP_ENTRIES)
- uentry_size = sizeof(struct qeth_arp_qi_entry7_short);
- break;
- }
- /* check if there is enough room in userspace */
- if ((qinfo->udata_len - qinfo->udata_offset) <
- qdata->no_entries * uentry_size){
- QETH_CARD_TEXT_(card, 4, "qaer3%i", -ENOMEM);
- cmd->hdr.return_code = -ENOMEM;
- goto out_error;
- }
- QETH_CARD_TEXT_(card, 4, "anore%i",
- cmd->data.setassparms.hdr.number_of_replies);
- QETH_CARD_TEXT_(card, 4, "aseqn%i", cmd->data.setassparms.hdr.seq_no);
QETH_CARD_TEXT_(card, 4, "anoen%i", qdata->no_entries);
- if (qinfo->mask_bits & QETH_QARP_STRIP_ENTRIES) {
- /* strip off "media specific information" */
- qeth_l3_copy_arp_entries_stripped(qinfo, qdata, entry_size,
- uentry_size);
- } else
- /*copy entries to user buffer*/
- memcpy(qinfo->udata + qinfo->udata_offset,
- (char *)&qdata->data, qdata->no_entries*uentry_size);
+ do_strip_entries = (qinfo->mask_bits & QETH_QARP_STRIP_ENTRIES) > 0;
+ stripped_bytes = do_strip_entries ? QETH_QARP_MEDIASPECIFIC_BYTES : 0;
+ entrybytes_done = 0;
+ for (e = 0; e < qdata->no_entries; ++e) {
+ char *cur_entry;
+ __u32 esize;
+ struct qeth_arp_entrytype *etype;
+
+ cur_entry = &qdata->data + entrybytes_done;
+ etype = &((struct qeth_arp_qi_entry5 *) cur_entry)->type;
+ if (!arpentry_matches_prot(etype, cmd->hdr.prot_version)) {
+ QETH_CARD_TEXT(card, 4, "pmis");
+ QETH_CARD_TEXT_(card, 4, "%i", etype->ip);
+ break;
+ }
+ esize = get_arp_entry_size(card, qdata, etype,
+ do_strip_entries);
+ QETH_CARD_TEXT_(card, 5, "esz%i", esize);
+ if (!esize)
+ break;
+
+ if ((qinfo->udata_len - qinfo->udata_offset) < esize) {
+ QETH_CARD_TEXT_(card, 4, "qaer3%i", -ENOMEM);
+ cmd->hdr.return_code = -ENOMEM;
+ goto out_error;
+ }
- qinfo->no_entries += qdata->no_entries;
- qinfo->udata_offset += (qdata->no_entries*uentry_size);
+ memcpy(qinfo->udata + qinfo->udata_offset,
+ &qdata->data + entrybytes_done + stripped_bytes,
+ esize);
+ entrybytes_done += esize + stripped_bytes;
+ qinfo->udata_offset += esize;
+ ++qinfo->no_entries;
+ }
/* check if all replies received ... */
if (cmd->data.setassparms.hdr.seq_no <
cmd->data.setassparms.hdr.number_of_replies)
return 1;
+ QETH_CARD_TEXT_(card, 4, "nove%i", qinfo->no_entries);
memcpy(qinfo->udata, &qinfo->no_entries, 4);
/* keep STRIP_ENTRIES flag so the user program can distinguish
* stripped entries from normal ones */
if (qinfo->mask_bits & QETH_QARP_STRIP_ENTRIES)
qdata->reply_bits |= QETH_QARP_STRIP_ENTRIES;
memcpy(qinfo->udata + QETH_QARP_MASK_OFFSET, &qdata->reply_bits, 2);
+ QETH_CARD_TEXT_(card, 4, "rc%i", 0);
return 0;
out_error:
i = 0;
@@ -2567,45 +2597,86 @@ static int qeth_l3_send_ipa_arp_cmd(stru
reply_cb, reply_param);
}
-static int qeth_l3_arp_query(struct qeth_card *card, char __user *udata)
+static int qeth_l3_query_arp_cache_info(struct qeth_card *card,
+ enum qeth_prot_versions prot,
+ struct qeth_arp_query_info *qinfo)
{
struct qeth_cmd_buffer *iob;
- struct qeth_arp_query_info qinfo = {0, };
+ struct qeth_ipa_cmd *cmd;
int tmp;
int rc;
+ QETH_CARD_TEXT_(card, 3, "qarpipv%i", prot);
+
+ iob = qeth_l3_get_setassparms_cmd(card, IPA_ARP_PROCESSING,
+ IPA_CMD_ASS_ARP_QUERY_INFO,
+ sizeof(struct qeth_arp_query_data) - sizeof(char),
+ prot);
+ cmd = (struct qeth_ipa_cmd *)(iob->data+IPA_PDU_HEADER_SIZE);
+ cmd->data.setassparms.data.query_arp.request_bits = 0x000F;
+ cmd->data.setassparms.data.query_arp.reply_bits = 0;
+ cmd->data.setassparms.data.query_arp.no_entries = 0;
+ rc = qeth_l3_send_ipa_arp_cmd(card, iob,
+ QETH_SETASS_BASE_LEN+QETH_ARP_CMD_LEN,
+ qeth_l3_arp_query_cb, (void *)qinfo);
+ if (rc) {
+ tmp = rc;
+ QETH_DBF_MESSAGE(2,
+ "Error while querying ARP cache on %s: %s "
+ "(0x%x/%d)\n", QETH_CARD_IFNAME(card),
+ qeth_l3_arp_get_error_cause(&rc), tmp, tmp);
+ }
+
+ return rc;
+}
+
+static int qeth_l3_arp_query(struct qeth_card *card, char __user *udata)
+{
+ struct qeth_arp_query_info qinfo = {0, };
+ int rc;
+
QETH_CARD_TEXT(card, 3, "arpquery");
if (!qeth_is_supported(card,/*IPA_QUERY_ARP_ADDR_INFO*/
IPA_ARP_PROCESSING)) {
- return -EOPNOTSUPP;
+ QETH_CARD_TEXT(card, 3, "arpqnsup");
+ rc = -EOPNOTSUPP;
+ goto out;
}
/* get size of userspace buffer and mask_bits -> 6 bytes */
- if (copy_from_user(&qinfo, udata, 6))
- return -EFAULT;
+ if (copy_from_user(&qinfo, udata, 6)) {
+ rc = -EFAULT;
+ goto out;
+ }
qinfo.udata = kzalloc(qinfo.udata_len, GFP_KERNEL);
- if (!qinfo.udata)
- return -ENOMEM;
+ if (!qinfo.udata) {
+ rc = -ENOMEM;
+ goto out;
+ }
qinfo.udata_offset = QETH_QARP_ENTRIES_OFFSET;
- iob = qeth_l3_get_setassparms_cmd(card, IPA_ARP_PROCESSING,
- IPA_CMD_ASS_ARP_QUERY_INFO,
- sizeof(int), QETH_PROT_IPV4);
-
- rc = qeth_l3_send_ipa_arp_cmd(card, iob,
- QETH_SETASS_BASE_LEN+QETH_ARP_CMD_LEN,
- qeth_l3_arp_query_cb, (void *)&qinfo);
+ rc = qeth_l3_query_arp_cache_info(card, QETH_PROT_IPV4, &qinfo);
if (rc) {
- tmp = rc;
- QETH_DBF_MESSAGE(2, "Error while querying ARP cache on %s: %s "
- "(0x%x/%d)\n", QETH_CARD_IFNAME(card),
- qeth_l3_arp_get_error_cause(&rc), tmp, tmp);
if (copy_to_user(udata, qinfo.udata, 4))
rc = -EFAULT;
+ goto free_and_out;
} else {
- if (copy_to_user(udata, qinfo.udata, qinfo.udata_len))
+#ifdef CONFIG_QETH_IPV6
+ if (qinfo.mask_bits & QETH_QARP_WITH_IPV6) {
+ /* fails in case of GuestLAN QDIO mode */
+ qeth_l3_query_arp_cache_info(card, QETH_PROT_IPV6,
+ &qinfo);
+ }
+#endif
+ if (copy_to_user(udata, qinfo.udata, qinfo.udata_len)) {
+ QETH_CARD_TEXT(card, 4, "qactf");
rc = -EFAULT;
+ goto free_and_out;
+ }
+ QETH_CARD_TEXT_(card, 4, "qacts");
}
+free_and_out:
kfree(qinfo.udata);
+out:
return rc;
}
^ permalink raw reply
* [patch 4/4] [PATCH] qeth: buffer count imbalance
From: frank.blaschka @ 2010-12-08 12:58 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Jan Glauber
In-Reply-To: <20101208125757.726629855@de.ibm.com>
[-- Attachment #1: 137-qeth-buffer-imbalance.diff --]
[-- Type: text/plain, Size: 1110 bytes --]
From: Jan Glauber <jang@linux.vnet.ibm.com>
The used buffers counter is not incremented in case of an error so
the counter can become negative. Increment the used buffers counter
before checking for errors.
Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/qeth_core_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -2840,6 +2840,7 @@ static void qeth_flush_buffers(struct qe
queue->card->perf_stats.outbound_do_qdio_time +=
qeth_get_micros() -
queue->card->perf_stats.outbound_do_qdio_start_time;
+ atomic_add(count, &queue->used_buffers);
if (rc) {
queue->card->stats.tx_errors += count;
/* ignore temporary SIGA errors without busy condition */
@@ -2853,7 +2854,6 @@ static void qeth_flush_buffers(struct qe
qeth_schedule_recovery(queue->card);
return;
}
- atomic_add(count, &queue->used_buffers);
if (queue->card->options.performance_stats)
queue->card->perf_stats.bufs_sent += count;
}
^ permalink raw reply
* [patch 0/4] s390: qeth patches for net-next
From: frank.blaschka @ 2010-12-08 12:57 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390
Hi Dave,
here is another patch set for net-next.
shortlog:
Jan Glauber (1)
qeth: buffer count imbalance
Einar Lueck (2)
qeth: support ipv6 query arp cache for HiperSockets
qeth: support VIPA add/del in offline mode
Frank Blaschka (1)
qeth: l3 add vlan hdr in passthru frames
Thanks,
Frank
^ permalink raw reply
* [patch 2/4] [PATCH] qeth: support VIPA add/del in offline mode
From: frank.blaschka @ 2010-12-08 12:57 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Einar Lueck
In-Reply-To: <20101208125757.726629855@de.ibm.com>
[-- Attachment #1: 605-qeth-vipa-offline.diff --]
[-- Type: text/plain, Size: 908 bytes --]
From: Einar Lueck <elelueck@de.ibm.com>
Only work through the IP adddress to do list if the card is UP or
SOFTSETUP. Enables to configure VIPA add/del in offline mode.
Signed-off-by: Einar Lueck <elelueck@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/qeth_l3_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -456,8 +456,11 @@ static void qeth_l3_set_ip_addr_list(str
QETH_CARD_TEXT(card, 2, "sdiplist");
QETH_CARD_HEX(card, 2, &card, sizeof(void *));
- if (card->options.sniffer)
+ if ((card->state != CARD_STATE_UP &&
+ card->state != CARD_STATE_SOFTSETUP) || card->options.sniffer) {
return;
+ }
+
spin_lock_irqsave(&card->ip_lock, flags);
tbd_list = card->ip_tbd_list;
card->ip_tbd_list = kmalloc(sizeof(struct list_head), GFP_ATOMIC);
^ permalink raw reply
* [patch 3/4] [PATCH] qeth: l3 add vlan hdr in passthru frames
From: frank.blaschka @ 2010-12-08 12:58 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390
In-Reply-To: <20101208125757.726629855@de.ibm.com>
[-- Attachment #1: 606-qeth-vlan-passthru.diff --]
[-- Type: text/plain, Size: 711 bytes --]
From: Frank Blaschka <frank.blaschka@de.ibm.com>
OSA l3 mode is hw accelerated VLAN only for IPv4. Take care we
add the vlan hdr to a passthru frame in the device driver.
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/qeth_l3_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -3115,7 +3115,7 @@ static int qeth_l3_hard_start_xmit(struc
skb_pull(new_skb, ETH_HLEN);
}
- if (ipv == 6 && card->vlangrp &&
+ if (ipv != 4 && card->vlangrp &&
vlan_tx_tag_present(new_skb)) {
skb_push(new_skb, VLAN_HLEN);
skb_copy_to_linear_data(new_skb, new_skb->data + 4, 4);
^ permalink raw reply
* [PATCH net-next 4/4] bnx2x: Update version number and a date.
From: Vladislav Zolotarov @ 2010-12-08 11:43 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev list, Eilon Greenstein
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index abbdf6d..7e4d682 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -20,8 +20,8 @@
* (you will need to reboot afterwards) */
/* #define BNX2X_STOP_ON_ERROR */
-#define DRV_MODULE_VERSION "1.60.00-6"
-#define DRV_MODULE_RELDATE "2010/11/29"
+#define DRV_MODULE_VERSION "1.60.00-7"
+#define DRV_MODULE_RELDATE "2010/12/08"
#define BNX2X_BC_VER 0x040200
#define BNX2X_MULTI_QUEUE
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next 3/4] bnx2x: Fixed a compilation warning
From: Vladislav Zolotarov @ 2010-12-08 11:43 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev list, Eilon Greenstein
bnx2x_src_init_t2() is used only when BCM_CNIC is defined.
So, to avoid a compilation warning, we won't define it unless
BCM_CNIC is defined.
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_init_ops.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_init_ops.h b/drivers/net/bnx2x/bnx2x_init_ops.h
index a306b0e..66df29f 100644
--- a/drivers/net/bnx2x/bnx2x_init_ops.h
+++ b/drivers/net/bnx2x/bnx2x_init_ops.h
@@ -838,7 +838,7 @@ static void bnx2x_qm_init_ptr_table(struct bnx2x *bp, int qm_cid_count,
/****************************************************************************
* SRC initializations
****************************************************************************/
-
+#ifdef BCM_CNIC
/* called during init func stage */
static void bnx2x_src_init_t2(struct bnx2x *bp, struct src_ent *t2,
dma_addr_t t2_mapping, int src_cid_count)
@@ -862,5 +862,5 @@ static void bnx2x_src_init_t2(struct bnx2x *bp, struct src_ent *t2,
U64_HI((u64)t2_mapping +
(src_cid_count-1) * sizeof(struct src_ent)));
}
-
+#endif
#endif /* BNX2X_INIT_OPS_H */
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next 2/4] bnx2x: Use dma_alloc_coherent() semantics for ILT memory allocation
From: Vladislav Zolotarov @ 2010-12-08 11:43 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev list, Eilon Greenstein
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index cfc25cf..abbdf6d 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1336,7 +1336,7 @@ static inline u32 reg_poll(struct bnx2x *bp, u32 reg, u32 expected, int ms,
#define BNX2X_ILT_ZALLOC(x, y, size) \
do { \
- x = pci_alloc_consistent(bp->pdev, size, y); \
+ x = dma_alloc_coherent(&bp->pdev->dev, size, y, GFP_KERNEL); \
if (x) \
memset(x, 0, size); \
} while (0)
@@ -1344,7 +1344,7 @@ static inline u32 reg_poll(struct bnx2x *bp, u32 reg, u32 expected, int ms,
#define BNX2X_ILT_FREE(x, y, size) \
do { \
if (x) { \
- pci_free_consistent(bp->pdev, size, x, y); \
+ dma_free_coherent(&bp->pdev->dev, size, x, y); \
x = NULL; \
y = 0; \
} \
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next 1/4] bnx2x: LSO code was broken on BE platforms
From: Vladislav Zolotarov @ 2010-12-08 11:43 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev list, Eilon Greenstein
Make the LSO code work on BE platforms: parsing_data field of
a parsing BD (PBD) for 57712 was improperly composed which made FW read wrong
values for TCP header's length and offset and, as a result, the corresponding
PCI device was performing bad DMA reads triggering EEH.
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 42 +++++++++++++++++++++++++---------------
1 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index a4555ed..236c00c 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -1795,15 +1795,15 @@ exit_lbl:
}
#endif
-static inline void bnx2x_set_pbd_gso_e2(struct sk_buff *skb,
- struct eth_tx_parse_bd_e2 *pbd,
- u32 xmit_type)
+static inline void bnx2x_set_pbd_gso_e2(struct sk_buff *skb, u32 *parsing_data,
+ u32 xmit_type)
{
- pbd->parsing_data |= cpu_to_le16(skb_shinfo(skb)->gso_size) <<
- ETH_TX_PARSE_BD_E2_LSO_MSS_SHIFT;
+ *parsing_data |= (skb_shinfo(skb)->gso_size <<
+ ETH_TX_PARSE_BD_E2_LSO_MSS_SHIFT) &
+ ETH_TX_PARSE_BD_E2_LSO_MSS;
if ((xmit_type & XMIT_GSO_V6) &&
(ipv6_hdr(skb)->nexthdr == NEXTHDR_IPV6))
- pbd->parsing_data |= ETH_TX_PARSE_BD_E2_IPV6_WITH_EXT_HDR;
+ *parsing_data |= ETH_TX_PARSE_BD_E2_IPV6_WITH_EXT_HDR;
}
/**
@@ -1848,15 +1848,15 @@ static inline void bnx2x_set_pbd_gso(struct sk_buff *skb,
* @return header len
*/
static inline u8 bnx2x_set_pbd_csum_e2(struct bnx2x *bp, struct sk_buff *skb,
- struct eth_tx_parse_bd_e2 *pbd,
- u32 xmit_type)
+ u32 *parsing_data, u32 xmit_type)
{
- pbd->parsing_data |= cpu_to_le16(tcp_hdrlen(skb)/4) <<
- ETH_TX_PARSE_BD_E2_TCP_HDR_LENGTH_DW_SHIFT;
+ *parsing_data |= ((tcp_hdrlen(skb)/4) <<
+ ETH_TX_PARSE_BD_E2_TCP_HDR_LENGTH_DW_SHIFT) &
+ ETH_TX_PARSE_BD_E2_TCP_HDR_LENGTH_DW;
- pbd->parsing_data |= cpu_to_le16(((unsigned char *)tcp_hdr(skb) -
- skb->data) / 2) <<
- ETH_TX_PARSE_BD_E2_TCP_HDR_START_OFFSET_W_SHIFT;
+ *parsing_data |= ((((u8 *)tcp_hdr(skb) - skb->data) / 2) <<
+ ETH_TX_PARSE_BD_E2_TCP_HDR_START_OFFSET_W_SHIFT) &
+ ETH_TX_PARSE_BD_E2_TCP_HDR_START_OFFSET_W;
return skb_transport_header(skb) + tcp_hdrlen(skb) - skb->data;
}
@@ -1925,6 +1925,7 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
struct eth_tx_bd *tx_data_bd, *total_pkt_bd = NULL;
struct eth_tx_parse_bd_e1x *pbd_e1x = NULL;
struct eth_tx_parse_bd_e2 *pbd_e2 = NULL;
+ u32 pbd_e2_parsing_data = 0;
u16 pkt_prod, bd_prod;
int nbd, fp_index;
dma_addr_t mapping;
@@ -2046,8 +2047,9 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
memset(pbd_e2, 0, sizeof(struct eth_tx_parse_bd_e2));
/* Set PBD in checksum offload case */
if (xmit_type & XMIT_CSUM)
- hlen = bnx2x_set_pbd_csum_e2(bp,
- skb, pbd_e2, xmit_type);
+ hlen = bnx2x_set_pbd_csum_e2(bp, skb,
+ &pbd_e2_parsing_data,
+ xmit_type);
} else {
pbd_e1x = &fp->tx_desc_ring[bd_prod].parse_bd_e1x;
memset(pbd_e1x, 0, sizeof(struct eth_tx_parse_bd_e1x));
@@ -2089,10 +2091,18 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
bd_prod = bnx2x_tx_split(bp, fp, tx_buf, &tx_start_bd,
hlen, bd_prod, ++nbd);
if (CHIP_IS_E2(bp))
- bnx2x_set_pbd_gso_e2(skb, pbd_e2, xmit_type);
+ bnx2x_set_pbd_gso_e2(skb, &pbd_e2_parsing_data,
+ xmit_type);
else
bnx2x_set_pbd_gso(skb, pbd_e1x, xmit_type);
}
+
+ /* Set the PBD's parsing_data field if not zero
+ * (for the chips newer than 57711).
+ */
+ if (pbd_e2_parsing_data)
+ pbd_e2->parsing_data = cpu_to_le32(pbd_e2_parsing_data);
+
tx_data_bd = (struct eth_tx_bd *)tx_start_bd;
/* Handle fragmented skb */
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] ipv6: fix nl group when advertising a new link
From: Thomas Graf @ 2010-12-08 10:04 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: David Miller, netdev
In-Reply-To: <4CFF5217.6010601@6wind.com>
On Wed, Dec 08, 2010 at 10:38:31AM +0100, Nicolas Dichtel wrote:
> >From d2ed52e7fcb639470c89045f7b0ce31eb681896a Mon Sep 17 00:00:00 2001
> From: Wang Xuefu <xuefu.wang@6wind.com>
> Date: Wed, 8 Dec 2010 10:24:48 +0100
> Subject: [PATCH] ipv6: fix nl group when advertising a new link
>
> New idev are advertised with NL group RTNLGRP_IPV6_IFADDR, but
> should use RTNLGRP_IPV6_IFINFO.
> Bug was introduced by commit 8d7a76c9.
>
> Signed-off-by: Wang Xuefu <xuefu.wang@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Thomas Graf <tgraf@infradead.org>
^ permalink raw reply
* Re: Fwd: usbnet: Recursive Locking bug ?
From: Neil Jones @ 2010-12-08 9:58 UTC (permalink / raw)
To: David Brownell
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <917120.68161.qm-g47maUHHHF+ORdMXk8NaZPu2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
>>though I seem to have missed a post with the diagnostic saying
>>what lock is being recursed.
[ INFO: possible recursive locking detected ]
2.6.37-rc4+ #1695
---------------------------------------------
ifconfig/536 is trying to acquire lock:
(&(&list->lock)->rlock#2){-.-...}, at: [<401a63bc>] _defer_bh+0x24/0x124
but task is already holding lock:
(&(&list->lock)->rlock#2){-.-...}, at: [<401a5f28>] _unlink_urbs+0x1c/0xa8
other info that might help us debug this:
2 locks held by ifconfig/536:
#0: (rtnl_mutex){+.+.+.}, at: [<4026b4f8>] _rtnl_lock+0x1c/0x2c
#1: (&(&list->lock)->rlock#2){-.-...}, at: [<401a5f28>] _unlink_urbs+0x1c/0xa8
We are using an OTG controller which isn't EHCI compliant and it has to
manage all the queues in software, thus unlinking URBs effectively
becomes synchronous. I cant see an easy solution to this short of modifying
the OTG-HCD driver to defer the unlinking to a workqueue, but even
then its still
possible to get this scenario.
Cheers
Neil
On Wed, Dec 8, 2010 at 4:55 AM, David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> wrote:
> I'll look at this some later, though I seem to
> have missed a post with the diagnostic saying
> what lock is being recursed.
>
> That particular chunk of code has periodically
> turned up problems, and isn't very pretty. But
> the most curious aspect of it is that it seemed
> to shake out HCD-specific behaviors. (We've
> gotten rid of most such code by now, this is a
> slight exception.
>
> Specifically, HCDs that could unlink speedily
> without certain locking patterns (ISTR OHCI and
> EHCI, if not also UHCI) didn't trigger oddness.
> But some other HCDs, with different approaches
> to unlinking URBs, were less happy. ( I was
> likely working with MUSB at the time.)
>
> I spent some time trying to rework that code in
> "usbnet", but no clean-and-obvious solutions
> became apparent when I did that (a few years
> back). Plus, ISTR being the only person to
> find issues (back then), so I couldn't make
> an argument to spend much more time on it.
>
> Hope that helps anyone trying to fix this.
>
> - Dave
>
>
>
--
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
* SEASONAL FINANCIAL LENDER
From: PRIVATE HOME LENDER INC @ 2010-12-08 9:50 UTC (permalink / raw)
To: saff
apply for a loan to establish your business.
our interest is very affordable and our loan process is very fast as well as
percentage rate of 2.5% yearly from $5 000.00 min To $100 000 000.00 max
get back to us on this information below
name
phone
duration
address
amount
regards
private home lender inc
phlmikejackson@gmail.com
mr mike jackson
^ permalink raw reply
* [PATCH] ipv6: fix nl group when advertising a new link
From: Nicolas Dichtel @ 2010-12-08 9:38 UTC (permalink / raw)
To: Thomas Graf, David Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 60 bytes --]
Hi,
please consider the following patch.
Regards,
Nicolas
[-- Attachment #2: 0001-ipv6-fix-nl-group-when-advertising-a-new-link.patch --]
[-- Type: text/x-diff, Size: 1145 bytes --]
>From d2ed52e7fcb639470c89045f7b0ce31eb681896a Mon Sep 17 00:00:00 2001
From: Wang Xuefu <xuefu.wang@6wind.com>
Date: Wed, 8 Dec 2010 10:24:48 +0100
Subject: [PATCH] ipv6: fix nl group when advertising a new link
New idev are advertised with NL group RTNLGRP_IPV6_IFADDR, but
should use RTNLGRP_IPV6_IFINFO.
Bug was introduced by commit 8d7a76c9.
Signed-off-by: Wang Xuefu <xuefu.wang@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index ab70a3f..0f695a1 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4021,11 +4021,11 @@ void inet6_ifinfo_notify(int event, struct inet6_dev *idev)
kfree_skb(skb);
goto errout;
}
- rtnl_notify(skb, net, 0, RTNLGRP_IPV6_IFADDR, NULL, GFP_ATOMIC);
+ rtnl_notify(skb, net, 0, RTNLGRP_IPV6_IFINFO, NULL, GFP_ATOMIC);
return;
errout:
if (err < 0)
- rtnl_set_sk_err(net, RTNLGRP_IPV6_IFADDR, err);
+ rtnl_set_sk_err(net, RTNLGRP_IPV6_IFINFO, err);
}
static inline size_t inet6_prefix_nlmsg_size(void)
--
1.5.6.5
^ permalink raw reply related
* Re: WARNING at local_bh_enable while tcp_retransmit
From: Ilya Loginov @ 2010-12-08 9:36 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev, davem
In-Reply-To: <4CFE9F73.1040203@gmail.com>
On Tue, 07 Dec 2010 21:56:19 +0100
Jarek Poplawski <jarkao2@gmail.com> wrote:
> Hi, isn't any of your drivers disabling irqs on this path?
No. But we are in soft_irq because tcp_retransmit. So, may be,
interrupts were really disabled.
> (If no, what is the kernel version?)
>
> Jarek P.
2.6.34. But this does not matter.
I am afraid of this is common problem in all network drivers using
dev_queue_xmit (for example bonding). I didn't see this problem before,
while I have no retransmits.
--
Ilya Loginov <isloginov@gmail.com>
^ permalink raw reply
* [PATCH] IP checksuming doesn't work on GE0301 option cards
From: Thomas Bogendoerfer @ 2010-12-08 8:21 UTC (permalink / raw)
To: netdev, j.dumon
There is definitly a problem, that some option cards send up broken
IP pakets leading to corrupted IP packets. These corruptions aren't
detected, because the driver claims that the packets are already
checksummed. This change removes the CHECKSUM_UNNECESSARY option
and let IP detect broken data.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
drivers/net/usb/hso.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index b154a94..1f94f92 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -958,10 +958,6 @@ static void packetizeRx(struct hso_net *odev, unsigned char *ip_pkt,
/* Packet is complete. Inject into stack. */
/* We have IP packet here */
odev->skb_rx_buf->protocol = cpu_to_be16(ETH_P_IP);
- /* don't check it */
- odev->skb_rx_buf->ip_summed =
- CHECKSUM_UNNECESSARY;
-
skb_reset_mac_header(odev->skb_rx_buf);
/* Ship it off to the kernel */
^ permalink raw reply related
* Re: [PATCH 2/3] xfrm: Traffic Flow Confidentiality for IPv4 ESP
From: Herbert Xu @ 2010-12-08 9:24 UTC (permalink / raw)
To: Martin Willi; +Cc: linux-crypto, netdev
In-Reply-To: <1291800041.2005.25.camel@martin>
On Wed, Dec 08, 2010 at 10:20:41AM +0100, Martin Willi wrote:
>
> > In particular, why would we need a boundary at all? Setting it to
> > anything other than the PMTU would seem to defeat the purpose of
> > TFC for packets between the boundary and the PMTU.
>
> I don't agree, this highly depends on the traffic on the SA. For a
> general purpose tunnel with TCP flows, PMTU padding is fine. But if
> there are only small packets (maybe SIP+RTP), padding to the PMTU is
> very expensive.
>
> The administrator setting up the SAs probably knows (or even controls
> directly) what traffic it is used for, and might lower the boundary
> accordingly.
OK, that's a good reason.
But you should probably get rid of that unused flag field in
the user-interface and just provide a pad length.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/3] xfrm: Traffic Flow Confidentiality for IPv4 ESP
From: Martin Willi @ 2010-12-08 9:20 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
In-Reply-To: <20101208084954.GA15252@gondor.apana.org.au>
> In particular, why would we need a boundary at all? Setting it to
> anything other than the PMTU would seem to defeat the purpose of
> TFC for packets between the boundary and the PMTU.
I don't agree, this highly depends on the traffic on the SA. For a
general purpose tunnel with TCP flows, PMTU padding is fine. But if
there are only small packets (maybe SIP+RTP), padding to the PMTU is
very expensive.
The administrator setting up the SAs probably knows (or even controls
directly) what traffic it is used for, and might lower the boundary
accordingly.
Regards
Martin
^ permalink raw reply
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Florian Mickler @ 2010-12-08 9:02 UTC (permalink / raw)
To: Ingo Molnar, Oleg Nesterov
Cc: Américo Wang, Dave Chinner, Eric Dumazet, linux-kernel,
netdev
In-Reply-To: <20101104054718.GC5210@cr0.nay.redhat.com>
[ ccing Ingo and Oleg ] as suggested
On Thu, 4 Nov 2010 13:47:18 +0800
Américo Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Nov 04, 2010 at 11:21:40AM +1100, Dave Chinner wrote:
> >On Wed, Nov 03, 2010 at 10:29:36PM +1100, Dave Chinner wrote:
> >> On Wed, Nov 03, 2010 at 09:34:48PM +1100, Dave Chinner wrote:
> >> > On Wed, Nov 03, 2010 at 08:13:22AM +0100, Eric Dumazet wrote:
> >> > > Le mercredi 03 novembre 2010 à 17:26 +1100, Dave Chinner a écrit :
> >> > > > Folks,
> >> > > >
> >> > > > Starting up KVM on a current mainline kernel using the tap
> >> > > > device for the networking is resulting in the ip process tryin gto
> >> > > > up the tap interface hanging. KVM is started with this networking
> >> > > > config:
> >> > > >
> >> > > > ....
> >> > > > -net nic,vlan=0,macaddr=00:e4:b6:63:63:6d,model=virtio \
> >> > > > -net tap,vlan=0,script=/vm-images/qemu-ifup,downscript=no \
> >> > > > ....
> >> > > >
> >> > > > And the script is effectively:
> >> > > >
> >> > > > switch=br0
> >> > > > 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
> >> > > > exit 1
> >> > > >
> >> > > > 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>
> >> > > >
> >> > > > In do_exit() with this trace:
> >> > > >
> >> > > > [ 1630.782255] ip x ffff88063fcb3600 0 3012 3011 0x00000000
> >> > > > [ 1630.789121] ffff880631328000 0000000000000046 0000000000000000 ffff880633104380
> >> > > > [ 1630.796524] 0000000000013600 ffff88062f031fd8 0000000000013600 0000000000013600
> >> > > > [ 1630.803925] ffff8806313282d8 ffff8806313282e0 ffff880631328000 0000000000013600
> >> > > > [ 1630.811324] Call Trace:
> >> > > > [ 1630.813760] [<ffffffff8104a90d>] ? do_exit+0x716/0x724
> >> > > > [ 1630.818964] [<ffffffff8104a995>] ? do_group_exit+0x7a/0xa4
> >> > > > [ 1630.824512] [<ffffffff8104a9d1>] ? sys_exit_group+0x12/0x16
> >> > > > [ 1630.830149] [<ffffffff81009a82>] ? system_call_fastpath+0x16/0x1b
> >> > > >
> >> > > > The address comes down to the schedule() call:
> >> > > >
> >> > > > (gdb) l *(do_exit+0x716)
> >> > > > 0xffffffff8104a90d is in do_exit (kernel/exit.c:1034).
> >> > > > 1029 preempt_disable();
> >> > > > 1030 exit_rcu();
> >> > > > 1031 /* causes final put_task_struct in finish_task_switch(). */
> >> > > > 1032 tsk->state = TASK_DEAD;
> >> > > > 1033 schedule();
> >> > > > 1034 BUG();
> >> > > > 1035 /* Avoid "noreturn function does return". */
> >> > > > 1036 for (;;)
> >> > > > 1037 cpu_relax(); /* For when BUG is null */
> >> > > > 1038 }
> >> > > >
> >> > > > Needless to say, KVM is not starting up. This works just fine on
> >> > > > 2.6.35.1 and so is a regression. I can't do a lot of testing on this as
> >> > > > the host is the machine that hosts all my build and test environments....
> >> > > >
> >> > > > Cheers,
> >> > > >
> >> > > > Dave.
> >> > >
> >> > > Could it be the same problem than
> >> > >
> >> > > http://kerneltrap.com/mailarchive/linux-netdev/2010/10/23/6288128
> >> > >
> >> > > Try to revert bee31369ce16fc3898ec9a54161248c9eddb06bc ?
> >> >
> >> > It's working fine on 2.6.36 right now, so it's something that came in
> >> > with the .37 merge cycle...
> >>
> >> Actually, the machine isn't running a 2.6.36 kernel (it had booted
> >> to the working .35 kernel and I didn't notice). So i've just tested
> >> a 2.6.36 kernel, and the problem _is present_ in 2.6.36. I've
> >> reverted the above commit but that does not fix the problem.
> >
> >Ok, so further investigation has shown I can reproduce this on
> >2.6.32 and 2.6.35. It's not a new bug, nor do I think that it is
> >a networking bug as it is not specific to the ip command.
> >
> >The trigger for the problem is actually an upgrade of the sudo
> >package in debian unstable which changed the behaviour of sudo (has
> >some per-login/pty restriction on it now). Basically, the startup
> >script I'm running does:
> >
> >sudo kvm .....
> >
> >which then executes the qemu-ifup bash script which does:
> >
> > sudo ip ....
> > sudo brctl ...
> >
> >because at one point KVM did not create the tap device automatically
> >and so kvm could be run as a user with only the ifup script
> >requiring privileges to create the tap device and mark it up. When
> >KVM started creating the tap device, I added the sudo to the KVM
> >script, an everything worked again.
> >
> >Now if I take the 'sudo' out of the ifup script, the hang goes away.
> >I first removed it from the ip command, and then the brctl command
> >hung in the same way the ip command was hanging. Hence my thoughts
> >that it is not directly related to networking utilities.
> >Unfortunately, it is not trivial to reproduce as I could only
> >trigger it through this kvm method, not on the command line. e.g:
> >
> >$ sudo bash -c "sudo ip link set tap1 up"
> >
> >does not hang.
> >
> >This sudo package upgrade coincided with kernel upgrades, and so
> >that lead to my confusion about where it occurred and what triggered
> >it. Still, it appears to be a bug that has been around for some
> >time.....
> >
>
> Interesting, the scheduler failed to put the dead task out of
> run queue, so to me this is likely to be a scheduler bug.
> I have no idea how sudo can change the behaviour here.
>
> Another guess is we need a smp_wmb() before schedule() above.
>
> We need to Cc Oleg and Ingo.
> --
> 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
>
>
^ permalink raw reply
* Re: [v3 PATCH 2/2] netpoll: remove IFF_IN_NETPOLL flag
From: Cong Wang @ 2010-12-08 8:52 UTC (permalink / raw)
To: Changli Gao
Cc: linux-kernel, Jiri Pirko, Neil Horman, netdev, David S. Miller,
Eric W. Biederman, Herbert Xu, bonding-devel, Jay Vosburgh,
Stephen Hemminger
In-Reply-To: <AANLkTikdweTkcsxTgf+phRaHYWMb9eAwrtr1xJr+0C1s@mail.gmail.com>
On 12/08/10 16:49, Changli Gao wrote:
> On Wed, Dec 8, 2010 at 4:36 PM, Cong Wang<amwang@redhat.com> wrote:
>>
>> A few lines above that code said:
>>
>> /* Private (from user) interface flags (netdevice->priv_flags). */
>>
>> unless this comment is wrong, we don't need to worry.
>>
>
> It seems these macros are exported to user space wrongly.
>
Maybe we should add #ifdef __KERNEL__ to protect them, I think.
^ 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