* Re: [RFC] nasty corner case in unix_dgram_sendmsg()
From: Al Viro @ 2019-02-26 23:59 UTC (permalink / raw)
To: Jason Baron; +Cc: Rainer Weikusat, netdev
In-Reply-To: <552b3d67-2f43-5831-e4ea-666827de54fe@akamai.com>
On Tue, Feb 26, 2019 at 03:35:39PM -0500, Jason Baron wrote:
> > I understand what the unix_dgram_peer_wake_me() is doing; I understand
> > what unix_dgram_poll() is using it for. What I do not understand is
> > what's the point of doing that in unix_dgram_sendmsg()...
> >
>
> Hi,
>
> So the unix_dgram_peer_wake_me() in unix_dgram_sendmsg() is there for
> epoll in edge-triggered mode. In that case, we want to ensure that if
> -EAGAIN is returned a subsequent epoll_wait() is not stuck indefinitely.
> Probably could use a comment...
*owwww*
Let me see if I've got it straight - you want the forwarding rearmed,
so that it would match the behaviour of ep_poll_callback() (i.e.
removing only when POLLFREE is passed)? Looks like an odd way to
do it, if that's what's happening...
While we are at it, why disarm a forwarder upon noticing that peer
is dead? Wouldn't it be simpler to move that
wake_up_interruptible_all(&u->peer_wait);
in unix_release_sock() to just before
unix_state_unlock(sk);
a line prior? Then anyone seeing SOCK_DEAD on (locked) peer
would be guaranteed that all forwarders are gone...
Another fun question about the same dgram sendmsg:
if (unix_peer(sk) == other) {
unix_peer(sk) = NULL;
unix_dgram_peer_wake_disconnect_wakeup(sk, other);
unix_state_unlock(sk);
unix_dgram_disconnected(sk, other);
... and we are holding any locks at the last line. What happens
if we have thread A doing
decide which address to talk to
connect(fd, that address)
send request over fd (with send(2) or write(2))
read reply from fd (recv(2) or read(2))
in a loop, with thread B doing explicit sendto(2) over the same
socket?
Suppose B happens to send to the last server thread A was talking
to and finds it just closed (e.g. because the last request from
A had been "shut down", which server has honoured). B gets ECONNREFUSED,
as it ought to, but it can also ends up disrupting the next exchange
of A.
Shouldn't we rather extract the skbs from that queue *before*
dropping sk->lock? E.g. move them to a temporary queue, and flush
that queue after we'd unlocked sk...
^ permalink raw reply
* Zdravstvujte Vas interesuyut bazy dannyh dlya prodazhi Vashih tovarov i uslug?
From: netdev @ 2019-02-26 4:48 UTC (permalink / raw)
To: netdev
Zdravstvujte Vas interesuyut bazy dannyh dlya prodazhi Vashih tovarov i uslug?
^ permalink raw reply
* Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
From: si-wei liu @ 2019-02-27 0:17 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Samudrala, Sridhar, Siwei Liu, Jiri Pirko, Stephen Hemminger,
David Miller, Netdev, virtualization, virtio-dev,
Brandeburg, Jesse, Alexander Duyck, Jakub Kicinski, Jason Wang,
liran.alon
In-Reply-To: <20190225210529-mutt-send-email-mst@kernel.org>
On 2/25/2019 6:08 PM, Michael S. Tsirkin wrote:
> On Mon, Feb 25, 2019 at 04:58:07PM -0800, si-wei liu wrote:
>>
>> On 2/22/2019 7:14 AM, Michael S. Tsirkin wrote:
>>> On Thu, Feb 21, 2019 at 11:55:11PM -0800, si-wei liu wrote:
>>>> On 2/21/2019 11:00 PM, Samudrala, Sridhar wrote:
>>>>> On 2/21/2019 7:33 PM, si-wei liu wrote:
>>>>>> On 2/21/2019 5:39 PM, Michael S. Tsirkin wrote:
>>>>>>> On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote:
>>>>>>>> Sorry for replying to this ancient thread. There was some remaining
>>>>>>>> issue that I don't think the initial net_failover patch got addressed
>>>>>>>> cleanly, see:
>>>>>>>>
>>>>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
>>>>>>>>
>>>>>>>> The renaming of 'eth0' to 'ens4' fails because the udev userspace was
>>>>>>>> not specifically writtten for such kernel automatic enslavement.
>>>>>>>> Specifically, if it is a bond or team, the slave would typically get
>>>>>>>> renamed *before* virtual device gets created, that's what udev can
>>>>>>>> control (without getting netdev opened early by the other part of
>>>>>>>> kernel) and other userspace components for e.g. initramfs,
>>>>>>>> init-scripts can coordinate well in between. The in-kernel
>>>>>>>> auto-enslavement of net_failover breaks this userspace convention,
>>>>>>>> which don't provides a solution if user care about consistent naming
>>>>>>>> on the slave netdevs specifically.
>>>>>>>>
>>>>>>>> Previously this issue had been specifically called out when IFF_HIDDEN
>>>>>>>> and the 1-netdev was proposed, but no one gives out a solution to this
>>>>>>>> problem ever since. Please share your mind how to proceed and solve
>>>>>>>> this userspace issue if netdev does not welcome a 1-netdev model.
>>>>>>> Above says:
>>>>>>>
>>>>>>> there's no motivation in the systemd/udevd community at
>>>>>>> this point to refactor the rename logic and make it work well with
>>>>>>> 3-netdev.
>>>>>>>
>>>>>>> What would the fix be? Skip slave devices?
>>>>>>>
>>>>>> There's nothing user can get if just skipping slave devices - the
>>>>>> name is still unchanged and unpredictable e.g. eth0, or eth1 the
>>>>>> next reboot, while the rest may conform to the naming scheme (ens3
>>>>>> and such). There's no way one can fix this in userspace alone - when
>>>>>> the failover is created the enslaved netdev was opened by the kernel
>>>>>> earlier than the userspace is made aware of, and there's no
>>>>>> negotiation protocol for kernel to know when userspace has done
>>>>>> initial renaming of the interface. I would expect netdev list should
>>>>>> at least provide the direction in general for how this can be
>>>>>> solved...
>>> I was just wondering what did you mean when you said
>>> "refactor the rename logic and make it work well with 3-netdev" -
>>> was there a proposal udev rejected?
>> No. I never believed this particular issue can be fixed in userspace alone.
>> Previously someone had said it could be, but I never see any work or
>> relevant discussion ever happened in various userspace communities (for e.g.
>> dracut, initramfs-tools, systemd, udev, and NetworkManager). IMHO the root
>> of the issue derives from the kernel, it makes more sense to start from
>> netdev, work out and decide on a solution: see what can be done in the
>> kernel in order to fix it, then after that engage userspace community for
>> the feasibility...
>>
>>> Anyway, can we write a time diagram for what happens in which order that
>>> leads to failure? That would help look for triggers that we can tie
>>> into, or add new ones.
>>>
>> See attached diagram.
>>
>>>
>>>
>>>
>>>>> Is there an issue if slave device names are not predictable? The user/admin scripts are expected
>>>>> to only work with the master failover device.
>>>> Where does this expectation come from?
>>>>
>>>> Admin users may have ethtool or tc configurations that need to deal with
>>>> predictable interface name. Third-party app which was built upon specifying
>>>> certain interface name can't be modified to chase dynamic names.
>>>>
>>>> Specifically, we have pre-canned image that uses ethtool to fine tune VF
>>>> offload settings post boot for specific workload. Those images won't work
>>>> well if the name is constantly changing just after couple rounds of live
>>>> migration.
>>> It should be possible to specify the ethtool configuration on the
>>> master and have it automatically propagated to the slave.
>>>
>>> BTW this is something we should look at IMHO.
>> I was elaborating a few examples that the expectation and assumption that
>> user/admin scripts only deal with master failover device is incorrect. It
>> had never been taken good care of, although I did try to emphasize it from
>> the very beginning.
>>
>> Basically what you said about propagating the ethtool configuration down to
>> the slave is the key pursuance of 1-netdev model. However, what I am seeking
>> now is any alternative that can also fix the specific udev rename problem,
>> before concluding that 1-netdev is the only solution. Generally a 1-netdev
>> scheme would take time to implement, while I'm trying to find a way out to
>> fix this particular naming problem under 3-netdev.
>>
>>>>> Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
>>>>> about moving them to a hidden network namespace so that they are not visible from the default namespace.
>>>>> I looked into this sometime back, but did not find the right kernel api to create a network namespace within
>>>>> kernel. If so, we could use this mechanism to simulate a 1-netdev model.
>>>> Yes, that's one possible implementation (IMHO the key is to make 1-netdev
>>>> model as much transparent to a real NIC as possible, while a hidden netns is
>>>> just the vehicle). However, I recall there was resistance around this
>>>> discussion that even the concept of hiding itself is a taboo for Linux
>>>> netdev. I would like to summon potential alternatives before concluding
>>>> 1-netdev is the only solution too soon.
>>>>
>>>> Thanks,
>>>> -Siwei
>>> Your scripts would not work at all then, right?
>> At this point we don't claim images with such usage as SR-IOV live
>> migrate-able. We would flag it as live migrate-able until this ethtool
>> config issue is fully addressed and a transparent live migration solution
>> emerges in upstream eventually.
>>
>>
>> Thanks,
>> -Siwei
>>>
>>>>>> -Siwei
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>>>
>> net_failover(kernel) | network.service (user) | systemd-udevd (user)
>> --------------------------------------------------+------------------------------+--------------------------------------------
>> (standby virtio-net and net_failover | |
>> devices created and initialized, | |
>> i.e. virtnet_probe()-> | |
>> net_failover_create() | |
>> was done.) | |
>> | |
>> | runs `ifup ens3' -> |
>> | ip link set dev ens3 up |
>> net_failover_open() | |
>> dev_open(virtnet_dev) | |
>> virtnet_open(virtnet_dev) | |
>> netif_carrier_on(failover_dev) | |
>> ... | |
>> | |
>> (VF hot plugged in) | |
>> ixgbevf_probe() | |
>> register_netdev(ixgbevf_netdev) | |
>> netdev_register_kobject(ixgbevf_netdev) | |
>> kobject_add(ixgbevf_dev) | |
>> device_add(ixgbevf_dev) | |
>> kobject_uevent(&ixgbevf_dev->kobj, KOBJ_ADD) | |
>> netlink_broadcast() | |
>> ... | |
>> call_netdevice_notifiers(NETDEV_REGISTER) | |
>> failover_event(..., NETDEV_REGISTER, ...) | |
>> failover_slave_register(ixgbevf_netdev) | |
>> net_failover_slave_register(ixgbevf_netdev) | |
>> dev_open(ixgbevf_netdev) | |
>> | |
>> | |
>> | | received ADD uevent from netlink fd
>> | | ...
>> | | udev-builtin-net_id.c:dev_pci_slot()
>> | | (decided to renamed 'eth0' )
>> | | ip link set dev eth0 name ens4
>> (dev_change_name() returns -EBUSY as | |
>> ixgbevf_netdev->flags has IFF_UP) | |
>> | |
>>
> Given renaming slaves does not work anyway:
I was actually thinking what if we relieve the rename restriction just
for the failover slave? What the impact would be? I think users don't
care about slave being renamed when it's in use, especially the initial
rename. Thoughts?
> would it work if we just
> hard-coded slave names instead?
>
> E.g.
> 1. fail slave renames
> 2. rename of failover to XX automatically renames standby to XXnsby
> and primary to XXnpry
That wouldn't help. The time when the failover master gets renamed, the
VF may not be present. I don't like the idea to delay exposing failover
master until VF is hot plugged in (probably subject to various failures)
later.
Thanks,
-Siwei
>
>
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the rdma tree
From: Stephen Rothwell @ 2019-02-27 0:25 UTC (permalink / raw)
To: David Miller, Networking, Doug Ledford, Jason Gunthorpe
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Shamir Rabinovitch, Jakub Kicinski
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/infiniband/hw/mlx4/Kconfig
between commit:
6fa8f1afd337 ("IB/{core,uverbs}: Move ib_umem_xxx functions from ib_core to ib_uverbs")
from the rdma tree and commit:
f4b6bcc7002f ("net: devlink: turn devlink into a built-in")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/hw/mlx4/Kconfig
index db4aa13ebae0,4e9936731867..000000000000
--- a/drivers/infiniband/hw/mlx4/Kconfig
+++ b/drivers/infiniband/hw/mlx4/Kconfig
@@@ -1,7 -1,7 +1,6 @@@
config MLX4_INFINIBAND
tristate "Mellanox ConnectX HCA support"
depends on NETDEVICES && ETHERNET && PCI && INET
- depends on MAY_USE_DEVLINK
- depends on INFINIBAND_USER_ACCESS || !INFINIBAND_USER_ACCESS
select NET_VENDOR_MELLANOX
select MLX4_CORE
---help---
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: BUG: please report to dccp@vger.kernel.org => prev = 10, last = 10 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_h
From: Eric Biggers @ 2019-02-27 0:42 UTC (permalink / raw)
To: syzbot; +Cc: davem, dccp, gerrit, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <0000000000007664bf057d71f6d7@google.com>
On Thu, Dec 20, 2018 at 02:55:03AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 6531e115b7ab Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13b0bd5d400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
> dashboard link: https://syzkaller.appspot.com/bug?extid=3c8a843d9de82272915b
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3c8a843d9de82272915b@syzkaller.appspotmail.com
>
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> BUG: please report to dccp@vger.kernel.org => prev = 10, last = 10 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 4.20.0-rc6+ #374
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x244/0x39d lib/dump_stack.c:113
> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> net/dccp/ccids/lib/packet_history.c:422
> ccid3_hc_rx_packet_recv+0x5c4/0xeb0 net/dccp/ccids/ccid3.c:767
> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:656
> sk_backlog_rcv include/net/sock.h:932 [inline]
> __sk_receive_skb+0x3e5/0xec0 net/core/sock.c:473
> dccp_v4_rcv+0x10f9/0x1f58 net/dccp/ipv4.c:877
> ip_local_deliver_finish+0x2e9/0xda0 net/ipv4/ip_input.c:215
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256
> dst_input include/net/dst.h:450 [inline]
> ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_rcv+0xed/0x600 net/ipv4/ip_input.c:524
> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4946
> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5056
> process_backlog+0x24e/0x7a0 net/core/dev.c:5864
> napi_poll net/core/dev.c:6287 [inline]
> net_rx_action+0x7fa/0x19b0 net/core/dev.c:6353
> __do_softirq+0x308/0xb7e kernel/softirq.c:292
> run_ksoftirqd+0x5e/0x100 kernel/softirq.c:654
> smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
> kthread+0x35a/0x440 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPVS: ftp: loaded support on port[0] = 21
> dccp_close: ABORT with 36864 bytes unread
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPVS: ftp: loaded support on port[0] = 21
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPVS: ftp: loaded support on port[0] = 21
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> IPVS: ftp: loaded support on port[0] = 21
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPVS: ftp: loaded support on port[0] = 21
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> IPVS: ftp: loaded support on port[0] = 21
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPVS: ftp: loaded support on port[0] = 21
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> IPVS: ftp: loaded support on port[0] = 21
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPVS: ftp: loaded support on port[0] = 21
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPVS: ftp: loaded support on port[0] = 21
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> bond0: enslaved VLAN challenged slave lo. Adding VLANs will be blocked as
> long as lo is part of bond bond0
> bond0: lo is up - this may be due to an out of date ifenslave
> A link change request failed with some changes committed already. Interface
> lo may have been left with an inconsistent configuration, please check.
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000007664bf057d71f6d7%40google.com.
> For more options, visit https://groups.google.com/d/optout.
#syz dup: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
Still occurring, see existing thread with reproducer here:
https://groups.google.com/d/msg/syzkaller-bugs/u5nq3PdPkIc/M7tbibYVCQAJ
- Eric
^ permalink raw reply
* Re: BUG: please report to dccp@vger.kernel.org => prev = 2, last = 2 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his
From: Eric Biggers @ 2019-02-27 0:42 UTC (permalink / raw)
To: syzbot; +Cc: davem, dccp, garsilva, gerrit, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <0000000000006dc2420578e29de3@google.com>
On Tue, Oct 23, 2018 at 03:13:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: ca9eb48fe01f Merge tag 'regulator-v5.0' of git://git.kerne..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1482a939400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=963b24abf3f7c2d8
> dashboard link: https://syzkaller.appspot.com/bug?extid=e786ba000564d103a6fe
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e786ba000564d103a6fe@syzkaller.appspotmail.com
>
> input: syz0 as /devices/virtual/input/input6
> BUG: please report to dccp@vger.kernel.org => prev = 2, last = 2 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.19.0+ #298
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c4/0x2b6 lib/dump_stack.c:113
> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> net/dccp/ccids/lib/packet_history.c:422
> ccid3_hc_rx_packet_recv+0x5c4/0xeb0 net/dccp/ccids/ccid3.c:767
> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:656
> sk_backlog_rcv include/net/sock.h:931 [inline]
> __sk_receive_skb+0x3e5/0xec0 net/core/sock.c:473
> dccp_v4_rcv+0x10f9/0x1f58 net/dccp/ipv4.c:877
> ip_local_deliver_finish+0x2e9/0xda0 net/ipv4/ip_input.c:215
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256
> dst_input include/net/dst.h:450 [inline]
> ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_rcv+0xed/0x600 net/ipv4/ip_input.c:524
> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
> process_backlog+0x218/0x6f0 net/core/dev.c:5829
> napi_poll net/core/dev.c:6249 [inline]
> net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
> __do_softirq+0x30c/0xb03 kernel/softirq.c:292
> run_ksoftirqd+0x94/0x100 kernel/softirq.c:653
> smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
> kthread+0x35a/0x420 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
> net_ratelimit: 18 callbacks suppressed
> dccp_close: ABORT with 105978 bytes unread
> input: syz0 as /devices/virtual/input/input7
> input: syz0 as /devices/virtual/input/input8
> dccp_close: ABORT with 52730 bytes unread
> input: syz0 as /devices/virtual/input/input9
> dccp_close: ABORT with 105978 bytes unread
> dccp_close: ABORT with 105978 bytes unread
> dccp_close: ABORT with 77306 bytes unread
> dccp_close: ABORT with 89594 bytes unread
> input: syz0 as /devices/virtual/input/input10
> input: syz0 as /devices/virtual/input/input11
> input: syz0 as /devices/virtual/input/input12
> input: syz0 as /devices/virtual/input/input13
> input: syz0 as /devices/virtual/input/input14
> input: syz0 as /devices/virtual/input/input15
> input: syz0 as /devices/virtual/input/input16
> input: syz0 as /devices/virtual/input/input17
> input: syz0 as /devices/virtual/input/input18
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
#syz dup: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
Still occurring, see existing thread with reproducer here:
https://groups.google.com/d/msg/syzkaller-bugs/u5nq3PdPkIc/M7tbibYVCQAJ
- Eric
^ permalink raw reply
* Re: BUG: please report to dccp@vger.kernel.org => prev = 5, last = 5 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his
From: Eric Biggers @ 2019-02-27 0:44 UTC (permalink / raw)
To: syzbot; +Cc: davem, dccp, garsilva, gerrit, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <000000000000627205057803724d@google.com>
On Fri, Oct 12, 2018 at 12:58:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 771b65e89c8a Add linux-next specific files for 20181011
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=167d2376400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=45f1c06c4da0a925
> dashboard link: https://syzkaller.appspot.com/bug?extid=e326127852f785c44347
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e326127852f785c44347@syzkaller.appspotmail.com
>
> BUG: please report to dccp@vger.kernel.org => prev = 5, last = 5 at
> net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()
> CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 4.19.0-rc7-next-20181011+ #92
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x244/0x3ab lib/dump_stack.c:113
> tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c
> net/dccp/ccids/lib/packet_history.c:422
> ccid3_hc_rx_packet_recv+0x5c4/0xeb0 net/dccp/ccids/ccid3.c:767
> ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
> dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
> dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
> dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:656
> sk_backlog_rcv include/net/sock.h:932 [inline]
> __sk_receive_skb+0x3e0/0xeb0 net/core/sock.c:473
> binder: send failed reply for transaction 41 to 27388:27389
> dccp_v4_rcv+0x10f9/0x1f58 net/dccp/ipv4.c:877
> ip_local_deliver_finish+0x2e9/0xda0 net/ipv4/ip_input.c:215
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_local_deliver+0x1e4/0x740 net/ipv4/ip_input.c:256
> dst_input include/net/dst.h:450 [inline]
> ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip_rcv+0xe8/0x600 net/ipv4/ip_input.c:524
> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4908
> __netif_receive_skb+0x27/0x1e0 net/core/dev.c:5018
> process_backlog+0x24e/0x7a0 net/core/dev.c:5822
> napi_poll net/core/dev.c:6242 [inline]
> net_rx_action+0x7fa/0x19b0 net/core/dev.c:6308
> __do_softirq+0x30d/0xb26 kernel/softirq.c:292
> run_ksoftirqd+0x5e/0x100 kernel/softirq.c:654
> smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
> kthread+0x35a/0x440 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
> dccp_close: ABORT with 52224 bytes unread
> binder: send failed reply for transaction 43 to 27399:27404
> dccp_close: ABORT with 3584 bytes unread
> binder: send failed reply for transaction 45 to 27417:27418
> binder: send failed reply for transaction 47 to 27424:27425
> dccp_close: ABORT with 105984 bytes unread
> dccp_close: ABORT with 105984 bytes unread
> dccp_close: ABORT with 105984 bytes unread
> nf_conntrack: default automatic helper assignment has been turned off for
> security reasons and CT-based firewall rule not found. Use the iptables CT
> target to attach helpers instead.
> Dead loop on virtual device ip6_vti0, fix it urgently!
> Dead loop on virtual device ip6_vti0, fix it urgently!
> Dead loop on virtual device ip6_vti0, fix it urgently!
> Dead loop on virtual device ip6_vti0, fix it urgently!
> Dead loop on virtual device ip6_vti0, fix it urgently!
> Dead loop on virtual device ip6_vti0, fix it urgently!
> IPVS: sync thread started: state = BACKUP, mcast_ifn = team_slave_0, syncid
> = 0, id = 0
> Dead loop on virtual device ip6_vti0, fix it urgently!
> IPVS: sync thread started: state = BACKUP, mcast_ifn = team_slave_0, syncid
> = 0, id = 0
> IPVS: ftp: loaded support on port[0] = 21
> : renamed from bpq0
> IPVS: ftp: loaded support on port[0] = 21
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
#syz dup: BUG: please report to dccp@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_hist_sample_rtt()
Still occurring, see existing thread with reproducer here:
https://groups.google.com/d/msg/syzkaller-bugs/u5nq3PdPkIc/M7tbibYVCQAJ
- Eric
^ permalink raw reply
* Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)
From: si-wei liu @ 2019-02-27 0:49 UTC (permalink / raw)
To: Michael S. Tsirkin, Stephen Hemminger
Cc: Samudrala, Sridhar, Siwei Liu, Jiri Pirko, David Miller, Netdev,
virtualization, virtio-dev, Brandeburg, Jesse, Alexander Duyck,
Jakub Kicinski, Jason Wang, liran.alon
In-Reply-To: <20190225210428-mutt-send-email-mst@kernel.org>
On 2/25/2019 6:05 PM, Michael S. Tsirkin wrote:
> On Mon, Feb 25, 2019 at 05:39:12PM -0800, Stephen Hemminger wrote:
>>>>>> Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
>>>>>> about moving them to a hidden network namespace so that they are not visible from the default namespace.
>>>>>> I looked into this sometime back, but did not find the right kernel api to create a network namespace within
>>>>>> kernel. If so, we could use this mechanism to simulate a 1-netdev model.
>>>>> Yes, that's one possible implementation (IMHO the key is to make 1-netdev
>>>>> model as much transparent to a real NIC as possible, while a hidden netns is
>>>>> just the vehicle). However, I recall there was resistance around this
>>>>> discussion that even the concept of hiding itself is a taboo for Linux
>>>>> netdev. I would like to summon potential alternatives before concluding
>>>>> 1-netdev is the only solution too soon.
>>>>>
>>>>> Thanks,
>>>>> -Siwei
>>>> Your scripts would not work at all then, right?
>>> At this point we don't claim images with such usage as SR-IOV live
>>> migrate-able. We would flag it as live migrate-able until this ethtool
>>> config issue is fully addressed and a transparent live migration
>>> solution emerges in upstream eventually.
>> The hyper-v netvsc with 1-dev model uses a timeout to allow udev to do its rename.
>> I proposed a patch to key state change off of the udev rename, but that patch was
>> rejected.
> Of course that would mean nothing works without udev - was
> that the objection? Could you help me find that discussion pls?
Yeah, the kernel should work with and without udev rename - typically
the kernel is agnostic of upcoming rename. User may opt out for kernel
provided names (particularly on older distros) then no rename would ever
happen.
I ever thought about this approach but didn't think it would fit. But,
what is the historical reason that prevents slave from being renamed
after being opened? Could we specialize a code path for this kernel
created device, as net_failover shouldn't carry over any history burden?
Thanks,
-Siwei
^ permalink raw reply
* Re: [PATCH] bpf: decrease usercnt if bpf_map_new_fd() fails in bpf_map_get_fd_by_id()
From: zerons @ 2019-02-27 0:49 UTC (permalink / raw)
To: Daniel Borkmann, ast; +Cc: netdev, linux-kernel
In-Reply-To: <ba6710b8-a2c9-3557-3a03-14b74ccde5b8@iogearbox.net>
On 2/27/19 00:24, Daniel Borkmann wrote:
> On 02/26/2019 03:58 PM, zerons wrote:
>> On 2/26/19 22:44, Daniel Borkmann wrote:
>>> On 02/26/2019 03:15 PM, zerons wrote:
>>>> [ Upstream commit c91951f15978f1a0c6b65f063d30f7ea7bc6fb42 ]
>>>
>>> Thanks for the fix! What do you mean by "upstream commit" above in this context?
>>
>> This patch is based on that commit, I thought I should mention this.
>> Sorry for the confusion.
>
> Ah, no. Usually that line is placed into stable commits that are
> cherry-picked to point to the original commit sha in the mainline
> tree. In any case, I didn't find c91951f15978, hence my question.
That is v4.20.12.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.20.12&id=c91951f15978f1a0c6b65f063d30f7ea7bc6fb42
> Anyway, for normal patch submissions in future, please don't add
> it into the log, we'll remove it this time.
>
Thanks for reminding me. I won't do that again.
^ permalink raw reply
* Re: general protection fault in finish_wait
From: Eric Biggers @ 2019-02-27 0:55 UTC (permalink / raw)
To: syzbot; +Cc: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
In-Reply-To: <0000000000009276d205708f9910@google.com>
On Mon, Jul 09, 2018 at 04:49:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 6508b6781be0 tcp: cleanup copied_seq and urg_data in tcp_d..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1256e6dc400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=2ca6c7a31d407f86
> dashboard link: https://syzkaller.appspot.com/bug?extid=3aac4a52d8e8ca0414d5
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1310fafc400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10af4f48400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3aac4a52d8e8ca0414d5@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> CPU: 1 PID: 19 Comm: kworker/1:0 Not tainted 4.18.0-rc3+ #4
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events smc_tcp_listen_work
> RIP: 0010:__lock_acquire+0x245/0x5020 kernel/locking/lockdep.c:3314
> Code: 28 00 00 00 0f 85 03 34 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f
> 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85
> c6 35 00 00 49 81 7d 00 60 76 e7 89 0f 84 42 ff
> RSP: 0000:ffff8801d9b36d20 EFLAGS: 00010006
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffffffff88f1b060
> RBP: ffff8801d9b370a8 R08: 0000000000000001 R09: 0000000000000001
> R10: ffff8801d9b2a500 R11: 0000000000000001 R12: 0000000000000001
> R13: 0000000000000018 R14: ffff8801d9b2a500 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020002cc0 CR3: 00000001ae03f000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
> finish_wait+0x119/0x430 kernel/sched/wait.c:364
> inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:418 [inline]
> inet_csk_accept+0x6d0/0xe70 net/ipv4/inet_connection_sock.c:451
> inet_accept+0x138/0x9f0 net/ipv4/af_inet.c:734
> kernel_accept+0x136/0x310 net/socket.c:3251
> smc_clcsock_accept net/smc/af_smc.c:701 [inline]
> smc_tcp_listen_work+0x222/0xef0 net/smc/af_smc.c:1114
> process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
> worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
> kthread+0x345/0x410 kernel/kthread.c:240
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
> Modules linked in:
> Dumping ftrace buffer:
> (ftrace buffer empty)
> ---[ end trace 472b359041f047a6 ]---
> RIP: 0010:__lock_acquire+0x245/0x5020 kernel/locking/lockdep.c:3314
> Code: 28 00 00 00 0f 85 03 34 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f
> 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85
> c6 35 00 00 49 81 7d 00 60 76 e7 89 0f 84 42 ff
> RSP: 0000:ffff8801d9b36d20 EFLAGS: 00010006
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffffffff88f1b060
> RBP: ffff8801d9b370a8 R08: 0000000000000001 R09: 0000000000000001
> R10: ffff8801d9b2a500 R11: 0000000000000001 R12: 0000000000000001
> R13: 0000000000000018 R14: ffff8801d9b2a500 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020002cc0 CR3: 00000001ae03f000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000009276d205708f9910%40google.com.
> For more options, visit https://groups.google.com/d/optout.
This was fixed by:
commit 78abe3d0dfad196959b1246003366e2610775ea6 (refs/bisect/new)
Author: Myungho Jung <mhjungk@gmail.com>
Date: Tue Dec 18 09:02:25 2018 -0800
net/smc: fix TCP fallback socket release
#syz fix: net/smc: fix TCP fallback socket release
There are newer crashes with this same signature, e.g.
https://syzkaller.appspot.com/text?tag=CrashReport&x=16cb391f400000
but they are something different...
- Eric
^ permalink raw reply
* Re: [BUG] net/sched : qlen can not really be per cpu ?
From: Eric Dumazet @ 2019-02-27 0:56 UTC (permalink / raw)
To: Cong Wang; +Cc: John Fastabend, Networking, Jamal Hadi Salim, Jiri Pirko
In-Reply-To: <CAM_iQpVuaP9kVyvM-s2MFw+cz1tZpp0ehipo7Gm-W8+=UzxuvQ@mail.gmail.com>
On 02/26/2019 03:51 PM, Cong Wang wrote:
> On Tue, Feb 26, 2019 at 3:19 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>
>>
>> On 02/25/2019 10:42 PM, Eric Dumazet wrote:
>>> HTB + pfifo_fast as a leaf qdisc hits badly the following warning in htb_activate() :
>>>
>>> WARN_ON(cl->level || !cl->leaf.q || !cl->leaf.q->q.qlen);
>>>
>>> This is because pfifo_fast does not update sch->q.qlen, but per cpu counters.
>>> So cl->leaf.q->q.qlen is zero.
>>>
>>> HFSC, CBQ, DRR, QFQ have the same problem.
>>>
>>> Any ideas how we can fix this ?
>>
>> What about something simple for stable ?
>> ( I yet have to boot/test this )
>
> Is merely updating qlen sufficient for fixing it?
>
> I thought it is because of the lack of qdisc_tree_reduce_backlog()
> in pfifo_fast.
It does not seem to be the qdisc_tree_reduce_backlog() thing.
HTB, HFSC, CBQ, DRR, QFQ only peek at their children 'qlen' to decide if there
is at least one packet in them.
The backlog is only reported for dumps, but the actual backlog value is not used in data path.
^ permalink raw reply
* [PATCH net-next] net: sched: pie: fix 64-bit division
From: Leslie Monis @ 2019-02-27 1:00 UTC (permalink / raw)
To: davem; +Cc: netdev, Leslie Monis
Use div_u64() to resolve build failures on 32-bit platforms.
Fixes: 3f7ae5f3dc52 ("net: sched: pie: add more cases to auto-tune alpha and beta")
Signed-off-by: Leslie Monis <lesliemonis@gmail.com>
---
net/sched/sch_pie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c
index 4c0670b6aec1..f93cfe034c72 100644
--- a/net/sched/sch_pie.c
+++ b/net/sched/sch_pie.c
@@ -429,7 +429,7 @@ static void calculate_probability(struct Qdisc *sch)
*/
if (qdelay == 0 && qdelay_old == 0 && update_prob)
- q->vars.prob = (q->vars.prob * 98) / 100;
+ q->vars.prob = 98 * div_u64(q->vars.prob, 100);
q->vars.qdelay = qdelay;
q->vars.qlen_old = qlen;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 1/2] vxlan: add extack support for create and changelink
From: Roopa Prabhu @ 2019-02-27 1:05 UTC (permalink / raw)
To: Petr Machata
Cc: davem@davemloft.net, netdev@vger.kernel.org,
dsa@cumulusnetworks.com, sd@queasysnail.net,
johannes@sipsolutions.net
In-Reply-To: <87h8cqfnq8.fsf@mellanox.com>
On Tue, Feb 26, 2019 at 9:45 AM Petr Machata <petrm@mellanox.com> wrote:
>
>
> Roopa Prabhu <roopa@cumulusnetworks.com> writes:
>
> > On Tue, Feb 26, 2019 at 5:51 AM Petr Machata <petrm@mellanox.com> wrote:
> >>
> >> Many of the flags for which you call this don't actually have the else
> >> branch. However I suspect there are no good reasons not to allow
> >> resetting a flag.
> >>
> >> Reviewed-by: Petr Machata <petrm@mellanox.com>
> >
> > yes, correct, that was intentional.
> > also, I am not sure what is the best way to support reseting of a NLA_FLAG.
> > Absence of the flag attribute in the request cannot be the reason for
> > resetting or clearing the flag.
>
> Yeah, I was thinking about that. It looks like this would need a new set
> of u8 attributes :-(
yes, and thats unfortunate. We should keep an eye on future NLA_FLAG
attributes during review .
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the net-next tree
From: tanhuazhong @ 2019-02-27 1:12 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jian Shen,
Peng Li
In-Reply-To: <20190225190034.0cad4e3d@canb.auug.org.au>
Hi Stephen & David,
It is my mistake, so sorry about this. There is a redundant "net: hns3:
" in the fixes tag.
How could I fix it?
Thanks.
On 2019/2/25 16:00, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> a638b1d8cc87 ("net: hns3: fix get VF RSS issue")
>
> Fixes tag
>
> Fixes: 374ad291762a ("net: hns3: net: hns3: Add RSS general configuration support for VF")
>
> has these problem(s):
>
> - Subject does not match target commit subject
> Just use
> git log -1 --format='Fixes: %h (%s)'
>
^ permalink raw reply
* [PATCH net-next v2 0/8] net: Remove switchdev_ops
From: Florian Fainelli @ 2019-02-27 1:14 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
Hi all,
This patch series completes the removal of the switchdev_ops by
converting switchdev_port_attr_set() to use either the blocking
(process) or non-blocking (atomic) notifier since we typically need to
deal with both depending on where in the bridge code we get called from.
This was tested with the forwarding selftests and DSA hardware.
Ido, hopefully this captures your comments done on v1, if not, can you
illustrate with some pseudo-code what you had in mind if that's okay?
Changes in v2:
- do not check for SWITCHDEV_F_DEFER when calling the blocking notifier
and instead directly call the atomic notifier from the single location
where this is required
Florian Fainelli (8):
switchdev: Add SWITCHDEV_PORT_ATTR_SET
rocker: Handle SWITCHDEV_PORT_ATTR_SET
net: dsa: Handle SWITCHDEV_PORT_ATTR_SET
mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_ATTR_SET
net: mscc: ocelot: Handle SWITCHDEV_PORT_ATTR_SET
staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_ATTR_SET
net: switchdev: Replace port attr set SDO with a notification
net: Remove switchdev_ops
.../net/ethernet/mellanox/mlxsw/spectrum.c | 12 --
.../net/ethernet/mellanox/mlxsw/spectrum.h | 2 -
.../mellanox/mlxsw/spectrum_switchdev.c | 24 ++--
drivers/net/ethernet/mscc/ocelot.c | 32 +++++-
drivers/net/ethernet/mscc/ocelot.h | 1 +
drivers/net/ethernet/mscc/ocelot_board.c | 2 +
drivers/net/ethernet/rocker/rocker_main.c | 23 +++-
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 24 +++-
include/linux/netdevice.h | 3 -
include/net/switchdev.h | 38 ++++---
net/bridge/br_switchdev.c | 7 +-
net/dsa/slave.c | 23 +++-
net/switchdev/switchdev.c | 104 +++++++++++++-----
13 files changed, 203 insertions(+), 92 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next v2 1/8] switchdev: Add SWITCHDEV_PORT_ATTR_SET
From: Florian Fainelli @ 2019-02-27 1:14 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190227011427.16487-1-f.fainelli@gmail.com>
In preparation for allowing switchdev enabled drivers to veto specific
attribute settings from within the context of the caller, introduce a
new switchdev notifier type for port attributes.
Suggested-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
include/net/switchdev.h | 27 +++++++++++++++++++++
net/switchdev/switchdev.c | 51 +++++++++++++++++++++++++++++++++++++++
2 files changed, 78 insertions(+)
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index be4b13e66668..5087c06ceb4b 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -132,6 +132,7 @@ enum switchdev_notifier_type {
SWITCHDEV_PORT_OBJ_ADD, /* Blocking. */
SWITCHDEV_PORT_OBJ_DEL, /* Blocking. */
+ SWITCHDEV_PORT_ATTR_SET, /* May be blocking . */
SWITCHDEV_VXLAN_FDB_ADD_TO_BRIDGE,
SWITCHDEV_VXLAN_FDB_DEL_TO_BRIDGE,
@@ -160,6 +161,13 @@ struct switchdev_notifier_port_obj_info {
bool handled;
};
+struct switchdev_notifier_port_attr_info {
+ struct switchdev_notifier_info info; /* must be first */
+ const struct switchdev_attr *attr;
+ struct switchdev_trans *trans;
+ bool handled;
+};
+
static inline struct net_device *
switchdev_notifier_info_to_dev(const struct switchdev_notifier_info *info)
{
@@ -212,7 +220,15 @@ int switchdev_handle_port_obj_del(struct net_device *dev,
int (*del_cb)(struct net_device *dev,
const struct switchdev_obj *obj));
+int switchdev_handle_port_attr_set(struct net_device *dev,
+ struct switchdev_notifier_port_attr_info *port_attr_info,
+ bool (*check_cb)(const struct net_device *dev),
+ int (*set_cb)(struct net_device *dev,
+ const struct switchdev_attr *attr,
+ struct switchdev_trans *trans));
+
#define SWITCHDEV_SET_OPS(netdev, ops) ((netdev)->switchdev_ops = (ops))
+
#else
static inline void switchdev_deferred_process(void)
@@ -299,6 +315,17 @@ switchdev_handle_port_obj_del(struct net_device *dev,
return 0;
}
+static inline int
+switchdev_handle_port_attr_set(struct net_device *dev,
+ struct switchdev_notifier_port_attr_info *port_attr_info,
+ bool (*check_cb)(const struct net_device *dev),
+ int (*set_cb)(struct net_device *dev,
+ const struct switchdev_attr *attr,
+ struct switchdev_trans *trans))
+{
+ return 0;
+}
+
#define SWITCHDEV_SET_OPS(netdev, ops) do {} while (0)
#endif
diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index 362413c9b389..3560c19aa7e2 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -655,3 +655,54 @@ int switchdev_handle_port_obj_del(struct net_device *dev,
return err;
}
EXPORT_SYMBOL_GPL(switchdev_handle_port_obj_del);
+
+static int __switchdev_handle_port_attr_set(struct net_device *dev,
+ struct switchdev_notifier_port_attr_info *port_attr_info,
+ bool (*check_cb)(const struct net_device *dev),
+ int (*set_cb)(struct net_device *dev,
+ const struct switchdev_attr *attr,
+ struct switchdev_trans *trans))
+{
+ struct net_device *lower_dev;
+ struct list_head *iter;
+ int err = -EOPNOTSUPP;
+
+ if (check_cb(dev)) {
+ port_attr_info->handled = true;
+ return set_cb(dev, port_attr_info->attr,
+ port_attr_info->trans);
+ }
+
+ /* Switch ports might be stacked under e.g. a LAG. Ignore the
+ * unsupported devices, another driver might be able to handle them. But
+ * propagate to the callers any hard errors.
+ *
+ * If the driver does its own bookkeeping of stacked ports, it's not
+ * necessary to go through this helper.
+ */
+ netdev_for_each_lower_dev(dev, lower_dev, iter) {
+ err = __switchdev_handle_port_attr_set(lower_dev, port_attr_info,
+ check_cb, set_cb);
+ if (err && err != -EOPNOTSUPP)
+ return err;
+ }
+
+ return err;
+}
+
+int switchdev_handle_port_attr_set(struct net_device *dev,
+ struct switchdev_notifier_port_attr_info *port_attr_info,
+ bool (*check_cb)(const struct net_device *dev),
+ int (*set_cb)(struct net_device *dev,
+ const struct switchdev_attr *attr,
+ struct switchdev_trans *trans))
+{
+ int err;
+
+ err = __switchdev_handle_port_attr_set(dev, port_attr_info, check_cb,
+ set_cb);
+ if (err == -EOPNOTSUPP)
+ err = 0;
+ return err;
+}
+EXPORT_SYMBOL_GPL(switchdev_handle_port_attr_set);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 2/8] rocker: Handle SWITCHDEV_PORT_ATTR_SET
From: Florian Fainelli @ 2019-02-27 1:14 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190227011427.16487-1-f.fainelli@gmail.com>
Following patches will change the way we communicate setting a port's
attribute and use notifiers towards that goal.
Prepare rocker to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET from both atomic and process context and use a
small helper to translate the event notifier into something that
rocker_port_attr_set() can process.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/rocker/rocker_main.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
index 309a6bf9130c..fc772cf079cc 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -2710,6 +2710,19 @@ static bool rocker_port_dev_check(const struct net_device *dev)
return dev->netdev_ops == &rocker_port_netdev_ops;
}
+static int
+rocker_switchdev_port_attr_set_event(struct net_device *netdev,
+ struct switchdev_notifier_port_attr_info *port_attr_info)
+{
+ int err;
+
+ err = rocker_port_attr_set(netdev, port_attr_info->attr,
+ port_attr_info->trans);
+
+ port_attr_info->handled = true;
+ return notifier_from_errno(err);
+}
+
struct rocker_switchdev_event_work {
struct work_struct work;
struct switchdev_notifier_fdb_info fdb_info;
@@ -2779,6 +2792,9 @@ static int rocker_switchdev_event(struct notifier_block *unused,
if (!rocker_port_dev_check(dev))
return NOTIFY_DONE;
+ if (event == SWITCHDEV_PORT_ATTR_SET)
+ return rocker_switchdev_port_attr_set_event(dev, ptr);
+
rocker_port = netdev_priv(dev);
switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC);
if (WARN_ON(!switchdev_work))
@@ -2841,6 +2857,8 @@ static int rocker_switchdev_blocking_event(struct notifier_block *unused,
case SWITCHDEV_PORT_OBJ_ADD:
case SWITCHDEV_PORT_OBJ_DEL:
return rocker_switchdev_port_obj_event(event, dev, ptr);
+ case SWITCHDEV_PORT_ATTR_SET:
+ return rocker_switchdev_port_attr_set_event(dev, ptr);
}
return NOTIFY_DONE;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 3/8] net: dsa: Handle SWITCHDEV_PORT_ATTR_SET
From: Florian Fainelli @ 2019-02-27 1:14 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190227011427.16487-1-f.fainelli@gmail.com>
Following patches will change the way we communicate setting a port's
attribute and use notifiers towards that goal.
Prepare DSA to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET from both atomic and process context and use a
small helper to translate the event notifier into something that
dsa_slave_port_attr_set() can process.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/dsa/slave.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 7274499293c9..b089b43120e1 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1524,6 +1524,19 @@ static int dsa_slave_netdevice_event(struct notifier_block *nb,
return NOTIFY_DONE;
}
+static int
+dsa_slave_switchdev_port_attr_set_event(struct net_device *netdev,
+ struct switchdev_notifier_port_attr_info *port_attr_info)
+{
+ int err;
+
+ err = dsa_slave_port_attr_set(netdev, port_attr_info->attr,
+ port_attr_info->trans);
+
+ port_attr_info->handled = true;
+ return notifier_from_errno(err);
+}
+
struct dsa_switchdev_event_work {
struct work_struct work;
struct switchdev_notifier_fdb_info fdb_info;
@@ -1602,6 +1615,9 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused,
if (!dsa_slave_dev_check(dev))
return NOTIFY_DONE;
+ if (event == SWITCHDEV_PORT_ATTR_SET)
+ return dsa_slave_switchdev_port_attr_set_event(dev, ptr);
+
switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC);
if (!switchdev_work)
return NOTIFY_BAD;
@@ -1664,6 +1680,8 @@ static int dsa_slave_switchdev_blocking_event(struct notifier_block *unused,
case SWITCHDEV_PORT_OBJ_ADD: /* fall through */
case SWITCHDEV_PORT_OBJ_DEL:
return dsa_slave_switchdev_port_obj_event(event, dev, ptr);
+ case SWITCHDEV_PORT_ATTR_SET:
+ return dsa_slave_switchdev_port_attr_set_event(dev, ptr);
}
return NOTIFY_DONE;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 4/8] mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_ATTR_SET
From: Florian Fainelli @ 2019-02-27 1:14 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190227011427.16487-1-f.fainelli@gmail.com>
Following patches will change the way we communicate setting a port's
attribute and use a notifier to perform those tasks.
Prepare mlxsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET and utilize the switchdev_handle_port_attr_set()
to handle stacking of devices.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 766f5b5f1cf5..c1aedfea3a31 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -3123,6 +3123,13 @@ static int mlxsw_sp_switchdev_event(struct notifier_block *unused,
struct net_device *br_dev;
int err;
+ if (event == SWITCHDEV_PORT_ATTR_SET) {
+ err = switchdev_handle_port_attr_set(dev, ptr,
+ mlxsw_sp_port_dev_check,
+ mlxsw_sp_port_attr_set);
+ return notifier_from_errno(err);
+ }
+
/* Tunnel devices are not our uppers, so check their master instead */
br_dev = netdev_master_upper_dev_get_rcu(dev);
if (!br_dev)
@@ -3446,6 +3453,11 @@ static int mlxsw_sp_switchdev_blocking_event(struct notifier_block *unused,
mlxsw_sp_port_dev_check,
mlxsw_sp_port_obj_del);
return notifier_from_errno(err);
+ case SWITCHDEV_PORT_ATTR_SET:
+ err = switchdev_handle_port_attr_set(dev, ptr,
+ mlxsw_sp_port_dev_check,
+ mlxsw_sp_port_attr_set);
+ return notifier_from_errno(err);
}
return NOTIFY_DONE;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 6/8] staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_ATTR_SET
From: Florian Fainelli @ 2019-02-27 1:14 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190227011427.16487-1-f.fainelli@gmail.com>
Following patches will change the way we communicate setting a port's
attribute and use a blocking notifier to perform those tasks.
Prepare ethsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET and simply translate that into the existing
swdev_port_attr_set() call.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index 018399ee8731..b0d2d9bf2532 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -929,6 +929,19 @@ static const struct switchdev_ops ethsw_port_switchdev_ops = {
.switchdev_port_attr_set = swdev_port_attr_set,
};
+static int
+ethsw_switchdev_port_attr_set_event(struct net_device *netdev,
+ struct switchdev_notifier_port_attr_info *port_attr_info)
+{
+ int err;
+
+ err = swdev_port_attr_set(netdev, port_attr_info->attr,
+ port_attr_info->trans);
+
+ port_attr_info->handled = true;
+ return notifier_from_errno(err);
+}
+
/* For the moment, only flood setting needs to be updated */
static int port_bridge_join(struct net_device *netdev,
struct net_device *upper_dev)
@@ -1047,6 +1060,12 @@ static int port_switchdev_event(struct notifier_block *unused,
struct ethsw_switchdev_event_work *switchdev_work;
struct switchdev_notifier_fdb_info *fdb_info = ptr;
+ if (!ethsw_port_dev_check(dev))
+ return NOTIFY_DONE;
+
+ if (event == SWITCHDEV_PORT_ATTR_SET)
+ return ethsw_switchdev_port_attr_set_event(dev, ptr);
+
switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC);
if (!switchdev_work)
return NOTIFY_BAD;
@@ -1115,6 +1134,8 @@ static int port_switchdev_blocking_event(struct notifier_block *unused,
case SWITCHDEV_PORT_OBJ_ADD: /* fall through */
case SWITCHDEV_PORT_OBJ_DEL:
return ethsw_switchdev_port_obj_event(event, dev, ptr);
+ case SWITCHDEV_PORT_ATTR_SET:
+ return ethsw_switchdev_port_attr_set_event(dev, ptr);
}
return NOTIFY_DONE;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 7/8] net: switchdev: Replace port attr set SDO with a notification
From: Florian Fainelli @ 2019-02-27 1:14 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190227011427.16487-1-f.fainelli@gmail.com>
Drop switchdev_ops.switchdev_port_attr_set. Drop the uses of this field
from all clients, which were migrated to use switchdev notification in
the previous patches.
Add a new function switchdev_port_attr_notify() that sends the switchdev
notifications SWITCHDEV_PORT_ATTR_SET and calls the blocking (process)
notifier chain.
We have one odd case within net/bridge/br_switchdev.c with the
SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attribute identifier that
requires executing from atomic context, we deal with that one
specifically.
Drop __switchdev_port_attr_set() and update switchdev_port_attr_set()
likewise.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/bridge/br_switchdev.c | 7 +++++-
net/switchdev/switchdev.c | 53 ++++++++++++++++++---------------------
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
index af57c4a2b78a..b7988d49d708 100644
--- a/net/bridge/br_switchdev.c
+++ b/net/bridge/br_switchdev.c
@@ -67,12 +67,17 @@ int br_switchdev_set_port_flag(struct net_bridge_port *p,
.id = SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS,
.u.brport_flags = mask,
};
+ struct switchdev_notifier_port_attr_info info = {
+ .attr = &attr,
+ };
int err;
if (mask & ~BR_PORT_FLAGS_HW_OFFLOAD)
return 0;
- err = switchdev_port_attr_set(p->dev, &attr);
+ /* We run from atomic context here */
+ err = call_switchdev_notifiers(SWITCHDEV_PORT_ATTR_SET, p->dev,
+ &info.info, NULL);
if (err == -EOPNOTSUPP)
return 0;
diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index 3560c19aa7e2..d81cfcee9ad9 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -174,39 +174,32 @@ static int switchdev_deferred_enqueue(struct net_device *dev,
return 0;
}
-static int __switchdev_port_attr_set(struct net_device *dev,
- const struct switchdev_attr *attr,
- struct switchdev_trans *trans)
+static int switchdev_port_attr_notify(enum switchdev_notifier_type nt,
+ struct net_device *dev,
+ const struct switchdev_attr *attr,
+ struct switchdev_trans *trans)
{
- const struct switchdev_ops *ops = dev->switchdev_ops;
- struct net_device *lower_dev;
- struct list_head *iter;
- int err = -EOPNOTSUPP;
-
- if (ops && ops->switchdev_port_attr_set) {
- err = ops->switchdev_port_attr_set(dev, attr, trans);
- goto done;
- }
-
- if (attr->flags & SWITCHDEV_F_NO_RECURSE)
- goto done;
+ int err;
+ int rc;
- /* Switch device port(s) may be stacked under
- * bond/team/vlan dev, so recurse down to set attr on
- * each port.
- */
+ struct switchdev_notifier_port_attr_info attr_info = {
+ .attr = attr,
+ .trans = trans,
+ .handled = false,
+ };
- netdev_for_each_lower_dev(dev, lower_dev, iter) {
- err = __switchdev_port_attr_set(lower_dev, attr, trans);
- if (err)
- break;
+ rc = call_switchdev_blocking_notifiers(nt, dev,
+ &attr_info.info, NULL);
+ err = notifier_to_errno(rc);
+ if (err) {
+ WARN_ON(!attr_info.handled);
+ return err;
}
-done:
- if (err == -EOPNOTSUPP && attr->flags & SWITCHDEV_F_SKIP_EOPNOTSUPP)
- err = 0;
+ if (!attr_info.handled)
+ return -EOPNOTSUPP;
- return err;
+ return 0;
}
static int switchdev_port_attr_set_now(struct net_device *dev,
@@ -225,7 +218,8 @@ static int switchdev_port_attr_set_now(struct net_device *dev,
*/
trans.ph_prepare = true;
- err = __switchdev_port_attr_set(dev, attr, &trans);
+ err = switchdev_port_attr_notify(SWITCHDEV_PORT_ATTR_SET, dev, attr,
+ &trans);
if (err) {
/* Prepare phase failed: abort the transaction. Any
* resources reserved in the prepare phase are
@@ -244,7 +238,8 @@ static int switchdev_port_attr_set_now(struct net_device *dev,
*/
trans.ph_prepare = false;
- err = __switchdev_port_attr_set(dev, attr, &trans);
+ err = switchdev_port_attr_notify(SWITCHDEV_PORT_ATTR_SET, dev, attr,
+ &trans);
WARN(err, "%s: Commit of attribute (id=%d) failed.\n",
dev->name, attr->id);
switchdev_trans_items_warn_destroy(dev, &trans);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 8/8] net: Remove switchdev_ops
From: Florian Fainelli @ 2019-02-27 1:14 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190227011427.16487-1-f.fainelli@gmail.com>
Now that we have converted all possible callers to using a switchdev
notifier for attributes we do not have a need for implementing
switchdev_ops anymore, and this can be removed from all drivers the
net_device structure.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 12 ------------
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 2 --
.../mellanox/mlxsw/spectrum_switchdev.c | 12 ------------
drivers/net/ethernet/mscc/ocelot.c | 5 -----
drivers/net/ethernet/rocker/rocker_main.c | 5 -----
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 5 -----
include/linux/netdevice.h | 3 ---
include/net/switchdev.h | 17 -----------------
net/dsa/slave.c | 5 -----
9 files changed, 66 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index b00f6f74f91a..995426ea9a43 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -3660,7 +3660,6 @@ static int mlxsw_sp_port_create(struct mlxsw_sp *mlxsw_sp, u8 local_port,
}
mlxsw_sp_port->default_vlan = mlxsw_sp_port_vlan;
- mlxsw_sp_port_switchdev_init(mlxsw_sp_port);
mlxsw_sp->ports[local_port] = mlxsw_sp_port;
err = register_netdev(dev);
if (err) {
@@ -3677,7 +3676,6 @@ static int mlxsw_sp_port_create(struct mlxsw_sp *mlxsw_sp, u8 local_port,
err_register_netdev:
mlxsw_sp->ports[local_port] = NULL;
- mlxsw_sp_port_switchdev_fini(mlxsw_sp_port);
mlxsw_sp_port_vlan_destroy(mlxsw_sp_port_vlan);
err_port_vlan_create:
err_port_pvid_set:
@@ -3720,7 +3718,6 @@ static void mlxsw_sp_port_remove(struct mlxsw_sp *mlxsw_sp, u8 local_port)
mlxsw_core_port_clear(mlxsw_sp->core, local_port, mlxsw_sp);
unregister_netdev(mlxsw_sp_port->dev); /* This calls ndo_stop */
mlxsw_sp->ports[local_port] = NULL;
- mlxsw_sp_port_switchdev_fini(mlxsw_sp_port);
mlxsw_sp_port_vlan_flush(mlxsw_sp_port, true);
mlxsw_sp_port_nve_fini(mlxsw_sp_port);
mlxsw_sp_tc_qdisc_fini(mlxsw_sp_port);
@@ -4441,12 +4438,6 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
goto err_span_init;
}
- err = mlxsw_sp_switchdev_init(mlxsw_sp);
- if (err) {
- dev_err(mlxsw_sp->bus_info->dev, "Failed to initialize switchdev\n");
- goto err_switchdev_init;
- }
-
err = mlxsw_sp_counter_pool_init(mlxsw_sp);
if (err) {
dev_err(mlxsw_sp->bus_info->dev, "Failed to init counter pool\n");
@@ -4517,8 +4508,6 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
err_afa_init:
mlxsw_sp_counter_pool_fini(mlxsw_sp);
err_counter_pool_init:
- mlxsw_sp_switchdev_fini(mlxsw_sp);
-err_switchdev_init:
mlxsw_sp_span_fini(mlxsw_sp);
err_span_init:
mlxsw_sp_lag_fini(mlxsw_sp);
@@ -4585,7 +4574,6 @@ static void mlxsw_sp_fini(struct mlxsw_core *mlxsw_core)
mlxsw_sp_nve_fini(mlxsw_sp);
mlxsw_sp_afa_fini(mlxsw_sp);
mlxsw_sp_counter_pool_fini(mlxsw_sp);
- mlxsw_sp_switchdev_fini(mlxsw_sp);
mlxsw_sp_span_fini(mlxsw_sp);
mlxsw_sp_lag_fini(mlxsw_sp);
mlxsw_sp_buffers_fini(mlxsw_sp);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
index a61c1130d9e3..da6278b0caa4 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -407,8 +407,6 @@ extern const struct mlxsw_sp_sb_vals mlxsw_sp2_sb_vals;
/* spectrum_switchdev.c */
int mlxsw_sp_switchdev_init(struct mlxsw_sp *mlxsw_sp);
void mlxsw_sp_switchdev_fini(struct mlxsw_sp *mlxsw_sp);
-void mlxsw_sp_port_switchdev_init(struct mlxsw_sp_port *mlxsw_sp_port);
-void mlxsw_sp_port_switchdev_fini(struct mlxsw_sp_port *mlxsw_sp_port);
int mlxsw_sp_rif_fdb_op(struct mlxsw_sp *mlxsw_sp, const char *mac, u16 fid,
bool adding);
void
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index c1aedfea3a31..f6ce386c3036 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -1938,10 +1938,6 @@ static struct mlxsw_sp_port *mlxsw_sp_lag_rep_port(struct mlxsw_sp *mlxsw_sp,
return NULL;
}
-static const struct switchdev_ops mlxsw_sp_port_switchdev_ops = {
- .switchdev_port_attr_set = mlxsw_sp_port_attr_set,
-};
-
static int
mlxsw_sp_bridge_8021q_port_join(struct mlxsw_sp_bridge_device *bridge_device,
struct mlxsw_sp_bridge_port *bridge_port,
@@ -3545,11 +3541,3 @@ void mlxsw_sp_switchdev_fini(struct mlxsw_sp *mlxsw_sp)
kfree(mlxsw_sp->bridge);
}
-void mlxsw_sp_port_switchdev_init(struct mlxsw_sp_port *mlxsw_sp_port)
-{
- mlxsw_sp_port->dev->switchdev_ops = &mlxsw_sp_port_switchdev_ops;
-}
-
-void mlxsw_sp_port_switchdev_fini(struct mlxsw_sp_port *mlxsw_sp_port)
-{
-}
diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
index 83a678b11757..a1d0d6e42533 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -1324,10 +1324,6 @@ static int ocelot_port_obj_del(struct net_device *dev,
return ret;
}
-static const struct switchdev_ops ocelot_port_switchdev_ops = {
- .switchdev_port_attr_set = ocelot_port_attr_set,
-};
-
static int ocelot_port_bridge_join(struct ocelot_port *ocelot_port,
struct net_device *bridge)
{
@@ -1660,7 +1656,6 @@ int ocelot_probe_port(struct ocelot *ocelot, u8 port,
dev->netdev_ops = &ocelot_port_netdev_ops;
dev->ethtool_ops = &ocelot_ethtool_ops;
- dev->switchdev_ops = &ocelot_port_switchdev_ops;
dev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_RXFCS;
dev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
index fc772cf079cc..c883aa89b7ca 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -2142,10 +2142,6 @@ static int rocker_port_obj_del(struct net_device *dev,
return err;
}
-static const struct switchdev_ops rocker_port_switchdev_ops = {
- .switchdev_port_attr_set = rocker_port_attr_set,
-};
-
struct rocker_fib_event_work {
struct work_struct work;
union {
@@ -2599,7 +2595,6 @@ static int rocker_probe_port(struct rocker *rocker, unsigned int port_number)
rocker_port_dev_addr_init(rocker_port);
dev->netdev_ops = &rocker_port_netdev_ops;
dev->ethtool_ops = &rocker_port_ethtool_ops;
- dev->switchdev_ops = &rocker_port_switchdev_ops;
netif_tx_napi_add(dev, &rocker_port->napi_tx, rocker_port_poll_tx,
NAPI_POLL_WEIGHT);
netif_napi_add(dev, &rocker_port->napi_rx, rocker_port_poll_rx,
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index b0d2d9bf2532..ad577beeb052 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -925,10 +925,6 @@ static int swdev_port_obj_del(struct net_device *netdev,
return err;
}
-static const struct switchdev_ops ethsw_port_switchdev_ops = {
- .switchdev_port_attr_set = swdev_port_attr_set,
-};
-
static int
ethsw_switchdev_port_attr_set_event(struct net_device *netdev,
struct switchdev_notifier_port_attr_info *port_attr_info)
@@ -1455,7 +1451,6 @@ static int ethsw_probe_port(struct ethsw_core *ethsw, u16 port_idx)
SET_NETDEV_DEV(port_netdev, dev);
port_netdev->netdev_ops = ðsw_port_ops;
port_netdev->ethtool_ops = ðsw_port_ethtool_ops;
- port_netdev->switchdev_ops = ðsw_port_switchdev_ops;
/* Set MTU limits */
port_netdev->min_mtu = ETH_MIN_MTU;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 58e83bd7a861..c10b60297d28 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1843,9 +1843,6 @@ struct net_device {
#endif
const struct net_device_ops *netdev_ops;
const struct ethtool_ops *ethtool_ops;
-#ifdef CONFIG_NET_SWITCHDEV
- const struct switchdev_ops *switchdev_ops;
-#endif
#ifdef CONFIG_NET_L3_MASTER_DEV
const struct l3mdev_ops *l3mdev_ops;
#endif
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index 5087c06ceb4b..e4f751e19ecf 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -112,17 +112,6 @@ void *switchdev_trans_item_dequeue(struct switchdev_trans *trans);
typedef int switchdev_obj_dump_cb_t(struct switchdev_obj *obj);
-/**
- * struct switchdev_ops - switchdev operations
- *
- * @switchdev_port_attr_set: Set a port attribute (see switchdev_attr).
- */
-struct switchdev_ops {
- int (*switchdev_port_attr_set)(struct net_device *dev,
- const struct switchdev_attr *attr,
- struct switchdev_trans *trans);
-};
-
enum switchdev_notifier_type {
SWITCHDEV_FDB_ADD_TO_BRIDGE = 1,
SWITCHDEV_FDB_DEL_TO_BRIDGE,
@@ -226,9 +215,6 @@ int switchdev_handle_port_attr_set(struct net_device *dev,
int (*set_cb)(struct net_device *dev,
const struct switchdev_attr *attr,
struct switchdev_trans *trans));
-
-#define SWITCHDEV_SET_OPS(netdev, ops) ((netdev)->switchdev_ops = (ops))
-
#else
static inline void switchdev_deferred_process(void)
@@ -325,9 +311,6 @@ switchdev_handle_port_attr_set(struct net_device *dev,
{
return 0;
}
-
-#define SWITCHDEV_SET_OPS(netdev, ops) do {} while (0)
-
#endif
#endif /* _LINUX_SWITCHDEV_H_ */
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index b089b43120e1..1808a2cd6872 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1118,10 +1118,6 @@ static const struct net_device_ops dsa_slave_netdev_ops = {
.ndo_vlan_rx_kill_vid = dsa_slave_vlan_rx_kill_vid,
};
-static const struct switchdev_ops dsa_slave_switchdev_ops = {
- .switchdev_port_attr_set = dsa_slave_port_attr_set,
-};
-
static struct device_type dsa_type = {
.name = "dsa",
};
@@ -1382,7 +1378,6 @@ int dsa_slave_create(struct dsa_port *port)
eth_hw_addr_inherit(slave_dev, master);
slave_dev->priv_flags |= IFF_NO_QUEUE;
slave_dev->netdev_ops = &dsa_slave_netdev_ops;
- slave_dev->switchdev_ops = &dsa_slave_switchdev_ops;
slave_dev->min_mtu = 0;
slave_dev->max_mtu = ETH_MAX_MTU;
SET_NETDEV_DEVTYPE(slave_dev, &dsa_type);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 5/8] net: mscc: ocelot: Handle SWITCHDEV_PORT_ATTR_SET
From: Florian Fainelli @ 2019-02-27 1:14 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190227011427.16487-1-f.fainelli@gmail.com>
Following patches will change the way we communicate setting a port's
attribute and use notifiers to perform those tasks.
Ocelot does not currently have an atomic notifier registered for
switchdev events, so we need to register one in order to deal with
atomic context SWITCHDEV_PORT_ATTR_SET events.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/mscc/ocelot.c | 27 ++++++++++++++++++++++++
drivers/net/ethernet/mscc/ocelot.h | 1 +
drivers/net/ethernet/mscc/ocelot_board.c | 2 ++
3 files changed, 30 insertions(+)
diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
index 195306d05bcd..83a678b11757 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -1582,6 +1582,28 @@ struct notifier_block ocelot_netdevice_nb __read_mostly = {
};
EXPORT_SYMBOL(ocelot_netdevice_nb);
+static int ocelot_switchdev_event(struct notifier_block *unused,
+ unsigned long event, void *ptr)
+{
+ struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
+ int err;
+
+ switch (event) {
+ case SWITCHDEV_PORT_ATTR_SET:
+ err = switchdev_handle_port_attr_set(dev, ptr,
+ ocelot_netdevice_dev_check,
+ ocelot_port_attr_set);
+ return notifier_from_errno(err);
+ }
+
+ return NOTIFY_DONE;
+}
+
+struct notifier_block ocelot_switchdev_nb __read_mostly = {
+ .notifier_call = ocelot_switchdev_event,
+};
+EXPORT_SYMBOL(ocelot_switchdev_nb);
+
static int ocelot_switchdev_blocking_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
@@ -1600,6 +1622,11 @@ static int ocelot_switchdev_blocking_event(struct notifier_block *unused,
ocelot_netdevice_dev_check,
ocelot_port_obj_del);
return notifier_from_errno(err);
+ case SWITCHDEV_PORT_ATTR_SET:
+ err = switchdev_handle_port_attr_set(dev, ptr,
+ ocelot_netdevice_dev_check,
+ ocelot_port_attr_set);
+ return notifier_from_errno(err);
}
return NOTIFY_DONE;
diff --git a/drivers/net/ethernet/mscc/ocelot.h b/drivers/net/ethernet/mscc/ocelot.h
index 086775f7b52f..ba3b3380b4d0 100644
--- a/drivers/net/ethernet/mscc/ocelot.h
+++ b/drivers/net/ethernet/mscc/ocelot.h
@@ -499,6 +499,7 @@ int ocelot_probe_port(struct ocelot *ocelot, u8 port,
struct phy_device *phy);
extern struct notifier_block ocelot_netdevice_nb;
+extern struct notifier_block ocelot_switchdev_nb;
extern struct notifier_block ocelot_switchdev_blocking_nb;
#endif
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
index ca3ea2fbfcd0..2c1121d86edf 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -329,6 +329,7 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
}
register_netdevice_notifier(&ocelot_netdevice_nb);
+ register_switchdev_notifier(&ocelot_switchdev_nb);
register_switchdev_blocking_notifier(&ocelot_switchdev_blocking_nb);
dev_info(&pdev->dev, "Ocelot switch probed\n");
@@ -345,6 +346,7 @@ static int mscc_ocelot_remove(struct platform_device *pdev)
ocelot_deinit(ocelot);
unregister_switchdev_blocking_notifier(&ocelot_switchdev_blocking_nb);
+ unregister_switchdev_notifier(&ocelot_switchdev_nb);
unregister_netdevice_notifier(&ocelot_netdevice_nb);
return 0;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next] net: sched: pie: fix 64-bit division
From: Randy Dunlap @ 2019-02-27 1:53 UTC (permalink / raw)
To: Leslie Monis, davem; +Cc: netdev
In-Reply-To: <20190227010006.22219-1-lesliemonis@gmail.com>
On 2/26/19 5:00 PM, Leslie Monis wrote:
> Use div_u64() to resolve build failures on 32-bit platforms.
>
> Fixes: 3f7ae5f3dc52 ("net: sched: pie: add more cases to auto-tune alpha and beta")
> Signed-off-by: Leslie Monis <lesliemonis@gmail.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
[https://lore.kernel.org/lkml/6ecd1bde-c15b-0568-2b72-6e0796a87864@infradead.org/]
> ---
> net/sched/sch_pie.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c
> index 4c0670b6aec1..f93cfe034c72 100644
> --- a/net/sched/sch_pie.c
> +++ b/net/sched/sch_pie.c
> @@ -429,7 +429,7 @@ static void calculate_probability(struct Qdisc *sch)
> */
>
> if (qdelay == 0 && qdelay_old == 0 && update_prob)
> - q->vars.prob = (q->vars.prob * 98) / 100;
> + q->vars.prob = 98 * div_u64(q->vars.prob, 100);
>
> q->vars.qdelay = qdelay;
> q->vars.qlen_old = qlen;
>
--
~Randy
^ permalink raw reply
* Re: [PATCH] net: dsa: read mac address from DT for slave device
From: xiaofeis @ 2019-02-27 2:04 UTC (permalink / raw)
To: Florian Fainelli
Cc: Vinod Koul, David S. Miller, linux-arm-msm, Bjorn Andersson,
Andrew Lunn, Vivien Didelot, Niklas Cassel, netdev
In-Reply-To: <967ec7b53270f1e29bb25e087c1a67a4@codeaurora.org>
On 2019-02-26 15:45, xiaofeis@codeaurora.org wrote:
> On 2019-02-26 01:27, Florian Fainelli wrote:
>> On 2/25/19 5:28 AM, xiaofeis@codeaurora.org wrote:
>>> Hi Florian
>>>
>>> We have two slave DSA interfaces, wan0 and lan0, one is for wan port,
>>> and the other is for lan port. Customer has it's mac address pool,
>>> they
>>> want
>>> to assign the mac address from the pool on wan0, lan0, and other
>>> interfaces like
>>> wifi, bt. Coreboot/uboot will populate it to the DTS node, so the
>>> driver
>>> can
>>> get it from it's node. For DSA slave interface, it already has it's
>>> own
>>> DTS node, it's
>>> easy to just add one porperty "local-mac-address" there for the usage
>>> in
>>> DSA driver.
>>>
>>> If not use DSA framework, normally we will use eth0.x and eth0.y for
>>> wan
>>> and lan.
>>> On this case, customer usually also assign the MAC address on these
>>> logical interface
>>> from it's pool.
>>
>> OK, but this is not necessary per my previous explanation: the CPU <=>
>> WAN pipe is a separate broadcast domain (otherwise it is a security
>> hole
>> since you exposing LAN machines to the outside world), and so there is
>> no need for a separate MAC address. It might be convenient to have
>> one,
>> especially for the provider, if they run a management software (e.g.:
>> TR69), but it is not required per-se.
>>
>> Let me ask a secondary question here, how many Ethernet MACs connect
>> to
>> the switch in this configuration? Is there one that is supposed to be
>> assigned all LAN traffic and one that is supposed to be assigned all
>> WAN
>> traffic? If so, then what you are doing makes even less
>>
>
> Only one MAC connected to switch cpu port, both lan0 and wan0 are on
> the top of
> same interface(eth0).
>
Customer doesn't care about the MAC controller's MAC address, just leave
it as the driver
randomly generated. They just want to assign the MAC address on wan and
lan DSA logical
interface.
Many customer doesn't use DSA, for example, they use eth0.1/eth0.2 for
lan/wan with one MAC controller.
They configure switch wan port in vlan2 group, and lan port in vlan1
group, they usually assign mac address
on the logical interface(eth0.1ð0.2), i think this is similar with
DSA slave interfaces.
>>>
>>> On 2019-02-22 23:43, Florian Fainelli wrote:
>>>> On 2/22/19 4:58 AM, Vinod Koul wrote:
>>>>> From: Xiaofei Shen <xiaofeis@codeaurora.org>
>>>>>
>>>>> Before creating a slave netdevice, get the mac address from DTS and
>>>>> apply in case it is valid.
>>>>
>>>> Can you explain your use case in details?
>>>>
>>>> Assigning a MAC address to a network device that represents a switch
>>>> port does not quite make sense in general. The switch port is really
>>>> representing one end of a pipe, so one side you have stations and on
>>>> the
>>>> other side, you have the CPU/management Ethernet MAC controller's
>>>> MAC
>>>> address which constitutes a station as well. The DSA slave network
>>>> devices are just software constructs meant to steer traffic towards
>>>> specific ports of the switch, but they are all from the perpsective
>>>> of
>>>> traffic reaching the CPU Port in the first place, therefore traffic
>>>> that
>>>> is generally a known unicast Ethernet frame with the CPU's MAC
>>>> address
>>>> as MAC DA (and of course all types of unknown MC, management traffic
>>>> etc.)
>>>>
>>>> By default, DSA switch need to come up in a configuration where all
>>>> ports (except CPU/management) must be strictly separate from every
>>>> other
>>>> port such that we can achieve what a standalone Ethernet NIC would
>>>> do.
>>>> This works because all ports are isolated from one another, so there
>>>> is
>>>> no cross talk and so having the same MAC address (the one from the
>>>> CPU)
>>>> on the DSA slave network devices just works, each port is a separate
>>>> broadcast domain.
>>>>
>>>> Once you start bridging one or ore ports, the bridge root port will
>>>> have
>>>> a MAC address, most likely the one the CPU/management Ethernet MAC,
>>>> but
>>>> similarly, this is not an issue and that's exactly how a software
>>>> bridge
>>>> would work as well.
>>>>
>>>>>
>>>>> Signed-off-by: Xiaofei Shen <xiaofeis@codeaurora.org>
>>>>> Signed-off-by: Vinod Koul <vkoul@kernel.org>
>>>>> ---
>>>>> include/net/dsa.h | 1 +
>>>>> net/dsa/dsa2.c | 1 +
>>>>> net/dsa/slave.c | 5 ++++-
>>>>> 3 files changed, 6 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/include/net/dsa.h b/include/net/dsa.h
>>>>> index b3eefe8e18fd..aa24ce756679 100644
>>>>> --- a/include/net/dsa.h
>>>>> +++ b/include/net/dsa.h
>>>>> @@ -198,6 +198,7 @@ struct dsa_port {
>>>>> unsigned int index;
>>>>> const char *name;
>>>>> const struct dsa_port *cpu_dp;
>>>>> + const char *mac;
>>>>> struct device_node *dn;
>>>>> unsigned int ageing_time;
>>>>> u8 stp_state;
>>>>> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
>>>>> index a1917025e155..afb7d9fa42f6 100644
>>>>> --- a/net/dsa/dsa2.c
>>>>> +++ b/net/dsa/dsa2.c
>>>>> @@ -261,6 +261,7 @@ static int dsa_port_setup(struct dsa_port *dp)
>>>>> int err = 0;
>>>>>
>>>>> memset(&dp->devlink_port, 0, sizeof(dp->devlink_port));
>>>>> + dp->mac = of_get_mac_address(dp->dn);
>>>>>
>>>>> if (dp->type != DSA_PORT_TYPE_UNUSED)
>>>>> err = devlink_port_register(ds->devlink,
>>>>> &dp->devlink_port,
>>>>> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>>>>> index a3fcc1d01615..8e64c4e947c6 100644
>>>>> --- a/net/dsa/slave.c
>>>>> +++ b/net/dsa/slave.c
>>>>> @@ -1308,7 +1308,10 @@ int dsa_slave_create(struct dsa_port *port)
>>>>> slave_dev->features = master->vlan_features | NETIF_F_HW_TC;
>>>>> slave_dev->hw_features |= NETIF_F_HW_TC;
>>>>> slave_dev->ethtool_ops = &dsa_slave_ethtool_ops;
>>>>> - eth_hw_addr_inherit(slave_dev, master);
>>>>> + if (port->mac && is_valid_ether_addr(port->mac))
>>>>> + ether_addr_copy(slave_dev->dev_addr, port->mac);
>>>>> + else
>>>>> + eth_hw_addr_inherit(slave_dev, master);
>>>>> slave_dev->priv_flags |= IFF_NO_QUEUE;
>>>>> slave_dev->netdev_ops = &dsa_slave_netdev_ops;
>>>>> slave_dev->switchdev_ops = &dsa_slave_switchdev_ops;
>>>>>
^ 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