* 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
* 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: 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: 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: [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: [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 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: [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: [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: [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
* [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: [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
* 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
* [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
* [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
* 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
* 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 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: 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: [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 v2] ARC: axs10x - add Ethernet PHY description in .dts
From: Vineet Gupta @ 2016-03-17 11:13 UTC (permalink / raw)
To: Sergei Shtylyov, Alexey Brodkin,
linux-snps-arc@lists.infradead.org
Cc: Rob Herring, netdev@vger.kernel.org, 4.5.x@synopsys.com,
linux-kernel@vger.kernel.org, stable@vger.kernel.org, Phil Reid,
#@synopsys.com, David S. Miller
In-Reply-To: <56EA8DCC.8070308@cogentembedded.com>
On Thursday 17 March 2016 04:28 PM, Sergei Shtylyov wrote:
> 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
Indeed - I've fixed this up and added to arc for-curr !
-Vineet
^ permalink raw reply
* Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts
From: Alexey Brodkin @ 2016-03-17 11:37 UTC (permalink / raw)
To: sergei.shtylyov@cogentembedded.com
Cc: robh@kernel.org, preid@electromag.com.au, davem@davemloft.net,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
linux-snps-arc@lists.infradead.org, netdev@vger.kernel.org
In-Reply-To: <56EA8DCC.8070308@cogentembedded.com>
Hi Sergei,
On Thu, 2016-03-17 at 13:58 +0300, Sergei Shtylyov wrote:
> 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>").
Frankly I haven't run that patch through checkpatch due to patch
simplicity.
But I'll try to not do any assumptions from now on and will try to
use checkpatch for each and every thing I send :)
Thanks for spotting all his!
-Alexey
^ permalink raw reply
* Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts
From: Vineet Gupta @ 2016-03-17 11:41 UTC (permalink / raw)
To: Alexey Brodkin, sergei.shtylyov@cogentembedded.com
Cc: robh@kernel.org, preid@electromag.com.au, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
linux-snps-arc@lists.infradead.org, davem@davemloft.net
In-Reply-To: <1458214678.14496.15.camel@synopsys.com>
On Thursday 17 March 2016 05:08 PM, Alexey Brodkin wrote:
> Hi Sergei,
>
> On Thu, 2016-03-17 at 13:58 +0300, Sergei Shtylyov wrote:
>> 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>").
> Frankly I haven't run that patch through checkpatch due to patch
> simplicity.
>
> But I'll try to not do any assumptions from now on and will try to
> use checkpatch for each and every thing I send :)
>
> Thanks for spotting all his!
>
> -Alexey
Sergei, do you mind providing a Ack/Reviewed-by on the patch below
-------->
>From 67216d835d8c2a5748ba1631c8bfc19da4fb87fa Mon Sep 17 00:00:00 2001
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Date: Thu, 17 Mar 2016 12:41:52 +0300
Subject: [PATCH] ARC: axs10x - add Ethernet PHY description in .dts
Commit e34d65696d2e ("stmmac: create of compatible mdio bus for stmmac
driver") broke DW GMAC functionality on ARC AXS10x boards:
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
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
---
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 44a578c10732..ab5d5701e11d 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 v2] ARC: axs10x - add Ethernet PHY description in .dts
From: Sergei Shtylyov @ 2016-03-17 11:59 UTC (permalink / raw)
To: Vineet Gupta, Alexey Brodkin
Cc: robh@kernel.org, preid@electromag.com.au, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
linux-snps-arc@lists.infradead.org, davem@davemloft.net
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075F4E903EF@us01wembx1.internal.synopsys.com>
Hello.
On 3/17/2016 2:41 PM, Vineet Gupta 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>").
>> Frankly I haven't run that patch through checkpatch due to patch
>> simplicity.
>>
>> But I'll try to not do any assumptions from now on and will try to
>> use checkpatch for each and every thing I send :)
>>
>> Thanks for spotting all his!
>>
Sorry for not reporting everything on the 1st review.
>> -Alexey
>
> Sergei, do you mind providing a Ack/Reviewed-by on the patch below
>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
The patch here is white space damaged however: tabs were converted to
spaces. :-(
MBR, Sergei
^ permalink raw reply
* Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev
From: Jiri Slaby @ 2016-03-17 12:00 UTC (permalink / raw)
To: Tejun Heo
Cc: Dmitry Vyukov, Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
David S. Miller, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, netdev,
LKML, syzkaller, Kostya Serebryany, Alexander Potapenko,
Sasha Levin, Eric Dumazet, Takashi Iwai
In-Reply-To: <20160311171205.GB24046-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]
Hello,
On 03/11/2016, 06:12 PM, Tejun Heo wrote:
> On Thu, Mar 03, 2016 at 10:12:01AM +0100, Jiri Slaby wrote:
>> On 03/02/2016, 04:45 PM, Tejun Heo wrote:
>>> On Fri, Feb 19, 2016 at 01:10:00PM +0100, Jiri Slaby wrote:
>>>>> 1. didn't help, the problem persists. So I haven't applied the patch from 2.
>>>>
>>>> FWIW I dumped more info about the wq:
>>>> wq->name='hci0' pwq=ffff8800390d7600 wq->dfl_pwq=ffff8800390d5200
>>>> pwq->refcnt=2 pwq->nr_active=0 delayed_works: <nothing>
>>>
>>> Can you please print out the same info for all pwq's during shutdown?
>>> It looks like we're leaking pwq refcnt but I can't spot a place where
>>> that could happen on an empty pwq.
>>
>> I have not done that yet, but today, I see:
>> destroy_workqueue: name='req_hci0' pwq=ffff88002f590300
>> wq->dfl_pwq=ffff88002f591e00 pwq->refcnt=2 pwq->nr_active=0 delayed_works:
>> pwq 12: cpus=0-1 node=0 flags=0x4 nice=-20 active=0/1
>> in-flight: 18568:wq_barrier_func
>
> So, this means that there's flush_work() racing against workqueue
> destruction, which can't be safe. :(
But I cannot trigger the WARN_ONs in the attached patch, so I am
confused how this can happen :(. (While I am still seeing the destroy
WARNINGs.)
BTW. what did you mean by dumping the states at shutdown? Is it still
relevant?
thanks,
--
js
suse labs
[-- Attachment #2: vhci_debug.patch --]
[-- Type: text/x-patch, Size: 7549 bytes --]
---
include/linux/workqueue.h | 1 +
include/net/bluetooth/hci_core.h | 5 +++++
kernel/reboot.c | 1 +
kernel/workqueue.c | 34 +++++++++++++++++++++++++++++++---
net/bluetooth/hci_core.c | 39 +++++++++++++++++++++++++++++++++++----
5 files changed, 73 insertions(+), 7 deletions(-)
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -312,6 +312,7 @@ enum {
__WQ_DRAINING = 1 << 16, /* internal: workqueue is draining */
__WQ_ORDERED = 1 << 17, /* internal: workqueue is ordered */
__WQ_LEGACY = 1 << 18, /* internal: create*_workqueue() */
+ __WQ_DESTROYING = 1 << 19,
WQ_MAX_ACTIVE = 512, /* I like 512, better ideas? */
WQ_MAX_UNBOUND_PER_CPU = 4, /* 4 * #cpus for unbound wq */
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -312,6 +312,11 @@ struct hci_dev {
struct workqueue_struct *workqueue;
struct workqueue_struct *req_workqueue;
+#define HCI_WQ_A 0
+#define HCI_WQ_D 1
+#define HCI_WQR_A 8
+#define HCI_WQR_D 9
+ unsigned long wq_status;
struct work_struct power_on;
struct delayed_work power_off;
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -231,6 +231,7 @@ static void kernel_shutdown_prepare(enum
(state == SYSTEM_HALT) ? SYS_HALT : SYS_POWER_OFF, NULL);
system_state = state;
usermodehelper_disable();
+ show_workqueue_state();
device_shutdown();
}
/**
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1366,6 +1366,9 @@ static void __queue_work(int cpu, struct
unsigned int work_flags;
unsigned int req_cpu = cpu;
+ if (WARN_ON(wq->flags & __WQ_DESTROYING))
+ return;
+
/*
* While a work item is PENDING && off queue, a task trying to
* steal the PENDING will busy-loop waiting for it to either get
@@ -2804,6 +2807,9 @@ static bool start_flush_work(struct work
pwq = worker->current_pwq;
}
+ if (WARN_ON(pwq->wq->flags & __WQ_DESTROYING))
+ return false;
+
check_flush_dependency(pwq->wq, work);
insert_wq_barrier(pwq, barr, work, worker);
@@ -2821,6 +2827,8 @@ static bool start_flush_work(struct work
lock_map_acquire_read(&pwq->wq->lockdep_map);
lock_map_release(&pwq->wq->lockdep_map);
+ WARN_ON(pwq->wq->flags & __WQ_DESTROYING);
+
return true;
already_gone:
spin_unlock_irq(&pool->lock);
@@ -3998,6 +4006,8 @@ err_destroy:
}
EXPORT_SYMBOL_GPL(__alloc_workqueue_key);
+static void show_pwq(struct pool_workqueue *pwq);
+
/**
* destroy_workqueue - safely terminate a workqueue
* @wq: target workqueue
@@ -4010,6 +4020,7 @@ void destroy_workqueue(struct workqueue_
int node;
/* drain it before proceeding with destruction */
+ wq->flags |= __WQ_DESTROYING;
drain_workqueue(wq);
/* sanity checks */
@@ -4024,9 +4035,26 @@ void destroy_workqueue(struct workqueue_
}
}
- if (WARN_ON((pwq != wq->dfl_pwq) && (pwq->refcnt > 1)) ||
- WARN_ON(pwq->nr_active) ||
- WARN_ON(!list_empty(&pwq->delayed_works))) {
+ if ((pwq != wq->dfl_pwq) && (pwq->refcnt > 1)) {
+ pr_info("%s: name='%s' pwq=%p wq->dfl_pwq=%p pwq->refcnt=%d pwq->nr_active=%d delayed_works:",
+ __func__, wq->name, pwq, wq->dfl_pwq,
+ pwq->refcnt, pwq->nr_active);
+
+ show_pwq(pwq);
+
+ mutex_unlock(&wq->mutex);
+ WARN_ON(1);
+ return;
+ }
+
+ if (WARN_ON(pwq->nr_active)) {
+ pr_info("%s: %ps\n", __func__, wq);
+ mutex_unlock(&wq->mutex);
+ return;
+ }
+
+ if (WARN_ON(!list_empty(&pwq->delayed_works))) {
+ pr_info("%s: %ps\n", __func__, wq);
mutex_unlock(&wq->mutex);
return;
}
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1471,7 +1471,11 @@ int hci_dev_open(__u16 dev)
* has finished. This means that error conditions like RFKILL
* or no valid public or static random address apply.
*/
+ WARN_ON(test_bit(HCI_WQR_D, &hdev->wq_status));
+ WARN_ON(!test_bit(HCI_WQR_A, &hdev->wq_status));
flush_workqueue(hdev->req_workqueue);
+ WARN_ON(test_bit(HCI_WQR_D, &hdev->wq_status));
+ WARN_ON(!test_bit(HCI_WQR_A, &hdev->wq_status));
/* For controllers not using the management interface and that
* are brought up using legacy ioctl, set the HCI_BONDABLE bit
@@ -2467,6 +2471,8 @@ static void hci_cmd_timeout(struct work_
struct hci_dev *hdev = container_of(work, struct hci_dev,
cmd_timer.work);
+ if (WARN_ON(hci_dev_test_flag(hdev, HCI_UNREGISTER)))
+ return;
if (hdev->sent_cmd) {
struct hci_command_hdr *sent = (void *) hdev->sent_cmd->data;
u16 opcode = __le16_to_cpu(sent->opcode);
@@ -3043,15 +3049,17 @@ int hci_register_dev(struct hci_dev *hde
BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
- hdev->workqueue = alloc_workqueue("%s", WQ_HIGHPRI | WQ_UNBOUND |
- WQ_MEM_RECLAIM, 1, hdev->name);
+ hdev->workqueue = alloc_workqueue("%s", WQ_HIGHPRI | WQ_UNBOUND
+ , 1, hdev->name);
+ set_bit(HCI_WQ_A, &hdev->wq_status);
if (!hdev->workqueue) {
error = -ENOMEM;
goto err;
}
- hdev->req_workqueue = alloc_workqueue("%s", WQ_HIGHPRI | WQ_UNBOUND |
- WQ_MEM_RECLAIM, 1, hdev->name);
+ hdev->req_workqueue = alloc_workqueue("req_%s", WQ_HIGHPRI | WQ_UNBOUND
+ , 1, hdev->name);
+ set_bit(HCI_WQR_A, &hdev->wq_status);
if (!hdev->req_workqueue) {
destroy_workqueue(hdev->workqueue);
error = -ENOMEM;
@@ -3108,8 +3116,12 @@ int hci_register_dev(struct hci_dev *hde
return id;
err_wqueue:
+ set_bit(HCI_WQ_D, &hdev->wq_status);
destroy_workqueue(hdev->workqueue);
+ clear_bit(HCI_WQ_A, &hdev->wq_status);
+ set_bit(HCI_WQR_D, &hdev->wq_status);
destroy_workqueue(hdev->req_workqueue);
+ clear_bit(HCI_WQR_A, &hdev->wq_status);
err:
ida_simple_remove(&hci_index_ida, hdev->id);
@@ -3160,7 +3172,9 @@ void hci_unregister_dev(struct hci_dev *
debugfs_remove_recursive(hdev->debugfs);
destroy_workqueue(hdev->workqueue);
+ set_bit(HCI_WQR_D, &hdev->wq_status);
destroy_workqueue(hdev->req_workqueue);
+ clear_bit(HCI_WQR_A, &hdev->wq_status);
hci_dev_lock(hdev);
hci_bdaddr_list_clear(&hdev->blacklist);
@@ -3225,6 +3239,11 @@ int hci_recv_frame(struct hci_dev *hdev,
return -ENXIO;
}
+ if (WARN_ON(hci_dev_test_flag(hdev, HCI_UNREGISTER))) {
+ kfree_skb(skb);
+ return -ENXIO;
+ }
+
if (hci_skb_pkt_type(skb) != HCI_EVENT_PKT &&
hci_skb_pkt_type(skb) != HCI_ACLDATA_PKT &&
hci_skb_pkt_type(skb) != HCI_SCODATA_PKT) {
@@ -3248,6 +3267,9 @@ EXPORT_SYMBOL(hci_recv_frame);
/* Receive diagnostic message from HCI drivers */
int hci_recv_diag(struct hci_dev *hdev, struct sk_buff *skb)
{
+ if (WARN_ON(hci_dev_test_flag(hdev, HCI_UNREGISTER)))
+ return -ENXIO;
+
/* Mark as diagnostic packet */
hci_skb_pkt_type(skb) = HCI_DIAG_PKT;
@@ -3326,6 +3348,9 @@ int hci_send_cmd(struct hci_dev *hdev, _
{
struct sk_buff *skb;
+ if (WARN_ON(hci_dev_test_flag(hdev, HCI_UNREGISTER)))
+ return -ENXIO;
+
BT_DBG("%s opcode 0x%4.4x plen %d", hdev->name, opcode, plen);
skb = hci_prepare_cmd(hdev, opcode, plen, param);
@@ -3461,6 +3486,9 @@ void hci_send_acl(struct hci_chan *chan,
{
struct hci_dev *hdev = chan->conn->hdev;
+ if (WARN_ON(hci_dev_test_flag(hdev, HCI_UNREGISTER)))
+ return;
+
BT_DBG("%s chan %p flags 0x%4.4x", hdev->name, chan, flags);
hci_queue_acl(chan, &chan->data_q, skb, flags);
@@ -3474,6 +3502,9 @@ void hci_send_sco(struct hci_conn *conn,
struct hci_dev *hdev = conn->hdev;
struct hci_sco_hdr hdr;
+ if (WARN_ON(hci_dev_test_flag(hdev, HCI_UNREGISTER)))
+ return;
+
BT_DBG("%s len %d", hdev->name, skb->len);
hdr.handle = cpu_to_le16(conn->handle);
^ 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