* Re: Significant capacity drop on loopback interface
From: Stephen Hemminger @ 2018-05-10 15:18 UTC (permalink / raw)
To: Naruto Nguyen; +Cc: netdev@vger.kernel.org
In-Reply-To: <CANpxKHFKqL+n596Liw7kzJpV3K+CqT9o+R9ynNoy+rPDwj1YNA@mail.gmail.com>
On Thu, 10 May 2018 22:03:33 +0700
Naruto Nguyen <narutonguyen2018@gmail.com> wrote:
> Hi Stephen,
>
> Thanks for your responding. But as I know kernel 4.4.104 has not included
> Spectre/Meltdown fix yet, right?
Yes. 4.4.104 doesn't have KPTI.
That came in around 4.4.109
^ permalink raw reply
* Re: STMMAC driver with TSO enabled issue
From: Bhadram Varka @ 2018-05-10 15:08 UTC (permalink / raw)
To: Jose Abreu, netdev@vger.kernel.org, Joao Pinto
In-Reply-To: <f423213d-4092-f77a-3bc5-4f4198bb222c@synopsys.com>
Hi Jose,
On 5/10/2018 7:59 PM, Jose Abreu wrote:
> Hi Bhadram,
>
> On 10-05-2018 09:55, Jose Abreu wrote:
>> ++net-dev
>>
>> Hi Bhadram,
>>
>> On 09-05-2018 12:03, Bhadram Varka wrote:
>>> Hi,
>>>
>>> Thanks for responding.
>>>
>>> Tried below suggested way. Still observing the issue -
>> It seems stmmac has a bug in the RX side when using TSO which is
>> causing all the RX descriptors to be consumed. The stmmac_rx()
>> function will need to be refactored. I will send a fix ASAP.
>
> Are you using this patch [1] ? Because there is a problem with
> the patch. By adding the previously removed call to
> stmmac_init_rx_desc() TSO works okay in my setup.
>
No. I don't have this change in my code base. I am using net-next tree.
Can you please post the change for which TSO works ? I can help you with
the testing.
--
Thanks,
Bhadram.
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Tariq Toukan @ 2018-05-10 15:03 UTC (permalink / raw)
To: Dan Carpenter, Yuval Shaia
Cc: Christophe JAILLET, davem, netdev, linux-rdma, linux-kernel,
kernel-janitors
In-Reply-To: <f29e851d-c4d7-cd04-dbb7-582adebc2854@mellanox.com>
On 10/05/2018 5:36 PM, Tariq Toukan wrote:
>
>
> On 10/05/2018 5:18 PM, Dan Carpenter wrote:
>> On Thu, May 10, 2018 at 04:38:08PM +0300, Yuval Shaia wrote:
>>> On Thu, May 10, 2018 at 09:02:26AM +0200, Christophe JAILLET wrote:
>>>> If an error occurs, 'mlx4_en_destroy_netdev()' is called.
>>>> It then calls 'mlx4_en_free_resources()' which does the needed
>>>> resources
>>>> cleanup.
>>>>
>>>> So, doing some explicit kfree in the error handling path would lead to
>>>> some double kfree.
>>>
>>> Patch make sense but what's bothering me is that mlx4_en_free_resources
>>> loops on the entire array, assuming !priv->tx_ring[t] means entry is
>>> allocated but the existing code does not assume that, see [1]. So i
>>> looked
>>> to see where tx_ring array is zeroed and didn't find it.
>>>
>>> Am i missing something here.
>>>
>>
>> It's zeroed twice. alloc_etherdev_mqs() allocates zeroed memory and
>> then we do a memset(priv, 0, sizeof(struct mlx4_en_priv));
>>
>> regards,
>> dan carpenter
>>
>
> We do zero (twice) on init, that's right. But I think Yuval's comment is
> valid in case of the driver went into configuration change, or down/up,
> that reallocates the rings. I'm double checking this.
Well, the flows in which we need to nullify the tx_rings pointer (if
any, I still need to investigate this) is not related to this init function.
Here we're safe.
Anyway, a V2 is already submitted, please use it for your next comments.
I think patch is OK.
^ permalink raw reply
* Re: Significant capacity drop on loopback interface
From: Stephen Hemminger @ 2018-05-10 14:58 UTC (permalink / raw)
To: Naruto Nguyen; +Cc: netdev
In-Reply-To: <CANpxKHFZPEOgE21oPM2WHF97jhD8w3-N-wdycSPEnOeMPwREsQ@mail.gmail.com>
On Thu, 10 May 2018 15:35:59 +0700
Naruto Nguyen <narutonguyen2018@gmail.com> wrote:
> Hello everyone,
>
> Recently, I used netperf to test the TCP performance on loopback
> interface on my 2 nodes, one is installed kernel 4.4.103 and the other
> is 3.12.61
>
> netperf -l 100 -t TCP_RR
> netperf -l 100 -t TCP_RR -- -D
>
> In both cases, I see that the throughput on 4.4.103 is about just 1/2
> in comparing with 3.12.61 node
>
> # netperf -l 100 -t TCP_RR
> MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0
> AF_INET to localhost () port 0 AF_INET : first burst 0
> Local /Remote
> Socket Size Request Resp. Elapsed Trans.
> Send Recv Size Size Time Rate
> bytes Bytes bytes bytes secs. per sec
>
> 16384 87380 1 1 100.00 37714.68
> 16384 87380
>
>
> netperf -l 100 -t TCP_RR
> MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0
> AF_INET to localhost () port 0 AF_INET : first burst 0
> Local /Remote
> Socket Size Request Resp. Elapsed Trans.
> Send Recv Size Size Time Rate
> bytes Bytes bytes bytes secs. per sec
>
> 16384 87380 1 1 100.00 64038.41
> 16384 87380
>
>
> When running tcpdump to capture all packets in loopback interface, I
> see that during 200s capture, the number of packets on loopback of
> 4.4.103 is double the number of packets in 3.12.61? Could you please
> let me know if it can cause the low throughput as above? Do we have
> any tuning for TCP on loopback to improve the performace (actually the
> low throughput also happens with UDP) or if we have any known
> performance issue in 4.4 kernel on loopback?
>
> Thanks a lot,
> Brs,
> Naruto
This might just be the increased overhead of KPTI to fix Spectre/Meltdown.
Loopback is very sensitive to syscall overhead.
^ permalink raw reply
* Re: [PATCH] net: aquantia: Fix an error handling path in 'aq_pci_probe()'
From: Christophe JAILLET @ 2018-05-10 14:38 UTC (permalink / raw)
To: Igor Russkikh, davem, pavel.belous, weiyongjun1, dan.carpenter
Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <a784ae7f-cd9c-4141-f862-0c01f61d0200@aquantia.com>
Le 08/05/2018 à 09:19, Igor Russkikh a écrit :
>
> This was just submitted yesterday and is already accepted in netdev by David:
>
> http://patchwork.ozlabs.org/patch/909746/
>
> Thanks!
>
> BR, Igor
>
Patch timing is sometimes surprising!
Not sure at all if it can be an issue, but I also noted that the order
of 'pci_release_regions()' and 'free_netdev()' is in reverse
order in the 'aq_pci_remove()' function.
I don't know if done on purpose and/or needed, so I've left it as-is.
CJ
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Tariq Toukan @ 2018-05-10 14:36 UTC (permalink / raw)
To: Dan Carpenter, Yuval Shaia
Cc: Christophe JAILLET, davem, tariqt, netdev, linux-rdma,
linux-kernel, kernel-janitors
In-Reply-To: <20180510141836.2qlm676j4675buti@mwanda>
On 10/05/2018 5:18 PM, Dan Carpenter wrote:
> On Thu, May 10, 2018 at 04:38:08PM +0300, Yuval Shaia wrote:
>> On Thu, May 10, 2018 at 09:02:26AM +0200, Christophe JAILLET wrote:
>>> If an error occurs, 'mlx4_en_destroy_netdev()' is called.
>>> It then calls 'mlx4_en_free_resources()' which does the needed resources
>>> cleanup.
>>>
>>> So, doing some explicit kfree in the error handling path would lead to
>>> some double kfree.
>>
>> Patch make sense but what's bothering me is that mlx4_en_free_resources
>> loops on the entire array, assuming !priv->tx_ring[t] means entry is
>> allocated but the existing code does not assume that, see [1]. So i looked
>> to see where tx_ring array is zeroed and didn't find it.
>>
>> Am i missing something here.
>>
>
> It's zeroed twice. alloc_etherdev_mqs() allocates zeroed memory and
> then we do a memset(priv, 0, sizeof(struct mlx4_en_priv));
>
> regards,
> dan carpenter
>
We do zero (twice) on init, that's right. But I think Yuval's comment is
valid in case of the driver went into configuration change, or down/up,
that reallocates the rings. I'm double checking this.
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Christophe JAILLET @ 2018-05-10 14:35 UTC (permalink / raw)
To: Yuval Shaia
Cc: davem, tariqt, netdev, linux-rdma, linux-kernel, kernel-janitors
In-Reply-To: <20180510133808.GA10943@lap1>
Le 10/05/2018 à 15:38, Yuval Shaia a écrit :
> On Thu, May 10, 2018 at 09:02:26AM +0200, Christophe JAILLET wrote:
>> If an error occurs, 'mlx4_en_destroy_netdev()' is called.
>> It then calls 'mlx4_en_free_resources()' which does the needed resources
>> cleanup.
>>
>> So, doing some explicit kfree in the error handling path would lead to
>> some double kfree.
> Patch make sense but what's bothering me is that mlx4_en_free_resources
> loops on the entire array, assuming !priv->tx_ring[t] means entry is
> allocated but the existing code does not assume that, see [1]. So i looked
> to see where tx_ring array is zeroed and didn't find it.
>
> Am i missing something here.
My understanding is that the array is zeoed at line 3289, when the whole
priv struct is memset(0)'ed (also done in alloc_etherdev_mqs but leaving
an explicit memset help to remind that the struct is zeroed)
If speed matters here (and I don't think so), the memset could be saved
(the mlx4_en_priv struct is quite big after all), but at least a comment
should remind that it is initialized within alloc_etherdev_mqs.
CJ
>> Simplify code to avoid such a case.
>>
>> Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 8 +-------
>> 1 file changed, 1 insertion(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>> index e0adac4a9a19..9670b33fc9b1 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>> @@ -3324,12 +3324,11 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
>> MAX_TX_RINGS, GFP_KERNEL);
>> if (!priv->tx_ring[t]) {
>> err = -ENOMEM;
>> - goto err_free_tx;
>> + goto out;
>> }
>> priv->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
>> MAX_TX_RINGS, GFP_KERNEL);
>> if (!priv->tx_cq[t]) {
>> - kfree(priv->tx_ring[t]);
>> err = -ENOMEM;
>> goto out;
>> }
>> @@ -3582,11 +3581,6 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
>>
>> return 0;
>>
>> -err_free_tx:
>> - while (t--) {
> [1]
>
>> - kfree(priv->tx_ring[t]);
>> - kfree(priv->tx_cq[t]);
>> - }
>> out:
>> mlx4_en_destroy_netdev(dev);
>> return err;
>> --
>> 2.17.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 08/10] net: stmmac: Do not initialize the RX Descriptor twice
From: Jose Abreu @ 2018-05-10 14:33 UTC (permalink / raw)
To: Jose Abreu, netdev
Cc: David S. Miller, Joao Pinto, Vitor Soares, Giuseppe Cavallaro,
Alexandre Torgue
In-Reply-To: <8dc038066ee0fbb30f1a82bce5e2e9118b13ce01.1525683833.git.joabreu@synopsys.com>
On 08-05-2018 15:45, Jose Abreu wrote:
> The RX Descriptor is already initialized in at setup phase so there is
> no need to set the values again, we just need to set the owner. This
> allow us to remove another if condition.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: Vitor Soares <soares@synopsys.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index c5769b4..80439be 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3255,10 +3255,7 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv, u32 queue)
> }
> dma_wmb();
>
> - if (unlikely(priv->synopsys_id >= DWMAC_CORE_4_00))
> - stmmac_init_rx_desc(priv, p, priv->use_riwt, 0, 0);
This cant be removed. Please don't merge it.
Thanks and Best Regards,
Jose Miguel Abreu
> - else
> - stmmac_set_rx_owner(priv, p);
> + stmmac_set_rx_owner(priv, p);
>
> dma_wmb();
>
^ permalink raw reply
* [PATCH] rsi: fix spelling mistake: "thead" -> "thread"
From: Colin King @ 2018-05-10 14:32 UTC (permalink / raw)
To: Kalle Valo, David S . Miller, Amitkumar Karwar,
Prameela Rani Garnepudi, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in rsi_dbg debug message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/rsi/rsi_91x_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_core.c b/drivers/net/wireless/rsi/rsi_91x_core.c
index 1f1b97220d43..3644d7d99463 100644
--- a/drivers/net/wireless/rsi/rsi_91x_core.c
+++ b/drivers/net/wireless/rsi/rsi_91x_core.c
@@ -485,7 +485,7 @@ void rsi_core_xmit(struct rsi_common *common, struct sk_buff *skb)
}
rsi_core_queue_pkt(common, skb);
- rsi_dbg(DATA_TX_ZONE, "%s: ===> Scheduling TX thead <===\n", __func__);
+ rsi_dbg(DATA_TX_ZONE, "%s: ===> Scheduling TX thread <===\n", __func__);
rsi_set_event(&common->tx_thread.event);
return;
--
2.17.0
^ permalink raw reply related
* Re: STMMAC driver with TSO enabled issue
From: Jose Abreu @ 2018-05-10 14:29 UTC (permalink / raw)
To: Bhadram Varka, Jose Abreu, netdev@vger.kernel.org, Joao Pinto
In-Reply-To: <77c98a42-195f-b597-711d-8c2e8b55f266@synopsys.com>
Hi Bhadram,
On 10-05-2018 09:55, Jose Abreu wrote:
> ++net-dev
>
> Hi Bhadram,
>
> On 09-05-2018 12:03, Bhadram Varka wrote:
>> Hi,
>>
>> Thanks for responding.
>>
>> Tried below suggested way. Still observing the issue -
> It seems stmmac has a bug in the RX side when using TSO which is
> causing all the RX descriptors to be consumed. The stmmac_rx()
> function will need to be refactored. I will send a fix ASAP.
Are you using this patch [1] ? Because there is a problem with
the patch. By adding the previously removed call to
stmmac_init_rx_desc() TSO works okay in my setup.
[1] https://patchwork.ozlabs.org/patch/910224/
>
> Thanks and Best Regards,
> Jose Miguel Abreu
>
>> [root@alarm ~]# iperf3 -c 10.19.65.141
>> Connecting to host 10.19.65.141, port 5201
>> [ 5] local 10.19.65.210 port 57630 connected to 10.19.65.141
>> port 5201
>> [ 65.408268] stmmac_tso_xmit(): line = 2842
>> [ 65.412362] stmmac_tso_xmit: tcphdrlen 32, hdr_len 66,
>> pay_len 0, mss 1448
>> [ 65.419224] skb->len 8754, skb->data_len 8688
>> [ 65.423672] stmmac_tso_xmit: curr=20 dirty=17 f=18, e=20,
>> f_p=00000000178e52e1, nfrags 1
>> [ 65.431747] TX descriptor ring:
>> [ 65.434881] 000 [0x82005000]: 0x0 0x0 0x0 0x0
>> [ 65.439230] 001 [0x82005010]: 0x0 0x0 0x0 0x0
>> [ 65.443578] 002 [0x82005020]: 0x0 0x0 0x0 0x0
>> [ 65.447927] 003 [0x82005030]: 0x0 0x0 0x0 0x0
>> [ 65.452275] 004 [0x82005040]: 0x0 0x0 0x0 0x0
>> [ 65.456622] 005 [0x82005050]: 0x0 0x0 0x0 0x0
>> [ 65.460970] 006 [0x82005060]: 0x0 0x0 0x0 0x0
>> [ 65.465316] 007 [0x82005070]: 0x0 0x0 0x0 0x0
>> [ 65.469664] 008 [0x82005080]: 0x0 0x0 0x0 0x0
>> [ 65.474010] 009 [0x82005090]: 0x0 0x0 0x0 0x0
>> [ 65.478357] 010 [0x820050a0]: 0x0 0x0 0x0 0x0
>> [ 65.482706] 011 [0x820050b0]: 0x0 0x0 0x0 0x0
>> [ 65.487053] 012 [0x820050c0]: 0x0 0x0 0x0 0x0
>> [ 65.491400] 013 [0x820050d0]: 0x0 0x0 0x0 0x0
>> [ 65.495746] 014 [0x820050e0]: 0x0 0x0 0x0 0x0
>> [ 65.500092] 015 [0x820050f0]: 0x0 0x0 0x0 0x0
>> [ 65.504438] 016 [0x82005100]: 0x0 0x0 0x0 0x0
>> [ 65.508784] 017 [0x82005110]: 0x0 0x0 0x5a8 0xc4000000
>> [ 65.513910] 018 [0x82005120]: 0xfb297000 0x0 0x42 0xa04421f0
>> [ 65.519557] 019 [0x82005130]: 0xfb298000 0x0 0x21f0 0x90000000
>> [ 65.525376] 020 [0x82005140]: 0x0 0x0 0x0 0x0
>> [ 65.529722] 021 [0x82005150]: 0x0 0x0 0x0 0x0
>> [ 65.534069] 022 [0x82005160]: 0x0 0x0 0x0 0x0
>> [ 65.538414] 023 [0x82005170]: 0x0 0x0 0x0 0x0
>> [ 65.542761] 024 [0x82005180]: 0x0 0x0 0x0 0x0
>> [ 65.547107] 025 [0x82005190]: 0x0 0x0 0x0 0x0
>> [ 65.551454] 026 [0x820051a0]: 0x0 0x0 0x0 0x0
>> [ 65.555802] 027 [0x820051b0]: 0x0 0x0 0x0 0x0
>> [ 65.560147] 028 [0x820051c0]: 0x0 0x0 0x0 0x0
>> [ 65.564493] 029 [0x820051d0]: 0x0 0x0 0x0 0x0
>> [ 65.568840] 030 [0x820051e0]: 0x0 0x0 0x0 0x0
>> [ 65.573187] 031 [0x820051f0]: 0x0 0x0 0x0 0x0
>> [ 65.577533] 032 [0x82005200]: 0x0 0x0 0x0 0x0
>> [ 65.581879] 033 [0x82005210]: 0x0 0x0 0x0 0x0
>> [ 65.586225] 034 [0x82005220]: 0x0 0x0 0x0 0x0
>> [ 65.590571] 035 [0x82005230]: 0x0 0x0 0x0 0x0
>> [ 65.594917] 036 [0x82005240]: 0x0 0x0 0x0 0x0
>> [ 65.599262] 037 [0x82005250]: 0x0 0x0 0x0 0x0
>> [ 65.603607] 038 [0x82005260]: 0x0 0x0 0x0 0x0
>> [ 65.607952] 039 [0x82005270]: 0x0 0x0 0x0 0x0
>> [ 65.612297] 040 [0x82005280]: 0x0 0x0 0x0 0x0
>> [ 65.616643] 041 [0x82005290]: 0x0 0x0 0x0 0x0
>> [ 65.620989] 042 [0x820052a0]: 0x0 0x0 0x0 0x0
>> [ 65.625336] 043 [0x820052b0]: 0x0 0x0 0x0 0x0
>> [ 65.629681] 044 [0x820052c0]: 0x0 0x0 0x0 0x0
>> [ 65.634027] 045 [0x820052d0]: 0x0 0x0 0x0 0x0
>> [ 65.638372] 046 [0x820052e0]: 0x0 0x0 0x0 0x0
>> [ 65.642718] 047 [0x820052f0]: 0x0 0x0 0x0 0x0
>> [ 65.647063] 048 [0x82005300]: 0x0 0x0 0x0 0x0
>> [ 65.651408] 049 [0x82005310]: 0x0 0x0 0x0 0x0
>> [ 65.655754] 050 [0x82005320]: 0x0 0x0 0x0 0x0
>> [ 65.660099] 051 [0x82005330]: 0x0 0x0 0x0 0x0
>> [ 65.664444] 052 [0x82005340]: 0x0 0x0 0x0 0x0
>> [ 65.668790] 053 [0x82005350]: 0x0 0x0 0x0 0x0
>> [ 65.673134] 054 [0x82005360]: 0x0 0x0 0x0 0x0
>> [ 65.677480] 055 [0x82005370]: 0x0 0x0 0x0 0x0
>> [ 65.681825] 056 [0x82005380]: 0x0 0x0 0x0 0x0
>> [ 65.686170] 057 [0x82005390]: 0x0 0x0 0x0 0x0
>> [ 65.690515] 058 [0x820053a0]: 0x0 0x0 0x0 0x0
>> [ 65.694861] 059 [0x820053b0]: 0x0 0x0 0x0 0x0
>> [ 65.699206] 060 [0x820053c0]: 0x0 0x0 0x0 0x0
>> [ 65.703552] 061 [0x820053d0]: 0x0 0x0 0x0 0x0
>> [ 65.707898] 062 [0x820053e0]: 0x0 0x0 0x0 0x0
>> [ 65.712243] 063 [0x820053f0]: 0x0 0x0 0x0 0x0
>> [ 65.716706] stmmac_tso_xmit(): line = 2842
>> [ 65.720802] stmmac_tso_xmit: tcphdrlen 32, hdr_len 66,
>> pay_len 0, mss 1448
>> [ 65.727669] skb->len 4410, skb->data_len 4344
>> [ 65.732114] stmmac_tso_xmit: curr=22 dirty=19 f=20, e=22,
>> f_p=00000000b1247b41, nfrags 1
>> [ 65.740190] TX descriptor ring:
>> [ 65.743327] 000 [0x82005000]: 0x0 0x0 0x0 0x0
>> [ 65.747678] 001 [0x82005010]: 0x0 0x0 0x0 0x0
>> [ 65.752029] 002 [0x82005020]: 0x0 0x0 0x0 0x0
>> [ 65.756378] 003 [0x82005030]: 0x0 0x0 0x0 0x0
>> [ 65.760727] 004 [0x82005040]: 0x0 0x0 0x0 0x0
>> [ 65.765077] 005 [0x82005050]: 0x0 0x0 0x0 0x0
>> [ 65.769427] 006 [0x82005060]: 0x0 0x0 0x0 0x0
>> [ 65.773776] 007 [0x82005070]: 0x0 0x0 0x0 0x0
>> [ 65.778126] 008 [0x82005080]: 0x0 0x0 0x0 0x0
>> [ 65.782476] 009 [0x82005090]: 0x0 0x0 0x0 0x0
>> [ 65.786826] 010 [0x820050a0]: 0x0 0x0 0x0 0x0
>> [ 65.791176] 011 [0x820050b0]: 0x0 0x0 0x0 0x0
>> [ 65.795526] 012 [0x820050c0]: 0x0 0x0 0x0 0x0
>> [ 65.799875] 013 [0x820050d0]: 0x0 0x0 0x0 0x0
>> [ 65.804225] 014 [0x820050e0]: 0x0 0x0 0x0 0x0
>> [ 65.808575] 015 [0x820050f0]: 0x0 0x0 0x0 0x0
>> [ 65.812925] 016 [0x82005100]: 0x0 0x0 0x0 0x0
>> [ 65.817274] 017 [0x82005110]: 0x0 0x0 0x0 0x0
>> [ 65.821625] 018 [0x82005120]: 0x0 0x0 0x0 0x0
>> [ 65.825976] 019 [0x82005130]: 0xfb298000 0x0 0x21f0 0x90000000
>> [ 65.831800] 020 [0x82005140]: 0xfb2a1000 0x0 0x42 0xa04410f8
>> [ 65.837450] 021 [0x82005150]: 0xfb2a2000 0x0 0x10f8 0x90000000
>> [ 65.843273] 022 [0x82005160]: 0x0 0x0 0x0 0x0
>> [ 65.847622] 023 [0x82005170]: 0x0 0x0 0x0 0x0
>> [ 65.851971] 024 [0x82005180]: 0x0 0x0 0x0 0x0
>> [ 65.856319] 025 [0x82005190]: 0x0 0x0 0x0 0x0
>> [ 65.860670] 026 [0x820051a0]: 0x0 0x0 0x0 0x0
>> [ 65.865020] 027 [0x820051b0]: 0x0 0x0 0x0 0x0
>> [ 65.869369] 028 [0x820051c0]: 0x0 0x0 0x0 0x0
>> [ 65.873719] 029 [0x820051d0]: 0x0 0x0 0x0 0x0
>> [ 65.878068] 030 [0x820051e0]: 0x0 0x0 0x0 0x0
>> [ 65.882418] 031 [0x820051f0]: 0x0 0x0 0x0 0x0
>> [ 65.886767] 032 [0x82005200]: 0x0 0x0 0x0 0x0
>> [ 65.891118] 033 [0x82005210]: 0x0 0x0 0x0 0x0
>> [ 65.895467] 034 [0x82005220]: 0x0 0x0 0x0 0x0
>> [ 65.899816] 035 [0x82005230]: 0x0 0x0 0x0 0x0
>> [ 65.904165] 036 [0x82005240]: 0x0 0x0 0x0 0x0
>> [ 65.908515] 037 [0x82005250]: 0x0 0x0 0x0 0x0
>> [ 65.912865] 038 [0x82005260]: 0x0 0x0 0x0 0x0
>> [ 65.917215] 039 [0x82005270]: 0x0 0x0 0x0 0x0
>> [ 65.921564] 040 [0x82005280]: 0x0 0x0 0x0 0x0
>> [ 65.925915] 041 [0x82005290]: 0x0 0x0 0x0 0x0
>> [ 65.930264] 042 [0x820052a0]: 0x0 0x0 0x0 0x0
>> [ 65.934615] 043 [0x820052b0]: 0x0 0x0 0x0 0x0
>> [ 65.938964] 044 [0x820052c0]: 0x0 0x0 0x0 0x0
>> [ 65.943313] 045 [0x820052d0]: 0x0 0x0 0x0 0x0
>> [ 65.947664] 046 [0x820052e0]: 0x0 0x0 0x0 0x0
>> [ 65.952012] 047 [0x820052f0]: 0x0 0x0 0x0 0x0
>> [ 65.956363] 048 [0x82005300]: 0x0 0x0 0x0 0x0
>> [ 65.960712] 049 [0x82005310]: 0x0 0x0 0x0 0x0
>> [ 65.965061] 050 [0x82005320]: 0x0 0x0 0x0 0x0
>> [ 65.969410] 051 [0x82005330]: 0x0 0x0 0x0 0x0
>> [ 65.973760] 052 [0x82005340]: 0x0 0x0 0x0 0x0
>> [ 65.978110] 053 [0x82005350]: 0x0 0x0 0x0 0x0
>> [ 65.982460] 054 [0x82005360]: 0x0 0x0 0x0 0x0
>> [ 65.986812] 055 [0x82005370]: 0x0 0x0 0x0 0x0
>> [ 65.991161] 056 [0x82005380]: 0x0 0x0 0x0 0x0
>> [ 65.995510] 057 [0x82005390]: 0x0 0x0 0x0 0x0
>> [ 65.999860] 058 [0x820053a0]: 0x0 0x0 0x0 0x0
>> [ 66.004210] 059 [0x820053b0]: 0x0 0x0 0x0 0x0
>> [ 66.008559] 060 [0x820053c0]: 0x0 0x0 0x0 0x0
>> [ 66.012908] 061 [0x820053d0]: 0x0 0x0 0x0 0x0
>> [ 66.017257] 062 [0x820053e0]: 0x0 0x0 0x0 0x0
>> [ 66.021607] 063 [0x820053f0]: 0x0 0x0 0x0 0x0
>> [ ID] Interval Transfer Bitrate Retr Cwnd
>> [ 5] 0.00-1.00 sec 184 KBytes 1.50 Mbits/sec 0
>> 1.41 KBytes
>> [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>> [ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41
>> KBytes
>>
>>
>> On 5/9/2018 3:35 PM, Jose Abreu wrote:
>>> Hi Bhadram,
>>>
>>> On 09-05-2018 08:18, Bhadram Varka wrote:
>>>> + queue0 {
>>>> + snps,weight = <0x10>;
>>>> + queue1 {
>>>> + snps,weight = <0x10>;
>>>>
>>>> + queue2 {
>>>> + snps,weight = <0x10>;
>>>>
>>>> + queue3 {
>>>> + snps,weight = <0x10>;
>>>>
>>> This is wrong. You can't use the same weight for all queues.
>>> Please try with different weights (for example: 0x10, 0x11, 0x12,
>>> 0x13).
>>>
>>> Thanks and Best Regards,
>>> Jose Miguel Abreu
>>>
>>>
^ permalink raw reply
* Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not working
From: Andrew Lunn @ 2018-05-10 14:29 UTC (permalink / raw)
To: Michal Vokáč; +Cc: netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <5e8ecfed-c772-5668-4bac-1549143f599a@gmail.com>
> So both the CPU and the switch are trying to talk to each other but their
> frames are not delivered. This still looks like RGMII configuration problem.
Yes, i would say it is.
> As it works with my old PHY driver I suspect the problem is at the switches
> side somewhere in qca8k_set_pad_ctrl or qca8k_setup in the qca8k driver.
>
> Any other ideas?
I would probably add code to dump all the qca8k registers. Compare the
values for your working setup and your non-working setup. Hopefully
they are not too different, and you can quickly get to the bits which
matter.
Andrew
^ permalink raw reply
* Re: [PATCH v1 iproute2-next 2/3] rdma: print driver resource attributes
From: Steve Wise @ 2018-05-10 14:19 UTC (permalink / raw)
To: David Ahern, leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <06375fd7-f241-74ad-70ce-a670100bf060@gmail.com>
On 5/9/2018 11:08 PM, David Ahern wrote:
> On 5/7/18 9:53 AM, Steve Wise wrote:
>> @@ -152,7 +153,10 @@ int main(int argc, char **argv)
>> pretty_output = true;
>> break;
>> case 'd':
>> - show_details = true;
>> + if (show_details)
>> + show_driver_details = true;
>> + else
>> + show_details = true;
>> break;
>> case 'j':
>> json_output = true;
> The above change should be reflected in the man page.
I did mention it in the man page:
-d, --details
Output detailed information. Adding a second -d includes
driver-specific details.
But I wasn't sure how to show it in the syntax. Maybe this?
OPTIONS := { -V[ersion] | -d[etails] [-d[etails]] } -j[son] } -p[retty] }
> Also, the set needs to be respun after I merged master where Stephen
> brought in updates to the uapi files.
Will do. Thanks for reviewing.
Steve.
^ permalink raw reply
* Re: [PATCHv2 1/1] net/mlx4_core: avoid resetting HCA when accessing an offline device
From: Tariq Toukan @ 2018-05-10 14:24 UTC (permalink / raw)
To: Zhu Yanjun, tariqt, netdev, linux-rdma
In-Reply-To: <1524058303-379-1-git-send-email-yanjun.zhu@oracle.com>
On 18/04/2018 4:31 PM, Zhu Yanjun wrote:
> While a faulty cable is used or HCA firmware error, HCA device will
> be offline. When the driver is accessing this offline device, the
> following call trace will pop out.
>
> "
> ...
> [<ffffffff816e4842>] dump_stack+0x63/0x81
> [<ffffffff816e459e>] panic+0xcc/0x21b
> [<ffffffffa03e5f8a>] mlx4_enter_error_state+0xba/0xf0 [mlx4_core]
> [<ffffffffa03e7298>] mlx4_cmd_reset_flow+0x38/0x60 [mlx4_core]
> [<ffffffffa03e7381>] mlx4_cmd_poll+0xc1/0x2e0 [mlx4_core]
> [<ffffffffa03e9f00>] __mlx4_cmd+0xb0/0x160 [mlx4_core]
> [<ffffffffa0406934>] mlx4_SENSE_PORT+0x54/0xd0 [mlx4_core]
> [<ffffffffa03f5f54>] mlx4_dev_cap+0x4a4/0xb50 [mlx4_core]
> ...
> "
> In the above call trace, the function mlx4_cmd_poll calls the function
> mlx4_cmd_post to access the HCA while HCA is offline. Then mlx4_cmd_post
> returns an error -EIO. Per -EIO, the function mlx4_cmd_poll calls
> mlx4_cmd_reset_flow to reset HCA. And the above call trace pops out.
>
> This is not reasonable. Since HCA device is offline when it is being
> accessed, it should not be reset again.
>
> In this patch, since HCA is offline, the function mlx4_cmd_post returns
> an error -EINVAL. Per -EINVAL, the function mlx4_cmd_poll directly returns
> instead of resetting HCA.
>
> CC: Srinivas Eeda <srinivas.eeda@oracle.com>
> CC: Junxiao Bi <junxiao.bi@oracle.com>
> Suggested-by: Håkon Bugge <haakon.bugge@oracle.com>
> Suggested-by: Tariq Toukan <tariqt@mellanox.com>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
> ---
> V1->V2: Follow Tariq's advice, avoid the disturbance from other returned errors.
> Since the returned values from the function mlx4_cmd_post are -EIO and -EINVAL,
> to -EIO, the HCA device should be reset. To -EINVAL, that means that the function
> mlx4_cmd_post is accessing an offline device. It is not necessary to reset HCA.
> Go to label out directly.
> ---
> drivers/net/ethernet/mellanox/mlx4/cmd.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Thanks Zhu.
^ permalink raw reply
* Re: [PATCH net-next] rocker: Postpone filtering of !added_by_user FDB
From: Vivien Didelot @ 2018-05-10 14:21 UTC (permalink / raw)
To: Petr Machata, netdev; +Cc: jiri, davem
In-Reply-To: <6fbb39711485d7abbe7cdaa8042a222b9588a6b6.1525957759.git.petrm@mellanox.com>
Petr Machata <petrm@mellanox.com> writes:
> Breaking out of the switch in rocker_switchdev_event() still ends up
> scheduling work, except an ill-defined one. This leads to an OOPS cited
> below. Fix by postponing the check until rocker_switchdev_event_work().
>
> [ 23.148476] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> [ 23.148810] PGD 0 P4D 0
> [ 23.148982] Oops: 0000 [#1] PREEMPT SMP PTI
> [ 23.149190] Modules linked in: bridge stp llc iptable_nat nf_nat_ipv4 nf_nat e1000 rocker
> [ 23.149768] CPU: 0 PID: 239 Comm: kworker/u2:4 Not tainted 4.17.0-rc3-net_next_queue-custom #6
> [ 23.150298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
> [ 23.150868] Workqueue: rocker rocker_switchdev_event_work [rocker]
> [ 23.151258] RIP: 0010:ofdpa_port_fdb+0x7b/0x230 [rocker]
> [ 23.151597] RSP: 0018:ffffc900004b3e18 EFLAGS: 00010246
> [ 23.151952] RAX: 00000000fffbc68c RBX: 0000000000000000 RCX: 0000000000000000
> [ 23.152363] RDX: 0000000000000010 RSI: ffff88003b4471e0 RDI: 00000000ffffffff
> [ 23.152768] RBP: ffff88003b4471c0 R08: ffff88003b4471e0 R09: ffff88003b4471c0
> [ 23.153141] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880036caf000
> [ 23.153515] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88003bc00000
> [ 23.153919] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 23.154444] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 23.154806] CR2: 0000000000000000 CR3: 0000000036eb6000 CR4: 00000000000006f0
> [ 23.155194] Call Trace:
> [ 23.155472] rocker_switchdev_event_work+0x9b/0xd0 [rocker]
> [ 23.155850] ? __schedule+0x231/0x700
> [ 23.156175] process_one_work+0x1cf/0x3e0
> [ 23.156490] worker_thread+0x26/0x3d0
> [ 23.156795] ? trace_event_raw_event_workqueue_execute_start+0x80/0x80
> [ 23.157181] kthread+0x10e/0x130
> [ 23.157485] ? kthread_create_worker_on_cpu+0x40/0x40
> [ 23.157824] ret_from_fork+0x35/0x40
> [ 23.158174] Code: 00 00 c1 e8 02 4c 8d 45 20 bf ff ff ff ff 83 e0 01 4c 89 65 20 88 45 14 48 8b 05 21 da 1f e2 4c 89 c6 4c 89 44 24 10 48 89 45 18 <41> 8b 45 00 89 45 28 41 0f b7 45 04 66 89 45 2c 0f b7 44 24 04
> [ 23.159346] RIP: ofdpa_port_fdb+0x7b/0x230 [rocker] RSP: ffffc900004b3e18
> [ 23.159742] CR2: 0000000000000000
> [ 23.160088] ---[ end trace f9b16d4cb6df0629 ]---
>
> Fixes: 816a3bed9549 ("switchdev: Add fdb.added_by_user to switchdev notifications")
> Suggested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* Re: [PATCH v1 iproute2-next 2/3] rdma: print driver resource attributes
From: David Ahern @ 2018-05-10 14:20 UTC (permalink / raw)
To: Steve Wise, leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <e94d0444-fcda-3a62-3b12-3b9e6ff23119@opengridcomputing.com>
On 5/10/18 8:19 AM, Steve Wise wrote:
>
> On 5/9/2018 11:08 PM, David Ahern wrote:
>> On 5/7/18 9:53 AM, Steve Wise wrote:
>>> @@ -152,7 +153,10 @@ int main(int argc, char **argv)
>>> pretty_output = true;
>>> break;
>>> case 'd':
>>> - show_details = true;
>>> + if (show_details)
>>> + show_driver_details = true;
>>> + else
>>> + show_details = true;
>>> break;
>>> case 'j':
>>> json_output = true;
>> The above change should be reflected in the man page.
>
> I did mention it in the man page:
>
> -d, --details
> Output detailed information. Adding a second -d includes
> driver-specific details.
>
> But I wasn't sure how to show it in the syntax. Maybe this?
>
> OPTIONS := { -V[ersion] | -d[etails] [-d[etails]] } -j[son] } -p[retty] }
I should have read the second patch before commenting. Didn't it have
first -d = details, a second -d = driver details? That should be fine.
>
>
>> Also, the set needs to be respun after I merged master where Stephen
>> brought in updates to the uapi files.
>
> Will do. Thanks for reviewing.
>
> Steve.
>
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Dan Carpenter @ 2018-05-10 14:18 UTC (permalink / raw)
To: Yuval Shaia
Cc: Christophe JAILLET, davem, tariqt, netdev, linux-rdma,
linux-kernel, kernel-janitors
In-Reply-To: <20180510133808.GA10943@lap1>
On Thu, May 10, 2018 at 04:38:08PM +0300, Yuval Shaia wrote:
> On Thu, May 10, 2018 at 09:02:26AM +0200, Christophe JAILLET wrote:
> > If an error occurs, 'mlx4_en_destroy_netdev()' is called.
> > It then calls 'mlx4_en_free_resources()' which does the needed resources
> > cleanup.
> >
> > So, doing some explicit kfree in the error handling path would lead to
> > some double kfree.
>
> Patch make sense but what's bothering me is that mlx4_en_free_resources
> loops on the entire array, assuming !priv->tx_ring[t] means entry is
> allocated but the existing code does not assume that, see [1]. So i looked
> to see where tx_ring array is zeroed and didn't find it.
>
> Am i missing something here.
>
It's zeroed twice. alloc_etherdev_mqs() allocates zeroed memory and
then we do a memset(priv, 0, sizeof(struct mlx4_en_priv));
regards,
dan carpenter
^ permalink raw reply
* [PATCH] qed: fix spelling mistake: "taskelt" -> "tasklet"
From: Colin King @ 2018-05-10 14:03 UTC (permalink / raw)
To: Ariel Elior, everest-linux-l2, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in DP_VERBOSE message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 70bc5634675c..9feed3b79cd4 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -680,7 +680,7 @@ static int qed_nic_stop(struct qed_dev *cdev)
tasklet_disable(p_hwfn->sp_dpc);
p_hwfn->b_sp_dpc_enabled = false;
DP_VERBOSE(cdev, NETIF_MSG_IFDOWN,
- "Disabled sp taskelt [hwfn %d] at %p\n",
+ "Disabled sp tasklet [hwfn %d] at %p\n",
i, p_hwfn->sp_dpc);
}
}
--
2.17.0
^ permalink raw reply related
* Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not working
From: Michal Vokáč @ 2018-05-10 13:49 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <20180504133014.GB9666@lunn.ch>
On 4.5.2018 15:30, Andrew Lunn wrote:
>> I am out of ideas how to further debug this.
>> Any additional adivce will be much appreciated.
>
> I would suggest looking at the statistics counters. ethtool -S. Try
> it for both the slave interfaces, and the master interface. The master
> interfaces statistics should have both the host counters, and the
> switches counters. Do you see packets being sent but not received? Are
> there errors reported?
Thanks Andrew, now I am getting closer!
I briefly looked at the statistics some time ago but could not interpret
the numbers correctly. Now I went through the relevant source code and it
shed some light to it.
This is what I get from the numbers:
Slaves - switch counters: some packets received, none transmitted. No errors.
Slaves - DSA counters: some packets transmitted, none received. No error cntrs.
Master - switch counters: some packets transmitted, none received. No errors.
Master - host/fec counters: some packets transmitted, none received. No errors,
but IEEE_rx_drop counter shows frames are being dropped!
So this is most probably the issue. From the i.MX6 RM:
"Counter increments if a frame with invalid or missing SFD character is
detected and has been dropped. None of the other counters increments if
this counter increments."
At first I thought that this could be caused by the atheros header.
But the atheros header is inserted in the frame by the switch after the SA.
So it can not be the issue as the frame is discarded even before the DA and SA
is processed.
So both the CPU and the switch are trying to talk to each other but their
frames are not delivered. This still looks like RGMII configuration problem.
As it works with my old PHY driver I suspect the problem is at the switches
side somewhere in qca8k_set_pad_ctrl or qca8k_setup in the qca8k driver.
Any other ideas?
BR, Michal
^ permalink raw reply
* Re: [PATCH] ipv6: remove min MTU check for tunnel destinations
From: Ashwanth Goli @ 2018-05-10 13:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, pabeni, dsahern, netdev-owner
In-Reply-To: <20180501.122223.1661453536072731491.davem@davemloft.net>
On 2018-05-01 21:52, David Miller wrote:
> From: Ashwanth Goli <ashwanth@codeaurora.org>
> Date: Mon, 30 Apr 2018 00:36:47 +0530
>
>> With 749439bfac "fix udpv6 sendmsg crash caused by too small MTU"
>> tunnel dst's that report a MTU less than IPV6_MIN_MTU are broken
>> even for packets that are smaller than IPV6_MIN_MTU.
>>
>> According to rfc2473#section-7.1
>>
>> if the original IPv6 packet is equal or smaller than the
>> IPv6 minimum link MTU, the tunnel entry-point node
>> encapsulates the original packet, and subsequently
>> fragments the resulting IPv6 tunnel packet into IPv6
>> fragments that do not exceed the Path MTU to the tunnel
>> exit-point.
>>
>> This patch drops the MTU check for tunnel destinations.
>>
>> Signed-off-by: Ashwanth Goli <ashwanth@codeaurora.org>
>
> RFC 2473 is generally about ipv6 tunnels....
>
>> - if (mtu < IPV6_MIN_MTU)
>> + if (!(rt->dst.flags & DST_XFRM_TUNNEL) && mtu < IPV6_MIN_MTU)
>> return -EINVAL;
>
> But the check you are adding is specifically checking only IPSEC
> tunnels.
>
> If what you say is true in your commit message, this test must
> more generally trigger for all ipv6 tunnel types, not just IPSEC
> ones.
>
> If IPSEC tunnels are being targetting in this patch intentionally,
> that needs to be explained in the commit message.
My intention is to fix the issue for IPSEC tunnels. Will resend by
changing the commit text.
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Yuval Shaia @ 2018-05-10 13:38 UTC (permalink / raw)
To: Christophe JAILLET
Cc: davem, tariqt, netdev, linux-rdma, linux-kernel, kernel-janitors
In-Reply-To: <20180510070226.19575-1-christophe.jaillet@wanadoo.fr>
On Thu, May 10, 2018 at 09:02:26AM +0200, Christophe JAILLET wrote:
> If an error occurs, 'mlx4_en_destroy_netdev()' is called.
> It then calls 'mlx4_en_free_resources()' which does the needed resources
> cleanup.
>
> So, doing some explicit kfree in the error handling path would lead to
> some double kfree.
Patch make sense but what's bothering me is that mlx4_en_free_resources
loops on the entire array, assuming !priv->tx_ring[t] means entry is
allocated but the existing code does not assume that, see [1]. So i looked
to see where tx_ring array is zeroed and didn't find it.
Am i missing something here.
>
> Simplify code to avoid such a case.
>
> Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index e0adac4a9a19..9670b33fc9b1 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -3324,12 +3324,11 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
> MAX_TX_RINGS, GFP_KERNEL);
> if (!priv->tx_ring[t]) {
> err = -ENOMEM;
> - goto err_free_tx;
> + goto out;
> }
> priv->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
> MAX_TX_RINGS, GFP_KERNEL);
> if (!priv->tx_cq[t]) {
> - kfree(priv->tx_ring[t]);
> err = -ENOMEM;
> goto out;
> }
> @@ -3582,11 +3581,6 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
>
> return 0;
>
> -err_free_tx:
> - while (t--) {
[1]
> - kfree(priv->tx_ring[t]);
> - kfree(priv->tx_cq[t]);
> - }
> out:
> mlx4_en_destroy_netdev(dev);
> return err;
> --
> 2.17.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next] rocker: Postpone filtering of !added_by_user FDB
From: Petr Machata @ 2018-05-10 13:29 UTC (permalink / raw)
To: netdev; +Cc: jiri, davem, vivien.didelot
Breaking out of the switch in rocker_switchdev_event() still ends up
scheduling work, except an ill-defined one. This leads to an OOPS cited
below. Fix by postponing the check until rocker_switchdev_event_work().
[ 23.148476] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[ 23.148810] PGD 0 P4D 0
[ 23.148982] Oops: 0000 [#1] PREEMPT SMP PTI
[ 23.149190] Modules linked in: bridge stp llc iptable_nat nf_nat_ipv4 nf_nat e1000 rocker
[ 23.149768] CPU: 0 PID: 239 Comm: kworker/u2:4 Not tainted 4.17.0-rc3-net_next_queue-custom #6
[ 23.150298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
[ 23.150868] Workqueue: rocker rocker_switchdev_event_work [rocker]
[ 23.151258] RIP: 0010:ofdpa_port_fdb+0x7b/0x230 [rocker]
[ 23.151597] RSP: 0018:ffffc900004b3e18 EFLAGS: 00010246
[ 23.151952] RAX: 00000000fffbc68c RBX: 0000000000000000 RCX: 0000000000000000
[ 23.152363] RDX: 0000000000000010 RSI: ffff88003b4471e0 RDI: 00000000ffffffff
[ 23.152768] RBP: ffff88003b4471c0 R08: ffff88003b4471e0 R09: ffff88003b4471c0
[ 23.153141] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880036caf000
[ 23.153515] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88003bc00000
[ 23.153919] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 23.154444] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 23.154806] CR2: 0000000000000000 CR3: 0000000036eb6000 CR4: 00000000000006f0
[ 23.155194] Call Trace:
[ 23.155472] rocker_switchdev_event_work+0x9b/0xd0 [rocker]
[ 23.155850] ? __schedule+0x231/0x700
[ 23.156175] process_one_work+0x1cf/0x3e0
[ 23.156490] worker_thread+0x26/0x3d0
[ 23.156795] ? trace_event_raw_event_workqueue_execute_start+0x80/0x80
[ 23.157181] kthread+0x10e/0x130
[ 23.157485] ? kthread_create_worker_on_cpu+0x40/0x40
[ 23.157824] ret_from_fork+0x35/0x40
[ 23.158174] Code: 00 00 c1 e8 02 4c 8d 45 20 bf ff ff ff ff 83 e0 01 4c 89 65 20 88 45 14 48 8b 05 21 da 1f e2 4c 89 c6 4c 89 44 24 10 48 89 45 18 <41> 8b 45 00 89 45 28 41 0f b7 45 04 66 89 45 2c 0f b7 44 24 04
[ 23.159346] RIP: ofdpa_port_fdb+0x7b/0x230 [rocker] RSP: ffffc900004b3e18
[ 23.159742] CR2: 0000000000000000
[ 23.160088] ---[ end trace f9b16d4cb6df0629 ]---
Fixes: 816a3bed9549 ("switchdev: Add fdb.added_by_user to switchdev notifications")
Suggested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
drivers/net/ethernet/rocker/rocker_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
index 152d694..e73e4fe 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -2738,6 +2738,8 @@ static void rocker_switchdev_event_work(struct work_struct *work)
switch (switchdev_work->event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE:
fdb_info = &switchdev_work->fdb_info;
+ if (!fdb_info->added_by_user)
+ break;
err = rocker_world_port_fdb_add(rocker_port, fdb_info);
if (err) {
netdev_dbg(rocker_port->dev, "fdb add failed err=%d\n", err);
@@ -2747,6 +2749,8 @@ static void rocker_switchdev_event_work(struct work_struct *work)
break;
case SWITCHDEV_FDB_DEL_TO_DEVICE:
fdb_info = &switchdev_work->fdb_info;
+ if (!fdb_info->added_by_user)
+ break;
err = rocker_world_port_fdb_del(rocker_port, fdb_info);
if (err)
netdev_dbg(rocker_port->dev, "fdb add failed err=%d\n", err);
@@ -2783,8 +2787,6 @@ static int rocker_switchdev_event(struct notifier_block *unused,
switch (event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE: /* fall through */
case SWITCHDEV_FDB_DEL_TO_DEVICE:
- if (!fdb_info->added_by_user)
- break;
memcpy(&switchdev_work->fdb_info, ptr,
sizeof(switchdev_work->fdb_info));
switchdev_work->fdb_info.addr = kzalloc(ETH_ALEN, GFP_ATOMIC);
--
2.4.11
^ permalink raw reply related
* [PATCH net-next] tls: Fix tls_device initialization
From: Boris Pismenny @ 2018-05-10 13:27 UTC (permalink / raw)
To: davem; +Cc: netdev, borisp, davejwatson
Add sg table initialization to fix a BUG_ON encountered when enabling
CONFIG_DEBUG_SG.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
---
net/tls/tls_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index ac45d62..a7a8f8e 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -604,6 +604,8 @@ int tls_set_device_offload(struct sock *sk, struct tls_context *ctx)
INIT_LIST_HEAD(&offload_ctx->records_list);
list_add_tail(&start_marker_record->list, &offload_ctx->records_list);
spin_lock_init(&offload_ctx->lock);
+ sg_init_table(offload_ctx->sg_tx_data,
+ ARRAY_SIZE(offload_ctx->sg_tx_data));
clean_acked_data_enable(inet_csk(sk), &tls_icsk_clean_acked);
ctx->push_pending_record = tls_device_push_pending_record;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next v2] tcp: Add mark for TIMEWAIT sockets
From: Eric Dumazet @ 2018-05-10 13:27 UTC (permalink / raw)
To: Jon Maxwell, davem; +Cc: kuznet, yoshfuji, netdev, linux-kernel, jmaxwell
In-Reply-To: <20180510065351.22535-1-jmaxwell37@gmail.com>
On 05/09/2018 11:53 PM, Jon Maxwell wrote:
> This version has some suggestions by Eric Dumazet:
>
> - Use a local variable for the mark in IPv6 instead of ctl_sk to avoid SMP
> races.
> - Use the more elegant "IP4_REPLY_MARK(net, skb->mark) ?: sk->sk_mark"
> statement.
> - Factorize code as sk_fullsock() check is not necessary.
>
> Aidan McGurn from Openwave Mobility systems reported the following bug:
>
> "Marked routing is broken on customer deployment. Its effects are large
> increase in Uplink retransmissions caused by the client never receiving
> the final ACK to their FINACK - this ACK misses the mark and routes out
> of the incorrect route."
>
> Currently marks are added to sk_buffs for replies when the "fwmark_reflect"
> sysctl is enabled. But not for TW sockets that had sk->sk_mark set via
> setsockopt(SO_MARK..).
>
> Fix this in IPv4/v6 by adding tw->tw_mark for TIME_WAIT sockets. Copy the the
> original sk->sk_mark in __inet_twsk_hashdance() to the new tw->tw_mark location.
> Then progate this so that the skb gets sent with the correct mark. Do the same
> for resets. Give the "fwmark_reflect" sysctl precedence over sk->sk_mark so that
> netfilter rules are still honored.
>
> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks Jon.
^ permalink raw reply
* Re: [PATCH] mlxsw: core: Fix an error handling path in \'mlxsw_core_bus_device_register()\'
From: Dan Carpenter @ 2018-05-10 13:17 UTC (permalink / raw)
To: Arkadi Sharshevsky; +Cc: netdev@vger.kernel.org
In-Reply-To: <2c5caff2-5ece-d07b-4df9-47a9ff24a86f@mellanox.com>
On Thu, May 10, 2018 at 04:08:22PM +0300, Arkadi Sharshevsky wrote:
> Hi Dan,
>
> I will fix the error path. Regarding the goto label this is
> the convention in the driver.
There is no rule against learning from the past.
Or there might be... I don't know all the rules at Mellanox.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] mlxsw: core: Fix an error handling path in \'mlxsw_core_bus_device_register()\'
From: Arkadi Sharshevsky @ 2018-05-10 13:08 UTC (permalink / raw)
To: dan.carpenter; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180510124138.6yerbsfcl3abqtmq@mwanda>
Hi Dan,
I will fix the error path. Regarding the goto label this is
the convention in the driver.
Thanks,
Arkadi
^ 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