* Re: [PATCH net-2.6] jme: Fix unmap error (Causing system freeze)
From: David Miller @ 2011-07-21 22:23 UTC (permalink / raw)
To: chrisw
Cc: jason, netdev, cooldavid, jason, marcus.disi, arieslee, devinchiu,
mschiff, stable
In-Reply-To: <20110721193008.GC9766@sequoia.sous-sol.org>
From: Chris Wright <chrisw@sous-sol.org>
Date: Thu, 21 Jul 2011 12:30:08 -0700
> * cooldavid@cooldavid.org (cooldavid@cooldavid.org) wrote:
>> From: Guo-Fu Tseng <cooldavid@cooldavid.org>
>>
>> This patch add the missing dma_unmap().
>> Which solved the critical issue of system freeze on heavy load.
>>
>> Michal Miroslaw's rejected patch:
>> [PATCH v2 10/46] net: jme: convert to generic DMA API
>> Pointed out the issue also, thank you Michal.
>> But the fix was incorrect. It would unmap needed address
>> when low memory.
>>
>> Got lots of feedback from End user and Gentoo Bugzilla.
>> https://bugs.gentoo.org/show_bug.cgi?id=373109
>> Thank you all. :)
>
> Also referred to in kernel bugzilla:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=39312
>
>> Cc: stable@kernel.org
>> Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
>
> Acked-by: Chris Wright <chrisw@sous-sol.org>
Applied, but it's too late for 3.0 so I'll just submit it to all
the -stable branches after 3.0-final is released.
Thanks.
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply
* Re: [PATCH] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods
From: Ben Greear @ 2011-07-21 22:26 UTC (permalink / raw)
To: David Miller
Cc: nhorman, eric.dumazet, jpirko, netdev, adobriyan, robert.olsson
In-Reply-To: <20110721.151903.297506479006061401.davem@davemloft.net>
On 07/21/2011 03:19 PM, David Miller wrote:
> From: Ben Greear<greearb@candelatech.com>
> Date: Thu, 21 Jul 2011 15:14:32 -0700
>
>> On 07/21/2011 03:01 PM, David Miller wrote:
>>> From: Neil Horman<nhorman@tuxdriver.com>
>>> Date: Wed, 20 Jul 2011 11:18:27 -0400
>>>
>>>> On Wed, Jul 20, 2011 at 06:24:15AM +0200, Eric Dumazet wrote:
>>>>> Le mardi 19 juillet 2011 à 22:07 -0400, Neil Horman a écrit :
>>>>>>>
>>>>>> I think this is a good idea. It lets pktgen dynamically make the
>>>>>> clone/share
>>>>>> decision dynamically and only impacts performance for those systems.
>>>>>>
>>>>>
>>>>> Just let pktgen refuse to use clone_skb command for these devices.
>>>>>
>>>> copy that, This is by no means final, but what do you think of this?
>>>> If its
>>>> agreeable to you, Ben, et al. I can add this to my local tree and
>>>> start auditing
>>>> all the drivers that may need to have the flag set.
>>>
>>> I think there is a much simpler solution.
>>>
>>> Set a flag in the SKB when pktgen does SKB sharing.
>>>
>>> In dev_queue_xmit() (or perhaps, dev_hard_start_xmit()), check the
>>> flag
>>> and if it's set then we copy the SKB.
>>>
>>> If this works, then we fix the crash and no driver changes are
>>> necessary both now and in the future.
>>
>> Doesn't that make clone-skb in pktgen much less efficient
>> in all cases?
>
> No, the copy only happens if we enter dev_queue_xmit() which pktgen
> doesn't do, it calls the driver's ->ndo_start_xmit() method directly.
>
> That's the whole idea. Only these encapsulating software devices
> will trigger the condition.
It seems there may be some Ethernet drivers that have similar issues,
though I don't know of any personally (many years ago, Chelsio 10G NICs had
this issue, but it may be fixed now.)
But, it should be no worse than what we have today, and now that I
better understand what you suggest, it sounds OK to me.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-2.6] ethtool: Allow zero-length register dumps again
From: David Miller @ 2011-07-21 22:25 UTC (permalink / raw)
To: bhutchings; +Cc: linville, kvalo, netdev, linux-wireless
In-Reply-To: <1311270840.28569.34.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 21 Jul 2011 19:54:00 +0200
> Some drivers (ab)use the ethtool_ops::get_regs operation to expose
> only a hardware revision ID. Commit
> a77f5db361ed9953b5b749353ea2c7fed2bf8d93 ('ethtool: Allocate register
> dump buffer with vmalloc()') had the side-effect of breaking these, as
> vmalloc() returns a null pointer for size=0 whereas kmalloc() did not.
>
> For backward-compatibility, allow zero-length dumps again.
>
> Reported-by: Kalle Valo <kvalo@qca.qualcomm.com>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Cc: stable@kernel.org [2.6.37+]
Applied to net-next-2.6, I left the CC: stable tag in there so
-stable will pick it up once it hits Linus's tree during the
merge window.
Thanks.
^ permalink raw reply
* Re: Just one more byte, it is wafer thin...
From: Rick Jones @ 2011-07-21 22:28 UTC (permalink / raw)
To: netdev; +Cc: Eli Cohen, Yevgeny Petrilin
In-Reply-To: <4E2764A0.90003@hp.com>
On 07/20/2011 04:28 PM, Rick Jones wrote:
> and just to be completely pedantic about it, set rx-usecs-high to 0:
>
> # HDR="-P 1";for r in 4344 4345; do netperf -H mumble.3.21 -t TCP_RR
> $HDR -- -r ${r},1; HDR="-P 0"; done
> MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
> to mumble.3.21 (mumble.3.21) port 0 AF_INET : histogram : first burst 0
> Local /Remote
> Socket Size Request Resp. Elapsed Trans.
> Send Recv Size Size Time Rate
> bytes Bytes bytes bytes secs. per sec
>
> 16384 87380 4344 1 10.00 14274.03
> 16384 87380
> 16384 87380 4345 1 10.00 13697.11
> 16384 87380
>
> and got a somewhat unexpected result - I've no idea why then they both
> went up - perhaps it was sensing "high" occasionally even in the 4344
> byte request case. Still, is this suggesting that perhaps the adaptive
> bits are being a bit to aggressive about sensing high? Over what
> interval is that measurement supposed to be happening?
So, from a 2.6.38 tree in drivers/net/mlx4/en_netdev:
/* Apply auto-moderation only when packet rate exceeds a rate that
* it matters */
if (rate > MLX4_EN_RX_RATE_THRESH) {
/* If tx and rx packet rates are not balanced, assume that
* traffic is mainly BW bound and apply maximum moderation.
* Otherwise, moderate according to packet rate */
if (2 * tx_pkt_diff > 3 * rx_pkt_diff &&
rx_pkt_diff / rx_byte_diff <
MLX4_EN_SMALL_PKT_SIZE)
moder_time = priv->rx_usecs_low;
else if (2 * rx_pkt_diff > 3 * tx_pkt_diff)
moder_time = priv->rx_usecs_high;
else {
if (rate < priv->pkt_rate_low)
moder_time = priv->rx_usecs_low;
else if (rate > priv->pkt_rate_high)
moder_time = priv->rx_usecs_high;
else
moder_time = (rate - priv->pkt_rate_low) *
(priv->rx_usecs_high -
priv->rx_usecs_low) /
(priv->pkt_rate_high -
priv->pkt_rate_low) +
priv->rx_usecs_low;
}
} else {
/* When packet rate is low, use default moderation
rather than
* 0 to prevent interrupt storms if traffic suddenly
increases */
moder_time = priv->rx_usecs;
}
It would seem that the assume is involved here. The TCP_RR test I was
running (or NFS Read, or NFS Write, or I suspect SMB/CIFS reads and
writes etc) will have either request much larger than response or vice
versa. That leaves the tx and rx packet rates decidedly not balanced
even when the traffic is not BW bound, particularly when there will not
be all that many requests outstanding at one time. And it becomes even
more unbalanced when LRO/GRO stretches the ACKs.
rick jones
^ permalink raw reply
* Re: [PATCH 1/4] stmmac: update the version (V2)
From: David Miller @ 2011-07-21 22:30 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1311156324-23928-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 20 Jul 2011 12:05:21 +0200
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/4] stmmac: remove warning when compile as built-in (V2)
From: David Miller @ 2011-07-21 22:30 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1311156324-23928-2-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 20 Jul 2011 12:05:22 +0200
> The patch removes the following serie of warnings
> when the driver is compiled as built-in:
>
> drivers/net/stmmac/stmmac_main.c: In function stmmac_cmdline_opt:
> drivers/net/stmmac/stmmac_main.c:1855:12: warning: ignoring return
> value of kstrtoul, declared with attribute warn_unused_result
> [snip]
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/4] stmmac: unify MAC and PHY configuration parameters (V2)
From: David Miller @ 2011-07-21 22:30 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, stuart.menefy
In-Reply-To: <1311156324-23928-3-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 20 Jul 2011 12:05:23 +0200
> Prior to this change, most PHY configuration parameters were passed
> into the STMMAC device as a separate PHY device. As well as being
> unusual, this made it difficult to make changes to the MAC/PHY
> relationship.
>
> This patch moves all the PHY parameters into the MAC configuration
> structure, mainly as a separate structure. This allows us to completely
> ignore the MDIO bus attached to a stmmac if desired, and not create
> the PHY bus. It also allows the stmmac driver to use a different PHY
> from the one it is connected to, for example a fixed PHY or bit banging
> PHY.
>
> Also derive the stmmac/PHY connection type (MII/RMII etc) from the
> mode can be passed into <platf>_configure_ethernet.
> STLinux kernel at git://git.stlinux.com/stm/linux-sh4-2.6.32.y.git
> provides several examples how to use this new infrastructure (that
> actually is easier to maintain and clearer).
>
> Signed-off-by: Stuart Menefy <stuart.menefy@st.com>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/4] stmmac: improve and up-to-date the documentation
From: David Miller @ 2011-07-21 22:30 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1311156324-23928-4-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 20 Jul 2011 12:05:24 +0200
> This patch adds new information for the driver
> especially about its platform structure fields.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6: make fragment identifications less predictable
From: Rick Jones @ 2011-07-21 22:46 UTC (permalink / raw)
To: David Miller; +Cc: fernando, eric.dumazet, security, eugeneteo, netdev, mpm
In-Reply-To: <20110721.151750.995903739612693126.davem@davemloft.net>
On 07/21/2011 03:17 PM, David Miller wrote:
> From: Fernando Gont<fernando@gont.com.ar>
> Date: Wed, 20 Jul 2011 22:32:18 -0300
>
>> Does it make sense to go in this direction rather than simply randomize
>> the IPv6 Fragment Identification?
>
> We could, but that's actually a bit more work.
>
> You have to avoid recycling IDs to the same destination host otherwise
> a retransmit could use the same ID and overlap with a previous set of
> frags, causing corruption.
I think you mean ID reuse rather than packet retransmit no?
It is the same "frankengram" issue present in IPv4 with its now puny 16
bit id field. Doesn't that pretty much rely on layer4 or higher
checksums to avoid corruption?
> This means if you go the "pure random" route, you have to make sure
> that the 32-bit series produced by the random number generator is
> maximally long. This is why openbsd uses an ID generator based upon
> skip32 etc.
>
> And I cannot say that about our RNG infrastructure.
>
> Also, 32-bits seems like a lot, but on a 40Gb link we can exhaust this
> space in ~20 minutes (1554 byte packet over standard ethernet MTU at
> 40Gbit is ~3454767 ipv6 frag IDs per second). So while maybe not a
> serious issue right now, we seem to go up by a factor of 10 every few
> years, therefore at ~400Gb it's down to 2 minutes.
With mode-rr and bonding (and enough CPU) you could probably get it down
to 2 minutes without having to wait a few years.
rick jones
> So we have to look at it like a constrained resource, and therefore
> doing it on a per-destination basis like ipv4 makes a lot of sense.
>
> I think Eric's work is the way forward and I'll be applying his patches.
> --
> 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] ipv6: make fragment identifications less predictable
From: David Miller @ 2011-07-21 23:13 UTC (permalink / raw)
To: rick.jones2; +Cc: fernando, eric.dumazet, security, eugeneteo, netdev, mpm
In-Reply-To: <4E28AC3D.1010907@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Thu, 21 Jul 2011 15:46:21 -0700
> On 07/21/2011 03:17 PM, David Miller wrote:
>> From: Fernando Gont<fernando@gont.com.ar>
>> Date: Wed, 20 Jul 2011 22:32:18 -0300
>>
>>> Does it make sense to go in this direction rather than simply
>>> randomize
>>> the IPv6 Fragment Identification?
>>
>> We could, but that's actually a bit more work.
>>
>> You have to avoid recycling IDs to the same destination host otherwise
>> a retransmit could use the same ID and overlap with a previous set of
>> frags, causing corruption.
>
> I think you mean ID reuse rather than packet retransmit no?
>
> It is the same "frankengram" issue present in IPv4 with its now puny
> 16 bit id field. Doesn't that pretty much rely on layer4 or higher
> checksums to avoid corruption?
We've had documented cases where checksums match after recycling the
fragment ID space in ipv4, that's why we have all of the special
code in the ipv4 fragmentation handling to work around that problem.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6: make fragment identifications less predictable
From: Fernando Gont @ 2011-07-21 23:37 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, security, eugeneteo, netdev, mpm
In-Reply-To: <20110721.151750.995903739612693126.davem@davemloft.net>
On 07/21/2011 07:17 PM, David Miller wrote:
>> Does it make sense to go in this direction rather than simply randomize
>> the IPv6 Fragment Identification?
>
> We could, but that's actually a bit more work.
>
> You have to avoid recycling IDs to the same destination host otherwise
> a retransmit could use the same ID and overlap with a previous set of
> frags, causing corruption.
>
> This means if you go the "pure random" route, you have to make sure
> that the 32-bit series produced by the random number generator is
> maximally long. This is why openbsd uses an ID generator based upon
> skip32 etc.
That scenario assumes packet reordering and/or packet loss. In that
case, and at those packet rates, I'd argue that you shoudn't be relying
on fragmentation, anyway (e.g., use PMTUD).
> So we have to look at it like a constrained resource, and therefore
> doing it on a per-destination basis like ipv4 makes a lot of sense.
>
> I think Eric's work is the way forward and I'll be applying his patches.
While I haven't had a chance to look at the patch yet, I was wondering
whether it defines both a separe "offset" and "counter" for each "flow".
(assuming that Identification values are selected as a result of ID =
offset + counter, where counter is incremented for each packet that is
sent, and offset is some value that depends on (src IP, dst ip)).
If you have separate "offset" for each flow, you solve the problem of
"predictable Identification values". However, if there's a single global
"counter", you're still subject of being exploited for an "idle scan").
Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
^ permalink raw reply
* Re: [PATCH] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods
From: Neil Horman @ 2011-07-21 23:50 UTC (permalink / raw)
To: David Miller
Cc: greearb, eric.dumazet, jpirko, netdev, adobriyan, robert.olsson
In-Reply-To: <20110721.151903.297506479006061401.davem@davemloft.net>
On Thu, Jul 21, 2011 at 03:19:03PM -0700, David Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Thu, 21 Jul 2011 15:14:32 -0700
>
> > On 07/21/2011 03:01 PM, David Miller wrote:
> >> From: Neil Horman<nhorman@tuxdriver.com>
> >> Date: Wed, 20 Jul 2011 11:18:27 -0400
> >>
> >>> On Wed, Jul 20, 2011 at 06:24:15AM +0200, Eric Dumazet wrote:
> >>>> Le mardi 19 juillet 2011 à 22:07 -0400, Neil Horman a écrit :
> >>>>>>
> >>>>> I think this is a good idea. It lets pktgen dynamically make the
> >>>>> clone/share
> >>>>> decision dynamically and only impacts performance for those systems.
> >>>>>
> >>>>
> >>>> Just let pktgen refuse to use clone_skb command for these devices.
> >>>>
> >>> copy that, This is by no means final, but what do you think of this?
> >>> If its
> >>> agreeable to you, Ben, et al. I can add this to my local tree and
> >>> start auditing
> >>> all the drivers that may need to have the flag set.
> >>
> >> I think there is a much simpler solution.
> >>
> >> Set a flag in the SKB when pktgen does SKB sharing.
> >>
> >> In dev_queue_xmit() (or perhaps, dev_hard_start_xmit()), check the
> >> flag
> >> and if it's set then we copy the SKB.
> >>
> >> If this works, then we fix the crash and no driver changes are
> >> necessary both now and in the future.
> >
> > Doesn't that make clone-skb in pktgen much less efficient
> > in all cases?
>
> No, the copy only happens if we enter dev_queue_xmit() which pktgen
> doesn't do, it calls the driver's ->ndo_start_xmit() method directly.
>
> That's the whole idea. Only these encapsulating software devices
> will trigger the condition.
>
I'm happy to go down this route Dave, and agree, its a more solid solution, but
I think the problem with it (which Ben may have been alluding to previously) is
that pktgen doesn't use dev_queue_xmit or dev_hard_start_xmit to send frames.
It mimics the locking of dev_hard_start_xmit (but ignores the other checks that
function does), and just calls the ndo_start_xmit routine of the driver
directly. So theres no common code that an skb traverses from pktgen to a given
driver where we can check such a flag
Again, I'm happy to change that so that pktgen uses dev_hard_start_xmit, but I
wonder if thats going to get the same sort of pushback about performance that my
origional patch did. Eric, et al., thoughts?
Regards
Neil
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6: make fragment identifications less predictable
From: David Miller @ 2011-07-22 0:07 UTC (permalink / raw)
To: fernando; +Cc: eric.dumazet, security, eugeneteo, netdev, mpm
In-Reply-To: <4E28B84C.2090305@gont.com.ar>
From: Fernando Gont <fernando@gont.com.ar>
Date: Thu, 21 Jul 2011 20:37:48 -0300
> While I haven't had a chance to look at the patch yet, I was wondering
> whether it defines both a separe "offset" and "counter" for each "flow".
Why wonder, just take a look.
If you aren't willing to even bother looking at the solution we came
up with, why should we feel compelled to spend any time at all looking
at your "anaylsis" and "concerns"?
^ permalink raw reply
* Re: ipvs oops in 3.0-rc7
From: Simon Horman @ 2011-07-22 0:08 UTC (permalink / raw)
To: Huajun Li
Cc: Julian Anastasov, Randy Dunlap, netdev, lvs-devel, Wensong Zhang
In-Reply-To: <CA+v9cxbhpt3LSZ_m+OA_Kujt79mvDZ7VnGqjbbPQxS_gY6+pTA@mail.gmail.com>
On Thu, Jul 21, 2011 at 09:37:29PM +0800, Huajun Li wrote:
> 2011/7/21 Julian Anastasov <ja@ssi.bg>:
> >
> > Hello,
> >
> > On Wed, 20 Jul 2011, Randy Dunlap wrote:
> >
> >> I'm seeing the following Oops in 3.0-rc7 on x86_64, just loading and unloading
> >> modules. Any chance this is already fixed? I can test current git, but I
> >> wanted to ask first.
> >>
> >> Looks like it is on the second module load of ip_vs (i.e.,
> >> modprobe ip_vs; rmmod ip_vs; modprobe ip_vs).
> >
> > I think, this problem was fixed by this patch:
> >
> > http://www.spinics.net/lists/lvs-devel/msg02051.html
> >
> > But it seems it was lost somewhere ...
> >
>
> That's great, SB. can help to apply it again, thanks.
Sorry about that. For some reason I thought that would be / had been
picked up. I'll send a pull request ASAP.
^ permalink raw reply
* Re: [PATCH] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods
From: David Miller @ 2011-07-22 0:08 UTC (permalink / raw)
To: nhorman; +Cc: greearb, eric.dumazet, jpirko, netdev, adobriyan, robert.olsson
In-Reply-To: <20110721235049.GA29489@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 21 Jul 2011 19:50:49 -0400
> I'm happy to go down this route Dave, and agree, its a more solid solution, but
> I think the problem with it (which Ben may have been alluding to previously) is
> that pktgen doesn't use dev_queue_xmit or dev_hard_start_xmit to send frames.
Neil, that's THE WHOLE POINT, and HOW MY IDEA WORKS.
Pktgen bypasses those functions, so it won't trigger the check and
therefore won't trigger making a copy of the SKB, since copying isn't
needed.
Only layering devices will end up eventually calling into those two
functions and trigger the "need to copy because this SKB is pktgen
shared" check.
^ permalink raw reply
* Re: [BUG] ipv6: all routes share same inetpeer
From: David Miller @ 2011-07-22 0:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311139774.3113.86.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 20 Jul 2011 07:29:34 +0200
> Le mardi 19 juillet 2011 à 11:59 -0700, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Tue, 19 Jul 2011 20:57:50 +0200
>>
>> > Le mardi 19 juillet 2011 à 20:20 +0200, Eric Dumazet a écrit :
>> >> Le mardi 19 juillet 2011 à 10:37 -0700, David Miller a écrit :
>> >> > From: Eric Dumazet <eric.dumazet@gmail.com>
>> >> > Date: Tue, 19 Jul 2011 19:23:49 +0200
>> >> >
>> >> > > Maybe you can find the bug before me ?
>> >> >
>> >> > I think when we add the route we cow the metrics almost immediately.
>> >> > The daddr is, unfortunately, fully prefixed at that point.
>> >>
>> >> Yes, we shall provide a second ip6_rt_copy() argument, with the
>> >> destination address.
>> >>
>> >
>> > Hmm, or maybe just change the dst_copy_metrics(&rt->dst, &ort->dst);
>> > call done from ip6_rt_copy(), to avoid doing the COW if not really
>> > needed ?
>>
>> This is ok if it handles the case where ort's metrics point to
>> writable inetpeer memory.
>
> OK but if ort's metrics are writeable we must perform the dst_copy_metrics()
> and therefore fill rt6i_dst before ?
If it's writable, then there are no problems.
Oh actually, I see what you mean. This is a mess.
I'll try to think about this some more and look at your most
recent patches.
^ permalink raw reply
* [GIT PULL nf-2.6] IPVS
From: Simon Horman @ 2011-07-22 0:18 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy,
Pablo Neira Ayuso, Dave Jones, Randy Dunlap, Huajun Li
Hi Pablo, Hi Patrick,
please consider pulling
git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-2.6.git master
to get the following crash on module removal fix for IPVS.
Sorry for sending this so very, very late in the release cycle.
I had sent it earlier but it seems to have slipped through the cracks
somehow.
Simon Horman (1):
IPVS: Free resources on module removal
net/netfilter/ipvs/ip_vs_ctl.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH] IPVS: Free resources on module removal
From: Simon Horman @ 2011-07-22 0:18 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy,
Pablo Neira Ayuso, Dave Jones, Randy Dunlap, Huajun Li,
Simon Horman, Hans Schillstrom
In-Reply-To: <1311293920-1983-1-git-send-email-horms@verge.net.au>
This resolves a panic on module removal.
Reported-by: Dave Jones <davej@redhat.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_ctl.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 699c79a..a178cb3 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -3771,6 +3771,7 @@ err_sock:
void ip_vs_control_cleanup(void)
{
EnterFunction(2);
+ unregister_netdevice_notifier(&ip_vs_dst_notifier);
ip_vs_genl_unregister();
nf_unregister_sockopt(&ip_vs_sockopts);
LeaveFunction(2);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH net-next-2.6] ipv6: make fragment identifications less predictable
From: Rick Jones @ 2011-07-22 0:34 UTC (permalink / raw)
To: Fernando Gont
Cc: David Miller, eric.dumazet, security, eugeneteo, netdev, mpm
In-Reply-To: <4E28B84C.2090305@gont.com.ar>
On 07/21/2011 04:37 PM, Fernando Gont wrote:
> On 07/21/2011 07:17 PM, David Miller wrote:
>>> Does it make sense to go in this direction rather than simply randomize
>>> the IPv6 Fragment Identification?
>>
>> We could, but that's actually a bit more work.
>>
>> You have to avoid recycling IDs to the same destination host otherwise
>> a retransmit could use the same ID and overlap with a previous set of
>> frags, causing corruption.
>>
>> This means if you go the "pure random" route, you have to make sure
>> that the 32-bit series produced by the random number generator is
>> maximally long. This is why openbsd uses an ID generator based upon
>> skip32 etc.
>
> That scenario assumes packet reordering and/or packet loss.
Isn't that a given? I mean if there were no packet reordering or packet
loss then the size of the ID space wouldn't matter right? The fragments
would be sent, in order and without loss and all would be happiness and
joy. It is only because there is packet reordering and/or packet loss
that we care about the size of the ID space and the time to reuse of a
given ID.
And indeed, fragmentation is considered bad, and was considered bad
enough that the "revenge of the router guys" that is IPv6 punted it to
the end systems, and yes, one should use PMTUD. Which is all well and
good when 999 times out of 1 traffic is flowing over a transport that
does its own segmentation and reassembly. And when IPv6 got spec'ed it
looked to all the world that UDP was on the way out - NFS was migrating
over to TCP, and DNS was "never" more than 512 byte messages. No problem
right? But since then we've gotten things like EDNS which will be
sending DNS messages in UDP datagrams that will have to be fragmented,
PMTUD notwithstanding.
rick jones
almost certainly fumbled a TLA in there somewhere :)
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6: make fragment identifications less predictable
From: Fernando Gont @ 2011-07-22 1:18 UTC (permalink / raw)
To: Rick Jones; +Cc: David Miller, eric.dumazet, security, eugeneteo, netdev, mpm
In-Reply-To: <4E28C58E.1080501@hp.com>
On 07/21/2011 09:34 PM, Rick Jones wrote:
>> That scenario assumes packet reordering and/or packet loss.
>
> Isn't that a given?
I mean that if these "collisions" of Identification numbers are of
concern, then, then, at such bandwidth rates, fragmentation itself would
be a concern.
Chances of collisions are proportional to reordering and losses. That
means that at such bandwidths, you'd need to be able to queue a huge
number of packets (which you might not be able to queue, becacuse of
lack of resources), etc.
> And indeed, fragmentation is considered bad, and was considered bad
> enough that the "revenge of the router guys" that is IPv6 punted it to
> the end systems, and yes, one should use PMTUD. Which is all well and
> good when 999 times out of 1 traffic is flowing over a transport that
> does its own segmentation and reassembly.
And provided that there's no ICMPv6 filtering out there (which there is)
-- at which point you need to implement some for of blackhole detection
a la PLMPTUD.
> And when IPv6 got spec'ed it
> looked to all the world that UDP was on the way out - NFS was migrating
> over to TCP, and DNS was "never" more than 512 byte messages. No problem
> right? But since then we've gotten things like EDNS which will be
> sending DNS messages in UDP datagrams that will have to be fragmented,
> PMTUD notwithstanding.
Hopefully you won't have the aforementioned 40GB traffic rate between
two DNS servers ;-)
Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
^ permalink raw reply
* Re: [PATCH] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods
From: Neil Horman @ 2011-07-22 1:37 UTC (permalink / raw)
To: David Miller
Cc: greearb, eric.dumazet, jpirko, netdev, adobriyan, robert.olsson
In-Reply-To: <20110721.170855.1343650615466483577.davem@davemloft.net>
On Thu, Jul 21, 2011 at 05:08:55PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Thu, 21 Jul 2011 19:50:49 -0400
>
> > I'm happy to go down this route Dave, and agree, its a more solid solution, but
> > I think the problem with it (which Ben may have been alluding to previously) is
> > that pktgen doesn't use dev_queue_xmit or dev_hard_start_xmit to send frames.
>
> Neil, that's THE WHOLE POINT, and HOW MY IDEA WORKS.
>
Dave, RELAX! I GET HOW YOUR IDEA SHOULD WORK! CAPS ARENT NEEDED! :)
> Pktgen bypasses those functions, so it won't trigger the check and
> therefore won't trigger making a copy of the SKB, since copying isn't
> needed.
>
But thats part of the problem, we can't just have pktgen bypass those calls
entirely, assuming that the underlying driver will do so. See the ppp driver as
an example, it does an skb_pull to add a header to the skb, so multiple
iterations of the multi-skb case will result in stacked header inadvertently.
Another example is the virtio_net driver, which uses the skb->cb area to store
information that would get corrupted in the process. Neither of those would
pass through the dev_hard_start_xmit path and would be left uncovered by this
solution.
We could fix that by:
a) having pktgen call dev_hard_start_xmit for all frames, giving rise to the
performance issue I was bringing up in my last note.
b) augmenting each driver to check for the flag in the skb as you describe,
which in my mind is no better than having a flag in the netdevice informing
pktgen of weather or not it can use a shared skb approach.
> Only layering devices will end up eventually calling into those two
> functions and trigger the "need to copy because this SKB is pktgen
> shared" check.
>
See above, that doesn't solve the entire problem.
Regards
Neil
^ permalink raw reply
* Re: [PATCH] net/fec: gasket needs to be enabled for some i.mx
From: Shawn Guo @ 2011-07-22 2:00 UTC (permalink / raw)
To: Grant Likely
Cc: netdev, s.hauer, troy.kisky, u.kleine-koenig, shawn.guo,
David Miller, linux-arm-kernel, LW
In-Reply-To: <20110708000638.GC12722@S2100-06.ap.freescale.net>
On Fri, Jul 08, 2011 at 08:06:39AM +0800, Shawn Guo wrote:
> On Thu, Jul 07, 2011 at 12:44:09PM -0600, Grant Likely wrote:
> > On Thu, Jul 07, 2011 at 09:41:58PM +0800, Shawn Guo wrote:
> > > On Thu, Jul 07, 2011 at 04:12:57AM -0700, David Miller wrote:
> > > > From: Shawn Guo <shawn.guo@linaro.org>
> > > > Date: Fri, 1 Jul 2011 18:11:22 +0800
> > > >
> > > > > On the recent i.mx (mx25/50/53), there is a gasket inside fec
> > > > > controller which needs to be enabled no matter phy works in MII
> > > > > or RMII mode.
> > > > >
> > > > > The current code enables the gasket only when phy interface is RMII.
> > > > > It's broken when the driver works with a MII phy. The patch uses
> > > > > platform_device_id to distinguish the SoCs that have the gasket and
> > > > > enables it on these SoCs for both MII and RMII mode.
> > > > >
> > > > > Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > >
> > > > Acked-by: David S. Miller <davem@davemloft.net>
> > > > --
> > >
> > > Thanks, David. I will try to get it through Sascha's tree after
> > > the rebase again dt series.
> > >
> > > Hi Sascha,
> > >
> > > How should we proceed? It seems Grant will take the fec-dt series
> > > on his tree. Would you then merge that tree into yours, so that I
> > > can rebase this patch on your tree and get it go through there?
> >
> > I should probably just take the lot.
> >
> Thanks, Grant. That makes people's life easier. Please let me know
> once you apply the dt series, so that I can start rebase the patch on
> your tree.
>
I think I should repost the patch together with the device tree support
one when Grant's devicetree/next and i.mx tree get merged on mainline
in the coming merge window, and get them through Sascha's tree, so that
we can avoid conflicts there.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH v2 0/3] Add device tree probe support for imx fec driver
From: Shawn Guo @ 2011-07-22 2:08 UTC (permalink / raw)
To: David Miller
Cc: grant.likely, netdev, devicetree-discuss, shawn.guo,
linux-arm-kernel, patches
In-Reply-To: <20110705.232252.897826991160254269.davem@davemloft.net>
On Tue, Jul 05, 2011 at 11:22:52PM -0700, David Miller wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Wed, 6 Jul 2011 00:19:01 -0600
>
> > Sorry about that, I missed the reference to that function which is
> > currently in my devicetree/next branch. I can either take the series
> > via devicetree/next, or I can provide you with a topic branch
> > containing the needed commit that you can merge. Whichever you prefer.
>
> Please just take the series, thanks.
>
I think the easier way is that I repost the series after
devicetree/next and i.mx tree get merged in the coming window, and
let them go through i.mx tree.
David, I assume I can add your acks to all 3 patches, otherwise
please let me know.
--
Regards,
Shawn
^ permalink raw reply
* [net-next 00/10][pull request] Intel Wired LAN Driver Update
From: Jeff Kirsher @ 2011-07-22 2:01 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
The following series contains updates to e1000, igb and ixgbe.
The following are changes since commit 557e2a394de0d142ba930ff3cdb2909419414e06:
stmmac: improve and up-to-date the documentation
and are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
Alexander Duyck (5):
ixgbe: Update ATR to use recorded TX queues instead of CPU for
routing
ixgbe: inline the ixgbe_maybe_stop_tx function
ixgbe: add structure for containing RX/TX rings to q_vector
ixgbe: Move interrupt related values out of ring and into q_vector
ixgbe: Pass staterr instead of re-reading status and error bits from
descriptor
Andy Gospodarek (1):
ixgbe: only enable WoL for magic packet by default
Don Skidmore (1):
ixgbe: convert to ndo_fix_features
Emil Tantilov (1):
ixgbe: remove ifdef check for non-existent define
Nicolas Schichan (1):
e1000: always call e1000_check_for_link() on e1000_ce4100 MACs.
Robert Healy (1):
igb: Fix for DH89xxCC near end loopback test
drivers/net/e1000/e1000_main.c | 11 +-
drivers/net/igb/e1000_defines.h | 10 +
drivers/net/igb/igb_ethtool.c | 33 +++
drivers/net/ixgbe/ixgbe.h | 50 ++--
drivers/net/ixgbe/ixgbe_ethtool.c | 200 +---------------
drivers/net/ixgbe/ixgbe_fcoe.c | 35 +---
drivers/net/ixgbe/ixgbe_main.c | 480 +++++++++++++++++++------------------
7 files changed, 338 insertions(+), 481 deletions(-)
--
1.7.6
^ permalink raw reply
* [net-next 01/10] e1000: always call e1000_check_for_link() on e1000_ce4100 MACs.
From: Jeff Kirsher @ 2011-07-22 2:01 UTC (permalink / raw)
To: davem; +Cc: Nicolas Schichan, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1311300078-12876-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Nicolas Schichan <nschichan@freebox.fr>
Interrupts about link lost or rx sequence errors are not reported by
the ce4100 hardware, leading to transitions from link UP to link DOWN
never being reported.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000_main.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index acaebec..f97afda 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2402,13 +2402,16 @@ bool e1000_has_link(struct e1000_adapter *adapter)
struct e1000_hw *hw = &adapter->hw;
bool link_active = false;
- /* get_link_status is set on LSC (link status) interrupt or
- * rx sequence error interrupt. get_link_status will stay
- * false until the e1000_check_for_link establishes link
- * for copper adapters ONLY
+ /* get_link_status is set on LSC (link status) interrupt or rx
+ * sequence error interrupt (except on intel ce4100).
+ * get_link_status will stay false until the
+ * e1000_check_for_link establishes link for copper adapters
+ * ONLY
*/
switch (hw->media_type) {
case e1000_media_type_copper:
+ if (hw->mac_type == e1000_ce4100)
+ hw->get_link_status = 1;
if (hw->get_link_status) {
e1000_check_for_link(hw);
link_active = !hw->get_link_status;
--
1.7.6
^ 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