* 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
* Re: [PATCH 5/7] x86: remove the experimental forcesac boot option
From: Thomas Gleixner @ 2018-05-28 6:07 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-6-hch-jcswGhMUV9g@public.gmane.org>
On Fri, 25 May 2018, Christoph Hellwig wrote:
x86/pci-dma: ...
Please
> Limiting the dma mask to avoid PCI (pre-PCIe) DAC cycles while paying
> the huge overhead of an IOMMU is rather pointless, and this seriously
> gets in the way of dma mapping work.
>
> Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Reviewed-by: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
^ permalink raw reply
* [PATCH iproute2] net:sched: add action inheritdsfield to skbedit
From: Fu, Qiaobin @ 2018-05-28 5:54 UTC (permalink / raw)
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, jhs@mojatatu.com, Michel Machado,
Marcelo Ricardo Leitner, xiyou.wangcong@gmail.com
The new action inheritdsfield copies the field DS of
IPv4 and IPv6 packets into skb->priority. This enables
later classification of packets based on the DS field.
Original idea by Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Qiaobin Fu <qiaobinf@bu.edu>
Reviewed-by: Michel Machado <michel@digirati.com.br>
---
Note that the motivation for this patch is found in the following discussion:
https://www.spinics.net/lists/netdev/msg501061.html
---
diff --git a/include/uapi/linux/tc_act/tc_skbedit.h b/include/uapi/linux/tc_act/tc_skbedit.h
index fbcfe27..432ad2f 100644
--- a/include/uapi/linux/tc_act/tc_skbedit.h
+++ b/include/uapi/linux/tc_act/tc_skbedit.h
@@ -30,9 +30,11 @@
#define SKBEDIT_F_MARK 0x4
#define SKBEDIT_F_PTYPE 0x8
#define SKBEDIT_F_MASK 0x10
+#define SKBEDIT_F_INHERITDSFIELD 0x20
struct tc_skbedit {
tc_gen;
+ __u64 flags;
};
enum {
diff --git a/tc/m_skbedit.c b/tc/m_skbedit.c
index db5c64c..7553a40 100644
--- a/tc/m_skbedit.c
+++ b/tc/m_skbedit.c
@@ -30,16 +30,18 @@
static void explain(void)
{
- fprintf(stderr, "Usage: ... skbedit <[QM] [PM] [MM] [PT]>\n"
+ fprintf(stderr, "Usage: ... skbedit <[QM] [PM] [MM] [PT] [IF]>\n"
"QM = queue_mapping QUEUE_MAPPING\n"
"PM = priority PRIORITY\n"
"MM = mark MARK\n"
"PT = ptype PACKETYPE\n"
+ "IF = inheritdsfield\n"
"PACKETYPE = is one of:\n"
" host, otherhost, broadcast, multicast\n"
"QUEUE_MAPPING = device transmit queue to use\n"
"PRIORITY = classID to assign to priority field\n"
- "MARK = firewall mark to set\n");
+ "MARK = firewall mark to set\n"
+ "note: inheritdsfield maps DS field to skb->priority\n");
}
static void
@@ -59,7 +61,7 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
struct rtattr *tail;
unsigned int tmp;
__u16 queue_mapping, ptype;
- __u32 flags = 0, priority, mark;
+ __u32 priority, mark;
struct tc_skbedit sel = { 0 };
if (matches(*argv, "skbedit") != 0)
@@ -69,7 +71,7 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
while (argc > 0) {
if (matches(*argv, "queue_mapping") == 0) {
- flags |= SKBEDIT_F_QUEUE_MAPPING;
+ sel.flags |= SKBEDIT_F_QUEUE_MAPPING;
NEXT_ARG();
if (get_unsigned(&tmp, *argv, 10) || tmp > 65535) {
fprintf(stderr, "Illegal queue_mapping\n");
@@ -78,7 +80,7 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
queue_mapping = tmp;
ok++;
} else if (matches(*argv, "priority") == 0) {
- flags |= SKBEDIT_F_PRIORITY;
+ sel.flags |= SKBEDIT_F_PRIORITY;
NEXT_ARG();
if (get_tc_classid(&priority, *argv)) {
fprintf(stderr, "Illegal priority\n");
@@ -86,7 +88,7 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
}
ok++;
} else if (matches(*argv, "mark") == 0) {
- flags |= SKBEDIT_F_MARK;
+ sel.flags |= SKBEDIT_F_MARK;
NEXT_ARG();
if (get_u32(&mark, *argv, 0)) {
fprintf(stderr, "Illegal mark\n");
@@ -109,7 +111,10 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
*argv);
return -1;
}
- flags |= SKBEDIT_F_PTYPE;
+ sel.flags |= SKBEDIT_F_PTYPE;
+ ok++;
+ } else if (matches(*argv, "inheritdsfield") == 0) {
+ sel.flags |= SKBEDIT_F_INHERITDSFIELD;
ok++;
} else if (matches(*argv, "help") == 0) {
usage();
@@ -144,16 +149,16 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
tail = addattr_nest(n, MAX_MSG, tca_id);
addattr_l(n, MAX_MSG, TCA_SKBEDIT_PARMS, &sel, sizeof(sel));
- if (flags & SKBEDIT_F_QUEUE_MAPPING)
+ if (sel.flags & SKBEDIT_F_QUEUE_MAPPING)
addattr_l(n, MAX_MSG, TCA_SKBEDIT_QUEUE_MAPPING,
&queue_mapping, sizeof(queue_mapping));
- if (flags & SKBEDIT_F_PRIORITY)
+ if (sel.flags & SKBEDIT_F_PRIORITY)
addattr_l(n, MAX_MSG, TCA_SKBEDIT_PRIORITY,
&priority, sizeof(priority));
- if (flags & SKBEDIT_F_MARK)
+ if (sel.flags & SKBEDIT_F_MARK)
addattr_l(n, MAX_MSG, TCA_SKBEDIT_MARK,
&mark, sizeof(mark));
- if (flags & SKBEDIT_F_PTYPE)
+ if (sel.flags & SKBEDIT_F_PTYPE)
addattr_l(n, MAX_MSG, TCA_SKBEDIT_PTYPE,
&ptype, sizeof(ptype));
addattr_nest_end(n, tail);
@@ -211,6 +216,8 @@ static int print_skbedit(struct action_util *au, FILE *f, struct rtattr *arg)
else
fprintf(f, " ptype %d", *ptype);
}
+ if (p->flags & SKBEDIT_F_INHERITDSFIELD)
+ fprintf(f, "inherit DS field ");
print_action_control(f, " ", p->action, "");
^ permalink raw reply related
* [PATCH v2 net-next] net:sched: add action inheritdsfield to skbedit
From: Fu, Qiaobin @ 2018-05-28 5:40 UTC (permalink / raw)
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, jhs@mojatatu.com, Michel Machado,
Marcelo Ricardo Leitner, xiyou.wangcong@gmail.com
The new action inheritdsfield copies the field DS of
IPv4 and IPv6 packets into skb->priority. This enables
later classification of packets based on the DS field.
Original idea by Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Qiaobin Fu <qiaobinf@bu.edu>
Reviewed-by: Michel Machado <michel@digirati.com.br>
---
Note that the motivation for this patch is found in the following discussion:
https://www.spinics.net/lists/netdev/msg501061.html
---
diff --git a/include/uapi/linux/tc_act/tc_skbedit.h b/include/uapi/linux/tc_act/tc_skbedit.h
index fbcfe27..432ad2f 100644
--- a/include/uapi/linux/tc_act/tc_skbedit.h
+++ b/include/uapi/linux/tc_act/tc_skbedit.h
@@ -30,9 +30,11 @@
#define SKBEDIT_F_MARK 0x4
#define SKBEDIT_F_PTYPE 0x8
#define SKBEDIT_F_MASK 0x10
+#define SKBEDIT_F_INHERITDSFIELD 0x20
struct tc_skbedit {
tc_gen;
+ __u64 flags;
};
enum {
diff --git a/net/sched/act_skbedit.c b/net/sched/act_skbedit.c
index 6138d1d7..c3e9d03 100644
--- a/net/sched/act_skbedit.c
+++ b/net/sched/act_skbedit.c
@@ -23,6 +23,9 @@
#include <linux/rtnetlink.h>
#include <net/netlink.h>
#include <net/pkt_sched.h>
+#include <net/ip.h>
+#include <net/ipv6.h>
+#include <net/dsfield.h>
#include <linux/tc_act/tc_skbedit.h>
#include <net/tc_act/tc_skbedit.h>
@@ -39,8 +42,32 @@ static int tcf_skbedit(struct sk_buff *skb, const struct tc_action *a,
tcf_lastuse_update(&d->tcf_tm);
bstats_update(&d->tcf_bstats, skb);
- if (d->flags & SKBEDIT_F_PRIORITY)
- skb->priority = d->priority;
+ if (d->flags & SKBEDIT_F_INHERITDSFIELD) {
+ int wlen = skb_network_offset(skb);
+
+ switch (tc_skb_protocol(skb)) {
+ case htons(ETH_P_IP):
+ wlen += sizeof(struct iphdr);
+ if (!pskb_may_pull(skb, wlen))
+ goto err;
+ skb->priority = ipv4_get_dsfield(ip_hdr(skb)) >> 2;
+ break;
+
+ case htons(ETH_P_IPV6):
+ wlen += sizeof(struct ipv6hdr);
+ if (!pskb_may_pull(skb, wlen))
+ goto err;
+ skb->priority = ipv6_get_dsfield(ipv6_hdr(skb)) >> 2;
+ break;
+
+ default:
+ goto default_priority;
+ }
+ } else {
+default_priority:
+ if (d->flags & SKBEDIT_F_PRIORITY)
+ skb->priority = d->priority;
+ }
if (d->flags & SKBEDIT_F_QUEUE_MAPPING &&
skb->dev->real_num_tx_queues > d->queue_mapping)
skb_set_queue_mapping(skb, d->queue_mapping);
@@ -53,6 +80,10 @@ static int tcf_skbedit(struct sk_buff *skb, const struct tc_action *a,
spin_unlock(&d->tcf_lock);
return d->tcf_action;
+
+err:
+ spin_unlock(&d->tcf_lock);
+ return TC_ACT_SHOT;
}
static const struct nla_policy skbedit_policy[TCA_SKBEDIT_MAX + 1] = {
@@ -115,6 +146,8 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
}
parm = nla_data(tb[TCA_SKBEDIT_PARMS]);
+ if (parm->flags & SKBEDIT_F_INHERITDSFIELD)
+ flags |= SKBEDIT_F_INHERITDSFIELD;
exists = tcf_idr_check(tn, parm->index, a, bind);
if (exists && bind)
^ permalink raw reply related
* [PATCH net] be2net: Fix error detection logic for BE3
From: Suresh Reddy @ 2018-05-28 5:26 UTC (permalink / raw)
To: netdev
In-Reply-To: <Suresh.Reddy@broadcom.com>
Check for 0xE00 (RECOVERABLE_ERR) along with ARMFW UE (0x0)
in be_detect_error() to know whether the error is valid error or not
Fixes: 673c96e5a ("be2net: Fix UE detection logic for BE3")
Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index c697e79..8f75500 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3309,7 +3309,9 @@ void be_detect_error(struct be_adapter *adapter)
if ((val & POST_STAGE_FAT_LOG_START)
!= POST_STAGE_FAT_LOG_START &&
(val & POST_STAGE_ARMFW_UE)
- != POST_STAGE_ARMFW_UE)
+ != POST_STAGE_ARMFW_UE &&
+ (val & POST_STAGE_RECOVERABLE_ERR)
+ != POST_STAGE_RECOVERABLE_ERR)
return;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2] Revert "alx: remove WoL support"
From: AceLan Kao @ 2018-05-28 5:06 UTC (permalink / raw)
To: David Miller
Cc: James Cliburn, Chris Snook, rakesh, netdev, Emily Chien,
Andrew Lunn, Linux-Kernel@Vger. Kernel. Org, Johannes Berg,
Johannes Stezenbach
In-Reply-To: <20180520.231820.868530785962553925.davem@davemloft.net>
Hi all,
Just inform you a news reported by a user who confirmed the wake up
issue can't be reproduce by the new kernel.
https://bugzilla.kernel.org/show_bug.cgi?id=61651#c126
<quote>
Guillaume de Jabrun 2018-05-27 15:12:54 UTC
I am using this patch for a long time. I was experiencing the "wake up
twice" bug, but with recent kernel version, I don't have this issue
anymore.
I can't tell which version actually fix the bug (I don't remember..).
</quote>
Best regards,
AceLan Kao.
2018-05-21 11:18 GMT+08:00 David Miller <davem@davemloft.net>:
> From: AceLan Kao <acelan.kao@canonical.com>
> Date: Mon, 21 May 2018 11:14:00 +0800
>
>> We are willing to fix the issue, but we don't have a machine to
>> reproduce it, and the WoL feature has been removed 5 years ago, it's
>> hard to find those buggy machines.
>
> Have you bothered to ask the person who did the revert?
>
>> WoL is a feature that is only used by a very small group of people,
>> and the wake up issue looks like only happens on some
>> platforms. Which means only small part of the group of people are
>> affected.
>
> One of those people was the wireless networking stack maintainer.
>
>> So, it's not a serious issue worth to remove it from alx driver.
>
> I disagree.
>
> You must fix the regression solved by the revert, before adding
> WoL support back to the driver.
>
> I'm not going to say this again.
>
> Thank you.
>
^ permalink raw reply
* [PATCH bpf v2 5/5] selftests/bpf: test_sockmap, print additional test options
From: Prashant Bhole @ 2018-05-28 4:38 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, John Fastabend
Cc: Prashant Bhole, David S . Miller, Shuah Khan, netdev,
linux-kselftest
In-Reply-To: <20180528043803.4824-1-bhole_prashant_q7@lab.ntt.co.jp>
Print values of test options like apply, cork, start, end so that
individual failed tests can be identified for manual run
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
tools/testing/selftests/bpf/test_sockmap.c | 28 +++++++++++++++-------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_sockmap.c b/tools/testing/selftests/bpf/test_sockmap.c
index e8faf4596dac..7970d48c4acb 100644
--- a/tools/testing/selftests/bpf/test_sockmap.c
+++ b/tools/testing/selftests/bpf/test_sockmap.c
@@ -869,6 +869,8 @@ static char *test_to_str(int test)
#define OPTSTRING 60
static void test_options(char *options)
{
+ char tstr[OPTSTRING];
+
memset(options, 0, OPTSTRING);
if (txmsg_pass)
@@ -881,14 +883,22 @@ static void test_options(char *options)
strncat(options, "redir_noisy,", OPTSTRING);
if (txmsg_drop)
strncat(options, "drop,", OPTSTRING);
- if (txmsg_apply)
- strncat(options, "apply,", OPTSTRING);
- if (txmsg_cork)
- strncat(options, "cork,", OPTSTRING);
- if (txmsg_start)
- strncat(options, "start,", OPTSTRING);
- if (txmsg_end)
- strncat(options, "end,", OPTSTRING);
+ if (txmsg_apply) {
+ snprintf(tstr, OPTSTRING, "apply %d,", txmsg_apply);
+ strncat(options, tstr, OPTSTRING);
+ }
+ if (txmsg_cork) {
+ snprintf(tstr, OPTSTRING, "cork %d,", txmsg_cork);
+ strncat(options, tstr, OPTSTRING);
+ }
+ if (txmsg_start) {
+ snprintf(tstr, OPTSTRING, "start %d,", txmsg_start);
+ strncat(options, tstr, OPTSTRING);
+ }
+ if (txmsg_end) {
+ snprintf(tstr, OPTSTRING, "end %d,", txmsg_end);
+ strncat(options, tstr, OPTSTRING);
+ }
if (txmsg_ingress)
strncat(options, "ingress,", OPTSTRING);
if (txmsg_skb)
@@ -897,7 +907,7 @@ static void test_options(char *options)
static int __test_exec(int cgrp, int test, struct sockmap_options *opt)
{
- char *options = calloc(60, sizeof(char));
+ char *options = calloc(OPTSTRING, sizeof(char));
int err;
if (test == SENDPAGE)
--
2.17.0
^ permalink raw reply related
* [PATCH bpf v2 4/5] selftests/bpf: test_sockmap, fix data verification
From: Prashant Bhole @ 2018-05-28 4:38 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, John Fastabend
Cc: Prashant Bhole, David S . Miller, Shuah Khan, netdev,
linux-kselftest
In-Reply-To: <20180528043803.4824-1-bhole_prashant_q7@lab.ntt.co.jp>
When data verification is enabled, some tests fail because verification is done
incorrectly. Following changes fix it.
- Identify the size of data block to be verified
- Reset verification counter when data block size is reached
- Fixed the value printed in case of verfication failure
Fixes: 16962b2404ac ("bpf: sockmap, add selftests")
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
tools/testing/selftests/bpf/test_sockmap.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/test_sockmap.c b/tools/testing/selftests/bpf/test_sockmap.c
index f79397513362..e8faf4596dac 100644
--- a/tools/testing/selftests/bpf/test_sockmap.c
+++ b/tools/testing/selftests/bpf/test_sockmap.c
@@ -337,8 +337,15 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
int fd_flags = O_NONBLOCK;
struct timeval timeout;
float total_bytes;
+ int bytes_cnt = 0;
+ int chunk_sz;
fd_set w;
+ if (opt->sendpage)
+ chunk_sz = iov_length * cnt;
+ else
+ chunk_sz = iov_length * iov_count;
+
fcntl(fd, fd_flags);
total_bytes = (float)iov_count * (float)iov_length * (float)cnt;
err = clock_gettime(CLOCK_MONOTONIC, &s->start);
@@ -388,9 +395,14 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
errno = -EIO;
fprintf(stderr,
"detected data corruption @iov[%i]:%i %02x != %02x, %02x ?= %02x\n",
- i, j, d[j], k - 1, d[j+1], k + 1);
+ i, j, d[j], k - 1, d[j+1], k);
goto out_errno;
}
+ bytes_cnt++;
+ if (bytes_cnt == chunk_sz) {
+ k = 0;
+ bytes_cnt = 0;
+ }
recv--;
}
}
--
2.17.0
^ permalink raw reply related
* [PATCH bpf v2 3/5] selftests/bpf: test_sockmap, fix test timeout
From: Prashant Bhole @ 2018-05-28 4:38 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, John Fastabend
Cc: Prashant Bhole, David S . Miller, Shuah Khan, netdev,
linux-kselftest
In-Reply-To: <20180528043803.4824-1-bhole_prashant_q7@lab.ntt.co.jp>
In order to reduce runtime of tests, recently timout for select() call
was reduced from 1sec to 10usec. This was causing many tests failures.
It was caught with failure handling commits in this series.
Restoring the timeout from 10usec to 1sec
Fixes: a18fda1a62c3 ("bpf: reduce runtime of test_sockmap tests")
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
tools/testing/selftests/bpf/test_sockmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_sockmap.c b/tools/testing/selftests/bpf/test_sockmap.c
index 8a81ea0e9fb6..f79397513362 100644
--- a/tools/testing/selftests/bpf/test_sockmap.c
+++ b/tools/testing/selftests/bpf/test_sockmap.c
@@ -345,8 +345,8 @@ static int msg_loop(int fd, int iov_count, int iov_length, int cnt,
if (err < 0)
perror("recv start time: ");
while (s->bytes_recvd < total_bytes) {
- timeout.tv_sec = 0;
- timeout.tv_usec = 10;
+ timeout.tv_sec = 1;
+ timeout.tv_usec = 0;
/* FD sets */
FD_ZERO(&w);
--
2.17.0
^ permalink raw reply related
* [PATCH bpf v2 2/5] selftests/bpf: test_sockmap, join cgroup in selftest mode
From: Prashant Bhole @ 2018-05-28 4:38 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, John Fastabend
Cc: Prashant Bhole, David S . Miller, Shuah Khan, netdev,
linux-kselftest
In-Reply-To: <20180528043803.4824-1-bhole_prashant_q7@lab.ntt.co.jp>
In case of selftest mode, temporary cgroup environment is created but
cgroup is not joined. It causes test failures. Fixed by joining the
cgroup
Fixes: 16962b2404ac ("bpf: sockmap, add selftests")
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
tools/testing/selftests/bpf/test_sockmap.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_sockmap.c b/tools/testing/selftests/bpf/test_sockmap.c
index 34feb74c95c4..8a81ea0e9fb6 100644
--- a/tools/testing/selftests/bpf/test_sockmap.c
+++ b/tools/testing/selftests/bpf/test_sockmap.c
@@ -1342,6 +1342,11 @@ static int __test_suite(char *bpf_file)
return cg_fd;
}
+ if (join_cgroup(CG_PATH)) {
+ fprintf(stderr, "ERROR: failed to join cgroup\n");
+ return -EINVAL;
+ }
+
/* Tests basic commands and APIs with range of iov values */
txmsg_start = txmsg_end = 0;
err = test_txmsg(cg_fd);
--
2.17.0
^ permalink raw reply related
* [PATCH bpf v2 1/5] selftests/bpf: test_sockmap, check test failure
From: Prashant Bhole @ 2018-05-28 4:37 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, John Fastabend
Cc: Prashant Bhole, David S . Miller, Shuah Khan, netdev,
linux-kselftest
In-Reply-To: <20180528043803.4824-1-bhole_prashant_q7@lab.ntt.co.jp>
Test failures are not identified because exit code of RX/TX threads
is not checked. Also threads are not returning correct exit code.
- Return exit code from threads depending on test execution status
- In main thread, check the exit code of RX/TX threads
Fixes: 16962b2404ac ("bpf: sockmap, add selftests")
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
tools/testing/selftests/bpf/test_sockmap.c | 25 ++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_sockmap.c b/tools/testing/selftests/bpf/test_sockmap.c
index eb17fae458e6..34feb74c95c4 100644
--- a/tools/testing/selftests/bpf/test_sockmap.c
+++ b/tools/testing/selftests/bpf/test_sockmap.c
@@ -429,8 +429,8 @@ static int sendmsg_test(struct sockmap_options *opt)
struct msg_stats s = {0};
int iov_count = opt->iov_count;
int iov_buf = opt->iov_length;
+ int rx_status, tx_status;
int cnt = opt->rate;
- int status;
errno = 0;
@@ -442,7 +442,7 @@ static int sendmsg_test(struct sockmap_options *opt)
rxpid = fork();
if (rxpid == 0) {
if (opt->drop_expected)
- exit(1);
+ exit(0);
if (opt->sendpage)
iov_count = 1;
@@ -463,7 +463,7 @@ static int sendmsg_test(struct sockmap_options *opt)
"rx_sendmsg: TX: %zuB %fB/s %fGB/s RX: %zuB %fB/s %fGB/s\n",
s.bytes_sent, sent_Bps, sent_Bps/giga,
s.bytes_recvd, recvd_Bps, recvd_Bps/giga);
- exit(1);
+ exit(err ? 1 : 0);
} else if (rxpid == -1) {
perror("msg_loop_rx: ");
return errno;
@@ -491,14 +491,27 @@ static int sendmsg_test(struct sockmap_options *opt)
"tx_sendmsg: TX: %zuB %fB/s %f GB/s RX: %zuB %fB/s %fGB/s\n",
s.bytes_sent, sent_Bps, sent_Bps/giga,
s.bytes_recvd, recvd_Bps, recvd_Bps/giga);
- exit(1);
+ exit(err ? 1 : 0);
} else if (txpid == -1) {
perror("msg_loop_tx: ");
return errno;
}
- assert(waitpid(rxpid, &status, 0) == rxpid);
- assert(waitpid(txpid, &status, 0) == txpid);
+ assert(waitpid(rxpid, &rx_status, 0) == rxpid);
+ assert(waitpid(txpid, &tx_status, 0) == txpid);
+ if (WIFEXITED(rx_status)) {
+ err = WEXITSTATUS(rx_status);
+ if (err) {
+ fprintf(stderr, "rx thread exited with err %d. ", err);
+ goto out;
+ }
+ }
+ if (WIFEXITED(tx_status)) {
+ err = WEXITSTATUS(tx_status);
+ if (err)
+ fprintf(stderr, "tx thread exited with err %d. ", err);
+ }
+out:
return err;
}
--
2.17.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox