* Re: [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: Steve Wise @ 2011-09-28 20:03 UTC (permalink / raw)
To: Jonathan Lallinger; +Cc: David Miller, netdev
In-Reply-To: <4E82075B.9000003@opengridcomputing.com>
On 09/27/2011 12:26 PM, Jonathan Lallinger wrote:
> Hello David,
>
> I am ashamed I made the same mistake twice. This happened because I had two git trees (I made a second one when
> kernel.org went down based off the github remote). I fixed, built, and ran several tests on the patch, and then sent
> the wrong patch from an old git tree (which was never build tested).
>
> I can assure you I have a working patch, and it has been tested by the QA group at Chelsio and it builds/runs but
> there are still additional bugs in rds. So once I resolve those I will resend the correct patch with some additional
> fixes.
Hey Jonathan,
I think you should get this patch resubmitted as-is (the correct patch though ;). If we hit other issues in testing,
then we can submit more patches. The problems Chelsio is seeing may be backport issues and not upstream bugs.
Steve.
^ permalink raw reply
* Re: Problem with ARP-replies on Kernels 2.6 (possibly 3.0, but not 2.4!)
From: Nicolas de Pesloüan @ 2011-09-28 20:07 UTC (permalink / raw)
To: skandranon; +Cc: netdev
In-Reply-To: <4E835E35.3030503@gmx.at>
Le 28/09/2011 19:49, skandranon a écrit :
> Basically, I would have expected MyMachine to answer ARP queries received via eth0 only if an
> address was queried that was assigned to eth0 (also secondary IP addresses assigned by "ip" or
> virtual interfaces generated by ifconfig).
>
> So: Is this a bug or a feature?
It is a feature.
You should have a look at the file Documentation/networking/ip-sysctl in the kernel source tree, in
particular the entry about arp_ignore.
Nicolas.
^ permalink raw reply
* Re: ICMP redirect issue
From: Flavio Leitner @ 2011-09-28 20:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110928.140632.726302773135946390.davem@davemloft.net>
On Wed, 28 Sep 2011 14:06:32 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Flavio Leitner <fbl@redhat.com>
> Date: Tue, 27 Sep 2011 16:21:20 -0300
>
> > The issue is about the gateway being a LVS, so the servers behind
> > use the IP alias address as the default gateway. However, when the
> > gateway sends an ICMP redirect, it comes from the primary IP
> > address which is ignored on older kernels because of the old_gw
> > check:
> >
> > - if (rth->rt_dst != daddr ||
> > - rth->rt_src != saddr ||
> > - rth->dst.error ||
> > - rth->rt_gateway != old_gw ||
> > - rth->dst.dev != dev)
> > - break;
> >
> >
> > Well, the consequence is that the issue doesn't happen in newer
> > kernels because it happily accepts the ICMP redirect.
> >
> > The admin can still control using shared_media and secure_redirects
> > if the host should accept only the ICMP redirects for gateways
> > listed in default gateway list or not.
>
> Unfortunately, shared_media is on by default which means the default
> secure_redirects setting of '1' is ignored.
>
> This means that redirects can be spoofed in the default configuration,
> but with the above check they would not be spoofable.
I fail to see what that check is preventing because if someone manages
to inject a redirect packet into the network, then likely the old_gw can
be tweaked to be the network gateway.
> I suspect that, because of this, we'll need to add the check back. Or
> do something similar.
>
> We can't "fix" this by turning shared_media off by default because
> that changes behavior on input route processing wrt. how we decide
> whether to emit a redirect or not.
What about something like below? It will change a bit the
secure_redirects documentation.
shared_media secure_redirect behavior:
0 0 all pass.
0 1 only from gateways and for gateways.
1 0 all pass.
1 1 default, old behavior, only from
gateways.
If you agree with the approach, I'll run tests here and post
the patch with a proper changelog, documentation and signed-off.
thanks,
fbl
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 075212e..fa00fcd 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1332,6 +1332,9 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw,
goto reject_redirect;
}
+ if (IN_DEV_SEC_REDIRECTS(in_dev) && ip_fib_check_default(old_gw, dev))
+ goto reject_redirect;
+
peer = inet_getpeer_v4(daddr, 1);
if (peer) {
peer->redirect_learned.a4 = new_gw;
^ permalink raw reply related
* Re: [PATCH] Fix repeatable Oops on container destroy with conntrack
From: Pablo Neira Ayuso @ 2011-09-28 21:08 UTC (permalink / raw)
To: Alex Bligh
Cc: Alexey Dobriyan, netfilter-devel, linux-kernel, containers,
Linux Containers, netdev
In-Reply-To: <A51A04647674405AF6C39A4F@nimrod.local>
On Wed, Sep 14, 2011 at 09:01:34AM +0100, Alex Bligh wrote:
> --On 14 September 2011 03:35:00 +0200 Pablo Neira Ayuso
> <pablo@netfilter.org> wrote:
>
> >>Is this new version OK? I am happy to adjust if not.
> >
> >Hm, I still think that this is a workaround.
>
> It is a bit of a workaround, that is true. But it is a workaround
> that will fix the bug in every kernel since 2.6.32 (and perhaps
> before - I haven't looked). It's thus reasonably easily applicable
> to stable kernel series.
The container support for netfilter seems to be in intermediate state,
we need several patches to get it finished that:
* subsys_table definition in nfnetlink.c.
* ctnl_notifier and ctnl_notifier_exp definitions in
nfnetlink_conntrack.c
* similar things for nfnetlink_queue and nfnetlink_log.
If nobody is going to fix all these, I'll find some spare time to do
it myself, but I don't think we'll have a proper fix that we can pass
to -stable. This will have to go to net-next, given the amount of
patches that we'll need to appropriately fix this.
> I'm not clued-up enough on Netfilter to know what the right fix is,
> but is applying the workaround in a commit which could be easily
> backported, then applying the 'right fix' (assuming that is different)
> a reasonable strategy?
>
> As you can probably tell, my interest here is to get something that
> doesn't oops into stable kernels.
As said, I'm not sure that this can happen, given that the amount of
patches that we need to fix it fine, sorry.
^ permalink raw reply
* Re: [PATCH RFC v2 0/5] netfilter reverse path filter matches
From: Pablo Neira Ayuso @ 2011-09-28 21:18 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, netdev, davem
In-Reply-To: <1315856552-1422-1-git-send-email-fw@strlen.de>
On Mon, Sep 12, 2011 at 09:42:27PM +0200, Florian Westphal wrote:
> Version 2 of the ipv4/v6 reverse path filter matches discussed during
> nfws 2011.
>
> The ipv4 match (ipt_rpfilter) tries to do exactly what the current
> fib_validate_source does. The main problem with this is that
> we need to do an additional fib lookup to get the oif in the match.
> [ delaying until FORWARD is invoked is not possible because by
> that point the stack might have already sent icmp errors ].
>
> Patrick McHardy suggested to simply attach the result as the dst, so
> ipv4 input path doesn't have to do it again.
>
> This works, but does have a few side effects wrt. route-by-mark and
> TPROXY, see patch changelog for details.
>
> The ipv6 version does a pure 'reverse' lookup instead. This makes
> things a lot easier (e.g. when multiple route entries exist), but has
> the caveat that a real reply packet might be handled differently due to
> policy routing rules.
>
> Userspace part is stored in my iptables repository on
> http://git.breakpoint.cc/cgi-bin/gitweb.cgi?p=fw/iptables.git (branch 'rpfilter').
>
> Kernel patches are located in the 'xt_rpfilter_5' branch on
> http://git.breakpoint.cc/cgi-bin/gitweb.cgi?p=fw/nf-next.git
> (patches will be sent as followup to this email).
>
> [ in case you are wondering: the earlier xt_rpfilter version was
> removed -- causes too many module dependency issues and most of the
> code cannot be shared anyway ].
This involves other net changes, I'd like to get an ack from David
before applying this. Or let me know if it's better to follow the
netdev path.
^ permalink raw reply
* Re: [PATCH RFC v2 0/5] netfilter reverse path filter matches
From: Florian Westphal @ 2011-09-28 21:23 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Florian Westphal, netfilter-devel, netdev, davem
In-Reply-To: <20110928211847.GC2761@1984>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Kernel patches are located in the 'xt_rpfilter_5' branch on
> > http://git.breakpoint.cc/cgi-bin/gitweb.cgi?p=fw/nf-next.git
> > (patches will be sent as followup to this email).
> >
> > [ in case you are wondering: the earlier xt_rpfilter version was
> > removed -- causes too many module dependency issues and most of the
> > code cannot be shared anyway ].
>
> This involves other net changes, I'd like to get an ack from David
> before applying this. Or let me know if it's better to follow the
> netdev path.
Pablo, please do not apply these patches, I have newer versions
available.
David, it would be nice if you could indicate how these patches
should be merged (ie. via net-next or netfilter-next).
[ in case there are objections, I'd like to hear about those too :-) ]
Thanks,
Florian
^ permalink raw reply
* Re: [GIT PULL net-next] IPVS
From: Pablo Neira Ayuso @ 2011-09-28 21:45 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Patrick McHardy, David S. Miller
In-Reply-To: <20110928132802.GC7661@verge.net.au>
On Wed, Sep 28, 2011 at 10:28:03PM +0900, Simon Horman wrote:
> On Tue, Sep 27, 2011 at 10:16:18AM +0200, Pablo Neira Ayuso wrote:
> > On Mon, Sep 26, 2011 at 06:05:33PM +0900, Simon Horman wrote:
> > > Hi,
> > >
> > > with all the excitement of kernel.org being offline and a bunch of trees
> > > likewise being offline I am a little unsure who should take this pull
> > > request which is based on the current net-next tree. But I guess it should
> > > be Patrick, Pablo or Dave.
> >
> > I'll try to set up one tree in one of my servers along today, I'll
> > send you the URI. We can use it until kernel.org comes back.
>
> Thanks. Would you like me to rebase my tree on yours?
Thinking it well, and given that you'll have to send me more patches,
I think it's a good idea if you rebase.
BTW, please no need to Cc netfilter@vger.kernel.org, that list is for
netfilter users, not for developers.
^ permalink raw reply
* Re: [PATCH] iwlagn: iwl-agn-rs: remove unnecessary null check for sta and lq_sta
From: Guy, Wey-Yi @ 2011-09-28 22:18 UTC (permalink / raw)
To: Gregory.Dietsche@cuw.edu
Cc: ilw@linux.intel.com, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1317250444-2248-1-git-send-email-Gregory.Dietsche@cuw.edu>
On Wed, 2011-09-28 at 15:54 -0700, Gregory.Dietsche@cuw.edu wrote:
> From: Greg Dietsche <Gregory.Dietsche@cuw.edu>
>
> both sta and lq_sta are guaranteed to be not null in the
> calling function so we don't need to check them here.
>
> Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
you are correct
Wey
^ permalink raw reply
* Re: [PATCH RFC v2 0/5] netfilter reverse path filter matches
From: David Miller @ 2011-09-28 22:39 UTC (permalink / raw)
To: fw; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20110928212358.GA13047@Chamillionaire.breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 28 Sep 2011 23:23:58 +0200
> David, it would be nice if you could indicate how these patches
> should be merged (ie. via net-next or netfilter-next).
I'm fine with them going into netfilter-next, I'll add my ACKs to the
next version you post.
^ permalink raw reply
* [ANN] compat-wireless for 3.1-rc8 is out
From: Luis R. Rodriguez @ 2011-09-28 22:53 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-bluetooth, netdev, linux-wireless
The world hasn't ended yet, even without kernel.org, so we get a new
compat-wireless release based on Linus' rc8 release. Given that
kernel.org is down I just sucked in Linus' tree on github into my
linux-2.6-allstable and reset it to 3.1-rc8. Please test and rant
about issues found.
http://linuxwireless.org/en/users/Download/stable (as
wireless.kernel.org DNS is bust right now)
sha1sum: db33de991c9764185707591da881963e041de9c8
Size: 4.1 MiB
http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.1/compat-wireless-3.1-rc8-1.tar.bz2
http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.1/ChangeLog-3.1-wireless
Luis
^ permalink raw reply
* [PATCH] iwlagn: iwl-agn-rs: remove unnecessary null check for sta and lq_sta
From: Gregory.Dietsche @ 2011-09-28 22:54 UTC (permalink / raw)
To: wey-yi.w.guy
Cc: ilw, linville, linux-wireless, netdev, linux-kernel,
Greg Dietsche
From: Greg Dietsche <Gregory.Dietsche@cuw.edu>
both sta and lq_sta are guaranteed to be not null in the
calling function so we don't need to check them here.
Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
---
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 3789ff4..e5ea33b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -2269,9 +2269,6 @@ static void rs_rate_scale_perform(struct iwl_priv *priv,
info->flags & IEEE80211_TX_CTL_NO_ACK)
return;
- if (!sta || !lq_sta)
- return;
-
lq_sta->supp_rates = sta->supp_rates[lq_sta->band];
tid = rs_tl_add_packet(lq_sta, hdr);
--
1.7.6.4
^ permalink raw reply related
* Re: ICMP redirect issue
From: David Miller @ 2011-09-28 22:56 UTC (permalink / raw)
To: fbl; +Cc: netdev
In-Reply-To: <20110928171952.0c0d2d05@asterix.rh>
From: Flavio Leitner <fbl@redhat.com>
Date: Wed, 28 Sep 2011 17:19:52 -0300
> What about something like below? It will change a bit the
> secure_redirects documentation.
The previous check was stronger, and served other purposes.
Firstly, it required that the spoofer know the exact gateway
IP address we used previously, whereas your test requires only
knowing the subnet which is easier to figure out.
But more importantly, the old test allowed us to ignore outdated
or erroneous redirects.
We really have to restore the original behavior before my inetpeer
changes (enforce that the old gateway matches), and find another way
to accomodate IPVS.
^ permalink raw reply
* Re: [GIT PULL net-next] IPVS
From: Simon Horman @ 2011-09-28 23:01 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Patrick McHardy, David S. Miller
In-Reply-To: <20110928214516.GE2761@1984>
On Wed, Sep 28, 2011 at 11:45:16PM +0200, Pablo Neira Ayuso wrote:
> On Wed, Sep 28, 2011 at 10:28:03PM +0900, Simon Horman wrote:
> > On Tue, Sep 27, 2011 at 10:16:18AM +0200, Pablo Neira Ayuso wrote:
> > > On Mon, Sep 26, 2011 at 06:05:33PM +0900, Simon Horman wrote:
> > > > Hi,
> > > >
> > > > with all the excitement of kernel.org being offline and a bunch of trees
> > > > likewise being offline I am a little unsure who should take this pull
> > > > request which is based on the current net-next tree. But I guess it should
> > > > be Patrick, Pablo or Dave.
> > >
> > > I'll try to set up one tree in one of my servers along today, I'll
> > > send you the URI. We can use it until kernel.org comes back.
> >
> > Thanks. Would you like me to rebase my tree on yours?
>
> Thinking it well, and given that you'll have to send me more patches,
> I think it's a good idea if you rebase.
Good thinking. I have rebased my ipvs-next tree on your nf-next branch.
> BTW, please no need to Cc netfilter@vger.kernel.org, that list is for
> netfilter users, not for developers.
Thanks, notied.
^ permalink raw reply
* Re: ICMP redirect issue
From: David Miller @ 2011-09-28 23:12 UTC (permalink / raw)
To: fbl; +Cc: netdev
In-Reply-To: <20110928.185654.560483806662347226.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 28 Sep 2011 18:56:54 -0400 (EDT)
> From: Flavio Leitner <fbl@redhat.com>
> Date: Wed, 28 Sep 2011 17:19:52 -0300
>
>> What about something like below? It will change a bit the
>> secure_redirects documentation.
>
> The previous check was stronger, and served other purposes.
>
> Firstly, it required that the spoofer know the exact gateway
> IP address we used previously, whereas your test requires only
> knowing the subnet which is easier to figure out.
>
> But more importantly, the old test allowed us to ignore outdated
> or erroneous redirects.
>
> We really have to restore the original behavior before my inetpeer
> changes (enforce that the old gateway matches), and find another way
> to accomodate IPVS.
BTW, I just double-checked RFC1122 and it explicitly specifies the
old_gw check:
[ RFC1122, section 3.2.2.2 ]
...
A Redirect message SHOULD be silently discarded if the new
gateway address it specifies is not on the same connected
(sub-) net through which the Redirect arrived [INTRO:2,
Appendix A], or if the source of the Redirect is not the
current first-hop gateway for the specified destination (see
Section 3.3.1).
In fact, it's saying that we should also validate that saddr == old_gw
too.
So really, we need to put the check back and find a way to accomodate IPVS.
^ permalink raw reply
* Re: 82574 DMA Burst Mode Enablement
From: Jesse Brandeburg @ 2011-09-28 23:20 UTC (permalink / raw)
To: Denis Radovanovic
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Prasanna Panchamukhi, Allan, Bruce W
In-Reply-To: <30751F5D655350478D3821069A3CF1F29D618D@365EXCH-MBX-P5.nbttech.com>
On Wed, 28 Sep 2011 11:39:54 -0700
Denis Radovanovic <Denis.Radovanovic@riverbed.com> wrote:
> We are currently testing small packet performance on 82574, comparing
> it to 82571. Initial pktgen measurements have shown a significant
> difference in performance that is the most visible when running
> bidirectional traffic with 256 byte packets.
>
> Looking at the e1000e driver, we noticed that flag FLAG2_DMA_BURST is
> enabled for 82571 and 82572 but it is not enabled for 82574. After
> enabling the flag, the 82574 performance significantly improved,
> approaching the one on 82571.
At the time the feature was implemented we didn't have the bandwidth to
validate it on other parts besides 82571/2
As it stands, yes you can enable it, but there will likely be some bugs
that you will run into that we already know about but don't fully have
fixed in the code. The bugs might result in tx hangs or other issues.
I do agree that there are significant performance gains to be had via
this feature, if the bugs can all be worked out.
if this is a feature that you would really like implemented please use
your Intel Field Agent or TME contacts in order to document your requirement
so we can consider it for future releases.
Thanks,
Jesse
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
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] tcp: properly update lost_cnt_hint during shifting
From: Nandita Dukkipati @ 2011-09-29 0:06 UTC (permalink / raw)
To: Ilpo Järvinen, Yan, Zheng; +Cc: netdev@vger.kernel.org, Yuchung Cheng
In-Reply-To: <alpine.DEB.2.00.1109281418280.21709@wel-95.cs.helsinki.fi>
Could you please clarify this case for me-
skb == tp->lost_skb_hint
If skb is sacked, doesn't tcp_mark_head_lost() already increment
lost_cnt_hint, in which case you won't need to do it here?
Nandita
On Wed, Sep 28, 2011 at 4:29 AM, Ilpo Järvinen
<ilpo.jarvinen@helsinki.fi> wrote:
> On Wed, 28 Sep 2011, Yan, Zheng wrote:
>
>> > But is the non-SACKed case really handled right when hint == skb by the
>> > sacktag_one. We move the seqno in between and then before(x->newseq,
>> > x->newseq) check returns false?
>> >
>> you are right, thank you.
>>
>> really hope my patch is correct this time :)
>> ---
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 21fab3e..a04622e 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -1390,8 +1390,7 @@ static int tcp_shifted_skb(struct sock *sk, struct sk_buff *skb,
>> BUG_ON(!pcount);
>>
>> /* Tweak before seqno plays */
>> - if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint &&
>> - !before(TCP_SKB_CB(tp->lost_skb_hint)->seq, TCP_SKB_CB(skb)->seq))
>> + if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint == skb)
>> tp->lost_cnt_hint += pcount;
>>
>> TCP_SKB_CB(prev)->end_seq += shifted;
>
> It also looks a lot nicer now and more obvious. According to my current
> understanding, feel free to add this once doing the proper submission with
> Signed-off etc. (please also remove the comment too as seqnos have no
> longer any significance here):
>
> Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>
> ...but it certainly wouldn't hurt if also somebody else has pair of eyes
> to spare to confirm that we (both) are now in agreement what the code
> really says.
>
>
> --
> i.
^ permalink raw reply
* Re: [PATCH] tcp: properly update lost_cnt_hint during shifting
From: Nandita Dukkipati @ 2011-09-29 0:12 UTC (permalink / raw)
To: Yan, Zheng; +Cc: netdev@vger.kernel.org, Yuchung Cheng, Ilpo Järvinen
In-Reply-To: <CAB_+Fg5ZzC43XcVjoByepZvA4Mknu6PkRWzpUju+KAQnoMb8JQ@mail.gmail.com>
Actually don't bother about my question. Your patch is correct. I
convinced myself that it's taking care of diff. cases correctly.
Nandita
On Wed, Sep 28, 2011 at 5:06 PM, Nandita Dukkipati <nanditad@google.com> wrote:
> Could you please clarify this case for me-
>
> skb == tp->lost_skb_hint
> If skb is sacked, doesn't tcp_mark_head_lost() already increment
> lost_cnt_hint, in which case you won't need to do it here?
>
> Nandita
>
> On Wed, Sep 28, 2011 at 4:29 AM, Ilpo Järvinen
> <ilpo.jarvinen@helsinki.fi> wrote:
>> On Wed, 28 Sep 2011, Yan, Zheng wrote:
>>
>>> > But is the non-SACKed case really handled right when hint == skb by the
>>> > sacktag_one. We move the seqno in between and then before(x->newseq,
>>> > x->newseq) check returns false?
>>> >
>>> you are right, thank you.
>>>
>>> really hope my patch is correct this time :)
>>> ---
>>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>>> index 21fab3e..a04622e 100644
>>> --- a/net/ipv4/tcp_input.c
>>> +++ b/net/ipv4/tcp_input.c
>>> @@ -1390,8 +1390,7 @@ static int tcp_shifted_skb(struct sock *sk, struct sk_buff *skb,
>>> BUG_ON(!pcount);
>>>
>>> /* Tweak before seqno plays */
>>> - if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint &&
>>> - !before(TCP_SKB_CB(tp->lost_skb_hint)->seq, TCP_SKB_CB(skb)->seq))
>>> + if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint == skb)
>>> tp->lost_cnt_hint += pcount;
>>>
>>> TCP_SKB_CB(prev)->end_seq += shifted;
>>
>> It also looks a lot nicer now and more obvious. According to my current
>> understanding, feel free to add this once doing the proper submission with
>> Signed-off etc. (please also remove the comment too as seqnos have no
>> longer any significance here):
>>
>> Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>>
>> ...but it certainly wouldn't hurt if also somebody else has pair of eyes
>> to spare to confirm that we (both) are now in agreement what the code
>> really says.
>>
>>
>> --
>> i.
>
^ permalink raw reply
* 群发软件+买家搜索机+最新广交会买家、海关数据,B2B询盘买家500万。
From: 仅10元每天 @ 2011-09-29 0:25 UTC (permalink / raw)
To: net2, netblaise, netdev, netfund, nethxz, netm.vpm, netplus,
netseek, nett61
群发软件+买家搜索机+109届广交会买家、展会买家、海关数据,B2B询盘买家500万。
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，最新全球买家库,共451660条数据。
3，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
4，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
5，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
6，60.8万条最新国外B2B买家询盘。
7，2009年海关提单数据piers版数据 1千万。
8，群发软件，群发软件的部署与安装。
共 500万个买家，每个均有Email.
保证每天都有买家回复。
保证每天都有买家回复。
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
诚信为本，如果不信任本人,可以走淘宝交易,收货验证后再付款,这是对您最好的保障了。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
广交会买家按产品类别分类，分为以下几类：
1 办公设备
2 编织及藤铁工艺品
3 玻璃
4 餐厨用具
5 车辆
6 大型机械及设备
7 电子电气
8 电子消费品
9 纺织
10 服装
11 个人护理
12 工程机械
13 工具
14 化工
15 计算机及通讯
16 家居用品
17 家居装饰
18 家具
19 家用电器
20 建筑及装饰材料
21 节日用品
22 礼品及赠品
23 摩托车
24 汽车配件
25 食品
26 陶瓷
27 铁石
28 玩具
29 卫浴
30 五金
31 小型机械
32 鞋
33 休闲用品
34 医疗
35 浴室产品
36 园林
37 照明产品
38 钟表眼镜
39 自行车
40 包
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
^ permalink raw reply
* [PATCH] tg3: Dont dump registers if interface not ready.
From: Joe Jin @ 2011-09-29 2:10 UTC (permalink / raw)
To: Matt Carlson, Michael Chan
Cc: Guru Anbalagane, Gurudas Pai, Joe Jin, netdev,
linux-kernel@vger.kernel.org, Greg Marsden
When bootup the server with BCM5704 Gigabit Ethernet get below warning:
tg3 0000:03:01.0: eth0: DMA Status error. Resetting chip.
<Registers state of device>
tg3 0000:03:01.0: eth0: 0: Host status block [00000007:00000002:(0000:0000:0000):(0000:0000)]
tg3 0000:03:01.0: eth0: 0: NAPI info [00000001:00000002:(0000:0000:01ff):0000:(00c8:0000:0000:0000)]
tg3 0000:03:01.0: eth0: Link is up at 1000 Mbps, full duplex
tg3 0000:03:01.0: eth0: Flow control is on for TX and on for RX
tg3 0000:03:01.0: tg3_stop_block timed out, ofs=4800 enable_bit=2
tg3 0000:03:01.0: eth0: Link is down
tg3 0000:03:01.0: eth0: Link is up at 1000 Mbps, full duplex
tg3 0000:03:01.0: eth0: Flow control is on for TX and on for RX
If device not ready, then would not dump registers info.
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Signed-off-by: Guru Anbalagane <guru.anbalagane@oracle.com>
Reported-by: Gurudas Pai <gurudas.pai@oracle.com>
Cc: Matt Carlson <mcarlson@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
---
drivers/net/tg3.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 4a1374d..d79d344 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5475,10 +5475,15 @@ static void tg3_process_error(struct tg3 *tp)
{
u32 val;
bool real_error = false;
+ bool dump = true;
if (tg3_flag(tp, ERROR_PROCESSED))
return;
+ /* If interface not ready then dont dump error */
+ if (!netif_carrier_ok(tp->dev))
+ dump = false;
+
/* Check Flow Attention register */
val = tr32(HOSTCC_FLOW_ATTN);
if (val & ~HOSTCC_FLOW_ATTN_MBUF_LWM) {
@@ -5492,14 +5497,16 @@ static void tg3_process_error(struct tg3 *tp)
}
if (tr32(RDMAC_STATUS) || tr32(WDMAC_STATUS)) {
- netdev_err(tp->dev, "DMA Status error. Resetting chip.\n");
+ if (dump)
+ netdev_err(tp->dev, "DMA Status error. Resetting chip.\n");
real_error = true;
}
if (!real_error)
return;
- tg3_dump_state(tp);
+ if (dump)
+ tg3_dump_state(tp);
tg3_flag_set(tp, ERROR_PROCESSED);
schedule_work(&tp->reset_task);
--
1.7.6.2
^ permalink raw reply related
* Re: Draft manpage for recvmmsg [RESEND]
From: Michael Kerrisk @ 2011-09-29 4:10 UTC (permalink / raw)
To: Andi Kleen
Cc: acme-H+wXaHxf7aLQT0dZR+AlfA, Stephan Mueller, linux-man,
Linux API, netdev
In-Reply-To: <20110928175213.GK7761-qrUzlfsMFqo/4alezvVtWx2eb7JE58TQ@public.gmane.org>
[Restoring CC]
Hi Andi,
On Wed, Sep 28, 2011 at 7:52 PM, Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> wrote:
> On Wed, Sep 28, 2011 at 07:29:00PM +0200, Michael Kerrisk wrote:
>> Hi Andi, Arnaldo,
>>
>> Could you please review the revised recvmmsg.2 man page below.
>>
>> Andi: I need to know what copyright and license to attach to the page
>> before I can release it.
>
> Your original proposal was fine for me.
I didn't make an initial proposal (or I don't recall that I did), but
I suspect you mean the initial proposal on
http://man7.org/linux/man-pages/licenses.html -- that is, the
"Verbatim license". Right?
But please note, I'm also looking for content review on the page,
since I made some notable changes:
* Reworking of some pieces of text
* Added new material on blocking versus non-blocking calls
* Added a more detailed description of how msgvec is updated on return
from the call.
* Added an ERRORS section
Do these changes look okay?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Web Notice!!!
From: Web Administrator @ 2011-09-29 3:23 UTC (permalink / raw)
Dear E-mail User,,
Please click this link to verify your account if is still active:
https://docs.google.com/spreadsheet/viewform?formkey=dHdoRzl4NUtpMWw1VzdtcnI3WkhTZUE6MQ
Note: failure to upgrade may to the closure of your e-mail.
Thank you for using Web mail.
E-mail? CMS Webmail GmbH 2011
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: tehuti: Alexander Indenbaum's address bounces
From: David Miller @ 2011-09-29 4:32 UTC (permalink / raw)
To: ian.campbell; +Cc: linux-kernel, baum, andy, akpm, netdev
In-Reply-To: <1316678906-17113-1-git-send-email-ian.campbell@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 22 Sep 2011 09:08:26 +0100
> I got:
> Generating server: Tehuti.onmicrosoft.com
>
> baum@tehutinetworks.net
> #< #5.1.1 smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found> #SMTP#
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6] cxgb4: Fix EEH on IBM P7IOC
From: David Miller @ 2011-09-29 4:34 UTC (permalink / raw)
To: divy; +Cc: netdev, linux-kernel, dm, swise, kxie
In-Reply-To: <20110924161130.18521.39558.stgit@speedy5.asicdesigners.com>
From: Divy Le Ray <divy@chelsio.com>
Date: Sat, 24 Sep 2011 09:11:31 -0700
> From: Divy Le Ray <divy@chelsio.com>
>
> Fix EEH recovery on new P Series platform by
> requesting fundamental reset.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: nullify ipv6_ac_list and ipv6_fl_list when creating new socket
From: David Miller @ 2011-09-29 4:34 UTC (permalink / raw)
To: zheng.z.yan; +Cc: netdev
In-Reply-To: <4E7F1CCA.5000104@intel.com>
From: "Yan, Zheng" <zheng.z.yan@intel.com>
Date: Sun, 25 Sep 2011 20:21:30 +0800
> ipv6_ac_list and ipv6_fl_list from listening socket are inadvertently
> shared with new socket created for connection.
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] ibmveth: Fix oops on request_irq failure
From: David Miller @ 2011-09-29 4:34 UTC (permalink / raw)
To: brking; +Cc: netdev
In-Reply-To: <201109281533.p8SFXhfe030707@d03av04.boulder.ibm.com>
From: Brian King <brking@linux.vnet.ibm.com>
Date: Wed, 28 Sep 2011 10:33:43 -0500
>
> If request_irq fails, the ibmveth driver will overwrite
> the rc and end up returning a successful rc on its open
> function, resulting in an oops later when a packet gets
> sent and buffers are not allocated due to the failed open.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
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