* Re: [PATCH v3 7/8] cgroup: Assign subsystem IDs during compile time
From: Tejun Heo @ 2012-09-11 21:36 UTC (permalink / raw)
To: Daniel Wagner
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, David S. Miller, Andrew Morton, Eric Dumazet,
Gao feng, Glauber Costa, Jamal Hadi Salim, John Fastabend,
Kamezawa Hiroyuki, Li Zefan, Neil Horman
In-Reply-To: <504FADC1.4060503-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
Hello, Daniel.
On Tue, Sep 11, 2012 at 11:31:45PM +0200, Daniel Wagner wrote:
> >Oops, that was wrong. net_prio_subsys_id itself becomes constant.
> >Let's please better explain why the RCU trick removal is safe then.
>
> In the last paragraph in the commit message I tried to document why
> it is safe to remove the RCU trick. Not good enough?
It isn't clear to me why it was necessary before and why it now
becomes unnecessary. It states what the code does and that it's no
longer necessary but I'd really like more elaboration.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v3 7/8] cgroup: Assign subsystem IDs during compile time
From: Daniel Wagner @ 2012-09-11 21:39 UTC (permalink / raw)
To: Tejun Heo
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, David S. Miller, Andrew Morton, Eric Dumazet,
Gao feng, Glauber Costa, Jamal Hadi Salim, John Fastabend,
Kamezawa Hiroyuki, Li Zefan, Neil Horman
In-Reply-To: <20120911213646.GF7677-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Hi Tejun,
On 09/11/2012 11:36 PM, Tejun Heo wrote:
> On Tue, Sep 11, 2012 at 11:31:45PM +0200, Daniel Wagner wrote:
>>> Oops, that was wrong. net_prio_subsys_id itself becomes constant.
>>> Let's please better explain why the RCU trick removal is safe then.
>>
>> In the last paragraph in the commit message I tried to document why
>> it is safe to remove the RCU trick. Not good enough?
>
> It isn't clear to me why it was necessary before and why it now
> becomes unnecessary. It states what the code does and that it's no
> longer necessary but I'd really like more elaboration.
Got it. I'll try to document then why it was necessary before. I'll add
then also the original author of those lines to the Cc list just in case
I get it wrong.
cheers,
daniel
^ permalink raw reply
* Re: [PATCH] scsi_netlink: Remove dead and buggy code
From: Eric W. Biederman @ 2012-09-11 22:40 UTC (permalink / raw)
To: James Bottomley; +Cc: David Miller, netdev, James.Smart, linux-scsi
In-Reply-To: <1347314879.3038.74.camel@dabdike.int.hansenpartnership.com>
James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> On Mon, 2012-09-10 at 15:07 -0400, David Miller wrote:
>> From: ebiederm@xmission.com (Eric W. Biederman)
>> Date: Fri, 07 Sep 2012 15:39:21 -0700
>>
>> >
>> > The scsi netlink code confuses the netlink port id with a process id,
>> > going so far as to read NETLINK_CREDS(skb)->pid instead of the correct
>> > NETLINK_CB(skb).pid. Fortunately it does not matter because nothing
>> > registers to respond to scsi netlink requests.
>> >
>> > The only interesting use of the scsi_netlink interface is
>> > fc_host_post_vendor_event which sends a netlink multicast message.
>> >
>> > Since nothing registers to handle scsi netlink messages kill all of the
>> > registration logic, while retaining the same error handling behavior
>> > preserving the userspace visible behavior and removing all of the
>> > confused code that thought a netlink port id was a process id.
>> >
>> > This was tested with a kernel allyesconfig build which had no problems.
>> >
>> > Cc: James Bottomley <James.Bottomley@parallels.com>
>> > Cc: James Smart <James.Smart@Emulex.Com>
>> > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>
>> James et al., please review and ACK.
>
> I'll defer to the decision of James Smart and the other FC contributors,
> since the FC transport class is really the only one using a netlink
> interface.
So just for curiosity I searched the entire git history for scsi_nl_add_
and the only commit that I found was the addition of that code to the
tree in August of 2008.
Does anyone have any reason to keep scsi_nl_add_transport or
scsi_nl_add_driver that have never been used in the 4 years since
they have been added?
Eric
^ permalink raw reply
* Re: [PATCH] scsi_netlink: Remove dead and buggy code
From: David Miller @ 2012-09-11 22:48 UTC (permalink / raw)
To: ebiederm; +Cc: James.Bottomley, netdev, James.Smart, linux-scsi
In-Reply-To: <878vcggp4n.fsf@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 11 Sep 2012 15:40:08 -0700
> So just for curiosity I searched the entire git history for scsi_nl_add_
> and the only commit that I found was the addition of that code to the
> tree in August of 2008.
>
> Does anyone have any reason to keep scsi_nl_add_transport or
> scsi_nl_add_driver that have never been used in the 4 years since
> they have been added?
That's basically the question on the table right now :-)
^ permalink raw reply
* Re: CBQ(but probably u32 filter bug), kernel "freeze", at least from 3.2.0
From: Denys Fedoryshchenko @ 2012-09-11 22:50 UTC (permalink / raw)
To: netdev, Eric Dumazet
>No problem, I reproduced the bug on my dev machine, but its always
>better to have bug reporter adding its own 'Tested-by:' tag ;)
>
>Thanks
Tested-by: Denys Fedoryschenko <denys@visp.net.lb>
Thank you a lot, it fixes the problem!
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* [PATCH] net-sched: sch_cbq: avoid infinite loop
From: Eric Dumazet @ 2012-09-11 23:11 UTC (permalink / raw)
To: Denys Fedoryshchenko, David Miller; +Cc: netdev
In-Reply-To: <ceeee25e4588b250ce7b363afe97a489@visp.net.lb>
From: Eric Dumazet <edumazet@google.com>
Its possible to setup a bad cbq configuration leading to
an infinite loop in cbq_classify()
DEV_OUT=eth0
ICMP="match ip protocol 1 0xff"
U32="protocol ip u32"
DST="match ip dst"
tc qdisc add dev $DEV_OUT root handle 1: cbq avpkt 1000 \
bandwidth 100mbit
tc class add dev $DEV_OUT parent 1: classid 1:1 cbq \
rate 512kbit allot 1500 prio 5 bounded isolated
tc filter add dev $DEV_OUT parent 1: prio 3 $U32 \
$ICMP $DST 192.168.3.234 flowid 1:
Reported-by: Denys Fedoryschenko <denys@visp.net.lb>
Tested-by: Denys Fedoryschenko <denys@visp.net.lb>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/sched/sch_cbq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index 6aabd77..564b9fc 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -250,10 +250,11 @@ cbq_classify(struct sk_buff *skb, struct Qdisc *sch, int *qerr)
else if ((cl = defmap[res.classid & TC_PRIO_MAX]) == NULL)
cl = defmap[TC_PRIO_BESTEFFORT];
- if (cl == NULL || cl->level >= head->level)
+ if (cl == NULL)
goto fallback;
}
-
+ if (cl->level >= head->level)
+ goto fallback;
#ifdef CONFIG_NET_CLS_ACT
switch (result) {
case TC_ACT_QUEUED:
^ permalink raw reply related
* [PATCH] net_tx_action: Call trace_consume_skb() instead of trace_kfree_skb()
From: Shawn Bohrer @ 2012-09-11 23:28 UTC (permalink / raw)
To: netdev; +Cc: sanagi.koki, davem, eric.dumazet, Shawn Bohrer
Call trace_consume_skb() instead of trace_kfree_skb() as skbs are
removed from the completion_queue during transmit. This avoids false
positives from dropwatch/drop_monitor making them more useful.
Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
---
In my case I seem to hit this tracepoint for every packet I transmit so
these appear to be false positives to me. Perhaps there are cases where
you could hit this and it is a real packet drop?
net/core/dev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 8398836..00774ce 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3015,7 +3015,7 @@ static void net_tx_action(struct softirq_action *h)
clist = clist->next;
WARN_ON(atomic_read(&skb->users));
- trace_kfree_skb(skb, net_tx_action);
+ trace_consume_skb(skb);
__kfree_skb(skb);
}
}
--
1.7.7.6
--
---------------------------------------------------------------
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
^ permalink raw reply related
* Re: [PATCHv4] virtio-spec: virtio network device multiqueue support
From: Rusty Russell @ 2012-09-12 0:29 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, netdev, rick.jones2, virtualization, levinsasha928, pbonzini,
Tom Herbert
In-Reply-To: <20120910061629.GC16819@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> In other words RPS is a hack to speed up networking on cheapo
> hardware, this is one of the reasons it is off by default.
> Good hardware has multiple receive queues.
> We can implement a good one so we do not need RPS.
>
> Also not all guest OS-es support RPS.
>
> Does this clarify?
Ok, thanks.
BTW, I found a better description by Tom Herbert, BTW:
https://code.google.com/p/kernel/wiki/NetScalingGuide
Now, I find the description of VIRTIO_NET_CTRL_STEERING_RX_FOLLOWS_TX
confusing:
1) AFAICT it turns on multiqueue rx, with no semantics attached.
I have no idea why it's called what it is. Why?
2) We've said we can remove steering methods, but we haven't actually
defined any, as we've left it completely open.
If I were a driver author, it leaves me completely baffled on how to
implement the spec :(
What are we actually planning to implement at the moment?
>For best performance, packets from a single connection should utilize
>the paired transmit and receive queues from the same virtqueue pair;
>for example both transmitqN and receiveqN. This rule makes it possible
>to optimize processing on the device side, but this is not a hard
>requirement: devices should function correctly even when this rule is
>not followed.
Why is this true? I don't actually see why the queues are in pairs at
all; are tx and rx not completely independent? So why does it matter?
>> When the steering rule is modified, some packets can still be
>> outstanding in one or more of the virtqueues. Device is not required
>> to wait for these packets to be consumed before delivering packets
>> using the new streering rule. Drivers modifying the steering rule at
>> a high rate (e.g. adaptively in response to changes in the workload)
>> are recommended to complete processing of the receive queue(s)
>> utilized by the original steering before processing any packets
>> delivered by the modified steering rule.
How can this be done? This isn't actually possible without taking the
queue down, since more packets are incoming.
Cheers,
Rusty.
^ permalink raw reply
* [PATCH] checkpatch: Check networking specific block comment style
From: Joe Perches @ 2012-09-12 0:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: Andy Whitcroft, David Miller, LKML, netdev
In an effort to get fewer checkpatch reviewer corrections,
add a networking specific style test for the preferred
networking comment style.
/* The preferred style for block comments in
* drivers/net/... and net/... is like this
*/
These tests are only used in net/ and drivers/net/
Tested with:
$ cat drivers/net/t.c
/* foo */
/*
* foo
*/
/* foo
*/
/* foo
* bar */
$ ./scripts/checkpatch.pl -f drivers/net/t.c
WARNING: networking block comments don't use an empty /* line, use /* Comment...
#4: FILE: net/t.c:4:
+
+/*
WARNING: networking block comments put the trailing */ on a separate line
#12: FILE: net/t.c:12:
+ * bar */
total: 0 errors, 2 warnings, 12 lines checked
Signed-off-by: Joe Perches <joe@perches.com>
---
scripts/checkpatch.pl | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index ca05ba2..7165516 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1873,6 +1873,20 @@ sub process {
"No space is necessary after a cast\n" . $hereprev);
}
+ if ($realfile =~ m@^(drivers/net/|net/)@ &&
+ $rawline =~ /^\+[ \t]*\/\*[ \t]*$/ &&
+ $prevrawline =~ /^\+[ \t]*$/) {
+ WARN("NETWORKING_BLOCK_COMMENT_STYLE",
+ "networking block comments don't use an empty /* line, use /* Comment...\n" . $hereprev);
+ }
+
+ if ($realfile =~ m@^(drivers/net/|net/)@ &&
+ $rawline !~ m@^\+[ \t]*(\/\*|\*\/)@ &&
+ $rawline =~ m@^\+[ \t]*.+\*\/[ \t]*$@) {
+ WARN("NETWORKING_BLOCK_COMMENT_STYLE",
+ "networking block comments put the trailing */ on a separate line\n" . $herecurr);
+ }
+
# check for spaces at the beginning of a line.
# Exceptions:
# 1) within comments
^ permalink raw reply related
* RE: [PATCH] checkpatch: Check networking specific block comment style
From: Allan, Bruce W @ 2012-09-12 1:19 UTC (permalink / raw)
To: Joe Perches, Andrew Morton; +Cc: Andy Whitcroft, David Miller, LKML, netdev
In-Reply-To: <1347410853.2456.7.camel@joe2Laptop>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Joe Perches
> Sent: Tuesday, September 11, 2012 5:48 PM
> To: Andrew Morton
> Cc: Andy Whitcroft; David Miller; LKML; netdev
> Subject: [PATCH] checkpatch: Check networking specific block comment
> style
>
> In an effort to get fewer checkpatch reviewer corrections,
> add a networking specific style test for the preferred
> networking comment style.
>
> /* The preferred style for block comments in
> * drivers/net/... and net/... is like this
> */
>
> These tests are only used in net/ and drivers/net/
>
> Tested with:
>
> $ cat drivers/net/t.c
>
> /* foo */
>
> /*
> * foo
> */
>
> /* foo
> */
>
> /* foo
> * bar */
> $ ./scripts/checkpatch.pl -f drivers/net/t.c
> WARNING: networking block comments don't use an empty /* line, use /* Comment...
This conflicts with the preferred style for long (multi-line) comments documented in
./Documentation/CodingStyle. If this is the way comments should be done in the
networking code this patch should also include an update to Chapter 8 in CodingStyle
documenting the networking specific style to avoid confusion.
^ permalink raw reply
* Re: [PATCH] net-sched: sch_cbq: avoid infinite loop
From: David Miller @ 2012-09-12 2:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: denys, netdev
In-Reply-To: <1347405072.13103.675.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 12 Sep 2012 01:11:12 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Its possible to setup a bad cbq configuration leading to
> an infinite loop in cbq_classify()
>
> DEV_OUT=eth0
> ICMP="match ip protocol 1 0xff"
> U32="protocol ip u32"
> DST="match ip dst"
> tc qdisc add dev $DEV_OUT root handle 1: cbq avpkt 1000 \
> bandwidth 100mbit
> tc class add dev $DEV_OUT parent 1: classid 1:1 cbq \
> rate 512kbit allot 1500 prio 5 bounded isolated
> tc filter add dev $DEV_OUT parent 1: prio 3 $U32 \
> $ICMP $DST 192.168.3.234 flowid 1:
>
> Reported-by: Denys Fedoryschenko <denys@visp.net.lb>
> Tested-by: Denys Fedoryschenko <denys@visp.net.lb>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* [PATCH] CodingStyle: Add networking specific block comment style
From: Joe Perches @ 2012-09-12 3:11 UTC (permalink / raw)
To: Allan, Bruce W; +Cc: Andrew Morton, Andy Whitcroft, David Miller, LKML, netdev
In-Reply-To: <804857E1F29AAC47BF68C404FC60A1842EB021D9@ORSMSX102.amr.corp.intel.com>
The block comment style in net/ and drivers/net is non-standard.
Document it.
Signed-off-by: Joe Perches <joe@perches.com>
---
> This conflicts with the preferred style for long (multi-line) comments documented in
> ./Documentation/CodingStyle. If this is the way comments should be done in the
> networking code this patch should also include an update to Chapter 8 in CodingStyle
> documenting the networking specific style to avoid confusion.
Documentation/CodingStyle | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index cb9258b..495e5ba 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -454,6 +454,16 @@ The preferred style for long (multi-line) comments is:
* with beginning and ending almost-blank lines.
*/
+For files in net/ and drivers/net/ the preferred style for long (multi-line)
+comments is a little different.
+
+ /* The preferred comment style for files in net/ and drivers/net
+ * looks like this.
+ *
+ * It is nearly the same as the generally preferred comment style,
+ * but there is no initial almost-blank line.
+ */
+
It's also important to comment data, whether they are basic types or derived
types. To this end, use just one data declaration per line (no commas for
multiple data declarations). This leaves you room for a small comment on each
^ permalink raw reply related
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5 corrupted using NFS
From: rebelyouth hacklab @ 2012-09-12 3:34 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAPxKiaw9yHisO8imXwKkTEqCm-BE+Tiq_t3s28EE7xMgqNnggA@mail.gmail.com>
Hi Xiong,
Sorry for the long delay but I did some experiment :
I tried with different pc and devices and OS and the problem is only in Linux.
I don't get kernel oops (actually was the ATI catalyst the problem,
now with the Open source driver is all ok ) and ifconfig showing is
all ok on the pc side (Atheros)
eth0 Link encap:Ethernet HWaddr
inet addr:192.168.2.2 Bcast:192.168.2.15 Mask:255.255.255.240
inet6 addr: fe80::226:18ff:fe62:72f5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9933884 errors:0 dropped:0 overruns:0 frame:0
TX packets:3235805 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:14432030555 (413.4 GiB) TX bytes:275014758 (262.2 GiB)
Interrupt:46
On the server side I received :
eth0 Link encap:Ethernet HWaddr
inet addr:192.168.2.5 Bcast:192.168.2.15 Mask:255.255.255.240
inet6 addr: fe80::201:2eff:fe2b:67b6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13922264 errors:20736 dropped:0 overruns:20736 frame:0
TX packets:8782465 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4995676199 (414.6 GiB) TX bytes:31479570606 (229.3 GiB)
Interrupt:22
The server receive a lot of errors in RX
RX packets:13922264 errors:20736 dropped:0 overruns:20736 frame:0
I tried big DVD isos and separate files zip an rar and there are
perfect in Windows, Freebsd and Mac OS X (samba,ftp,nfs) the ipconfig
on the server showing is all ok
I also tried to optimize the NFS server and client but the only
setting for get the same of the other OS is need to set proto=udp on
/ etc/fstab (now is more stable from before)
I can also see there isn't any problem on the client computer using
the usb adapter with ax8112 Chipset without set proto=udp
So tried to disable the TSO with : ethtool -K eth0 tso off and IS
working !!!
I really think the problem is this one and unfortunately I can't send
any oops, but if you need any information or to run any software
please let me know!!!
> On Fri, Aug 10, 2012 at 3:26 PM, Rebelyouth
> <rebelyouth.hacklab@gmail.com> wrote:
>>
>>
>> Hi Xiong,
>>
>> Thank you for your replay,
>>
>> I am in a middle of reinstall all my machines f, so for now I can send you my
>> lspci and try to recreate the MD5 /SHA1 problem
>>
>> I will send you another email when I get the result
>> Thanks in advance
>>
>>
>>
>> 00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge
>> Subsystem: Advanced Micro Devices [AMD] RS780 Host Bridge
>> Flags: bus master, 66MHz, medium devsel, latency 0
>> Capabilities: <access denied>
>>
>> 00:02.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (ext
>> gfx port 0) (prog-if 00 [Normal decode])
>> Flags: bus master, fast devsel, latency 0
>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>> I/O behind bridge: 0000c000-0000cfff
>> Memory behind bridge: fbd00000-fbdfffff
>> Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
>> Capabilities: <access denied>
>> Kernel driver in use: pcieport
>>
>> 00:06.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE
>> port 2) (prog-if 00 [Normal decode])
>> Flags: bus master, fast devsel, latency 0
>> Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
>> I/O behind bridge: 0000d000-0000dfff
>> Memory behind bridge: fbe00000-fbefffff
>> Capabilities: <access denied>
>> Kernel driver in use: pcieport
>>
>> 00:07.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE
>> port 3) (prog-if 00 [Normal decode])
>> Flags: bus master, fast devsel, latency 0
>> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
>> I/O behind bridge: 0000e000-0000efff
>> Memory behind bridge: fbf00000-fbffffff
>> Capabilities: <access denied>
>> Kernel driver in use: pcieport
>>
>> 00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI
>> SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (prog-if 01 [AHCI 1.0])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA
>> Controller [AHCI mode]
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 43
>> I/O ports at b000 [size=8]
>> I/O ports at a000 [size=4]
>> I/O ports at 9000 [size=8]
>> I/O ports at 8000 [size=4]
>> I/O ports at 7000 [size=16]
>> Memory at fbcffc00 (32-bit, non-prefetchable) [size=1K]
>> Capabilities: <access denied>
>> Kernel driver in use: ahci
>>
>> 00:12.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> USB OHCI0 Controller (prog-if 10 [OHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB
>> OHCI0 Controller
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
>> Memory at fbcfd000 (32-bit, non-prefetchable) [size=4K]
>> Kernel driver in use: ohci_hcd
>>
>> 00:12.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1
>> Controller (prog-if 10 [OHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1
>> Controller
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
>> Memory at fbcfe000 (32-bit, non-prefetchable) [size=4K]
>> Kernel driver in use: ohci_hcd
>>
>> 00:12.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> USB EHCI Controller (prog-if 20 [EHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4397
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17
>> Memory at fbcff800 (32-bit, non-prefetchable) [size=256]
>> Capabilities: <access denied>
>> Kernel driver in use: ehci_hcd
>>
>> 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> USB OHCI0 Controller (prog-if 10 [OHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4398
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
>> Memory at fbcfb000 (32-bit, non-prefetchable) [size=4K]
>> Kernel driver in use: ohci_hcd
>>
>> 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1
>> Controller (prog-if 10 [OHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4399
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
>> Memory at fbcfc000 (32-bit, non-prefetchable) [size=4K]
>> Kernel driver in use: ohci_hcd
>>
>> 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> USB EHCI Controller (prog-if 20 [EHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB
>> EHCI Controller
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
>> Memory at fbcff400 (32-bit, non-prefetchable) [size=256]
>> Capabilities: <access denied>
>> Kernel driver in use: ehci_hcd
>>
>> 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller
>> (rev 3c)
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller
>> Flags: 66MHz, medium devsel
>> Capabilities: <access denied>
>>
>> 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> IDE Controller (prog-if 8a [Master SecP PriP])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 IDE
>> Controller
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
>> I/O ports at 01f0 [size=8]
>> I/O ports at 03f4 [size=1]
>> I/O ports at 0170 [size=8]
>> I/O ports at 0374 [size=1]
>> I/O ports at ff00 [size=16]
>> Capabilities: <access denied>
>> Kernel driver in use: pata_atiixp
>>
>> 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel
>> HDA)
>> Subsystem: ASUSTeK Computer Inc. Device 8357
>> Flags: bus master, slow devsel, latency 64, IRQ 16
>> Memory at fbcf4000 (64-bit, non-prefetchable) [size=16K]
>> Capabilities: <access denied>
>> Kernel driver in use: snd_hda_intel
>>
>> 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC
>> host controller
>> Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4383
>> Flags: bus master, 66MHz, medium devsel, latency 0
>>
>> 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI
>> Bridge (prog-if 01 [Subtractive decode])
>> Flags: bus master, 66MHz, medium devsel, latency 64
>> Bus: primary=00, secondary=04, subordinate=04, sec-latency=64
>>
>> 00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> USB OHCI2 Controller (prog-if 10 [OHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4396
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
>> Memory at fbcfa000 (32-bit, non-prefetchable) [size=4K]
>> Kernel driver in use: ohci_hcd
>>
>> 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
>> HyperTransport Configuration
>> Flags: fast devsel
>> Capabilities: <access denied>
>>
>> 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address
>> Map
>> Flags: fast devsel
>>
>> 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM
>> Controller
>> Flags: fast devsel
>>
>> 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
>> Miscellaneous Control
>> Flags: fast devsel
>> Capabilities: <access denied>
>> Kernel driver in use: k10temp
>>
>> 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link
>> Control
>> Flags: fast devsel
>>
>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
>> Juniper [Radeon HD 5700 Series] (prog-if 00 [VGA controller])
>> Subsystem: Micro-Star International Co., Ltd. Device 2140
>> Flags: bus master, fast devsel, latency 0, IRQ 44
>> Memory at d0000000 (64-bit, prefetchable) [size=256M]
>> Memory at fbdc0000 (64-bit, non-prefetchable) [size=128K]
>> I/O ports at c000 [size=256]
>> Expansion ROM at fbda0000 [disabled] [size=128K]
>> Capabilities: <access denied>
>> Kernel driver in use: radeon
>>
>> 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio
>> [Radeon HD 5700 Series]
>> Subsystem: Micro-Star International Co., Ltd. Device aa58
>> Flags: bus master, fast devsel, latency 0, IRQ 45
>> Memory at fbdfc000 (64-bit, non-prefetchable) [size=16K]
>> Capabilities: <access denied>
>> Kernel driver in use: snd_hda_intel
>>
>> 02:00.0 Ethernet controller: Atheros Communications Inc. AR8121/AR8113/AR8114
>> Gigabit or Fast Ethernet (rev b0)
>> Subsystem: ASUSTeK Computer Inc. Device 831c
>> Flags: bus master, fast devsel, latency 0, IRQ 46
>> Memory at fbec0000 (64-bit, non-prefetchable) [size=256K]
>> I/O ports at dc00 [size=128]
>> Capabilities: <access denied>
>> Kernel driver in use: ATL1E
>>
>> 03:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire
>> Controller (prog-if 10 [OHCI])
>> Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
>> Flags: bus master, fast devsel, latency 0, IRQ 19
>> Memory at fbfff800 (64-bit, non-prefetchable) [size=2K]
>> I/O ports at e800 [size=256]
>> Capabilities: <access denied>
>> Kernel driver in use: firewire_ohci
>>
>> > Marco
>> > Could you run lspci, and list the kernel oops ?
>> > we could duplicate it using the same NIC.
>> >
>> >
>> > PS. The driver of 1.0.1.14 is not for your NIC.
>> >
>> > Thanks
>> > Xiong
>> >
>> > > -----Original Message-----
>> > > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>> > > On Behalf Of Marco Castiglione
>> > > Sent: Tuesday, August 07, 2012 1:03
>> > > To: netdev@vger.kernel.org
>> > > Subject: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or
>> > > Fast Ethernet (rev b0) 1.0.0.7 md5 corrupted using NFS
>> > >
>> > > Hi,
>> > >
>> > > I have a problem with :
>> > >
>> > > Ethernet controller: Atheros Communications Inc. AR8121/AR8113/AR8114
>> > > Gigabit or Fast Ethernet (rev b0)
>> > >
>> > > Subsystem: ASUSTeK Computer Inc. Device 831c
>> > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> > >
>> > > ParErr-
>> > > Stepping- SERR+ FastB2B- DisINTx+
>> > >
>> > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> > >
>> > > <TAbort- <MAbort- >SERR- <PERR- INTx-
>> > >
>> > > Latency: 0, Cache Line Size: 64 bytes
>> > > Interrupt: pin A routed to IRQ 46
>> > > Region 0: Memory at fbec0000 (64-bit, non-prefetchable)
>> > > [size=256K] Region 2: I/O ports at dc00 [size=128]
>> > > Capabilities: <access denied>
>> > > Kernel driver in use: ATL1E
>> > >
>> > > The driver working fine except for nfs3 and nfs4
>> > >
>> > > If I try to copy a file bigger of 400 mb the file get corrupted, If I try
>> > > with multiple files I have a kernel oops
>> > >
>> > > I tried different system and service (Ftp,samba) and they working fine.
>> > >
>> > > I also tried to set nfs to use udp, it kinda fix the problem but only in
>> > > part (I get 1 on 3 big file with md5 mismatch).
>> > >
>> > > I notice in almost every kernel from 2.6 to now 3.2.15 the driver is the
>> > > same version
>> > >
>> > > Filename: /lib/modules/3.2.0-2-amd64/
>> > > kernel/drivers/net/ethernet/atheros/atl1e/atl1e.ko
>> > > version: 1.0.0.7-NAPI
>> > > license: GPL
>> > > description: Atheros 1000M Ethernet Network Driver
>> > > author: Atheros Corporation, <xiong.huang@atheros.com>, Jie Yang
>> > > < jie.yang@atheros.com>
>> > > srcversion: 6E5949327D7FDF32D5F4A5B
>> > > alias: pci:v00001969d00001066sv*sd*bc*sc*i*
>> > > alias: pci:v00001969d00001026sv*sd*bc*sc*i*
>> > > depends:
>> > > intree: Y
>> > > vermagic: 3.2.0-2-amd64 SMP mod_unload modversions
>> > > parm: tx_desc_cnt:Transmit description count (array of int)
>> > > parm: rx_mem_size:memory size of rx buffer(KB) (array of int)
>> > > parm: media_type:MediaType Select (array of int)
>> > > parm: int_mod_timer:Interrupt Moderator Timer (array of int)
>> > >
>> > > I found on ubuntu website the last version of the driver is 1.0.1.14 with
>> > > this change log :
>> > >
>> > > 1.0.1.14
>> > >
>> > > 1. don't define napi_struct in kcompat.h when GRO isn't supported.
>> > >
>> > > 1.0.1.13
>> > >
>> > > 1. fix AR8151-A hang when plug in LAN cable by cleaning bit1 of
>> > >
>> > > REG(0x1114).
>> > >
>> > > 1.0.1.12
>> > >
>> > > 1. fix tpd, rfd, rrs, configure error for powerpc
>> > >
>> > > 1.0.1.11
>> > >
>> > > 1. only save power when WOL enable.
>> > >
>> > > 1.0.1.10
>> > >
>> > > 1. add l1d 2.0 support.
>> > > 2. fix atl1c_phy_power_saving bug.
>> > >
>> > > 1.0.1.9
>> > >
>> > > 1. fix AR8131 reset error TX pending.
>> > > 2. add AR8152 description.
>> > >
>> > > 1.0.1.8
>> > >
>> > > 1. add L2CB V2.0 support.
>> > >
>> > > 1.0.1.7
>> > >
>> > > 1. fix L0s/L1 bug.
>> > > 2. update suspend procedure.
>> > >
>> > > 1.0.1.6
>> > >
>> > > 1. fix valn error.
>> > > 2. use common task instead of reset task and link change task.
>> > > 3. reset phy when link down.
>> > >
>> > > 1.0.1.5
>> > >
>> > > 1. change rx mod.
>> > >
>> > > 1.0.1.4
>> > >
>> > > 1. add l1d support.
>> > >
>> > > 1.0.1.3
>> > >
>> > > 1. fix TSO error.
>> > >
>> > > 1.0.1.2
>> > >
>> > > 1. fix compile error for kernel >= 2.6.30.
>> > >
>> > > 1.0.1.1
>> > >
>> > > 1. add L2cB support.
>> > >
>> > > 1.0.0.10
>> > >
>> > > 1. fix memory leak when power suspend.
>> > >
>> > > 1.0.0.9
>> > >
>> > > 1. do power saving when bootup with link lost.
>> > > 2. remove ATL1C_INTR_CLEAR_ON_READ for power saving
>> > >
>> > > 1.0.0.8
>> > >
>> > > 1. remove dump_stack(), which was used for debugging.
>> > >
>> > > So I found out the TSO is corrupt in the current version and that
>> > > explain with the udp setting do the trick.
>> > >
>> > > Now I tried to compile the new version from AR81Family-linux-
>> > > v1.0.1.14.tar.gz but was made for the 2.6 so I can't
>> > > compile.( <http://goog_56610235>
>> > > http://media.cdn.ubuntu-de.org/forum/attachments/2666793/AR81Family-
>> > > linux-
>> > > v1.0.1.14_10.10.tar.gz
>> > > )
>> > >
>> > > The Atheros support and web page is gone after Qualcomm acquisition and
>> > > the patch I found on Ubuntu forum don't work either (
>> > > http://ubuntuforums.org/attachment.php?attachmentid=182141&d=1296221
>> > > 015)
>> > >
>> > > I found out lots of people have the same issue and they using samba at
>> > > the moment.
>> > >
>> > > My temp solution is use a usb/eth adapter with ax8112 chipset but it run
>> > > at 100mbps.
>> > >
>> > > SO my request is this : Is possible for somebody of the kernel team look
>> > > the code inside AR81Family-linux-v1.0.1.14.tar.gz and update the one in
>> > > the kernel 3.x?
>> > >
>> > > Thank you for you time and consideration
>> > > --
>> > > 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
>>
>>
>> Hi
^ permalink raw reply
* [PATCH] ipv6: replace write lock with read lock when get route info
From: roy.qing.li @ 2012-09-12 5:25 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
geting route info does not write rt->rt6i_table, so replace
write lock with read lock
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/ipv6/route.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 399613b..8be1d86 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1837,7 +1837,7 @@ static struct rt6_info *rt6_get_route_info(struct net *net,
if (!table)
return NULL;
- write_lock_bh(&table->tb6_lock);
+ read_lock_bh(&table->tb6_lock);
fn = fib6_locate(&table->tb6_root, prefix ,prefixlen, NULL, 0);
if (!fn)
goto out;
@@ -1853,7 +1853,7 @@ static struct rt6_info *rt6_get_route_info(struct net *net,
break;
}
out:
- write_unlock_bh(&table->tb6_lock);
+ read_unlock_bh(&table->tb6_lock);
return rt;
}
@@ -1896,7 +1896,7 @@ struct rt6_info *rt6_get_dflt_router(const struct in6_addr *addr, struct net_dev
if (!table)
return NULL;
- write_lock_bh(&table->tb6_lock);
+ read_lock_bh(&table->tb6_lock);
for (rt = table->tb6_root.leaf; rt; rt=rt->dst.rt6_next) {
if (dev == rt->dst.dev &&
((rt->rt6i_flags & (RTF_ADDRCONF | RTF_DEFAULT)) == (RTF_ADDRCONF | RTF_DEFAULT)) &&
@@ -1905,7 +1905,7 @@ struct rt6_info *rt6_get_dflt_router(const struct in6_addr *addr, struct net_dev
}
if (rt)
dst_hold(&rt->dst);
- write_unlock_bh(&table->tb6_lock);
+ read_unlock_bh(&table->tb6_lock);
return rt;
}
--
1.7.4.1
^ permalink raw reply related
* Re: [V3 PATCH 9/9] cxgb4vf: Chelsio FCoE offload driver submission (header compatibility fixes).
From: Naresh Kumar Inna @ 2012-09-12 5:35 UTC (permalink / raw)
To: David Miller
Cc: JBottomley@parallels.com, linux-scsi@vger.kernel.org,
Dimitrios Michailidis, Casey Leedom, netdev@vger.kernel.org,
Chethan Seshadri
In-Reply-To: <20120911.133321.282568248903907762.davem@davemloft.net>
On 9/11/2012 11:03 PM, David Miller wrote:
> From: Naresh Kumar Inna <naresh@chelsio.com>
> Date: Tue, 11 Sep 2012 20:09:07 +0530
>
>> This patch contains minor fixes to make cxgb4vf driver work with the updates to
>> shared firmware/hardware header files.
>>
>> Signed-off-by: Naresh Kumar Inna <naresh@chelsio.com>
>
> You cannot submit a patch set that isn't bisectable, and in particular
> create a situation that mid-way through your patch set things do not
> build or operate correctly.
>
Sorry, I am new to this process. The reason I did that was because I was
not sure if I could create a single patch with both cxgb4 and cxgb4vf
files in it, since they are two different subsystems. If I could do
that, the single patch then would build on its own, and not be dependent
on the other patches in the series. Is that something I can do?
Thanks,
Naresh.
^ permalink raw reply
* Re: [V3 PATCH 5/9] csiostor: Chelsio FCoE offload driver submission (sources part 5).
From: Naresh Kumar Inna @ 2012-09-12 5:40 UTC (permalink / raw)
To: David Miller
Cc: JBottomley@parallels.com, linux-scsi@vger.kernel.org,
Dimitrios Michailidis, Casey Leedom, netdev@vger.kernel.org,
Chethan Seshadri
In-Reply-To: <20120911.133510.1351483747174862495.davem@davemloft.net>
On 9/11/2012 11:05 PM, David Miller wrote:
> From: Naresh Kumar Inna <naresh@chelsio.com>
> Date: Tue, 11 Sep 2012 20:09:03 +0530
>
>> +#include <linux/moduleparam.h>
>
> This header include is not necessary.
>
I will remove it, thanks.
^ permalink raw reply
* Re: [V3 PATCH 9/9] cxgb4vf: Chelsio FCoE offload driver submission (header compatibility fixes).
From: David Miller @ 2012-09-12 5:47 UTC (permalink / raw)
To: naresh; +Cc: JBottomley, linux-scsi, dm, leedom, netdev, chethan
In-Reply-To: <50501F1A.6040905@chelsio.com>
From: Naresh Kumar Inna <naresh@chelsio.com>
Date: Wed, 12 Sep 2012 11:05:22 +0530
> On 9/11/2012 11:03 PM, David Miller wrote:
>> From: Naresh Kumar Inna <naresh@chelsio.com>
>> Date: Tue, 11 Sep 2012 20:09:07 +0530
>>
>>> This patch contains minor fixes to make cxgb4vf driver work with the updates to
>>> shared firmware/hardware header files.
>>>
>>> Signed-off-by: Naresh Kumar Inna <naresh@chelsio.com>
>>
>> You cannot submit a patch set that isn't bisectable, and in particular
>> create a situation that mid-way through your patch set things do not
>> build or operate correctly.
>>
>
> Sorry, I am new to this process. The reason I did that was because I was
> not sure if I could create a single patch with both cxgb4 and cxgb4vf
> files in it, since they are two different subsystems. If I could do
> that, the single patch then would build on its own, and not be dependent
> on the other patches in the series. Is that something I can do?
I don't know how else to say this, every step along the way the tree
has to build. You arrange the patches however necessary to achieve
that goal.
^ permalink raw reply
* Re: [PATCHv4] virtio-spec: virtio network device multiqueue support
From: Rusty Russell @ 2012-09-12 5:49 UTC (permalink / raw)
To: Jason Wang, Michael S. Tsirkin
Cc: kvm, netdev, rick.jones2, virtualization, levinsasha928, pbonzini,
Tom Herbert
In-Reply-To: <504DC831.1000709@redhat.com>
Jason Wang <jasowang@redhat.com> writes:
> On 09/10/2012 02:33 PM, Michael S. Tsirkin wrote:
>> A final addition: what you suggest above would be
>> "TX follows RX", right?
BTW, yes. But it's a weird way to express what the nic is doing.
>> It is in anticipation of something like that, that I made
>> steering programming so generic.
>> I think TX follows RX is more immediately useful for reasons above
>> but we can add both to spec and let drivers and devices
>> decide what they want to support.
You mean "RX follows TX"? ie. accelerated RFS. I agree.
Perhaps Tom can explain how we avoid out-of-order receive for the
accelerated RFS case? It's not clear to me, but we need to be able to
do that for virtio-net if it implements accelerated RFS.
> AFAIK, ixgbe does "rx follows tx". The only differences between ixgbe
> and virtio-net is that ixgbe driver programs the flow director during
> packet transmission but we suggest to do it silently in the device for
> simplicity.
Implying the receive queue by xmit will be slightly laggy. Don't know
if that's a problem.
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH 2/2] netprio_cgroup: Optimize the priomap copy loop slightly
From: Srivatsa S. Bhat @ 2012-09-12 6:05 UTC (permalink / raw)
To: David Laight
Cc: davem, nhorman, john.r.fastabend, gaofeng, eric.dumazet,
mark.d.rustad, lizefan, netdev, linux-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6FE9@saturn3.aculab.com>
On 09/11/2012 05:12 PM, David Laight wrote:
>> - for (i = 0;
>> - old_priomap && (i < old_priomap->priomap_len);
>> - i++)
>> - new_priomap->priomap[i] = old_priomap->priomap[i];
>> + if (old_priomap) {
>> + old_len = old_priomap->priomap_len;
>> +
>> + for (i = 0; i < old_len; i++)
>> + new_priomap->priomap[i] = old_priomap->priomap[i];
>> + }
>
> Or:
> memcpy(new_priomap->priomap, old_priomap->priomap,
> old_priomap->priomap_len * sizeof old_priomap->priomap[0]);
>
Ah, indeed that would be better. I'll send out an updated version of the
patches. Thanks!
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* [v2 PATCH 1/2] netprio_cgroup: Remove update_netdev_tables() since it is unnecessary
From: Srivatsa S. Bhat @ 2012-09-12 6:07 UTC (permalink / raw)
To: davem, nhorman
Cc: David.Laight, john.r.fastabend, gaofeng, eric.dumazet,
mark.d.rustad, lizefan, netdev, linux-kernel, srivatsa.bhat
The update_netdev_tables() function appears to be unnecessary, since the
write_update_netdev_table() function will adjust the priomaps as and when
required anyway. So drop the usage of update_netdev_tables() entirely.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
net/core/netprio_cgroup.c | 32 --------------------------------
1 files changed, 0 insertions(+), 32 deletions(-)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index c75e3f9..fd339bb0 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -109,32 +109,6 @@ static int write_update_netdev_table(struct net_device *dev)
return ret;
}
-static int update_netdev_tables(void)
-{
- int ret = 0;
- struct net_device *dev;
- u32 max_len;
- struct netprio_map *map;
-
- rtnl_lock();
- max_len = atomic_read(&max_prioidx) + 1;
- for_each_netdev(&init_net, dev) {
- map = rtnl_dereference(dev->priomap);
- /*
- * don't allocate priomap if we didn't
- * change net_prio.ifpriomap (map == NULL),
- * this will speed up skb_update_prio.
- */
- if (map && map->priomap_len < max_len) {
- ret = extend_netdev_table(dev, max_len);
- if (ret < 0)
- break;
- }
- }
- rtnl_unlock();
- return ret;
-}
-
static struct cgroup_subsys_state *cgrp_create(struct cgroup *cgrp)
{
struct cgroup_netprio_state *cs;
@@ -153,12 +127,6 @@ static struct cgroup_subsys_state *cgrp_create(struct cgroup *cgrp)
goto out;
}
- ret = update_netdev_tables();
- if (ret < 0) {
- put_prioidx(cs->prioidx);
- goto out;
- }
-
return &cs->css;
out:
kfree(cs);
^ permalink raw reply related
* [v2 PATCH 2/2] netprio_cgroup: Use memcpy instead of the for-loop to copy priomap
From: Srivatsa S. Bhat @ 2012-09-12 6:07 UTC (permalink / raw)
To: davem, nhorman
Cc: David.Laight, john.r.fastabend, gaofeng, eric.dumazet,
mark.d.rustad, lizefan, netdev, linux-kernel, srivatsa.bhat
In-Reply-To: <20120912060741.11037.37347.stgit@srivatsabhat.in.ibm.com>
Replace the current (inefficient) for-loop with memcpy, to copy priomap.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
net/core/netprio_cgroup.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index fd339bb0..83bbd0e 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -73,7 +73,6 @@ static int extend_netdev_table(struct net_device *dev, u32 new_len)
((sizeof(u32) * new_len));
struct netprio_map *new_priomap = kzalloc(new_size, GFP_KERNEL);
struct netprio_map *old_priomap;
- int i;
old_priomap = rtnl_dereference(dev->priomap);
@@ -82,10 +81,10 @@ static int extend_netdev_table(struct net_device *dev, u32 new_len)
return -ENOMEM;
}
- for (i = 0;
- old_priomap && (i < old_priomap->priomap_len);
- i++)
- new_priomap->priomap[i] = old_priomap->priomap[i];
+ if (old_priomap)
+ memcpy(new_priomap->priomap, old_priomap->priomap,
+ old_priomap->priomap_len *
+ sizeof(old_priomap->priomap[0]));
new_priomap->priomap_len = new_len;
^ permalink raw reply related
* [PATCH] iproute2: GENL: merge GENL_REQUEST and GENL_INITIALIZER
From: Julian Anastasov @ 2012-09-12 6:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Both macros are used together, so better to have
single define. Update all requests in ipl2tp.c to use the
new macro.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
include/libgenl.h | 27 +++++++++-----------
ip/ipl2tp.c | 72 +++++++++++-----------------------------------------
lib/libgenl.c | 7 ++---
3 files changed, 31 insertions(+), 75 deletions(-)
diff --git a/include/libgenl.h b/include/libgenl.h
index 0b11a89..9db4baf 100644
--- a/include/libgenl.h
+++ b/include/libgenl.h
@@ -3,25 +3,22 @@
#include "libnetlink.h"
-#define GENL_REQUEST(_req, _hdrsiz, _bufsiz) \
+#define GENL_REQUEST(_req, _bufsiz, _family, _hdrsiz, _ver, _cmd, _flags) \
struct { \
struct nlmsghdr n; \
struct genlmsghdr g; \
char buf[NLMSG_ALIGN(_hdrsiz) + (_bufsiz)]; \
-} _req
-
-#define GENL_INITIALIZER(_family, _hdrsiz, _ver, _cmd, _flags) \
- { \
- .n = { \
- .nlmsg_type = (_family), \
- .nlmsg_flags = (_flags), \
- .nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN + (_hdrsiz)), \
- }, \
- .g = { \
- .cmd = (_cmd), \
- .version = (_ver), \
- }, \
- }
+} _req = { \
+ .n = { \
+ .nlmsg_type = (_family), \
+ .nlmsg_flags = (_flags), \
+ .nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN + (_hdrsiz)), \
+ }, \
+ .g = { \
+ .cmd = (_cmd), \
+ .version = (_ver), \
+ }, \
+}
extern int genl_resolve_family(struct rtnl_handle *grth, const char *family);
diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index aaa3d31..f6e264a 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -96,9 +96,8 @@ static int create_tunnel(struct l2tp_parm *p)
uint32_t local_attr = L2TP_ATTR_IP_SADDR;
uint32_t peer_attr = L2TP_ATTR_IP_DADDR;
- GENL_REQUEST(req, 0, 1024)
- = GENL_INITIALIZER(genl_family, NLM_F_REQUEST | NLM_F_ACK, 0,
- L2TP_CMD_TUNNEL_CREATE, L2TP_GENL_VERSION);
+ GENL_REQUEST(req, 1024, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_TUNNEL_CREATE, NLM_F_REQUEST | NLM_F_ACK);
addattr32(&req.n, 1024, L2TP_ATTR_CONN_ID, p->tunnel_id);
addattr32(&req.n, 1024, L2TP_ATTR_PEER_CONN_ID, p->peer_tunnel_id);
@@ -126,9 +125,8 @@ static int create_tunnel(struct l2tp_parm *p)
static int delete_tunnel(struct l2tp_parm *p)
{
- GENL_REQUEST(req, 0, 1024)
- = GENL_INITIALIZER(genl_family, NLM_F_REQUEST | NLM_F_ACK, 0,
- L2TP_CMD_TUNNEL_DELETE, L2TP_GENL_VERSION);
+ GENL_REQUEST(req, 128, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_TUNNEL_DELETE, NLM_F_REQUEST | NLM_F_ACK);
addattr32(&req.n, 128, L2TP_ATTR_CONN_ID, p->tunnel_id);
@@ -140,18 +138,8 @@ static int delete_tunnel(struct l2tp_parm *p)
static int create_session(struct l2tp_parm *p)
{
- struct {
- struct nlmsghdr n;
- struct genlmsghdr g;
- char buf[1024];
- } req;
-
- memset(&req, 0, sizeof(req));
- req.n.nlmsg_type = genl_family;
- req.n.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
- req.n.nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN);
- req.g.cmd = L2TP_CMD_SESSION_CREATE;
- req.g.version = L2TP_GENL_VERSION;
+ GENL_REQUEST(req, 1024, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_SESSION_CREATE, NLM_F_REQUEST | NLM_F_ACK);
addattr32(&req.n, 1024, L2TP_ATTR_CONN_ID, p->tunnel_id);
addattr32(&req.n, 1024, L2TP_ATTR_PEER_CONN_ID, p->peer_tunnel_id);
@@ -182,18 +170,8 @@ static int create_session(struct l2tp_parm *p)
static int delete_session(struct l2tp_parm *p)
{
- struct {
- struct nlmsghdr n;
- struct genlmsghdr g;
- char buf[128];
- } req;
-
- memset(&req, 0, sizeof(req));
- req.n.nlmsg_type = genl_family;
- req.n.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
- req.n.nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN);
- req.g.cmd = L2TP_CMD_SESSION_DELETE;
- req.g.version = L2TP_GENL_VERSION;
+ GENL_REQUEST(req, 1024, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_SESSION_DELETE, NLM_F_REQUEST | NLM_F_ACK);
addattr32(&req.n, 1024, L2TP_ATTR_CONN_ID, p->tunnel_id);
addattr32(&req.n, 1024, L2TP_ATTR_SESSION_ID, p->session_id);
@@ -380,20 +358,11 @@ static int session_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n, void
static int get_session(struct l2tp_data *p)
{
- struct {
- struct nlmsghdr n;
- struct genlmsghdr g;
- char buf[128];
- } req;
-
- memset(&req, 0, sizeof(req));
- req.n.nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN);
- req.n.nlmsg_type = genl_family;
- req.n.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST;
- req.n.nlmsg_seq = genl_rth.dump = ++genl_rth.seq;
+ GENL_REQUEST(req, 128, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_SESSION_GET,
+ NLM_F_ROOT | NLM_F_MATCH | NLM_F_REQUEST);
- req.g.cmd = L2TP_CMD_SESSION_GET;
- req.g.version = L2TP_GENL_VERSION;
+ req.n.nlmsg_seq = genl_rth.dump = ++genl_rth.seq;
if (p->config.tunnel_id && p->config.session_id) {
addattr32(&req.n, 128, L2TP_ATTR_CONN_ID, p->config.tunnel_id);
@@ -423,20 +392,11 @@ static int tunnel_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n, void
static int get_tunnel(struct l2tp_data *p)
{
- struct {
- struct nlmsghdr n;
- struct genlmsghdr g;
- char buf[1024];
- } req;
-
- memset(&req, 0, sizeof(req));
- req.n.nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN);
- req.n.nlmsg_type = genl_family;
- req.n.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST;
- req.n.nlmsg_seq = genl_rth.dump = ++genl_rth.seq;
+ GENL_REQUEST(req, 1024, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_TUNNEL_GET,
+ NLM_F_ROOT | NLM_F_MATCH | NLM_F_REQUEST);
- req.g.cmd = L2TP_CMD_TUNNEL_GET;
- req.g.version = L2TP_GENL_VERSION;
+ req.n.nlmsg_seq = genl_rth.dump = ++genl_rth.seq;
if (p->config.tunnel_id)
addattr32(&req.n, 1024, L2TP_ATTR_CONN_ID, p->config.tunnel_id);
diff --git a/lib/libgenl.c b/lib/libgenl.c
index d68e58e..ef3e5db 100644
--- a/lib/libgenl.c
+++ b/lib/libgenl.c
@@ -47,11 +47,10 @@ static int genl_parse_getfamily(struct nlmsghdr *nlh)
int genl_resolve_family(struct rtnl_handle *grth, const char *family)
{
- GENL_REQUEST(req, 0, 1024)
- = GENL_INITIALIZER(GENL_ID_CTRL, 0,
- 0, CTRL_CMD_GETFAMILY, NLM_F_REQUEST);
+ GENL_REQUEST(req, 1024, GENL_ID_CTRL, 0, 0, CTRL_CMD_GETFAMILY,
+ NLM_F_REQUEST);
- addattr_l(&req.n, 1024, CTRL_ATTR_FAMILY_NAME,
+ addattr_l(&req.n, sizeof(req), CTRL_ATTR_FAMILY_NAME,
family, strlen(family) + 1);
if (rtnl_talk(grth, &req.n, 0, 0, &req.n) < 0) {
--
1.7.3.4
^ permalink raw reply related
* Re: [V3 PATCH 9/9] cxgb4vf: Chelsio FCoE offload driver submission (header compatibility fixes).
From: Naresh Kumar Inna @ 2012-09-12 6:27 UTC (permalink / raw)
To: David Miller
Cc: JBottomley@parallels.com, linux-scsi@vger.kernel.org,
Dimitrios Michailidis, Casey Leedom, netdev@vger.kernel.org,
Chethan Seshadri
In-Reply-To: <20120912.014746.636228439025755624.davem@davemloft.net>
On 9/12/2012 11:17 AM, David Miller wrote:
> From: Naresh Kumar Inna <naresh@chelsio.com>
> Date: Wed, 12 Sep 2012 11:05:22 +0530
>
>> On 9/11/2012 11:03 PM, David Miller wrote:
>>> From: Naresh Kumar Inna <naresh@chelsio.com>
>>> Date: Tue, 11 Sep 2012 20:09:07 +0530
>>>
>>>> This patch contains minor fixes to make cxgb4vf driver work with the updates to
>>>> shared firmware/hardware header files.
>>>>
>>>> Signed-off-by: Naresh Kumar Inna <naresh@chelsio.com>
>>>
>>> You cannot submit a patch set that isn't bisectable, and in particular
>>> create a situation that mid-way through your patch set things do not
>>> build or operate correctly.
>>>
>>
>> Sorry, I am new to this process. The reason I did that was because I was
>> not sure if I could create a single patch with both cxgb4 and cxgb4vf
>> files in it, since they are two different subsystems. If I could do
>> that, the single patch then would build on its own, and not be dependent
>> on the other patches in the series. Is that something I can do?
>
> I don't know how else to say this, every step along the way the tree
> has to build. You arrange the patches however necessary to achieve
> that goal.
>
OK, I think I should be able to arrange the patch set to fulfill that
requirement. I was under the impression it was fine for new drivers to
split patches in this fashion, since they go as a single commit, sorry
about that.
As for a single patch with both cxgb4 and cxgb4vf changes, I assume it
is OK for the commit log to start with "cxgb4/cxgb4vf:..."?
Thanks,
Naresh.
^ permalink raw reply
* Re: [PATCH] net_tx_action: Call trace_consume_skb() instead of trace_kfree_skb()
From: Eric Dumazet @ 2012-09-12 7:33 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: netdev, sanagi.koki, davem
In-Reply-To: <1347406098-22071-1-git-send-email-sbohrer@rgmadvisors.com>
On Tue, 2012-09-11 at 18:28 -0500, Shawn Bohrer wrote:
> Call trace_consume_skb() instead of trace_kfree_skb() as skbs are
> removed from the completion_queue during transmit. This avoids false
> positives from dropwatch/drop_monitor making them more useful.
>
> Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
> ---
>
> In my case I seem to hit this tracepoint for every packet I transmit so
> these appear to be false positives to me. Perhaps there are cases where
> you could hit this and it is a real packet drop?
>
> net/core/dev.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8398836..00774ce 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3015,7 +3015,7 @@ static void net_tx_action(struct softirq_action *h)
> clist = clist->next;
>
> WARN_ON(atomic_read(&skb->users));
> - trace_kfree_skb(skb, net_tx_action);
> + trace_consume_skb(skb);
> __kfree_skb(skb);
> }
> }
> --
> 1.7.7.6
>
>
Problem here is : we dont know if caller of dev_kfree_skb_irq(skb)
wanted to drop or consume skb.
(We dont have a dev_consume_skb_irq(skb) function)
For example, drivers/infiniband/ulp/ipoib/ipoib_main.c function
path_free() does :
while ((skb = __skb_dequeue(&path->queue)))
dev_kfree_skb_irq(skb);
Are these packets dropped or consumed, I dont really know...
Note : NAPI drivers dont use dev_kfree_skb_irq(skb).
What is the NIC driver you are using, I thought it was mellanox (wich is
NAPI) ?
^ permalink raw reply
* Re: [PATCH net-next v3 4/4] ipv6: use DST_* macro to set obselete field
From: Eric Dumazet @ 2012-09-12 7:40 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: vyasevich, davem, sds, james.l.morris, eparis, sri, linux-sctp,
netdev
In-Reply-To: <1347350987-8054-5-git-send-email-nicolas.dichtel@6wind.com>
On Tue, 2012-09-11 at 10:09 +0200, Nicolas Dichtel wrote:
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> net/ipv6/route.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 561f249..0c6f132 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -226,7 +226,7 @@ static struct rt6_info ip6_null_entry_template = {
> .dst = {
> .__refcnt = ATOMIC_INIT(1),
> .__use = 1,
> - .obsolete = -1,
> + .obsolete = DST_OBSOLETE_FORCE_CHK,
> .error = -ENETUNREACH,
> .input = ip6_pkt_discard,
> .output = ip6_pkt_discard_out,
> @@ -246,7 +246,7 @@ static struct rt6_info ip6_prohibit_entry_template = {
> .dst = {
> .__refcnt = ATOMIC_INIT(1),
> .__use = 1,
> - .obsolete = -1,
> + .obsolete = DST_OBSOLETE_FORCE_CHK,
> .error = -EACCES,
> .input = ip6_pkt_prohibit,
> .output = ip6_pkt_prohibit_out,
> @@ -261,7 +261,7 @@ static struct rt6_info ip6_blk_hole_entry_template = {
> .dst = {
> .__refcnt = ATOMIC_INIT(1),
> .__use = 1,
> - .obsolete = -1,
> + .obsolete = DST_OBSOLETE_FORCE_CHK,
> .error = -EINVAL,
> .input = dst_discard,
> .output = dst_discard,
Acked-by: Eric Dumazet <edumazet@google.com>
^ 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