- 28 Aug, 2020 27 commits
-
-
Florian Westphal authored
The /proc interface for nf_conntrack displays the "error" counter as "icmp_error". It makes sense to not increment "invalid" when failing to handle an icmp packet since those are special. For example, its possible for conntrack to see partial and/or fragmented packets inside icmp errors. This should be a separate event and not get mixed with the "invalid" counter. Likewise, remove the "error" increment for errors from get_l4proto(). After this, the error counter will only increment for errors coming from icmp(v6) packet handling. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
Jose M. Guisado Gomez authored
Enables storing userdata for nft_table. Field udata points to user data and udlen store its length. Adds new attribute flag NFTA_TABLE_USERDATA Signed-off-by:
Jose M. Guisado Gomez <guigom@riseup.net> Signed-off-by:
-
Peilin Ye authored
do_ip_vs_set_ctl() is referencing uninitialized stack value when `len` is zero. Fix it. Reported-by: syzbot+23b5f9e7caf61d9a3898@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=46ebfb92a8a812621a001ef04d90dfa459520fe2Suggested-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Acked-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Michael Zhou authored
Detect and rewrite a prefix embedded in an ICMPv6 original packet that was rewritten by a corresponding DNPT/SNPT rule so it will be recognised by the host that sent the original packet. Example Rules in effect on the 1:2:3:4::/64 + 5:6:7:8::/64 side router: * SNPT src-pfx 1:2:3:4::/64 dst-pfx 5:6:7:8::/64 * DNPT src-pfx 5:6:7:8::/64 dst-pfx 1:2:3:4::/64 No rules on the 9:a:b:c::/64 side. 1. 1:2:3:4::1 sends UDP packet to 9:a:b:c::1 2. Router applies SNPT changing src to 5:6:7:8::ffef::1 3. 9:a:b:c::1 receives packet with (src 5:6:7:8::ffef::1 dst 9:a:b:c::1) and replies with ICMPv6 port unreachable to 5:6:7:8::ffef::1, including original packet (src 5:6:7:8::ffef::1 dst 9:a:b:c::1) 4. Router forwards ICMPv6 packet with (src 9:a:b:c::1 dst 5:6:7:8::ffef::1) including original packet (src 5:6:7:8::ffef::1 dst 9:a:b:c::1) and applies DNPT changing dst to 1:2:3:4::1 5. 1:2:3:4::1 receives ICMPv6 packet with (src 9:a:b:c::1 dst 1:2:3:4::1) including original packet (src 5:6:7:8::ffef::1 dst 9:a:b:c::1). It doesn't recognise the original packet as the src doesn't match anything it originally sent With this change, at step 4, DNPT will also rewrite the original packet src to 1:2:3:4::1, so at step 5, 1:2:3:4::1 will recognise the ICMPv6 error and provide feedback to the application properly. Conversely, SNPT will help when ICMPv6 errors are sent from the translated network. 1. 9:a:b:c::1 sends UDP packet to 5:6:7:8::ffef::1 2. Router applies DNPT changing dst to 1:2:3:4::1 3. 1:2:3:4::1 receives packet with (src 9:a:b:c::1 dst 1:2:3:4::1) and replies with ICMPv6 port unreachable to 9:a:b:c::1 including original packet (src 9:a:b:c::1 dst 1:2:3:4::1) 4. Router forwards ICMPv6 packet with (src 1:2:3:4::1 dst 9:a:b:c::1) including original packet (src 9:a:b:c::1 dst 1:2:3:4::1) and applies SNPT changing src to 5:6:7:8::ffef::1 5. 9:a:b:c::1 receives ICMPv6 packet with (src 5:6:7:8::ffef::1 dst 9:a:b:c::1) including original packet (src 9:a:b:c::1 dst 1:2:3:4::1). It doesn't recognise the original packet as the dst doesn't match anything it already sent The change to SNPT means the ICMPv6 original packet dst will be rewritten to 5:6:7:8::ffef::1 in step 4, allowing the error to be properly recognised in step 5. Signed-off-by:
Michael Zhou <mzhou@cse.unsw.edu.au> Signed-off-by:
-
Alex Dewar authored
Commit d3b990b7 ("netlabel: fix problems with mapping removal") added a check to return an error if ret_val != 0, before ret_val is later used in a log message. Now it will unconditionally print "... res=1". So just drop the check. Addresses-Coverity: ("Dead code") Fixes: d3b990b7 ("netlabel: fix problems with mapping removal") Signed-off-by:
Alex Dewar <alex.dewar90@gmail.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Shannon Nelson says: ==================== ionic memory usage rework Previous review comments have suggested [1],[2] that this driver needs to rework how queue resources are managed and reconfigured so that we don't do a full driver reset and to better handle potential allocation failures. This patchset is intended to address those comments. The first few patches clean some general issues and simplify some of the memory structures. The last 4 patches specifically address queue parameter changes without a full ionic_stop()/ionic_open(). [1] https://lore.kernel.org/netdev/20200706103305.182bd727@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/ [2] https://lore.kernel.org/netdev/20200724.194417.2151242753657227232.davem@davemloft.net/ v3: use PTR_ALIGN without typecast fix up Neel's attribution v2: use PTR_ALIGN recovery if netif_set_real_num_tx/rx_queues fails less racy queue bring up after reconfig common-ize the reconfig queue stop and start ==================== Signed-off-by:
-
Shannon Nelson authored
Convert tx_timeout handler to not do the full reset. As this was the last user of ionic_reset_queues(), we can drop it. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Shannon Nelson authored
Add to our new ionic_reconfigure_queues() to also be able to change the number of queues in use, and to change the queue interrupt layout between split and combined. Signed-off-by:
-
Shannon Nelson authored
The original way of changing ring length was to completely tear down the lif's queue structure and then rebuild it, while running the risk of allocations that might fail in the middle and leave us with a broken driver. Instead, we can set up all the new queue and descriptor allocations first, then swap them out and delete the old allocations. If the new allocations fail, we report the error, stay with the old setup and continue running. This gives us a safer path, and a smaller window of time where we're not processing traffic. Signed-off-by:
-
Shannon Nelson authored
We really don't need to tear down and rebuild the whole queue structure when changing the MTU; we can simply stop the queues, clean and refill, then restart the queues. Signed-off-by:
-
Shannon Nelson authored
Use index counters rather than pointers for tracking head and tail in the queues to save a little memory and to perhaps slightly faster queue processing. Signed-off-by:
-
Shannon Nelson authored
Split out the queue descriptor blocks into separate dma allocations to make for smaller blocks. Co-developed-by:
Neel Patel <neel@pensando.io> Signed-off-by:
-
Shannon Nelson authored
ionic_open() and ionic_stop() are not referenced outside of their defining file, so make them static. Signed-off-by:
-
Shannon Nelson authored
Use a block of stats structs attached to the lif instead of little ones attached to each qcq. This simplifies our memory management and gets rid of a lot of unnecessary indirection. Signed-off-by:
-
Shannon Nelson authored
As we aren't yet supporting multiple lifs, we can remove complexity by removing the list concept and related code, to be re-engineered later when actually needed. Signed-off-by:
-
Shannon Nelson authored
Use kcalloc for allocating arrays of structures. Following along after commit e71642009cbdA ("ionic_lif: Use devm_kcalloc() in ionic_qcq_alloc()") there are a couple more array allocations that can be converted to using devm_kcalloc(). Signed-off-by: -
Shannon Nelson authored
Fix the queue name displayed. Signed-off-by:
-
Shannon Nelson authored
The NIC might tell us its minimum MTU, but let's be sure not to use something smaller than ETH_MIN_MTU. Signed-off-by:
-
David S. Miller authored
Dan Murphy says: ==================== Enable Fiber on DP83822 PHY The DP83822 Ethernet PHY has the ability to connect via a Fiber port. The derivative PHYs DP83825 and DP83826 do not have this ability. In fiber mode the DP83822 disables auto negotiation and has a fixed 100Mbps speed with support for full or half duplex modes. A devicetree binding was added to set the signal polarity for the fiber connection. This property is only applicable if the FX_EN strap is set in hardware other wise the signal loss detection is disabled on the PHY. If the FX_EN is not strapped the device can be configured to run in fiber mode via the device tree. All be it the PHY will not perform signal loss detection. v2 review from a long time ago can be found here - https://lore.kernel.org/patchwork/patch/1270958/ ==================== Signed-off-by:
-
Dan Murphy authored
The DP83822 can be configured to use a Fiber connection. The strap register is read to determine if the device has been configured to use a fiber connection. With the fiber connection the PHY can be configured to detect whether the fiber connection is active by either a high signal or a low signal. Fiber mode is only applicable to the DP83822 so rework the PHY match table so that non-fiber PHYs can still use the same driver but not call or use any of the fiber features. Signed-off-by:
Dan Murphy <dmurphy@ti.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Dan Murphy authored
Add a dt binding for the TI dp83822 ethernet phy device. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Mahesh Bandewar authored
The sysctl that was added earlier by commit 79134e6c ("net: do not create fallback tunnels for non-default namespaces") to create fall-back only in root-ns. This patch enhances that behavior to provide option not to create fallback tunnels in root-ns as well. Since modules that create fallback tunnels could be built-in and setting the sysctl value after booting is pointless, so added a kernel cmdline options to change this default. The default setting is preseved for backward compatibility. The kernel command line option of fb_tunnels=initns will set the sysctl value to 1 and will create fallback tunnels only in initns while kernel cmdline fb_tunnels=none will set the sysctl value to 2 and fallback tunnels are skipped in every netns. Signed-off-by:
Mahesh Bandewar <maheshb@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Maciej Zenczykowski <maze@google.com> Cc: Jian Yang <jianyang@google.com> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
David S. Miller authored
Andre Edich says: ==================== Add phylib support to smsc95xx To allow to probe external PHY drivers, this patch series adds use of phylib to the smsc95xx driver. Changes in v5: - Removed all phy_read calls from the smsc95xx driver. Changes in v4: - Removed useless inline type qualifier. Changes in v3: - Moved all MDI-X functionality to the corresponding phy driver; - Removed field internal_phy from a struct smsc95xx_priv; - Initialized field is_internal of a struct phy_device; - Kconfig: Added selection of PHYLIB and SMSC_PHY for USB_NET_SMSC95XX. Changes in v2: - Moved 'net' patches from here to the separate patch series; - Removed redundant call of the phy_start_aneg after phy_start; - Removed netif_dbg tracing "speed, duplex, lcladv, and rmtadv"; - mdiobus: added dependency from the usbnet device; - Moved making of the MII address from 'phy_id' and 'idx' into the function mii_address; - Moved direct MDIO accesses under condition 'if (pdata->internal_phy)', as they only need for the internal PHY; - To be sure, that this set of patches is git-bisectable, tested each sub-set of patches to be functional for both, internal and external PHYs, including suspend/resume test for the 'devices' (5.7.8-1-ARCH, Raspberry Pi 3 Model B). ==================== Signed-off-by: -
Andre Edich authored
Generally, each PHY has their own configuration and it can be done through an external PHY driver. The smsc95xx driver uses only the hard-coded internal PHY configuration. This patch adds phylib support to probe external PHY drivers for configuring external PHYs. The MDI-X configuration for the internal PHYs moves from drivers/net/usb/smsc95xx.c to drivers/net/phy/smsc.c. Signed-off-by:
Andre Edich <andre.edich@microchip.com> Signed-off-by:
-
Andre Edich authored
Using `void *driver_priv` instead of `unsigned long data[]` is more straightforward way to recover the `struct smsc95xx_priv *` from the `struct net_device *`. Signed-off-by:
-
Andre Edich authored
This patch removes arguments netdev and phy_id from the functions smsc95xx_mdio_read_nopm and smsc95xx_mdio_write_nopm. Both removed arguments are recovered from a new argument `struct usbnet *dev`. Signed-off-by:
-
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2020-08-28' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== This time we have: * some code to support SAE (WPA3) offload in AP mode * many documentation (wording) fixes/updates * netlink policy updates, including the use of NLA_RANGE with binary attributes * regulatory improvements for adjacent frequency bands * and a few other small additions/refactorings/cleanups ==================== Signed-off-by:
-
- 27 Aug, 2020 13 commits
-
-
Nicolas Dichtel authored
Like all other network functions, let's notify gtp context on creation and deletion. Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Tested-by:
Gabriel Ganne <gabriel.ganne@6wind.com> Acked-by:
Harald Welte <laforge@gnumonks.org> Signed-off-by:
-
David S. Miller authored
Julian Wiedmann says: ==================== s390/qeth: updates 2020-08-27 please apply the following patch series for qeth to netdev's net-next tree. Patch 8 makes some improvements to how we handle HW address events, avoiding some uncertainty around processing stale events after we switched off the feature. Except for that it's all straight-forward cleanups. ==================== Signed-off-by: -
Julian Wiedmann authored
The current code for bridge address events has two shortcomings in its control sequence: 1. after disabling address events via PNSO, we don't flush the remaining events from the event_wq. So if the feature is re-enabled fast enough, stale events could leak over. 2. PNSO and the events' arrival via the READ ccw device are unordered. So even if we flushed the workqueue, it's difficult to say whether the READ device might produce more events onto the workqueue afterwards. Fix this by 1. explicitly fencing off the events when we no longer care, in the READ device's event handler. This ensures that once we flush the workqueue, it doesn't get additional address events. 2. Flush the workqueue after disabling the events & fencing them off. As the code that triggers the flush will typically hold the sbp_lock, we need to rework the worker code to avoid a deadlock here in case of a 'notifications-stopped' event. In case of lock contention, requeue such an event with a delay. We'll eventually aquire the lock, or spot that the feature has been disabled and the event can thus be discarded. This leaves the theoretical race that a stale event could arrive _after_ we re-enabled ourselves to receive events again. Such an event would be impossible to distinguish from a 'good' event, nothing we can do about it. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
The data returned from IPA_SBP_QUERY_BRIDGE_PORTS and IPA_SBP_BRIDGE_PORT_STATE_CHANGE has the same format. Use a single struct definition for it. Signed-off-by:
-
Julian Wiedmann authored
Current code copies _all_ entries from the event into a worker, when we later only need specific data from the first entry. Signed-off-by:
-
Julian Wiedmann authored
The only time that our Bridgeport role should change is when we change the configuration ourselves. In which case we also adjust our internal state tracking, no need to do it again when we receive the corresponding event. Removing the locked section helps a subsequent patch that needs to flush the workqueue while under sbp_lock. It would be nice to raise a warning here in case HW does weird things after all, but this could end up generating false-positives when we change the configuration ourselves. Suggested-by:
-
Julian Wiedmann authored
A newly initialized device is disabled for address events, there's no need to explicitly disable them. Signed-off-by:
-
Julian Wiedmann authored
queue->state is a ternary spinlock in disguise, used by OSA's TX completion path to lock the Output Queue and flush any pending packets on it to the device. If the Queue is already locked by our TX code, setting the lock word to QETH_OUT_Q_LOCKED_FLUSH lets the TX completion code move on - the TX path will later take care of things when it unlocks the Queue. This sort of DIY locking is a non-starter of course, just let the TX completion path block on the spinlock when necessary. If that ends up causing additional latency due to lock contention, then converting the OSA path to use xmit_more is the right way to go forward. Also slightly expand the locked section and capture all of qeth_do_send_packet(), so that the update for the 'bufs_pack' statistics is done race-free. While reworking the TX completion path's code, remove a barrier() that doesn't make any sense. Signed-off-by:
-
Julian Wiedmann authored
Avoid poking around in the delayed_work struct's internals. Signed-off-by:
-
Julian Wiedmann authored
Clarify that the 'ipacmd' parameter is an enum, and thus compatible to what qeth_ipa_alloc_cmd() expects as input. Signed-off-by:
-
Hoang Huu Le authored
Syzbot has reported those issues as: ================================================================== BUG: KASAN: use-after-free in tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759 Read of size 1 at addr ffff88805e6b3571 by task kworker/0:6/3850 CPU: 0 PID: 3850 Comm: kworker/0:6 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipc_net_finalize_work Thread 1's call trace: [...] kfree+0x103/0x2c0 mm/slab.c:3757 <- bcbase releasing tipc_bcast_stop+0x1b0/0x2f0 net/tipc/bcast.c:721 tipc_exit_net+0x24/0x270 net/tipc/core.c:112 [...] Thread 2's call trace: [...] tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759 <- bcbase has already been freed by Thread 1 tipc_node_broadcast+0x9e/0xcc0 net/tipc/node.c:1744 tipc_nametbl_publish+0x60b/0x970 net/tipc/name_table.c:752 tipc_net_finalize net/tipc/net.c:141 [inline] tipc_net_finalize+0x1fa/0x310 net/tipc/net.c:131 tipc_net_finalize_work+0x55/0x80 net/tipc/net.c:150 [...] ================================================================== BUG: KASAN: use-after-free in tipc_named_reinit+0xef/0x290 net/tipc/name_distr.c:344 Read of size 8 at addr ffff888052ab2000 by task kworker/0:13/30628 CPU: 0 PID: 30628 Comm: kworker/0:13 Not tainted 5.8.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipc_net_finalize_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1f0/0x31e lib/dump_stack.c:118 print_address_description+0x66/0x5a0 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report+0x132/0x1d0 mm/kasan/report.c:530 tipc_named_reinit+0xef/0x290 net/tipc/name_distr.c:344 tipc_net_finalize+0x85/0xe0 net/tipc/net.c:138 tipc_net_finalize_work+0x50/0x70 net/tipc/net.c:150 process_one_work+0x789/0xfc0 kernel/workqueue.c:2269 worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415 kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 [...] Freed by task 14058: save_stack mm/kasan/common.c:48 [inline] set_track mm/kasan/common.c:56 [inline] kasan_set_free_info mm/kasan/common.c:316 [inline] __kasan_slab_free+0x114/0x170 mm/kasan/common.c:455 __cache_free mm/slab.c:3426 [inline] kfree+0x10a/0x220 mm/slab.c:3757 tipc_exit_net+0x29/0x50 net/tipc/core.c:113 ops_exit_list net/core/net_namespace.c:186 [inline] cleanup_net+0x708/0xba0 net/core/net_namespace.c:603 process_one_work+0x789/0xfc0 kernel/workqueue.c:2269 worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415 kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Fix it by calling flush_scheduled_work() to make sure the tipc_net_finalize_work() stopped before releasing bcbase object. Reported-by: syzbot+6ea1f7a8df64596ef4d7@syzkaller.appspotmail.com Reported-by: syzbot+e9cc557752ab126c1b99@syzkaller.appspotmail.com Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
Hoang Huu Le <hoang.h.le@dektech.com.au> Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== Move MDIO drivers into their own directory The phy subdirectory is getting cluttered. It has both PHY drivers and MDIO drivers, plus a stray switch driver. Soon more PCS drivers are likely to appear. Move MDIO and PCS drivers into new directories. This requires fixing up the xgene driver which uses a relative include path. v2: Move the subdirs to drivers/net, rather than drivers/net/phy. v3: Add subdirectories under include/linux for mdio and pcs v4: there->their include path fix No new kconfig prompts ==================== Signed-off-by: -
Andrew Lunn authored
Sort the Kconfig based on the text shown in make menuconfig and sort the Makefile by CONFIG symbol. Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
