* Re: [PATCH] brcmfmac: stop watchdog before detach and free everything
From: Michael Nazzareno Trimarchi @ 2018-05-28 9:54 UTC (permalink / raw)
To: Arend van Spriel
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, Pieter-Paul Giesberts, Ian Molton,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev, LKML
In-Reply-To: <5B0BD13D.8000809@broadcom.com>
Hi Arend
On Mon, May 28, 2018 at 11:51 AM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 5/28/2018 9:50 AM, Michael Trimarchi wrote:
>>
>> Watchdog need to be stopped in brcmf_sdio_remove to avoid
>> i
>> The system is going down NOW!
>> [ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual
>> address 000002f8
>> Sent SIGTERM to all processes
>> [ 1348.121412] Mem abort info:
>> [ 1348.126962] ESR = 0x96000004
>> [ 1348.130023] Exception class = DABT (current EL), IL = 32 bits
>> [ 1348.135948] SET = 0, FnV = 0
>> [ 1348.138997] EA = 0, S1PTW = 0
>> [ 1348.142154] Data abort info:
>> [ 1348.145045] ISV = 0, ISS = 0x00000004
>> [ 1348.148884] CM = 0, WnR = 0
>> [ 1348.151861] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
>> [ 1348.158475] [00000000000002f8] pgd=0000000000000000
>> [ 1348.163364] Internal error: Oops: 96000004 [#1] PREEMPT SMP
>> [ 1348.168927] Modules linked in: ipv6
>> [ 1348.172421] CPU: 3 PID: 1421 Comm: brcmf_wdog/mmc0 Not tainted
>> 4.17.0-rc5-next-20180517 #18
>> [ 1348.180757] Hardware name: Amarula A64-Relic (DT)
>> [ 1348.185455] pstate: 60000005 (nZCv daif -PAN -UAO)
>> [ 1348.190251] pc : brcmf_sdiod_freezer_count+0x0/0x20
>> [ 1348.195124] lr : brcmf_sdio_watchdog_thread+0x64/0x290
>
>
> Hi Michael,
>
> Thanks for the patch. In normal scenario the callstack looks like this:
>
> brcmf_sdio_remove()
> -> brcmf_detach()
> -> brcmf_bus_stop()
> -> brcmf_sdio_bus_stop()
>
> In brcmf_sdio_bus_stop() the watchdog is terminated. So in what scenario did
> you encounter this null pointer deref?
Is this happen even when there is not wifi firmware?
boot without any firmware in the filesystem and then trigger a reboot
Michael
>
> Regards,
> Arend
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
^ permalink raw reply
* Re: [PATCH] brcmfmac: stop watchdog before detach and free everything
From: Arend van Spriel @ 2018-05-28 9:51 UTC (permalink / raw)
To: Michael Trimarchi
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Kalle Valo, David S. Miller, Pieter-Paul Giesberts, Ian Molton,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev, linux-kernel
In-Reply-To: <1527493857-2220-1-git-send-email-michael@amarulasolutions.com>
On 5/28/2018 9:50 AM, Michael Trimarchi wrote:
> Watchdog need to be stopped in brcmf_sdio_remove to avoid
> i
> The system is going down NOW!
> [ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 000002f8
> Sent SIGTERM to all processes
> [ 1348.121412] Mem abort info:
> [ 1348.126962] ESR = 0x96000004
> [ 1348.130023] Exception class = DABT (current EL), IL = 32 bits
> [ 1348.135948] SET = 0, FnV = 0
> [ 1348.138997] EA = 0, S1PTW = 0
> [ 1348.142154] Data abort info:
> [ 1348.145045] ISV = 0, ISS = 0x00000004
> [ 1348.148884] CM = 0, WnR = 0
> [ 1348.151861] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
> [ 1348.158475] [00000000000002f8] pgd=0000000000000000
> [ 1348.163364] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> [ 1348.168927] Modules linked in: ipv6
> [ 1348.172421] CPU: 3 PID: 1421 Comm: brcmf_wdog/mmc0 Not tainted 4.17.0-rc5-next-20180517 #18
> [ 1348.180757] Hardware name: Amarula A64-Relic (DT)
> [ 1348.185455] pstate: 60000005 (nZCv daif -PAN -UAO)
> [ 1348.190251] pc : brcmf_sdiod_freezer_count+0x0/0x20
> [ 1348.195124] lr : brcmf_sdio_watchdog_thread+0x64/0x290
Hi Michael,
Thanks for the patch. In normal scenario the callstack looks like this:
brcmf_sdio_remove()
-> brcmf_detach()
-> brcmf_bus_stop()
-> brcmf_sdio_bus_stop()
In brcmf_sdio_bus_stop() the watchdog is terminated. So in what scenario
did you encounter this null pointer deref?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 3/6] ravb: remove custom .set_link_ksettings from ethtool ops
From: Vladimir Zapolskiy @ 2018-05-28 9:51 UTC (permalink / raw)
To: Sergei Shtylyov, David S. Miller; +Cc: netdev, linux-renesas-soc
In-Reply-To: <ab7d62f4-75eb-a58a-69ff-4ca8c1ece36b@cogentembedded.com>
Hello Sergei,
On 05/26/2018 10:50 PM, Sergei Shtylyov wrote:
> On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote:
>
>> The change replaces a custom implementation of .set_link_ksettings
>> callback with a shared phy_ethtool_set_link_ksettings(), this fixes
>> sleep in atomic context bug, which is encountered every time when link
>> settings are changed by ethtool.
>
> Seeing it now...
>
>> Now duplex mode setting is enforced in ravb_adjust_link() only, also
>> now TX/RX is disabled when link is put down or modifications to E-MAC
>> registers ECMR and GECMR are expected for both cases of checked and
>> ignored link status pin state from E-MAC interrupt handler.
>>
>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
>> ---
>> drivers/net/ethernet/renesas/ravb_main.c | 58 +++++++++-----------------------
>> 1 file changed, 15 insertions(+), 43 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
>> index 3d91caa44176..0d811c02ff34 100644
>> --- a/drivers/net/ethernet/renesas/ravb_main.c
>> +++ b/drivers/net/ethernet/renesas/ravb_main.c
>> @@ -980,6 +980,13 @@ static void ravb_adjust_link(struct net_device *ndev)
>> struct ravb_private *priv = netdev_priv(ndev);
>> struct phy_device *phydev = ndev->phydev;
>> bool new_state = false;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&priv->lock, flags);
>> +
>> + /* Disable TX and RX right over here, if E-MAC change is ignored */
>> + if (priv->no_avb_link)
>> + ravb_rcv_snd_disable(ndev);
>>
>> if (phydev->link) {
>> if (phydev->duplex != priv->duplex) {
>> @@ -997,18 +1004,21 @@ static void ravb_adjust_link(struct net_device *ndev)
>> ravb_modify(ndev, ECMR, ECMR_TXF, 0);
>> new_state = true;
>> priv->link = phydev->link;
>> - if (priv->no_avb_link)
>> - ravb_rcv_snd_enable(ndev);
>> }
>> } else if (priv->link) {
>> new_state = true;
>> priv->link = 0;
>> priv->speed = 0;
>> priv->duplex = -1;
>> - if (priv->no_avb_link)
>> - ravb_rcv_snd_disable(ndev);
>> }
>>
>> + /* Enable TX and RX right over here, if E-MAC change is ignored */
>> + if (priv->no_avb_link && phydev->link)
>> + ravb_rcv_snd_enable(ndev);
>> +
>> + mmiowb();
>> + spin_unlock_irqrestore(&priv->lock, flags);
>> +
>
> I like this part. :-)
>
A weight off my mind :) And I hope that this change will remain the less
questionable one, other ones from the series are trivial.
Anyway I hope it is understandable that this part of the change can not
be simply extracted from the rest one below, otherwise there'll be bugs of
another type intorduced.
>> if (new_state && netif_msg_link(priv))
>> phy_print_status(phydev);
>> }
>> @@ -1096,44 +1106,6 @@ static int ravb_phy_start(struct net_device *ndev)
>> return 0;
>> }
>>
>> -static int ravb_set_link_ksettings(struct net_device *ndev,
>> - const struct ethtool_link_ksettings *cmd)
>> -{
>> - struct ravb_private *priv = netdev_priv(ndev);
>> - unsigned long flags;
>> - int error;
>> -
>> - if (!ndev->phydev)
>> - return -ENODEV;
>> -
>> - spin_lock_irqsave(&priv->lock, flags);
>> -
>> - /* Disable TX and RX */
>> - ravb_rcv_snd_disable(ndev);
>> -
>> - error = phy_ethtool_ksettings_set(ndev->phydev, cmd);
>> - if (error)
>> - goto error_exit;
>> -
>> - if (cmd->base.duplex == DUPLEX_FULL)
>> - priv->duplex = 1;
>> - else
>> - priv->duplex = 0;
>> -
>> - ravb_set_duplex(ndev);
>> -
>> -error_exit:
>> - mdelay(1);
>> -
>> - /* Enable TX and RX */
>> - ravb_rcv_snd_enable(ndev);
>> -
>> - mmiowb();
>> - spin_unlock_irqrestore(&priv->lock, flags);
>> -
>> - return error;
>> -}
>> -
>
> But this part is clearly lumping it all together...
Please elaborate.
>
> [...]
>> @@ -1357,7 +1329,7 @@ static const struct ethtool_ops ravb_ethtool_ops = {
>> .set_ringparam = ravb_set_ringparam,
>> .get_ts_info = ravb_get_ts_info,
>> .get_link_ksettings = phy_ethtool_get_link_ksettings,
>> - .set_link_ksettings = ravb_set_link_ksettings,
>> + .set_link_ksettings = phy_ethtool_set_link_ksettings,
>
> Should have been a part of the final patch in the fix/enhancement chain...
Please elaborate.
Do you mean that firstly I have to make erroneous ravb_set_link_ksettings()
to look similar to phy_ethtool_set_link_ksettings() and then remove it?
As I see it in the current context (removal of ravb_set_duplex() call and
so on), the problem with this approach is that the actual fix change will
be done on top of a number of enchancement changes, thus it contradicts to
the accepted development/maintenace model "fixes first", and most probably
it won't be possible to backport the real fix, however this sole change can
be backported.
>
>> .get_wol = ravb_get_wol,
>> .set_wol = ravb_set_wol,
>> };
>
^ permalink raw reply
* Re: Grant-
From: M. M. Fridman @ 2018-05-28 2:44 UTC (permalink / raw)
To: Recipients
I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.
Check the link below for confirmation:
http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604
Reply as soon as possible with further directives.
Best Regards,
Mikhail Fridman.
^ permalink raw reply
* Re: [PATCH mlx5-next v1 02/13] net/mlx5: Export flow counter related API
From: Leon Romanovsky @ 2018-05-28 9:16 UTC (permalink / raw)
To: Or Gerlitz
Cc: Raed Salem, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <CAJ3xEMg_2zd1yr4vZjvgEEmAAYbXX9Ax9C+Jtyt87eQNrioPVA@mail.gmail.com>
On Mon, May 28, 2018 at 11:34:18AM +0300, Or Gerlitz wrote:
> On Sun, May 27, 2018 at 1:23 PM, Leon Romanovsky <leon@kernel.org> wrote:
> > From: Raed Salem <raeds@mellanox.com>
> >
> > Exports counters API to be used in both IB and EN.
> >
> > Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> > Signed-off-by: Raed Salem <raeds@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > ---
> > drivers/net/ethernet/mellanox/mlx5/core/fs_core.h | 23 ----------------------
> > .../net/ethernet/mellanox/mlx5/core/fs_counters.c | 3 +++
> > include/linux/mlx5/fs.h | 22 +++++++++++++++++++++
> > 3 files changed, 25 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
> > index b6da322a8016..40992aed1791 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
> > @@ -131,29 +131,6 @@ struct mlx5_flow_table {
> > struct rhltable fgs_hash;
> > };
> >
> > -struct mlx5_fc_cache {
> > - u64 packets;
> > - u64 bytes;
> > - u64 lastuse;
> > -};
> > -
> > -struct mlx5_fc {
> > - struct rb_node node;
> > - struct list_head list;
> > -
> > - /* last{packets,bytes} members are used when calculating the delta since
> > - * last reading
> > - */
> > - u64 lastpackets;
> > - u64 lastbytes;
> > -
> > - u32 id;
> > - bool deleted;
> > - bool aging;
> > -
> > - struct mlx5_fc_cache cache ____cacheline_aligned_in_smp;
> > -};
> > -
>
> are you using the caching services @ the IB driver? please point me to
> the patch that does so
IB doesn't use cache, but uses "struct mlx5_fc", which needs
mlx5_fc_cache struct for compilation.
For example in this patch [1], Raed uses "struct mlx5_fc".
[1] https://patchwork.ozlabs.org/patch/921076/
Thanks
^ permalink raw reply
* [PATCH net-next] netfilter: fix null-ptr-deref in nf_nat_decode_session
From: Prashant Bhole @ 2018-05-28 9:14 UTC (permalink / raw)
To: David S . Miller, Pablo Neira Ayuso
Cc: Prashant Bhole, Jozsef Kadlecsik, Florian Westphal, netdev
Add null check for nat_hook in nf_nat_decode_session()
[ 195.648098] UBSAN: Undefined behaviour in ./include/linux/netfilter.h:348:14
[ 195.651366] BUG: KASAN: null-ptr-deref in __xfrm_policy_check+0x208/0x1d70
[ 195.653888] member access within null pointer of type 'struct nf_nat_hook'
[ 195.653896] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.17.0-rc6+ #5
[ 195.656320] Read of size 8 at addr 0000000000000008 by task ping/2469
[ 195.658715] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 195.658721] Call Trace:
[ 195.661087]
[ 195.669341] <IRQ>
[ 195.670574] dump_stack+0xc6/0x150
[ 195.672156] ? dump_stack_print_info.cold.0+0x1b/0x1b
[ 195.674121] ? ubsan_prologue+0x31/0x92
[ 195.676546] ubsan_epilogue+0x9/0x49
[ 195.678159] handle_null_ptr_deref+0x11a/0x130
[ 195.679800] ? sprint_OID+0x1a0/0x1a0
[ 195.681322] __ubsan_handle_type_mismatch_v1+0xd5/0x11d
[ 195.683146] ? ubsan_prologue+0x92/0x92
[ 195.684642] __xfrm_policy_check+0x18ef/0x1d70
[ 195.686294] ? rt_cache_valid+0x118/0x180
[ 195.687804] ? __xfrm_route_forward+0x410/0x410
[ 195.689463] ? fib_multipath_hash+0x700/0x700
[ 195.691109] ? kvm_sched_clock_read+0x23/0x40
[ 195.692805] ? pvclock_clocksource_read+0xf6/0x280
[ 195.694409] ? graph_lock+0xa0/0xa0
[ 195.695824] ? pvclock_clocksource_read+0xf6/0x280
[ 195.697508] ? pvclock_read_flags+0x80/0x80
[ 195.698981] ? kvm_sched_clock_read+0x23/0x40
[ 195.700347] ? sched_clock+0x5/0x10
[ 195.701525] ? sched_clock_cpu+0x18/0x1a0
[ 195.702846] tcp_v4_rcv+0x1d32/0x1de0
[ 195.704115] ? lock_repin_lock+0x70/0x270
[ 195.707072] ? pvclock_read_flags+0x80/0x80
[ 195.709302] ? tcp_v4_early_demux+0x4b0/0x4b0
[ 195.711833] ? lock_acquire+0x195/0x380
[ 195.714222] ? ip_local_deliver_finish+0xfc/0x770
[ 195.716967] ? raw_rcv+0x2b0/0x2b0
[ 195.718856] ? lock_release+0xa00/0xa00
[ 195.720938] ip_local_deliver_finish+0x1b9/0x770
[...]
Fixes: 2c205dd3981f ("netfilter: add struct nf_nat_hook and use it")
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
include/linux/netfilter.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index 04551af2ff23..dd2052f0efb7 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -345,7 +345,7 @@ nf_nat_decode_session(struct sk_buff *skb, struct flowi *fl, u_int8_t family)
rcu_read_lock();
nat_hook = rcu_dereference(nf_nat_hook);
- if (nat_hook->decode_session)
+ if (nat_hook && nat_hook->decode_session)
nat_hook->decode_session(skb, fl);
rcu_read_unlock();
#endif
--
2.17.0
^ permalink raw reply related
* Re: STMMAC driver with TSO enabled issue
From: Bhadram Varka @ 2018-05-28 9:15 UTC (permalink / raw)
To: Jose Abreu, netdev@vger.kernel.org, Joao Pinto
In-Reply-To: <a806ab0c-40b8-2d64-4f7b-4e98a3d03c1b@synopsys.com>
Hi Jose,
On 5/25/2018 8:02 PM, Jose Abreu wrote:
> On 25-05-2018 15:25, Bhadram Varka wrote:
>> Hi Jose,
>>
>> On 5/25/2018 7:35 PM, Jose Abreu wrote:
>>> Hi Bhadram,
>>>
>>> On 25-05-2018 05:41, Bhadram Varka wrote:
>>>> Hi Jose,
>>>>
>>>> On 5/24/2018 3:01 PM, Jose Abreu wrote:
>>>>> Hi Bhadram,
>>>>>
>>>>> On 24-05-2018 06:58, Bhadram Varka wrote:
>>>>>>
>>>>>> After some time if check Tx descriptor status - then I see
>>>>>> only
>>>>>> below
>>>>>>
>>>>>> [..]
>>>>>> [85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8
>>>>>> 0x90000000
>>>>>>
>>>>>> index 025 and 026 descriptors processed but not index 027.
>>>>>>
>>>>>> At this stage Tx DMA is always in below state -
>>>>>>
>>>>>> ■ 3'b011: Running (Reading Data from system memory
>>>>>> buffer and queuing it to the Tx buffer (Tx FIFO))
>>>>>
>>>>> Thats strange, I think the descriptors look okay though. I will
>>>>> need the registers values (before the lock) and, if
>>>>> possible, the
>>>>> git bisect output.
>>>>
>>>> Attaching the register dump file after the issue observed.
>>>> Please check once.
>>>>
>>>
>>> ----->8-----
>>> 0x112c = 0x0000003F
>>> 0x11ac = 0x0000003F
>>> 0x122c = 0x0000003F
>>> 0x12ac = 0x0000003F
>>>
>>> 0x1130 = 0x0000003F
>>> 0x11b0 = 0x0000003F
>>> 0x1230 = 0x0000003F
>>> 0x12b0 = 0x0000003F
>>> ----->8-----
>>>
>>> This can't be right, it should be DMA_{RX/TX}_SIZE - 1 = 511. Did
>>> you change these values in the code?
>>>
>>
>> Yes. I have changed the descriptor length to 64 - so that
>> searching for the current descriptor status would be easy.
>
> Ok, it shouldn't impact anything. The only thing I'm remembering
> now is that you can have TSO not enabled in all DMA channels (HW
> configuration allows this). Please check if TSO in single-queue
> works.
TSO works fine if only single queue enabled. I don't see any limitation
from HW side because TSO works fine with other driver which we received
from Synopsys with IP drop.
Thanks,
Bhadram.
^ permalink raw reply
* Re: [PATCH v4 net-next 00/19] inet: frags: bring rhashtables to IP defrag
From: Tariq Toukan @ 2018-05-28 9:12 UTC (permalink / raw)
To: David Miller, edumazet
Cc: netdev, fw, herbert, tgraf, brouer, alex.aring, stefan, ktkhai,
eric.dumazet, Moshe Shemesh, Eran Ben Elisha
In-Reply-To: <20180331.232558.823542518953124984.davem@davemloft.net>
On 01/04/2018 6:25 AM, David Miller wrote:
> From: Eric Dumazet <edumazet@google.com>
> Date: Sat, 31 Mar 2018 12:58:41 -0700
>
>> IP defrag processing is one of the remaining problematic layer in linux.
>>
>> It uses static hash tables of 1024 buckets, and up to 128 items per bucket.
>>
>> A work queue is supposed to garbage collect items when host is under memory
>> pressure, and doing a hash rebuild, changing seed used in hash computations.
>>
>> This work queue blocks softirqs for up to 25 ms when doing a hash rebuild,
>> occurring every 5 seconds if host is under fire.
>>
>> Then there is the problem of sharing this hash table for all netns.
>>
>> It is time to switch to rhashtables, and allocate one of them per netns
>> to speedup netns dismantle, since this is a critical metric these days.
>>
>> Lookup is now using RCU, and 64bit hosts can now provision whatever amount
>> of memory needed to handle the expected workloads.
> ...
>
> Series applied, thanks Eric.
>
Hi Eric,
Recently my colleague (Moshe Shemesh) got a failure in upstream
regression, which is related to this patchset. We don’t see the failure
before it was merged.
We checked again on net-next (from May 24th), it still reproduces.
The test case runs netperf with ipv6 udp single stream (64K message size).
After the change we see huge packet loss:
145,134 messages failed out of 145,419 (only 285 fully received)
[root@reg-l-vrt-67100-104 ~]# netperf -H
fe80::e61d:2dff:feca:c7c3%ens9,inet6 -t udp_stream --
MIGRATED UDP STREAM TEST from ::0 (::) port 0 AF_INET6 to
fe80::e61d:2dff:feca:c7c3%ens9 () port 0 AF_INET6
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 65507 10.00 145419 0 7620.35
212992 10.00 285 14.93
By checking nstat counters we see that Ip6ReasmFails got very high:
#kernel
...
Ip6InReceives 6665965 0.0
Ip6InDelivers 300 0.0
Ip6OutRequests 9 0.0
Ip6ReasmReqds 6665950 0.0
Ip6ReasmOKs 285 0.0
Ip6ReasmFails 6650890 0.0
Ip6InOctets 9813929354 0.0
Ip6OutOctets 2608 0.0
Ip6InNoECTPkts 6665965 0.0
...
Udp6InDatagrams 286 0.0
...
Same test on kernel without the patchset got low failure rate:
Only 810 messages failed out of 114,112 (113,302 fully received)
[root@reg-l-vrt-67100-104 ~]# netperf -H
fe80::e61d:2dff:feca:c7c3%ens9,inet6 -t udp_stream --
MIGRATED UDP STREAM TEST from ::0 (::) port 0 AF_INET6 to
fe80::e61d:2dff:feca:c7c3%ens9 () port 0 AF_INET6
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 65507 10.00 114112 0 5979.69
212992 10.00 113302 5937.24
nstat counters to compare:
#kernel
...
Ip6InReceives 5249166 0.0
Ip6InDelivers 114126 0.0
Ip6OutRequests 8 0.0
Ip6ReasmReqds 5249152 0.0
Ip6ReasmOKs 114112 0.0
Ip6InOctets 7728009224 0.0
Ip6OutOctets 2544 0.0
Ip6InNoECTPkts 5249166 0.0
...
Udp6InDatagrams 113303 0.0
Udp6InErrors 810 0.0
Udp6RcvbufErrors 810 0.0
...
We did not get to bisect within the patchset yet.
Regards,
Tariq and Moshe
^ permalink raw reply
* Unable to create ip alias on bridge interface
From: Akshat Kakkar @ 2018-05-28 9:05 UTC (permalink / raw)
To: netdev
I am having a bridge named br0 having ports eno1 and eno2 as members.
I have given IP to br0 as 10.10.10.1/24
Now I want to create alias on br0 as br0:1 and give IP as
10.10.10.2/24, but I am unable to.
I know, we can add multiple IPs to br0 using "ip addr" command, but I
dont want to do it that way as I want all outgoing connections from
br0 to take src ip as 10.10.10.1. I know by providing option of "src"
in all routes, things can work but this looks more like a hack and
less of a solution.
Coming back to my original issue, I keep getting error "add bridge
failed: Invalid argument".
So, whats the best way out?
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: Add Netgear Aircard 779S
From: Bjørn Mork @ 2018-05-28 8:45 UTC (permalink / raw)
To: Josh Hill; +Cc: joshuajhill, David S. Miller, netdev, linux-usb, linux-kernel
In-Reply-To: <1527466241-28446-1-git-send-email-josh@joshuajhill.com>
Josh Hill <josh@joshuajhill.com> writes:
> Add support for Netgear Aircard 779S
>
> Signed-off-by: Josh Hill <josh@joshuajhill.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Please queue this for stable too. Thanks.
Bjørn
^ permalink raw reply
* Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
From: Christoph Hellwig @ 2018-05-28 8:39 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Fenghua Yu, Tony Luck, linux-ia64-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Ingo Molnar,
netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig
In-Reply-To: <alpine.DEB.2.21.1805280823240.1585-ecDvlHI5BZPZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
On Mon, May 28, 2018 at 08:23:35AM +0200, Thomas Gleixner wrote:
> > > They remove the commandline switch before having the replacement in place
> > > unless I'm misreading something.
> >
> > The command line switch to force 32-bit dma is removed without
> > replacement. The PCI quirk for force the 32-bit dma for VIA bridges
> > is kept in place, and switch to a different mechanism in this patch.
>
> Fair enough
Thanks. Do you want me to repost them for the x86 tree, or should
just pull the changes with the commit logs fixed to the dma-mapping
tree?
^ permalink raw reply
* Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
From: Thomas Gleixner @ 2018-05-28 8:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Fenghua Yu, Tony Luck, linux-ia64-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Ingo Molnar,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180528083931.GA7169-jcswGhMUV9g@public.gmane.org>
On Mon, 28 May 2018, Christoph Hellwig wrote:
> On Mon, May 28, 2018 at 08:23:35AM +0200, Thomas Gleixner wrote:
> > > > They remove the commandline switch before having the replacement in place
> > > > unless I'm misreading something.
> > >
> > > The command line switch to force 32-bit dma is removed without
> > > replacement. The PCI quirk for force the 32-bit dma for VIA bridges
> > > is kept in place, and switch to a different mechanism in this patch.
> >
> > Fair enough
>
> Thanks. Do you want me to repost them for the x86 tree, or should
> just pull the changes with the commit logs fixed to the dma-mapping
> tree?
Just take them through your tree. There is nothing conflicting in tip.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH mlx5-next v1 02/13] net/mlx5: Export flow counter related API
From: Or Gerlitz @ 2018-05-28 8:34 UTC (permalink / raw)
To: Raed Salem, Leon Romanovsky
Cc: RDMA mailing list, Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <20180527102346.15149-3-leon@kernel.org>
On Sun, May 27, 2018 at 1:23 PM, Leon Romanovsky <leon@kernel.org> wrote:
> From: Raed Salem <raeds@mellanox.com>
>
> Exports counters API to be used in both IB and EN.
>
> Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> Signed-off-by: Raed Salem <raeds@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/fs_core.h | 23 ----------------------
> .../net/ethernet/mellanox/mlx5/core/fs_counters.c | 3 +++
> include/linux/mlx5/fs.h | 22 +++++++++++++++++++++
> 3 files changed, 25 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
> index b6da322a8016..40992aed1791 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
> @@ -131,29 +131,6 @@ struct mlx5_flow_table {
> struct rhltable fgs_hash;
> };
>
> -struct mlx5_fc_cache {
> - u64 packets;
> - u64 bytes;
> - u64 lastuse;
> -};
> -
> -struct mlx5_fc {
> - struct rb_node node;
> - struct list_head list;
> -
> - /* last{packets,bytes} members are used when calculating the delta since
> - * last reading
> - */
> - u64 lastpackets;
> - u64 lastbytes;
> -
> - u32 id;
> - bool deleted;
> - bool aging;
> -
> - struct mlx5_fc_cache cache ____cacheline_aligned_in_smp;
> -};
> -
are you using the caching services @ the IB driver? please point me to
the patch that does so
^ permalink raw reply
* Re: [PATCH net] mlxsw: spectrum: Forbid creation of VLAN 1 over port/LAG
From: Petr Machata @ 2018-05-28 8:31 UTC (permalink / raw)
To: Ido Schimmel; +Cc: Andrew Lunn, Ido Schimmel, netdev, davem, jiri, mlxsw
In-Reply-To: <20180528063303.GA15094@splinter.mtl.com>
Ido Schimmel <idosch@idosch.org> writes:
> On Mon, May 28, 2018 at 05:55:58AM +0200, Andrew Lunn wrote:
>> > diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
>> > index ca38a30fbe91..adc6ab2cf429 100644
>> > --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
>> > +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
>> > @@ -4433,6 +4433,11 @@ static int mlxsw_sp_netdevice_port_upper_event(struct net_device *lower_dev,
>> > NL_SET_ERR_MSG_MOD(extack, "Can not put a VLAN on an OVS port");
>> > return -EINVAL;
>> > }
>> > + if (is_vlan_dev(upper_dev) &&
>> > + vlan_dev_vlan_id(upper_dev) == 1) {
>> > + NL_SET_ERR_MSG_MOD(extack, "Creating a VLAN device with VID 1 is unsupported: VLAN 1 carries untagged traffic");
>> > + return -EINVAL;
>> > + }
>>
>> Would ENOTSUPP be a better return code. VLAN 1 is valid, you just
>> don't support it.
>
> OK, makes sense. We currently use EINVAL for such errors, but we can
> convert to EOPNOTSUPP in net-next.
Yep, agreed.
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH net-next 6/7] net: bridge: Notify about bridge VLANs
From: Petr Machata @ 2018-05-28 8:20 UTC (permalink / raw)
To: Vivien Didelot
Cc: devel, f.fainelli, andrew, nikolay, netdev, bridge, idosch, jiri,
razvan.stefanescu, gregkh, davem
In-Reply-To: <87y3g6mpr2.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
> Hi Petr,
>
> Petr Machata <petrm@mellanox.com> writes:
>
>> Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
>>
>>>> + } else {
>>>> + err = br_switchdev_port_obj_add(dev, v->vid, flags);
>>>> + if (err && err != -EOPNOTSUPP)
>>>> + goto out;
>>>> }
>>>
>>> Except that br_switchdev_port_obj_add taking vid and flags arguments
>>> seems confusing to me, the change looks good:
>>
>> I'm not sure what you're aiming at. Both VID and flags are sent with the
>> notification, so they need to be passed on to the function somehow. Do
>> you have a counterproposal for the API?
>
> I'm only questioning the code organization here, not the functional
> aspect which I do agree with. What I'm saying is that you name a new
> switchdev helper br_switchdev_port_OBJ_add, which takes VLAN arguments
> (vid and flags.) How would you call another eventual helper taking MDB
> arguments, br_switchdev_port_OBJ_add again? So something like
> br_switchdev_port_VLAN_add would be more intuitive.
>
> At the same time there's an effort to centralize all switchdev helpers
> of the bridge layer (i.e. the software -> hardware bridge calls) into
> net/bridge/br_switchdev.c, so that file would be more adequate.
>
> You may discard my comments but I think it'd be beneficial to us all to
> finally keep a bit of consistency in that bridge layer code.
Nope, those are reasonable points. I'll post a v2 along those lines.
Thanks,
Petr
^ permalink raw reply
* Re: 4.16 issue with mbim modem and ping with size > 14552 bytes
From: Greg KH @ 2018-05-28 8:04 UTC (permalink / raw)
To: Daniele Palmas; +Cc: netdev, linux-usb
In-Reply-To: <CAGRyCJHamtS2eANzyA1GEUqQ4YQO0kCiEMDfCTbqaQh8TjSEVA@mail.gmail.com>
On Mon, May 28, 2018 at 09:58:01AM +0200, Daniele Palmas wrote:
> 2018-05-25 0:54 GMT+02:00 Daniele Palmas <dnlplm@gmail.com>:
> > Hi Greg,
> >
> > 2018-05-24 17:53 GMT+02:00 Greg KH <gregkh@linuxfoundation.org>:
> >> On Thu, May 24, 2018 at 05:04:49PM +0200, Daniele Palmas wrote:
> >>> Hello,
> >>>
> >>> I have an issue with an USB mbim modem when trying to send with ping
> >>> more than 14552 bytes: it looks like to me a kernel issue, but not at
> >>> the cdc_mbim or cdc_ncm level, anyway not sure, so I'm reporting the
> >>> issue.
> >>>
> >>> My kernel is 4.16. The device is the following:
> >>
> >> Does older kernels work, or is this something that has always been
> >> there?
> >>
> >
> > Not tested yet, I'm going to do.
> >
>
> So, ping with more than 14552 was working properly until v4.5-rc7:
> starting from v4.5 I'm not even able to make a data connection with
> mbim since things fail badly with the following:
>
> [ 259.551836] ------------[ cut here ]------------
> [ 259.551848] WARNING: CPU: 2 PID: 0 at
> /home/kernel/COD/linux/net/sched/sch_generic.c:303
> dev_watchdog+0x237/0x240()
> [ 259.551860] NETDEV WATCHDOG: wwp0s20u7i2 (cdc_mbim): transmit queue
> 0 timed out
> [ 259.551861] Modules linked in: cdc_mbim cdc_wdm cdc_ncm usbnet mii
> intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm
> snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic
> irqbypass crct10dif_pclmul snd_hda_intel snd_hda_codec snd_hda_core
> crc32_pclmul snd_hwdep ghash_clmulni_intel aesni_intel aes_x86_64
> snd_pcm snd_seq_midi lrw snd_seq_midi_event gf128mul input_leds
> snd_rawmidi snd_seq glue_helper snd_seq_device ablk_helper snd_timer
> cryptd snd soundcore shpchp serio_raw mac_hid lpc_ich 8250_fintek
> mei_me mei parport_pc ppdev lp parport autofs4 hid_generic usbhid hid
> i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect psmouse
> sysimgblt ahci fb_sys_fops e1000e libahci drm ptp pps_core wmi fjes
> video
> [ 259.551889] CPU: 2 PID: 0 Comm: swapper/2 Not tainted
> 4.5.0-040500-generic #201603140130
> [ 259.551890] Hardware name: LENOVO 10A6A0J5IX/SHARKBAY, BIOS
> FBKT79AUS 04/17/2014
> [ 259.551891] 0000000000000286 108c91d75cf5b65f ffff88021eb03d98
> ffffffff813e0233
> [ 259.551893] ffff88021eb03de0 ffffffff81d816a0 ffff88021eb03dd0
> ffffffff81080e72
> [ 259.551894] 0000000000000000 ffff8800cee81880 0000000000000002
> ffff8800a19f8000
> [ 259.551895] Call Trace:
> [ 259.551896] <IRQ> [<ffffffff813e0233>] dump_stack+0x63/0x90
> [ 259.551903] [<ffffffff81080e72>] warn_slowpath_common+0x82/0xc0
> [ 259.551904] [<ffffffff81080f0c>] warn_slowpath_fmt+0x5c/0x80
> [ 259.551907] [<ffffffff8173f557>] dev_watchdog+0x237/0x240
> [ 259.551909] [<ffffffff8173f320>] ? qdisc_rcu_free+0x40/0x40
> [ 259.551910] [<ffffffff810ecc75>] call_timer_fn+0x35/0x120
> [ 259.551911] [<ffffffff8173f320>] ? qdisc_rcu_free+0x40/0x40
> [ 259.551912] [<ffffffff810ed626>] run_timer_softirq+0x246/0x2f0
> [ 259.551914] [<ffffffff81085836>] __do_softirq+0xf6/0x280
> [ 259.551916] [<ffffffff81085b33>] irq_exit+0xa3/0xb0
> [ 259.551919] [<ffffffff81826092>] smp_apic_timer_interrupt+0x42/0x50
> [ 259.551920] [<ffffffff81824362>] apic_timer_interrupt+0x82/0x90
> [ 259.551922] <EOI> [<ffffffff816b669d>] ? cpuidle_enter_state+0x11d/0x2c0
> [ 259.551925] [<ffffffff816b6877>] cpuidle_enter+0x17/0x20
> [ 259.551928] [<ffffffff810c413a>] call_cpuidle+0x2a/0x40
> [ 259.551929] [<ffffffff810c4505>] cpu_startup_entry+0x295/0x350
> [ 259.551931] [<ffffffff81050d9e>] start_secondary+0x15e/0x190
> [ 259.551933] ---[ end trace 6f8d3c1a1b02644d ]---
>
> but this is probably something different, cause with v4.16 data
> connection works fine.
>
> If this is not helpful I guess I need to bisect.
Bisection would be best. It looks like you narrowed things down really
well already, bisection should go very quickly.
thanks,
greg k-h
^ permalink raw reply
* Re: 4.16 issue with mbim modem and ping with size > 14552 bytes
From: Daniele Palmas @ 2018-05-28 7:58 UTC (permalink / raw)
To: Greg KH; +Cc: netdev, linux-usb
In-Reply-To: <CAGRyCJFmn+H-f_sjqYW0jX6gg5FwEpmG0LvrNDFLukFV1L3SqQ@mail.gmail.com>
2018-05-25 0:54 GMT+02:00 Daniele Palmas <dnlplm@gmail.com>:
> Hi Greg,
>
> 2018-05-24 17:53 GMT+02:00 Greg KH <gregkh@linuxfoundation.org>:
>> On Thu, May 24, 2018 at 05:04:49PM +0200, Daniele Palmas wrote:
>>> Hello,
>>>
>>> I have an issue with an USB mbim modem when trying to send with ping
>>> more than 14552 bytes: it looks like to me a kernel issue, but not at
>>> the cdc_mbim or cdc_ncm level, anyway not sure, so I'm reporting the
>>> issue.
>>>
>>> My kernel is 4.16. The device is the following:
>>
>> Does older kernels work, or is this something that has always been
>> there?
>>
>
> Not tested yet, I'm going to do.
>
So, ping with more than 14552 was working properly until v4.5-rc7:
starting from v4.5 I'm not even able to make a data connection with
mbim since things fail badly with the following:
[ 259.551836] ------------[ cut here ]------------
[ 259.551848] WARNING: CPU: 2 PID: 0 at
/home/kernel/COD/linux/net/sched/sch_generic.c:303
dev_watchdog+0x237/0x240()
[ 259.551860] NETDEV WATCHDOG: wwp0s20u7i2 (cdc_mbim): transmit queue
0 timed out
[ 259.551861] Modules linked in: cdc_mbim cdc_wdm cdc_ncm usbnet mii
intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm
snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic
irqbypass crct10dif_pclmul snd_hda_intel snd_hda_codec snd_hda_core
crc32_pclmul snd_hwdep ghash_clmulni_intel aesni_intel aes_x86_64
snd_pcm snd_seq_midi lrw snd_seq_midi_event gf128mul input_leds
snd_rawmidi snd_seq glue_helper snd_seq_device ablk_helper snd_timer
cryptd snd soundcore shpchp serio_raw mac_hid lpc_ich 8250_fintek
mei_me mei parport_pc ppdev lp parport autofs4 hid_generic usbhid hid
i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect psmouse
sysimgblt ahci fb_sys_fops e1000e libahci drm ptp pps_core wmi fjes
video
[ 259.551889] CPU: 2 PID: 0 Comm: swapper/2 Not tainted
4.5.0-040500-generic #201603140130
[ 259.551890] Hardware name: LENOVO 10A6A0J5IX/SHARKBAY, BIOS
FBKT79AUS 04/17/2014
[ 259.551891] 0000000000000286 108c91d75cf5b65f ffff88021eb03d98
ffffffff813e0233
[ 259.551893] ffff88021eb03de0 ffffffff81d816a0 ffff88021eb03dd0
ffffffff81080e72
[ 259.551894] 0000000000000000 ffff8800cee81880 0000000000000002
ffff8800a19f8000
[ 259.551895] Call Trace:
[ 259.551896] <IRQ> [<ffffffff813e0233>] dump_stack+0x63/0x90
[ 259.551903] [<ffffffff81080e72>] warn_slowpath_common+0x82/0xc0
[ 259.551904] [<ffffffff81080f0c>] warn_slowpath_fmt+0x5c/0x80
[ 259.551907] [<ffffffff8173f557>] dev_watchdog+0x237/0x240
[ 259.551909] [<ffffffff8173f320>] ? qdisc_rcu_free+0x40/0x40
[ 259.551910] [<ffffffff810ecc75>] call_timer_fn+0x35/0x120
[ 259.551911] [<ffffffff8173f320>] ? qdisc_rcu_free+0x40/0x40
[ 259.551912] [<ffffffff810ed626>] run_timer_softirq+0x246/0x2f0
[ 259.551914] [<ffffffff81085836>] __do_softirq+0xf6/0x280
[ 259.551916] [<ffffffff81085b33>] irq_exit+0xa3/0xb0
[ 259.551919] [<ffffffff81826092>] smp_apic_timer_interrupt+0x42/0x50
[ 259.551920] [<ffffffff81824362>] apic_timer_interrupt+0x82/0x90
[ 259.551922] <EOI> [<ffffffff816b669d>] ? cpuidle_enter_state+0x11d/0x2c0
[ 259.551925] [<ffffffff816b6877>] cpuidle_enter+0x17/0x20
[ 259.551928] [<ffffffff810c413a>] call_cpuidle+0x2a/0x40
[ 259.551929] [<ffffffff810c4505>] cpu_startup_entry+0x295/0x350
[ 259.551931] [<ffffffff81050d9e>] start_secondary+0x15e/0x190
[ 259.551933] ---[ end trace 6f8d3c1a1b02644d ]---
but this is probably something different, cause with v4.16 data
connection works fine.
If this is not helpful I guess I need to bisect.
Thanks,
Daniele
>> I ask, as my mobile provider does horrible things to large packet sizes.
>> So much so that I have to set the mtu to 1280 just to get things to work
>> properly when tethering my phone through to my laptop. So this might be
>> a network provider issue :)
>>
>
> Yeah, I thought the same, so I tried the same scenario with Windows 10
> but it is working fine.
>
> Thanks,
> Daniele
>
>> thanks,
>>
>> greg k-h
^ permalink raw reply
* [PATCH] brcmfmac: stop watchdog before detach and free everything
From: Michael Trimarchi @ 2018-05-28 7:50 UTC (permalink / raw)
Cc: michael, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, David S. Miller,
Pieter-Paul Giesberts, Ian Molton, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev, linux-kernel
Watchdog need to be stopped in brcmf_sdio_remove to avoid
i
The system is going down NOW!
[ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 000002f8
Sent SIGTERM to all processes
[ 1348.121412] Mem abort info:
[ 1348.126962] ESR = 0x96000004
[ 1348.130023] Exception class = DABT (current EL), IL = 32 bits
[ 1348.135948] SET = 0, FnV = 0
[ 1348.138997] EA = 0, S1PTW = 0
[ 1348.142154] Data abort info:
[ 1348.145045] ISV = 0, ISS = 0x00000004
[ 1348.148884] CM = 0, WnR = 0
[ 1348.151861] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
[ 1348.158475] [00000000000002f8] pgd=0000000000000000
[ 1348.163364] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 1348.168927] Modules linked in: ipv6
[ 1348.172421] CPU: 3 PID: 1421 Comm: brcmf_wdog/mmc0 Not tainted 4.17.0-rc5-next-20180517 #18
[ 1348.180757] Hardware name: Amarula A64-Relic (DT)
[ 1348.185455] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 1348.190251] pc : brcmf_sdiod_freezer_count+0x0/0x20
[ 1348.195124] lr : brcmf_sdio_watchdog_thread+0x64/0x290
[ 1348.200253] sp : ffff00000b85be30
[ 1348.203561] x29: ffff00000b85be30 x28: 0000000000000000
[ 1348.208868] x27: ffff00000b6cb918 x26: ffff80003b990638
[ 1348.214176] x25: ffff0000087b1a20 x24: ffff80003b94f800
[ 1348.219483] x23: ffff000008e620c8 x22: ffff000008f0b660
[ 1348.224790] x21: ffff000008c6a858 x20: 00000000fffffe00
[ 1348.230097] x19: ffff80003b94f800 x18: 0000000000000001
[ 1348.235404] x17: 0000ffffab2e8a74 x16: ffff0000080d7de8
[ 1348.240711] x15: 0000000000000000 x14: 0000000000000400
[ 1348.246018] x13: 0000000000000400 x12: 0000000000000001
[ 1348.251324] x11: 00000000000002c4 x10: 0000000000000a10
[ 1348.256631] x9 : ffff00000b85bc40 x8 : ffff80003be11870
[ 1348.261937] x7 : ffff80003dfc7308 x6 : 000000078ff08b55
[ 1348.267243] x5 : 00000139e1058400 x4 : 0000000000000000
[ 1348.272550] x3 : dead000000000100 x2 : 958f2788d6618100
[ 1348.277856] x1 : 00000000fffffe00 x0 : 0000000000000000
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 412a05b..061f69d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4294,6 +4294,13 @@ void brcmf_sdio_remove(struct brcmf_sdio *bus)
brcmf_dbg(TRACE, "Enter\n");
if (bus) {
+ /* Stop watchdog task */
+ if (bus->watchdog_tsk) {
+ send_sig(SIGTERM, bus->watchdog_tsk, 1);
+ kthread_stop(bus->watchdog_tsk);
+ bus->watchdog_tsk = NULL;
+ }
+
/* De-register interrupt handler */
brcmf_sdiod_intr_unregister(bus->sdiodev);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] mlxsw: spectrum: Forbid creation of VLAN 1 over port/LAG
From: Ido Schimmel @ 2018-05-28 6:33 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Ido Schimmel, netdev, davem, jiri, petrm, mlxsw
In-Reply-To: <20180528035558.GD18029@lunn.ch>
On Mon, May 28, 2018 at 05:55:58AM +0200, Andrew Lunn wrote:
> > diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
> > index ca38a30fbe91..adc6ab2cf429 100644
> > --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
> > +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
> > @@ -4433,6 +4433,11 @@ static int mlxsw_sp_netdevice_port_upper_event(struct net_device *lower_dev,
> > NL_SET_ERR_MSG_MOD(extack, "Can not put a VLAN on an OVS port");
> > return -EINVAL;
> > }
> > + if (is_vlan_dev(upper_dev) &&
> > + vlan_dev_vlan_id(upper_dev) == 1) {
> > + NL_SET_ERR_MSG_MOD(extack, "Creating a VLAN device with VID 1 is unsupported: VLAN 1 carries untagged traffic");
> > + return -EINVAL;
> > + }
>
> Hi Ido
>
> Would ENOTSUPP be a better return code. VLAN 1 is valid, you just
> don't support it.
OK, makes sense. We currently use EINVAL for such errors, but we can
convert to EOPNOTSUPP in net-next.
Thanks
^ permalink raw reply
* Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
From: Christoph Hellwig @ 2018-05-28 6:27 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Fenghua Yu, Tony Luck, linux-ia64-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Ingo Molnar,
netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig
In-Reply-To: <alpine.DEB.2.21.1805280817310.1585-ecDvlHI5BZPZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
On Mon, May 28, 2018 at 08:18:46AM +0200, Thomas Gleixner wrote:
> > Which other two? The boot optional removal patches? They just remove
> > the visible interface, but keep the implementation which is converted
> > to the better mechanism here, so I think the order makes sense.
> > But I might be missing something..
>
> They remove the commandline switch before having the replacement in place
> unless I'm misreading something.
The command line switch to force 32-bit dma is removed without
replacement. The PCI quirk for force the 32-bit dma for VIA bridges
is kept in place, and switch to a different mechanism in this patch.
^ permalink raw reply
* Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
From: Thomas Gleixner @ 2018-05-28 6:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Fenghua Yu, Tony Luck, linux-ia64-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Ingo Molnar,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180528062725.GA4309-jcswGhMUV9g@public.gmane.org>
On Mon, 28 May 2018, Christoph Hellwig wrote:
> On Mon, May 28, 2018 at 08:18:46AM +0200, Thomas Gleixner wrote:
> > > Which other two? The boot optional removal patches? They just remove
> > > the visible interface, but keep the implementation which is converted
> > > to the better mechanism here, so I think the order makes sense.
> > > But I might be missing something..
> >
> > They remove the commandline switch before having the replacement in place
> > unless I'm misreading something.
>
> The command line switch to force 32-bit dma is removed without
> replacement. The PCI quirk for force the 32-bit dma for VIA bridges
> is kept in place, and switch to a different mechanism in this patch.
Fair enough
^ permalink raw reply
* Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
From: Christoph Hellwig @ 2018-05-28 6:19 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Fenghua Yu, Tony Luck, linux-ia64-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Ingo Molnar,
netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig
In-Reply-To: <alpine.DEB.2.21.1805280808280.1585-ecDvlHI5BZPZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
On Mon, May 28, 2018 at 08:10:40AM +0200, Thomas Gleixner wrote:
> n Fri, 25 May 2018, Christoph Hellwig wrote:
>
> x86/pci-dma: ...
>
> Please
>
> > Instead of globally disabling > 32bit DMA using the arch_dma_supported
> > hook walk the PCI bus under the actually affected bridge and mark every
> > device with the dma_32bit_limit flag. This also gets rid of the
> > arch_dma_supported hook entirely.
>
> Shouldn't this go before the other two?
Which other two? The boot optional removal patches? They just remove
the visible interface, but keep the implementation which is converted
to the better mechanism here, so I think the order makes sense.
But I might be missing something..
^ permalink raw reply
* Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
From: Thomas Gleixner @ 2018-05-28 6:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Fenghua Yu, Tony Luck, linux-ia64-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Ingo Molnar,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180528061859.GA4145-jcswGhMUV9g@public.gmane.org>
On Mon, 28 May 2018, Christoph Hellwig wrote:
> On Mon, May 28, 2018 at 08:10:40AM +0200, Thomas Gleixner wrote:
> > n Fri, 25 May 2018, Christoph Hellwig wrote:
> >
> > x86/pci-dma: ...
> >
> > Please
> >
> > > Instead of globally disabling > 32bit DMA using the arch_dma_supported
> > > hook walk the PCI bus under the actually affected bridge and mark every
> > > device with the dma_32bit_limit flag. This also gets rid of the
> > > arch_dma_supported hook entirely.
> >
> > Shouldn't this go before the other two?
>
> Which other two? The boot optional removal patches? They just remove
> the visible interface, but keep the implementation which is converted
> to the better mechanism here, so I think the order makes sense.
> But I might be missing something..
They remove the commandline switch before having the replacement in place
unless I'm misreading something.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
From: Thomas Gleixner @ 2018-05-28 6:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Fenghua Yu, Tony Luck, linux-ia64-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Ingo Molnar,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180525143512.1466-8-hch-jcswGhMUV9g@public.gmane.org>
n Fri, 25 May 2018, Christoph Hellwig wrote:
x86/pci-dma: ...
Please
> Instead of globally disabling > 32bit DMA using the arch_dma_supported
> hook walk the PCI bus under the actually affected bridge and mark every
> device with the dma_32bit_limit flag. This also gets rid of the
> arch_dma_supported hook entirely.
Shouldn't this go before the other two?
> Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Reviewed-by: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
^ permalink raw reply
* Re: [PATCH 6/7] x86: remove the explicit nodac and allowdac option
From: Thomas Gleixner @ 2018-05-28 6:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Fenghua Yu, Tony Luck, linux-ia64-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Ingo Molnar,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180525143512.1466-7-hch-jcswGhMUV9g@public.gmane.org>
On Fri, 25 May 2018, Christoph Hellwig wrote:
x86/pci-dma: ...
Please
> This is something drivers should decide (modulo chipset quirks like
> for VIA), which as far as I can tell is how things have been handled
> for the last 15 years.
>
> Note that we keep the usedac option for now, as it is used in the wild
> to override the too generic VIA quirk.
>
> Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Reviewed-by: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
^ 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