* Re: [RFCv2 0/3] mac80211: implement fq codel
From: Bob Copeland @ 2016-03-17 11:12 UTC (permalink / raw)
To: Michal Kazior
Cc: Jasmine Strong, Dave Taht, Network Development, linux-wireless,
ath10k@lists.infradead.org, codel@lists.bufferbloat.net,
make-wifi-fast
In-Reply-To: <CA+BoTQnFN6VANn=5EUvHc0Dbfh4Zv0HraOto2ySN3_HdOpD7Sg@mail.gmail.com>
On Thu, Mar 17, 2016 at 09:55:03AM +0100, Michal Kazior wrote:
> If you consider Wi-Fi is half-duplex and latency in the entire stack
> (for processing ICMP and UDP_RR) is greater than 11e contention window
> timings you can get your BE flow responses with extra delay (since
> other queues might have responses ready quicker).
Got it, that makes sense. Thanks for the explanation!
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH] xfrm: don't segment UFO packets
From: Steffen Klassert @ 2016-03-17 11:01 UTC (permalink / raw)
To: Jiri Bohac; +Cc: Herbert Xu, David S. Miller, netdev
In-Reply-To: <20160317104953.GB11706@midget.suse.cz>
On Thu, Mar 17, 2016 at 11:49:53AM +0100, Jiri Bohac wrote:
> On Thu, Mar 17, 2016 at 11:24:59AM +0100, Steffen Klassert wrote:
> > > > On Wed, Mar 16, 2016 at 05:00:26PM +0100, Jiri Bohac wrote:
> > > Fixes my broken case.
> >
> > Is this IPv4 or IPv6? IPv4 should not create a GSO skb
> > if IPsec is done. It checks for rt->dst.header_len
> > in __ip_append_data() and does a fallback to the
> > standard case if rt->dst.header_len is non zero.
>
> It's IPv6.
>
> > In IPv6 this check is missing, so this could be the
> > problem if this is IPv6.
>
> Doesn't the check do exactly the opposite of what the RFC says?
> The RFC wants ESP to be performed first and fragmentation after
> that. UDPv4 currently seems to be doing the opposite.
No, __ip_append_data() only prepares the packets for fragmentation
and enqueues them. Then __ip_make_skb() dequeues and builds
one skb with a fraglist. Then the xfrm layer is called, so
esp linearizes (unfortunately) the skb and applies the
transformation. Fragmentation happens after that.
^ permalink raw reply
* Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts
From: Sergei Shtylyov @ 2016-03-17 10:58 UTC (permalink / raw)
To: Alexey Brodkin, linux-snps-arc
Cc: Rob Herring, Phil Reid, David S. Miller, linux-kernel, netdev,
stable, #, 4.5.x
In-Reply-To: <1458207712-29435-1-git-send-email-abrodkin@synopsys.com>
On 3/17/2016 12:41 PM, Alexey Brodkin wrote:
> Following commit broke DW GMAC functionality on AXS10x boards:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763
Note that scripts/checkpatch.pl now enforces certain format for citing
commits: commit <12-digit SHA1> ("<commit summary>").
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] xfrm: don't segment UFO packets
From: Jiri Bohac @ 2016-03-17 10:49 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Herbert Xu, David S. Miller, netdev
In-Reply-To: <20160317102459.GG3347@gauss.secunet.com>
On Thu, Mar 17, 2016 at 11:24:59AM +0100, Steffen Klassert wrote:
> > > On Wed, Mar 16, 2016 at 05:00:26PM +0100, Jiri Bohac wrote:
> > Fixes my broken case.
>
> Is this IPv4 or IPv6? IPv4 should not create a GSO skb
> if IPsec is done. It checks for rt->dst.header_len
> in __ip_append_data() and does a fallback to the
> standard case if rt->dst.header_len is non zero.
It's IPv6.
> In IPv6 this check is missing, so this could be the
> problem if this is IPv6.
Doesn't the check do exactly the opposite of what the RFC says?
The RFC wants ESP to be performed first and fragmentation after
that. UDPv4 currently seems to be doing the opposite. Well at
least it works, unlike in the IPv6 case, where the packet is
fragmented, but not enough space is reserved, so after adding the
ESP headers, it is fragmented once more.
(Details can be found in my first e-mail in this thread, I now
replied into the old thread after >1 month, sorry for that:
http://thread.gmane.org/gmane.linux.network/396952
)
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply
* Re: [PATCH] xfrm: don't segment UFO packets
From: Steffen Klassert @ 2016-03-17 10:24 UTC (permalink / raw)
To: Jiri Bohac; +Cc: Herbert Xu, David S. Miller, netdev
In-Reply-To: <20160317094115.GA11706@midget.suse.cz>
On Thu, Mar 17, 2016 at 10:41:15AM +0100, Jiri Bohac wrote:
> On Thu, Mar 17, 2016 at 01:03:59PM +0800, Herbert Xu wrote:
> > On Wed, Mar 16, 2016 at 05:00:26PM +0100, Jiri Bohac wrote:
> > > Prevent xfrm_output() from segmenting UFO packets so that they will be
> > > fragmented after the xfrm transforms.
> >
> > Fair enough. But I wonder if this is enough. Wouldn't UDP notice
> > that we're doing IPsec and prefragment the packet anyway? So I think
> > this check may also be needed in the UDP output path.
>
> Fixes my broken case.
Is this IPv4 or IPv6? IPv4 should not create a GSO skb
if IPsec is done. It checks for rt->dst.header_len
in __ip_append_data() and does a fallback to the
standard case if rt->dst.header_len is non zero.
In IPv6 this check is missing, so this could be the
problem if this is IPv6.
^ permalink raw reply
* [PATCH] qmi_wwan: Added support for Gemalto's Cinterion PHxx WWAN interface
From: Schemmel Hans-Christoph @ 2016-03-17 10:07 UTC (permalink / raw)
To: bjorn@mork.no, netdev@vger.kernel.org; +Cc: linux-usb@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]
Added support for Gemalto's Cinterion PHxx WWAN interfaces
by adding QMI_FIXED_INTF with Cinterion's VID and PID.
PHxx can have:
2 RmNet Interfaces (PID 0x0082) or
1 RmNet + 1 USB Audio interface (PID 0x0083).
Signed-off-by: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
---
patch is against linux-4.5
--- linux/drivers/net/usb/qmi_wwan.c.orig 2016-03-14 12:18:07.153497489 +0100
+++ linux/drivers/net/usb/qmi_wwan.c 2016-03-14 12:21:37.722541644 +0100
@@ -881,6 +881,9 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)}, /* Olivetti Olicard 500 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */
{QMI_FIXED_INTF(0x1e2d, 0x0053, 4)}, /* Cinterion PHxx,PXxx */
+ {QMI_FIXED_INTF(0x1e2d, 0x0082, 4)}, /* Cinterion PHxx,PXxx (2 RmNet) */
+ {QMI_FIXED_INTF(0x1e2d, 0x0082, 5)}, /* Cinterion PHxx,PXxx (2 RmNet) */
+ {QMI_FIXED_INTF(0x1e2d, 0x0083, 4)}, /* Cinterion PHxx,PXxx (1 RmNet + USB Audio)*/
{QMI_FIXED_INTF(0x413c, 0x81a2, 8)}, /* Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a3, 8)}, /* Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a4, 8)}, /* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 7229 bytes --]
^ permalink raw reply
* [PATCH] rtlwifi: fix gcc-6 indentation warning
From: Arnd Bergmann @ 2016-03-17 10:03 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: Arnd Bergmann, linux-wireless, netdev, linux-kernel
The rtl8821ae_dm_txpower_tracking_callback_thermalmeter function
contains a call to RT_TRACE() that is indented in a misleading
way, as pointed out by a gcc-6 warning:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c: In function 'rtl8821ae_dm_txpower_tracking_callback_thermalmeter':
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2491:4: error: statement is indented as if it were guarded by...
RT_TRACE(rtlpriv, COMP_POWER_TRACKING, DBG_LOUD,
^~~~~~~~
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2488:3: note: ...this 'for' clause, but it is not
for (p = RF90_PATH_A; p < MAX_PATH_NUM_8821A; p++)
^~~
It is clear from the context that the call was not meant to be
part of the loop and only the indentation is wrong, so this
removes the extra tabs.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
index 95dcbff4673b..6a8245c4ea48 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
@@ -2488,9 +2488,9 @@ void rtl8821ae_dm_txpower_tracking_callback_thermalmeter(
for (p = RF90_PATH_A; p < MAX_PATH_NUM_8821A; p++)
rtldm->swing_idx_ofdm_base[p] = rtldm->swing_idx_ofdm[p];
- RT_TRACE(rtlpriv, COMP_POWER_TRACKING, DBG_LOUD,
- "pDM_Odm->RFCalibrateInfo.ThermalValue = %d ThermalValue= %d\n",
- rtldm->thermalvalue, thermal_value);
+ RT_TRACE(rtlpriv, COMP_POWER_TRACKING, DBG_LOUD,
+ "pDM_Odm->RFCalibrateInfo.ThermalValue = %d ThermalValue= %d\n",
+ rtldm->thermalvalue, thermal_value);
/*Record last Power Tracking Thermal Value*/
rtldm->thermalvalue = thermal_value;
}
--
2.7.0
^ permalink raw reply related
* Re: [PATCH v3 2/9] net: arc_emac: add phy reset is optional for device tree
From: Caesar Wang @ 2016-03-17 10:02 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Caesar Wang, Heiko Stuebner, David S. Miller, Rob Herring,
Mark Rutland, devicetree, Pawel Moll, Ian Campbell, netdev,
Kumar Gala, linux-kernel, linux-rockchip, keescook, leozwang
In-Reply-To: <56E96656.5000101@cogentembedded.com>
Hi Sergei,
在 2016年03月16日 21:57, Sergei Shtylyov 写道:
> Hello.
>
> On 3/14/2016 11:01 AM, Caesar Wang wrote:
>
>> This patch adds the following property for arc_emac.
>>
>> 1) phy-reset-gpios:
>> The phy-reset-gpio is an optional property for arc emac device tree
>> boot.
>> Change the binding document to match the driver code.
>>
>> 2) phy-reset-duration:
>> Different boards may require different phy reset duration. Add property
>> phy-reset-duration for device tree probe, so that the boards that need
>> a longer reset duration can specify it in their device tree.
>>
>> Anyway, we can add the above property for arc emac.
>>
>> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
>
> Could you have a look at drivers/net/ethernet/cadence/macb/? It
> seems to be the only driver which places the PHY's "reset-gpios" prop
> correctly, into the PHY subnode? I'm currently working on adding
> support of this prop into phylib...
I see the driver on now.
/* Power up the PHY if there is a GPIO reset */
phy_node = of_get_next_available_child(np, NULL);
if (phy_node) {
int gpio = of_get_named_gpio(phy_node, "reset-gpios", 0);
if (gpio_is_valid(gpio))
bp->reset_gpio = gpio_to_desc(gpio);
gpiod_set_value(bp->reset_gpio, GPIOD_OUT_HIGH);
}
of_node_put(phy_node);
...
Frankly, I don't like this way in device drivers.
That's seem same with the /drivers/mmc/core/pwrseq_simple.c, power up
the device.
Is it not really reset hardware PHY from the gpio reset pin? Just power up.
Of course, I hope to see and test it if you improve the PHY framework to
support the phy reset.:-)
---
Anyway, David had applied this series patches into net branch.
Although the clock and dts patches should be applied into Heiko branch,
I'm glad to see David's way.
Heiko branch:
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/
I wish won't destory Heiko to merge in the future.
-Caesar
>
> MBR, Sergei
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
Thanks,
Caesar
^ permalink raw reply
* Re: [RFCv2 0/3] mac80211: implement fq codel
From: Michal Kazior @ 2016-03-17 9:43 UTC (permalink / raw)
To: Dave Taht
Cc: Network Development, codel@lists.bufferbloat.net, linux-wireless,
ath10k@lists.infradead.org, make-wifi-fast
In-Reply-To: <CAA93jw6tDdiYuginPbUY1DFJLiDxofHMFN6j2BvQPabPmBtuRw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]
I've re-tested selected cases with wmm_enabled=0 set on the DUT AP.
I'm attaching results.
Naming:
* "old-" is without mac/ath10k changes (referred to as kvalo-reverts
previously) and fq_codel on qdiscs,
* "patched-" is all patches applied (both mac and ath),
* "-be-bursts" is stock "bursts" flent test,
* "-all-bursts" is modified "bursts" flent test to burst on all 3
tids simultaneously: tid0(BE), tid1(BK), tid5(VI).
Michał
On 16 March 2016 at 19:36, Dave Taht <dave.taht@gmail.com> wrote:
> That is the sanest 802.11e queue behavior I have ever seen! (at both
> 6 and 300mbit! in the ath10k patched mac test)
>
> It would be good to add a flow to this test that exercises the VI
> queue (CS5 diffserv marking?), and to repeat this test with wmm
> disabled for comparison.
>
>
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>
>
> On Wed, Mar 16, 2016 at 8:37 AM, Dave Taht <dave.taht@gmail.com> wrote:
>> it is helpful to name the test files coherently in the flent tests, in
>> addition to using a directory structure and timestamp. It makes doing
>> comparison plots in data->add-other-open-data-files simpler. "-t
>> patched-mac-300mbps", for example.
>>
>> Also netperf from svn (maybe 2.7, don't remember) will restart udp_rr
>> after a packet loss in 250ms. Seeing a loss on UDP_RR and it stop for
>> a while is "ok".
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> https://www.gofundme.com/savewifi
>>
>>
>> On Wed, Mar 16, 2016 at 3:26 AM, Michal Kazior <michal.kazior@tieto.com> wrote:
>>> On 16 March 2016 at 11:17, Michal Kazior <michal.kazior@tieto.com> wrote:
>>>> Hi,
>>>>
>>>> Most notable changes:
>>> [...]
>>>> * ath10k proof-of-concept that uses the new tx
>>>> scheduling (will post results in separate
>>>> email)
>>>
>>> I'm attaching a bunch of tests I've done using flent. They are all
>>> "burst" tests with burst-ports=1 and burst-length=2. The testing
>>> topology is:
>>>
>>> AP ----> STA
>>> AP )) (( STA
>>> [veth]--[br]--[wlan] )) (( [wlan]
>>>
>>> You can notice that in some tests plot data gets cut-off. There are 2
>>> problems I've identified:
>>> - excess drops (not a problem with the patchset and can be seen when
>>> there's no codel-in-mac or scheduling isn't used)
>>> - UDP_RR hangs (apparently QCA99X0 I have hangs for a few hundred ms
>>> sometimes at times and doesn't Rx frames causing UDP_RR to stop
>>> mid-way; confirmed with logs and sniffer; I haven't figured out *why*
>>> exactly, could be some hw/fw quirk)
>>>
>>> Let me know if you have questions or comments regarding my testing/results.
>>>
>>>
>>> Michał
[-- Attachment #2: bursts-2016-03-17T093033.443115.patched_all_bursts.flent.gz --]
[-- Type: application/x-gzip, Size: 13841 bytes --]
[-- Attachment #3: bursts-2016-03-17T092946.721003.patched_be_bursts.flent.gz --]
[-- Type: application/x-gzip, Size: 13786 bytes --]
[-- Attachment #4: bursts-2016-03-17T092445.132728.old_be_bursts.flent.gz --]
[-- Type: application/x-gzip, Size: 6349 bytes --]
[-- Attachment #5: bursts-2016-03-17T091952.053950.old_all_bursts.flent.gz --]
[-- Type: application/x-gzip, Size: 5458 bytes --]
[-- Attachment #6: patched-be-bursts.gif --]
[-- Type: image/gif, Size: 17961 bytes --]
[-- Attachment #7: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
^ permalink raw reply
* [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts
From: Alexey Brodkin @ 2016-03-17 9:41 UTC (permalink / raw)
To: linux-snps-arc
Cc: Alexey Brodkin, Rob Herring, Phil Reid, David S. Miller,
linux-kernel, netdev, stable, #, 4.5.x, Sergei Shtylyov
Following commit broke DW GMAC functionality on AXS10x boards:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763
That's what happens on eth0 up:
--------------------------->8------------------------
libphy: PHY stmmac-0:ffffffff not found
eth0: Could not attach to PHY
stmmac_open: Cannot attach to PHY (error: -19)
--------------------------->8------------------------
Simplest solution is to add PHY description in board's .dts.
And so we do here.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Phil Reid <preid@electromag.com.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org # 4.5.x
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes v1 -> v2:
* PHY node name changed to match real PHY number being used (Sergei)
arch/arc/boot/dts/axs10x_mb.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 44a578c..ab5d570 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -47,6 +47,14 @@
clocks = <&apbclk>;
clock-names = "stmmaceth";
max-speed = <100>;
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
ehci@0x40000 {
--
2.5.0
^ permalink raw reply related
* Re: [PATCH] xfrm: don't segment UFO packets
From: Jiri Bohac @ 2016-03-17 9:41 UTC (permalink / raw)
To: Herbert Xu; +Cc: Steffen Klassert, David S. Miller, netdev
In-Reply-To: <20160317050359.GA3840@gondor.apana.org.au>
On Thu, Mar 17, 2016 at 01:03:59PM +0800, Herbert Xu wrote:
> On Wed, Mar 16, 2016 at 05:00:26PM +0100, Jiri Bohac wrote:
> > Prevent xfrm_output() from segmenting UFO packets so that they will be
> > fragmented after the xfrm transforms.
>
> Fair enough. But I wonder if this is enough. Wouldn't UDP notice
> that we're doing IPsec and prefragment the packet anyway? So I think
> this check may also be needed in the UDP output path.
Fixes my broken case. Ftracing a sendmsg call that sends ~8k of
data over the UDP socket, I see a single 8k skb travel through the
stack all the way to xfrm_output(). MTU is 1500.
That's the whole poing of fragmentation offloading, to pass all
the data at once as far as we can, isn't it? What UDP code did
you think would "notice and prefragment"?
Thanks,
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply
* Re: [RFCv2 0/3] mac80211: implement fq codel
From: Michal Kazior @ 2016-03-17 9:03 UTC (permalink / raw)
To: Dave Taht
Cc: Felix Fietkau, Emmanuel Grumbach, Network Development,
linux-wireless, ath10k@lists.infradead.org,
codel@lists.bufferbloat.net, make-wifi-fast, Johannes Berg,
Tim Shepard
In-Reply-To: <CAA93jw5cUaj_qM+CYHHoRaghLDLC+BUgF4AjT=Oec+SB-zb74g@mail.gmail.com>
On 16 March 2016 at 16:37, Dave Taht <dave.taht@gmail.com> wrote:
> it is helpful to name the test files coherently in the flent tests, in
> addition to using a directory structure and timestamp. It makes doing
> comparison plots in data->add-other-open-data-files simpler. "-t
> patched-mac-300mbps", for example.
Sorry. I'm still trying to figure out what variables are worth
considering for comparison purposes.
> Also netperf from svn (maybe 2.7, don't remember) will restart udp_rr
> after a packet loss in 250ms. Seeing a loss on UDP_RR and it stop for
> a while is "ok".
I'm using 2.6 straight out of debian repos so yeah. I guess I'll try
using more recent netperf if I can't figure out the hiccups.
Michał
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>
>
> On Wed, Mar 16, 2016 at 3:26 AM, Michal Kazior <michal.kazior@tieto.com> wrote:
>> On 16 March 2016 at 11:17, Michal Kazior <michal.kazior@tieto.com> wrote:
>>> Hi,
>>>
>>> Most notable changes:
>> [...]
>>> * ath10k proof-of-concept that uses the new tx
>>> scheduling (will post results in separate
>>> email)
>>
>> I'm attaching a bunch of tests I've done using flent. They are all
>> "burst" tests with burst-ports=1 and burst-length=2. The testing
>> topology is:
>>
>> AP ----> STA
>> AP )) (( STA
>> [veth]--[br]--[wlan] )) (( [wlan]
>>
>> You can notice that in some tests plot data gets cut-off. There are 2
>> problems I've identified:
>> - excess drops (not a problem with the patchset and can be seen when
>> there's no codel-in-mac or scheduling isn't used)
>> - UDP_RR hangs (apparently QCA99X0 I have hangs for a few hundred ms
>> sometimes at times and doesn't Rx frames causing UDP_RR to stop
>> mid-way; confirmed with logs and sniffer; I haven't figured out *why*
>> exactly, could be some hw/fw quirk)
>>
>> Let me know if you have questions or comments regarding my testing/results.
>>
>>
>> Michał
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
^ permalink raw reply
* Re: [RFCv2 0/3] mac80211: implement fq codel
From: Michal Kazior @ 2016-03-17 8:55 UTC (permalink / raw)
To: Jasmine Strong
Cc: Network Development, linux-wireless, ath10k@lists.infradead.org,
codel@lists.bufferbloat.net, make-wifi-fast, Bob Copeland
In-Reply-To: <CAGyitvMDEUiNx7HD=XKjXNHnFvZ_gxD_BbQx3AP-57_+dBeD4A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
TxOP 0 has a special meaning in the standard. For HT/VHT it means the
it is actually limited to 5484us (mixed-mode) or 10000us (greenfield).
I suspect the BK/BE latency difference has to do with the fact that
there's bulk traffic going on BE queues (this isn't reflected
explicitly in the plots). The `bursts` flent test includes short
bursts of traffic on tid0 (BE) which is shared with ICMP and BE UDP_RR
(seen as green and blue lines on the plot). Due to (intended) limited
outflow (6mbps) BE queues build up and don't drain for the duration of
the entire test creating more opportunities for aggregating BE traffic
while other queues are near-empty and very short (time wise as well).
If you consider Wi-Fi is half-duplex and latency in the entire stack
(for processing ICMP and UDP_RR) is greater than 11e contention window
timings you can get your BE flow responses with extra delay (since
other queues might have responses ready quicker).
I've modified traffic-gen and re-run tests with bursts on all tested
tids/ACs (tid0, tid1, tid5). I'm attaching the results.
With bursts on all tids you can clearly see BK has much higher latency than BE.
(Note, I've changed my AP to QCA988X with oldie firmware 10.1.467 for
this test; it doesn't have the weird hiccups I was seeing on QCA99X0
and newer QCA988X firmware reports bogus expected throughput which is
most likely a result of my sloppy proof-of-concept change in ath10k).
Michał
On 16 March 2016 at 20:48, Jasmine Strong <jas@eero.com> wrote:
> BK usually has 0 txop, so it doesn't do aggregation.
>
> On Wed, Mar 16, 2016 at 11:55 AM, Bob Copeland <me@bobcopeland.com> wrote:
>>
>> On Wed, Mar 16, 2016 at 11:36:31AM -0700, Dave Taht wrote:
>> > That is the sanest 802.11e queue behavior I have ever seen! (at both
>> > 6 and 300mbit! in the ath10k patched mac test)
>>
>> Out of curiosity, why does BE have larger latency than BK in that chart?
>> I'd have expected the opposite.
>>
>> --
>> Bob Copeland %% http://bobcopeland.com/
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
>
[-- Attachment #2: bursts-2016-03-17T083932.549858.qca988x_10_1_467_fqmac_ath10k_with_tx_sched_6mbps_.flent.gz --]
[-- Type: application/x-gzip, Size: 14649 bytes --]
[-- Attachment #3: bursts-2016-03-17T083803.348752.qca988x_10_1_467_fqmac_ath10k_with_tx_sched_6mbps_.flent.gz --]
[-- Type: application/x-gzip, Size: 15029 bytes --]
[-- Attachment #4: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
^ permalink raw reply
* Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing
From: Nicolas Dichtel @ 2016-03-17 8:47 UTC (permalink / raw)
To: Mahesh Bandewar, David Miller; +Cc: mahesh, Eric Dumazet, linux-netdev
In-Reply-To: <CAF2d9jgqAqUxN0HSTUguQyf6m62wDWizTH4bQ+Hz1xxte-=kaQ@mail.gmail.com>
Le 14/03/2016 18:57, Mahesh Bandewar a écrit :
> On Sun, Mar 13, 2016 at 8:53 PM, David Miller <davem@davemloft.net> wrote:
[snip]
>> Furthermore, when you walk across the ns boundary, that old device has
>> to disappear. That's why that is the device assigned to skb->dev.
>>
> The layer boundaries are not that well maintained. We do check for the xfrm
> policies in L4 and expect the skb->dev pointing to the L3 device. So unless we
> have a way to derive a L3 dev from skb->dev, I don't think xfrm will
> work. Unless
> some Xfrm-expert asserts that this is not needed.
Adding a hook "at the right place" to do the switch is probably the better way.
For xfrm, you will need to handle it in this hook or rearrange things.
I don't think that a quick and easy solution will be possible.
^ permalink raw reply
* Re: [PATCH net] esp: Fix crash observed during device unregistration and decryption
From: Steffen Klassert @ 2016-03-17 8:26 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan; +Cc: netdev, 'Herbert Xu'
In-Reply-To: <008d01d17fe3$81c2b520$85481f60$@codeaurora.org>
On Wed, Mar 16, 2016 at 06:25:26PM -0600, Subash Abhinov Kasiviswanathan wrote:
> A crash is observed when a decrypted packet is processed in receive path.
> get_rps_cpus() tries to dereference the skb->dev fields but it appears
> that the device is freed from the poison pattern.
>
> [<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
> [<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
> [<ffffffc000af6094>] netif_rx+0x74/0x94
> [<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
> [<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
> [<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
> [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
> [<ffffffc0000b7324>] worker_thread+0x2f8/0x418
> [<ffffffc0000bb40c>] kthread+0xe0/0xec
>
> -013|get_rps_cpu(
> | dev = 0xFFFFFFC08B688000,
> | skb = 0xFFFFFFC0C76AAC00 -> (
> | dev = 0xFFFFFFC08B688000 -> (
> | name =
> "......................................................
> | name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
> 0xAAAAAAAAAAA
>
> Following are the sequence of events observed -
>
> - Encrypted packet in receive path from netdevice is queued
> - Encrypted packet queued for decryption (asynchronous)
> - Netdevice brought down and freed
> - Packet is decrypted and returned through callback in esp_input_done
> - Packet is queued again for process in network stack using netif_rx
>
> Since the device appears to have been freed, the dereference of skb->dev in
> get_rps_cpus() leads to an unhandled page fault exception.
>
> Fix this by holding on to device reference when queueing packets
> asynchronously and releasing the reference on call back return.
>
> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> ---
> net/ipv4/esp4.c | 2 ++
> net/ipv6/esp6.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
> index 4779374..d482a96 100644
> --- a/net/ipv4/esp4.c
> +++ b/net/ipv4/esp4.c
> @@ -380,6 +380,7 @@ static void esp_input_done(struct crypto_async_request
> *base, int err)
> {
> struct sk_buff *skb = base->data;
>
> + dev_put(skb->dev);
esp_input_done() is called just on asynchronous resumption, so you
leak the reference on synchronous crypto.
Also, other IPsec protocols need this too. So maybe better
to add this to xfrm_input().
^ permalink raw reply
* Re: [PATCH] net: phy: fix PHY_RUNNING in phy_state_machine
From: Yegor Yefremov @ 2016-03-17 8:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: shaohui ???, netdev, David Miller, Shaohui Xie, Florian Fainelli,
N, Mugunthan V, drivshin
In-Reply-To: <20160316230505.GA18161@lunn.ch>
On Thu, Mar 17, 2016 at 12:05 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Wed, Mar 16, 2016 at 11:23:59PM +0100, Yegor Yefremov wrote:
>> Hi Andrew,
>>
>> On Wed, Mar 16, 2016 at 5:18 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > On Wed, Mar 16, 2016 at 04:59:23PM +0100, Yegor Yefremov wrote:
>> >
>> >> This patch breaks my am335x based board, where one of the CPSW slaves
>> >> is connected to IP175D switch chip via RMII interface. Since this
>> >> patch packet reception is not working.
>> >
>> > Hi Yegor
>> >
>> > Which phy is causing the problem? A PHY inside the switch?
>> >
>> > Do you have two back to back PHYs between the MAC and the switch, or
>> > is the CPSW RMII connected directly to the switch?
>>
>> CPSW RMII is connected directly to the switch.
>
> So which PHY is causing you problems?
First of all this is the system in question [1]. am335x CPSW has two
slaves and in this particular configuration CPSW is working in Dual
EMAC mode, so that both slaves are independent interfaces eth0 and
eth1.
eth1 is connected to Atheros 8035 PHY via RGMII channel and is working
as expected. eth0 is connected to ICPlus IP175D via RMII interface, so
from CPSW point of view ICPlus IP175D is just an ordinary PHY. Both
Atheros 8035 and ICPlus IP175D are connected via MDIO, so that both of
them will be detected at runtime:
davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
davinci_mdio 4a101000.mdio: detected phy mask f00fff00
Atheros 8035 ethernet 4a101000.mdio:07: GPIO lookup for consumer reset
Atheros 8035 ethernet 4a101000.mdio:07: using lookup tables for GPIO lookup
Atheros 8035 ethernet 4a101000.mdio:07: lookup for GPIO reset failed
libphy: 4a101000.mdio: probed
davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver
ICPlus IP175C
davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver
ICPlus IP175C
davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:02, driver
ICPlus IP175C
davinci_mdio 4a101000.mdio: phy[3]: device 4a101000.mdio:03, driver
ICPlus IP175C
davinci_mdio 4a101000.mdio: phy[4]: device 4a101000.mdio:04, driver
ICPlus IP175C
davinci_mdio 4a101000.mdio: phy[5]: device 4a101000.mdio:05, driver unknown
davinci_mdio 4a101000.mdio: phy[6]: device 4a101000.mdio:06, driver unknown
davinci_mdio 4a101000.mdio: phy[7]: device 4a101000.mdio:07, driver
Atheros 8035 ethernet
davinci_mdio 4a101000.mdio: phy[20]: device 4a101000.mdio:14, driver unknown
davinci_mdio 4a101000.mdio: phy[21]: device 4a101000.mdio:15, driver unknown
davinci_mdio 4a101000.mdio: phy[22]: device 4a101000.mdio:16, driver unknown
davinci_mdio 4a101000.mdio: phy[23]: device 4a101000.mdio:17, driver unknown
davinci_mdio 4a101000.mdio: phy[24]: device 4a101000.mdio:18, driver unknown
davinci_mdio 4a101000.mdio: phy[25]: device 4a101000.mdio:19, driver unknown
davinci_mdio 4a101000.mdio: phy[26]: device 4a101000.mdio:1a, driver unknown
davinci_mdio 4a101000.mdio: phy[27]: device 4a101000.mdio:1b, driver unknown
>From ICPlus IP175D point of view eth0 is just a fifth port in the
switch. ICPlus IP175D is in its default configuration, i.e. just acts
as an unmanaged Ethernet switch. As soon as eth0 will be brought up it
has constant 100Mbps connection. I assume, that from MDIO signalling
this connection differs from physical cable insertion.
In prior kernels when I make ip link set eth0 up I get:
cpsw 4a100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
After this patch I don't get this state message. Though I cannot see
differences in "ethtool eth0" or "ip addr show eth0" for both kernels.
So I assume, that ICPlus IP175D stays in PHY_RUNNING state.
Let me know, what additional info do you need.
[1] http://www.visionsystems.de/produkte/baltos-ir-5221.html
Yegor
^ permalink raw reply
* Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)
From: Marc Zyngier @ 2016-03-17 7:52 UTC (permalink / raw)
To: Bert Lindner
Cc: Andreas Färber, Robin Murphy, Maxime Ripard,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, Giuseppe Cavallaro
In-Reply-To: <56E9F2B8.1030605-phGP8mJ4Mqk@public.gmane.org>
On Thu, 17 Mar 2016 00:56:40 +0100
Bert Lindner <bert-phGP8mJ4Mqk@public.gmane.org> wrote:
> On 2016-03-16 18:42, Marc Zyngier wrote:
> > On 16/03/16 15:10, Bert Lindner wrote:
> >> On 2016-03-16 14:10, Andreas Färber wrote:
> >>> Am 16.03.2016 um 13:09 schrieb Robin Murphy:
> >>>> On 16/03/16 11:39, Marc Zyngier wrote:
> >>>>> On 16/03/16 11:19, Bert Lindner wrote:
> >>>>>> Hopefully this is the correct place and way to report this.
> >>>
> >>> The main discussion is on netdev list actually, CC'ed.
> >>>
> >>>>>> For the board sun7i-a20-olinuxino-lime2, there seems to be a problem
> >>>>>> with the eth0 PHY in mainline kernel 4.5.0 that developed since
> >>>>>> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
> >>>>>>
> >>>>>> root@lime2-079f:~# ip a l eth0
> >>>>>> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> >>>>>> default qlen 1000
> >>>>>> link/ether 02:c9:05:02:07:9f brd ff:ff:ff:ff:ff:ff
> >>>>>>
> >>>>>> Difference reported in dmesg:
> >>>>>>
> >>>>>> 4.5.0-rc7:
> >>>>>> [ 9.379279] NET: Registered protocol family 10
> >>>>>> [ 10.217148] RX IPC Checksum Offload disabled
> >>>>>> [ 10.217195] No MAC Management Counters available
> >>>>>> [ 10.217627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> >>>>>> [ 15.206250] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
> >>>>>> 1Gbps/Full - flow control off
> >>>>>> [ 15.206360] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> >>>>>>
> >>>>>> 4.5.0:
> >>>>>> [ 9.767125] NET: Registered protocol family 10
> >>>>>> [ 10.357405] libphy: PHY stmmac-0:ffffffff not found
> >>>>>> [ 10.362382] eth0: Could not attach to PHY
> >>>>>> [ 10.366557] stmmac_open: Cannot attach to PHY (error: -19)
> >>>>>>
> >>>>>> .config is identical for both, also after make oldconfig, apart from
> >>>>>> comment with version number. DTB file is also identical between the two
> >>>>>> versions.
> >>>>>>
> >>>>>> Kernels are compiled on the board itself. /proc/version string:
> >>>>>> Linux version 4.5.0-rc7 (root@lime2-079f) (gcc version 4.9.1
> >>>>>> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Mon Mar 7 11:57:25 UTC 2016
> >>>>>> Linux version 4.5.0 (root@lime2-079f) (gcc version 4.9.1 (Ubuntu/Linaro
> >>>>>> 4.9.1-16ubuntu6) ) #1 SMP Tue Mar 15 11:39:01 UTC 2016
> >>>>>>
> >>>>>> Please let me know if more info is needed, if I should post complete
> >>>>>> .config, test compile with a particular config or patch, etc. Part of
> >>>>>> .config below.
> >>>>>
> >>>>> Can you please try reverting 88f8b1b ("stmmac: Fix 'eth0: No PHY found'
> >>>>> regression") and report whether or not this changes anything? This seems
> >>>>> to be the only stmac patch between -rc7 and release...
> >>>>
> >>>> Sounds like the same thing as the giant ongoing discussion thread here:
> >>>>
> >>>> http://thread.gmane.org/gmane.linux.drivers.devicetree/159007/focus=402830
> >>>
> >>> v4 fixes for 4.5 are here:
> >>>
> >>> https://patchwork.ozlabs.org/patch/598195/ (revert)
> >>> https://patchwork.ozlabs.org/patch/598196/
> >>>
> >>> v2 fixes for linux-next here:
> >>>
> >>> https://patchwork.ozlabs.org/patch/598331/ (revert)
> >>> https://patchwork.ozlabs.org/patch/598332/
> >>>
> >>> Please let Peppe know whether they work for you guys.
> >>
> >> Hi guys - I can confirm 4.5.0 minus 88f8b1b works for me:
> >>
> >> root@lime2-079f:~# cat /proc/version
> >> Linux version 4.5.0-minus-88f8b1b (root@lime2-079f) (gcc version 4.9.1
> >> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #2 SMP Wed Mar 16 12:50:03 UTC 2016
> >>
> >> From dmesg output:
> >> [ 9.731730] NET: Registered protocol family 10
> >> [ 10.516893] RX IPC Checksum Offload disabled
> >> [ 10.516948] No MAC Management Counters available
> >> [ 10.517374] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> >> [ 15.505548] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
> >> 1Gbps/Full - flow control off
> >> [ 15.505660] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> >>
> >> .. and connected over ethernet.
> >
> > Good to know, thanks. Could you also give the potential fix a go (as
> > mentioned by Andreas)? Just to make sure that whatever gets merged next
> > will actually fix the issue.
>
> Yes sure, it took a while because I had to travel. Confirmed, the
> v4-for-4.5 fix works well for me, on sun7i-a20-olinuxino-lime2:
>
> root@lime2-079f:~# cat /proc/version
> Linux version 4.5.0-598195-598196-v4 (root@lime2-079f) (gcc version
> 4.9.1 (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Wed Mar 16 16:44:22 UTC 2016
>
> dmesg:
> [ 8.245273] NET: Registered protocol family 10
> [ 9.297406] RX IPC Checksum Offload disabled
> [ 9.297460] No MAC Management Counters available
> [ 9.297951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 16.285658] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
> 1Gbps/Full - flow control rx/tx
> [ 16.285798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> The board is connected to my laptop rather than to a switch, so that
> might be where the flow control message comes from (not sure). Anyway
> ethernet works.
Cool, many thanks for taking the time to test and report.
Hopefully Giuseppe will get this merged quickly enough in mainline, and
it should then trickle into a 4.5-stable release (cc-ing stable on
these patches would probably be a good idea, BTW).
> I'm less familiar with linux-next - not sure what base to test against,
> I understand it is being redefined almost daily.
You can consider -next as a daily view of what mainline could become.
An over-sized crystal ball, in a way... ;-) Given that the regression
exists in mainline, there was no real point testing with -next.
Thanks again,
M.
--
Jazz is not dead. It just smells funny.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: Hung up was occurred after v4.4-rc1 during IPv6 Ready Logo Conformance Test
From: Yuki Machida @ 2016-03-17 7:40 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev
In-Reply-To: <20160310063919.GA76112@kafai-mba.local>
Hi Martin,
Thank you for your reply.
Sorry for the delay.
On 2016年03月10日 15:39, Martin KaFai Lau wrote:
> On Thu, Mar 10, 2016 at 01:21:05PM +0900, Yuki Machida wrote:
>> Hi all,
>>
>> Hung up was occurred at Linux Kernel after v4.4-rc1 during IPv6 Ready Logo Conformance Test.
>> Not Fix a bug in v4.5-rc7 yet.
>>
>> Currently, it is under investigation.
>>
>> The following are the details:
> I think you forgot to paste the details?
I found that this problem don't cause a hang-up.
I will report again after more investigation.
>
>>
>> IPv6 Ready Logo
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ipv6ready.org_&d=CwICJg&c=5VD0RTtNlTh3ycd41b3MUw&r=VQnoQ7LvghIj0gVEaiQSUw&m=BzjeED6xB_NfQBjateVt8Gh7IK7hST7tSmPGXEAtRdQ&s=oaM204vOhRnGb6aTD1wxTZu9ss_bCzFAeZU0EmvVe6I&e=
>>
>> I ran the IPv6 Ready Logo Core Conformance Test on Intel D510MO (Atom D510).
>> It is using userland build with yocto project.
>>
>> Test Environment
>> Test Specification : 4.0.6
>> Tool Version : REL_3_3_2
>> Test Program Version : V6LC_5_0_0
>> Target Device : Intel D510MO (Atom D510)
>>
>> Regards,
>> Yuki Machida
>
^ permalink raw reply
* Re: Re: [PATCH V7] netfilter: h323: avoid potential attack
From: Zhouyi Zhou @ 2016-03-17 6:41 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Zhouyi Zhou, eric.dumazet, kaber, kadlec, davem, netfilter-devel,
coreteam, netdev, linux-kernel, fw, gnomes, sergei.shtylyov
In-Reply-To: <20160312121902.GA2398@salvia>
Thanks Pablo for reviewing
> From: "Pablo Neira Ayuso" <pablo@netfilter.org>
> Sent Time: Saturday, March 12, 2016
> To: "Zhouyi Zhou" <zhouzhouyi@gmail.com>
> On Sun, Feb 21, 2016 at 12:03:59AM +0800, Zhouyi Zhou wrote:
> > I think hackers chould build a malicious h323 packet to overflow
(iph->ihl * 4 + th->doff * 4);
> You cannot trust the information that is available in the header. If
> this is bogus this check will be defeated. That's why we pass this
> protoff parameters to each function.
The length of IP header is checked in the function nf_conntrack_in which calls
get_l4proto hook to detect bogus ip header.
There is no where in the call stack to the function set_addr to check bogus
TCP header, and my code does the job:
+ th = (void *)iph + iph->ihl * 4;
+ datalen = skb->len - (iph->ihl * 4 + th->doff * 4);
+ /* check offset overflow */
+ if (addroff > datalen)
+ return -1;
if th->doff be too big addroff will greater than datalen.
>
> You also refer to get_h225_addr() in your description. That function
> always copies 4 or 16 bytes, so I would appreciate if you can describe
> the possible issue further.
The problem of get_h225_addr lies in bogus taddr->ipAddress.ip, if this value
is too big, it may make the pointer p point to no exist address.
(gdb) list 686
681 struct h323_ct_state *ctstate)
682 {
683 const unsigned char *p;
684 int len;
685
686 switch (taddr->choice) {
687 case eTransportAddress_ipAddress:
688 if (nf_ct_l3num(ct) != AF_INET)
689 return 0;
690 p = data + taddr->ipAddress.ip;
Thanks for your time and effort
Cheers
Zhouyi
^ permalink raw reply
* Re: [PATCH 1/3] infiniband: IB/hns: add Hisilicon RoCE support
From: Leon Romanovsky @ 2016-03-17 6:43 UTC (permalink / raw)
To: Jiri Pirko
Cc: oulijun, dledford, sean.hefty, hal.rosenstock, davem,
jeffrey.t.kirsher, jiri, ogerlitz, linux-rdma, linux-kernel,
netdev, gongyangming, xiaokun, tangchaofei, haifeng.wei,
yisen.zhuang, yankejian, lisheng011, charles.chenxin, linuxarm
In-Reply-To: <20160316103638.GB2254@nanopsycho.orion>
On Wed, Mar 16, 2016 at 11:36:38AM +0100, Jiri Pirko wrote:
> >so, I continue to have it.
>
> I will continue to bash on your odd codingstyle. Please fix it!
Jiri,
Checkpatch errors is an easiest issue with this patch.
It is full of functions without use, unconnected macros and
if you replace "hsi" to name of other well known driver, you will get
same code :).
They need to redesign the whole driver before resubmission.
Thanks.
^ permalink raw reply
* [PATCH net] tcp/dccp: remove obsolete WARN_ON() in icmp handlers
From: Eric Dumazet @ 2016-03-17 5:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ben Lazarus, Neal Cardwell
From: Eric Dumazet <edumazet@google.com>
Now SYN_RECV request sockets are installed in ehash table, an ICMP
handler can find a request socket while another cpu handles an incoming
packet transforming this SYN_RECV request socket into an ESTABLISHED
socket.
We need to remove the now obsolete WARN_ON(req->sk), since req->sk
is set when a new child is created and added into listener accept queue.
If this race happens, the ICMP will do nothing special.
Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Ben Lazarus <blazarus@google.com>
Reported-by: Neal Cardwell <ncardwell@google.com>
---
net/dccp/ipv4.c | 2 --
net/ipv4/tcp_ipv4.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index b5672e5fe649..9c67a961ba53 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -204,8 +204,6 @@ void dccp_req_err(struct sock *sk, u64 seq)
* ICMPs are not backlogged, hence we cannot get an established
* socket here.
*/
- WARN_ON(req->sk);
-
if (!between48(seq, dccp_rsk(req)->dreq_iss, dccp_rsk(req)->dreq_gss)) {
NET_INC_STATS_BH(net, LINUX_MIB_OUTOFWINDOWICMPS);
} else {
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0b02ef773705..e7528b101e68 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -319,8 +319,6 @@ void tcp_req_err(struct sock *sk, u32 seq, bool abort)
/* ICMPs are not backlogged, hence we cannot get
* an established socket here.
*/
- WARN_ON(req->sk);
-
if (seq != tcp_rsk(req)->snt_isn) {
NET_INC_STATS_BH(net, LINUX_MIB_OUTOFWINDOWICMPS);
} else if (abort) {
^ permalink raw reply related
* Re: [RFC PATCH kernel] Revert "net/mlx4_core: Set UAR page size to 4KB regardless of system page size"
From: Or Gerlitz @ 2016-03-17 5:05 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Eli Cohen, Huy Nguyen, Doug Ledford, Eugenia Emantayev,
Hal Rosenstock, Sean Hefty, Yishai Hadas, Linux Kernel,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Netdev List, Paul Mackerras, Carol L Soto, Yevgeny Petrilin,
Brian J King
In-Reply-To: <56EA0B12.3070901-sLpHqDYs0B2HXe+LvDLADg@public.gmane.org>
On Thu, Mar 17, 2016 at 3:40 AM, Alexey Kardashevskiy <aik-sLpHqDYs0B2HXe+LvDLADg@public.gmane.org> wrote:
> On 03/16/2016 08:45 PM, Or Gerlitz wrote:
>> On Wed, Mar 16, 2016 at 10:34 AM, Alexey Kardashevskiy <aik-sLpHqDYs0B2HXe+LvDLADg@public.gmane.org>
>> wrote:
>>
>>> Oh. ok. It also looks like even with the reverted patch, mlx4 VF does not
>>> work in a guest:
>>
>>
>> So where is the breakage point for you? does 4.4 works? if not, what?
> Ah, my bad. It is unrelated to the kernel version.
> I tried passing a PF to a guest while its VFs are already passed to another
> guest and see how exactly it blows up (AER/EEH were thrown but the host
> recovered => good) but this left the device in a weird state when I could
> not use VF in a guest anymore but it seemed to keep working on the host.
> It seems like the actual adapter does not reset completely when the machine
> is rebooted, I had unplug/replug power cables to fix this.
So to make sure, now things works fine with the patch reverted?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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] xfrm: don't segment UFO packets
From: Herbert Xu @ 2016-03-17 5:03 UTC (permalink / raw)
To: Jiri Bohac; +Cc: Steffen Klassert, David S. Miller, netdev
In-Reply-To: <20160316160026.GB19258@midget.suse.cz>
On Wed, Mar 16, 2016 at 05:00:26PM +0100, Jiri Bohac wrote:
> xfrm_output() will segment GSO packets, including UDP (UFO) packets.
> this is wrong per RFC4303, section 3.3.4. Fragmentation:
>
> If necessary, fragmentation is performed after ESP
> processing within an IPsec implementation. Thus,
> transport mode ESP is applied only to whole IP
> datagrams (not to IP fragments).
>
> Prevent xfrm_output() from segmenting UFO packets so that they will be
> fragmented after the xfrm transforms.
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Fair enough. But I wonder if this is enough. Wouldn't UDP notice
that we're doing IPsec and prefragment the packet anyway? So I think
this check may also be needed in the UDP output path.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH net] vlan: propagate gso_max_segs
From: Eric Dumazet @ 2016-03-17 4:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
vlan drivers lack proper propagation of gso_max_segs from
lower device.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/ipvlan/ipvlan_main.c | 2 ++
drivers/net/macvlan.c | 2 ++
net/8021q/vlan.c | 1 +
net/8021q/vlan_dev.c | 1 +
4 files changed, 6 insertions(+)
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index 5802b90..57941d3 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -119,6 +119,7 @@ static int ipvlan_init(struct net_device *dev)
dev->features = phy_dev->features & IPVLAN_FEATURES;
dev->features |= NETIF_F_LLTX;
dev->gso_max_size = phy_dev->gso_max_size;
+ dev->gso_max_segs = phy_dev->gso_max_segs;
dev->hard_header_len = phy_dev->hard_header_len;
ipvlan_set_lockdep_class(dev);
@@ -592,6 +593,7 @@ static int ipvlan_device_event(struct notifier_block *unused,
list_for_each_entry(ipvlan, &port->ipvlans, pnode) {
ipvlan->dev->features = dev->features & IPVLAN_FEATURES;
ipvlan->dev->gso_max_size = dev->gso_max_size;
+ ipvlan->dev->gso_max_segs = dev->gso_max_segs;
netdev_features_change(ipvlan->dev);
}
break;
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 6e953e3..2bcf1f3 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -803,6 +803,7 @@ static int macvlan_init(struct net_device *dev)
dev->hw_features |= NETIF_F_LRO;
dev->vlan_features = lowerdev->vlan_features & MACVLAN_FEATURES;
dev->gso_max_size = lowerdev->gso_max_size;
+ dev->gso_max_segs = lowerdev->gso_max_segs;
dev->hard_header_len = lowerdev->hard_header_len;
macvlan_set_lockdep_class(dev);
@@ -1532,6 +1533,7 @@ static int macvlan_device_event(struct notifier_block *unused,
case NETDEV_FEAT_CHANGE:
list_for_each_entry(vlan, &port->vlans, list) {
vlan->dev->gso_max_size = dev->gso_max_size;
+ vlan->dev->gso_max_segs = dev->gso_max_segs;
netdev_update_features(vlan->dev);
}
break;
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 69929c0..a1e273a 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -311,6 +311,7 @@ static void vlan_transfer_features(struct net_device *dev,
struct vlan_dev_priv *vlan = vlan_dev_priv(vlandev);
vlandev->gso_max_size = dev->gso_max_size;
+ vlandev->gso_max_segs = dev->gso_max_segs;
if (vlan_hw_offload_capable(dev->features, vlan->vlan_proto))
vlandev->hard_header_len = dev->hard_header_len;
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index e416a40..e7e6257 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -551,6 +551,7 @@ static int vlan_dev_init(struct net_device *dev)
dev->features |= real_dev->vlan_features | NETIF_F_LLTX |
NETIF_F_GSO_SOFTWARE;
dev->gso_max_size = real_dev->gso_max_size;
+ dev->gso_max_segs = real_dev->gso_max_segs;
if (dev->features & NETIF_F_VLAN_FEATURES)
netdev_warn(real_dev, "VLAN features are set incorrectly. Q-in-Q configurations may not work correctly.\n");
^ permalink raw reply related
* [PATCH][net-next] ipv6: rework the lock in addrconf_permanent_addr
From: roy.qing.li @ 2016-03-17 3:39 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
1. nothing of idev is changed, so read lock is enough
2. ifp is changed, so used ifp->lock or cmpxchg to protect it
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/ipv6/addrconf.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 8c0dab2..08a9ee9 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3178,14 +3178,21 @@ static void addrconf_gre_config(struct net_device *dev)
static void l3mdev_check_host_rt(struct inet6_dev *idev,
struct inet6_ifaddr *ifp)
{
+ struct rt6_info *rt = NULL;
+
+ spin_lock(&ifp->lock);
if (ifp->rt) {
u32 tb_id = l3mdev_fib_table(idev->dev) ? : RT6_TABLE_LOCAL;
if (tb_id != ifp->rt->rt6i_table->tb6_id) {
- ip6_del_rt(ifp->rt);
+ rt = ifp->rt;
ifp->rt = NULL;
}
}
+ spin_unlock(&ifp->lock);
+
+ if (rt)
+ ip6_del_rt(rt);
}
#else
static void l3mdev_check_host_rt(struct inet6_dev *idev,
@@ -3197,6 +3204,8 @@ static void l3mdev_check_host_rt(struct inet6_dev *idev,
static int fixup_permanent_addr(struct inet6_dev *idev,
struct inet6_ifaddr *ifp)
{
+ struct rt6_info *prev;
+
l3mdev_check_host_rt(idev, ifp);
if (!ifp->rt) {
@@ -3206,7 +3215,12 @@ static int fixup_permanent_addr(struct inet6_dev *idev,
if (unlikely(IS_ERR(rt)))
return PTR_ERR(rt);
- ifp->rt = rt;
+ prev = cmpxchg(&ifp->rt, NULL, rt);
+
+ /*if cmpxchg failed*/
+ if (prev) {
+ ip6_rt_put(rt);
+ }
}
if (!(ifp->flags & IFA_F_NOPREFIXROUTE)) {
@@ -3228,21 +3242,21 @@ static void addrconf_permanent_addr(struct net_device *dev)
if (!idev)
return;
- write_lock_bh(&idev->lock);
+ read_lock_bh(&idev->lock);
list_for_each_entry_safe(ifp, tmp, &idev->addr_list, if_list) {
if ((ifp->flags & IFA_F_PERMANENT) &&
fixup_permanent_addr(idev, ifp) < 0) {
- write_unlock_bh(&idev->lock);
+ read_unlock_bh(&idev->lock);
ipv6_del_addr(ifp);
- write_lock_bh(&idev->lock);
+ read_lock_bh(&idev->lock);
net_info_ratelimited("%s: Failed to add prefix route for address %pI6c; dropping\n",
idev->dev->name, &ifp->addr);
}
}
- write_unlock_bh(&idev->lock);
+ read_unlock_bh(&idev->lock);
}
static int addrconf_notify(struct notifier_block *this, unsigned long event,
--
2.1.4
^ 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