- 30 Jan, 2023 14 commits
-
-
Jiri Pirko authored
This effectively reverts commit 05a7f4a8 ("devlink: Break parameter notification sequence to be before/after unload/load driver"). Cited commit resolved a problem in mlx5 params implementation, when param notification code accessed memory previously freed during reload. Now, when the params can be registered and unregistered when devlink instance is registered, mlx5 code unregisters the problematic param during devlink reload. The fix is therefore no longer needed. Current behavior is a it problematic, as it sends DEL notifications even in potential case when reload_down() call fails which might confuse userspace notifications listener. So move the reload notifications back where they were originally in between reload_down() and reload_up() calls. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Steen Hegelund says: ==================== Adding Sparx5 ES2 VCAP support This provides the Egress Stage 2 (ES2) VCAP (Versatile Content-Aware Processor) support for the Sparx5 platform. The ES2 VCAP is an Egress Access Control VCAP that uses frame keyfields and previously classified keyfields to apply e.g. policing, trapping or mirroring to frames. The ES2 VCAP has 2 lookups and they are accessible with a TC chain id: - chain 20000000: ES2 Lookup 0 - chain 20100000: ES2 Lookup 1 As the other Sparx5 VCAPs the ES2 VCAP has its own lookup/port keyset configuration that decides which keys will be used for matching on which traffic type. The ES2 VCAP has these traffic classifications: - IPv4 frames - IPv6 frames - Other frames The ES2 VCAP can match on an ISDX key (Ingress Service Index) as one of the frame metadata keyfields. The IS0 VCAP can update this key using its actions, and this allows a IS0 VCAP rule to be linked to an ES2 rule. This is similar to how the IS0 VCAP and the IS2 VCAP use the PAG (Policy Association Group) keyfield to link rules. From user space this is exposed via "chain offsets", so an IS0 rule with a "goto chain 20000015" action will use an ISDX key value of 15 to link to a rule in the ES2 VCAP attached to the same chain id. ==================== Signed-off-by: -
Steen Hegelund authored
This enhances the KUNIT test of the VCAP API with tests of the chaining functionality. Signed-off-by:
Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by:
-
Steen Hegelund authored
This enables the TC command to use the Sparx5 ES2 VCAP, and provides a new ES2 ethertype table and handling of rule links between IS0 and ES2. Signed-off-by:
-
Steen Hegelund authored
This allows the check of the goto action to be specific to the ingress and egress VCAP instances. The debugfs support is also updated to show this information. Signed-off-by:
-
Steen Hegelund authored
This adds the ES2 VCAP port keyset configuration for Sparx5 and also updates the debugFS support to show the keyset configuration and the egress port mask. Signed-off-by:
-
Steen Hegelund authored
This provides the VCAP model for the Sparx5 ES2 (Egress Stage 2) VCAP. This VCAP provides tagging and remarking functionality This also renames a VCAP keyfield: VCAP_KF_MIRROR_ENA becomes VCAP_KF_MIRROR_PROBE, as the first name was caused by a mistake in the model transformation. Signed-off-by:
-
Steen Hegelund authored
This improves the error message when a TC filter with CVLAN tag is used and the selected VCAP instance does not support this. Signed-off-by:
-
Steen Hegelund authored
This ensures that it will be possible for a VCAP rule to distinguish IPv6 frames from non-IP frames, as the IS0 keyset usually selected for the IPv6 traffic class in (7TUPLE) does not offer a key that specifies IPv6 directly: only non-IPv4. The IP_SNAP key ensures that we select (at least) IP frames. Signed-off-by:
-
Steen Hegelund authored
When there is only one keyset available for a certain VCAP rule size, the particular keyset does not need a type id when encoded in the VCAP Hardware. This provides support for getting a keyset from a rule, when this is the case: only one keyset fits this rule size. Signed-off-by:
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Simon Wunderlich says: ==================== This feature/cleanup patchset includes the following patches: - bump version strings, by Simon Wunderlich - drop prandom.h includes, by Sven Eckelmann - fix mailing list address, by Sven Eckelmann - multicast feature preparation, by Linus Lüssing (2 patches) ==================== Signed-off-by: -
Florian Fainelli authored
Occasionnaly we may get oversized packets from the hardware which exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early check which drops the packet to avoid invoking skb_over_panic() and move on to processing the next packet. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
The driver can be trivially converted, as it only triggers the gpio pin briefly to do a reset, and it already only supports DT. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Heiner Kallweit authored
By using __clk_is_enabled () we can avoid defining an own variable for tracking whether enable counter is zero. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
- 28 Jan, 2023 11 commits
-
-
Johannes Berg authored
For large ranges (outside of s16) the documentation currently recommends open-coding the validation, but it's better to use the NLA_POLICY_FULL_RANGE() or NLA_POLICY_FULL_RANGE_SIGNED() policy validation instead; recommend that. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20230127084506.09f280619d64.I5dece85f06efa8ab0f474ca77df9e26d3553d4ab@changeidSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski authored
Daniel Borkmann says: ==================== bpf-next 2023-01-28 We've added 124 non-merge commits during the last 22 day(s) which contain a total of 124 files changed, 6386 insertions(+), 1827 deletions(-). The main changes are: 1) Implement XDP hints via kfuncs with initial support for RX hash and timestamp metadata kfuncs, from Stanislav Fomichev and Toke Høiland-Jørgensen. Measurements on overhead: https://lore.kernel.org/bpf/875yellcx6.fsf@toke.dk 2) Extend libbpf's bpf_tracing.h support for tracing arguments of kprobes/uprobes and syscall as a special case, from Andrii Nakryiko. 3) Significantly reduce the search time for module symbols by livepatch and BPF, from Jiri Olsa and Zhen Lei. 4) Enable cpumasks to be used as kptrs, which is useful for tracing programs tracking which tasks end up running on which CPUs in different time intervals, from David Vernet. 5) Fix several issues in the dynptr processing such as stack slot liveness propagation, missing checks for PTR_TO_STACK variable offset, etc, from Kumar Kartikeya Dwivedi. 6) Various performance improvements, fixes, and introduction of more than just one XDP program to XSK selftests, from Magnus Karlsson. 7) Big batch to BPF samples to reduce deprecated functionality, from Daniel T. Lee. 8) Enable struct_ops programs to be sleepable in verifier, from David Vernet. 9) Reduce pr_warn() noise on BTF mismatches when they are expected under the CONFIG_MODULE_ALLOW_BTF_MISMATCH config anyway, from Connor O'Brien. 10) Describe modulo and division by zero behavior of the BPF runtime in BPF's instruction specification document, from Dave Thaler. 11) Several improvements to libbpf API documentation in libbpf.h, from Grant Seltzer. 12) Improve resolve_btfids header dependencies related to subcmd and add proper support for HOSTCC, from Ian Rogers. 13) Add ipip6 and ip6ip decapsulation support for bpf_skb_adjust_room() helper along with BPF selftests, from Ziyang Xuan. 14) Simplify the parsing logic of structure parameters for BPF trampoline in the x86-64 JIT compiler, from Pu Lehui. 15) Get BTF working for kernels with CONFIG_RUST enabled by excluding Rust compilation units with pahole, from Martin Rodriguez Reboredo. 16) Get bpf_setsockopt() working for kTLS on top of TCP sockets, from Kui-Feng Lee. 17) Disable stack protection for BPF objects in bpftool given BPF backends don't support it, from Holger Hoffstätte. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (124 commits) selftest/bpf: Make crashes more debuggable in test_progs libbpf: Add documentation to map pinning API functions libbpf: Fix malformed documentation formatting selftests/bpf: Properly enable hwtstamp in xdp_hw_metadata selftests/bpf: Calls bpf_setsockopt() on a ktls enabled socket. bpf: Check the protocol of a sock to agree the calls to bpf_setsockopt(). bpf/selftests: Verify struct_ops prog sleepable behavior bpf: Pass const struct bpf_prog * to .check_member libbpf: Support sleepable struct_ops.s section bpf: Allow BPF_PROG_TYPE_STRUCT_OPS programs to be sleepable selftests/bpf: Fix vmtest static compilation error tools/resolve_btfids: Alter how HOSTCC is forced tools/resolve_btfids: Install subcmd headers bpf/docs: Document the nocast aliasing behavior of ___init bpf/docs: Document how nested trusted fields may be defined bpf/docs: Document cpumask kfuncs in a new file selftests/bpf: Add selftest suite for cpumask kfuncs selftests/bpf: Add nested trust selftests suite bpf: Enable cpumasks to be queried and used as kptrs bpf: Disallow NULLable pointers for trusted kfuncs ... ==================== Link: https://lore.kernel.org/r/20230128004827.21371-1-daniel@iogearbox.netSigned-off-by:
-
Breno Leitao authored
This patch removes the msleep(4s) during netpoll_setup() if the carrier appears instantly. Here are some scenarios where this workaround is counter-productive in modern ages: Servers which have BMC communicating over NC-SI via the same NIC as gets used for netconsole. BMC will keep the PHY up, hence the carrier appearing instantly. The link is fibre, SERDES getting sync could happen within 0.1Hz, and the carrier also appears instantly. Other than that, if a driver is reporting instant carrier and then losing it, this is probably a driver bug. Reported-by:
Michael van der Westhuizen <rmikey@meta.com> Signed-off-by:
Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20230125185230.3574681-1-leitao@debian.orgSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Conflicts: drivers/net/ethernet/intel/ice/ice_main.c 418e5340 ("ice: move devlink port creation/deletion") 643ef23b ("ice: Introduce local var for readability") https://lore.kernel.org/all/20230127124025.0dacef40@canb.auug.org.au/ https://lore.kernel.org/all/20230124005714.3996270-1-anthony.l.nguyen@intel.com/ drivers/net/ethernet/engleder/tsnep_main.c 3d53aaef ("tsnep: Fix TX queue stop/wake for multiple queues") 25faa6a4 ("tsnep: Replace TX spin_lock with __netif_tx_lock") https://lore.kernel.org/all/20230127123604.36bb3e99@canb.auug.org.au/ net/netfilter/nf_conntrack_proto_sctp.c 13bd9b31 ("Revert "netfilter: conntrack: add sctp DATA_SENT state"") a44b7651 ("netfilter: conntrack: unify established states for SCTP paths") f71cb8f4 ("netfilter: conntrack: sctp: use nf log infrastructure for invalid packets") https://lore.kernel.org/all/20230127125052.674281f9@canb.auug.org.au/ https://lore.kernel.org/all/d36076f3-6add-a442-6d4b-ead9f7ffff86@tessares.net/Signed-off-by:
-
Arınç ÜNAL authored
Fix description for tristate and help sections which include inaccurate information. Signed-off-by:
Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20230126190110.9124-1-arinc.unal@arinc9.comSigned-off-by:
-
Jakub Kicinski authored
Magnus Karlsson says: ==================== net: xdp: execute xdp_do_flush() before napi_complete_done() Make sure that xdp_do_flush() is always executed before napi_complete_done(). This is important for two reasons. First, a redirect to an XSKMAP assumes that a call to xdp_do_redirect() from napi context X on CPU Y will be followed by a xdp_do_flush() from the same napi context and CPU. This is not guaranteed if the napi_complete_done() is executed before xdp_do_flush(), as it tells the napi logic that it is fine to schedule napi context X on another CPU. Details from a production system triggering this bug using the veth driver can be found in [1]. The second reason is that the XDP_REDIRECT logic in itself relies on being inside a single NAPI instance through to the xdp_do_flush() call for RCU protection of all in-kernel data structures. Details can be found in [2]. The drivers have only been compile-tested since I do not own any of the HW below. So if you are a maintainer, it would be great if you could take a quick look to make sure I did not mess something up. Note that these were the drivers I found that violated the ordering by running a simple script and manually checking the ones that came up as potential offenders. But the script was not perfect in any way. There might still be offenders out there, since the script can generate false negatives. [1] https://lore.kernel.org/r/20221220185903.1105011-1-sbohrer@cloudflare.com [2] https://lore.kernel.org/all/20210624160609.292325-1-toke@redhat.com/ ==================== Link: https://lore.kernel.org/r/20230125074901.2737-1-magnus.karlsson@gmail.comSigned-off-by:
-
Magnus Karlsson authored
Make sure that xdp_do_flush() is always executed before napi_complete_done(). This is important for two reasons. First, a redirect to an XSKMAP assumes that a call to xdp_do_redirect() from napi context X on CPU Y will be followed by a xdp_do_flush() from the same napi context and CPU. This is not guaranteed if the napi_complete_done() is executed before xdp_do_flush(), as it tells the napi logic that it is fine to schedule napi context X on another CPU. Details from a production system triggering this bug using the veth driver can be found following the first link below. The second reason is that the XDP_REDIRECT logic in itself relies on being inside a single NAPI instance through to the xdp_do_flush() call for RCU protection of all in-kernel data structures. Details can be found in the second link below. Fixes: d678be1d ("dpaa2-eth: add XDP_REDIRECT support") Signed-off-by:
Magnus Karlsson <magnus.karlsson@intel.com> Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/r/20221220185903.1105011-1-sbohrer@cloudflare.com Link: https://lore.kernel.org/all/20210624160609.292325-1-toke@redhat.com/Signed-off-by:
-
Magnus Karlsson authored
Make sure that xdp_do_flush() is always executed before napi_complete_done(). This is important for two reasons. First, a redirect to an XSKMAP assumes that a call to xdp_do_redirect() from napi context X on CPU Y will be followed by a xdp_do_flush() from the same napi context and CPU. This is not guaranteed if the napi_complete_done() is executed before xdp_do_flush(), as it tells the napi logic that it is fine to schedule napi context X on another CPU. Details from a production system triggering this bug using the veth driver can be found following the first link below. The second reason is that the XDP_REDIRECT logic in itself relies on being inside a single NAPI instance through to the xdp_do_flush() call for RCU protection of all in-kernel data structures. Details can be found in the second link below. Fixes: a1e031ff ("dpaa_eth: add XDP_REDIRECT support") Signed-off-by:
Camelia Groza <camelia.groza@nxp.com> Signed-off-by:
-
Magnus Karlsson authored
Make sure that xdp_do_flush() is always executed before napi_complete_done(). This is important for two reasons. First, a redirect to an XSKMAP assumes that a call to xdp_do_redirect() from napi context X on CPU Y will be followed by a xdp_do_flush() from the same napi context and CPU. This is not guaranteed if the napi_complete_done() is executed before xdp_do_flush(), as it tells the napi logic that it is fine to schedule napi context X on another CPU. Details from a production system triggering this bug using the veth driver can be found following the first link below. The second reason is that the XDP_REDIRECT logic in itself relies on being inside a single NAPI instance through to the xdp_do_flush() call for RCU protection of all in-kernel data structures. Details can be found in the second link below. Fixes: 186b3c99 ("virtio-net: support XDP_REDIRECT") Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Magnus Karlsson authored
Make sure that xdp_do_flush() is always executed before napi_complete_done(). This is important for two reasons. First, a redirect to an XSKMAP assumes that a call to xdp_do_redirect() from napi context X on CPU Y will be followed by a xdp_do_flush() from the same napi context and CPU. This is not guaranteed if the napi_complete_done() is executed before xdp_do_flush(), as it tells the napi logic that it is fine to schedule napi context X on another CPU. Details from a production system triggering this bug using the veth driver can be found following the first link below. The second reason is that the XDP_REDIRECT logic in itself relies on being inside a single NAPI instance through to the xdp_do_flush() call for RCU protection of all in-kernel data structures. Details can be found in the second link below. Fixes: a825b611 ("net: lan966x: Add support for XDP_REDIRECT") Signed-off-by:
-
Magnus Karlsson authored
Make sure that xdp_do_flush() is always executed before napi_complete_done(). This is important for two reasons. First, a redirect to an XSKMAP assumes that a call to xdp_do_redirect() from napi context X on CPU Y will be followed by a xdp_do_flush() from the same napi context and CPU. This is not guaranteed if the napi_complete_done() is executed before xdp_do_flush(), as it tells the napi logic that it is fine to schedule napi context X on another CPU. Details from a production system triggering this bug using the veth driver can be found following the first link below. The second reason is that the XDP_REDIRECT logic in itself relies on being inside a single NAPI instance through to the xdp_do_flush() call for RCU protection of all in-kernel data structures. Details can be found in the second link below. Fixes: d1b25b79 ("qede: add .ndo_xdp_xmit() and XDP_REDIRECT support") Signed-off-by:
-
- 27 Jan, 2023 15 commits
-
-
Stanislav Fomichev authored
Reset stdio before printing verbose log of the SIGSEGV'ed test. Otherwise, it's hard to understand what's going on in the cases like [0]. With the following patch applied: --- a/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c +++ b/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c @@ -392,6 +392,11 @@ void test_xdp_metadata(void) "generate freplace packet")) goto out; + + ASSERT_EQ(1, 2, "oops"); + int *x = 0; + *x = 1; /* die */ + while (!retries--) { if (bpf_obj2->bss->called) break; Before: #281 xdp_metadata:FAIL Caught signal #11! Stack trace: ./test_progs(crash_handler+0x1f)[0x55c919d98bcf] /lib/x86_64-linux-gnu/libc.so.6(+0x3bf90)[0x7f36aea5df90] ./test_progs(test_xdp_metadata+0x1db0)[0x55c919d8c6d0] ./test_progs(+0x23b438)[0x55c919d9a438] ./test_progs(main+0x534)[0x55c919d99454] /lib/x86_64-linux-gnu/libc.so.6(+0x2718a)[0x7f36aea4918a] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7f36aea49245] ./test_progs(_start+0x21)[0x55c919b82ef1] After: test_xdp_metadata:PASS:ip netns add xdp_metadata 0 nsec open_netns:PASS:malloc token 0 nsec open_netns:PASS:open /proc/self/ns/net 0 nsec open_netns:PASS:open netns fd 0 nsec open_netns:PASS:setns 0 nsec .. test_xdp_metadata:FAIL:oops unexpected oops: actual 1 != expected 2 #281 xdp_metadata:FAIL Caught signal #11! Stack trace: ./test_progs(crash_handler+0x1f)[0x562714a76bcf] /lib/x86_64-linux-gnu/libc.so.6(+0x3bf90)[0x7fa663f9cf90] ./test_progs(test_xdp_metadata+0x1db0)[0x562714a6a6d0] ./test_progs(+0x23b438)[0x562714a78438] ./test_progs(main+0x534)[0x562714a77454] /lib/x86_64-linux-gnu/libc.so.6(+0x2718a)[0x7fa663f8818a] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7fa663f88245] ./test_progs(_start+0x21)[0x562714860ef1] 0: https://github.com/kernel-patches/bpf/actions/runs/4019879316/jobs/6907358876Signed-off-by:Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/r/20230127215705.1254316-1-sdf@google.comSigned-off-by:
Martin KaFai Lau <martin.lau@kernel.org>
-
Grant Seltzer authored
This adds documentation for the following API functions: - bpf_map__set_pin_path() - bpf_map__pin_path() - bpf_map__is_pinned() - bpf_map__pin() - bpf_map__unpin() - bpf_object__pin_maps() - bpf_object__unpin_maps() Signed-off-by:
Grant Seltzer <grantseltzer@gmail.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20230126024225.520685-1-grantseltzer@gmail.com
-
Grant Seltzer authored
This fixes the doxygen format documentation above the user_ring_buffer__* APIs. There has to be a newline before the @brief, otherwise doxygen won't render them for libbpf.readthedocs.org. Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== devlink: Cleanup params usage This patchset takes care of small cleanup of devlink params usage. Some of the patches (first 2/3) are cosmetic, but I would like to point couple of interesting ones: Patch 9 is the main one of this set and introduces devlink instance locking for params, similar to other devlink objects. That allows params to be registered/unregistered when devlink instance is registered. Patches 10-12 change mlx5 code to register non-driverinit params in the code they are related to, and thanks to patch 8 this might be when devlink instance is registered - for example during devlink reload. --- v1->v2: - Just small fix in the last patch ==================== Signed-off-by: -
Jiri Pirko authored
Move the param registration and handling code into the eswitch offloads code as they are related to each other. No point in having the devlink param registration done in separate file. Signed-off-by:
-
Jiri Pirko authored
Move the param registration and handling code into the flow steering code as they are related to each other. No point in having the devlink param registration done in separate file. Signed-off-by:
-
Jiri Pirko authored
Move the param registration and handling code into the fw reset code as they are related to each other. No point in having the devlink param registration done in separate file. Signed-off-by:
-
Jiri Pirko authored
Commit 1d18bb1a ("devlink: allow registering parameters after the instance") as the subject implies introduced possibility to register devlink params even for already registered devlink instance. This is a bit problematic, as the consistency or params list was originally secured by the fact it is static during devlink lifetime. So in order to protect the params list, take devlink instance lock during the params operations. Introduce unlocked function variants and use them in drivers in locked context. Put lock assertions to appropriate places. Signed-off-by:
Simon Horman <simon.horman@corigine.com> Tested-by:
-
Jiri Pirko authored
Put couple of WARN_ONs in devlink_param_driverinit_value_get() function to clearly indicate, that it is a driver bug if used without reload support or for non-driverinit param. Signed-off-by:
-
Jiri Pirko authored
devlink_param_driverinit_value_set() currently returns int with possible error, but no user is checking it anyway. The only reason for a fail is a driver bug. So convert the function to return void and put WARN_ONs on error paths. Signed-off-by:
-
Jiri Pirko authored
devlink_param_driverinit_value_set() call makes sense only for " driverinit" params. However here, the param is "runtime". devlink_param_driverinit_value_set() returns -EOPNOTSUPP in such case and does not do anything. So remove the pointless call to devlink_param_driverinit_value_set() entirely. Signed-off-by:
-
Jiri Pirko authored
devlink_param_driverinit_value_set() call makes sense only for "driverinit" params. However here, both params are "runtime". devlink_param_driverinit_value_set() returns -EOPNOTSUPP in such case and does not do anything. So remove the pointless calls to devlink_param_driverinit_value_set() entirely. Signed-off-by:
-
Jiri Pirko authored
There is a WARN_ON checking the param_item for being NULL when the param is not inserted in the list. That indicates a driver BUG. Instead of continuing to work with NULL pointer with its consequences, return. Signed-off-by:
-
Jiri Pirko authored
There is no user outside the devlink code, so remove the export and make the functions static. Move them before callers to avoid forward declarations. Signed-off-by:
-
Jiri Pirko authored
Since mlx5 is the only user of devlink API to register/unregister a single param, convert it to use array registration function allowing to simplify the devlink API by removing the single param registration functions. Signed-off-by:
-
