* Re: iproute2 issue with adding rules.
From: Stephen Hemminger @ 2010-05-17 20:27 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4BF1A352.5020500@candelatech.com>
On Mon, 17 May 2010 13:13:06 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 05/17/2010 12:03 PM, Ben Greear wrote:
> > On older releases, you can do this with iproute:
> >
> > # ip ru add from 9.9.9.2/32 table 226 pref 400
> > #
> >
> > But, in latest git, it returns an error:
> > # ip ru add from 9.9.9.2/32 table 226 pref 400
> > Error: an inet prefix is expected rather than "9.9.9.2/32".
> >
> > Is that on purpose?
>
> I was thinking maybe this was a library issue, since I compiled
> on one machine and ran the 'ip' exe on another. So, I tried compiling
> on the test system.
>
> But, iproute will not compile, apparently because it finds the
> /usr/include/linux header files before whatever is packaged with
> iproute:
>
> gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib/\" -c -o ipaddress.o ipaddress.c
> ipaddress.c: In function ‘print_linkinfo’:
> ipaddress.c:334: error: ‘IFLA_VFINFO’ undeclared (first use in this function)
> ipaddress.c:334: error: (Each undeclared identifier is reported only once
> ipaddress.c:334: error: for each function it appears in.)
> make[1]: *** [ipaddress.o] Error 1
> make[1]: Leaving directory `/root/git/iproute2/ip'
> make: *** [all] Error 2
>
>
> I tried moving /usr/include/linux out of the way, but then it blows up
> even worse (can't find errno.h, etc)
>
> Are we supposed to be able to compile iproute2 on a system with moderately
> outdated kernel headers?
>
> If not, why bother with the iproute/include/linux directory at all?
The issue is the last minute VF changes in 2.6.34 are not supported
in iproute util yet. Please wait until it is fixed.
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 20:28 UTC (permalink / raw)
To: NetDev
In-Reply-To: <4BF1A352.5020500@candelatech.com>
On 05/17/2010 01:13 PM, Ben Greear wrote:
> On 05/17/2010 12:03 PM, Ben Greear wrote:
>> On older releases, you can do this with iproute:
>>
>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>> #
>>
>> But, in latest git, it returns an error:
>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>> Error: an inet prefix is expected rather than "9.9.9.2/32".
>>
>> Is that on purpose?
>
> I was thinking maybe this was a library issue, since I compiled
> on one machine and ran the 'ip' exe on another. So, I tried compiling
> on the test system.
I'm not thinking too well today, but this patch fixes the compile.
No idea if it's actually correct code.
Still can't add the rule like I was trying...but at least it's probably
not an issue with libraries:
[root@ct503-10G-09 iproute2]# git diff
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 48f7b1e..4d4481a 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -331,13 +331,13 @@ int print_linkinfo(const struct sockaddr_nl *who,
);
}
}
- if (do_link && tb[IFLA_VFINFO] && tb[IFLA_NUM_VF]) {
+ if (do_link && tb[IFLA_VFINFO_LIST] && tb[IFLA_NUM_VF]) {
SPRINT_BUF(b1);
- struct rtattr *rta = tb[IFLA_VFINFO];
+ struct rtattr *rta = tb[IFLA_VFINFO_LIST];
struct ifla_vf_info *ivi;
int i;
for (i = 0; i < *(int *)RTA_DATA(tb[IFLA_NUM_VF]); i++) {
- if (rta->rta_type != IFLA_VFINFO) {
+ if (rta->rta_type != IFLA_VFINFO_LIST) {
fprintf(stderr, "BUG: rta type is %d\n", rta->rta_type);
break;
}
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply related
* Re: iproute2 issue with adding rules.
From: Chris Wright @ 2010-05-17 20:30 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4BF1A6D1.70507@candelatech.com>
* Ben Greear (greearb@candelatech.com) wrote:
> On 05/17/2010 01:13 PM, Ben Greear wrote:
> >On 05/17/2010 12:03 PM, Ben Greear wrote:
> >>On older releases, you can do this with iproute:
> >>
> >># ip ru add from 9.9.9.2/32 table 226 pref 400
> >>#
> >>
> >>But, in latest git, it returns an error:
> >># ip ru add from 9.9.9.2/32 table 226 pref 400
> >>Error: an inet prefix is expected rather than "9.9.9.2/32".
> >>
> >>Is that on purpose?
> >
> >I was thinking maybe this was a library issue, since I compiled
> >on one machine and ran the 'ip' exe on another. So, I tried compiling
> >on the test system.
>
> I'm not thinking too well today, but this patch fixes the compile.
> No idea if it's actually correct code.
Needs more changes than that patch.
thanks,
-chris
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 20:34 UTC (permalink / raw)
To: Chris Wright; +Cc: NetDev
In-Reply-To: <20100517203004.GD8301@sequoia.sous-sol.org>
On 05/17/2010 01:30 PM, Chris Wright wrote:
> * Ben Greear (greearb@candelatech.com) wrote:
>> On 05/17/2010 01:13 PM, Ben Greear wrote:
>>> On 05/17/2010 12:03 PM, Ben Greear wrote:
>>>> On older releases, you can do this with iproute:
>>>>
>>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>>>> #
>>>>
>>>> But, in latest git, it returns an error:
>>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>>>> Error: an inet prefix is expected rather than "9.9.9.2/32".
>>>>
>>>> Is that on purpose?
>>>
>>> I was thinking maybe this was a library issue, since I compiled
>>> on one machine and ran the 'ip' exe on another. So, I tried compiling
>>> on the test system.
>>
>> I'm not thinking too well today, but this patch fixes the compile.
>> No idea if it's actually correct code.
>
> Needs more changes than that patch.
Ok, I'll try going back a few commits to find something that compiles
w/out my hacks.
Also, the rule addition does work..make install put ip in
a different place than it's installed in fedora, so I wasn't
actually running the latest code when I first tried to add
the rule.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Stephen Hemminger @ 2010-05-17 20:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <1274072629.2299.58.camel@edumazet-laptop>
On Mon, 17 May 2010 07:03:49 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 17 mai 2010 à 03:49 +0000, Bijay Singh a écrit :
>
> > I am on quite an old kernel 2.6.27 and could not apply your patches.
> >
> > Then i moved on to the kernel 2.6.32.11 however since then I have not been able to bring up my card, this is something i need to fix before i can test you fix. Working on that.
> >
>
> Thanks again for the status report.
>
> I see bug is older than what I stated in my previous mail
>
> I could reproduce it in my lab and confirm following patch fixes it
>
> This is a stable candidate (2.6.27 kernels)
>
> Thanks
>
> [PATCH] tcp: tcp_synack_options() fix
>
> Commit 33ad798c924b4a (tcp: options clean up) introduced a problem
> if MD5+SACK+timestamps were used in initial SYN message.
>
> Some stacks (old linux for example) try to negotiate MD5+SACK+TSTAMP
> sessions, but since 20 bytes of tcp options space are not enough to
> store all the bits needed, we chose to disable timestamps in this case.
>
> We send a SYN-ACK _without_ timestamp option, but socket has timestamps
> enabled and all further outgoing messages contain a TS block, all with
> the initial timestamp of the remote peer.
>
> Fix is to really disable timestamps option for the whole session.
>
> Reported-by: Bijay Singh <Bijay.Singh@guavus.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/tcp_output.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 0dda86e..b8bb226 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -667,7 +667,7 @@ static unsigned tcp_synack_options(struct sock *sk,
> u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
> xvp->cookie_plus :
> 0;
> - bool doing_ts = ireq->tstamp_ok;
> + bool doing_ts;
>
> #ifdef CONFIG_TCP_MD5SIG
> *md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
> @@ -680,11 +680,12 @@ static unsigned tcp_synack_options(struct sock *sk,
> * rather than TS in order to fit in better with old,
> * buggy kernels, but that was deemed to be unnecessary.
> */
> - doing_ts &= !ireq->sack_ok;
> + ireq->tstamp_ok &= !ireq->sack_ok;
> }
> #else
> *md5 = NULL;
> #endif
> + doing_ts = ireq->tstamp_ok;
>
> /* We always send an MSS option. */
> opts->mss = mss;
>
>
Since you are doing away with flag variable, why not this instead?
--- a/net/ipv4/tcp_output.c 2010-05-17 13:38:32.822025583 -0700
+++ b/net/ipv4/tcp_output.c 2010-05-17 13:41:47.321734775 -0700
@@ -668,7 +668,6 @@ static unsigned tcp_synack_options(struc
u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
xvp->cookie_plus :
0;
- bool doing_ts = ireq->tstamp_ok;
#ifdef CONFIG_TCP_MD5SIG
*md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
@@ -681,7 +680,7 @@ static unsigned tcp_synack_options(struc
* rather than TS in order to fit in better with old,
* buggy kernels, but that was deemed to be unnecessary.
*/
- doing_ts &= !ireq->sack_ok;
+ ireq->tstamp_ok &= !ireq->sack_ok;
}
#else
*md5 = NULL;
@@ -696,7 +695,7 @@ static unsigned tcp_synack_options(struc
opts->options |= OPTION_WSCALE;
remaining -= TCPOLEN_WSCALE_ALIGNED;
}
- if (likely(doing_ts)) {
+ if (likely(ireq->tstamp_ok)) {
opts->options |= OPTION_TS;
opts->tsval = TCP_SKB_CB(skb)->when;
opts->tsecr = req->ts_recent;
@@ -704,7 +703,7 @@ static unsigned tcp_synack_options(struc
}
if (likely(ireq->sack_ok)) {
opts->options |= OPTION_SACK_ADVERTISE;
- if (unlikely(!doing_ts))
+ if (unlikely(!ireq->tstamp_ok))
remaining -= TCPOLEN_SACKPERM_ALIGNED;
}
@@ -712,7 +711,7 @@ static unsigned tcp_synack_options(struc
* If the <SYN> options fit, the same options should fit now!
*/
if (*md5 == NULL &&
- doing_ts &&
+ ireq->tstamp_ok &&
cookie_plus > TCPOLEN_COOKIE_BASE) {
int need = cookie_plus; /* has TCPOLEN_COOKIE_BASE */
--
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Eric W. Biederman @ 2010-05-17 20:58 UTC (permalink / raw)
To: Greg KH
Cc: David Miller, gregkh, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517181133.GB18721@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
>> From: Greg KH <greg@kroah.com>
>> Date: Thu, 6 May 2010 13:04:04 -0700
>>
>> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
>> >>
>> >> With the tagged sysfs support finally merged into Greg's tree,
>> >> it is time for the last little bits of work to get the kobject
>> >> layer and network namespaces to play together properly.
>> >>
>> >> These patches are roughly evenly divided between network layer work
>> >> and sysfs layer work. Last time this conundrum came up I believe
>> >> we decided that the easiest way to handle this was for Greg to carry
>> >> all of the patches. David, Greg does that still make sense?
>> >
>> > That's fine, if I get David's ack on these.
>>
>> Looks good to me:
>>
>> Acked-by: David S. Miller <davem@davemloft.net>
>
> Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> them up then to get some testing in linux-next so that they can make it
> into .36?
Grumble. Grumble. Grumble.
If I must I will resend these, but these patches are already in
production use, and I had them to you weeks before the merge window
closed.
Is there no way we can get these in for 2.6.35?
Eric
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Greg KH @ 2010-05-17 21:03 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <m1zkzyfdob.fsf@fess.ebiederm.org>
On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
> Greg KH <greg@kroah.com> writes:
>
> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
> >> From: Greg KH <greg@kroah.com>
> >> Date: Thu, 6 May 2010 13:04:04 -0700
> >>
> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
> >> >>
> >> >> With the tagged sysfs support finally merged into Greg's tree,
> >> >> it is time for the last little bits of work to get the kobject
> >> >> layer and network namespaces to play together properly.
> >> >>
> >> >> These patches are roughly evenly divided between network layer work
> >> >> and sysfs layer work. Last time this conundrum came up I believe
> >> >> we decided that the easiest way to handle this was for Greg to carry
> >> >> all of the patches. David, Greg does that still make sense?
> >> >
> >> > That's fine, if I get David's ack on these.
> >>
> >> Looks good to me:
> >>
> >> Acked-by: David S. Miller <davem@davemloft.net>
> >
> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> > them up then to get some testing in linux-next so that they can make it
> > into .36?
>
> Grumble. Grumble. Grumble.
>
> If I must I will resend these, but these patches are already in
> production use, and I had them to you weeks before the merge window
> closed.
Yes, but they were not reviewed by the network maintainer until after
the merge window closed. I already have your sysfs-namespace patches
queued up for .35, and that's a big enough change for me to feel
comfortable with at the moment.
> Is there no way we can get these in for 2.6.35?
No, sorry. One thing at a time please.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] tcp: tcp_synack_options() fix
From: Eric Dumazet @ 2010-05-17 21:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <20100517134240.1949f245@nehalam>
Le lundi 17 mai 2010 à 13:42 -0700, Stephen Hemminger a écrit :
> Since you are doing away with flag variable, why not this instead?
>
Sure, we can eliminate this doing_ts variable and save few bytes
Thanks
[PATCH] tcp: tcp_synack_options() fix
Commit 33ad798c924b4a (tcp: options clean up) introduced a problem
if MD5+SACK+timestamps were used in initial SYN message.
Some stacks (old linux for example) try to negotiate MD5+SACK+TSTAMP
sessions, but since 40 bytes of tcp options space are not enough to
store all the bits needed, we chose to disable timestamps in this case.
We send a SYN-ACK _without_ timestamp option, but socket has timestamps
enabled and all further outgoing messages contain a TS block, all with
the initial timestamp of the remote peer.
Fix is to really disable timestamps option for the whole session.
Reported-by: Bijay Singh <Bijay.Singh@guavus.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 0dda86e..44e98d9 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -667,7 +667,6 @@ static unsigned tcp_synack_options(struct sock *sk,
u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
xvp->cookie_plus :
0;
- bool doing_ts = ireq->tstamp_ok;
#ifdef CONFIG_TCP_MD5SIG
*md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
@@ -680,7 +679,7 @@ static unsigned tcp_synack_options(struct sock *sk,
* rather than TS in order to fit in better with old,
* buggy kernels, but that was deemed to be unnecessary.
*/
- doing_ts &= !ireq->sack_ok;
+ ireq->tstamp_ok &= !ireq->sack_ok;
}
#else
*md5 = NULL;
@@ -695,7 +694,7 @@ static unsigned tcp_synack_options(struct sock *sk,
opts->options |= OPTION_WSCALE;
remaining -= TCPOLEN_WSCALE_ALIGNED;
}
- if (likely(doing_ts)) {
+ if (likely(ireq->tstamp_ok)) {
opts->options |= OPTION_TS;
opts->tsval = TCP_SKB_CB(skb)->when;
opts->tsecr = req->ts_recent;
@@ -703,7 +702,7 @@ static unsigned tcp_synack_options(struct sock *sk,
}
if (likely(ireq->sack_ok)) {
opts->options |= OPTION_SACK_ADVERTISE;
- if (unlikely(!doing_ts))
+ if (unlikely(!ireq->tstamp_ok))
remaining -= TCPOLEN_SACKPERM_ALIGNED;
}
@@ -711,7 +710,7 @@ static unsigned tcp_synack_options(struct sock *sk,
* If the <SYN> options fit, the same options should fit now!
*/
if (*md5 == NULL &&
- doing_ts &&
+ ireq->tstamp_ok &&
cookie_plus > TCPOLEN_COOKIE_BASE) {
int need = cookie_plus; /* has TCPOLEN_COOKIE_BASE */
^ permalink raw reply related
* [PATCH] [resend] fix non-mergeable buffers packet too large error handling
From: David L Stevens @ 2010-05-17 21:16 UTC (permalink / raw)
To: mst; +Cc: netdev, kvm, virtualization
This patch enforces single-buffer allocation when
mergeable rx buffers is not enabled.
Reported-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 309c570..c346304 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -361,13 +361,21 @@ static void handle_rx(struct vhost_net *net)
break;
}
/* TODO: Should check and handle checksum. */
- if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF) &&
- memcpy_toiovecend(vq->hdr, (unsigned char *)&headcount,
- offsetof(typeof(hdr), num_buffers),
- sizeof hdr.num_buffers)) {
- vq_err(vq, "Failed num_buffers write");
+ if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF)) {
+ if (memcpy_toiovecend(vq->hdr,
+ (unsigned char *)&headcount,
+ offsetof(typeof(hdr),
+ num_buffers),
+ sizeof hdr.num_buffers)) {
+ vq_err(vq, "Failed num_buffers write");
+ vhost_discard_desc(vq, headcount);
+ break;
+ }
+ } else if (headcount > 1) {
+ vq_err(vq, "rx packet too large (%d) for guest",
+ sock_len);
vhost_discard_desc(vq, headcount);
- break;
+ continue;
}
vhost_add_used_and_signal_n(&net->dev, vq, vq->heads,
headcount);
^ permalink raw reply related
* Re: iproute2 issue with adding rules.
From: Stephen Hemminger @ 2010-05-17 21:41 UTC (permalink / raw)
To: Ben Greear; +Cc: Chris Wright, NetDev
In-Reply-To: <4BF1A855.3090905@candelatech.com>
On Mon, 17 May 2010 13:34:29 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 05/17/2010 01:30 PM, Chris Wright wrote:
> > * Ben Greear (greearb@candelatech.com) wrote:
> >> On 05/17/2010 01:13 PM, Ben Greear wrote:
> >>> On 05/17/2010 12:03 PM, Ben Greear wrote:
> >>>> On older releases, you can do this with iproute:
> >>>>
> >>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
> >>>> #
> >>>>
> >>>> But, in latest git, it returns an error:
> >>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
> >>>> Error: an inet prefix is expected rather than "9.9.9.2/32".
> >>>>
> >>>> Is that on purpose?
> >>>
> >>> I was thinking maybe this was a library issue, since I compiled
> >>> on one machine and ran the 'ip' exe on another. So, I tried compiling
> >>> on the test system.
> >>
> >> I'm not thinking too well today, but this patch fixes the compile.
> >> No idea if it's actually correct code.
> >
> > Needs more changes than that patch.
>
> Ok, I'll try going back a few commits to find something that compiles
> w/out my hacks.
>
> Also, the rule addition does work..make install put ip in
> a different place than it's installed in fedora, so I wasn't
> actually running the latest code when I first tried to add
> the rule.
Distributions never seem to agree where it should be: /sbin or /usr/sbin
or even /bin
^ permalink raw reply
* Re: [patch] pm_qos update fixing mmotm 2010-05-11 -dies in pm_qos_update_request()
From: Rafael J. Wysocki @ 2010-05-17 21:58 UTC (permalink / raw)
To: markgross
Cc: mgross, Valdis.Kletnieks, e1000-devel, netdev, linux-kernel,
linux-pm, akpm, davem
In-Reply-To: <20100517001241.GA2962@thegnar.org>
On Monday 17 May 2010, mgross wrote:
> On Mon, May 17, 2010 at 12:21:25AM +0200, Rafael J. Wysocki wrote:
> > On Saturday 15 May 2010, mgross wrote:
> > > On Sat, May 15, 2010 at 09:38:47PM +0200, Rafael J. Wysocki wrote:
> > > > On Saturday 15 May 2010, mgross wrote:
> > > > > I apologize for the goofy email address.
> > > > >
> > > > > The following is a fix for the crash reported by Valdis.
> > > > >
> > > > > The problem was that the original pm_qos silently fails when a request
> > > > > update is passed to a parameter that has not been added to the list
> > > > > yet. It seems that the e1000e is doing this. This update restores this
> > > > > behavior.
> > > > >
> > > > > I need to think about how to better handle such abuse, but for now this
> > > > > restores the original behavior.
> > > >
> > > > Can you please post a signed-off incremental patch against
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6.git for-llinus
> > > >
> > > > that contains your original PM QOS update?
> > >
> > > No problem:
> > >
> > > Signed-off-by: markgross <markgross@thegnar.org>
> >
> > Thanks! Do you want to use this address for the sign-off or the Intel one?
>
> I guess so. Ever since switching groups within intel last summer my
> mgross@linux.intel.com address isn't checked as often as this one.
>
> The other option is to use my outlook email (mark.gross@intel.com), but
> I really hate posting from outlook. Besides, doing upstream kernel
> stuff isn't my day job any more so using markgross@thegnar.org makes
> sense to me.
Good. Patch applied to suspend-2.6/for-linus.
Thanks,
Rafael
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Eric W. Biederman @ 2010-05-17 22:37 UTC (permalink / raw)
To: Greg KH
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517210318.GA6170@suse.de>
Greg KH <gregkh@suse.de> writes:
> On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
>> Greg KH <greg@kroah.com> writes:
>>
>> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
>> >> From: Greg KH <greg@kroah.com>
>> >> Date: Thu, 6 May 2010 13:04:04 -0700
>> >>
>> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
>> >> >>
>> >> >> With the tagged sysfs support finally merged into Greg's tree,
>> >> >> it is time for the last little bits of work to get the kobject
>> >> >> layer and network namespaces to play together properly.
>> >> >>
>> >> >> These patches are roughly evenly divided between network layer work
>> >> >> and sysfs layer work. Last time this conundrum came up I believe
>> >> >> we decided that the easiest way to handle this was for Greg to carry
>> >> >> all of the patches. David, Greg does that still make sense?
>> >> >
>> >> > That's fine, if I get David's ack on these.
>> >>
>> >> Looks good to me:
>> >>
>> >> Acked-by: David S. Miller <davem@davemloft.net>
>> >
>> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
>> > them up then to get some testing in linux-next so that they can make it
>> > into .36?
>>
>> Grumble. Grumble. Grumble.
>>
>> If I must I will resend these, but these patches are already in
>> production use, and I had them to you weeks before the merge window
>> closed.
>
> Yes, but they were not reviewed by the network maintainer until after
> the merge window closed.
Strictly speaking the day before but I get your point.
> I already have your sysfs-namespace patches
> queued up for .35, and that's a big enough change for me to feel
> comfortable with at the moment.
>
>> Is there no way we can get these in for 2.6.35?
>
> No, sorry. One thing at a time please.
Sure.
If we are going to push this last bit off until the 2.6.36 time frame
Dave, Greg mind if I flip around who I send these patches to?
The big dependency is the sysfs-namespace patches which will be in
2.6.35, and if the patches get into net-next as well as linux-next
there will be a larger number of potential testers.
Eric
^ permalink raw reply
* [PATCH] net: Introduce skb_tunnel_rx() helper
From: Eric Dumazet @ 2010-05-17 22:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
skb rxhash should be cleared when a skb is handled by a tunnel before
being delivered again, so that correct packet steering can take place.
There are other cleanups and accounting that we can factorize in a new
helper, skb_tunnel_rx()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/dst.h | 20 ++++++++++++++++++++
net/ipv4/ip_gre.c | 9 +--------
net/ipv4/ipip.c | 7 ++-----
net/ipv4/ipmr.c | 8 +++-----
net/ipv6/ip6_tunnel.c | 8 ++------
net/ipv6/ip6mr.c | 8 +++-----
net/ipv6/sit.c | 8 +++-----
7 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index aac5a5f..d708c22 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -184,6 +184,26 @@ static inline void skb_dst_drop(struct sk_buff *skb)
skb->_skb_dst = 0UL;
}
+
+/**
+ * skb_tunnel_rx - prepare skb for rx reinsert
+ * @skb: buffer
+ * @dev: tunnel device
+ *
+ * After decapsulation, packet is going to re-enter (netif_rx()) our stack,
+ * so make some cleanups, and perform accounting.
+ */
+static inline void skb_tunnel_rx(struct sk_buff *skb, struct net_device *dev)
+{
+ skb->dev = dev;
+ /* TODO : stats should be SMP safe */
+ dev->stats.rx_packets++;
+ dev->stats.rx_bytes += skb->len;
+ skb->rxhash = 0;
+ skb_dst_drop(skb);
+ nf_reset(skb);
+}
+
/* Children define the path of the packet through the
* Linux networking. Thus, destinations are stackable.
*/
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index fe381d1..498cf69 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -538,7 +538,6 @@ static int ipgre_rcv(struct sk_buff *skb)
struct ip_tunnel *tunnel;
int offset = 4;
__be16 gre_proto;
- unsigned int len;
if (!pskb_may_pull(skb, 16))
goto drop_nolock;
@@ -629,8 +628,6 @@ static int ipgre_rcv(struct sk_buff *skb)
tunnel->i_seqno = seqno + 1;
}
- len = skb->len;
-
/* Warning: All skb pointers will be invalidated! */
if (tunnel->dev->type == ARPHRD_ETHER) {
if (!pskb_may_pull(skb, ETH_HLEN)) {
@@ -644,11 +641,7 @@ static int ipgre_rcv(struct sk_buff *skb)
skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
}
- stats->rx_packets++;
- stats->rx_bytes += len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+ skb_tunnel_rx(skb, tunnel->dev);
skb_reset_network_header(skb);
ipgre_ecn_decapsulate(iph, skb);
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 0b27b14..7fd6367 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -374,11 +374,8 @@ static int ipip_rcv(struct sk_buff *skb)
skb->protocol = htons(ETH_P_IP);
skb->pkt_type = PACKET_HOST;
- tunnel->dev->stats.rx_packets++;
- tunnel->dev->stats.rx_bytes += skb->len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+ skb_tunnel_rx(skb, tunnel->dev);
+
ipip_ecn_decapsulate(iph, skb);
netif_rx(skb);
rcu_read_unlock();
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 7a7ee1c..217ebe0 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1831,14 +1831,12 @@ static int __pim_rcv(struct mr_table *mrt, struct sk_buff *skb,
skb->mac_header = skb->network_header;
skb_pull(skb, (u8*)encap - skb->data);
skb_reset_network_header(skb);
- skb->dev = reg_dev;
skb->protocol = htons(ETH_P_IP);
skb->ip_summed = 0;
skb->pkt_type = PACKET_HOST;
- skb_dst_drop(skb);
- reg_dev->stats.rx_bytes += skb->len;
- reg_dev->stats.rx_packets++;
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, reg_dev);
+
netif_rx(skb);
dev_put(reg_dev);
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 2599870..8f39893 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -723,14 +723,10 @@ static int ip6_tnl_rcv(struct sk_buff *skb, __u16 protocol,
skb->protocol = htons(protocol);
skb->pkt_type = PACKET_HOST;
memset(skb->cb, 0, sizeof(struct inet6_skb_parm));
- skb->dev = t->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
- dscp_ecn_decapsulate(t, ipv6h, skb);
+ skb_tunnel_rx(skb, t->dev);
- t->dev->stats.rx_packets++;
- t->dev->stats.rx_bytes += skb->len;
+ dscp_ecn_decapsulate(t, ipv6h, skb);
netif_rx(skb);
rcu_read_unlock();
return 0;
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 163850e..bd9e7d3 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -658,14 +658,12 @@ static int pim6_rcv(struct sk_buff *skb)
skb->mac_header = skb->network_header;
skb_pull(skb, (u8 *)encap - skb->data);
skb_reset_network_header(skb);
- skb->dev = reg_dev;
skb->protocol = htons(ETH_P_IPV6);
skb->ip_summed = 0;
skb->pkt_type = PACKET_HOST;
- skb_dst_drop(skb);
- reg_dev->stats.rx_bytes += skb->len;
- reg_dev->stats.rx_packets++;
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, reg_dev);
+
netif_rx(skb);
dev_put(reg_dev);
return 0;
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 5abae10..e51e650 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -566,11 +566,9 @@ static int ipip6_rcv(struct sk_buff *skb)
kfree_skb(skb);
return 0;
}
- tunnel->dev->stats.rx_packets++;
- tunnel->dev->stats.rx_bytes += skb->len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, tunnel->dev);
+
ipip6_ecn_decapsulate(iph, skb);
netif_rx(skb);
rcu_read_unlock();
^ permalink raw reply related
* Re: [PATCH 0/6] netns support in the kobject layer
From: Greg KH @ 2010-05-17 22:54 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <m1hbm6f93x.fsf@fess.ebiederm.org>
On Mon, May 17, 2010 at 03:37:22PM -0700, Eric W. Biederman wrote:
> Greg KH <gregkh@suse.de> writes:
>
> > On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
> >> Greg KH <greg@kroah.com> writes:
> >>
> >> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
> >> >> From: Greg KH <greg@kroah.com>
> >> >> Date: Thu, 6 May 2010 13:04:04 -0700
> >> >>
> >> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
> >> >> >>
> >> >> >> With the tagged sysfs support finally merged into Greg's tree,
> >> >> >> it is time for the last little bits of work to get the kobject
> >> >> >> layer and network namespaces to play together properly.
> >> >> >>
> >> >> >> These patches are roughly evenly divided between network layer work
> >> >> >> and sysfs layer work. Last time this conundrum came up I believe
> >> >> >> we decided that the easiest way to handle this was for Greg to carry
> >> >> >> all of the patches. David, Greg does that still make sense?
> >> >> >
> >> >> > That's fine, if I get David's ack on these.
> >> >>
> >> >> Looks good to me:
> >> >>
> >> >> Acked-by: David S. Miller <davem@davemloft.net>
> >> >
> >> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> >> > them up then to get some testing in linux-next so that they can make it
> >> > into .36?
> >>
> >> Grumble. Grumble. Grumble.
> >>
> >> If I must I will resend these, but these patches are already in
> >> production use, and I had them to you weeks before the merge window
> >> closed.
> >
> > Yes, but they were not reviewed by the network maintainer until after
> > the merge window closed.
>
> Strictly speaking the day before but I get your point.
>
> > I already have your sysfs-namespace patches
> > queued up for .35, and that's a big enough change for me to feel
> > comfortable with at the moment.
> >
> >> Is there no way we can get these in for 2.6.35?
> >
> > No, sorry. One thing at a time please.
>
> Sure.
>
> If we are going to push this last bit off until the 2.6.36 time frame
> Dave, Greg mind if I flip around who I send these patches to?
>
> The big dependency is the sysfs-namespace patches which will be in
> 2.6.35, and if the patches get into net-next as well as linux-next
> there will be a larger number of potential testers.
Sure, that's fine with me.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: David Miller @ 2010-05-17 23:48 UTC (permalink / raw)
To: gregkh
Cc: ebiederm, greg, kay.sievers, linux-kernel, tj, cornelia.huck,
eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517210318.GA6170@suse.de>
From: Greg KH <gregkh@suse.de>
Date: Mon, 17 May 2010 14:03:18 -0700
> On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
>> Greg KH <greg@kroah.com> writes:
>>
>> If I must I will resend these, but these patches are already in
>> production use, and I had them to you weeks before the merge window
>> closed.
>
> Yes, but they were not reviewed by the network maintainer until after
> the merge window closed. I already have your sysfs-namespace patches
> queued up for .35, and that's a big enough change for me to feel
> comfortable with at the moment.
Greg, this is complete bullshit. I reviewed them last week, they are fine
and have been around forever.
Merge them in now, making them wait until 2.6.36 is completely rediculious.
^ permalink raw reply
* Re: [PATCH 1/1] ipv6 addrlabel: permit deletion of labels assigned to removed dev
From: David Miller @ 2010-05-18 0:08 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1273267893-22485-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Fri, 7 May 2010 23:31:33 +0200
> as addrlabels with an interface index are left alone when the
> interface gets removed this results in addrlabels that can no
> longer be removed.
>
> Restrict validation of index to adding new addrlabels.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH 1/1] ibmveth: Add suspend/resume support
From: David Miller @ 2010-05-18 0:09 UTC (permalink / raw)
To: brking; +Cc: netdev
In-Reply-To: <201005071156.o47BuCYM007062@d03av03.boulder.ibm.com>
From: Brian King <brking@linux.vnet.ibm.com>
Date: Fri, 07 May 2010 13:56:08 -0500
>
> Adds support for resuming from suspend for IBM virtual ethernet devices.
> We may have lost an interrupt over the suspend, so we just kick the
> interrupt handler to process anything that is outstanding.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/asix.c Fix unaligned access
From: David Miller @ 2010-05-18 0:18 UTC (permalink / raw)
To: neiljay; +Cc: netdev
In-Reply-To: <AANLkTiliFhlbe7HAOyn9O3935MkmEuRumLKYY7Ew4DXQ@mail.gmail.com>
From: Neil Jones <neiljay@gmail.com>
Date: Mon, 10 May 2010 17:06:01 +0100
> Using this driver can cause unaligned accesses in the IP layer
> This has been fixed by aligning the skb data correctly using the
> spare room left over by the 4 byte header inserted between packets
> by the device.
>
> Signed-off-by: Neil Jones <NeilJay@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/9] netdev: bfin_mac: add support for IEEE 1588 PTP
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, barry.song
In-Reply-To: <1273505954-32588-1-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:06 -0400
> Newer on-chip MAC peripherals support IEEE 1588 PTP in the hardware, so
> extend the driver to support this functionality.
>
> Signed-off-by: Barry Song <barry.song@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/9] netdev: bfin_mac: handler RX status errors
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, pmeerw, graf.yang
In-Reply-To: <1273505954-32588-2-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:07 -0400
> From: Peter Meerwald <pmeerw@pmeerw.net>
>
> Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
> Signed-off-by: Graf Yang <graf.yang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 3/9] netdev: bfin_mac: invalid data cache only once for each new rx skb buffer
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, sonic.zhang
In-Reply-To: <1273505954-32588-3-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:08 -0400
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> The skb buffer isn't actually used until we finish transferring and pass
> it up to higher layers, so only invalidate the range once before we start
> receiving actual data. This also avoids the problem with data invalidating
> on Blackfin systems -- there is no invalidate-only, just invalidate+flush.
> So when running in writeback mode, there is the small (but not uncommon)
> possibility of the flush overwriting valid DMA-ed data from the cache.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 5/9] netdev: bfin_mac: clear RXCKS if hardware generated checksum is not enabled
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, sonic.zhang
In-Reply-To: <1273505954-32588-5-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:10 -0400
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> Otherwise we might be get a setting mismatch from a previous module or
> bootloader and what the driver currently expects.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 4/9 v2] netdev: bfin_mac: deduce Ethernet FCS from hardware IP payload checksum
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier-aBrp7R+bbdUdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, jon.kowal-obo422lQt0aqq+TXWfNVuQ,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <1273505954-32588-4-git-send-email-vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
From: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Date: Mon, 10 May 2010 11:39:09 -0400
> From: Sonic Zhang <sonic.zhang-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
>
> IP checksum is based on 16-bit one's complement algorithm, so to deduce a
> value from checksum is equal to add its complement.
>
> Unfortunately, the Blackfin on-chip MAC checksum logic only works when the
> IP packet has a header length of 20 bytes. This is true for most IPv4
> packets, but not for IPv6 packets or IPv4 packets which use header options.
> So only use the hardware checksum when appropriate.
>
> Signed-off-by: Sonic Zhang <sonic.zhang-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Jon Kowal <jon.kowal-obo422lQt0aqq+TXWfNVuQ@public.gmane.org>
> Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH 6/9] netdev: bfin_mac: add support for wake-on-lan magic packets
From: David Miller @ 2010-05-18 0:21 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, michael.hennerich
In-Reply-To: <1273505954-32588-6-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:11 -0400
> From: Michael Hennerich <michael.hennerich@analog.com>
>
> Note that WOL works only in PM Suspend Standby Mode (Sleep Mode).
>
> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH 7/9] netdev: bfin_mac: use promiscuous flag for promiscuous mode
From: David Miller @ 2010-05-18 0:22 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel, sonic.zhang
In-Reply-To: <1273505954-32588-7-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 10 May 2010 11:39:12 -0400
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> Rather than using the Receive All Frames (RAF) bit to enable promiscuous
> mode, use the Promiscuous (PR) bit. This lowers overhead at runtime as
> we let the hardware process the packets that should actually be checked.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox