* [PATCH V2] ipv6: fix race condition regarding dst->expires and dst->from.
From: YOSHIFUJI Hideaki @ 2013-02-20 10:29 UTC (permalink / raw)
To: Eric Dumazet, Neil Horman, Gao Feng, netdev, davem; +Cc: yoshfuji
In-Reply-To: <5124A48F.3060907@linux-ipv6.org>
Eric Dumazet wrote:
| Some strange crashes happen in rt6_check_expired(), with access
| to random addresses.
|
| At first glance, it looks like the RTF_EXPIRES and
| stuff added in commit 1716a96101c49186b
| (ipv6: fix problem with expired dst cache)
| are racy : same dst could be manipulated at the same time
| on different cpus.
|
| At some point, our stack believes rt->dst.from contains a dst pointer,
| while its really a jiffie value (as rt->dst.expires shares the same area
| of memory)
|
| rt6_update_expires() should be fixed, or am I missing something ?
|
| CC Neil because of https://bugzilla.redhat.com/show_bug.cgi?id=892060
Because we do not have any locks for dst_entry, we cannot change
essential structure in the entry; e.g., we cannot change reference
to other entity.
To fix this issue, split 'from' and 'expires' field in dst_entry
out of union. Once it is 'from' is assigned in the constructor,
keep the reference until the very last stage of the life time of
the object.
Of course, it is unsafe to change 'from', so make rt6_set_from simple
just for fresh entries.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Reported-by: Neil Horman <nhorman@tuxdriver.com>
CC: Gao Feng <gaofeng@cn.fujitsu.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
include/net/dst.h | 8 ++------
include/net/ip6_fib.h | 39 ++++++++++++---------------------------
net/core/dst.c | 1 +
net/ipv6/route.c | 8 +++-----
4 files changed, 18 insertions(+), 38 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index 3da47e0..853cda1 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -36,13 +36,9 @@ struct dst_entry {
struct net_device *dev;
struct dst_ops *ops;
unsigned long _metrics;
- union {
- unsigned long expires;
- /* point to where the dst_entry copied from */
- struct dst_entry *from;
- };
+ unsigned long expires;
struct dst_entry *path;
- void *__pad0;
+ struct dst_entry *from;
#ifdef CONFIG_XFRM
struct xfrm_state *xfrm;
#else
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 6919a50..2a601e7 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -164,50 +164,35 @@ static inline struct inet6_dev *ip6_dst_idev(struct dst_entry *dst)
static inline void rt6_clean_expires(struct rt6_info *rt)
{
- if (!(rt->rt6i_flags & RTF_EXPIRES) && rt->dst.from)
- dst_release(rt->dst.from);
-
rt->rt6i_flags &= ~RTF_EXPIRES;
- rt->dst.from = NULL;
}
static inline void rt6_set_expires(struct rt6_info *rt, unsigned long expires)
{
- if (!(rt->rt6i_flags & RTF_EXPIRES) && rt->dst.from)
- dst_release(rt->dst.from);
-
- rt->rt6i_flags |= RTF_EXPIRES;
rt->dst.expires = expires;
+ rt->rt6i_flags |= RTF_EXPIRES;
}
-static inline void rt6_update_expires(struct rt6_info *rt, int timeout)
+static inline void rt6_update_expires(struct rt6_info *rt0, int timeout)
{
- if (!(rt->rt6i_flags & RTF_EXPIRES)) {
- if (rt->dst.from)
- dst_release(rt->dst.from);
- /* dst_set_expires relies on expires == 0
- * if it has not been set previously.
- */
- rt->dst.expires = 0;
- }
-
- dst_set_expires(&rt->dst, timeout);
- rt->rt6i_flags |= RTF_EXPIRES;
+ struct rt6_info *rt;
+
+ for (rt = rt0; rt && !(rt->rt6i_flags & RTF_EXPIRES);
+ rt = (struct rt6_info *)rt->dst.from);
+ if (rt && rt != rt0)
+ rt0->dst.expires = rt->dst.expires;
+
+ dst_set_expires(&rt0->dst, timeout);
+ rt0->rt6i_flags |= RTF_EXPIRES;
}
static inline void rt6_set_from(struct rt6_info *rt, struct rt6_info *from)
{
struct dst_entry *new = (struct dst_entry *) from;
- if (!(rt->rt6i_flags & RTF_EXPIRES) && rt->dst.from) {
- if (new == rt->dst.from)
- return;
- dst_release(rt->dst.from);
- }
-
rt->rt6i_flags &= ~RTF_EXPIRES;
- rt->dst.from = new;
dst_hold(new);
+ rt->dst.from = new;
}
static inline void ip6_rt_put(struct rt6_info *rt)
diff --git a/net/core/dst.c b/net/core/dst.c
index ee6153e..35fd12f 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -179,6 +179,7 @@ void *dst_alloc(struct dst_ops *ops, struct net_device *dev,
dst_init_metrics(dst, dst_default_metrics, true);
dst->expires = 0UL;
dst->path = dst;
+ dst->from = NULL;
#ifdef CONFIG_XFRM
dst->xfrm = NULL;
#endif
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 515bb51..9282665 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -287,6 +287,7 @@ static void ip6_dst_destroy(struct dst_entry *dst)
{
struct rt6_info *rt = (struct rt6_info *)dst;
struct inet6_dev *idev = rt->rt6i_idev;
+ struct dst_entry *from = dst->from;
if (!(rt->dst.flags & DST_HOST))
dst_destroy_metrics_generic(dst);
@@ -296,8 +297,8 @@ static void ip6_dst_destroy(struct dst_entry *dst)
in6_dev_put(idev);
}
- if (!(rt->rt6i_flags & RTF_EXPIRES) && dst->from)
- dst_release(dst->from);
+ dst->from = NULL;
+ dst_release(from);
if (rt6_has_peer(rt)) {
struct inet_peer *peer = rt6_peer_ptr(rt);
@@ -1010,7 +1011,6 @@ struct dst_entry *ip6_blackhole_route(struct net *net, struct dst_entry *dst_ori
rt->rt6i_gateway = ort->rt6i_gateway;
rt->rt6i_flags = ort->rt6i_flags;
- rt6_clean_expires(rt);
rt->rt6i_metric = 0;
memcpy(&rt->rt6i_dst, &ort->rt6i_dst, sizeof(struct rt6key));
@@ -1784,8 +1784,6 @@ static struct rt6_info *ip6_rt_copy(struct rt6_info *ort,
if ((ort->rt6i_flags & (RTF_DEFAULT | RTF_ADDRCONF)) ==
(RTF_DEFAULT | RTF_ADDRCONF))
rt6_set_from(rt, ort);
- else
- rt6_clean_expires(rt);
rt->rt6i_metric = 0;
#ifdef CONFIG_IPV6_SUBTREES
--
1.7.9.5
^ permalink raw reply related
* RE: [RFC PATCH] ipv6: Split from and expires field in dst_entry out of union [net-next]
From: David Laight @ 2013-02-20 10:55 UTC (permalink / raw)
To: Neil Horman, netdev; +Cc: eric.dumazet, David Miller, Gao feng, Jiri Bohac
In-Reply-To: <1361305694-8303-1-git-send-email-nhorman@tuxdriver.com>
> static inline void rt6_clean_expires(struct rt6_info *rt)
> {
> - if (!(rt->rt6i_flags & RTF_EXPIRES) && rt->dst.from)
> + if (!rt->rt6i_flags & RTF_EXPIRES)
> dst_release(rt->dst.from);
>
> rt->rt6i_flags &= ~RTF_EXPIRES;
> rt->dst.from = NULL;
> + rt->dst.expires = 0;
> }
>
> static inline void rt6_set_expires(struct rt6_info *rt, unsigned long expires)
> {
> - if (!(rt->rt6i_flags & RTF_EXPIRES) && rt->dst.from)
> + if (!rt->rt6i_flags & RTF_EXPIRES)
> dst_release(rt->dst.from);
>
> rt->rt6i_flags |= RTF_EXPIRES;
> + rt->dst.from = NULL;
> rt->dst.expires = expires;
> }
>
> static inline void rt6_update_expires(struct rt6_info *rt, int timeout)
> {
> if (!(rt->rt6i_flags & RTF_EXPIRES)) {
> - if (rt->dst.from)
> - dst_release(rt->dst.from);
> + dst_release(rt->dst.from);
> /* dst_set_expires relies on expires == 0
> * if it has not been set previously.
> */
> rt->dst.expires = 0;
> + rt6->dst.from = NULL;
> }
Aren't there also problems with setting and clearing RTF_EXPIRES?
Since that flag looks as though it was the descriminant for the union
it probably isn't needed - provided dst.expires is never 0 when valid.
David
^ permalink raw reply
* Problem with Reaktek 8168
From: Ralf Friedl @ 2013-02-20 11:52 UTC (permalink / raw)
To: netdev
Hi
I have a problem with the Reaktek 8168 on two Asus mainboards, the M5A97
LE R2.0 and the M5A97 EVO R2.0.
Sporadically, but especially when I transmit larger amounts of data, the
driver stops receiving packets from the network. I can verify with
tcpdump that packets sent from the driver reach the network, but packets
(answers) sent from the network don't read the driver.
I have opensuse 12.2 installed on both systems. With the supplied r8169
driver, this effect would happen within a few seconds when transferring
large files between two systems with gigabit ethernet. I the found and
compiled the r8168 driver. With this driver it is much better, but it
happens occasionally anyway. I can fix this by reloading the driver, or
by rebinding the driver with
echo 0000:02:00.0 > /sys/bus/pci/drivers/r8168/unbind
echo 0000:02:00.0 > /sys/bus/pci/drivers/r8168/bind
So to me it seems to be a software issue, especially as this happens on
two different boards. Unfortunately both reloading and rebinding take a
few seconds to reestablish the network link, and first it is necessary
to detect that the driver can't receive packets any more.
Is this a known problem?
If so, is there a known way to fix it?
If not, what additional information can I provide to fix it? Are there
any interesting debug settings?
Is there as a workaround a faster way to reinitialize the driver?
If it helps I can also run a custom driver with additional debug code.
Regards
Ralf Friedl
Additional information:
modinfo r8168 (downloaded from the Realtek site):
filename:
/lib/modules/3.4.28-2.20-default/kernel/drivers/net/ethernet/realtek/r8168.ko
version: 8.035.00-NAPI
license: GPL
description: RealTek RTL-8168 Gigabit Ethernet driver
author: Realtek and the Linux r8168 crew <netdev@vger.kernel.org>
srcversion: C7041A3D9074A1575512C13
alias: pci:v00001186d00004300sv00001186sd00004B10bc*sc*i*
alias: pci:v000010ECd00008168sv*sd*bc*sc*i*
depends:
vermagic: 3.4.28-2.20-default SMP mod_unload modversions
parm: eee_enable:int
parm: speed:force phy operation. Deprecated by ethtool (8).
(ushort)
parm: duplex:force phy operation. Deprecated by ethtool (8). (int)
parm: autoneg:force phy operation. Deprecated by ethtool (8).
(int)
parm: aspm:Enable ASPM. (int)
parm: rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: debug:Debug verbosity level (0=none, ..., 16=all) (int)
modinfo r8169 (from opensuse):
filename:
/lib/modules/3.4.28-2.20-default/kernel/drivers/net/ethernet/realtek/r8169.ko
firmware: rtl_nic/rtl8168f-2.fw
firmware: rtl_nic/rtl8168f-1.fw
firmware: rtl_nic/rtl8105e-1.fw
firmware: rtl_nic/rtl8168e-3.fw
firmware: rtl_nic/rtl8168e-2.fw
firmware: rtl_nic/rtl8168e-1.fw
firmware: rtl_nic/rtl8168d-2.fw
firmware: rtl_nic/rtl8168d-1.fw
version: 2.3LK-NAPI
license: GPL
description: RealTek RTL-8169 Gigabit Ethernet driver
author: Realtek and the Linux r8169 crew <netdev@vger.kernel.org>
srcversion: 193CB90A8A79025AB5CC132
alias: pci:v00000001d00008168sv*sd00002410bc*sc*i*
alias: pci:v00001737d00001032sv*sd00000024bc*sc*i*
alias: pci:v000016ECd00000116sv*sd*bc*sc*i*
alias: pci:v00001259d0000C107sv*sd*bc*sc*i*
alias: pci:v00001186d00004302sv*sd*bc*sc*i*
alias: pci:v00001186d00004300sv*sd*bc*sc*i*
alias: pci:v000010ECd00008169sv*sd*bc*sc*i*
alias: pci:v000010ECd00008168sv*sd*bc*sc*i*
alias: pci:v000010ECd00008167sv*sd*bc*sc*i*
alias: pci:v000010ECd00008136sv*sd*bc*sc*i*
alias: pci:v000010ECd00008129sv*sd*bc*sc*i*
depends:
intree: Y
vermagic: 3.4.28-2.20-default SMP mod_unload modversions
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: debug:Debug verbosity level (0=none, ..., 16=all) (int)
Asus M5A97 LE R2.0 lspci:
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168] (rev 09)
Subsystem: ASUSTeK Computer Inc. P8H77-I Motherboard [1043:8505]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort+ <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 81
Region 0: I/O ports at d000 [size=256]
Region 2: Memory at d2104000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at d2100000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000feeff00c Data: 416a
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB,
EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-,
LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
No end tag found
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+
ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-00-00-00-68-4c-e0-00
Kernel driver in use: r8168
Asus M5A97 EVO R2.0 lspci:
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168] (rev 09)
Subsystem: ASUSTeK Computer Inc. P8H77-I Motherboard [1043:8505]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort+ <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 90
Region 0: I/O ports at e000 [size=256]
Region 2: Memory at fea04000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at fea00000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000feeff00c Data: 41b2
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB,
EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-,
LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
No end tag found
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+
ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-00-00-00-68-4c-e0-00
Kernel driver in use: r8168
Differences between LE and EVO:
--- M5A97 LE
+++ M5A97 EVO
@@ -3,15 +3,15 @@
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort+ <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
- Interrupt: pin A routed to IRQ 81
- Region 0: I/O ports at d000 [size=256]
- Region 2: Memory at d2104000 (64-bit, prefetchable) [size=4K]
- Region 4: Memory at d2100000 (64-bit, prefetchable) [size=16K]
+ Interrupt: pin A routed to IRQ 90
+ Region 0: I/O ports at e000 [size=256]
+ Region 2: Memory at fea04000 (64-bit, prefetchable) [size=4K]
+ Region 4: Memory at fea00000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
- Address: 00000000feeff00c Data: 416a
+ Address: 00000000feeff00c Data: 41b2
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
@@ -40,7 +40,7 @@
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
- CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
+ CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+
ChkEn-
Capabilities: [140 v1] Virtual Channel
^ permalink raw reply
* Re: [RFC PATCH] ipv6: Split from and expires field in dst_entry out of union [net-next]
From: Neil Horman @ 2013-02-20 12:02 UTC (permalink / raw)
To: David Laight; +Cc: netdev, eric.dumazet, David Miller, Gao feng, Jiri Bohac
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7157@saturn3.aculab.com>
On Wed, Feb 20, 2013 at 10:55:35AM -0000, David Laight wrote:
> > static inline void rt6_clean_expires(struct rt6_info *rt)
> > {
> > - if (!(rt->rt6i_flags & RTF_EXPIRES) && rt->dst.from)
> > + if (!rt->rt6i_flags & RTF_EXPIRES)
> > dst_release(rt->dst.from);
> >
> > rt->rt6i_flags &= ~RTF_EXPIRES;
> > rt->dst.from = NULL;
> > + rt->dst.expires = 0;
> > }
> >
> > static inline void rt6_set_expires(struct rt6_info *rt, unsigned long expires)
> > {
> > - if (!(rt->rt6i_flags & RTF_EXPIRES) && rt->dst.from)
> > + if (!rt->rt6i_flags & RTF_EXPIRES)
> > dst_release(rt->dst.from);
> >
> > rt->rt6i_flags |= RTF_EXPIRES;
> > + rt->dst.from = NULL;
> > rt->dst.expires = expires;
> > }
> >
> > static inline void rt6_update_expires(struct rt6_info *rt, int timeout)
> > {
> > if (!(rt->rt6i_flags & RTF_EXPIRES)) {
> > - if (rt->dst.from)
> > - dst_release(rt->dst.from);
> > + dst_release(rt->dst.from);
> > /* dst_set_expires relies on expires == 0
> > * if it has not been set previously.
> > */
> > rt->dst.expires = 0;
> > + rt6->dst.from = NULL;
> > }
>
> Aren't there also problems with setting and clearing RTF_EXPIRES?
> Since that flag looks as though it was the descriminant for the union
> it probably isn't needed - provided dst.expires is never 0 when valid.
>
> David
The use of RTF_EXPIRES is weak at this point, if there are multiple accessors,
but I think the point is moot, in that the only thing we ever do when we change
the flag is release dst.from, which is safe.
Neil
^ permalink raw reply
* RE: [RFC PATCH] ipv6: Split from and expires field in dst_entry out of union [net-next]
From: David Laight @ 2013-02-20 12:08 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, eric.dumazet, David Miller, Gao feng, Jiri Bohac
In-Reply-To: <20130220120225.GA14501@hmsreliant.think-freely.org>
> > Aren't there also problems with setting and clearing RTF_EXPIRES?
> > Since that flag looks as though it was the descriminant for the union
> > it probably isn't needed - provided dst.expires is never 0 when valid.
> >
> > David
>
> The use of RTF_EXPIRES is weak at this point, if there are multiple accessors,
> but I think the point is moot, in that the only thing we ever do when we change
> the flag is release dst.from, which is safe.
>
> Neil
I was also worried about the RMW cycles of rt6i_flags itself.
David
^ permalink raw reply
* Re: AW: ixgbe: Regression, unsupported SFP+ modules on 10Gbit/s X520 NIC no longer work with allow_unsupported_sfp=1
From: Jeff Kirsher @ 2013-02-20 13:39 UTC (permalink / raw)
To: Stefan Behte
Cc: Tantilov, Emil S, netdev@vger.kernel.org, Skidmore, Donald C,
Fujinaka, Todd, Ronciak, John, Boom, Douglas
In-Reply-To: <D76AF9B3DDF5FF49833AC0A1396549060314FC0C@s554.babiel.com>
[-- Attachment #1: Type: text/plain, Size: 11390 bytes --]
On Mon, 2013-02-18 at 04:13 -0800, Stefan Behte wrote:
> Hi,
>
> >I don't think this is a regression since the check you are bypassing with your patch has nothing to do with the unsupported SFP modules lock (this check is few lines below).
> No, that part skipped by the goto.
>
> >The check you are trying to bypass is actually for supported 1gig SFP module types.
> Actually that's inaccurate: if it's not a compatible module, it's being marked as unsupported. That's the whole purpose of that code.
>
> //if it's not a 10GE Module
> if (comp_codes_10g == 0 &&
>
> // and if the current module is NOT compatible (hw->phy.sfp_type must be 9, 10, 11 or 12, see ixgbe_type.h)
> !(hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core1 ||
> hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core0 ||
> hw->phy.sfp_type == ixgbe_sfp_type_1g_sx_core0 ||
> hw->phy.sfp_type == ixgbe_sfp_type_1g_sx_core1)) {
>
> // then mark hardware as unsupported -> the SFP will not be enabled
> // but it should be, if allow_unsupported_sfp=1
> hw->phy.type = ixgbe_phy_sfp_unsupported;
> status = IXGBE_ERR_SFP_NOT_SUPPORTED;
>
> // skip other stuff, e.g. the checks you mentioned below
> goto out;
> }
>
> Ok, my patch is not nice. I've attached one that completely removes the block, as IMHO its only purpose is to lock out non-intel SFPs. Of course I've verified that the code works (at least for me :)).
>
> >1. What is the SFP+ module you are using (make/model/type)?
> The module is a TP-Link TL-SM311LS 1000BASE-LX LC.
>
> >2. What is the hw->phy.sfp_type set to (you can add a printk, or if you plug it in after load there should be a "detected SFP+" message in dmesg).
> It's in the log I sent:
> [13920.949008] ixgbe 0000:02:00.1: MAC: 2, PHY: 14, SFP+: 65535, PBA No: E68793-005
> So hw->phy.sfp_type is 65535.
>
> >3. You said that you get the interfaces, but are they operational (link, pass traffic etc)?
> I'm going to run some longterm tests for reliability. But yes, they appear to be working just fine.
>
> >4. Because you mentioned that this is a regression - was there a previous version of the driver that loads without the unsupported errors with this SFP module?
> Not sure, but as a result of the discussion (http://marc.info/?l=e1000-devel&m=132697406314730&w=2) there was a decision and patch that would allow non-intel SFPs.
> So I don't care too much what we call this - the driver does not work as intended: Intel is preventing use of 3rd-party SFPs.
>
> So can we please remove this lock-in?
>
> Best regards,
> Stefan Behte
>
> --------------------------------------------
>
> Stefan Behte
> Teamleiter Systemadministration
>
> Babiel GmbH
> Erkrather Str. 224a
> D-40233 Düsseldorf
>
> Tel: 0211-179349 0
> Fax: 0211-179349 29
> E-Mail: s.behte@babiel.com
> Internet: http://www.babiel.com
>
> Geschäftsführer: Georg Babiel, Dr. Rainer Babiel, Harald Babiel Amtsgericht Düsseldorf HRB 38633
>
> ~~~~~~~~~~~~~~ DISCLAIMER ~~~~~~~~~~~~~~~
>
> The information transmitted in this electronic mail message may contain confidential and or privileged materials. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive such e-mails in error, please contact the sender and delete the material from any computer.
>
>
> -----Ursprüngliche Nachricht-----
> Von: Tantilov, Emil S [mailto:emil.s.tantilov@intel.com]
> Gesendet: Freitag, 15. Februar 2013 21:14
> An: Stefan Behte; netdev@vger.kernel.org
> Cc: Skidmore, Donald C; Kirsher, Jeffrey T; Fujinaka, Todd; Ronciak, John
> Betreff: RE: ixgbe: Regression, unsupported SFP+ modules on 10Gbit/s X520 NIC no longer work with allow_unsupported_sfp=1
>
> Stefan,
>
> I don't think this is a regression since the check you are bypassing with your patch has nothing to do with the unsupported SFP modules lock (this check is few lines below). The check you are trying to bypass is actually for supported 1gig SFP module types. Could you provide some additional information about your setup?
>
> 1. What is the SFP+ module you are using (make/model/type)?
> 2. What is the hw->phy.sfp_type set to (you can add a printk, or if you plug it in after load there should be a "detected SFP+" message in dmesg).
> 3. You said that you get the interfaces, but are they operational (link, pass traffic etc)?
> 4. Because you mentioned that this is a regression - was there a previous version of the driver that loads without the unsupported errors with this SFP module?
>
> Thanks,
> Emil
>
> >-----Original Message-----
> >From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> >Behalf Of Stefan Behte
> >Sent: Thursday, February 14, 2013 4:58 PM
> >To: netdev@vger.kernel.org
> >Subject: ixgbe: Regression, unsupported SFP+ modules on 10Gbit/s X520 NIC
> >no longer work with allow_unsupported_sfp=1
> >
> >Hello,
> >
> >I was told to send a mail, even though I had already opened
> >https://bugzilla.kernel.org/show_bug.cgi?id=53901.
> >
> >Someone patched the ixgbe driver, and now non-intel SFPs do not work
> >anymore, again. The issue of intel "lock-in" was discussed before here:
> >http://marc.info/?l=e1000-devel&m=132697406314730&w=2
> >
> >A tested patch is attached.
> >
> >Here is what I do:
> >
> ># modinfo ixgbe | grep parm
> >parm: max_vfs:Maximum number of virtual functions to allocate per
> >physical function - default is zero and maximum value is 63 (uint)
> >parm: allow_unsupported_sfp:Allow unsupported and untested SFP+
> >modules on 82599-based adapters (uint)
> >parm: debug:Debug level (0=none,...,16=all) (int)
> >
> ># modprobe -r ixgbe
> ># modprobe ixgbe allow_unsupported_sfp=0
> ># dmesg | grep ixgbe
> >[13690.355090] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver -
> >version 3.9.15-k
> >[13690.355092] ixgbe: Copyright (c) 1999-2012 Intel Corporation.
> >[13690.373128] ixgbe 0000:02:00.0: failed to load because an unsupported
> >SFP+ module type was detected.
> >[13690.373177] ixgbe 0000:02:00.0: Reload the driver after installing a
> >supported module.
> >[13690.390987] ixgbe 0000:02:00.1: failed to load because an unsupported
> >SFP+ module type was detected.
> >[13690.391036] ixgbe 0000:02:00.1: Reload the driver after installing a
> >supported module.
> >
> ># modprobe -r ixgbe
> ># modprobe ixgbe allow_unsupported_sfp=1
> ># dmesg | grep ixgbe
> >[13679.088849] dca service started, version 1.12.1
> >[13679.091174] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver -
> >version 3.9.15-k
> >[13679.091177] ixgbe: Copyright (c) 1999-2012 Intel Corporation.
> >[13679.109194] ixgbe 0000:02:00.0: failed to load because an unsupported
> >SFP+ module type was detected.
> >[13679.109243] ixgbe 0000:02:00.0: Reload the driver after installing a
> >supported module.
> >[13679.127399] ixgbe 0000:02:00.1: failed to load because an unsupported
> >SFP+ module type was detected.
> >[13679.127450] ixgbe 0000:02:00.1: Reload the driver after installing a
> >supported module.
> >[13690.352712] dca service started, version 1.12.1
> >
> >
> >With the patch:
> >
> ># modprobe -r ixgbe
> ># modprobe ixgbe allow_unsupported_sfp=0
> ># dmesg | grep ixgbe
> >[13907.870087] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver -
> >version 3.9.15-k
> >[13907.870089] ixgbe: Copyright (c) 1999-2012 Intel Corporation.
> >[13907.888106] ixgbe 0000:02:00.0: failed to load because an unsupported
> >SFP+ module type was detected.
> >[13907.888155] ixgbe 0000:02:00.0: Reload the driver after installing a
> >supported module.
> >[13907.906187] ixgbe 0000:02:00.1: failed to load because an unsupported
> >SFP+ module type was detected.
> >[13907.906237] ixgbe 0000:02:00.1: Reload the driver after installing a
> >supported module.
> >
> >
> ># modprobe -r ixgbe
> ># modprobe ixgbe allow_unsupported_sfp=1
> ># dmesg | grep ixgbe
> >[13914.534758] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver -
> >version3.9.15-k
> >[13914.534761] ixgbe: Copyright (c) 1999-2012 Intel Corporation.
> >[13914.552820] ixgbe 0000:02:00.0 (unregistered net_device): WARNING: Intel
> >(R) Network Connections are quality tested using Intel (R) Ethernet Optics.
> >Using untested modules is not supported and may cause unstable operation or
> >damage to
> >the module or the adapter. Intel Corporation is not responsible for any
> >harm caused by using untested modules.
> >[13917.741931] ixgbe 0000:02:00.0: irq 50 for MSI/MSI-X
> >[13917.741938] ixgbe 0000:02:00.0: irq 51 for MSI/MSI-X
> >[13917.741942] ixgbe 0000:02:00.0: irq 52 for MSI/MSI-X
> >[13917.741951] ixgbe 0000:02:00.0: irq 53 for MSI/MSI-X
> >[13917.741955] ixgbe 0000:02:00.0: irq 54 for MSI/MSI-X
> >[13917.741960] ixgbe 0000:02:00.0: irq 55 for MSI/MSI-X
> >[13917.741965] ixgbe 0000:02:00.0: irq 56 for MSI/MSI-X
> >[13917.741969] ixgbe 0000:02:00.0: irq 57 for MSI/MSI-X
> >[13917.741973] ixgbe 0000:02:00.0: irq 58 for MSI/MSI-X
> >[13917.742002] ixgbe 0000:02:00.0: Multiqueue Enabled: Rx Queue count = 8,
> >Tx Queue count = 8
> >[13917.742126] ixgbe 0000:02:00.0: (PCI Express:5.0GT/s:Width x8)
> >90:e2:ba:37:3b:18
> >[13917.742207] ixgbe 0000:02:00.0: MAC: 2, PHY: 14, SFP+: 65535, PBA No:
> >E68793-005
> >[13917.743461] ixgbe 0000:02:00.0: Intel(R) 10 Gigabit Network Connection
> >[13917.761578] ixgbe 0000:02:00.1 (unregistered net_device): WARNING: Intel
> >(R) Network Connections are quality tested using Intel (R) Ethernet Optics.
> >Using untested modules is not supported and may cause unstable operation or
> >damage to the module or the adapter. Intel Corporation is not responsible
> >for any harm caused by using untested modules.
> >[13920.948726] ixgbe 0000:02:00.1: irq 59 for MSI/MSI-X
> >[13920.948737] ixgbe 0000:02:00.1: irq 60 for MSI/MSI-X
> >[13920.948742] ixgbe 0000:02:00.1: irq 61 for MSI/MSI-X
> >[13920.948746] ixgbe 0000:02:00.1: irq 62 for MSI/MSI-X
> >[13920.948751] ixgbe 0000:02:00.1: irq 63 for MSI/MSI-X
> >[13920.948757] ixgbe 0000:02:00.1: irq 64 for MSI/MSI-X
> >[13920.948761] ixgbe 0000:02:00.1: irq 65 for MSI/MSI-X
> >[13920.948767] ixgbe 0000:02:00.1: irq 66 for MSI/MSI-X
> >[13920.948774] ixgbe 0000:02:00.1: irq 67 for MSI/MSI-X
> >[13920.948803] ixgbe 0000:02:00.1: Multiqueue Enabled: Rx Queue count = 8,
> >Tx Queue count = 8
> >[13920.948927] ixgbe 0000:02:00.1: (PCI Express:5.0GT/s:Width x8)
> >90:e2:ba:37:3b:19
> >[13920.949008] ixgbe 0000:02:00.1: MAC: 2, PHY: 14, SFP+: 65535, PBA No:
> >E68793-005
> >[13920.950237] ixgbe 0000:02:00.1: Intel(R) 10 Gigabit Network Connection
> >
> >And then I get two nice Interfaces. Please apply. :)
> >
> >
> >Best regards,
> >
> >Stefan Behte
> >
Stefan,
We are currently working on the resolution to your issue. I have also
added your patch to my queue of ixgbe patches.
Cheers,
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH net-next v2 1/2] ip_gre: allow CSUM capable devices to handle packets
From: Dmitry Kravkov @ 2013-02-20 14:45 UTC (permalink / raw)
To: pravin; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <CANvJab0xqZhj9TDZOQKtqvDjLu4ez7MrocWY3FaBw28Nxc-Qdg@mail.gmail.com>
> -----Original Message-----
> From: pravin [mailto:pravin.shelar@gmail.com]
> Sent: Wednesday, February 20, 2013 1:04 AM
> To: Dmitry Kravkov
> Cc: davem@davemloft.net; netdev@vger.kernel.org
> Subject: Re: [PATCH net-next v2 1/2] ip_gre: allow CSUM capable devices to
> handle packets
>
> On Tue, Feb 19, 2013 at 11:20 AM, Dmitry Kravkov <dmitry@broadcom.com>
> wrote:
> >
> >> -----Original Message-----
> >> From: pravin [mailto:pravin.shelar@gmail.com]
> >> Sent: Tuesday, February 19, 2013 8:28 PM
> >> To: Dmitry Kravkov
> >> Cc: davem@davemloft.net; netdev@vger.kernel.org
> >> Subject: Re: [PATCH net-next v2 1/2] ip_gre: allow CSUM capable devices to
> >> handle packets
> >>
> >> On Mon, Feb 18, 2013 at 11:50 AM, Dmitry Kravkov <dmitry@broadcom.com>
> >> wrote:
> >> > If device is not able to handle checksumming it will
> >> > be handled in dev_xmit
> >> >
> >> > Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> >> > ---
> >> > Changes from v1: fixed email address
> >> >
> >> > net/ipv4/ip_gre.c | 7 ++-----
> >> > 1 files changed, 2 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> >> > index a56f118..cdc31ac 100644
> >> > --- a/net/ipv4/ip_gre.c
> >> > +++ b/net/ipv4/ip_gre.c
> >> > @@ -745,12 +745,9 @@ static struct sk_buff *handle_offloads(struct sk_buff
> >> *skb)
> >> > goto error;
> >> > skb_shinfo(skb)->gso_type |= SKB_GSO_GRE;
> >> > return skb;
> >> > - } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
> >> > - err = skb_checksum_help(skb);
> >> > - if (unlikely(err))
> >> > - goto error;
> >> > }
> >> > - skb->ip_summed = CHECKSUM_NONE;
> >> > + if (skb->ip_summed != CHECKSUM_PARTIAL)
> >> > + skb->ip_summed = CHECKSUM_NONE;
> >> >
> >> > return skb;
> >> >
> >> > --
> >> > 1.7.7.2
> >> >
> >> >
> >>
> >> This patch breaks GRE tunnel with GRE_CSUM. since GRE_CSUM need
> >> complete IP packet to checksum entire GRE payload.
> >
> > Testing for o_flags&GRE_CSUM does not look too hurt here, since it will be
> used in ipgre_tunnel_xmit() later on
> > This is the only problematic case, right?
> >
>
> It does not work for me. I have GRE device with csum on. Ping works
> fine but Netperf is not working.
I will test this mode also ...
> Looking at code, I am not sure how tcp will work if inner packet TCP
> checksum is calculated after GRE_CSUM calculation.
Not sure if there is HW that supports it today
> Thanks,
> Pravin.
^ permalink raw reply
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Eric Dumazet @ 2013-02-20 15:11 UTC (permalink / raw)
To: Johannes Berg
Cc: Marc MERLIN, David Miller, Larry.Finger, bhutchings,
linux-wireless, netdev
In-Reply-To: <1361351703.8629.5.camel@jlt4.sipsolutions.net>
On Wed, 2013-02-20 at 10:15 +0100, Johannes Berg wrote:
> OTOH, this affects the protocol, and when you really can't allocate any
> order-1 pages you pointed out yourself that many other things also won't
> work, so I'm not really sure it makes a big difference if we change the
> driver?
It will make a huge difference, even on non pressure mode, as TCP
receive window will grow twice faster.
Unless wifi speed reaches 10Gbps, following patch should do the trick
diff --git a/drivers/net/wireless/iwlwifi/dvm/rx.c b/drivers/net/wireless/iwlwifi/dvm/rx.c
index a4eed20..77a3ee3 100644
--- a/drivers/net/wireless/iwlwifi/dvm/rx.c
+++ b/drivers/net/wireless/iwlwifi/dvm/rx.c
@@ -750,7 +750,12 @@ static void iwlagn_pass_packet_to_mac80211(struct iwl_priv *priv,
/* Dont use dev_alloc_skb(), we'll have enough headroom once
* ieee80211_hdr pulled.
*/
- skb = alloc_skb(128, GFP_ATOMIC);
+ fraglen = 128;
+ /* if we use order-1 pages, copy to get better TCP performance */
+ if (rxb->truesize > PAGE_SIZE)
+ fraglen = max_t(unsigned, fraglen, len);
+
+ skb = alloc_skb(fraglen, GFP_ATOMIC);
if (!skb) {
IWL_ERR(priv, "alloc_skb failed\n");
return;
^ permalink raw reply related
* Re: [PATCH] b43: Increase number of RX DMA slots
From: Larry Finger @ 2013-02-20 15:49 UTC (permalink / raw)
To: Gábor Stefanik, Julian Calaby, David Miller, David.Laight,
linville, linux-wireless, netdev, stable, openwrt-devel
In-Reply-To: <20130220081538.GO8730@medion.lan>
[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]
On 02/20/2013 02:15 AM, Bastian Bittorf wrote:
> * Larry Finger <Larry.Finger@lwfinger.net> [20.02.2013 08:32]:
>> On 02/20/2013 12:26 AM, Gábor Stefanik wrote:
>>>
>>> Is this an issue that vendor drivers are also vulnerable to? If it is
>>> a firmware issue, I would certainly think so.
>>
>> I also think so, at least if they are using the firmware version that
>> Bastian is using. His logs don't have that info in them, but I
>> certainly saw the problem on my BCM4312 using firmware 508.154 from
>> 2009.
>
> Another test this morning with heavy downloading (but tcp only)
> show slot usage auf max 204/256. we are using firmware
>
> "version 666.2 (2011-02-23 01:15:07)" which is OpenWrt's default
> for b43. see here the full logs, including minstrel output and dmesg:
>
> http://intercity-vpn.de/files/openwrt/b43test2.dmesg.txt
>
> if a slot needs ~2500 bytes, so 256 slot are only 640kb which seems
> ok to me. ofcourse it raises the memory consumption by 500kb, but now
> the router is useful 8-)
Thanks for the testing and the report. The skb associated with each slot is
allocated at 2390 bytes, but I think each allocation is a minimum of one page.
In any case, using extra memory is much better than having the device freeze
without explanation. I do not think there is any newer firmware for the 4318
than the version you are using.
I have reworked the patch that resets on overflow, and added the section for
64-bit DMA. I still need to test that part, but I am sending two patches to you
for testing on the WRT54G. The first renames a couple of register names to make
32- and 64-bit naming to only differ in the number. The second is the reset code
patch.
Larry
[-- Attachment #2: b43_rename_B43_DMA64_RXSTAT --]
[-- Type: text/plain, Size: 1968 bytes --]
Index: wireless-testing-new/drivers/net/wireless/b43/dma.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/b43/dma.c
+++ wireless-testing-new/drivers/net/wireless/b43/dma.c
@@ -476,7 +476,7 @@ static int b43_dmacontroller_rx_reset(st
break;
}
} else {
- value &= B43_DMA32_RXSTATE;
+ value &= B43_DMA32_RXSTAT;
if (value == B43_DMA32_RXSTAT_DISABLED) {
i = -1;
break;
@@ -513,7 +513,7 @@ static int b43_dmacontroller_tx_reset(st
value == B43_DMA64_TXSTAT_STOPPED)
break;
} else {
- value &= B43_DMA32_TXSTATE;
+ value &= B43_DMA32_TXSTAT;
if (value == B43_DMA32_TXSTAT_DISABLED ||
value == B43_DMA32_TXSTAT_IDLEWAIT ||
value == B43_DMA32_TXSTAT_STOPPED)
@@ -534,7 +534,7 @@ static int b43_dmacontroller_tx_reset(st
break;
}
} else {
- value &= B43_DMA32_TXSTATE;
+ value &= B43_DMA32_TXSTAT;
if (value == B43_DMA32_TXSTAT_DISABLED) {
i = -1;
break;
Index: wireless-testing-new/drivers/net/wireless/b43/dma.h
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/b43/dma.h
+++ wireless-testing-new/drivers/net/wireless/b43/dma.h
@@ -27,7 +27,7 @@
#define B43_DMA32_TXINDEX 0x08
#define B43_DMA32_TXSTATUS 0x0C
#define B43_DMA32_TXDPTR 0x00000FFF
-#define B43_DMA32_TXSTATE 0x0000F000
+#define B43_DMA32_TXSTAT 0x0000F000
#define B43_DMA32_TXSTAT_DISABLED 0x00000000
#define B43_DMA32_TXSTAT_ACTIVE 0x00001000
#define B43_DMA32_TXSTAT_IDLEWAIT 0x00002000
@@ -52,7 +52,7 @@
#define B43_DMA32_RXINDEX 0x18
#define B43_DMA32_RXSTATUS 0x1C
#define B43_DMA32_RXDPTR 0x00000FFF
-#define B43_DMA32_RXSTATE 0x0000F000
+#define B43_DMA32_RXSTAT 0x0000F000
#define B43_DMA32_RXSTAT_DISABLED 0x00000000
#define B43_DMA32_RXSTAT_ACTIVE 0x00001000
#define B43_DMA32_RXSTAT_IDLEWAIT 0x00002000
[-- Attachment #3: b43_workaround_RX_buffer_overflow --]
[-- Type: text/plain, Size: 4684 bytes --]
Index: drivers/net/wireless/b43/dma.c
===================================================================
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1689,6 +1692,31 @@
sync_descbuffer_for_device(ring, dmaaddr, ring->rx_buffersize);
}
+static int dma_rx_check_overflow(struct b43_dmaring *ring)
+{
+ u32 state;
+ u32 rxctl;
+
+ if (ring->type != B43_DMA_32BIT)
+ return 0;
+
+ state = b43_dma_read(ring, B43_DMA32_RXSTATUS) & B43_DMA32_RXSTATE;
+ if (state != B43_DMA32_RXSTAT_IDLEWAIT)
+ return 0;
+
+ rxctl = b43_dma_read(ring, B43_DMA32_RXCTL);
+ b43_dmacontroller_rx_reset(ring->dev, ring->mmio_base, ring->type);
+
+ b43_dma_write(ring, B43_DMA32_RXCTL, rxctl);
+ b43_dma_write(ring, B43_DMA32_RXINDEX, ring->nr_slots *
+ sizeof(struct b43_dmadesc32));
+ ring->current_slot = 0;
+
+ printk("DMA RX reset due to overflow\n");
+
+ return 1;
+}
+
void b43_dma_rx(struct b43_dmaring *ring)
{
const struct b43_dma_ops *ops = ring->ops;
@@ -1700,6 +1728,18 @@
B43_WARN_ON(!(current_slot >= 0 && current_slot < ring->nr_slots));
slot = ring->current_slot;
+
+ /* XXX: BRCM4318(?) dirty workaround:
+ * it seems sometimes the RX ring overflows due to interrupt latencies;
+ * i.e. skb allocations are slow on routers with high CPU load
+ * and tight memory constraints */
+ if (slot == current_slot) {
+ /* Try to reset the RX channel, will cost us few lost frames,
+ * but will recover from an eternal stall */
+ if (dma_rx_check_overflow(ring))
+ return;
+ }
+
for (; slot != current_slot; slot = next_slot(ring, slot)) {
dma_rx(ring, &slot);
update_max_used_slots(ring, ++used_slots);
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c
+++ wireless-testing/drivers/net/wireless/b43/dma.c
@@ -1692,6 +1692,50 @@ drop_recycle_buffer:
sync_descbuffer_for_device(ring, dmaaddr, ring->rx_buffersize);
}
+/* check for overflow of the RX descriptor ring. If found, reset the DMA
+ * controller and return true.
+ */
+static bool dma_rx_check_overflow(struct b43_dmaring *ring)
+{
+ if (ring->type == B43_DMA_64BIT) {
+ u64 state;
+ u64 rxctl;
+
+ state = b43_dma_read(ring, B43_DMA64_RXSTATUS) &
+ B43_DMA64_RXSTAT;
+ if (state != B43_DMA64_RXSTAT_IDLEWAIT)
+ return false;
+ rxctl = b43_dma_read(ring, B43_DMA64_RXCTL);
+ b43_dmacontroller_rx_reset(ring->dev, ring->mmio_base,
+ ring->type);
+
+ b43_dma_write(ring, B43_DMA64_RXCTL, rxctl);
+ b43_dma_write(ring, B43_DMA64_RXINDEX, ring->nr_slots *
+ sizeof(struct b43_dmadesc64));
+ } else {
+ u32 state;
+ u32 rxctl;
+
+ state = b43_dma_read(ring, B43_DMA32_RXSTATUS) &
+ B43_DMA32_RXSTAT;
+ if (state != B43_DMA32_RXSTAT_IDLEWAIT)
+ return false;
+
+ rxctl = b43_dma_read(ring, B43_DMA32_RXCTL);
+ b43_dmacontroller_rx_reset(ring->dev, ring->mmio_base,
+ ring->type);
+
+ b43_dma_write(ring, B43_DMA32_RXCTL, rxctl);
+ b43_dma_write(ring, B43_DMA32_RXINDEX, ring->nr_slots *
+ sizeof(struct b43_dmadesc32));
+ }
+ ring->current_slot = 0;
+
+ b43err(ring->dev->wl, "DMA RX reset due to overflow\n");
+
+ return true;
+}
+
void b43_dma_rx(struct b43_dmaring *ring)
{
const struct b43_dma_ops *ops = ring->ops;
@@ -1703,7 +1747,21 @@ void b43_dma_rx(struct b43_dmaring *ring
B43_WARN_ON(!(current_slot >= 0 && current_slot < ring->nr_slots));
slot = ring->current_slot;
- for (; slot != current_slot; slot = next_slot(ring, slot)) {
+
+ /* XXX: BRCM4318(?) dirty workaround:
+ * it seems sometimes the RX ring overflows due to interrupt
+ * latencies; particularly for systems with slow CPUs and tight
+ * memory constraints
+ */
+ if (slot == current_slot) {
+ /* Try to reset the RX channel, will cost us few lost frames,
+ * but will recover from an eternal stall
+ */
+ if (dma_rx_check_overflow(ring))
+ return; /* exit on overflow and reset */
+ }
+
+ for (; slot != current_slot; slot = next_slot(ring, slot)) {
dma_rx(ring, &slot);
update_max_used_slots(ring, ++used_slots);
}
^ permalink raw reply
* [PATCH 1/3] sctp: fix association hangs due to reassembly/ordering logic
From: Roberts, Lee A. @ 2013-02-20 15:54 UTC (permalink / raw)
To: linux-sctp@vger.kernel.org, netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <1361374860.3450.1.camel@laptop.lroberts>
From: Lee A. Roberts <lee.roberts@hp.com>
Resolve SCTP association hangs observed during SCTP stress
testing. Observable symptoms include communications hangs
with data being held in the association lobby (ordering)
queue. Close examination of reassembly/ordering queues shows
duplicated packets.
In sctp_tsnmap_grow(), correct off-by-one errors when copying
and resizing the tsnmap. If max_tsn_seen is in the LSB of the
word, this bit can be lost, causing the corresponding packet
to be transmitted again and to be entered as a duplicate into
the SCTP reassembly/ordering queues.
Patch applies to linux-3.8 kernel.
Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
---
net/sctp/tsnmap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff -uprN -X linux-3.8-vanilla/Documentation/dontdiff
linux-3.8-vanilla/net/sctp/tsnmap.c linux-3.8-SCTP+1/net/sctp/tsnmap.c
--- linux-3.8-vanilla/net/sctp/tsnmap.c 2013-02-18 16:58:34.000000000
-0700
+++ linux-3.8-SCTP+1/net/sctp/tsnmap.c 2013-02-20 08:01:02.555223259
-0700
@@ -369,14 +369,15 @@ static int sctp_tsnmap_grow(struct sctp_
if (gap >= SCTP_TSN_MAP_SIZE)
return 0;
- inc = ALIGN((gap - map->len),BITS_PER_LONG) + SCTP_TSN_MAP_INCREMENT;
+ inc = ALIGN((gap - map->len + 1), BITS_PER_LONG)
+ + SCTP_TSN_MAP_INCREMENT;
len = min_t(u16, map->len + inc, SCTP_TSN_MAP_SIZE);
new = kzalloc(len>>3, GFP_ATOMIC);
if (!new)
return 0;
- bitmap_copy(new, map->tsn_map, map->max_tsn_seen - map->base_tsn);
+ bitmap_copy(new, map->tsn_map, map->max_tsn_seen - map->base_tsn + 1);
kfree(map->tsn_map);
map->tsn_map = new;
map->len = len;
^ permalink raw reply
* [PATCH 2/3] sctp: fix association hangs due to reassembly/ordering logic
From: Roberts, Lee A. @ 2013-02-20 15:55 UTC (permalink / raw)
To: linux-sctp@vger.kernel.org, netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <1361374925.3450.2.camel@laptop.lroberts>
From: Lee A. Roberts <lee.roberts@hp.com>
Resolve SCTP association hangs observed during SCTP stress
testing. Observable symptoms include communications hangs
with data being held in the association reassembly and/or lobby
(ordering) queues. Close examination of reassembly queue shows
missing packets.
In sctp_ulpq_renege_list(), do not renege packets below the
cumulative TSN ACK point. Events being reneged from the
ordering queue may correspond to multiple TSNs; identify
and renege all affected packets from the tsnmap.
Patch applies to linux-3.8 kernel.
Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
---
net/sctp/ulpqueue.c | 30 +++++++++++++++++++++++++-----
1 file changed, 25 insertions(+), 5 deletions(-)
diff -uprN -X linux-3.8-vanilla/Documentation/dontdiff linux-3.8-SCTP
+1/net/sctp/ulpqueue.c linux-3.8-SCTP+2/net/sctp/ulpqueue.c
--- linux-3.8-SCTP+1/net/sctp/ulpqueue.c 2013-02-18 16:58:34.000000000
-0700
+++ linux-3.8-SCTP+2/net/sctp/ulpqueue.c 2013-02-20 08:17:53.679233365
-0700
@@ -962,20 +962,40 @@ static __u16 sctp_ulpq_renege_list(struc
struct sk_buff_head *list, __u16 needed)
{
__u16 freed = 0;
- __u32 tsn;
- struct sk_buff *skb;
+ __u32 tsn, last_tsn;
+ struct sk_buff *skb, *flist, *last;
struct sctp_ulpevent *event;
struct sctp_tsnmap *tsnmap;
tsnmap = &ulpq->asoc->peer.tsn_map;
- while ((skb = __skb_dequeue_tail(list)) != NULL) {
- freed += skb_headlen(skb);
+ while ((skb = skb_peek_tail(list)) != NULL) {
event = sctp_skb2event(skb);
tsn = event->tsn;
+ /* Don't renege below the Cumulative TSN ACK Point. */
+ if (TSN_lte(tsn, sctp_tsnmap_get_ctsn(tsnmap)))
+ break;
+
+ /* Events in ordering queue may have multiple fragments
+ * corresponding to additional TSNs. Find the last one.
+ */
+ flist = skb_shinfo(skb)->frag_list;
+ for (last = flist; flist; flist = flist->next)
+ last = flist;
+ if (last)
+ last_tsn = sctp_skb2event(last)->tsn;
+ else
+ last_tsn = tsn;
+
+ /* Unlink the event, then renege all applicable TSNs. */
+ __skb_unlink(skb, list);
+ freed += skb_headlen(skb);
sctp_ulpevent_free(event);
- sctp_tsnmap_renege(tsnmap, tsn);
+ while (TSN_lte(tsn, last_tsn)) {
+ sctp_tsnmap_renege(tsnmap, tsn);
+ tsn++;
+ }
if (freed >= needed)
return freed;
}
^ permalink raw reply
* [PATCH 3/3] sctp: fix association hangs due to reassembly/ordering logic
From: Roberts, Lee A. @ 2013-02-20 15:56 UTC (permalink / raw)
To: linux-sctp@vger.kernel.org, netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <1361374996.3450.3.camel@laptop.lroberts>
From: Lee A. Roberts <lee.roberts@hp.com>
Resolve SCTP association hangs observed during SCTP stress
testing. Observable symptoms include communications hangs
with data being held in the association reassembly and/or lobby
(ordering) queues. Close examination of reassembly queue shows
missing packets.
In sctp_eat_data(), enter partial delivery mode only if the
data on the head of the reassembly queue is at or before the
cumulative TSN ACK point.
In sctp_ulpq_retrieve_partial() and sctp_ulpq_retrieve_first(),
correct message reassembly logic for SCTP partial delivery.
Change logic to ensure that as much data as possible is sent
with the initial partial delivery and that following partial
deliveries contain all available data.
In sctp_ulpq_renege(), adjust logic to enter partial delivery
only if the incoming chunk remains on the reassembly queue
after processing by sctp_ulpq_tail_data(). Remove call to
sctp_tsnmap_mark(), as this is handled correctly in call to
sctp_ulpq_tail_data().
Patch applies to linux-3.8 kernel.
Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
---
net/sctp/sm_statefuns.c | 12 ++++++++++--
net/sctp/ulpqueue.c | 33 ++++++++++++++++++++++++++-------
2 files changed, 36 insertions(+), 9 deletions(-)
diff -uprN -X linux-3.8-vanilla/Documentation/dontdiff linux-3.8-SCTP
+2/net/sctp/sm_statefuns.c linux-3.8-SCTP+3/net/sctp/sm_statefuns.c
--- linux-3.8-SCTP+2/net/sctp/sm_statefuns.c 2013-02-18
16:58:34.000000000 -0700
+++ linux-3.8-SCTP+3/net/sctp/sm_statefuns.c 2013-02-20
08:31:51.092132884 -0700
@@ -6090,7 +6090,8 @@ static int sctp_eat_data(const struct sc
size_t datalen;
sctp_verb_t deliver;
int tmp;
- __u32 tsn;
+ __u32 tsn, ctsn;
+ struct sk_buff *skb;
struct sctp_tsnmap *map = (struct sctp_tsnmap *)&asoc->peer.tsn_map;
struct sock *sk = asoc->base.sk;
struct net *net = sock_net(sk);
@@ -6160,7 +6161,14 @@ static int sctp_eat_data(const struct sc
/* Even if we don't accept this chunk there is
* memory pressure.
*/
- sctp_add_cmd_sf(commands, SCTP_CMD_PART_DELIVER, SCTP_NULL());
+ skb = skb_peek(&asoc->ulpq.reasm);
+ if (skb != NULL) {
+ ctsn = sctp_skb2event(skb)->tsn;
+ if (TSN_lte(ctsn,
+ sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map)))
+ sctp_add_cmd_sf(commands,
+ SCTP_CMD_PART_DELIVER, SCTP_NULL());
+ }
}
/* Spill over rwnd a little bit. Note: While allowed, this spill over
diff -uprN -X linux-3.8-vanilla/Documentation/dontdiff linux-3.8-SCTP
+2/net/sctp/ulpqueue.c linux-3.8-SCTP+3/net/sctp/ulpqueue.c
--- linux-3.8-SCTP+2/net/sctp/ulpqueue.c 2013-02-20 08:17:53.679233365
-0700
+++ linux-3.8-SCTP+3/net/sctp/ulpqueue.c 2013-02-20 08:27:02.785042744
-0700
@@ -540,14 +540,19 @@ static struct sctp_ulpevent *sctp_ulpq_r
ctsn = cevent->tsn;
switch (cevent->msg_flags & SCTP_DATA_FRAG_MASK) {
+ case SCTP_DATA_FIRST_FRAG:
+ if (!first_frag)
+ return NULL;
+ goto done;
case SCTP_DATA_MIDDLE_FRAG:
if (!first_frag) {
first_frag = pos;
next_tsn = ctsn + 1;
last_frag = pos;
- } else if (next_tsn == ctsn)
+ } else if (next_tsn == ctsn) {
next_tsn++;
- else
+ last_frag = pos;
+ } else
goto done;
break;
case SCTP_DATA_LAST_FRAG:
@@ -651,6 +656,14 @@ static struct sctp_ulpevent *sctp_ulpq_r
} else
goto done;
break;
+
+ case SCTP_DATA_LAST_FRAG:
+ if (!first_frag)
+ return NULL;
+ else
+ goto done;
+ break;
+
default:
return NULL;
}
@@ -1054,6 +1067,7 @@ void sctp_ulpq_renege(struct sctp_ulpq *
gfp_t gfp)
{
struct sctp_association *asoc;
+ struct sk_buff *skb;
__u16 needed, freed;
asoc = ulpq->asoc;
@@ -1074,12 +1088,17 @@ void sctp_ulpq_renege(struct sctp_ulpq *
}
/* If able to free enough room, accept this chunk. */
if (chunk && (freed >= needed)) {
- __u32 tsn;
+ __u32 tsn, ctsn;
tsn = ntohl(chunk->subh.data_hdr->tsn);
- sctp_tsnmap_mark(&asoc->peer.tsn_map, tsn, chunk->transport);
- sctp_ulpq_tail_data(ulpq, chunk, gfp);
-
- sctp_ulpq_partial_delivery(ulpq, gfp);
+ if (sctp_ulpq_tail_data(ulpq, chunk, gfp) == 0) {
+ skb = skb_peek(&ulpq->reasm);
+ if (skb != NULL) {
+ ctsn = sctp_skb2event(skb)->tsn;
+ if (TSN_lte(ctsn, tsn))
+ sctp_ulpq_partial_delivery(ulpq, chunk,
+ gfp);
+ }
+ }
}
sk_mem_reclaim(asoc->base.sk);
^ permalink raw reply
* Re: [PATCHv2 vringh 1/3] remoteproc: Add support for vringh (Host vrings)
From: Ohad Ben-Cohen @ 2013-02-20 16:05 UTC (permalink / raw)
To: Sjur Brændeland
Cc: Dmitry Tarnyagin, Sjur Brændeland, Linus Walleij, Ido Yariv,
linux-kernel@vger.kernel.org, Erwan Yvin, virtualization, netdev,
David S. Miller
In-Reply-To: <1360669793-6921-2-git-send-email-sjur.brandeland@stericsson.com>
Hi Sjur,
On Tue, Feb 12, 2013 at 1:49 PM, <sjur.brandeland@stericsson.com> wrote:
> From: Sjur Brændeland <sjur.brandeland@stericsson.com>
>
> Add functions for creating, deleting and kicking host-side virtio rings.
>
> The host ring is not integrated with virtiqueues and cannot be managed
> through virtio-config.
Is that an inherent design/issue of vringh or just a description of
the current vringh code ?
> Remoteproc must export functions for handling the host-side virtio rings.
Have you considered exporting this via virtio instead ?
> The functions rproc_virtio_get_vringh(), rproc_virtio_del_vringh(),
> rproc_virtio_kick_vringh() are added to remoteproc_virtio.c.
I wonder if this is the way we want things to work.
Following this design, virtio drivers that use these rproc_* functions
will be coupled with the remoteproc framework.
One issue with this is what happens if, e.g., a VIRTIO_ID_CAIF vdev is
added by other than remoteproc (e.g. by virtio_pci or virtio_mmio).
Not sure how probable this really is, and whether there's anything
that prevents this, but things will go awry if this happens.
But maybe the important aspect to consider is whether we really want
to couple virtio drivers (such as the upcoming caif one) with the
remoteproc framework.
If you'll take a look at the rpmsg virtio driver, there's nothing
there which couples it with remoteproc. It's just a standard virtio
driver, that can be easily used with traditional virtio hosts as well.
This is possible of course thanks to the abstraction provided by
virtio: remoteproc only implements a set of callbacks which virtio
invokes when needed.
Do we not want to follow a similar design scheme with vringh ?
I have some other questions as well but maybe it's better to discuss
first the bigger picture.
Thanks!
Ohad.
^ permalink raw reply
* Re: [PATCH V2] ipv6: fix race condition regarding dst->expires and dst->from.
From: Eric Dumazet @ 2013-02-20 16:12 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Neil Horman, Gao Feng, netdev, davem, Steinar H. Gunderson
In-Reply-To: <5124A574.5030904@linux-ipv6.org>
On Wed, 2013-02-20 at 19:29 +0900, YOSHIFUJI Hideaki wrote:
> Eric Dumazet wrote:
> | Some strange crashes happen in rt6_check_expired(), with access
> | to random addresses.
> |
> | At first glance, it looks like the RTF_EXPIRES and
> | stuff added in commit 1716a96101c49186b
> | (ipv6: fix problem with expired dst cache)
> | are racy : same dst could be manipulated at the same time
> | on different cpus.
> |
> | At some point, our stack believes rt->dst.from contains a dst pointer,
> | while its really a jiffie value (as rt->dst.expires shares the same area
> | of memory)
> |
> | rt6_update_expires() should be fixed, or am I missing something ?
> |
> | CC Neil because of https://bugzilla.redhat.com/show_bug.cgi?id=892060
>
> Because we do not have any locks for dst_entry, we cannot change
> essential structure in the entry; e.g., we cannot change reference
> to other entity.
>
> To fix this issue, split 'from' and 'expires' field in dst_entry
> out of union. Once it is 'from' is assigned in the constructor,
> keep the reference until the very last stage of the life time of
> the object.
>
> Of course, it is unsafe to change 'from', so make rt6_set_from simple
> just for fresh entries.
>
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Reported-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Gao Feng <gaofeng@cn.fujitsu.com>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> ---
This seems good to me, but I cant test it at this moment.
I CC Steinar as he reported one crash to me.
Thanks Yoshifuji !
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reported-by: Steinar H. Gunderson <sesse@google.com>
^ permalink raw reply
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Johannes Berg @ 2013-02-20 16:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Marc MERLIN, David Miller, Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1361373064.19353.180.camel@edumazet-glaptop>
On Wed, 2013-02-20 at 07:11 -0800, Eric Dumazet wrote:
> On Wed, 2013-02-20 at 10:15 +0100, Johannes Berg wrote:
>
> > OTOH, this affects the protocol, and when you really can't allocate any
> > order-1 pages you pointed out yourself that many other things also won't
> > work, so I'm not really sure it makes a big difference if we change the
> > driver?
>
> It will make a huge difference, even on non pressure mode, as TCP
> receive window will grow twice faster.
Hmm, why does that depend on the allocation size?
> Unless wifi speed reaches 10Gbps, following patch should do the trick
>
>
> diff --git a/drivers/net/wireless/iwlwifi/dvm/rx.c b/drivers/net/wireless/iwlwifi/dvm/rx.c
> index a4eed20..77a3ee3 100644
> --- a/drivers/net/wireless/iwlwifi/dvm/rx.c
> +++ b/drivers/net/wireless/iwlwifi/dvm/rx.c
> @@ -750,7 +750,12 @@ static void iwlagn_pass_packet_to_mac80211(struct iwl_priv *priv,
> /* Dont use dev_alloc_skb(), we'll have enough headroom once
> * ieee80211_hdr pulled.
> */
> - skb = alloc_skb(128, GFP_ATOMIC);
> + fraglen = 128;
> + /* if we use order-1 pages, copy to get better TCP performance */
> + if (rxb->truesize > PAGE_SIZE)
> + fraglen = max_t(unsigned, fraglen, len);
> +
> + skb = alloc_skb(fraglen, GFP_ATOMIC);
Hmm, I don't quite understand -- that's not doing any copy?
FWIW if you do the copy you should not "steal" the pages, then they'd be
recycled in the RX ring right away.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* Re: [PATCH V2] ipv6: fix race condition regarding dst->expires and dst->from.
From: Neil Horman @ 2013-02-20 16:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: YOSHIFUJI Hideaki, Gao Feng, netdev, davem, Steinar H. Gunderson
In-Reply-To: <1361376760.19353.185.camel@edumazet-glaptop>
On Wed, Feb 20, 2013 at 08:12:40AM -0800, Eric Dumazet wrote:
> On Wed, 2013-02-20 at 19:29 +0900, YOSHIFUJI Hideaki wrote:
> > Eric Dumazet wrote:
> > | Some strange crashes happen in rt6_check_expired(), with access
> > | to random addresses.
> > |
> > | At first glance, it looks like the RTF_EXPIRES and
> > | stuff added in commit 1716a96101c49186b
> > | (ipv6: fix problem with expired dst cache)
> > | are racy : same dst could be manipulated at the same time
> > | on different cpus.
> > |
> > | At some point, our stack believes rt->dst.from contains a dst pointer,
> > | while its really a jiffie value (as rt->dst.expires shares the same area
> > | of memory)
> > |
> > | rt6_update_expires() should be fixed, or am I missing something ?
> > |
> > | CC Neil because of https://bugzilla.redhat.com/show_bug.cgi?id=892060
> >
> > Because we do not have any locks for dst_entry, we cannot change
> > essential structure in the entry; e.g., we cannot change reference
> > to other entity.
> >
> > To fix this issue, split 'from' and 'expires' field in dst_entry
> > out of union. Once it is 'from' is assigned in the constructor,
> > keep the reference until the very last stage of the life time of
> > the object.
> >
> > Of course, it is unsafe to change 'from', so make rt6_set_from simple
> > just for fresh entries.
> >
> > Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> > Reported-by: Neil Horman <nhorman@tuxdriver.com>
> > CC: Gao Feng <gaofeng@cn.fujitsu.com>
> > Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> > ---
>
> This seems good to me, but I cant test it at this moment.
>
> I CC Steinar as he reported one crash to me.
>
> Thanks Yoshifuji !
>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
>
> Reported-by: Steinar H. Gunderson <sesse@google.com>
>
I've also got requests in to test, and a recent fedora build running here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5036210
If anyone else wants to test it. Although, looking at it, I think this is a
good fix:
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
>
>
>
^ permalink raw reply
* Re: [PATCH 2/3] sctp: fix association hangs due to reassembly/ordering logic
From: Vlad Yasevich @ 2013-02-20 16:38 UTC (permalink / raw)
To: Roberts, Lee A.
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <D64EC45690EF85409BA6C4730E0162244310CBB5@G4W3231.americas.hpqcorp.net>
On 02/20/2013 10:55 AM, Roberts, Lee A. wrote:
> From: Lee A. Roberts <lee.roberts@hp.com>
>
> Resolve SCTP association hangs observed during SCTP stress
> testing. Observable symptoms include communications hangs
> with data being held in the association reassembly and/or lobby
> (ordering) queues. Close examination of reassembly queue shows
> missing packets.
>
> In sctp_ulpq_renege_list(), do not renege packets below the
> cumulative TSN ACK point. Events being reneged from the
> ordering queue may correspond to multiple TSNs; identify
> and renege all affected packets from the tsnmap.
>
> Patch applies to linux-3.8 kernel.
>
> Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
> ---
> net/sctp/ulpqueue.c | 30 +++++++++++++++++++++++++-----
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff -uprN -X linux-3.8-vanilla/Documentation/dontdiff linux-3.8-SCTP
> +1/net/sctp/ulpqueue.c linux-3.8-SCTP+2/net/sctp/ulpqueue.c
> --- linux-3.8-SCTP+1/net/sctp/ulpqueue.c 2013-02-18 16:58:34.000000000
> -0700
> +++ linux-3.8-SCTP+2/net/sctp/ulpqueue.c 2013-02-20 08:17:53.679233365
> -0700
> @@ -962,20 +962,40 @@ static __u16 sctp_ulpq_renege_list(struc
> struct sk_buff_head *list, __u16 needed)
> {
> __u16 freed = 0;
> - __u32 tsn;
> - struct sk_buff *skb;
> + __u32 tsn, last_tsn;
> + struct sk_buff *skb, *flist, *last;
> struct sctp_ulpevent *event;
> struct sctp_tsnmap *tsnmap;
>
> tsnmap = &ulpq->asoc->peer.tsn_map;
>
> - while ((skb = __skb_dequeue_tail(list)) != NULL) {
> - freed += skb_headlen(skb);
> + while ((skb = skb_peek_tail(list)) != NULL) {
> event = sctp_skb2event(skb);
> tsn = event->tsn;
>
> + /* Don't renege below the Cumulative TSN ACK Point. */
> + if (TSN_lte(tsn, sctp_tsnmap_get_ctsn(tsnmap)))
> + break;
> +
> + /* Events in ordering queue may have multiple fragments
> + * corresponding to additional TSNs. Find the last one.
> + */
> + flist = skb_shinfo(skb)->frag_list;
> + for (last = flist; flist; flist = flist->next)
> + last = flist;
> + if (last)
> + last_tsn = sctp_skb2event(last)->tsn;
> + else
> + last_tsn = tsn;
> +
> + /* Unlink the event, then renege all applicable TSNs. */
> + __skb_unlink(skb, list);
> + freed += skb_headlen(skb);
This is no longer correct. You are actually freeing more space if you
are reneging a reassembled event from the the ordered queue.
Please separate the 2 patches since they fix 2 distinct bugs.
Thanks
-vlad
> sctp_ulpevent_free(event);
> - sctp_tsnmap_renege(tsnmap, tsn);
> + while (TSN_lte(tsn, last_tsn)) {
> + sctp_tsnmap_renege(tsnmap, tsn);
> + tsn++;
> + }
> if (freed >= needed)
> return freed;
> }
>
> N�����r��y���b�X��ǧv�^�){.n�+����{���i�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+��ݢj"��!tml=
>
^ permalink raw reply
* Re: Kernel 3.7.2 strange warning and short system hang
From: Eric Dumazet @ 2013-02-20 16:52 UTC (permalink / raw)
To: Urban Loesch; +Cc: linux-kernel, netdev
In-Reply-To: <5124F57A.6080908@enas.net>
On Wed, 2013-02-20 at 17:10 +0100, Urban Loesch wrote:
> Hi,
>
> today I had a strange system hang on one of our new Dell PER620 machines.
> I'm running a self compiled kernel, version 3.7.2 with linux vserver patch included.
>
> uname -a
> Linux dbhost04 3.7.2-vs2.3.5.5-rol-em64t #4 SMP Sun Feb 3 14:08:37 CET 2013 x86_64 GNU/Linux
>
> 15min. systemload between 1-3.
>
>
> Today the system hangs for some seconds and I got the folling errors in syslog multiple times within one second:
>
> ...
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196338] WARNING: at net/core/skbuff.c:573 skb_release_head_state+0xed/0x100()
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196338] Hardware name: PowerEdge R620
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196352] Modules linked in: lru_cache netconsole configfs act_police cls_basic cls_flow cls_fw cls_u32
> sch_tbf sch_prio sch_hfsc sch_htb sch_ingress sch_sfq xt_statistic xt_CT xt_realm xt_LOG xt_c
> onnlimit iptable_raw xt_comment xt_nat xt_recent ipt_ULOG ipt_REJECT ipt_MASQUERADE ipt_ECN ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_sip nf_nat_pptp
> nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_conntrack_tftp nf_con
> ntrack_sane nf_conntrack_sip nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink
> nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc ts_kmp nf_conntrack_h323 nf_con
> ntrack_amanda nf_conntrack_ftp xt_TPROXY xt_time nf_tproxy_core xt_TCPMSS xt_tcpmss xt_sctp xt_policy xt_pkttype xt_NFLOG nfnetlink_log xt_physdev
> xt_owner xt_NFQUEUE xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt
> _hashlimit xt_DSCP xt_dscp xt_dccp xt_connmark xt_CLASSIFY iptable_nat nf_nat_ipv
> Feb 20 15:58:04 dbhost04 kernel: 4 nf_nat ip6t_REJECT nf_conntrack_ipv4 xt_tcpudp nf_defrag_ipv4 xt_state nf_conntrack_ipv6 nf_defrag_ipv6
> xt_conntrack nf_conntrack iptable_mangle ip6table_raw ip6table_mangle nfnetlink ip6table_filter ip
> 6_tables iptable_filter ip_tables x_tables ipmi_devintf ipmi_si ipmi_msghandler coretemp kvm_intel kvm ghash_clmulni_intel aesni_intel xts aes_x86_64
> lrw gf128mul ablk_helper cryptd iTCO_wdt iTCO_vendor_support dcdbas microcode pcspkr jo
> ydev lpc_ich shpchp hed evbug hid_generic usbhid hid ahci libahci megaraid_sas tg3 [last unloaded: drbd]
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196368] Pid: 10942, comm: mysqld Tainted: G W 3.7.2-vs2.3.5.5-rol-em64t #4
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196368] Call Trace:
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196370] <IRQ> [<ffffffff81053bff>] warn_slowpath_common+0x7f/0xc0
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196371] [<ffffffff81594c52>] ? skb_release_data+0xf2/0x110
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196372] [<ffffffff81053c5a>] warn_slowpath_null+0x1a/0x20
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196373] [<ffffffff81594e9d>] skb_release_head_state+0xed/0x100
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196374] [<ffffffff81594c86>] __kfree_skb+0x16/0xa0
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196375] [<ffffffff8159521c>] consume_skb+0x2c/0x80
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196379] [<ffffffffa000b0af>] tg3_poll_work+0x5ef/0xdb0 [tg3]
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196384] [<ffffffffa000b055>] ? tg3_poll_work+0x595/0xdb0 [tg3]
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196388] [<ffffffffa00145cf>] tg3_poll+0x7f/0x390 [tg3]
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196392] [<ffffffffa000b927>] ? tg3_poll_msix+0xb7/0x140 [tg3]
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196394] [<ffffffff815b9622>] netpoll_poll_dev+0x162/0x580
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196395] [<ffffffff815b9bcc>] netpoll_send_skb_on_dev+0x18c/0x3a0
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196398] [<ffffffff815ba0f7>] netpoll_send_udp+0x277/0x290
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196400] [<ffffffffa03ae91f>] write_msg+0xaf/0x100 [netconsole]
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196401] [<ffffffff81054959>] call_console_drivers.constprop.16+0x99/0x100
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196403] [<ffffffff810553b9>] console_unlock+0x3d9/0x420
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196404] [<ffffffff81055ca5>] vprintk_emit+0x255/0x510
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196406] [<ffffffff8169f0b9>] printk+0x61/0x63
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196407] [<ffffffff81031e8e>] therm_throt_process+0x13e/0x180
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196408] [<ffffffff81032066>] intel_thermal_interrupt+0x196/0x1a0
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196410] [<ffffffff810320c1>] smp_thermal_interrupt+0x21/0x40
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196411] [<ffffffff816b1a1a>] thermal_interrupt+0x6a/0x70
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196413] <EOI> [<ffffffff816b0e19>] ? system_call_fastpath+0x16/0x1b
> Feb 20 15:58:04 dbhost04 kernel: [1463997.196414] ---[ end trace e3ec69533a534ff5 ]---
> ...
>
> After the last message I got this entries in syslog, too:
> Feb 20 15:58:04 dbhost04 kernel: [1464001.755218] CPU18: Core power limit normal
> Feb 20 15:58:04 dbhost04 kernel: [1464001.760038] Clocksource tsc unstable (delta = 299966106527 ns)
> Feb 20 15:58:04 dbhost04 kernel: [1464001.769627] Switching to clocksource hpet
>
> I searched the archives for this error, but I can't find any solution.
> And my second PER620 doesn't show this error until now.
>
> Have you any idea what this problem could be?
>
> I'm not subscribed to lkml, if you need more information please contact me directly by email.
>
> Many thanks for your help.
> Urban
CC netdev
I guess tg3 needs to call dev_kfree_skb_any()
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index bdb0869..22d9e44 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -5942,7 +5942,7 @@ static void tg3_tx(struct tg3_napi *tnapi)
pkts_compl++;
bytes_compl += skb->len;
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
if (unlikely(tx_bug)) {
tg3_tx_recover(tp);
^ permalink raw reply related
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Eric Dumazet @ 2013-02-20 16:55 UTC (permalink / raw)
To: Johannes Berg
Cc: Marc MERLIN, David Miller, Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1361377243.8629.34.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
On Wed, 2013-02-20 at 17:20 +0100, Johannes Berg wrote:
> On Wed, 2013-02-20 at 07:11 -0800, Eric Dumazet wrote:
> > On Wed, 2013-02-20 at 10:15 +0100, Johannes Berg wrote:
> >
> > > OTOH, this affects the protocol, and when you really can't allocate any
> > > order-1 pages you pointed out yourself that many other things also won't
> > > work, so I'm not really sure it makes a big difference if we change the
> > > driver?
> >
> > It will make a huge difference, even on non pressure mode, as TCP
> > receive window will grow twice faster.
>
> Hmm, why does that depend on the allocation size?
I guess you missed all the patches about skb->truesize on netdev
>
> > Unless wifi speed reaches 10Gbps, following patch should do the trick
> >
> >
> > diff --git a/drivers/net/wireless/iwlwifi/dvm/rx.c b/drivers/net/wireless/iwlwifi/dvm/rx.c
> > index a4eed20..77a3ee3 100644
> > --- a/drivers/net/wireless/iwlwifi/dvm/rx.c
> > +++ b/drivers/net/wireless/iwlwifi/dvm/rx.c
> > @@ -750,7 +750,12 @@ static void iwlagn_pass_packet_to_mac80211(struct iwl_priv *priv,
> > /* Dont use dev_alloc_skb(), we'll have enough headroom once
> > * ieee80211_hdr pulled.
> > */
> > - skb = alloc_skb(128, GFP_ATOMIC);
> > + fraglen = 128;
> > + /* if we use order-1 pages, copy to get better TCP performance */
> > + if (rxb->truesize > PAGE_SIZE)
> > + fraglen = max_t(unsigned, fraglen, len);
> > +
> > + skb = alloc_skb(fraglen, GFP_ATOMIC);
>
> Hmm, I don't quite understand -- that's not doing any copy?
>
> FWIW if you do the copy you should not "steal" the pages, then they'd be
> recycled in the RX ring right away.
Code should just works, please read the following lines in the same
function....
/* If frame is small enough to fit in skb->head, pull it completely.
* If not, only pull ieee80211_hdr so that splice() or TCP coalesce
* are more efficient.
*/
hdrlen = (len <= skb_tailroom(skb)) ? len : sizeof(*hdr);
memcpy(skb_put(skb, hdrlen), hdr, hdrlen);
fraglen = len - hdrlen;
if (fraglen) {
int offset = (void *)hdr + hdrlen -
rxb_addr(rxb) + rxb_offset(rxb);
skb_add_rx_frag(skb, 0, rxb_steal_page(rxb), offset,
fraglen, rxb->truesize);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* why is it not allowed to add a new socket protocol family as an external module?
From: Chris Friesen @ 2013-02-20 16:56 UTC (permalink / raw)
To: netdev
Hi,
I was just wondering why the kernel doesn't allow a new network protocol
family to be loaded as as a kernel module built outside the kernel
source tree.
Most of the networking code would seem to allow this, but the check for
"if (ops->family >= NPROTO)" in sock_register() means that only protocol
families defined in socket.h can be registered.
Was this intentional for ideological reasons, or has nobody wanted to be
able to add arbitrary network protocols without patching the kernel and
rebuilding?
Thanks,
Chris
^ permalink raw reply
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Johannes Berg @ 2013-02-20 16:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: Marc MERLIN, David Miller, Larry.Finger, bhutchings,
linux-wireless, netdev
In-Reply-To: <1361379331.19353.189.camel@edumazet-glaptop>
On Wed, 2013-02-20 at 08:55 -0800, Eric Dumazet wrote:
> > > It will make a huge difference, even on non pressure mode, as TCP
> > > receive window will grow twice faster.
> >
> > Hmm, why does that depend on the allocation size?
>
> I guess you missed all the patches about skb->truesize on netdev
Yeah, I don't follow netdev much any more...
> > > - skb = alloc_skb(128, GFP_ATOMIC);
> > > + fraglen = 128;
> > > + /* if we use order-1 pages, copy to get better TCP performance */
> > > + if (rxb->truesize > PAGE_SIZE)
> > > + fraglen = max_t(unsigned, fraglen, len);
> > > +
> > > + skb = alloc_skb(fraglen, GFP_ATOMIC);
> >
> > Hmm, I don't quite understand -- that's not doing any copy?
> >
> > FWIW if you do the copy you should not "steal" the pages, then they'd be
> > recycled in the RX ring right away.
>
> Code should just works, please read the following lines in the same
> function....
>
> /* If frame is small enough to fit in skb->head, pull it completely.
> * If not, only pull ieee80211_hdr so that splice() or TCP coalesce
> * are more efficient.
> */
Oh, right, though I guess the comment is now wrong since practically
every packet will be copied either here or in mac80211 (A-MSDUs are
split up there)
johannes
^ permalink raw reply
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Johannes Berg @ 2013-02-20 17:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: Marc MERLIN, David Miller, Larry.Finger, bhutchings,
linux-wireless, netdev
In-Reply-To: <1361379331.19353.189.camel@edumazet-glaptop>
On Wed, 2013-02-20 at 08:55 -0800, Eric Dumazet wrote:
> > > Unless wifi speed reaches 10Gbps, following patch should do the trick
> > >
> > >
> > > diff --git a/drivers/net/wireless/iwlwifi/dvm/rx.c b/drivers/net/wireless/iwlwifi/dvm/rx.c
> > > index a4eed20..77a3ee3 100644
> > > --- a/drivers/net/wireless/iwlwifi/dvm/rx.c
> > > +++ b/drivers/net/wireless/iwlwifi/dvm/rx.c
> > > @@ -750,7 +750,12 @@ static void iwlagn_pass_packet_to_mac80211(struct iwl_priv *priv,
> > > /* Dont use dev_alloc_skb(), we'll have enough headroom once
> > > * ieee80211_hdr pulled.
> > > */
> > > - skb = alloc_skb(128, GFP_ATOMIC);
> > > + fraglen = 128;
> > > + /* if we use order-1 pages, copy to get better TCP performance */
> > > + if (rxb->truesize > PAGE_SIZE)
> > > + fraglen = max_t(unsigned, fraglen, len);
> > > +
> > > + skb = alloc_skb(fraglen, GFP_ATOMIC);
> >
> > Hmm, I don't quite understand -- that's not doing any copy?
> >
> > FWIW if you do the copy you should not "steal" the pages, then they'd be
> > recycled in the RX ring right away.
>
> Code should just works, please read the following lines in the same
> function....
FWIW, I think just using order-0 pages and turning 8k A-MSDUs off by
default makes more sense, A-MSDU is rarely used to begin with ...
Also, if we copy larger frames here, we should also take into account
the (variable) 802.11 header length to avoid copying into a position
where the IP header ends up being unaligned.
johannes
^ permalink raw reply
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Eric Dumazet @ 2013-02-20 17:24 UTC (permalink / raw)
To: Johannes Berg
Cc: Marc MERLIN, David Miller, Larry.Finger, bhutchings,
linux-wireless, netdev
In-Reply-To: <1361379686.8629.41.camel@jlt4.sipsolutions.net>
On Wed, 2013-02-20 at 18:01 +0100, Johannes Berg wrote:
> FWIW, I think just using order-0 pages and turning 8k A-MSDUs off by
> default makes more sense, A-MSDU is rarely used to begin with ...
>
My suggested patch makes sure that if someone needs 8k A-MSDU, iwlwifi
still works correctly.
> Also, if we copy larger frames here, we should also take into account
> the (variable) 802.11 header length to avoid copying into a position
> where the IP header ends up being unaligned.
But the current code already has this problem (if its a problem at all,
as on x86 NET_IP_ALIGN is 0)
I only increase available tailroom in the skb. Right now there is enough
room for IP and tcp headers.
^ permalink raw reply
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Eric Dumazet @ 2013-02-20 17:39 UTC (permalink / raw)
To: Johannes Berg
Cc: Marc MERLIN, David Miller, Larry.Finger, bhutchings,
linux-wireless, netdev
In-Reply-To: <1361379597.8629.39.camel@jlt4.sipsolutions.net>
On Wed, 2013-02-20 at 17:59 +0100, Johannes Berg wrote:
> Yeah, I don't follow netdev much any more...
>
Short answer : tcp stack has autotuning sk_rcvbuf, tracking _memory_ use
of a socket.
If network layer provides 8k fat skbs (holding 1500 bytes), the
advertised TCP receive window will be much smaller than if network layer
provides 2k skbs.
Its quite visible in a tcpdump in the beginning of a tcp session.
You'll see how linux grows the receive window, before and after my
patch. You'll see how the sender can send its data faster.
Providing nice skbs is a way to speedup Internet browsing, as most http
traffic happen exactly while tcp receiver didnt yet advertised a big
window. (Especially visible with large RTT)
> >
> > /* If frame is small enough to fit in skb->head, pull it completely.
> > * If not, only pull ieee80211_hdr so that splice() or TCP coalesce
> > * are more efficient.
> > */
>
> Oh, right, though I guess the comment is now wrong since practically
> every packet will be copied either here or in mac80211 (A-MSDUs are
> split up there)
Comment is not 'wrong', it describes what happens here.
If there is enough room in skb->head to avoid attaching a page fragment
to the skb, lets copy the frame so that the page fragment can be reused
by the NIC driver immediately.
^ permalink raw reply
* Re: [PATCH 1/3] sctp: fix association hangs due to reassembly/ordering logic
From: David Miller @ 2013-02-20 17:53 UTC (permalink / raw)
To: lee.roberts; +Cc: linux-sctp, netdev, linux-kernel
In-Reply-To: <D64EC45690EF85409BA6C4730E0162244310ABA1@G4W3231.americas.hpqcorp.net>
Your email client has corrupted every one of your patches, splitting up
new lines as well as making other alterations, making them useless for
us.
Please read Documentation/email-clients.txt to learn how to fix this
problem, and only resubmit your patches when you can successfully
email a patch to yourself and cleanly apply the patch you receive
in that email as-is.
Thanks.
^ 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