* [PATCH 1/1] ipv6: ignore looped-back NA while dad is running
From: Daniel Walter @ 2011-04-14 7:09 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, davem
[ipv6] Ignore looped-back NAs while in Duplicate Address Detection
If we send an unsolicited NA shortly after bringing up an
IPv6 address, the duplicate address detection algorithm
fails and the ip stays in tentative mode forever.
This is due a missing check if the NA is looped-back to us.
Signed-off-by: Daniel Walter <dwalter@barracuda.com>
---
apply against linux-2.6 HEAD
net/ipv6/ndisc.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
---
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 92f952d..f057ff3 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -945,9 +945,10 @@ static void ndisc_recv_na(struct sk_buff *skb)
}
ifp = ipv6_get_ifaddr(dev_net(dev), &msg->target, dev, 1);
if (ifp) {
- if (ifp->flags & IFA_F_TENTATIVE) {
- addrconf_dad_failure(ifp);
- return;
+ if (skb->pkt_type != PACKET_LOOPBACK
+ && (ifp->flags & IFA_F_TENTATIVE)) {
+ addrconf_dad_failure(ifp);
+ return;
}
/* What should we make now? The advertisement
is invalid, but ndisc specs say nothing
^ permalink raw reply related
* RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
From: Wei Gu @ 2011-04-14 6:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexander Duyck, Peter Zijlstra, netdev, Kirsher, Jeffrey T
In-Reply-To: <1302762810.3549.233.camel@edumazet-laptop>
I did the single flow test, it shows no rx error with 300kpps. While I was start multiple flow with same 300Kpps traffic, then it looks really bad with high rx_missing_error.
Multiple Flow:
SUM: 191925 ETH8: 0 ETH10: 191925 ETH6: 0 ETH4: 0
SUM: 214634 ETH8: 0 ETH10: 214634 ETH6: 0 ETH4: 0
SUM: 237600 ETH8: 0 ETH10: 237600 ETH6: 0 ETH4: 0
SUM: 198925 ETH8: 0 ETH10: 198925 ETH6: 0 ETH4: 0
SUM: 249290 ETH8: 0 ETH10: 249290 ETH6: 0 ETH4: 0
Single Flow:
SUM: 302018 ETH8: 0 ETH10: 302018 ETH6: 0 ETH4: 0
SUM: 301849 ETH8: 0 ETH10: 301849 ETH6: 0 ETH4: 0
SUM: 302163 ETH8: 0 ETH10: 302163 ETH6: 0 ETH4: 0
Thanks
WeiGu
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: Thursday, April 14, 2011 2:34 PM
To: Wei Gu
Cc: Alexander Duyck; Peter Zijlstra; netdev; Kirsher, Jeffrey T
Subject: RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
Le jeudi 14 avril 2011 à 08:07 +0200, Eric Dumazet a écrit :
> Le jeudi 14 avril 2011 à 13:42 +0800, Wei Gu a écrit :
> > Hi guys,
> > Do you think it was a bug in the kernel from 2.6.35.2 with Intel 10GE ixgbe driver?
> > If so shall I issue a Bug on the bugzilla, and which category? Cause I'm not sure it was driver problem Or sched problem.
>
> This makes no sense to me.
>
> What is the maximum throughput you can get in pps before having packet
> drops ?
>
> Please try with a single flow (to hit one queue, one cpu)
>
> Thanks
>
Also, please try to check if using smaller or bigger packets makes any change in this max throughput
^ permalink raw reply
* [PATCH] NET: AX.25, NETROM, ROSE: Remove SOCK_DEBUG calls
From: Ralf Baechle @ 2011-04-14 6:49 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-hams
Nobody alive seems to recall when they last were useful.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
net/ax25/af_ax25.c | 16 +---------------
net/netrom/af_netrom.c | 12 +-----------
net/rose/af_rose.c | 16 ++--------------
3 files changed, 4 insertions(+), 40 deletions(-)
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 6da5dae..e7c69f4 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1538,8 +1538,6 @@ static int ax25_sendmsg(struct kiocb *iocb, struct socket *sock,
}
/* Build a packet */
- SOCK_DEBUG(sk, "AX.25: sendto: Addresses built. Building packet.\n");
-
/* Assume the worst case */
size = len + ax25->ax25_dev->dev->hard_header_len;
@@ -1549,8 +1547,6 @@ static int ax25_sendmsg(struct kiocb *iocb, struct socket *sock,
skb_reserve(skb, size - len);
- SOCK_DEBUG(sk, "AX.25: Appending user data\n");
-
/* User data follows immediately after the AX.25 data */
if (memcpy_fromiovec(skb_put(skb, len), msg->msg_iov, len)) {
err = -EFAULT;
@@ -1564,8 +1560,6 @@ static int ax25_sendmsg(struct kiocb *iocb, struct socket *sock,
if (!ax25->pidincl)
*skb_push(skb, 1) = sk->sk_protocol;
- SOCK_DEBUG(sk, "AX.25: Transmitting buffer\n");
-
if (sk->sk_type == SOCK_SEQPACKET) {
/* Connected mode sockets go via the LAPB machine */
if (sk->sk_state != TCP_ESTABLISHED) {
@@ -1583,22 +1577,14 @@ static int ax25_sendmsg(struct kiocb *iocb, struct socket *sock,
skb_push(skb, 1 + ax25_addr_size(dp));
- SOCK_DEBUG(sk, "Building AX.25 Header (dp=%p).\n", dp);
-
- if (dp != NULL)
- SOCK_DEBUG(sk, "Num digipeaters=%d\n", dp->ndigi);
+ /* Building AX.25 Header */
/* Build an AX.25 header */
lv = ax25_addr_build(skb->data, &ax25->source_addr, &sax.sax25_call,
dp, AX25_COMMAND, AX25_MODULUS);
- SOCK_DEBUG(sk, "Built header (%d bytes)\n",lv);
-
skb_set_transport_header(skb, lv);
- SOCK_DEBUG(sk, "base=%p pos=%p\n",
- skb->data, skb_transport_header(skb));
-
*skb_transport_header(skb) = AX25_UI;
/* Datagram frames go straight out of the door as UI */
diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
index 06cb027..732152f 100644
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -591,7 +591,6 @@ static int nr_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
return -EINVAL;
}
if ((dev = nr_dev_get(&addr->fsa_ax25.sax25_call)) == NULL) {
- SOCK_DEBUG(sk, "NET/ROM: bind failed: invalid node callsign\n");
release_sock(sk);
return -EADDRNOTAVAIL;
}
@@ -632,7 +631,7 @@ static int nr_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
sock_reset_flag(sk, SOCK_ZAPPED);
dev_put(dev);
release_sock(sk);
- SOCK_DEBUG(sk, "NET/ROM: socket is bound\n");
+
return 0;
}
@@ -1082,8 +1081,6 @@ static int nr_sendmsg(struct kiocb *iocb, struct socket *sock,
sax.sax25_call = nr->dest_addr;
}
- SOCK_DEBUG(sk, "NET/ROM: sendto: Addresses built.\n");
-
/* Build a packet - the conventional user limit is 236 bytes. We can
do ludicrously large NetROM frames but must not overflow */
if (len > 65536) {
@@ -1091,7 +1088,6 @@ static int nr_sendmsg(struct kiocb *iocb, struct socket *sock,
goto out;
}
- SOCK_DEBUG(sk, "NET/ROM: sendto: building packet.\n");
size = len + NR_NETWORK_LEN + NR_TRANSPORT_LEN;
if ((skb = sock_alloc_send_skb(sk, size, msg->msg_flags & MSG_DONTWAIT, &err)) == NULL)
@@ -1105,7 +1101,6 @@ static int nr_sendmsg(struct kiocb *iocb, struct socket *sock,
*/
asmptr = skb_push(skb, NR_TRANSPORT_LEN);
- SOCK_DEBUG(sk, "Building NET/ROM Header.\n");
/* Build a NET/ROM Transport header */
@@ -1114,15 +1109,12 @@ static int nr_sendmsg(struct kiocb *iocb, struct socket *sock,
*asmptr++ = 0; /* To be filled in later */
*asmptr++ = 0; /* Ditto */
*asmptr++ = NR_INFO;
- SOCK_DEBUG(sk, "Built header.\n");
/*
* Put the data on the end
*/
skb_put(skb, len);
- SOCK_DEBUG(sk, "NET/ROM: Appending user data\n");
-
/* User data follows immediately after the NET/ROM transport header */
if (memcpy_fromiovec(skb_transport_header(skb), msg->msg_iov, len)) {
kfree_skb(skb);
@@ -1130,8 +1122,6 @@ static int nr_sendmsg(struct kiocb *iocb, struct socket *sock,
goto out;
}
- SOCK_DEBUG(sk, "NET/ROM: Transmitting buffer\n");
-
if (sk->sk_state != TCP_ESTABLISHED) {
kfree_skb(skb);
err = -ENOTCONN;
diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index a80aef6..f9ea925 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -682,10 +682,8 @@ static int rose_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
if ((unsigned int) addr->srose_ndigis > ROSE_MAX_DIGIS)
return -EINVAL;
- if ((dev = rose_dev_get(&addr->srose_addr)) == NULL) {
- SOCK_DEBUG(sk, "ROSE: bind failed: invalid address\n");
+ if ((dev = rose_dev_get(&addr->srose_addr)) == NULL)
return -EADDRNOTAVAIL;
- }
source = &addr->srose_call;
@@ -716,7 +714,7 @@ static int rose_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
rose_insert_socket(sk);
sock_reset_flag(sk, SOCK_ZAPPED);
- SOCK_DEBUG(sk, "ROSE: socket is bound\n");
+
return 0;
}
@@ -1109,10 +1107,7 @@ static int rose_sendmsg(struct kiocb *iocb, struct socket *sock,
srose.srose_digis[n] = rose->dest_digis[n];
}
- SOCK_DEBUG(sk, "ROSE: sendto: Addresses built.\n");
-
/* Build a packet */
- SOCK_DEBUG(sk, "ROSE: sendto: building packet.\n");
/* Sanity check the packet size */
if (len > 65535)
return -EMSGSIZE;
@@ -1127,7 +1122,6 @@ static int rose_sendmsg(struct kiocb *iocb, struct socket *sock,
/*
* Put the data on the end
*/
- SOCK_DEBUG(sk, "ROSE: Appending user data\n");
skb_reset_transport_header(skb);
skb_put(skb, len);
@@ -1152,8 +1146,6 @@ static int rose_sendmsg(struct kiocb *iocb, struct socket *sock,
*/
asmptr = skb_push(skb, ROSE_MIN_LEN);
- SOCK_DEBUG(sk, "ROSE: Building Network Header.\n");
-
/* Build a ROSE Network header */
asmptr[0] = ((rose->lci >> 8) & 0x0F) | ROSE_GFI;
asmptr[1] = (rose->lci >> 0) & 0xFF;
@@ -1162,10 +1154,6 @@ static int rose_sendmsg(struct kiocb *iocb, struct socket *sock,
if (qbit)
asmptr[0] |= ROSE_Q_BIT;
- SOCK_DEBUG(sk, "ROSE: Built header.\n");
-
- SOCK_DEBUG(sk, "ROSE: Transmitting buffer\n");
-
if (sk->sk_state != TCP_ESTABLISHED) {
kfree_skb(skb);
return -ENOTCONN;
^ permalink raw reply related
* RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
From: Eric Dumazet @ 2011-04-14 6:33 UTC (permalink / raw)
To: Wei Gu; +Cc: Alexander Duyck, Peter Zijlstra, netdev, Kirsher, Jeffrey T
In-Reply-To: <1302761251.3549.198.camel@edumazet-laptop>
Le jeudi 14 avril 2011 à 08:07 +0200, Eric Dumazet a écrit :
> Le jeudi 14 avril 2011 à 13:42 +0800, Wei Gu a écrit :
> > Hi guys,
> > Do you think it was a bug in the kernel from 2.6.35.2 with Intel 10GE ixgbe driver?
> > If so shall I issue a Bug on the bugzilla, and which category? Cause I'm not sure it was driver problem Or sched problem.
>
> This makes no sense to me.
>
> What is the maximum throughput you can get in pps before having packet
> drops ?
>
> Please try with a single flow (to hit one queue, one cpu)
>
> Thanks
>
Also, please try to check if using smaller or bigger packets makes any
change in this max throughput
^ permalink raw reply
* RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
From: Eric Dumazet @ 2011-04-14 6:07 UTC (permalink / raw)
To: Wei Gu; +Cc: Alexander Duyck, Peter Zijlstra, netdev, Kirsher, Jeffrey T
In-Reply-To: <D12839161ADD3A4B8DA63D1A134D084026E49535F2@ESGSCCMS0001.eapac.ericsson.se>
Le jeudi 14 avril 2011 à 13:42 +0800, Wei Gu a écrit :
> Hi guys,
> Do you think it was a bug in the kernel from 2.6.35.2 with Intel 10GE ixgbe driver?
> If so shall I issue a Bug on the bugzilla, and which category? Cause I'm not sure it was driver problem Or sched problem.
This makes no sense to me.
What is the maximum throughput you can get in pps before having packet
drops ?
Please try with a single flow (to hit one queue, one cpu)
Thanks
^ permalink raw reply
* Re: [Bugme-new] [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: Simon Horman @ 2011-04-14 2:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, akpm, netdev, bugzilla-daemon, bugme-daemon, kees
In-Reply-To: <1302663327.2811.55.camel@edumazet-laptop>
On Wed, Apr 13, 2011 at 04:55:27AM +0200, Eric Dumazet wrote:
> Le mardi 12 avril 2011 à 16:17 -0700, David Miller a écrit :
> > From: Andrew Morton <akpm@linux-foundation.org>
> > Date: Tue, 12 Apr 2011 16:15:56 -0700
> >
> > >
> > > (switched to email. Please respond via emailed reply-to-all, not via the
> > > bugzilla web interface).
> >
> > Stephen Hemminger forwarded this to the list last week, and Eric
> > Dumazet is actively working on a fix.
>
> I worked on it this week end to discover FreeBSD 8.1 would not allow
> several CLOSE sockets bound to same port even with REUSEADDR.
>
> So haproxy claim is a bit wrong (its trick doesnt work on FreeBSD), and
> used an undocumented linux feature.
>
> I feel this case is a call for SO_REUSEPORT, eventually.
>
> http://www.unixguide.net/network/socketfaq/4.11.shtml
>
> SO_REUSEADDR allows your server to bind to an address which is in a
> TIME_WAIT state. It does not allow more than one server to bind to
> the same address. It was mentioned that use of this flag can create a
> security risk because another server can bind to a the same port, by
> binding to a specific address as opposed to INADDR_ANY. The
> SO_REUSEPORT flag allows multiple processes to bind to the same
> address provided all of them use the SO_REUSEPORT option.
>
>
> Since SO_REUSEPORT is not a 'stable fix', I suggest we revert the patch,
> and eventually work on SO_REUSEPORT on net-next-2.6
>
> What do you think ?
Not entirely related, but FWIW I think that SO_REUSEPORT would
be rather useful for haproxy.
I've been working on allowing haproxy to be reconfigured without dropping
or reusing connections. I have done this by re-using open sockets. But it
would have been rather a lot easier to achieve using SO_REUSEPORT -
assuming that I understand SO_REUSEPORT correctly.
^ permalink raw reply
* RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
From: Wei Gu @ 2011-04-14 5:42 UTC (permalink / raw)
To: Eric Dumazet, Alexander Duyck, Peter Zijlstra; +Cc: netdev, Kirsher, Jeffrey T
In-Reply-To: <1302536577.4605.1.camel@edumazet-laptop>
Hi guys,
Do you think it was a bug in the kernel from 2.6.35.2 with Intel 10GE ixgbe driver?
If so shall I issue a Bug on the bugzilla, and which category? Cause I'm not sure it was driver problem Or sched problem.
Thans
WeiGu
-----Original Message-----
From: Wei Gu
Sent: Tuesday, April 12, 2011 12:40 PM
To: 'Eric Dumazet'; 'Alexander Duyck'; 'Peter Zijlstra'
Cc: 'netdev'; 'Kirsher, Jeffrey T'
Subject: RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
Hi,
I found the problem was introduced by this revert patch "2010-08-13 Peter Zijlstra sched: Revert nohz_ratelimit() for now"
I tried the remove this patch from 2.6.35.2 and then build the application again, then the ixgbe driver looks works fine.
I don't know why this time revert the nohz_ratelimit() will cause the problem on ixgbe driver, since this nohz_ratelimit was first introduced "2010-03-11". And before that time with 2.6.32 kernel it also doesn't have this problem with ixgbe driver.
Some log from git:
=========================================================================================
2.6.35.2
2010-08-13 Peter Zijlstra sched: Revert nohz_ratelimit() for now
2.6.35.1
2010-08-01 Linus Torvalds Linux 2.6.35 v2.6.35
2010-06-17 Peter Zijlstra nohz: Fix nohz ratelimit
2.6.35-rc3
2010-03-11 Mike Galbraith sched: Rate-limit nohz
Thanks
WeiGu
-----Original Message-----
From: Wei Gu
Sent: Tuesday, April 12, 2011 9:23 AM
To: 'Eric Dumazet'
Cc: Alexander Duyck; netdev; Kirsher, Jeffrey T
Subject: RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
I was not stress the NIC/CPU, since I only send 290Kpps 400byte packets towards eth10. the CPU load almost 100%IDEL.
BTW, there are some problem with perf tool on 2.6.35.2, I will try to get you the top offenders if possible.
Thanks
WeiGu
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: Monday, April 11, 2011 11:43 PM
To: Wei Gu
Cc: Alexander Duyck; netdev; Kirsher, Jeffrey T
Subject: RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
Le lundi 11 avril 2011 à 23:14 +0800, Wei Gu a écrit :
> I tried the ixgbe-3.3.8 (insmod ixgbe.ko RSS=8,8,8,8,8,8,8,8 FdirMode=0,0,0,0,0,0,0,0 Node=0,0,1,1,2,2,3,3) from e1000.sf.net both on 2.6.35.1 and 2.6.35.2, same observation as 3.2.10 ixgbe driver, On 2.6.35.2 it have high rx errors:
> Ethtool -S eth10 |grep error
> rx_errors: 0
> tx_errors: 0
> rx_over_errors: 0
> rx_crc_errors: 0
> rx_frame_errors: 0
> rx_fifo_errors: 0
> rx_missed_errors: 2263088
> tx_aborted_errors: 0
> tx_carrier_errors: 0
> tx_fifo_errors: 0
> tx_heartbeat_errors: 0
> rx_long_length_errors: 0
> rx_short_length_errors: 0
> rx_csum_offload_errors: 0
> fcoe_last_errors: 0
>
It would be nice you post perf record / perf report results
During your stress , do
perf record -a -g sleep 10
perf report
And post "top offenders"
Thanks
^ permalink raw reply
* RE: [stable] [PATCH NET-2.6 1/1] qlcnic: limit skb frags for non tso packet
From: Amit Salecha @ 2011-04-14 5:22 UTC (permalink / raw)
To: Greg KH; +Cc: David Miller, netdev, Anirban Chakraborty, stable, Ameen Rahman
In-Reply-To: <20110413161534.GA20578@kroah.com>
> > Footer will present in my reply to this email. But footer should not
> be there in patches sent by me.
> > Can you verify patch version 2 again ? Here
> http://patchwork.ozlabs.org/patch/90938/ I don't see any footer.
> > If you see footer with patch version 2, please send me that.
>
> Your footer was not in your patch, correct. But it was in this email.
>
> And that's the issue, you can't have that footer on emails you send to
> a
> public list where you are going to be collaborating on a public
> project,
> otherwise no one can use anything you say.
>
> Now if you only think that people will just accept your patches,
> without
> being able to have you participate in development and maintance of
> those
> patches (which is required to be done through email), you are mistaken.
>
> So please fix your email issue, otherwise it is not going to work.
>
> Note, other people at qualcomm have fixed this, so you are not alone.
>
Ok.
Our IT has fixed the footer issue. Sending this email to verify.
-Amit
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* Re: [PATCH] ip: ip_options_compile() resilient to NULL skb route
From: Hiroaki SHIMODA @ 2011-04-14 4:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, David Miller, lkml, netdev
In-Reply-To: <1302752263.3549.41.camel@edumazet-laptop>
On Thu, 14 Apr 2011 05:37:43 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Indeed good catch, but should we return 0 or -EINVAL so that caller can
> drop packet ?
>
> @@ -606,7 +606,7 @@ int ip_options_rcv_srr(struct sk_buff *skb)
> if (!opt->srr)
> return 0;
>
> - if (skb->pkt_type != PACKET_HOST)
> + if (skb->pkt_type != PACKET_HOST || !rt)
> return -EINVAL;
> if (rt->rt_type == RTN_UNICAST) {
> if (!opt->is_strictroute)
>
As your patch does we don't treat an skb without rt as error
on bridge/netfilter context.
So, I think returning 0 would be better off.
But thinking of ip_options_rcv_srr() is called from another context again
adding an extra check in br_parse_ip_options() is safer ?
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index f3bc322..10ac127 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -263,7 +263,7 @@ static int br_parse_ip_options(struct sk_buff *skb)
if (in_dev && !IN_DEV_SOURCE_ROUTE(in_dev))
goto drop;
- if (ip_options_rcv_srr(skb))
+ if (skb_rtable(skb) && ip_options_rcv_srr(skb))
goto drop;
}
Thanks.
^ permalink raw reply related
* RE: SMSC 8720a/MDIO/PHY help.
From: ANDY KENNEDY @ 2011-04-14 4:08 UTC (permalink / raw)
To: netdev
In-Reply-To: <9AC3F0E75060224C8BBC5BA2DDC8853A1FA8E8D4@EXV1.corp.adtran.com>
> > -----Original Message-----
> > From: Michael Riesch [mailto:michael@riesch.at]
> > Sent: Wednesday, April 13, 2011 4:19 PM
> > To: netdev@vger.kernel.org
> > Cc: ANDY KENNEDY
> > Subject: Re: SMSC 8720a/MDIO/PHY help.
> >
> >
> > > If you have an idea of something for me to try, I'd love to
> > entertain
> > > it.
> >
> > I am rather new to PHYLIB, but these are my ideas:
> >
> > 1) make sure phy_connect is executed (AFIAK called by MDIO bus
> > driver)
Along this line of though: phy_connect requires struct net_device, which has a struct net_device_ops within it. When I do a phy_connect am I supposed to provide the minimal functions for netdev_ops (correct this list if I am mistaken):
ndo_open
ndo_stop
ndo_start_xmit
ndo_get_stats
ndo_set_multicast_list
As well as populate the dev->dev_addr within the struct net_device.
The part that confuses me is that the smsc.c ??driver?? under drivers/net/phy/smsc.c doesn’t do any of this. This is a phy supported by this file, so should I have to do all this to get the device up?
Spinning,
Andy
^ permalink raw reply
* Re: [PATCH] ip: ip_options_compile() resilient to NULL skb route
From: Eric Dumazet @ 2011-04-14 3:37 UTC (permalink / raw)
To: Hiroaki SHIMODA; +Cc: Stephen Hemminger, David Miller, lkml, netdev
In-Reply-To: <20110414123058.d4ffe7fb.shimoda.hiroaki@gmail.com>
Le jeudi 14 avril 2011 à 12:30 +0900, Hiroaki SHIMODA a écrit :
> On Thu, 14 Apr 2011 05:03:34 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Le mercredi 13 avril 2011 à 19:54 -0700, Stephen Hemminger a écrit :
> >
> > > I like this because it lets the bridge be transparent.
> > > The existing options code adds entry in record route, and which
> > > is not desirable.
> >
> > OK then, I realize I should have submitted a full patch, here it is.
> >
> > Thanks !
> >
> > [PATCH] ip: ip_options_compile() resilient to NULL skb route
> >
> > Scot Doyle demonstrated ip_options_compile() could be called with an skb
> > without an attached route, using a setup involving a bridge, netfilter,
> > and forged IP packets.
> >
> > Let's make ip_options_compile() a bit more robust, instead of changing
> > bridge/netfilter code.
>
> And ip_options_rcv_srr() in br_parse_ip_options() also
> expects an skb with attached route, so below patch is needed ?
>
> diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
> index 28a736f..3af1968 100644
> --- a/net/ipv4/ip_options.c
> +++ b/net/ipv4/ip_options.c
> @@ -603,7 +603,7 @@ int ip_options_rcv_srr(struct sk_buff *skb)
> unsigned long orefdst;
> int err;
>
> - if (!opt->srr)
> + if (!opt->srr || !rt)
> return 0;
>
> if (skb->pkt_type != PACKET_HOST)
>
> Thanks.
Indeed good catch, but should we return 0 or -EINVAL so that caller can
drop packet ?
@@ -606,7 +606,7 @@ int ip_options_rcv_srr(struct sk_buff *skb)
if (!opt->srr)
return 0;
- if (skb->pkt_type != PACKET_HOST)
+ if (skb->pkt_type != PACKET_HOST || !rt)
return -EINVAL;
if (rt->rt_type == RTN_UNICAST) {
if (!opt->is_strictroute)
^ permalink raw reply
* Re: [PATCH] ip: ip_options_compile() resilient to NULL skb route
From: Hiroaki SHIMODA @ 2011-04-14 3:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, David Miller, lkml, netdev
In-Reply-To: <1302750214.3549.34.camel@edumazet-laptop>
On Thu, 14 Apr 2011 05:03:34 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 13 avril 2011 à 19:54 -0700, Stephen Hemminger a écrit :
>
> > I like this because it lets the bridge be transparent.
> > The existing options code adds entry in record route, and which
> > is not desirable.
>
> OK then, I realize I should have submitted a full patch, here it is.
>
> Thanks !
>
> [PATCH] ip: ip_options_compile() resilient to NULL skb route
>
> Scot Doyle demonstrated ip_options_compile() could be called with an skb
> without an attached route, using a setup involving a bridge, netfilter,
> and forged IP packets.
>
> Let's make ip_options_compile() a bit more robust, instead of changing
> bridge/netfilter code.
And ip_options_rcv_srr() in br_parse_ip_options() also
expects an skb with attached route, so below patch is needed ?
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 28a736f..3af1968 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -603,7 +603,7 @@ int ip_options_rcv_srr(struct sk_buff *skb)
unsigned long orefdst;
int err;
- if (!opt->srr)
+ if (!opt->srr || !rt)
return 0;
if (skb->pkt_type != PACKET_HOST)
Thanks.
^ permalink raw reply related
* [PATCH] ip: ip_options_compile() resilient to NULL skb route
From: Eric Dumazet @ 2011-04-14 3:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, lkml, shimoda.hiroaki, netdev
In-Reply-To: <20110413195424.1d2393c6@s6510>
Le mercredi 13 avril 2011 à 19:54 -0700, Stephen Hemminger a écrit :
> I like this because it lets the bridge be transparent.
> The existing options code adds entry in record route, and which
> is not desirable.
OK then, I realize I should have submitted a full patch, here it is.
Thanks !
[PATCH] ip: ip_options_compile() resilient to NULL skb route
Scot Doyle demonstrated ip_options_compile() could be called with an skb
without an attached route, using a setup involving a bridge, netfilter,
and forged IP packets.
Let's make ip_options_compile() a bit more robust, instead of changing
bridge/netfilter code.
Reported-by: Scot Doyle <lkml@scotdoyle.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
---
net/ipv4/ip_options.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 28a736f..c10ad63 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -329,7 +329,7 @@ int ip_options_compile(struct net *net,
pp_ptr = optptr + 2;
goto error;
}
- if (skb) {
+ if (rt) {
memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
opt->is_changed = 1;
}
@@ -371,7 +371,7 @@ int ip_options_compile(struct net *net,
goto error;
}
opt->ts = optptr - iph;
- if (skb) {
+ if (rt) {
memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
timeptr = (__be32*)&optptr[optptr[2]+3];
}
^ permalink raw reply related
* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Stephen Hemminger @ 2011-04-14 2:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, lkml, shimoda.hiroaki, netdev
In-Reply-To: <1302748276.3549.20.camel@edumazet-laptop>
On Thu, 14 Apr 2011 04:31:16 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 13 avril 2011 à 14:48 -0700, David Miller a écrit :
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 13 Apr 2011 17:28:07 +0200
> >
> > > Dont worry, Stephen or me will send it asap.
> >
> > I'm looking forward to it :)
>
> I was considering another way to handle this problem,
> patching ip_options_compile() to take care of null skb_dst() in slow
> path instead ?
>
> What would be the best thing ?
>
> diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
> index 28a736f..c10ad63 100644
> --- a/net/ipv4/ip_options.c
> +++ b/net/ipv4/ip_options.c
> @@ -329,7 +329,7 @@ int ip_options_compile(struct net *net,
> pp_ptr = optptr + 2;
> goto error;
> }
> - if (skb) {
> + if (rt) {
> memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
> opt->is_changed = 1;
> }
> @@ -371,7 +371,7 @@ int ip_options_compile(struct net *net,
> goto error;
> }
> opt->ts = optptr - iph;
> - if (skb) {
> + if (rt) {
> memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
> timeptr = (__be32*)&optptr[optptr[2]+3];
> }
>
I like this because it lets the bridge be transparent.
The existing options code adds entry in record route, and which
is not desirable.
^ permalink raw reply
* [net-next-2.6 00/26 v2][pull request] Intel Wired LAN Driver Update
From: Jeff Kirsher @ 2011-04-14 2:38 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
The following series contains updates to e1000e, igb and ixgbe.
- e1000e has two conversion, one to use usleep_range and the other
to the new VLAN model. There is also a fix for a debug statement as
well as a fix for ASPM.
- igb has a documentation update, comment fix, and the introduction
of thermal sensor checking.
- ixgbe contains the majority of the changes, with several cleanups
and fixes. As well as a conversion to use usleep_range().
-v2 Drop the e1000 patch to convert to the new set_phys_id interface
The following are changes since commit c326de88b8ac7ed1cd1027017ba6079dbe91be49:
net: allow shifted access in smsc911x V2
and are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
Bruce Allan (3):
e1000e: convert short duration msleep() to usleep_range()
e1000e: PCIe link speed in GT/s, not GB/s
e1000e: If ASPM L0s needs to be disabled, do it prior to enabling
device
Don Skidmore (1):
ixgbe: cleanup short msleep's (<20ms) to use usleep_range
Emil Tantilov (10):
ixgbe: fix return value checks
ixgbe: correct function number for some 82598 parts
ixgbe: fix namespacecheck issue
ixgbe: refactor common start_hw code for 82599 and x540
ixgbe: move disabling of relaxed ordering in start_hw()
ixgbe: fix 82599 KR downshift coexistence with LESM FW module
ixgbe: fix semaphores in eeprom routines for x540
ixgbe: add support for new HW
ixgbe: explicitly disable 100H for x540
ixgbe: make device_caps() generic
Flavio Leitner (1):
e1000e: fix stats locking in e1000_watchdog_task
Greg Rose (1):
igb: Add anti-spoofing feature documentation
Jeff Kirsher (2):
e1000e: convert to new VLAN model
ixgbe: update version string for Dell CEM use
John Fastabend (3):
ixgbe: DCB, further cleanups to app configuration
ixgbe: DCB, misallocated packet buffer size with X540 device
ixgbe: DCB, X540 devices do not respond to pause frames
Stefan Assmann (2):
igb: fix typo in igb_validate_nvm_checksum_82580
igb: introduce igb_thermal_sensor_event for sensor checking
Documentation/networking/igb.txt | 13 ++
drivers/net/e1000e/82571.c | 20 ++--
drivers/net/e1000e/e1000.h | 6 +-
drivers/net/e1000e/es2lan.c | 4 +-
drivers/net/e1000e/ethtool.c | 46 ++++++--
drivers/net/e1000e/ich8lan.c | 12 +-
drivers/net/e1000e/lib.c | 10 +-
drivers/net/e1000e/netdev.c | 211 ++++++++++++++++++++---------------
drivers/net/e1000e/phy.c | 4 +-
drivers/net/igb/e1000_82575.c | 3 +-
drivers/net/igb/igb_main.c | 67 ++++++------
drivers/net/ixgbe/ixgbe_82598.c | 60 ++++++++++-
drivers/net/ixgbe/ixgbe_82599.c | 104 ++++++++++++------
drivers/net/ixgbe/ixgbe_common.c | 112 ++++++++++++++++++-
drivers/net/ixgbe/ixgbe_common.h | 4 +-
drivers/net/ixgbe/ixgbe_dcb_82599.c | 77 ++++++++-----
drivers/net/ixgbe/ixgbe_dcb_82599.h | 2 +
drivers/net/ixgbe/ixgbe_dcb_nl.c | 109 ++++--------------
drivers/net/ixgbe/ixgbe_ethtool.c | 14 +-
drivers/net/ixgbe/ixgbe_main.c | 22 ++--
drivers/net/ixgbe/ixgbe_phy.c | 7 +-
drivers/net/ixgbe/ixgbe_type.h | 12 ++
drivers/net/ixgbe/ixgbe_x540.c | 192 +++++++++++++++++++++++---------
23 files changed, 718 insertions(+), 393 deletions(-)
--
1.7.4.2
^ permalink raw reply
* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Eric Dumazet @ 2011-04-14 2:31 UTC (permalink / raw)
To: David Miller; +Cc: lkml, shemminger, shimoda.hiroaki, netdev
In-Reply-To: <20110413.144812.116375845.davem@davemloft.net>
Le mercredi 13 avril 2011 à 14:48 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 13 Apr 2011 17:28:07 +0200
>
> > Dont worry, Stephen or me will send it asap.
>
> I'm looking forward to it :)
I was considering another way to handle this problem,
patching ip_options_compile() to take care of null skb_dst() in slow
path instead ?
What would be the best thing ?
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 28a736f..c10ad63 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -329,7 +329,7 @@ int ip_options_compile(struct net *net,
pp_ptr = optptr + 2;
goto error;
}
- if (skb) {
+ if (rt) {
memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
opt->is_changed = 1;
}
@@ -371,7 +371,7 @@ int ip_options_compile(struct net *net,
goto error;
}
opt->ts = optptr - iph;
- if (skb) {
+ if (rt) {
memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
timeptr = (__be32*)&optptr[optptr[2]+3];
}
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2 3/3] sctp: Add a valid address list in association local
From: Michio Honda @ 2011-04-14 2:28 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev, lksctp-developers
In-Reply-To: <4DA65AEF.70800@cn.fujitsu.com>
Ah, OK, if so, this patch is unnecessary.
Sorry for missing to read the code.
Thanks,
- Michio
On Apr 14, 2011, at 11:24 , Wei Yongjun wrote:
>
>> Hi,
>>
>> I implemented that functionality for following situations.
>> 1. Suppose two associations A and B directed to different destination that belong to the same endpoint. (one-to-many socket).
>
> Yes, but the addr list of assoc A and B is independent, see
> asoc->base.bind_addr, which is per asoc.
>
> endpoint hold the bind list for new create assoc. when assoc
> is created, the bind list will be copy from ep, by
> sctp_assoc_set_bind_addr_from_ep().
>
>> 2. After the address addition event, A and B will send an ASCONF.
>> 3. Suppose only A receives ASCONF-ACK, and B has not received one yet.
>> 4. In this moment, A can use the new address as the source address for regular chunk, but B can't.
>> 5. But I think both A and B use the new address even after only A receives ASCONF-ACK in current SCTP implementation,
>> This patch achieves that only A uses that new address in this moment.
>>
>> Am I missing something?
>>
>> Thanks,
>> - Michio
>>
>> On Apr 14, 2011, at 10:33 , Wei Yongjun wrote:
>>
>>>
>>>> When the SCTP association transmits an ASCONF with ADD_IP_ADDRESS, that association cannot use the adding address until it receives ASCONF-ACK.
>>>> This patch prevents that associations that do not receive ASCONF-ACK use the adding address.
>>> The new adding address is marked SCTP_ADDR_NEW, and cannot use
>>> in LKSCTP until received ASCONF-ACK and marked as SCTP_ADDR_SRC.
>>> So, add this valid address list is unnecessary.
>>>
>>> I guess you want to fix the route lookup issue?
>>>
>>> If it is, the only thing we need to fix is the lookup of route. If we can not
>>> found a valid dst for transport, we can try address marked with SCTP_ADDR_NEW.
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 3/3] sctp: Add a valid address list in association local
From: Wei Yongjun @ 2011-04-14 2:24 UTC (permalink / raw)
To: Michio Honda; +Cc: netdev, lksctp-developers
In-Reply-To: <EB560391-3EE8-43BB-83A4-DD55352CFEAF@sfc.wide.ad.jp>
> Hi,
>
> I implemented that functionality for following situations.
> 1. Suppose two associations A and B directed to different destination that belong to the same endpoint. (one-to-many socket).
Yes, but the addr list of assoc A and B is independent, see
asoc->base.bind_addr, which is per asoc.
endpoint hold the bind list for new create assoc. when assoc
is created, the bind list will be copy from ep, by
sctp_assoc_set_bind_addr_from_ep().
> 2. After the address addition event, A and B will send an ASCONF.
> 3. Suppose only A receives ASCONF-ACK, and B has not received one yet.
> 4. In this moment, A can use the new address as the source address for regular chunk, but B can't.
> 5. But I think both A and B use the new address even after only A receives ASCONF-ACK in current SCTP implementation,
> This patch achieves that only A uses that new address in this moment.
>
> Am I missing something?
>
> Thanks,
> - Michio
>
> On Apr 14, 2011, at 10:33 , Wei Yongjun wrote:
>
>>
>>> When the SCTP association transmits an ASCONF with ADD_IP_ADDRESS, that association cannot use the adding address until it receives ASCONF-ACK.
>>> This patch prevents that associations that do not receive ASCONF-ACK use the adding address.
>> The new adding address is marked SCTP_ADDR_NEW, and cannot use
>> in LKSCTP until received ASCONF-ACK and marked as SCTP_ADDR_SRC.
>> So, add this valid address list is unnecessary.
>>
>> I guess you want to fix the route lookup issue?
>>
>> If it is, the only thing we need to fix is the lookup of route. If we can not
>> found a valid dst for transport, we can try address marked with SCTP_ADDR_NEW.
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: Eric Dumazet @ 2011-04-14 2:17 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, bugzilla-daemon, bugme-daemon, kees
In-Reply-To: <20110413.120929.28806842.davem@davemloft.net>
Le mercredi 13 avril 2011 à 12:09 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 13 Apr 2011 05:00:08 +0200
>
> > Le mercredi 13 avril 2011 à 04:55 +0200, Eric Dumazet a écrit :
> >
> >> Since SO_REUSEPORT is not a 'stable fix', I suggest we revert the patch,
> >> and eventually work on SO_REUSEPORT on net-next-2.6
> >>
> >> What do you think ?
> >>
> >
> > Sorry, I should have mentioned commit id : c191a836a908d1dd6
> > (tcp: disallow bind() to reuse addr/port)
>
> I'm commiting the revert as follows to net-2.6, and will queue
> it up for -stable as well:
>
> --------------------
> Revert "tcp: disallow bind() to reuse addr/port"
>
> This reverts commit c191a836a908d1dd6b40c503741f91b914de3348.
>
> It causes known regressions for programs that expect to be able to use
> SO_REUSEADDR to shutdown a socket, then successfully rebind another
> socket to the same ID.
>
> Programs such as haproxy and amavisd expect this to work.
>
> This should fix kernel bugzilla 32832.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
Thanks David, I was planning to submit this revert this morning, you
beat me ;)
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 3/3] sctp: Add a valid address list in association local
From: Michio Honda @ 2011-04-14 2:01 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev, lksctp-developers
In-Reply-To: <4DA64EF0.30506@cn.fujitsu.com>
Hi,
I implemented that functionality for following situations.
1. Suppose two associations A and B directed to different destination that belong to the same endpoint. (one-to-many socket).
2. After the address addition event, A and B will send an ASCONF.
3. Suppose only A receives ASCONF-ACK, and B has not received one yet.
4. In this moment, A can use the new address as the source address for regular chunk, but B can't.
5. But I think both A and B use the new address even after only A receives ASCONF-ACK in current SCTP implementation,
This patch achieves that only A uses that new address in this moment.
Am I missing something?
Thanks,
- Michio
On Apr 14, 2011, at 10:33 , Wei Yongjun wrote:
>
>
>> When the SCTP association transmits an ASCONF with ADD_IP_ADDRESS, that association cannot use the adding address until it receives ASCONF-ACK.
>> This patch prevents that associations that do not receive ASCONF-ACK use the adding address.
>
> The new adding address is marked SCTP_ADDR_NEW, and cannot use
> in LKSCTP until received ASCONF-ACK and marked as SCTP_ADDR_SRC.
> So, add this valid address list is unnecessary.
>
> I guess you want to fix the route lookup issue?
>
> If it is, the only thing we need to fix is the lookup of route. If we can not
> found a valid dst for transport, we can try address marked with SCTP_ADDR_NEW.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: ipv4: add IPPROTO_ICMP socket kind
From: Simon Horman @ 2011-04-14 1:53 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Vasiliy Kulikov, linux-kernel, netdev, Pavel Kankovsky,
Solar Designer, Kees Cook, Dan Rosenberg, Eugene Teo,
Nelson Elhage, David S. Miller, Alexey Kuznetsov, Pekka Savola,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <BANLkTi=ogJg_uJqsJFpnwnnr6LS+SFT3Vg@mail.gmail.com>
On Wed, Apr 13, 2011 at 01:29:49PM +0300, Alexey Dobriyan wrote:
> On Sat, Apr 9, 2011 at 1:15 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
[snip]
> > @@ -714,8 +790,22 @@ static __net_init int ipv4_sysctl_init_net(struct net *net)
> > &net->ipv4.sysctl_icmp_ratemask;
> > table[6].data =
> > &net->ipv4.sysctl_rt_cache_rebuild_count;
> > +#ifdef CONFIG_IP_PING
> > + table[7].data =
> > + &net->ipv4.sysctl_ping_group_range;
> > +#endif
>
> Now I understand it's not related, but next sysctl will have
> "table[8].data = ..." line which is off-by-one if CONFIG_IP_PING=n.
Another good reason for the code to be non-optoinal
and not to have CONFIG_IP_PING.
^ permalink raw reply
* [PATCH] Clean up 'FLAG_POINTTOPOINT' and 'FLAG_MULTI_PACKET' overlaps in usbnet.h
From: huajun li @ 2011-04-14 1:43 UTC (permalink / raw)
To: David Miller; +Cc: Gottfried Haider, netdev
USB tethering does not work anymore since 2.6.39-rc2, but it's okay in
-rc1. The root cause is the new added mask code 'FLAG_POINTTOPOINT'
overlaps 'FLAG_MULTI_PACKET' in include/linux/usb/usbnet.h, this
causes logic issue in rx_process(). This patch cleans up the overlap.
Reported-and-Tested-by: Gottfried Haider <gottfried.haider@gmail.com>
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
---
include/linux/usb/usbnet.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 3c7329b..0e18550 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -103,8 +103,8 @@ struct driver_info {
* Indicates to usbnet, that USB driver accumulates multiple IP packets.
* Affects statistic (counters) and short packet handling.
*/
-#define FLAG_MULTI_PACKET 0x1000
-#define FLAG_RX_ASSEMBLE 0x2000 /* rx packets may span >1 frames */
+#define FLAG_MULTI_PACKET 0x2000
+#define FLAG_RX_ASSEMBLE 0x4000 /* rx packets may span >1 frames */
/* init device ... can sleep, or cause probe() failure */
int (*bind)(struct usbnet *, struct usb_interface *);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2 3/3] sctp: Add a valid address list in association local
From: Wei Yongjun @ 2011-04-14 1:33 UTC (permalink / raw)
To: Michio Honda; +Cc: netdev, lksctp-developers
In-Reply-To: <115A4380-6E63-4014-BD24-04A29472ACCD@sfc.wide.ad.jp>
> When the SCTP association transmits an ASCONF with ADD_IP_ADDRESS, that association cannot use the adding address until it receives ASCONF-ACK.
> This patch prevents that associations that do not receive ASCONF-ACK use the adding address.
The new adding address is marked SCTP_ADDR_NEW, and cannot use
in LKSCTP until received ASCONF-ACK and marked as SCTP_ADDR_SRC.
So, add this valid address list is unnecessary.
I guess you want to fix the route lookup issue?
If it is, the only thing we need to fix is the lookup of route. If we can not
found a valid dst for transport, we can try address marked with SCTP_ADDR_NEW.
^ permalink raw reply
* [PATCH 3/3] net-bonding: Adding support for throughputs larger than 65536 Mbps
From: David Decotigny @ 2011-04-14 1:22 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, netdev, linux-kernel; +Cc: David Decotigny
In-Reply-To: <1302744151-12452-1-git-send-email-decot@google.com>
This updates the bonding driver to support v2.6.27-rc3 enhancements
(b11f8d8c aka. "ethtool: Expand ethtool_cmd.speed to 32 bits") which
allow to encode the Mbps link speed on 32-bits (Max 4 Pbps) instead of
16 (Max 65536 Mbps).
This patch also attempts to compact struct slave by reordering its
fields.
Signed-off-by: David Decotigny <decot@google.com>
---
drivers/net/bonding/bond_main.c | 12 +++++++-----
drivers/net/bonding/bonding.h | 6 +++---
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 145f9be..c5d8ac2 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -631,7 +631,8 @@ down:
static int bond_update_speed_duplex(struct slave *slave)
{
struct net_device *slave_dev = slave->dev;
- struct ethtool_cmd etool;
+ struct ethtool_cmd etool = { .cmd = ETHTOOL_GSET };
+ u32 slave_speed;
int res;
/* Fake speed and duplex */
@@ -645,7 +646,8 @@ static int bond_update_speed_duplex(struct slave *slave)
if (res < 0)
return -1;
- switch (etool.speed) {
+ slave_speed = ethtool_cmd_speed(&etool);
+ switch (slave_speed) {
case SPEED_10:
case SPEED_100:
case SPEED_1000:
@@ -663,7 +665,7 @@ static int bond_update_speed_duplex(struct slave *slave)
return -1;
}
- slave->speed = etool.speed;
+ slave->speed = slave_speed;
slave->duplex = etool.duplex;
return 0;
@@ -2493,7 +2495,7 @@ static void bond_miimon_commit(struct bonding *bond)
bond_update_speed_duplex(slave);
- pr_info("%s: link status definitely up for interface %s, %d Mbps %s duplex.\n",
+ pr_info("%s: link status definitely up for interface %s, %u Mbps %s duplex.\n",
bond->dev->name, slave->dev->name,
slave->speed, slave->duplex ? "full" : "half");
@@ -3339,7 +3341,7 @@ static int bond_slave_netdev_event(unsigned long event,
slave = bond_get_slave_by_dev(bond, slave_dev);
if (slave) {
- u16 old_speed = slave->speed;
+ u32 old_speed = slave->speed;
u8 old_duplex = slave->duplex;
bond_update_speed_duplex(slave);
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 3ca503e..553c764 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -196,12 +196,12 @@ struct slave {
u8 backup:1, /* indicates backup slave. Value corresponds with
BOND_STATE_ACTIVE and BOND_STATE_BACKUP */
inactive:1; /* indicates inactive slave */
+ u8 duplex;
u32 original_mtu;
u32 link_failure_count;
- u8 perm_hwaddr[ETH_ALEN];
- u16 speed;
- u8 duplex;
+ u32 speed;
u16 queue_id;
+ u8 perm_hwaddr[ETH_ALEN];
struct ad_slave_info ad_info; /* HUGE - better to dynamically alloc */
struct tlb_slave_info tlb_info;
#ifdef CONFIG_NET_POLL_CONTROLLER
--
1.7.3.1
^ permalink raw reply related
* [PATCH 2/3] net-bonding: Fix minor/cosmetic type inconsistencies
From: David Decotigny @ 2011-04-14 1:22 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, netdev, linux-kernel; +Cc: David Decotigny
In-Reply-To: <1302744151-12452-1-git-send-email-decot@google.com>
The __get_link_speed() function returns a u16 value which was stored
in a u32 local variable. This patch uses the return value directly,
thus fixing that minor type consistency.
The 'duplex' field in struct slave being encoded on 8 bits, to be more
consistent we use a u8 integer (instead of u16) whenever we copy it to
local variables.
Signed-off-by: David Decotigny <decot@google.com>
---
drivers/net/bonding/bond_3ad.c | 4 +---
drivers/net/bonding/bond_main.c | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 494bf96..123dd60 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -716,11 +716,9 @@ static void __set_agg_ports_ready(struct aggregator *aggregator, int val)
static u32 __get_agg_bandwidth(struct aggregator *aggregator)
{
u32 bandwidth = 0;
- u32 basic_speed;
if (aggregator->num_of_ports) {
- basic_speed = __get_link_speed(aggregator->lag_ports);
- switch (basic_speed) {
+ switch (__get_link_speed(aggregator->lag_ports)) {
case AD_LINK_SPEED_BITMASK_1MBPS:
bandwidth = aggregator->num_of_ports;
break;
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 8264ed7..145f9be 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3340,7 +3340,7 @@ static int bond_slave_netdev_event(unsigned long event,
slave = bond_get_slave_by_dev(bond, slave_dev);
if (slave) {
u16 old_speed = slave->speed;
- u16 old_duplex = slave->duplex;
+ u8 old_duplex = slave->duplex;
bond_update_speed_duplex(slave);
--
1.7.3.1
^ 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