- 23 Oct, 2018 10 commits
-
-
Shiju Jose authored
Set of hw errors occurred in the HNS3 are reported to the hns3 driver through PCIe AER and RAS.The error info will be processed and appropriately recovered. This patch adds error_detected callback and error processing. Signed-off-by: Shiju Jose <shiju.jose@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nathan Chancellor authored
Clang warns (trimmed for brevity): drivers/isdn/mISDN/tei.c:1193:7: warning: overflow converting case value to switch condition type (2147764552 to 18446744071562348872) [-Wswitch] case IMHOLD_L1: ^ drivers/isdn/mISDN/tei.c:1187:7: warning: overflow converting case value to switch condition type (2147764550 to 18446744071562348870) [-Wswitch] case IMCLEAR_L2: ^ 2 warnings generated. The root cause is that the _IOC macro can generate really large numbers, which don't find into type int. My research into how GCC and Clang are handling this at a low level didn't prove fruitful and surveying the kernel tree shows that aside from here and a few places in the scsi subsystem, everything that uses _IOC is at least of type 'unsigned int'. Make that change here because as nothing in this function cares about the signedness of the variable and it removes ambiguity, which is never good when dealing with compilers. While we're here, remove the unnecessary local variable ret (just return -EINVAL and 0 directly). Link: https://github.com/ClangBuiltLinux/linux/issues/67Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jon Maloy authored
We have seen the following race scenario: 1) named_distribute() builds a "bulk" message, containing a PUBLISH item for a certain publication. This is based on the contents of the binding tables's 'cluster_scope' list. 2) tipc_named_withdraw() removes the same publication from the list, bulds a WITHDRAW message and distributes it to all cluster nodes. 3) tipc_named_node_up(), which was calling named_distribute(), sends out the bulk message built under 1) 4) The WITHDRAW message arrives at the just detected node, finds no corresponding publication, and is dropped. 5) The PUBLISH item arrives at the same node, is added to its binding table, and remains there forever. This arrival disordering was earlier taken care of by the backlog queue, originally added for a different purpose, which was removed in the commit referred to below, but we now need a different solution. In this commit, we replace the rcu lock protecting the 'cluster_scope' list with a regular RW lock which comprises even the sending of the bulk message. This both guarantees both the list integrity and the message sending order. We will later add a commit which cleans up this code further. Note that this commit needs recently added commit d3092b2e ("tipc: fix unsafe rcu locking when accessing publication list") to apply cleanly. Fixes: 37922ea4 ("tipc: permit overlapping service ranges in name table") Reported-by: Tuong Lien Tong <tuong.t.lien@dektech.com.au> Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/marvell/octeontx2/af/rvu.c: In function 'rvu_detach_rsrcs': drivers/net/ethernet/marvell/octeontx2/af/rvu.c:855:6: warning: variable 'devnum' set but not used [-Wunused-but-set-variable] drivers/net/ethernet/marvell/octeontx2/af/rvu.c:853:7: warning: variable 'is_pf' set but not used [-Wunused-but-set-variable] drivers/net/ethernet/marvell/octeontx2/af/rvu.c: In function 'rvu_mbox_handler_ATTACH_RESOURCES': drivers/net/ethernet/marvell/octeontx2/af/rvu.c:1054:7: warning: variable 'is_pf' set but not used [-Wunused-but-set-variable] drivers/net/ethernet/marvell/octeontx2/af/rvu.c:1053:6: warning: variable 'devnum' set but not used [-Wunused-but-set-variable] It never used since introduction in commit 746ea742 ("octeontx2-af: Add RVU block LF provisioning support") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/marvell/octeontx2/af/rvu_npa.c: In function 'rvu_npa_init': drivers/net/ethernet/marvell/octeontx2/af/rvu_npa.c:446:20: warning: variable 'block' set but not used [-Wunused-but-set-variable] It never used since introduction in commit 7a37245e ("octeontx2-af: NPA block admin queue init") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Gustavo A. R. Silva says: ==================== phy: ocelot-serdes: fix out-of-bounds read This patchset aims to fix an out-of-bounds bug in the phy-ocelot-serdes driver. Currently, there is an out-of-bounds read on array ctrl->phys, once variable i reaches the maximum array size of SERDES_MAX in the for loop. Quentin Schulz pointed out that SERDES_MAX is a valid value to index ctrl->phys. So, I updated SERDES_MAX to be SERDES6G_MAX + 1 in include/dt-bindings/phy/phy-ocelot-serdes.h. Then I changed the condition in the for loop from i <= SERDES_MAX to i < SERDES_MAX in order to complete the fix. The reason I'm sending this fix as series is because checkpatch reported an error when I first tried to integrate the whole solution into a singe patch. So, changes to dt-bindings should be sent as a separate patch. Changes in v3: - Post the series to netdev, so Dave can take it. Changes in v2: - Send the whole series to Kishon Vijay Abraham I, so it can be taken into the PHY tree. - Add Quentin's Reviewed-by to commit log in both patches. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
Currently, there is an out-of-bounds read on array ctrl->phys, once variable i reaches the maximum array size of SERDES_MAX in the for loop. Fix this by changing the condition in the for loop from i <= SERDES_MAX to i < SERDES_MAX. Addresses-Coverity-ID: 1473966 ("Out-of-bounds read") Addresses-Coverity-ID: 1473959 ("Out-of-bounds read") Fixes: 51f6b410 ("phy: add driver for Microsemi Ocelot SerDes muxing") Reviewed-by: Quentin Schulz <quentin.schulz@bootlin.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
SERDES_MAX is a valid value to index ctrl->phys in drivers/phy/mscc/phy-ocelot-serdes.c. But, currently, there is an out-of-bounds bug in the mentioned driver when reading from ctrl->phys, because the size of array ctrl->phys is SERDES_MAX. Partially fix this by updating SERDES_MAX to be SERDES6G_MAX + 1. Notice that this is the first part of the solution to the out-of-bounds bug mentioned above. Although this change is not dependent on any other one. Suggested-by: Quentin Schulz <quentin.schulz@bootlin.com> Reviewed-by: Quentin Schulz <quentin.schulz@bootlin.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Guoqing Jiang authored
Got below warning with gcc 8.2 compiler. net/tipc/topsrv.c: In function ‘tipc_topsrv_start’: net/tipc/topsrv.c:660:2: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=] strncpy(srv->name, name, strlen(name) + 1); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/tipc/topsrv.c:660:27: note: length computed here strncpy(srv->name, name, strlen(name) + 1); ^~~~~~~~~~~~ So change it to correct length and use strscpy. Signed-off-by: Guoqing Jiang <gqjiang@suse.com> Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nathan Chancellor authored
Clang warns: drivers/isdn/hisax/hfc_pci.c:131:34: error: if statement has empty body [-Werror,-Wempty-body] if (Read_hfc(cs, HFCPCI_INT_S1)); ^ drivers/isdn/hisax/hfc_pci.c:131:34: note: put the semicolon on a separate line to silence this warning In my attempt to hide the warnings because I thought they didn't serve any purpose[1], Masahiro Yamada pointed out that {Read,Write}_hfc in hci_pci.c should be using a standard register access method; otherwise, the compiler will just remove the if statements. For hfc_pci, use the versions of {Read,Write}_hfc found in drivers/isdn/hardware/mISDN/hfc_pCI.h while converting pci_io to be 'void __iomem *' (and clean up ioremap) then remove the empty if statements. For hfc_sx, {Read,Write}_hfc are already use a proper register accessor (inb, outb) so just remove the unnecessary if statements. [1]: https://lore.kernel.org/lkml/20181016021454.11953-1-natechancellor@gmail.com/ Link: https://github.com/ClangBuiltLinux/linux/issues/66Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 22 Oct, 2018 11 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2018-10-21 The following pull-request contains BPF updates for your *net-next* tree. The main changes are: 1) Implement two new kind of BPF maps, that is, queue and stack map along with new peek, push and pop operations, from Mauricio. 2) Add support for MSG_PEEK flag when redirecting into an ingress psock sk_msg queue, and add a new helper bpf_msg_push_data() for insert data into the message, from John. 3) Allow for BPF programs of type BPF_PROG_TYPE_CGROUP_SKB to use direct packet access for __skb_buff, from Song. 4) Use more lightweight barriers for walking perf ring buffer for libbpf and perf tool as well. Also, various fixes and improvements from verifier side, from Daniel. 5) Add per-symbol visibility for DSO in libbpf and hide by default global symbols such as netlink related functions, from Andrey. 6) Two improvements to nfp's BPF offload to check vNIC capabilities in case prog is shared with multiple vNICs and to protect against mis-initializing atomic counters, from Jakub. 7) Fix for bpftool to use 4 context mode for the nfp disassembler, also from Jakub. 8) Fix a return value comparison in test_libbpf.sh and add several bpftool improvements in bash completion, documentation of bpf fs restrictions and batch mode summary print, from Quentin. 9) Fix a file resource leak in BPF selftest's load_kallsyms() helper, from Peng. 10) Fix an unused variable warning in map_lookup_and_delete_elem(), from Alexei. 11) Fix bpf_skb_adjust_room() signature in BPF UAPI helper doc, from Nicolas. 12) Add missing executables to .gitignore in BPF selftests, from Anders. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Wolfram Sang says: ==================== net: simplify getting .driver_data I got tired of fixing this in Renesas drivers manually, so I took the big hammer. Remove this cumbersome code pattern which got copy-pasted too much already: - struct platform_device *pdev = to_platform_device(dev); - struct ep93xx_keypad *keypad = platform_get_drvdata(pdev); + struct ep93xx_keypad *keypad = dev_get_drvdata(dev); A branch, tested by buildbot, can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git coccinelle/get_drvdata I have been asked if it couldn't be done for dev_set_drvdata as well. I checked it and did not find one occasion where it could be simplified like this. Not much of a surprise because driver_data is usually set in probe() functions which access struct platform_device in many other ways. I am open for other comments, suggestions, too, of course. Here is the cocci-script I created: @@ struct device* d; identifier pdev; expression *ptr; @@ ( - struct platform_device *pdev = to_platform_device(d); | - struct platform_device *pdev; ... - pdev = to_platform_device(d); ) <... when != pdev - &pdev->dev + d ...> ptr = - platform_get_drvdata(pdev) + dev_get_drvdata(d) <... when != pdev - &pdev->dev + d ...> ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 21 Oct, 2018 14 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
David Ahern's dump indexing bug fix in 'net' overlapped the change of the function signature of inet6_fill_ifaddr() in 'net-next'. Trivially resolved. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Quentin Monnet authored
When trying to complete "bpftool map update" commands, the call to printf would print an error message that would show on the command line if no map is found to complete the command line. Fix it by making sure we have map ids to complete the line with, before we try to print something. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
-
Quentin Monnet authored
When batch mode is used and all commands succeeds, bpftool prints the number of commands processed to stderr. There is no particular reason to use stderr for this, we could as well use stdout. It would avoid getting unnecessary output on stderr if the standard ouptut is redirected, for example. Reported-by: David Beckett <david.beckett@netronome.com> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
-
Quentin Monnet authored
Names used to pin eBPF programs and maps under the eBPF virtual file system cannot contain a dot character, which is reserved for future extensions of this file system. Document this in bpftool man pages to avoid users getting confused if pinning fails because of a dot. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netGreg Kroah-Hartman authored
David writes: "Networking: A few straggler bug fixes: 1) Fix indexing of multi-pass dumps of ipv6 addresses, from David Ahern. 2) Revert RCU locking change for bonding netpoll, causes worse problems than it solves. 3) pskb_trim_rcsum_slow() doesn't handle odd trim offsets, resulting in erroneous bad hw checksum triggers with CHECKSUM_COMPLETE devices. From Dimitris Michailidis. 4) a revert to some neighbour code changes that adjust notifications in a way that confuses some apps." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: Revert "neighbour: force neigh_invalidate when NUD_FAILED update is from admin" net/ipv6: Fix index counter for unicast addresses in in6_dump_addrs net: fix pskb_trim_rcsum_slow() with odd trim offset Revert "bond: take rcu lock in netpoll_send_skb_on_dev"
-
Quentin Monnet authored
The return value for each test in test_libbpf.sh is compared with if (( $? == 0 )) ; then ... This works well with bash, but not with dash, that /bin/sh is aliased to on some systems (such as Ubuntu). Let's replace this comparison by something that works on both shells. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Alexei Starovoitov authored
Daniel Borkmann says: ==================== Last batch of misc patches I had in queue: first one removes some left-over bits from ULP, second is a fix in the verifier where we wrongly use register number as type to fetch the string for the dump, third disables xadd on flow keys and subsequent one removes the flow key type from check_helper_mem_access() as they cannot be passed into any helper as of today. Next one lets map push, pop, peek avoid having to go through retpoline, and last one has a couple of minor fixes and cleanups for the ring buffer walk. ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Daniel Borkmann authored
Simplify bpf_perf_event_read_simple() a bit and fix up some minor things along the way: the return code in the header is not of type int but enum bpf_perf_event_ret instead. Once callback indicated to break the loop walking event data, it also needs to be consumed in data_tail since it has been processed already. Moreover, bpf_perf_event_print_t callback should avoid void * as we actually get a pointer to struct perf_event_header and thus applications can make use of container_of() to have type checks. The walk also doesn't have to use modulo op since the ring size is required to be power of two. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Daniel Borkmann authored
Extend prior work from 09772d92 ("bpf: avoid retpoline for lookup/update/delete calls on maps") to also apply to the recently added map helpers that perform push/pop/peek operations so that the indirect call can be avoided. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Daniel Borkmann authored
They PTR_TO_FLOW_KEYS is not used today to be passed into a helper as memory, so it can be removed from check_helper_mem_access(). Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Daniel Borkmann authored
We should not enable xadd operation for flow key memory if not needed there anyway. There is no such issue as described in the commit f37a8cb8 ("bpf: reject stores into ctx via st and xadd") since there's no context rewriter for flow keys today, but it also shouldn't become part of the user facing behavior to allow for it. After patch: 0: (79) r7 = *(u64 *)(r1 +144) 1: (b7) r3 = 4096 2: (db) lock *(u64 *)(r7 +0) += r3 BPF_XADD stores into R7 flow_keys is not allowed Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Daniel Borkmann authored
Using reg_type_str[insn->dst_reg] is incorrect since insn->dst_reg contains the register number but not the actual register type. Add a small reg_state() helper and use it to get to the type. Also fix up the test_verifier test cases that have an incorrect errstr. Fixes: 9d2be44a ("bpf: Reuse canonical string formatter for ctx errs") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Daniel Borkmann authored
They are not used anymore and therefore should be removed. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-
Roopa Prabhu authored
This reverts commit 8e326289. This patch results in unnecessary netlink notification when one tries to delete a neigh entry already in NUD_FAILED state. Found this with a buggy app that tries to delete a NUD_FAILED entry repeatedly. While the notification issue can be fixed with more checks, adding more complexity here seems unnecessary. Also, recent tests with other changes in the neighbour code have shown that the INCOMPLETE and PROBE checks are good enough for the original issue. Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 20 Oct, 2018 5 commits
-
-
David Ahern authored
The loop wants to skip previously dumped addresses, so loops until current index >= saved index. If the message fills it wants to save the index for the next address to dump - ie., the one that did not fit in the current message. Currently, it is incrementing the index counter before comparing to the saved index, and then the saved index is off by 1 - it assumes the current address is going to fit in the message. Change the index handling to increment only after a succesful dump. Fixes: 502a2ffd ("ipv6: convert idev_list to list macros") Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
John Fastabend says: ==================== This series adds a new helper bpf_msg_push_data to be used by sk_msg programs. The helper can be used to insert extra bytes into the message that can then be used by the program as metadata tags among other things. The first patch adds the helper, second patch the libbpf support, and last patch updates test_sockmap to run msg_push_data tests. v2: rebase after queue map and in filter.c convert int -> u32 ==================== Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
-
John Fastabend authored
Add options to run msg_push_data, this patch creates two more flags in test_sockmap that can be used to specify the offset and length of bytes to be added. The new options are --txmsg_start_push to specify where bytes should be inserted and --txmsg_end_push to specify how many bytes. This is analagous to the options that are used to pull data, --txmsg_start and --txmsg_end. In addition to adding the options tests are added to the test suit to run the tests similar to what was done for msg_pull_data. Signed-off-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
-
John Fastabend authored
Add support for new bpf_msg_push_data in libbpf. Signed-off-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
-
John Fastabend authored
This allows user to push data into a msg using sk_msg program types. The format is as follows, bpf_msg_push_data(msg, offset, len, flags) this will insert 'len' bytes at offset 'offset'. For example to prepend 10 bytes at the front of the message the user can, bpf_msg_push_data(msg, 0, 10, 0); This will invalidate data bounds so BPF user will have to then recheck data bounds after calling this. After this the msg size will have been updated and the user is free to write into the added bytes. We allow any offset/len as long as it is within the (data, data_end) range. However, a copy will be required if the ring is full and its possible for the helper to fail with ENOMEM or EINVAL errors which need to be handled by the BPF program. This can be used similar to XDP metadata to pass data between sk_msg layer and lower layers. Signed-off-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
-