- 25 Jul, 2023 11 commits
-
-
Paolo Abeni authored
Leon Romanovsky says: ==================== Support UDP encapsulation in packet offload mode As was raised by Ilia in this thread [1], the ESP over UDP feature is supported in packet offload mode. So comes this series, which adds relevant bits to the mlx5 driver and opens XFRM core code to accept such configuration. NAT-T is part of IKEv2 and strongswan uses it automatically [2]. [1] https://lore.kernel.org/all/20230718092405.4124345-1-quic_ilial@quicinc.com [2] https://wiki.strongswan.org/projects/1/wiki/NatTraversal ==================== Link: https://lore.kernel.org/r/cover.1689757619.git.leon@kernel.orgSigned-off-by: Paolo Abeni <pabeni@redhat.com>
-
Leon Romanovsky authored
Since mlx5 supports UDP encapsulation in packet offload, change the XFRM core to allow users to configure it. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Acked-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Leon Romanovsky authored
Extend mlx5 IPsec packet offload to support UDP encapsulation of IPsec ESP packets. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Leon Romanovsky authored
Set relevant IPsec capability to indicate if flow steering supports UDP encapsulation and decapsulation of IPsec ESP packets. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Leon Romanovsky authored
Provide an ability to check if flow steering supports UDP encapsulation and decapsulation of IPsec ESP packets. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Paolo Abeni authored
Russell King says: ==================== Remove legacy phylink behaviour This series removes the - as far as I can tell - unreachable code in mtk_eth_soc that relies upon legacy phylink behaviour, and then removes the support in phylink for this legacy behaviour. Patch 1 removes the clocking configuration from mtk_eth_soc for non- TRGMII, non-serdes based interface modes, and disables those interface modes prior to phylink configuration. Patch 2 removes the mac_pcs_get_state() method from mtk_eth_soc which I believe is also not used - mtk_eth_soc appears not to be used with SFPs (which would use a kind of in-band mode) nor does any DT appear to specify in-band mode for any non-serdes based interface mode. With both of those dealt with, the kernel is now free of any driver relying on the phylink legacy mode. Therefore, patch 3 removes support for this. Finally, with the advent of a new driver being submitted today that makes use of state->speed in the mac_config() path, patch 4 ensures that any phylink_link_state member that should not be used in mac_config is either cleared or set to an invalid value. ==================== Link: https://lore.kernel.org/r/ZLw8DoRskRXLQK37@shell.armlinux.org.ukSigned-off-by: Paolo Abeni <pabeni@redhat.com>
-
Russell King (Oracle) authored
Explicitly invalidate the phylink_link_state structure members in mac_config that do not contain reliable information for this function, thereby preventing their future incorrect use. Reviewed-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Russell King (Oracle) authored
Strip out all the pre-March 2020 legacy code from phylink now that the last user of it is gone. Reviewed-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Russell King (Oracle) authored
Remove the .mac_pcs_get_state function, since as far as I can tell is never called - no DT appears to specify an in-band-status management nor SFP support for this driver. Removal of this, along with the previous patch to remove the incorrect clocking configuration, means that the driver becomes non-legacy, so we can remove the "legacy_pre_march2020" status from this driver. Reviewed-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Russell King (Oracle) authored
MT7623 GMAC0 attempts to configure the system clocking according to the required speed in the .mac_config callback for non-SGMII, non-baseX and non-TRGMII modes. state->speed setting has never been reliable in the .mac_config callback - there are cases where this is not the link speed, particularly via ethtool paths, so this has always been unreliable (as detailed in phylink's documentation.) There is the additional issue that mtk_gmac0_rgmii_adjust() will only be called if state->interface changes, which means it only configures the system clocking on the very first .mac_config call, which will be made when the network device is first brought up before any link is established. Essentially, this code is incredibly buggy, and probably never worked. Moreover, checking the in-kernel DT files, it seems no platform makes use of this code path. Therefore, let's remove it, and disable interface modes for port 0 that are not SGMII, 1000base-X, 2500base-X or TRGMII on the MT7623. Reviewed-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Suman Ghosh authored
As of today, hardware does not support installing tc filter rules based on priority. This patch adds support to install the hardware rules based on priority. The final hardware rules will not be dependent on rule installation order, it will be strictly priority based, same as software. Signed-off-by: Suman Ghosh <sumang@marvell.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230721043925.2627806-1-sumang@marvell.comSigned-off-by: Paolo Abeni <pabeni@redhat.com>
-
- 24 Jul, 2023 14 commits
-
-
Paolo Abeni authored
The MPTCP code uses the assumption that the tcp_win_from_space() helper does not use any TCP-specific field, and thus works correctly operating on an MPTCP socket. The commit dfa2f048 ("tcp: get rid of sysctl_tcp_adv_win_scale") broke such assumption, and as a consequence most MPTCP connections stall on zero-window event due to auto-tuning changing the rcv buffer size quite randomly. Address the issue syncing again the MPTCP auto-tuning code with the TCP one. To achieve that, factor out the windows size logic in socket independent helpers, and reuse them in mptcp_rcv_space_adjust(). The MPTCP level scaling_ratio is selected as the minimum one from the all the subflows, as a worst-case estimate. Fixes: dfa2f048 ("tcp: get rid of sysctl_tcp_adv_win_scale") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Co-developed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Link: https://lore.kernel.org/r/20230720-upstream-net-next-20230720-mptcp-fix-rcv-buffer-auto-tuning-v1-1-175ef12b8380@tessares.netSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Breno Leitao authored
Replace kstrtoint() by kstrtobool() in the sysfs _store() functions. This improves the user usability and simplify the code. With this fix, it is now possible to use [YyNn] to set and unset a feature. Old behaviour is still unchanged. kstrtobool() is also safer and doesn't need the extra validation that is required when converting a string to bool (end field in the struct), which makes the code simpler. Suggested-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230721092146.4036622-2-leitao@debian.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Breno Leitao authored
According to the sysfs.rst documentation, _show() functions should only use sysfs_emit() instead of snprintf(). Since snprintf() shouldn't be used in the sysfs _show() path, replace it by sysfs_emit(). Suggested-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230721092146.4036622-1-leitao@debian.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Maciej Fijalkowski authored
Cited commit under 'Fixes' tag introduced new member to struct net_device without providing description of it - fix it. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/all/20230720141613.61488b9e@canb.auug.org.au/ Fixes: 13ce2daa ("xsk: add new netlink attribute dedicated for ZC max frags") Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Tested-by: Simon Horman <simon.horman@corigine.com> # build-tested Link: https://lore.kernel.org/r/20230721145808.596298-1-maciej.fijalkowski@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Daniel Borkmann authored
On qdisc destruction, the ingress_destroy() needs to update the correct entry, that is, tcx_entry_update must NULL the dev->tcx_ingress pointer. Therefore, fix the typo. Fixes: e420bed0 ("bpf: Add fd-based tcx multi-prog infra with link support") Reported-by: syzbot+bdcf141f362ef83335cf@syzkaller.appspotmail.com Reported-by: syzbot+b202b7208664142954fa@syzkaller.appspotmail.com Reported-by: syzbot+14736e249bce46091c18@syzkaller.appspotmail.com Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: syzbot+bdcf141f362ef83335cf@syzkaller.appspotmail.com Tested-by: syzbot+b202b7208664142954fa@syzkaller.appspotmail.com Tested-by: syzbot+14736e249bce46091c18@syzkaller.appspotmail.com Tested-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/20230721233330.5678-1-daniel@iogearbox.netSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
David S. Miller authored
Shannon Nelson says: ==================== ionic: add FLR support Add support for handing and recovering from a PCI FLR event. This patchset first moves some code around to make it usable from multiple paths, then adds the PCI error handler callbacks for reset_prepare and reset_done. Example test: echo 1 > /sys/bus/pci/devices/0000:2a:00.0/reset v4: - don't remove ionic_dev_teardown() in ionic_probe() in patch 2/4 - remove clear_bit() change from patch 3/4 v3: Link: https://lore.kernel.org/netdev/20230717170001.30539-1-shannon.nelson@amd.com/ - removed first patch, it is already merged into net v2: Link: https://lore.kernel.org/netdev/20230713192936.45152-1-shannon.nelson@amd.com/ - removed redundant pci_save/restore_state() calls ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Add support for the PCI reset handlers in order to manage an FLR event. Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Pull out some code from ionic_lif_handle_fw_up() that can be used in the coming FLR recovery patch. Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Pull out some chunks of code from ionic_probe() that will be common in rebuild paths. Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Pull out a chunk of code from ionic_remove() that will be common in teardown paths. Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Samin Guo says: ==================== Add motorcomm phy pad-driver-strength-cfg support The motorcomm phy (YT8531) supports the ability to adjust the drive strength of the rx_clk/rx_data, and the default strength may not be suitable for all boards. So add configurable options to better match the boards.(e.g. StarFive VisionFive 2) The first patch adds a description of dt-bingding, and the second patch adds YT8531's parsing and settings for pad-driver-strength-cfg. Changes since v4: Patch 1: - Removed register-related DS(3b) values and added vol descriptions (by Andrew Lunn) - Dropped the type and added '-microamp' suffix. (by Rob Herring) Patch 2: - Return -EINVAL if the value in DT but it is invalid (by Andrew Lunn) Changes since v3: Patch 1: - Used current values instead of register values - Added units and numerical descriptions of driver-strength Patch 2: - Added a lookup table to listing the valid values in the schema (by Andrew Lunn) Changes since v2: Patch 2: - Readjusted the order of YT8531_RGMII_xxx to below YTPHY_PAD_DRIVE_STRENGTH_REG (by Frank Sae) - Reversed Christmas tree, sort these longest first, shortest last (by Andrew Lunn) - Rebased on tag v6.4 Changes since v1: Patch 1: - Renamed "rx-xxx-driver-strength" to "motorcomm,rx-xxx-driver-strength" (by Frank Sae) Patch 2: - Added default values for rxc/rxd driver strength (by Frank Sea/Andrew Lunn) - Added range checking when val is in DT (by Frank Sea/Andrew Lunn) Previous versions: v1 - https://patchwork.kernel.org/project/netdevbpf/cover/20230426063541.15378-1-samin.guo@starfivetech.com v2 - https://patchwork.kernel.org/project/netdevbpf/cover/20230505090558.2355-1-samin.guo@starfivetech.com v3 - https://patchwork.kernel.org/project/netdevbpf/cover/20230526090502.29835-1-samin.guo@starfivetech.com v4 - https://patchwork.kernel.org/project/netdevbpf/cover/20230714101406.17686-1-samin.guo@starfivetech.com ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Samin Guo authored
The motorcomm phy (YT8531) supports the ability to adjust the drive strength of the rx_clk/rx_data, and the default strength may not be suitable for all boards. So add configurable options to better match the boards.(e.g. StarFive VisionFive 2) When we configure the drive strength, we need to read the current LDO voltage value to ensure that it is a legal value at that LDO voltage. Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Samin Guo authored
The motorcomm phy (YT8531) supports the ability to adjust the drive strength of the rx_clk/rx_data. The YT8531 RGMII LDO voltage supports 1.8V/3.3V, and the LDO voltage can be configured with hardware pull-up resistors to match the SOC voltage (usually 1.8V). The software can read the registers 0xA001 obtain the current LDO voltage value. Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
IPv6 inet sockets are supposed to have a "struct ipv6_pinfo" field at the end of their definition, so that inet6_sk_generic() can derive from socket size the offset of the "struct ipv6_pinfo". This is very fragile, and prevents adding bigger alignment in sockets, because inet6_sk_generic() does not work if the compiler adds padding after the ipv6_pinfo component. We are currently working on a patch series to reorganize TCP structures for better data locality and found issues similar to the one fixed in commit f5d54767 ("tcp: fix tcp_inet6_sk() for 32bit kernels") Alternative would be to force an alignment on "struct ipv6_pinfo", greater or equal to __alignof__(any ipv6 sock) to ensure there is no padding. This does not look great. v2: fix typo in mptcp_proto_v6_init() (Paolo) Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Chao Wu <wwchao@google.com> Cc: Wei Wang <weiwan@google.com> Cc: Coco Li <lixiaoyan@google.com> Cc: YiFei Zhu <zhuyifei@google.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 23 Jul, 2023 9 commits
-
-
Patrick Rohr authored
This change adds a new sysctl accept_ra_min_rtr_lft to specify the minimum acceptable router lifetime in an RA. If the received RA router lifetime is less than the configured value (and not 0), the RA is ignored. This is useful for mobile devices, whose battery life can be impacted by networks that configure RAs with a short lifetime. On such networks, the device should never gain IPv6 provisioning and should attempt to drop RAs via hardware offload, if available. Signed-off-by: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Cc: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
justinstitt@google.com authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. Even call sites utilizing length-bounded destination buffers should switch over to using `strtomem` or `strtomem_pad`. In this case, however, the compiler is unable to determine the size of the `data` buffer which renders `strtomem` unusable. Due to this, `strscpy` should be used. It should be noted that most call sites already zero-initialize the destination buffer. However, I've opted to use `strscpy_pad` to maintain the same exact behavior that `strncpy` produced (zero-padded tail up to `len`). Also see [3]. [1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [2]: elixir.bootlin.com/linux/v6.3/source/net/ethtool/ioctl.c#L1944 [3]: manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html Link: https://github.com/KSPP/linux/issues/90Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Justin Stitt <justinstitt@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Anjali Kulkarni says: ==================== Process connector bug fixes & enhancements Oracle DB is trying to solve a performance overhead problem it has been facing for the past 10 years and using this patch series, we can fix this issue. Oracle DB runs on a large scale with 100000s of short lived processes, starting up and exiting quickly. A process monitoring DB daemon which tracks and cleans up after processes that have died without a proper exit needs notifications only when a process died with a non-zero exit code (which should be rare). Due to the pmon architecture, which is distributed, each process is independent and has minimal interaction with pmon. Hence fd based solutions to track a process's spawning and exit cannot be used. Pmon needs to detect the abnormal death of a process so it can cleanup after. Currently it resorts to checking /proc every few seconds. Other methods we tried like using system call to reduce the above overhead were not accepted upstream. With this change, we add event based filtering to proc connector module so that DB can only listen to the events it is interested in. A new event type PROC_EVENT_NONZERO_EXIT is added, which is only sent by kernel to a listening application when any process exiting has a non-zero exit status. This change will give Oracle DB substantial performance savings - it takes 50ms to scan about 8K PIDs in /proc, about 500ms for 100K PIDs. DB does this check every 3 secs, so over an hour we save 10secs for 100K PIDs. With this, a client can register to listen for only exit or fork or a mix or all of the events. This greatly enhances performance - currently, we need to listen to all events, and there are 9 different types of events. For eg. handling 3 types of events - 8K-forks + 8K-exits + 8K-execs takes 200ms, whereas handling 2 types - 8K-forks + 8K-exits takes about 150ms, and handling just one type - 8K exits takes about 70ms. Measuring the time using pidfds for monitoring 8K process exits took 4 times longer - 200ms, as compared to 70ms using only exit notifications of proc connector. Hence, we cannot use pidfd for our use case. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. This patch series is organized as follows - Patch 1 : Needed for patch 3 to work. Patch 2 : Needed for patch 3 to work. Patch 3 : Fixes some bugs in proc connector, details in the patch. Patch 4 : Adds event based filtering for performance enhancements. Patch 5 : Allow non-root users access to proc connector events. Patch 6 : Selftest code for proc connector. v9->v10 changes: - Rebased to net-next, re-compiled and re-tested. v8->v9 changes: - Added sha1 ("title") of reversed patch as suggested by Eric Dumazet. v7->v8 changes: - Fixed an issue pointed by Liam Howlett in v7. v6->v7 changes: - Incorporated Liam Howlett's comments on v6 - Incorporated Kalesh Anakkur Purayil's comments v5->v6 changes: - Incorporated Liam Howlett's comments - Removed FILTER define from proc_filter.c and added a "-f" run-time option to run new filter code. - Made proc_filter.c a selftest in tools/testing/selftests/connector v4->v5 changes: - Change the cover letter - Fix a small issue in proc_filter.c v3->v4 changes: - Fix comments by Jakub Kicinski to incorporate root access changes within bind call of connector v2->v3 changes: - Fix comments by Jakub Kicinski to separate netlink (patch 2) (after layering) from connector fixes (patch 3). - Minor fixes suggested by Jakub. - Add new multicast group level permissions check at netlink layer. Split this into netlink & connector layers (patches 6 & 7) v1->v2 changes: - Fix comments by Jakub Kicinski to keep layering within netlink and update kdocs. - Move non-root users access patch last in series so remaining patches can go in first. v->v1 changes: - Changed commit log in patch 4 as suggested by Christian Brauner - Changed patch 4 to make more fine grained access to non-root users - Fixed warning in cn_proc.c, Reported-by: kernel test robot <lkp@intel.com> - Fixed some existing warnings in cn_proc.c ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
Run as ./proc_filter -f to run new filter code. Run without "-f" to run usual proc connector code without the new filtering code. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
There were a couple of reasons for not allowing non-root users access initially - one is there was some point no proper receive buffer management in place for netlink multicast. But that should be long fixed. See link below for more context. Second is that some of the messages may contain data that is root only. But this should be handled with a finer granularity, which is being done at the protocol layer. The only problematic protocols are nf_queue and the firewall netlink. Hence, this restriction for non-root access was relaxed for NETLINK_ROUTE initially: https://lore.kernel.org/all/20020612013101.A22399@wotan.suse.de/ This restriction has also been removed for following protocols: NETLINK_KOBJECT_UEVENT, NETLINK_AUDIT, NETLINK_SOCK_DIAG, NETLINK_GENERIC, NETLINK_SELINUX. Since process connector messages are not sensitive (process fork, exit notifications etc.), and anyone can read /proc data, we can allow non-root access here. However, since process event notification is not the only consumer of NETLINK_CONNECTOR, we can make this change even more fine grained than the protocol level, by checking for multicast group within the protocol. Allow non-root access for NETLINK_CONNECTOR via NL_CFG_F_NONROOT_RECV but add new bind function cn_bind(), which allows non-root access only for CN_IDX_PROC multicast group. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
The current proc connector code has the foll. bugs - if there are more than one listeners for the proc connector messages, and one of them deregisters for listening using PROC_CN_MCAST_IGNORE, they will still get all proc connector messages, as long as there is another listener. Another issue is if one client calls PROC_CN_MCAST_LISTEN, and another one calls PROC_CN_MCAST_IGNORE, then both will end up not getting any messages. This patch adds filtering and drops packet if client has sent PROC_CN_MCAST_IGNORE. This data is stored in the client socket's sk_user_data. In addition, we only increment or decrement proc_event_num_listeners once per client. This fixes the above issues. cn_release is the release function added for NETLINK_CONNECTOR. It uses the newly added netlink_release function added to netlink_sock. It will free sk_user_data. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
A new function netlink_release is added in netlink_sock to store the protocol's release function. This is called when the socket is deleted. This can be supplied by the protocol via the release function in netlink_kernel_cfg. This is being added for the NETLINK_CONNECTOR protocol, so it can free it's data when socket is deleted. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
To use filtering at the connector & cn_proc layers, we need to enable filtering in the netlink layer. This reverses the patch which removed netlink filtering - commit ID for that patch: 549017aa (netlink: remove netlink_broadcast_filtered). Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 22 Jul, 2023 6 commits
-
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== net: page_pool: remove page_pool_release_page() page_pool_return_page() is a historic artefact from before recycling of pages attached to skbs was supported. Theoretical uses for it may be thought up but in practice all existing users can be converted to use skb_mark_for_recycle() instead. This code was previously posted as part of the memory provider RFC. https://lore.kernel.org/all/20230707183935.997267-1-kuba@kernel.org/ ==================== Link: https://lore.kernel.org/r/20230720010409.1967072-1-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Now that page_pool_release_page() is not exported we can merge it with page_pool_return_page(). I believe that the "Do not replace this with page_pool_return_page()" comment was there in case page_pool_return_page() was not inlined, to avoid two function calls. Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com> Link: https://lore.kernel.org/r/20230720010409.1967072-5-kuba@kernel.orgReviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
There seems to be no user calling page_pool_release_page() for legit reasons, all the users simply haven't been converted to skb-based recycling, yet. Previous changes converted them. Update the docs, and unexport the function. Link: https://lore.kernel.org/r/20230720010409.1967072-4-kuba@kernel.orgReviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
stmmac removes pages from the page pool after attaching them to skbs. Use page recycling instead. skb heads are always copied, and pages are always from page pool in this driver. We could as well mark all allocated skbs for recycling. Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com> Link: https://lore.kernel.org/r/20230720010409.1967072-3-kuba@kernel.orgReviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
tsnep builds an skb with napi_build_skb() and then calls page_pool_release_page() for the page in which that skb's head sits. Use recycling instead, recycling of heads works just fine. Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com> Link: https://lore.kernel.org/r/20230720010409.1967072-2-kuba@kernel.orgReviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Currently, if cmd in the split ops array is of lower value than the previous one, genl_validate_ops() continues to do the checks as if the values are equal. This may result in non-obvious WARN_ON() hit in these check. Instead, check the incorrect ordering explicitly and put a WARN_ON() in case it is broken. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20230720111354.562242-1-jiri@resnulli.usSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-