summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-11-21Merge branch 'gve-alternate-missed-completions'David S. Miller
Jeroen de Borst says: ==================== gve: Handle alternate miss-completions Some versions of the virtual NIC present miss-completions in an alternative way. Let the diver handle these alternate completions and announce this capability to the device. The capability is announced uing a new AdminQ command that sends driver information to the device. The device can refuse a driver if it is lacking support for a capability, or it can adopt it's behavior to work around OS specific issues. Changed in v5: - Removed comments in fucntion calls - Switched ENOTSUPP back to EOPNOTSUPP and made sure it gets passed Changed in v4: - Clarified new AdminQ command in cover letter - Changed EOPNOTSUPP to ENOTSUPP to match device's response Changed in v3: - Rewording cover letter - Added 'Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>' Changes in v2: - Changed the subject to include 'gve:' ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21gve: Handle alternate miss completionsJeroen de Borst
The virtual NIC has 2 ways of indicating a miss-path completion. This handles the alternate. Signed-off-by: Jeroen de Borst <jeroendb@google.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21gve: Adding a new AdminQ command to verify driverJeroen de Borst
Check whether the driver is compatible with the device presented. Signed-off-by: Jeroen de Borst <jeroendb@google.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21NFC: nci: Extend virtual NCI deinit testDmitry Vyukov
Extend the test to check the scenario when NCI core tries to send data to already closed device to ensure that nothing bad happens. Signed-off-by: Dmitry Vyukov <dvyukov@google.com> Cc: Bongsu Jeon <bongsu.jeon@samsung.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21Merge branch 'axiennet-mdio-bus-freq'David S. Miller
Andy Chiu says: ==================== net: axienet: Use a DT property to configure frequency of the MDIO bus Some FPGA platforms have to set frequency of the MDIO bus lower than 2.5 MHz. Thus, we use a DT property, which is "clock-frequency", to work with it at boot time. The default 2.5 MHz would be set if the property is not pressent. Also, factor out mdio enable/disable functions due to the api change since 253761a0e61b7. Changelog: --- v5 --- 1. Make dt-binding patch prior to the implementation patch. 2. Disable mdio bus in error path. 3. Update description of some functions. --- v4 --- 1. change MAX_MDIO_FREQ to DEFAULT_MDIO_FREQ as suggested by Andrew. --- v3 RESEND --- 1. Repost the exact same patch again --- v3 --- 1. Fix coding style, and make probing of the driver fail if MDC overflow --- v2 --- 1. Use clock-frequency, as defined in mdio.yaml, to configure MDIO clock. 2. Only print out frequency if it is set to a non-standard value. 3. Reduce the scope of axienet_mdio_enable and remove axienet_mdio_disable because no one really uses it anymore. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21net: axienet: set mdio clock according to bus-frequencyAndy Chiu
Some FPGA platforms have 80KHz MDIO bus frequency constraint when connecting Ethernet to its on-board external Marvell PHY. Thus, we may have to set MDIO clock according to the DT. Otherwise, use the default 2.5 MHz, as specified by 802.3, if the entry is not present. Also, change MAX_MDIO_FREQ to DEFAULT_MDIO_FREQ because we may actually set MDIO bus frequency higher than 2.5MHz if undelying devices support it. And properly disable the mdio bus clock in error path. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21dt-bindings: describe the support of "clock-frequency" in mdioAndy Chiu
mdio bus frequency is going to be configurable at boottime by a property in DT now, so add a description to it. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Greentime Hu <greentime.hu@sifive.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21net: axienet: Unexport and remove unused mdio functionsAndy Chiu
Both axienet_mdio_{enable/disable} functions are no longer used in xilinx_axienet_main.c due to 253761a0e61b7. And axienet_mdio_disable is not even used in the mdio.c. So unexport and remove them. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Greentime Hu <greentime.hu@sifive.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21net: microchip: sparx5: prevent uninitialized variableDan Carpenter
Smatch complains that: drivers/net/ethernet/microchip/sparx5/sparx5_dcb.c:112 sparx5_dcb_apptrust_validate() error: uninitialized symbol 'match'. This would only happen if the: if (sparx5_dcb_apptrust_policies[i].nselectors != nselectors) condition is always true (they are not equal). The "nselectors" variable comes from dcbnl_ieee_set() and it is a number between 0-256. This seems like a probably a real bug. Fixes: 23f8382cd95d ("net: microchip: sparx5: add support for apptrust") Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21net: ethernet: mtk_eth_soc: fix RSTCTRL_PPE{0,1} definitionsLorenzo Bianconi
Fix RSTCTRL_PPE0 and RSTCTRL_PPE1 register mask definitions for MTK_NETSYS_V2. Remove duplicated definitions. Fixes: 160d3a9b1929 ("net: ethernet: mtk_eth_soc: introduce MTK_NETSYS_V2 support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21net: microchip: sparx5: kunit test: Fix compile warnings.Horatiu Vultur
When VCAP_KUNIT_TEST is enabled the following warnings are generated: drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:257:34: warning: Using plain integer as NULL pointer drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:258:41: warning: Using plain integer as NULL pointer drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:342:23: warning: Using plain integer as NULL pointer drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:359:23: warning: Using plain integer as NULL pointer drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:1327:34: warning: Using plain integer as NULL pointer drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:1328:41: warning: Using plain integer as NULL pointer Therefore fix this. Fixes: dccc30cc4906 ("net: microchip: sparx5: Add KUNIT test of counters and sorted rules") Fixes: c956b9b318d9 ("net: microchip: sparx5: Adding KUNIT tests of key/action values in VCAP API") Fixes: 67d637516fa9 ("net: microchip: sparx5: Adding KUNIT test for the VCAP API") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21Merge branch 'nfp-ipsec-offload'David S. Miller
Simon Horman says: ==================== nfp: IPsec offload support Huanhuan Wang says: this series adds support for IPsec offload to the NFP driver. It covers three enhancements: 1. Patches 1/3: - Extend the capability word and control word to to support new features. 2. Patch 2/3: - Add framework to support IPsec offloading for NFP driver, but IPsec offload control plane interface xfrm callbacks which interact with upper layer are not implemented in this patch. 3. Patch 3/3: - IPsec control plane interface xfrm callbacks are implemented in this patch. Changes since v3 * Remove structure fields that describe firmware but are not used for Kernel offload * Add WARN_ON(!xa_empty()) before call to xa_destroy() * Added helpers for hash methods Changes since v2 * OFFLOAD_HANDLE_ERROR macro and the associated code removed * Unnecessary logging removed * Hook function xdo_dev_state_free in struct xfrmdev_ops removed * Use Xarray to maintain SA entries Changes since v1 * Explicitly return failure when XFRM_STATE_ESN is set * Fix the issue that AEAD algorithm is not correctly offloaded ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21nfp: implement xfrm callbacks and expose ipsec offload feature to upper layerHuanhuan Wang
Xfrm callbacks are implemented to offload SA info into firmware by mailbox. It supports 16K SA info in total. Expose ipsec offload feature to upper layer, this feature will signal the availability of the offload. Based on initial work of Norm Bagley <norman.bagley@netronome.com>. Signed-off-by: Huanhuan Wang <huanhuan.wang@corigine.com> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Acked-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21nfp: add framework to support ipsec offloadingHuanhuan Wang
A new metadata type and config structure are introduced to interact with firmware to support ipsec offloading. This feature relies on specific firmware that supports ipsec encrypt/decrypt by advertising related capability bit. The xfrm callbacks which interact with upper layer are implemented in the following patch. Based on initial work of Norm Bagley <norman.bagley@netronome.com>. Signed-off-by: Huanhuan Wang <huanhuan.wang@corigine.com> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21nfp: extend capability and control wordsYinjun Zhang
Currently the 32-bit capability word is almost exhausted, now allocate some more words to support new features, and control word is also extended accordingly. Packet-type offloading is implemented in NIC application firmware, but it's not used in kernel driver, so reserve this bit here in case it's redefined for other use. Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-21bna: Avoid clashing function prototypesGustavo A. R. Silva
When built with Control Flow Integrity, function prototypes between caller and function declaration must match. These mismatches are visible at compile time with the new -Wcast-function-type-strict in Clang[1]. Fix a total of 227 warnings like these: drivers/net/ethernet/brocade/bna/bna_enet.c:519:3: warning: cast from 'void (*)(struct bna_ethport *, enum bna_ethport_event)' to 'bfa_fsm_t' (aka 'void (*)(void *, int)') converts to incompatible function type [-Wcast-function-type-strict] bfa_fsm_set_state(ethport, bna_ethport_sm_down); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The bna state machine code heavily overloads its state machine functions, so these have been separated into their own sets of structs, enums, typedefs, and helper functions. There are almost zero binary code changes, all seem to be related to header file line numbers changing, or the addition of the new stats helper. Important to mention is that while I was manually implementing this changes I was staring at this[2] patch from Kees Cook. Thanks, Kees. :) Link: https://github.com/KSPP/linux/issues/240 [1] https://reviews.llvm.org/D134831 [2] https://lore.kernel.org/linux-hardening/20220929230334.2109344-1-keescook@chromium.org/ Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-20Merge branch 'clean-up bpftool from legacy support'Alexei Starovoitov
Sahid Orentino Ferdjaoui says: ==================== As part of commit 93b8952d223a ("libbpf: deprecate legacy BPF map definitions") and commit bd054102a8c7 ("libbpf: enforce strict libbpf 1.0 behaviors") The --legacy option is not relevant anymore. #1 is removing it. #4 is cleaning the code from using libbpf_get_error(). About patches #2 and #3 They are changes discovered while working on this series (credits to Quentin Monnet). #2 is cleaning-up usage of an unnecessary PTR_ERR(NULL), finally #3 is fixing an invalid value passed to strerror(). v1 -> v2: - Addressed review comments from Yonghong Song on patch #4 - Added a patch #5 that removes unwanted function noticed by Yonghong Song v2 -> v3 - Addressed review comments from Andrii Nakryiko on patch #2, #3, #4 * clean-up usage of libbpf_get_error() (#2, #3) * fix possible return of an uninitialized local variable err * fix returned errors using errno v3 -> v4 - Addressed review comments from Quentin Monnet * fix line moved from patch #2 to patch #3 * fix missing returned errors using errno * fix some returned values to errno instead of -1 ==================== Reviewed-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpftool: remove function free_btf_vmlinux()Sahid Orentino Ferdjaoui
The function contains a single btf__free() call which can be inlined. Credits to Yonghong Song. Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Acked-by: Yonghong Song <yhs@fb.com> Suggested-by: Yonghong Song <yhs@fb.com> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/r/20221120112515.38165-6-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpftool: clean-up usage of libbpf_get_error()Sahid Orentino Ferdjaoui
bpftool is now totally compliant with libbpf 1.0 mode and is not expected to be compiled with pre-1.0, let's clean-up the usage of libbpf_get_error(). The changes stay aligned with returned errors always negative. - In tools/bpf/bpftool/btf.c This fixes an uninitialized local variable `err` in function do_dump() because it may now be returned without having been set. - This also removes the checks on NULL pointers before calling btf__free() because that function already does the check. Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Link: https://lore.kernel.org/r/20221120112515.38165-5-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpftool: fix error message when function can't register struct_opsSahid Orentino Ferdjaoui
It is expected that errno be passed to strerror(). This also cleans this part of code from using libbpf_get_error(). Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Acked-by: Yonghong Song <yhs@fb.com> Suggested-by: Quentin Monnet <quentin@isovalent.com> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/r/20221120112515.38165-4-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpftool: replace return value PTR_ERR(NULL) with 0Sahid Orentino Ferdjaoui
There is no reasons to keep PTR_ERR() when kern_btf=NULL, let's just return 0. This also cleans this part of code from using libbpf_get_error(). Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Acked-by: Yonghong Song <yhs@fb.com> Suggested-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/r/20221120112515.38165-3-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpftool: remove support of --legacy option for bpftoolSahid Orentino Ferdjaoui
Following: commit bd054102a8c7 ("libbpf: enforce strict libbpf 1.0 behaviors") commit 93b8952d223a ("libbpf: deprecate legacy BPF map definitions") The --legacy option is no longer relevant as libbpf no longer supports it. libbpf_set_strict_mode() is a no-op operation. Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Acked-by: Yonghong Song <yhs@fb.com> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/r/20221120112515.38165-2-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20Merge branch 'bpf: Implement two type cast kfuncs'Alexei Starovoitov
Yonghong Song says: ==================== Currenty, a non-tracing bpf program typically has a single 'context' argument with predefined uapi struct type. Following these uapi struct, user is able to access other fields defined in uapi header. Inside the kernel, the user-seen 'context' argument is replaced with 'kernel context' (or 'kctx' in short) which can access more information than what uapi header provides. To access other info not in uapi header, people typically do two things: (1). extend uapi to access more fields rooted from 'context'. (2). use bpf_probe_read_kernl() helper to read particular field based on kctx. Using (1) needs uapi change and using (2) makes code more complex since direct memory access is not allowed. There are already a few instances trying to access more information from kctx: . trying to access some fields from perf_event kctx ([1]). . trying to access some fields from xdp kctx ([2]). This patch set tried to allow direct memory access for kctx fields by introducing bpf_cast_to_kern_ctx() kfunc. Martin mentioned a use case like type casting below: #define skb_shinfo(SKB) ((struct skb_shared_info *)(skb_end_pointer(SKB))) basically a 'unsigned char *" casted to 'struct skb_shared_info *'. This patch set tries to support such a use case as well with bpf_rdonly_cast(). For the patch series, Patch 1 added support for a kfunc available to all prog types. Patch 2 added bpf_cast_to_kern_ctx() kfunc. Patch 3 added bpf_rdonly_cast() kfunc. Patch 4 added a few positive and negative tests. [1] https://lore.kernel.org/bpf/ad15b398-9069-4a0e-48cb-4bb651ec3088@meta.com/ [2] https://lore.kernel.org/bpf/20221109215242.1279993-1-john.fastabend@gmail.com/ Changelog: v3 -> v4: - remove unnecessary bpf_ctx_convert.t error checking - add and use meta.ret_btf_id instead of meta.arg_constant.value for bpf_cast_to_kern_ctx(). - add PTR_TRUSTED to the return PTR_TO_BTF_ID type for bpf_cast_to_kern_ctx(). v2 -> v3: - rebase on top of bpf-next (for merging conflicts) - add the selftest to s390x deny list rfcv1 -> v2: - break original one kfunc into two. - add missing error checks and error logs. - adapt to the new conventions in https://lore.kernel.org/all/20221118015614.2013203-1-memxor@gmail.com/ for example, with __ign and __k suffix. - added support in fixup_kfunc_call() to replace kfunc calls with a single mov. ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpf: Add type cast unit testsYonghong Song
Three tests are added. One is from John Fastabend ({1]) which tests tracing style access for xdp program from the kernel ctx. Another is a tc test to test both kernel ctx tracing style access and explicit non-ctx type cast. The third one is for negative tests including two tests, a tp_bpf test where the bpf_rdonly_cast() returns a untrusted ptr which cannot be used as helper argument, and a tracepoint test where the kernel ctx is a u64. Also added the test to DENYLIST.s390x since s390 does not currently support calling kernel functions in JIT mode. [1] https://lore.kernel.org/bpf/20221109215242.1279993-1-john.fastabend@gmail.com/ Signed-off-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20221120195442.3114844-1-yhs@fb.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpf: Add a kfunc for generic type castYonghong Song
Implement bpf_rdonly_cast() which tries to cast the object to a specified type. This tries to support use case like below: #define skb_shinfo(SKB) ((struct skb_shared_info *)(skb_end_pointer(SKB))) where skb_end_pointer(SKB) is a 'unsigned char *' and needs to be casted to 'struct skb_shared_info *'. The signature of bpf_rdonly_cast() looks like void *bpf_rdonly_cast(void *obj, __u32 btf_id) The function returns the same 'obj' but with PTR_TO_BTF_ID with btf_id. The verifier will ensure btf_id being a struct type. Since the supported type cast may not reflect what the 'obj' represents, the returned btf_id is marked as PTR_UNTRUSTED, so the return value and subsequent pointer chasing cannot be used as helper/kfunc arguments. Signed-off-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20221120195437.3114585-1-yhs@fb.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpf: Add a kfunc to type cast from bpf uapi ctx to kernel ctxYonghong Song
Implement bpf_cast_to_kern_ctx() kfunc which does a type cast of a uapi ctx object to the corresponding kernel ctx. Previously if users want to access some data available in kctx but not in uapi ctx, bpf_probe_read_kernel() helper is needed. The introduction of bpf_cast_to_kern_ctx() allows direct memory access which makes code simpler and easier to understand. Signed-off-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20221120195432.3113982-1-yhs@fb.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpf: Add support for kfunc set with common btf_idsYonghong Song
Later on, we will introduce kfuncs bpf_cast_to_kern_ctx() and bpf_rdonly_cast() which apply to all program types. Currently kfunc set only supports individual prog types. This patch added support for kfunc applying to all program types. Signed-off-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20221120195426.3113828-1-yhs@fb.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpf: Disallow bpf_obj_new_impl call when bpf_mem_alloc_init failsKumar Kartikeya Dwivedi
In the unlikely event that bpf_global_ma is not correctly initialized, instead of checking the boolean everytime bpf_obj_new_impl is called, simply check it while loading the program and return an error if bpf_global_ma_set is false. Suggested-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20221120212610.2361700-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20Merge branch 'Support storing struct task_struct objects as kptrs'Alexei Starovoitov
David Vernet says: ==================== Now that BPF supports adding new kernel functions with kfuncs, and storing kernel objects in maps with kptrs, we can add a set of kfuncs which allow struct task_struct objects to be stored in maps as referenced kptrs. The possible use cases for doing this are plentiful. During tracing, for example, it would be useful to be able to collect some tasks that performed a certain operation, and then periodically summarize who they are, which cgroup they're in, how much CPU time they've utilized, etc. Doing this now would require storing the tasks' pids along with some relevant data to be exported to user space, and later associating the pids to tasks in other event handlers where the data is recorded. Another useful by-product of this is that it allows a program to pin a task in a BPF program, and by proxy therefore also e.g. pin its task local storage. In order to support this, we'll need to expand KF_TRUSTED_ARGS to support receiving trusted, non-refcounted pointers. It currently only supports either PTR_TO_CTX pointers, or refcounted pointers. What this means in terms of the implementation is that check_kfunc_args() would have to also check for the PTR_TRUSTED or MEM_ALLOC type modifiers when determining if a trusted KF_ARG_PTR_TO_ALLOC_BTF_ID or KF_ARG_PTR_TO_BTF_ID pointer requires a refcount. Note that PTR_UNTRUSTED is insufficient for this purpose, as it does not cover all of the possible types of potentially unsafe pointers. For example, a pointer obtained from walking a struct is not PTR_UNTRUSTED. To account for this and enable us to expand KF_TRUSTED_ARGS to include allow-listed arguments such as those passed by the kernel to tracepoints and struct_ops callbacks, this patch set also introduces a new PTR_TRUSTED type flag modifier which records if a pointer was obtained passed from the kernel in a trusted context. Currently, both PTR_TRUSTED and MEM_ALLOC are used to imply that a pointer is trusted. Longer term, PTR_TRUSTED should be the sole source of truth for whether a pointer is trusted. This requires us to set PTR_TRUSTED when appropriate (e.g. when setting MEM_ALLOC), and unset it when appropriate (e.g. when setting PTR_UNTRUSTED). We don't do that in this patch, as we need to do more clean up before this can be done in a clear and well-defined manner. In closing, this patch set: 1. Adds the new PTR_TRUSTED register type modifier flag, and updates the verifier and existing selftests accordingly. Also expands KF_TRUSTED_ARGS to also include trusted pointers that were not obtained from walking structs. 2. Adds a new set of kfuncs that allows struct task_struct* objects to be used as kptrs. 3. Adds a new selftest suite to validate these new task kfuncs. --- Changelog: v8 -> v9: - Moved check for release register back to where we check for !PTR_TO_BTF_ID || socket. Change the verifier log message to reflect really what's being tested (the presence of unsafe modifiers) (Alexei) - Fix verifier_test error tests to reflect above changes - Remove unneeded parens around bitwise operator checks (Alexei) - Move updates to reg_type_str() which allow multiple type modifiers to be present in the prefix string, to a separate patch (Alexei) - Increase TYPE_STR_BUF_LEN size to 128 to reflect larger prefix size in reg_type_str(). v7 -> v8: - Rebased onto Kumar's latest patch set which, adds a new MEM_ALLOC reg type modifier for bpf_obj_new() calls. - Added comments to bpf_task_kptr_get() describing some of the subtle races we're protecting against (Alexei and John) - Slightly rework process_kf_arg_ptr_to_btf_id(), and add a new reg_has_unsafe_modifiers() function which validates that a register containing a kfunc release arg doesn't have unsafe modifiers. Note that this is slightly different than the check for KF_TRUSTED_ARGS. An alternative here would be to treat KF_RELEASE as implicitly requiring KF_TRUSTED_ARGS. - Export inline bpf_type_has_unsafe_modifiers() function from bpf_verifier.h so that it can be used from bpf_tcp_ca.c. Eventually this function should likely be changed to bpf_type_is_trusted(), once PTR_TRUSTED is the real source of truth. v6 -> v7: - Removed the PTR_WALKED type modifier, and instead define a new PTR_TRUSTED type modifier which is set on registers containing pointers passed from trusted contexts (i.e. as tracepoint or struct_ops callback args) (Alexei) - Remove the new KF_OWNED_ARGS kfunc flag. This can be accomplished by defining a new type that wraps an existing type, such as with struct nf_conn___init (Alexei) - Add a test_task_current_acquire_release testcase which verifies we can acquire a task struct returned from bpf_get_current_task_btf(). - Make bpf_task_acquire() no longer return NULL, as it can no longer be called with a NULL task. - Removed unnecessary is_test_kfunc_task() checks from failure testcases. v5 -> v6: - Add a new KF_OWNED_ARGS kfunc flag which may be used by kfuncs to express that they require trusted, refcounted args (Kumar) - Rename PTR_NESTED -> PTR_WALKED in the verifier (Kumar) - Convert reg_type_str() prefixes to use snprintf() instead of strncpy() (Kumar) - Add PTR_TO_BTF_ID | PTR_WALKED to missing struct btf_reg_type instances -- specifically btf_id_sock_common_types, and percpu_btf_ptr_types. - Add a missing PTR_TO_BTF_ID | PTR_WALKED switch case entry in check_func_arg_reg_off(), which is required when validating helper calls (Kumar) - Update reg_type_mismatch_ok() to check base types for the registers (i.e. to accommodate type modifiers). Additionally, add a lengthy comment that explains why this is being done (Kumar) - Update convert_ctx_accesses() to also issue probe reads for PTR_TO_BTF_ID | PTR_WALKED (Kumar) - Update selftests to expect new prefix reg type strings. - Rename task_kfunc_acquire_trusted_nested testcase to task_kfunc_acquire_trusted_walked, and fix a comment (Kumar) - Remove KF_TRUSTED_ARGS from bpf_task_release(), which already includes KF_RELEASE (Kumar) - Add bpf-next in patch subject lines (Kumar) v4 -> v5: - Fix an improperly formatted patch title. v3 -> v4: - Remove an unnecessary check from my repository that I forgot to remove after debugging something. v2 -> v3: - Make bpf_task_acquire() check for NULL, and include KF_RET_NULL (Martin) - Include new PTR_NESTED register modifier type flag which specifies whether a pointer was obtained from walking a struct. Use this to expand the meaning of KF_TRUSTED_ARGS to include trusted pointers that were passed from the kernel (Kumar) - Add more selftests to the task_kfunc selftest suite which verify that you cannot pass a walked pointer to bpf_task_acquire(). - Update bpf_task_acquire() to also specify KF_TRUSTED_ARGS. v1 -> v2: - Rename tracing_btf_ids to generic_kfunc_btf_ids, and add the new kfuncs to that list instead of making a separate btf id list (Alexei). - Don't run the new selftest suite on s390x, which doesn't appear to support invoking kfuncs. - Add a missing __diag_ignore block for -Wmissing-prototypes (lkp@intel.com). - Fix formatting on some of the SPDX-License-Identifier tags. - Clarified the function header comment a bit on bpf_task_kptr_get(). ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpf/selftests: Add selftests for new task kfuncsDavid Vernet
A previous change added a series of kfuncs for storing struct task_struct objects as referenced kptrs. This patch adds a new task_kfunc test suite for validating their expected behavior. Signed-off-by: David Vernet <void@manifault.com> Link: https://lore.kernel.org/r/20221120051004.3605026-5-void@manifault.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpf: Add kfuncs for storing struct task_struct * as a kptrDavid Vernet
Now that BPF supports adding new kernel functions with kfuncs, and storing kernel objects in maps with kptrs, we can add a set of kfuncs which allow struct task_struct objects to be stored in maps as referenced kptrs. The possible use cases for doing this are plentiful. During tracing, for example, it would be useful to be able to collect some tasks that performed a certain operation, and then periodically summarize who they are, which cgroup they're in, how much CPU time they've utilized, etc. In order to enable this, this patch adds three new kfuncs: struct task_struct *bpf_task_acquire(struct task_struct *p); struct task_struct *bpf_task_kptr_get(struct task_struct **pp); void bpf_task_release(struct task_struct *p); A follow-on patch will add selftests validating these kfuncs. Signed-off-by: David Vernet <void@manifault.com> Link: https://lore.kernel.org/r/20221120051004.3605026-4-void@manifault.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpf: Allow trusted pointers to be passed to KF_TRUSTED_ARGS kfuncsDavid Vernet
Kfuncs currently support specifying the KF_TRUSTED_ARGS flag to signal to the verifier that it should enforce that a BPF program passes it a "safe", trusted pointer. Currently, "safe" means that the pointer is either PTR_TO_CTX, or is refcounted. There may be cases, however, where the kernel passes a BPF program a safe / trusted pointer to an object that the BPF program wishes to use as a kptr, but because the object does not yet have a ref_obj_id from the perspective of the verifier, the program would be unable to pass it to a KF_ACQUIRE | KF_TRUSTED_ARGS kfunc. The solution is to expand the set of pointers that are considered trusted according to KF_TRUSTED_ARGS, so that programs can invoke kfuncs with these pointers without getting rejected by the verifier. There is already a PTR_UNTRUSTED flag that is set in some scenarios, such as when a BPF program reads a kptr directly from a map without performing a bpf_kptr_xchg() call. These pointers of course can and should be rejected by the verifier. Unfortunately, however, PTR_UNTRUSTED does not cover all the cases for safety that need to be addressed to adequately protect kfuncs. Specifically, pointers obtained by a BPF program "walking" a struct are _not_ considered PTR_UNTRUSTED according to BPF. For example, say that we were to add a kfunc called bpf_task_acquire(), with KF_ACQUIRE | KF_TRUSTED_ARGS, to acquire a struct task_struct *. If we only used PTR_UNTRUSTED to signal that a task was unsafe to pass to a kfunc, the verifier would mistakenly allow the following unsafe BPF program to be loaded: SEC("tp_btf/task_newtask") int BPF_PROG(unsafe_acquire_task, struct task_struct *task, u64 clone_flags) { struct task_struct *acquired, *nested; nested = task->last_wakee; /* Would not be rejected by the verifier. */ acquired = bpf_task_acquire(nested); if (!acquired) return 0; bpf_task_release(acquired); return 0; } To address this, this patch defines a new type flag called PTR_TRUSTED which tracks whether a PTR_TO_BTF_ID pointer is safe to pass to a KF_TRUSTED_ARGS kfunc or a BPF helper function. PTR_TRUSTED pointers are passed directly from the kernel as a tracepoint or struct_ops callback argument. Any nested pointer that is obtained from walking a PTR_TRUSTED pointer is no longer PTR_TRUSTED. From the example above, the struct task_struct *task argument is PTR_TRUSTED, but the 'nested' pointer obtained from 'task->last_wakee' is not PTR_TRUSTED. A subsequent patch will add kfuncs for storing a task kfunc as a kptr, and then another patch will add selftests to validate. Signed-off-by: David Vernet <void@manifault.com> Link: https://lore.kernel.org/r/20221120051004.3605026-3-void@manifault.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-20bpf: Allow multiple modifiers in reg_type_str() prefixDavid Vernet
reg_type_str() in the verifier currently only allows a single register type modifier to be present in the 'prefix' string which is eventually stored in the env type_str_buf. This currently works fine because there are no overlapping type modifiers, but once PTR_TRUSTED is added, that will no longer be the case. This patch updates reg_type_str() to support having multiple modifiers in the prefix string, and updates the size of type_str_buf to be 128 bytes. Signed-off-by: David Vernet <void@manifault.com> Link: https://lore.kernel.org/r/20221120051004.3605026-2-void@manifault.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-18net: ethernet: mediatek: ppe: assign per-port queues for offloaded trafficFelix Fietkau
Keeps traffic sent to the switch within link speed limits Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20221116080734.44013-7-nbd@nbd.name Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-18net: dsa: tag_mtk: assign per-port queuesFelix Fietkau
Keeps traffic sent to the switch within link speed limits Signed-off-by: Felix Fietkau <nbd@nbd.name> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20221116080734.44013-6-nbd@nbd.name Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-18net: ethernet: mtk_eth_soc: implement multi-queue support for per-port queuesFelix Fietkau
When sending traffic to multiple ports with different link speeds, queued packets to one port can drown out tx to other ports. In order to better handle transmission to multiple ports, use the hardware shaper feature to implement weighted fair queueing between ports. Weight and maximum rate are automatically adjusted based on the link speed of the port. The first 3 queues are unrestricted and reserved for non-DSA direct tx on GMAC ports. The following queues are automatically assigned by the MTK DSA tag driver based on the target port number. The PPE offload code configures the queues for offloaded traffic in the same way. This feature is only supported on devices supporting QDMA. All queues still share the same DMA ring and descriptor pool. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20221116080734.44013-5-nbd@nbd.name Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-18net: ethernet: mtk_eth_soc: avoid port_mg assignment on MT7622 and newerFelix Fietkau
On newer chips, this field is unused and contains some bits related to queue assignment. Initialize it to 0 in those cases. Fix offload_version on MT7621 and MT7623, which still need the previous value. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20221116080734.44013-4-nbd@nbd.name Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-18net: ethernet: mtk_eth_soc: drop packets to WDMA if the ring is fullFelix Fietkau
Improves handling of DMA ring overflow. Clarify other WDMA drop related comment. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20221116080734.44013-3-nbd@nbd.name Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-18net: ethernet: mtk_eth_soc: increase tx ring size for QDMA devicesFelix Fietkau
In order to use the hardware traffic shaper feature, a larger tx ring is needed, especially for the scratch ring, which the hardware shaper uses to reorder packets. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20221116080734.44013-2-nbd@nbd.name Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-18net: fman: remove reference to non-existing config PCSLukas Bulwahn
Commit a7c2a32e7f22 ("net: fman: memac: Use lynx pcs driver") makes the Freescale Data-Path Acceleration Architecture Frame Manager use lynx pcs driver by selecting PCS_LYNX. It also selects the non-existing config PCS as well, which has no effect. Remove this select to a non-existing config. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20221116102450.13928-1-lukas.bulwahn@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-18netlink: remove the flex array from struct nlmsghdrJakub Kicinski
I've added a flex array to struct nlmsghdr in commit 738136a0e375 ("netlink: split up copies in the ack construction") to allow accessing the data easily. It leads to warnings with clang, if user space wraps this structure into another struct and the flex array is not at the end of the container. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/all/20221114023927.GA685@u2004-local/ Link: https://lore.kernel.org/r/20221118033903.1651026-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-18bpf, samples: Use "grep -E" instead of "egrep"Tiezhu Yang
The latest version of grep (3.8+) claims the egrep is now obsolete so the build now contains warnings that look like: egrep: warning: egrep is obsolescent; using grep -E Fix this up by moving the related file to use "grep -E" instead. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/bpf/1668765001-12477-1-git-send-email-yangtiezhu@loongson.cn
2022-11-18bpf, docs: DEVMAPs and XDP_REDIRECTMaryam Tahhan
Add documentation for BPF_MAP_TYPE_DEVMAP and BPF_MAP_TYPE_DEVMAP_HASH including kernel version introduced, usage and examples. Add documentation that describes XDP_REDIRECT. Signed-off-by: Maryam Tahhan <mtahhan@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20221115144921.165483-1-mtahhan@redhat.com
2022-11-18libbpf: Ignore hashmap__find() result explicitly in btf_dumpAndrii Nakryiko
Coverity is reporting that btf_dump_name_dups() doesn't check return result of hashmap__find() call. This is intentional, so make it explicit with (void) cast. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20221117192824.4093553-1-andrii@kernel.org
2022-11-18selftests/bpf: Skip spin lock failure test on s390xKumar Kartikeya Dwivedi
Instead of adding the whole test to DENYLIST.s390x, which also has success test cases that should be run, just skip over failure test cases in case the JIT does not support kfuncs. Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20221118185938.2139616-3-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-11-18mrp: introduce active flags to prevent UAF when applicant uninitSchspa Shi
The caller of del_timer_sync must prevent restarting of the timer, If we have no this synchronization, there is a small probability that the cancellation will not be successful. And syzbot report the fellowing crash: ================================================================== BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline] BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 Write at addr f9ff000024df6058 by task syz-fuzzer/2256 Pointer tag: [f9], memory tag: [fe] CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008- ge01d50cbd6ee #0 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395 kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320 do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749 do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367 el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627 call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4 kernel/time/timer.c:1519 To fix it, we can introduce a new active flags to make sure the timer will not restart. Reported-by: syzbot+6fd64001c20aa99e34a4@syzkaller.appspotmail.com Signed-off-by: Schspa Shi <schspa@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18Merge tag 'rxrpc-next-20221116' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs David Howells says: ==================== rxrpc: Fix oops and missing config conditionals The patches that were pulled into net-next previously[1] had some issues that this patchset fixes: (1) Fix missing IPV6 config conditionals. (2) Fix an oops caused by calling udpv6_sendmsg() directly on an AF_INET socket. (3) Fix the validation of network addresses on entry to socket functions so that we don't allow an AF_INET6 address if we've selected an AF_INET transport socket. Link: https://lore.kernel.org/r/166794587113.2389296.16484814996876530222.stgit@warthog.procyon.org.uk/ [1] ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18net: fix napi_disable() logic errorEric Dumazet
Dan reported a new warning after my recent patch: New smatch warnings: net/core/dev.c:6409 napi_disable() error: uninitialized symbol 'new'. Indeed, we must first wait for STATE_SCHED and STATE_NPSVC to be cleared, to make sure @new variable has been initialized properly. Fixes: 4ffa1d1c6842 ("net: adopt try_cmpxchg() in napi_{enable|disable}()") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18rxrpc: uninitialized variable in rxrpc_send_ack_packet()Dan Carpenter
The "pkt" was supposed to have been deleted in a previous patch. It leads to an uninitialized variable bug. Fixes: 72f0c6fb0579 ("rxrpc: Allocate ACK records at proposal and queue for transmission") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-18rxrpc: fix rxkad_verify_response()Dan Carpenter
The error handling for if skb_copy_bits() fails was accidentally deleted so the rxkad_decrypt_ticket() function is not called. Fixes: 5d7edbc9231e ("rxrpc: Get rid of the Rx ring") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>