- 01 May, 2022 6 commits
-
-
Vasily Averin authored
veth netdevice defines own rx queues and allocates array containing up to 4095 ~750-bytes-long 'struct veth_rq' elements. Such allocation is quite huge and should be accounted to memcg. Signed-off-by:
Vasily Averin <vvs@openvz.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Pavel Begunkov says: ==================== UDP sock_wfree optimisations The series is not UDP specific but that the main beneficiary. 2/3 saves one atomic in sock_wfree() and on top 3/3 removes an extra barrier. Tested with UDP over dummy netdev, 2038491 -> 2099071 req/s (or around +3%). note: in regards to 1/3, there is a "Should agree with poll..." comment that I don't completely get, and there is no git history to explain it. Though I can't see how it could rely on having the second check without racing with tasks woken by wake_up*(). The series was split from a larger patchset, see https://lore.kernel.org/netdev/cover.1648981570.git.asml.silence@gmail.com/ ==================== Signed-off-by:
-
Pavel Begunkov authored
Now we have a separate path for sock_def_write_space() and can go one step further. When it's called from sock_wfree() we know that there is a preceding atomic for putting down ->sk_wmem_alloc. We can use it to replace to replace smb_mb() with a less expensive smp_mb__after_atomic(). It also removes an extra RCU read lock/unlock as a small bonus. Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Signed-off-by:
-
Pavel Begunkov authored
For non SOCK_USE_WRITE_QUEUE sockets, sock_wfree() (atomically) puts ->sk_wmem_alloc twice. It's needed to keep the socket alive while calling ->sk_write_space() after the first put. However, some sockets, such as UDP, are freed by RCU (i.e. SOCK_RCU_FREE) and use already RCU-safe sock_def_write_space(). Carve a fast path for such sockets, put down all refs in one go before calling sock_def_write_space() but guard the socket from being freed by an RCU read section. note: because TCP sockets are marked with SOCK_USE_WRITE_QUEUE it doesn't add extra checks in its path. Signed-off-by:
-
Pavel Begunkov authored
Except for minor rounding differences the first ->sk_wmem_alloc test in sock_def_write_space() is a hand coded version of sock_writeable(). Replace it with the helper, and also kill the following if duplicating the check. Signed-off-by:
-
Robert Hancock authored
With some SFP modules, such as Finisar FCLF8522P2BTL, the PHY hardware strapping defaults to 1000BaseX mode, but the kernel prefers to set them for SGMII mode. When this happens and the PHY is soft reset, the BMSR status register is updated, but this happens after the kernel has already read the PHY abilities during probing. This results in support not being detected for, and the PHY not advertising support for, 10 and 100 Mbps modes, preventing the link from working with a non-gigabit link partner. When the PHY is being configured for SGMII mode, call genphy_read_abilities again in order to re-read the capabilities, and update the advertising field accordingly. Signed-off-by:
Robert Hancock <robert.hancock@calian.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
- 30 Apr, 2022 28 commits
-
-
Horatiu Vultur authored
Starting from the blamed commit, the lan966x build fails with the following compilation error: drivers/net/ethernet/microchip/lan966x/lan966x_ptp.c:342:9: error: implicit declaration of function ‘ptp_find_pin_unlocked’ [-Werror=implicit-function-declaration] 342 | pin = ptp_find_pin_unlocked(phc->clock, PTP_PF_EXTTS, 0); The issue is that there is no stub function for ptp_find_pin_unlocked in case CONFIG_PTP_1588_CLOCK is not selected. Therefore add one. Reported-by:
kernel test robot <lkp@intel.com> Fixes: f3d8e0a9 ("net: lan966x: Add support for PTP_PF_EXTTS") Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Yu Zhe authored
remove unnecessary void* type castings. Signed-off-by:
Yu Zhe <yuzhe@nfschina.com> Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. This patch covers three more drivers which I missed in commit 5f012b40 ("eth: remove copies of the NAPI_POLL_WEIGHT define"). Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Pengcheng Yang authored
This patch doesn't change any functionality. Signed-off-by:
Pengcheng Yang <yangpc@wangsu.com> Cc: Neal Cardwell <ncardwell@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Tested-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Minghao Chi authored
Simplify the return expression. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
-
Prabhakar Kushwaha authored
Reduce verbosity of ptp tx timestamp error to reduce excessive log messages. Signed-off-by:
Manish Chopra <manishc@marvell.com> Signed-off-by:
Alok Prasad <palok@marvell.com> Signed-off-by:
Ariel Elior <aelior@marvell.com> Signed-off-by:
Prabhakar Kushwaha <pkushwaha@marvell.com> Signed-off-by:
-
Colin Foster authored
There is a desire to share the oclot_stats_layout struct outside of the current vsc7514 driver. In order to do so, the length of the array needs to be known at compile time, and defined in the struct ocelot and struct felix_info. Since the array is defined in a .c file and would be declared in the header file via: extern struct ocelot_stat_layout[]; the size of the array will not be known at compile time to outside modules. To fix this, remove the need for defining the number of stats at compile time and allow this number to be determined at initialization. Signed-off-by:
Colin Foster <colin.foster@in-advantage.com> Signed-off-by:
-
Eric Dumazet authored
In commit f84af32c ("net: ip_queue_rcv_skb() helper") I dropped the skb dst in tcp_data_queue(). This only dealt with so-called TCP input slow path. When fast path is taken, tcp_rcv_established() calls tcp_queue_rcv() while skb still has a dst. This was mostly fine, because most dsts at this point are not refcounted (thanks to early demux) However, TCP packets sent over loopback have refcounted dst. Then commit 68822bdf ("net: generalize skb freeing deferral to per-cpu lists") came and had the effect of delaying skb freeing for an arbitrary time. If during this time the involved netns is dismantled, cleanup_net() frees the struct net with embedded net->ipv6.ip6_dst_ops. Then when eventually dst_destroy_rcu() is called, if (dst->ops->destroy) ... triggers an use-after-free. It is not clear if ip6_route_net_exit() lacks a rcu_barrier() as syzbot reported similar issues before the blamed commit. ( https://groups.google.com/g/syzkaller-bugs/c/CofzW4eeA9A/m/009WjumTAAAJ ) Fixes: 68822bdf ("net: generalize skb freeing deferral to per-cpu lists") Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
David S. Miller authored
Michael Walle says: ==================== net: lan966x: remove PHY reset support Remove the unneeded PHY reset node as well as the driver support for it. This was already discussed [1] and I expect Microchip to Ack on this removal. Since there is no user, no breakage is expected. I'm not sure it this should go through net or net-next and if the patches should have a Fixes: tag or not. In upstream linux there was never any user of it, so there is no bug to be fixed. But OTOH if the schema fix isn't backported, then there might be an older schema version still containing the reset node. Thoughts? The patches needed for the GPIO part are just waiting to be picked up by Linus [2,3]. This patch and the GPIO parts are the last pieces of the puzzle to get ethernet working on the LAN9668 on upstream linux. [1] https://lore.kernel.org/netdev/20220330110210.3374165-1-michael@walle.cc/ [2] https://lore.kernel.org/linux-gpio/CACRpkdbxmN+SWt95aGHjA2ZGnN61aWaA7c5S4PaG+WePAj=htg@mail.gmail.com/ [3] https://lore.kernel.org/linux-gpio/20220420191926.3411830-1-michael@walle.cc/ ==================== Signed-off-by:
-
Michael Walle authored
The PHY subsystem as well as the MIIM mdio driver (in case of the integrated PHYs) will take care of the resets. A separate reset driver isn't needed. There is no in-tree user of this feature. Remove the support. Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
Michael Walle authored
The PHY reset was intended to be a phandle for a special PHY reset driver for the integrated PHYs as well as any external PHYs. It turns out, that the culprit is how the reset of the switch device is done. In particular, the switch reset also affects other subsystems like the GPIO and the SGPIO block and it happens to be the case that the reset lines of the external PHYs are connected to a common GPIO line. Thus as soon as the switch issues a reset during probe time, all the external PHYs will go into reset because all the GPIO lines will switch to input and the pull-down on that signal will take effect. So even if there was a special PHY reset driver, it (1) won't fix the root cause of the problem and (2) it won't fix all the other consumers of GPIO lines which will also be reset. It turns out, the Ocelot SoC has the same weird behavior (or the lack of a dedicated switch reset) and there the problem is already solved and all the bits and pieces are already there and this PHY reset property isn't not needed at all. There are no users of this binding. Just remove it. Signed-off-by:
-
David S. Miller authored
Pavel Begunkov says: ==================== generic net and ipv6 minor optimisations 1-3 inline simple functions that only reshuffle arguments possibly adding extra zero args, and call another function. It was benchmarked before with a bunch of extra patches, see for details https://lore.kernel.org/netdev/cover.1648981570.git.asml.silence@gmail.com/ It may increase the binary size, but it's the right thing to do and at least without modules it actually sheds some bytes for some standard-ish config. text data bss dec hex filename 9627200 0 0 9627200 92e640 ./arch/x86_64/boot/bzImage text data bss dec hex filename 9627104 0 0 9627104 92e5e0 ./arch/x86_64/boot/bzImage ==================== Signed-off-by:
-
Pavel Begunkov authored
Throw neigh checks in ip6_finish_output2() under a single slow path if, so we don't have the overhead in the hot path. Signed-off-by:
-
Pavel Begunkov authored
There are two callers of __ip6_finish_output(), both are in ip6_finish_output(). We can combine the call sites into one and handle return code after, that will inline __ip6_finish_output(). Note, error handling under NET_XMIT_CN will only return 0 if __ip6_finish_output() succeded, and in this case it return 0. Considering that NET_XMIT_SUCCESS is 0, it'll be returning exactly the same result for it as before. Signed-off-by:
-
Pavel Begunkov authored
Inline dev_queue_xmit() and dev_queue_xmit_accel(), they both are small proxy functions doing nothing but redirecting the control flow to __dev_queue_xmit(). Signed-off-by:
-
Pavel Begunkov authored
skb_zerocopy_iter_dgram() is a small proxy function, inline it. For that, move __zerocopy_sg_from_iter into linux/skbuff.h Signed-off-by:
-
Pavel Begunkov authored
sock_alloc_send_skb() is simple and just proxying to another function, so we can inline it and cut associated overhead. Signed-off-by:
-
Jakub Kicinski authored
Merge branch 'tcp-pass-back-data-left-in-socket-after-receive' of git://git.kernel.org/pub/scm/linux/kernel/git/kuba/linuxSigned-off-by:
-
Jens Axboe authored
This is currently done for CMSG_INQ, add an ability to do so via struct msghdr as well and have CMSG_INQ use that too. If the caller sets msghdr->msg_get_inq, then we'll pass back the hint in msghdr->msg_inq. Rearrange struct msghdr a bit so we can add this member while shrinking it at the same time. On a 64-bit build, it was 96 bytes before this change and 88 bytes afterwards. Reviewed-by:
Jens Axboe <axboe@kernel.dk> Link: https://lore.kernel.org/r/650c22ca-cffc-0255-9a05-2413a1e20826@kernel.dkSigned-off-by:
-
Yinjun Zhang authored
The device info from which conntrack originates is stored in metadata field of the ct flow to offload now, driver can utilize it to reduce the number of offloaded flows. v2: Drop inline keyword from get_netdev_from_rule() signature. The compiler can decide. Signed-off-by:Yinjun Zhang <yinjun.zhang@corigine.com> Signed-off-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20220429075124.128589-1-simon.horman@corigine.comSigned-off-by:
-
Pieter Jansen van Vuuren authored
This patch extends the EF100 PF driver by adding .sriov_configure() which would allow users to enable and disable virtual functions using the sriov sysfs. Signed-off-by:
Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Signed-off-by:
Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/75e74d9e-14ce-0524-9668-5ab735a7cf62@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Mat Martineau says: ==================== mptcp: Path manager mode selection MPTCP already has an in-kernel path manager (PM) to add and remove TCP subflows associated with a given MPTCP connection. This in-kernel PM has been designed to handle typical server-side use cases, but is not very flexible or configurable for client devices that may have more complicated policies to implement. This patch series from the MPTCP tree is the first step toward adding a generic-netlink-based API for MPTCP path management, which a privileged userspace daemon will be able to use to control subflow establishment. These patches add a per-namespace sysctl to select the default PM type (in-kernel or userspace) for new MPTCP sockets. New self-tests confirm expected behavior when userspace PM is selected but there is no daemon available to handle existing MPTCP PM events. Subsequent patch series (already staged in the MPTCP tree) will add the generic netlink path management API. ==================== Link: https://lore.kernel.org/r/20220427225002.231996-1-mathew.j.martineau@linux.intel.comSigned-off-by:
-
Mat Martineau authored
These tests ensure that the in-kernel path manager is bypassed when the userspace path manager is configured. Kernel code is still responsible for ADD_ADDR echo, so also make sure that's working. Tested-by:
Geliang Tang <geliang.tang@suse.com> Acked-by:
Paolo Abeni <pabeni@redhat.com> Co-developed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Mat Martineau authored
The new net.mptcp.pm_type sysctl determines which path manager will be used by each newly-created MPTCP socket. v2: Handle builds without CONFIG_SYSCTL v3: Clarify logic for type-specific PM init (Geliang Tang and Paolo Abeni) Acked-by:
-
Mat Martineau authored
Userspace-managed sockets should not have their subflows or advertisements changed by the kernel path manager. v3: Use helper function for PM mode (Paolo Abeni) Acked-by:
-
Mat Martineau authored
When a MPTCP connection is managed by a userspace PM, bypass the kernel PM for incoming advertisements and subflow events. Netlink events are still sent to userspace. v2: Remove unneeded check in mptcp_pm_rm_addr_received() (Kishen Maloor) v3: Add and use helper function for PM mode (Paolo Abeni) Acked-by:
Kishen Maloor <kishen.maloor@intel.com> Signed-off-by:
-
Mat Martineau authored
When adding support for netlink path management commands, the kernel needs to know whether paths are being controlled by the in-kernel path manager or a userspace PM. Acked-by:
-
Mat Martineau authored
A few members of the mptcp_pm_data struct were assigned to hard-coded values in mptcp_pm_data_reset(), and then immediately changed in mptcp_pm_nl_data_init(). Instead, flatten all the assignments in to mptcp_pm_data_reset(). v2: Resolve conflicts due to rename of mptcp_pm_data_reset() v4: Resolve conflict in mptcp_pm_data_reset() Acked-by:
-
- 29 Apr, 2022 6 commits
-
-
Jakub Kicinski authored
Michael Walle says: ==================== net: phy: micrel: add coma mode support Add support to disable coma mode by a GPIO line. ==================== Link: https://lore.kernel.org/r/20220427214406.1348872-1-michael@walle.ccSigned-off-by:
-
Michael Walle authored
The LAN8814 has a coma mode pin which puts the PHY into isolate and power-dowm mode. Unfortunately, the mode cannot be disabled by a register. Usually, the input pin has a pull-up and connected to a GPIO which can then be used to disable the mode. Try to get the GPIO and deassert it. Signed-off-by:
-
Michael Walle authored
Both lan8814_ptp_init() and lan8814_ptp_probe_once() are only used if PTP and PHY timestamping is enabed. Up until now the probe function just returns early, if they are not needed. But we need the phy_package_init_once() functionality for the coma mode GPIO setup. Move the check into the functions itself. Signed-off-by:
-
Michael Walle authored
The LAN8814 has a coma mode pin which is used to put the PHY into isolate and power-down mode. Usually strapped to be asserted by default. A GPIO is then used to take the PHY out of this mode. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
David S. Miller authored
Merge branch 'remove-NAPI_POLL_WEIGHT-copies' Jakub Kicinski says: ==================== remove copies of the NAPI_POLL_WEIGHT define netif_napi_add() takes weight as the last argument. The value of that parameter is hard to come up with and depends on many factors, so driver authors are encouraged to use NAPI_POLL_WEIGHT. We should probably move weight to an "advanced" version of the API (__netif_napi_add()?) and simplify the life of most driver authors. In preparation for such API changes this series removes local defines equivalent to NAPI_POLL_WEIGHT from drivers, so that a simple coccinelle / spatch script does not get thrown off by them. v2: - drop staging bits (patch 2) - fix subject (patch 8) - add qeth change (patch 15) ==================== Signed-off-by: -
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
-
