- 30 Apr, 2022 21 commits
-
-
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:
Eric Dumazet <edumazet@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
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 <asml.silence@gmail.com> 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:
Jakub Kicinski <kuba@kernel.org>
-
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 19 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:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Acked-by:
Geoff Levand <geoff@infradead.org> 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:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. 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:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.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. Signed-off-by:
Lino Sanfilippo <LinoSanfilippo@gmx.de> 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:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.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. 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:
-
