* Re: [PATCH net-next] 8021q: fix a potential use-after-free
From: Eric Dumazet @ 2013-03-23 15:16 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Patrick McHardy, David S. Miller
In-Reply-To: <1364015648-4195-1-git-send-email-amwang@redhat.com>
On Sat, 2013-03-23 at 13:14 +0800, Cong Wang wrote:
> From: Cong Wang <amwang@redhat.com>
>
> vlan_vid_del() could possibly free ->vlan_info after a RCU grace
> period, however, we may still refer to the freed memory area
> by 'grp' pointer. Found by code inspection.
>
> This patch moves vlan_vid_del() as behind as possible.
>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
> ---
> net/8021q/vlan.c | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next] ip_gre: increase inner ip header ID only for IPv4
From: Sergei Shtylyov @ 2013-03-23 15:10 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Pravin B Shelar, Eric Dumazet, David S. Miller
In-Reply-To: <1364016584-7189-1-git-send-email-amwang@redhat.com>
Hello.
On 23-03-2013 9:29, Cong Wang wrote:
> From: Cong Wang <amwang@redhat.com>
> Pravin pointed out the inner network header of a GRE tunnel packet
> could be IPv6, where there is no ID. So we should check the version.
> Cc: Pravin B Shelar <pshelar@nicira.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
> ---
> diff --git a/net/ipv4/gre.c b/net/ipv4/gre.c
> index e20631c..a2516f5 100644
> --- a/net/ipv4/gre.c
> +++ b/net/ipv4/gre.c
[...]
> @@ -172,7 +172,12 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
> skb->mac_len = skb_inner_network_offset(skb);
>
> iph = ip_hdr(skb);
> - id = ntohs(iph->id);
> + if (iph->version == 4) {
> + ipv4 = true;
> + id = ntohs(iph->id);
> + } else
> + ipv4 = false;
Both arms of *if* statement should have {}, according to
Documentation/CodingStyle chapter 3.
WBR, Sergei
^ permalink raw reply
* Re: [RFC PATCH] udp: don't rereference dst_entry dev pointer on rcv
From: Eric Dumazet @ 2013-03-23 15:09 UTC (permalink / raw)
To: Damien Wyart; +Cc: Tom Parkin, David Miller, netdev
In-Reply-To: <20130323103139.GA4190@brouette>
On Sat, 2013-03-23 at 11:31 +0100, Damien Wyart wrote:
> Hi Eric,
>
> * Tom Parkin <tparkin@katalix.com> [2013-03-14 16:14]:
> > On Thu, Mar 14, 2013 at 04:29:06PM +0100, Eric Dumazet wrote:
> > > OK, I tested the following one instead, please test it so that I can send an official patch.
>
> > > Thanks
>
> > > diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
> > > index b6d30ac..2d23830 100644
> > > --- a/net/ipv4/ip_fragment.c
> > > +++ b/net/ipv4/ip_fragment.c
> > > @@ -529,6 +529,7 @@ found:
> > > qp->q.meat == qp->q.len)
> > > return ip_frag_reasm(qp, prev, dev);
>
> > > + skb_dst_drop(skb);
> > > inet_frag_lru_move(&qp->q);
> > > return -EINPROGRESS;
>
> > Thanks again, Eric.
>
> > Sadly, with this patch the oops is back :-( It falls over quite
> > quickly for me.
>
> Just a quick check: do you plan to have another look at this in the
> coming days/weeks? You said you had a huge backlog, but in the meantime,
> you sent many patches on many topics, so just wanted to check if this
> one had not be forgotten for ever.
Hi Damien. This one is part of my backlog, I will send a patch soon.
Thanks
^ permalink raw reply
* Re: [PATCH net-next] bridge: avoid br_ifinfo_notify when nothing changed
From: Sergei Shtylyov @ 2013-03-23 15:06 UTC (permalink / raw)
To: Hong Zhiguo; +Cc: netdev, bridge, davem, stephen, herbert, zhiguo.hong
In-Reply-To: <1364015653-7322-1-git-send-email-honkiko@gmail.com>
Hello.
On 23-03-2013 9:14, Hong Zhiguo wrote:
> When neither IFF_BRIDGE_PORT or IFF_BRIDGE_PORT is set,
That is the same flag repeated twice.
> and afspec == NULL but protinfo != NULL, we run into
> "if (err == 0) br_ifinfo_notify(RTM_NEWLINK, p);" with
> random value in ret.
> Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
WBR, Sergei
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-23 15:06 UTC (permalink / raw)
To: rebelyouth; +Cc: netdev
In-Reply-To: <514D3581.4040001@gmail.com>
On Sat, Mar 23, 2013 at 12:54:25AM -0400, rebelyouth wrote:
> I applied your patch on my the kernel 3.7.9 and look like the patch do
> what you said before :
>
> "This does not solve the real problem, which I have not yet understood
> (wrong packets will be discarded now and will be hopefully resend). "
>
> There are errors on the RX side of the server and the speed is 5~10%
> less but the files are ok in nfsv4 , SFTP/FTP and samba.
>
> Maybe the Atheros drivers for windows had a patch for the checksum
> already in the drivers and the chipset have some hardware bug, but for
> me your patch is already an achievement and I really thank you for your
> time and consideration.
The upstream driver (which is a tarball I found with google
AR81Family-linux-v1.0.1.14.tar.gz) has this function ifdefed out. I have
a couple of more things I want to test as soon as I have access to the
hardware again. If I don't find a better solution I will submit a patch
which disables rx checksumming as a whole for inclusion to net-next.
Thanks,
Hannes
^ permalink raw reply
* [PATCH] bridge: fix crash when set mac address of br interface
From: Hong Zhiguo @ 2013-03-23 12:27 UTC (permalink / raw)
To: netdev; +Cc: bridge, davem, stephen, herbert, zhiguo.hong, Hong Zhiguo
When I tried to set mac address of a bridge interface to a mac
address which already learned on this bridge, I got system hang.
The cause is straight forward: function br_fdb_change_mac_address
calls fdb_insert with NULL source nbp. Then an fdb lookup is
performed. If an fdb entry is found and it's local, it's OK. But
if it's not local, source is dereferenced for printk without NULL
check.
Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
---
net/bridge/br_fdb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 10b47d4..c581f12 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -421,7 +421,7 @@ static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source,
return 0;
br_warn(br, "adding interface %s with same address "
"as a received packet\n",
- source->dev->name);
+ source ? source->dev->name : br->dev->name);
fdb_delete(br, fdb);
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] brcmsmac: Remove unused macro SI_MSG
From: Arend van Spriel @ 2013-03-23 12:14 UTC (permalink / raw)
To: Joe Perches
Cc: Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman,
John W. Linville, linux-wireless, brcm80211-dev-list, netdev,
linux-kernel
In-Reply-To: <25a69b0ba20a54e5c1c0165e68a1ef2c69c84255.1363982285.git.joe@perches.com>
On 03/22/2013 09:00 PM, Joe Perches wrote:
> commit 6236dc2e2 ("brcmsmac: remove some redundant chip common workarounds")
> removed the last uses.
Good riddance.
Acked-by: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 6 ------
> 1 file changed, 6 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH] udp: don't rereference dst_entry dev pointer on rcv
From: Damien Wyart @ 2013-03-23 10:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Parkin, David Miller, netdev
In-Reply-To: <20130314161436.GC2512@raven>
Hi Eric,
* Tom Parkin <tparkin@katalix.com> [2013-03-14 16:14]:
> On Thu, Mar 14, 2013 at 04:29:06PM +0100, Eric Dumazet wrote:
> > OK, I tested the following one instead, please test it so that I can send an official patch.
> > Thanks
> > diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
> > index b6d30ac..2d23830 100644
> > --- a/net/ipv4/ip_fragment.c
> > +++ b/net/ipv4/ip_fragment.c
> > @@ -529,6 +529,7 @@ found:
> > qp->q.meat == qp->q.len)
> > return ip_frag_reasm(qp, prev, dev);
> > + skb_dst_drop(skb);
> > inet_frag_lru_move(&qp->q);
> > return -EINPROGRESS;
> Thanks again, Eric.
> Sadly, with this patch the oops is back :-( It falls over quite
> quickly for me.
Just a quick check: do you plan to have another look at this in the
coming days/weeks? You said you had a huge backlog, but in the meantime,
you sent many patches on many topics, so just wanted to check if this
one had not be forgotten for ever.
Thanks,
--
Damien Wyart
^ permalink raw reply
* [PATCH net-next] ip_gre: increase inner ip header ID only for IPv4
From: Cong Wang @ 2013-03-23 5:29 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, Eric Dumazet, David S. Miller, Cong Wang
From: Cong Wang <amwang@redhat.com>
Pravin pointed out the inner network header of a GRE tunnel packet
could be IPv6, where there is no ID. So we should check the version.
Cc: Pravin B Shelar <pshelar@nicira.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
diff --git a/net/ipv4/gre.c b/net/ipv4/gre.c
index e20631c..a2516f5 100644
--- a/net/ipv4/gre.c
+++ b/net/ipv4/gre.c
@@ -128,7 +128,7 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
struct iphdr *iph;
int mac_len = skb->mac_len;
int tnl_hlen, id;
- bool csum;
+ bool csum, ipv4;
if (unlikely(skb_shinfo(skb)->gso_type &
~(SKB_GSO_TCPV4 |
@@ -172,7 +172,12 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
skb->mac_len = skb_inner_network_offset(skb);
iph = ip_hdr(skb);
- id = ntohs(iph->id);
+ if (iph->version == 4) {
+ ipv4 = true;
+ id = ntohs(iph->id);
+ } else
+ ipv4 = false;
+
/* segment inner packet. */
enc_features = skb->dev->hw_enc_features & netif_skb_features(skb);
segs = skb_mac_gso_segment(skb, enc_features);
@@ -182,8 +187,10 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
skb = segs;
tnl_hlen = skb_tnl_header_len(skb);
do {
- iph = (struct iphdr *)skb->data;
- iph->id = htons(id++);
+ if (ipv4) {
+ iph = (struct iphdr *)skb->data;
+ iph->id = htons(id++);
+ }
__skb_push(skb, ghl);
if (csum) {
__be32 *pcsum;
^ permalink raw reply related
* [PATCH net-next] bridge: avoid br_ifinfo_notify when nothing changed
From: Hong Zhiguo @ 2013-03-23 5:14 UTC (permalink / raw)
To: netdev; +Cc: bridge, davem, stephen, herbert, zhiguo.hong, Hong Zhiguo
When neither IFF_BRIDGE_PORT or IFF_BRIDGE_PORT is set,
and afspec == NULL but protinfo != NULL, we run into
"if (err == 0) br_ifinfo_notify(RTM_NEWLINK, p);" with
random value in ret.
Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
---
net/bridge/br_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 84c3b7d..b96e02e 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -357,7 +357,7 @@ int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
struct nlattr *afspec;
struct net_bridge_port *p;
struct nlattr *tb[IFLA_BRPORT_MAX + 1];
- int err;
+ int err = 0;
ifm = nlmsg_data(nlh);
@@ -370,7 +370,7 @@ int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
/* We want to accept dev as bridge itself if the AF_SPEC
* is set to see if someone is setting vlan info on the brigde
*/
- if (!p && ((dev->priv_flags & IFF_EBRIDGE) && !afspec))
+ if (!p && !afspec)
return -EINVAL;
if (p && protinfo) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next] 802: fix a possible race condition
From: Cong Wang @ 2013-03-23 5:14 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, David Ward, Jorge Boncompte [DTI2], Cong Wang
In-Reply-To: <1364015648-4195-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
garp_pdu_queue() should ways be called with this spin lock.
garp_uninit_applicant() only holds rtnl lock which is not
enough here.
Found by code inspection.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: David Ward <david.ward@ll.mit.edu>
Cc: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
net/802/garp.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/802/garp.c b/net/802/garp.c
index 8456f5d..5d9630a 100644
--- a/net/802/garp.c
+++ b/net/802/garp.c
@@ -609,8 +609,12 @@ void garp_uninit_applicant(struct net_device *dev, struct garp_application *appl
/* Delete timer and generate a final TRANSMIT_PDU event to flush out
* all pending messages before the applicant is gone. */
del_timer_sync(&app->join_timer);
+
+ spin_lock_bh(&app->lock);
garp_gid_event(app, GARP_EVENT_TRANSMIT_PDU);
garp_pdu_queue(app);
+ spin_unlock_bh(&app->lock);
+
garp_queue_xmit(app);
dev_mc_del(dev, appl->proto.group_address);
--
1.7.7.6
^ permalink raw reply related
* [PATCH net-next] 8021q: fix a potential use-after-free
From: Cong Wang @ 2013-03-23 5:14 UTC (permalink / raw)
To: netdev; +Cc: Patrick McHardy, David S. Miller, Cong Wang
In-Reply-To: <1363938600-26129-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
vlan_vid_del() could possibly free ->vlan_info after a RCU grace
period, however, we may still refer to the freed memory area
by 'grp' pointer. Found by code inspection.
This patch moves vlan_vid_del() as behind as possible.
Cc: Patrick McHardy <kaber@trash.net>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
net/8021q/vlan.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index a187144..85addcd 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -86,13 +86,6 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
grp = &vlan_info->grp;
- /* Take it out of our own structures, but be sure to interlock with
- * HW accelerating devices or SW vlan input packet processing if
- * VLAN is not 0 (leave it there for 802.1p).
- */
- if (vlan_id)
- vlan_vid_del(real_dev, vlan_id);
-
grp->nr_vlan_devs--;
if (vlan->flags & VLAN_FLAG_MVRP)
@@ -114,6 +107,13 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
vlan_gvrp_uninit_applicant(real_dev);
}
+ /* Take it out of our own structures, but be sure to interlock with
+ * HW accelerating devices or SW vlan input packet processing if
+ * VLAN is not 0 (leave it there for 802.1p).
+ */
+ if (vlan_id)
+ vlan_vid_del(real_dev, vlan_id);
+
/* Get rid of the vlan's reference to real_dev */
dev_put(real_dev);
}
--
1.7.7.6
^ permalink raw reply related
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: rebelyouth @ 2013-03-23 4:54 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130323021008.GC939@order.stressinduktion.org>
On 22/03/13 10:10 PM, Hannes Frederic Sowa wrote:
> On Fri, Mar 22, 2013 at 08:07:22PM -0400, rebelyouth wrote:
>> On 22/03/13 07:54 PM, Eric Dumazet wrote:
>>> On Fri, 2013-03-22 at 19:07 -0400, rebelyouth wrote:
>>>> Hi,
>>>>
>>>> I'm writing again for the same issue about :
>>>>
>>> Your mail is so long that we are lost.
>>>
>>> Have you done some research to tell if the bug is :
>>>
>>> 1) Sending corrupt frames
>>>
>>> 2) receive corrupt frames
>>>
>>>
>> Hi Eric and Hannes,
>>
>> The server receiver errors when I use the atheros:
>>
>> RX packets:78125369 errors:58741 dropped:0 overruns:58741 frame:0
>>
>> but on the client side there aren't any error but the file is corrupted
>>
>> I rebooted the server and did the test with the Realtek:
>>
>> file ok , no errors in both sides
>>
>> I also reset again the server and did a test on windows using samba and
>> the Atheros:
>>
>> file ok , no errors in both sides
> Could you try this patch? It solves the problem with an atl1e nic on my
> friends computer. This does not solve the real problem, which I have
> not yet understood (wrong packets will be discarded now and will be
> hopefully resend).
>
> [PATCH RFC] atl1e: don't rely on hardware checksumming
>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> index e1f1b2a..0363e5b 100644
> --- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> +++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> @@ -1337,6 +1337,8 @@ static inline void atl1e_rx_checksum(struct atl1e_adapter *adapter,
> u16 err_flags;
>
> skb_checksum_none_assert(skb);
> + goto hw_xsum;
> +
> pkt_flags = prrs->pkt_flag;
> err_flags = prrs->err_flag;
> if (((pkt_flags & RRS_IS_IPV4) || (pkt_flags & RRS_IS_IPV6)) &&
Hi Hannes,
I applied your patch on my the kernel 3.7.9 and look like the patch do
what you said before :
"This does not solve the real problem, which I have not yet understood
(wrong packets will be discarded now and will be hopefully resend). "
There are errors on the RX side of the server and the speed is 5~10%
less but the files are ok in nfsv4 , SFTP/FTP and samba.
Maybe the Atheros drivers for windows had a patch for the checksum
already in the drivers and the chipset have some hardware bug, but for
me your patch is already an achievement and I really thank you for your
time and consideration.
You will upload this patch to be included in the kernel? I hope so, a
lot of people had problem with this issue before and will be fantastic
if this fix will be included.
Thank you
Rebelyouth
^ permalink raw reply
* Re: [PATCH net-next 1/2] ip_gre: increase inner ip header ID during segmentation
From: Cong Wang @ 2013-03-23 3:25 UTC (permalink / raw)
To: Pravin Shelar; +Cc: netdev, Eric Dumazet, David S. Miller
In-Reply-To: <CALnjE+q=v4iu7kQod103P-gqCf5YRmJOKeA4-ev9LA_diaVdYA@mail.gmail.com>
On Fri, 2013-03-22 at 10:12 -0700, Pravin Shelar wrote:
> On Fri, Mar 22, 2013 at 3:31 AM, Cong Wang <amwang@redhat.com> wrote:
> > From: Cong Wang <amwang@redhat.com>
> >
> > According to the previous discussion [1] on netdev list, DaveM insists
> > we should increase the IP header ID for each segmented packets.
> > This patch fixes it.
> >
>
> Outer IP header ids are incremented in inet_gso_segment for GRE. So it
> is already done. In any case I don't think we should increment
> IP-Identification in GRE handler, This is layering violation.
> This breaks GRE with IPV6 payload.
I knew, $subject mentions this increases the *inner* IP header ID, not
outer one.
But you are probably right that we should check for IPv4, I will send
patch to fix it.
Thanks.
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-23 2:10 UTC (permalink / raw)
To: rebelyouth; +Cc: netdev
In-Reply-To: <514CF23A.3010702@gmail.com>
On Fri, Mar 22, 2013 at 08:07:22PM -0400, rebelyouth wrote:
> On 22/03/13 07:54 PM, Eric Dumazet wrote:
> >On Fri, 2013-03-22 at 19:07 -0400, rebelyouth wrote:
> >>Hi,
> >>
> >>I'm writing again for the same issue about :
> >>
> >Your mail is so long that we are lost.
> >
> >Have you done some research to tell if the bug is :
> >
> >1) Sending corrupt frames
> >
> >2) receive corrupt frames
> >
> >
> Hi Eric and Hannes,
>
> The server receiver errors when I use the atheros:
>
> RX packets:78125369 errors:58741 dropped:0 overruns:58741 frame:0
>
> but on the client side there aren't any error but the file is corrupted
>
> I rebooted the server and did the test with the Realtek:
>
> file ok , no errors in both sides
>
> I also reset again the server and did a test on windows using samba and
> the Atheros:
>
> file ok , no errors in both sides
Could you try this patch? It solves the problem with an atl1e nic on my
friends computer. This does not solve the real problem, which I have
not yet understood (wrong packets will be discarded now and will be
hopefully resend).
[PATCH RFC] atl1e: don't rely on hardware checksumming
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index e1f1b2a..0363e5b 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -1337,6 +1337,8 @@ static inline void atl1e_rx_checksum(struct atl1e_adapter *adapter,
u16 err_flags;
skb_checksum_none_assert(skb);
+ goto hw_xsum;
+
pkt_flags = prrs->pkt_flag;
err_flags = prrs->err_flag;
if (((pkt_flags & RRS_IS_IPV4) || (pkt_flags & RRS_IS_IPV6)) &&
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH 1/1]core:Change a wrong explain about dev_get_by_name
From: tingwei liu @ 2013-03-23 1:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Alexey Kuznetsov, davem
In-Reply-To: <1363793549.3333.12.camel@edumazet-glaptop>
On Wed, Mar 20, 2013 at 11:32 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2013-03-20 at 17:33 +0800, tingwei liu wrote:
>> From 5d787e8c3725efa6af3036eeb52aba1905c70de9 Mon Sep 17 00:00:00 2001
>> From: root <root@linux-19.site>
>> Date: Wed, 20 Mar 2013 17:39:59 +0800
>> Subject: [PATCH] Change a wrong explain about dev_get_by_name
>>
>
> No changelog ? This patch really needs a changelog.
>
How to get the lastest commit about this comment?
Thanks a lot.
> I have no idea why we should document this function being not safe in
> irq context.
>
> Most part of networking stack is non safe in hard irq context.
>
> Should we add a comment in front of all possible entry points ?
>
>
>
^ permalink raw reply
* Re: [PATCH 1/1]core:Change a wrong explain about dev_get_by_name
From: Eric Dumazet @ 2013-03-23 1:32 UTC (permalink / raw)
To: tingwei liu; +Cc: Ben Hutchings, netdev, Alexey Kuznetsov, davem
In-Reply-To: <CA+qZnST22XrkFgsNqE8aAziD++4EZXzBGzM-4GNbbxfi8z+yvQ@mail.gmail.com>
On Sat, 2013-03-23 at 09:24 +0800, tingwei liu wrote:
> On Thu, Mar 21, 2013 at 1:43 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Wed, 2013-03-20 at 17:10 +0000, Ben Hutchings wrote:
> >
> >> If they are wrongly documented as 'can be called from any context', yes.
> >
> > Wow, thats really useful.
> >
> > Why is this function not allowed from hard irq context, we have no idea.
> When function "list_netdevice" get write lock "dev_base_lock" only
> disable soft interrupt. So dev_get_by_name get read lock
> "dev_base_lock", can not called on interrupt context.
dev_get_by_name() doesn't read lock dev_base_lock
since commit 72c9528bab94cc052
This was back to linux-2.6.33
Are you sending patches for older kernel versions per chance ?
^ permalink raw reply
* Re: [PATCH 1/1]core:Change a wrong explain about dev_get_by_name
From: tingwei liu @ 2013-03-23 1:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Hutchings, netdev, Alexey Kuznetsov, davem
In-Reply-To: <1363801389.3333.25.camel@edumazet-glaptop>
On Thu, Mar 21, 2013 at 1:43 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2013-03-20 at 17:10 +0000, Ben Hutchings wrote:
>
>> If they are wrongly documented as 'can be called from any context', yes.
>
> Wow, thats really useful.
>
> Why is this function not allowed from hard irq context, we have no idea.
When function "list_netdevice" get write lock "dev_base_lock" only
disable soft interrupt. So dev_get_by_name get read lock
"dev_base_lock", can not called on interrupt context.
>
> Why someone would like to call it from hard irq context, we have no
> idea.
>
> I hope to get a clear explanation here, not only playing with words.
>
> Thanks
>
>
^ permalink raw reply
* [PATCH] net: remove a WARN_ON() in net_enable_timestamp()
From: Eric Dumazet @ 2013-03-23 0:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Laurent Chavey
From: Eric Dumazet <edumazet@google.com>
The WARN_ON(in_interrupt()) in net_enable_timestamp() can get false
positive, in socket clone path, run from softirq context :
[ 3641.624425] WARNING: at net/core/dev.c:1532 net_enable_timestamp+0x7b/0x80()
[ 3641.668811] Call Trace:
[ 3641.671254] <IRQ> [<ffffffff80286817>] warn_slowpath_common+0x87/0xc0
[ 3641.677871] [<ffffffff8028686a>] warn_slowpath_null+0x1a/0x20
[ 3641.683683] [<ffffffff80742f8b>] net_enable_timestamp+0x7b/0x80
[ 3641.689668] [<ffffffff80732ce5>] sk_clone_lock+0x425/0x450
[ 3641.695222] [<ffffffff8078db36>] inet_csk_clone_lock+0x16/0x170
[ 3641.701213] [<ffffffff807ae449>] tcp_create_openreq_child+0x29/0x820
[ 3641.707663] [<ffffffff807d62e2>] ? ipt_do_table+0x222/0x670
[ 3641.713354] [<ffffffff807aaf5b>] tcp_v4_syn_recv_sock+0xab/0x3d0
[ 3641.719425] [<ffffffff807af63a>] tcp_check_req+0x3da/0x530
[ 3641.724979] [<ffffffff8078b400>] ? inet_hashinfo_init+0x60/0x80
[ 3641.730964] [<ffffffff807ade6f>] ? tcp_v4_rcv+0x79f/0xbe0
[ 3641.736430] [<ffffffff807ab9bd>] tcp_v4_do_rcv+0x38d/0x4f0
[ 3641.741985] [<ffffffff807ae14a>] tcp_v4_rcv+0xa7a/0xbe0
Its safe at this point because the parent socket owns a reference
on the netstamp_needed, so we cant have a 0 -> 1 transition, which
requires to lock a mutex.
Instead of refining the check, lets remove it, as all known callers
are safe. If it ever changes in the future, static_key_slow_inc()
will complain anyway.
Reported-by: Laurent Chavey <chavey@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/dev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d540ced..b13e5c7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1545,7 +1545,6 @@ void net_enable_timestamp(void)
return;
}
#endif
- WARN_ON(in_interrupt());
static_key_slow_inc(&netstamp_needed);
}
EXPORT_SYMBOL(net_enable_timestamp);
^ permalink raw reply related
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: rebelyouth @ 2013-03-23 0:07 UTC (permalink / raw)
To: netdev
In-Reply-To: <1363996448.4431.73.camel@edumazet-glaptop>
On 22/03/13 07:54 PM, Eric Dumazet wrote:
> On Fri, 2013-03-22 at 19:07 -0400, rebelyouth wrote:
>> Hi,
>>
>> I'm writing again for the same issue about :
>>
> Your mail is so long that we are lost.
>
> Have you done some research to tell if the bug is :
>
> 1) Sending corrupt frames
>
> 2) receive corrupt frames
>
>
Hi Eric and Hannes,
The server receiver errors when I use the atheros:
RX packets:78125369 errors:58741 dropped:0 overruns:58741 frame:0
but on the client side there aren't any error but the file is corrupted
I rebooted the server and did the test with the Realtek:
file ok , no errors in both sides
I also reset again the server and did a test on windows using samba and
the Atheros:
file ok , no errors in both sides
my lspci -vv
03:00.0 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 47
Region 0: Memory at fbfc0000 (64-bit, non-prefetchable) [size=256K]
Region 2: I/O ports at ec00 [size=128]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 4142
Capabilities: [58] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 4096 bytes, PhantFunc 0, Latency L0s
<4us, L1 unlimited
ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+
AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s,
Latency L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
AERCap: First Error Pointer: 14, GenCap+ CGenEn-
ChkCap+ ChkEn-
Capabilities: [180 v1] Device Serial Number ff-62-72-f5-00-26-18-ff
and for the ASPM:
[ 0.407310] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device.
You can enable it with 'pcie_aspm=force'
[ 0.407800] pci0000:00: ACPI _OSC support notification failed,
disabling PCIe ASPM
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-23 0:01 UTC (permalink / raw)
To: rebelyouth; +Cc: netdev
In-Reply-To: <514CE440.3010003@gmail.com>
On Fri, Mar 22, 2013 at 07:07:44PM -0400, rebelyouth wrote:
> 02:00.0 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 45
>
> Region 0: Memory at fbfc0000 (64-bit, non-prefetchable) [size=256K]
>
> Region 2: I/O ports at ec00 [size=128]
>
> Capabilities: <access denied>
>
> Kernel driver in use: ATL1E
Could you show us the capabilities (running lspci -vv as root)? Please check
if ASPM is enabled and try to disable it in the BIOS.
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Eric Dumazet @ 2013-03-22 23:54 UTC (permalink / raw)
To: rebelyouth; +Cc: netdev
In-Reply-To: <514CE440.3010003@gmail.com>
On Fri, 2013-03-22 at 19:07 -0400, rebelyouth wrote:
> Hi,
>
> I'm writing again for the same issue about :
>
Your mail is so long that we are lost.
Have you done some research to tell if the bug is :
1) Sending corrupt frames
2) receive corrupt frames
^ permalink raw reply
* Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: rebelyouth @ 2013-03-22 23:07 UTC (permalink / raw)
To: netdev
Hi,
I'm writing again for the same issue about :
Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast
Ethernet (rev b0) 1.0.0.7 md5 /sha1 corrupted using NFS and samba
My solution in this past 7 months was one : don't use the chip (I also
deactivate the chip from the BIOS)
A friend of mine let me borrowed a pci-x with a Realtek RTL8168C/8111C.
The card worked in any condition, no problem with nfs or samba.
Unfortunately my friend need back the card for a project and I
activated back the Atheros card...and the problem is still there
I'm using at the moment a Debian sid with kernel 3.7.9 and a Chackra
2013 with kernel 3.7.6 and I see the atl1e is the same 1.0.0.7-NAPI :
modinfo atl1e
filename:
/lib/modules/3.7.9-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: 440FEE0BD620C8D71C0B74A
alias: pci:v00001969d00001066sv*sd*bc*sc*i*
alias: pci:v00001969d00001026sv*sd*bc*sc*i*
depends:
intree: Y
vermagic: 3.7.9-amd64 SMP preempt 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 know the simple solution will be to buy a card with a different chip
(like the Realtek RTL8168C/8111C) but I would like to help the
community with this issue.
The problem : files bigger of 1Gb are corrupted (and file 400mb + I
get a corruption in the 75% of the cases)
I don't receive any oops on the kernel or any dmesg error on the
client side but the server receive a lot of errors in RX:
RX packets:78125369 errors:58741 dropped:0 overruns:58741 frame:0
This are the test I did:
I test the connection with another cable CAT 6e, tried another router,
a switch and direct connection, also tried to connect another adapter
to the server
to see if the chipset on the server (Ethernet controller: NVIDIA
Corporation MCP79 Ethernet (rev b1) ) was the one who send corrupt
data or have a conflict with the atheros, but this, from my test,
wasn't the case
Software test:
I'm using Nfs 4 with this setting on the server:
/media 192.168.0.0/24(rw,fsid=0,no_subtree_check,sync)
/media/disk 192.168.0.0/24(rw,nohide,insecure,no_subtree_check,sync)
(tried async but doesn't fix the issue)
on the client : 192.168.0.1:/ /nfs nfs4
defaults,users,_netdev 0 0 (tried rsize=32768,wsize=32768, async
without success)
I tried too copy large zero files (400mb, 1gb, 4gb,8gb ,16gb) and the
sha1/md5 are ok
if I try a iso or vdi or a video bigger on these above that the
corruption occurs all the time,
same issue if I use samba.
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
Temp solution :
1) disable TSO with ethtool -K eth0 tso off NOT working (and not like
the 80%
in the previous email)
2) set the fstab on the nfs to use proto=udp working but samba files
are still corrupted
3) with the usb adapter with Axis AX88772A I have no problem with nfs
and samba with standard setting (the same setting I used with the
Realtek RTL8168C/8111C)
4) I notice on https://bugzilla.kernel.org/show_bug.cgi?id=12282 the
problem
is present from a long time and several people wrote about this
5) I would like to want to know why windows have no problem with the chip :
"It was interesting that I couldn't trigger this bug under Windows using the
Asus driver supplied. That suggested that either it's a atl1e driver
issue, or
that the Windows driver provides some way to checksum the data in software
that the atl1e driver doesn't, similar to the workaround Martin
suggested in #18."
is what the commenter wrote down on the Comment #21 From orion@frondeg.co.uk
UPDATE:
I did couple of test on the issue and this are the results:
NFSv4 : file 8Gb ,16Gb ,32Gb
TCP =speed 50 mb/s corrupted
UDP = 48 mb/s File OK
ethtool -K eth0 tso off / no udp = 50 mb corrupted
FTP/SFTP
tso off = 48 m/s File OK
tso on = 50 mb/s File OK
But in both I receive:
Error: Incorrect MAC received on packet
SAMBA
42 mb/s corrupted
I tried also to set at 100mbs , speed is 5 times lower but the result
are the
same.
Zero files are always ok.
This is ethtool -k eth0 for the card:
rx-checksumming: off [fixed]
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
I tried to disable rx-checksumming and tx-checksumming and scatter-gatherd
both on the client (Atheros) and server ( NVIDIA MCP79) but still the
have the
same issue.
UPDATE 2:
Today I bought a TP-LINK SOHO TG-3468, Gigabit PCIe Network Adapter
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI
Express Gigabit Ethernet controller (rev 06)
Subsystem: Device 7470:3468
Flags: bus master, fast devsel, latency 0, IRQ 43
I/O ports at d800 [size=256]
Memory at fbeff000 (64-bit, non-prefetchable) [size=4K]
Memory at faffc000 (64-bit, prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: r8169
the card working without problem on NFSv4, SFTP/FTP ,Samba
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: off
tx-scatter-gather: off
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
I did also the same test disabling and enabling rx-checksumming and tx-
checksumming and scatter-gatherd tec and the file are ok.
I saw the r8169.ko had problem in the past
https://lkml.org/lkml/2012/6/8/41 but now look ok
I hope these information will help to find the solution and I'm will
available for others tests.
Here my lspci -vvv:
00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge
Subsystem: Advanced Micro Devices [AMD] RS780 Host Bridge
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
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])
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
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fbe00000-fbefffff
Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
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])
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
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: fbf00000-fbffffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
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]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 42
Region 0: I/O ports at c000 [size=8]
Region 1: I/O ports at b000 [size=4]
Region 2: I/O ports at a000 [size=8]
Region 3: I/O ports at 9000 [size=4]
Region 4: I/O ports at 8000 [size=16]
Region 5: Memory at fbdffc00 (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
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fbdfd000 (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
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fbdfe000 (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
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at fbdff800 (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
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fbdfb000 (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
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fbdfc000 (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
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 19
Region 0: Memory at fbdff400 (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
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort+ <MAbort- >SERR- <PERR- INTx-
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
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at 01f0 [size=8]
Region 1: I/O ports at 03f4 [size=1]
Region 2: I/O ports at 0170 [size=8]
Region 3: I/O ports at 0374 [size=1]
Region 4: 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
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fbdf4000 (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
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to
PCI Bridge (prog-if 01 [Subtractive decode])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Bus: primary=00, secondary=03, subordinate=03, sec-latency=64
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: fff00000-000fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
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
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin C routed to IRQ 18
Region 0: Memory at fbdfa000 (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
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-
Capabilities: <access denied>
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
Address Map
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-
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
DRAM Controller
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-
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
Miscellaneous Control
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-
Capabilities: <access denied>
Kernel driver in use: k10temp
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
Link Control
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-
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
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 43
Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at fbec0000 (64-bit, non-prefetchable) [size=128K]
Region 4: I/O ports at d000 [size=256]
Expansion ROM at fbea0000 [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
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 B routed to IRQ 44
Region 0: Memory at fbefc000 (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
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 45
Region 0: Memory at fbfc0000 (64-bit, non-prefetchable) [size=256K]
Region 2: I/O ports at ec00 [size=128]
Capabilities: <access denied>
Kernel driver in use: ATL1E
And the lsusb :Bus 001 Device 004: ID 0b95:772a ASIX Electronics Corp.
AX88772A Fast Ethernet
^ permalink raw reply
* Re: [RFC][PATCH] iproute: Faster ip link add, set and delete
From: Stephen Hemminger @ 2013-03-22 22:27 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, Serge Hallyn, Benoit Lourdelet
In-Reply-To: <87k3ozm5v1.fsf@xmission.com>
The whole ifindex map is a design mistake at this point.
Better off to do a lazy cache or something like that.
On Fri, Mar 22, 2013 at 3:23 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> Because ip link add, set, and delete map the interface name to the
> interface index by dumping all of the interfaces before performing
> their respective commands. Operations that should be constant time
> slow down when lots of network interfaces are in use. Resulting
> in O(N^2) time to work with O(N) devices.
>
> Make the work that iproute does constant time by passing the interface
> name to the kernel instead.
>
> In small scale testing on my system this shows dramatic performance
> increases of ip link add from 120s to just 11s to add 5000 network
> devices. And from longer than I cared to wait to just 58s to delete
> all of those interfaces again.
>
> Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
> Reported-by: Benoit Lourdelet <blourdel@juniper.net>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
>
> I think I am bungling the case where people specify an ifindex as ifNNNN
> but does anyone care?
>
> ip/iplink.c | 19 +------------------
> 1 files changed, 1 insertions(+), 18 deletions(-)
>
> diff --git a/ip/iplink.c b/ip/iplink.c
> index ad33611..6dffbf0 100644
> --- a/ip/iplink.c
> +++ b/ip/iplink.c
> @@ -533,8 +533,6 @@ static int iplink_modify(int cmd, unsigned int flags, int argc, char **argv)
> }
> }
>
> - ll_init_map(&rth);
> -
> if (!(flags & NLM_F_CREATE)) {
> if (!dev) {
> fprintf(stderr, "Not enough information: \"dev\" "
> @@ -542,27 +540,12 @@ static int iplink_modify(int cmd, unsigned int flags, int argc, char **argv)
> exit(-1);
> }
>
> - req.i.ifi_index = ll_name_to_index(dev);
> - if (req.i.ifi_index == 0) {
> - fprintf(stderr, "Cannot find device \"%s\"\n", dev);
> - return -1;
> - }
> + name = dev;
> } else {
> /* Allow "ip link add dev" and "ip link add name" */
> if (!name)
> name = dev;
>
> - if (link) {
> - int ifindex;
> -
> - ifindex = ll_name_to_index(link);
> - if (ifindex == 0) {
> - fprintf(stderr, "Cannot find device \"%s\"\n",
> - link);
> - return -1;
> - }
> - addattr_l(&req.n, sizeof(req), IFLA_LINK, &ifindex, 4);
> - }
> }
>
> if (name) {
> --
> 1.7.5.4
>
^ permalink raw reply
* [RFC][PATCH] iproute: Faster ip link add, set and delete
From: Eric W. Biederman @ 2013-03-22 22:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Serge Hallyn, Benoit Lourdelet
Because ip link add, set, and delete map the interface name to the
interface index by dumping all of the interfaces before performing
their respective commands. Operations that should be constant time
slow down when lots of network interfaces are in use. Resulting
in O(N^2) time to work with O(N) devices.
Make the work that iproute does constant time by passing the interface
name to the kernel instead.
In small scale testing on my system this shows dramatic performance
increases of ip link add from 120s to just 11s to add 5000 network
devices. And from longer than I cared to wait to just 58s to delete
all of those interfaces again.
Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
Reported-by: Benoit Lourdelet <blourdel@juniper.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
I think I am bungling the case where people specify an ifindex as ifNNNN
but does anyone care?
ip/iplink.c | 19 +------------------
1 files changed, 1 insertions(+), 18 deletions(-)
diff --git a/ip/iplink.c b/ip/iplink.c
index ad33611..6dffbf0 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -533,8 +533,6 @@ static int iplink_modify(int cmd, unsigned int flags, int argc, char **argv)
}
}
- ll_init_map(&rth);
-
if (!(flags & NLM_F_CREATE)) {
if (!dev) {
fprintf(stderr, "Not enough information: \"dev\" "
@@ -542,27 +540,12 @@ static int iplink_modify(int cmd, unsigned int flags, int argc, char **argv)
exit(-1);
}
- req.i.ifi_index = ll_name_to_index(dev);
- if (req.i.ifi_index == 0) {
- fprintf(stderr, "Cannot find device \"%s\"\n", dev);
- return -1;
- }
+ name = dev;
} else {
/* Allow "ip link add dev" and "ip link add name" */
if (!name)
name = dev;
- if (link) {
- int ifindex;
-
- ifindex = ll_name_to_index(link);
- if (ifindex == 0) {
- fprintf(stderr, "Cannot find device \"%s\"\n",
- link);
- return -1;
- }
- addattr_l(&req.n, sizeof(req), IFLA_LINK, &ifindex, 4);
- }
}
if (name) {
--
1.7.5.4
^ permalink raw reply related
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