- Dec 11, 2021
-
-
Clément Léger authored
FDMA will need this code to prepare the injection frame header when sending SKBs. Move this code into ocelot_ifh_port_set() and add conditional IFH setting for vlan and rew op if they are not set. Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
Clément Léger <clement.leger@bootlin.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
M Chetan Kumar says: ==================== net: wwan: iosm: improvements This patch series brings in IOSM driver improvments. PATCH1: Set tx queue len. PATCH2: Release data channel if there is no active IP session. PATCH3: Removes dead code. PATCH4: Correct open parenthesis alignment. ==================== Link: https://lore.kernel.org/r/20211209143230.3054755-1-m.chetan.kumar@linux.intel.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
M Chetan Kumar authored
Fix checkpatch warning in iosm_ipc_mmio.c - Alignment should match open parenthesis Signed-off-by:
M Chetan Kumar <m.chetan.kumar@linux.intel.com> Reviewed-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
M Chetan Kumar authored
ipc_wwan_tx_flowctrl() is declared in iosm_ipc_wwan.h but is not defined. Removed the dead code. Signed-off-by:
M Chetan Kumar <m.chetan.kumar@linux.intel.com> Reviewed-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
M Chetan Kumar authored
If there is no active IP session (interface up & running) then release the data channel. Use nr_sessions variable to track current active IP sessions. If the count drops to 0, then send pipe close ctrl message to release the data channel. Signed-off-by:
M Chetan Kumar <m.chetan.kumar@linux.intel.com> Reviewed-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
M Chetan Kumar authored
Set wwan net dev tx queue len to DEFAULT_TX_QUEUE_LEN. Signed-off-by:
M Chetan Kumar <m.chetan.kumar@linux.intel.com> Reviewed-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Colin Foster authored
commit 32ecd22b ("net: mscc: ocelot: split register definitions to a separate file") left out an include for <soc/mscc/ocelot_vcap.h>. It was missed because the only consumer was ocelot_vsc7514.h, which already included ocelot_vcap. Fixes: 32ecd22b ("net: mscc: ocelot: split register definitions to a separate file") Signed-off-by:
Colin Foster <colin.foster@in-advantage.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20211209074010.1813010-1-colin.foster@in-advantage.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Erik Ekman authored
The BR-series installation guide from https://driverdownloads.qlogic.com/ mentions the cards support 10Gbase-SR/LR as well as direct attach cables. The cards only have SFP+ ports, so 10000baseT is not the right mode. Switch to using more specific link modes added in commit 5711a982 ("net: ethtool: add support for 1000BaseX and missing 10G link modes"). Only compile tested. Signed-off-by:
Erik Ekman <erik@kryo.se> Link: https://lore.kernel.org/r/20211208230022.153496-1-erik@kryo.se Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Kuniyuki Iwashima authored
This patch moves sock_release_ownership() down in include/net/sock.h and replaces some sk_lock.owned tests with sock_owned_by_user_nocheck(). Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.co.jp> Link: https://lore.kernel.org/r/20211208062158.54132-1-kuniyu@amazon.co.jp Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski authored
Andrii Nakryiko says: ==================== bpf-next 2021-12-10 v2 We've added 115 non-merge commits during the last 26 day(s) which contain a total of 182 files changed, 5747 insertions(+), 2564 deletions(-). The main changes are: 1) Various samples fixes, from Alexander Lobakin. 2) BPF CO-RE support in kernel and light skeleton, from Alexei Starovoitov. 3) A batch of new unified APIs for libbpf, logging improvements, version querying, etc. Also a batch of old deprecations for old APIs and various bug fixes, in preparation for libbpf 1.0, from Andrii Nakryiko. 4) BPF documentation reorganization and improvements, from Christoph Hellwig and Dave Tucker. 5) Support for declarative initialization of BPF_MAP_TYPE_PROG_ARRAY in libbpf, from Hengqi Chen. 6) Verifier log fixes, from Hou Tao. 7) Runtime-bounded loops support with bpf_loop() helper, from Joanne Koong. 8) Extend branch record capturing to all platforms that support it, from Kajol Jain. 9) Light skeleton codegen improvements, from Kumar Kartikeya Dwivedi. 10) bpftool doc-generating script improvements, from Quentin Monnet. 11) Two libbpf v0.6 bug fixes, from Shuyi Cheng and Vincent Minet. 12) Deprecation warning fix for perf/bpf_counter, from Song Liu. 13) MAX_TAIL_CALL_CNT unification and MIPS build fix for libbpf, from Tiezhu Yang. 14) BTF_KING_TYPE_TAG follow-up fixes, from Yonghong Song. 15) Selftests fixes and improvements, from Ilya Leoshkevich, Jean-Philippe Brucker, Jiri Olsa, Maxim Mikityanskiy, Tirthendu Sarkar, Yucong Sun, and others. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (115 commits) libbpf: Add "bool skipped" to struct bpf_map libbpf: Fix typo in btf__dedup@LIBBPF_0.0.2 definition bpftool: Switch bpf_object__load_xattr() to bpf_object__load() selftests/bpf: Remove the only use of deprecated bpf_object__load_xattr() selftests/bpf: Add test for libbpf's custom log_buf behavior selftests/bpf: Replace all uses of bpf_load_btf() with bpf_btf_load() libbpf: Deprecate bpf_object__load_xattr() libbpf: Add per-program log buffer setter and getter libbpf: Preserve kernel error code and remove kprobe prog type guessing libbpf: Improve logging around BPF program loading libbpf: Allow passing user log setting through bpf_object_open_opts libbpf: Allow passing preallocated log_buf when loading BTF into kernel libbpf: Add OPTS-based bpf_btf_load() API libbpf: Fix bpf_prog_load() log_buf logic for log_level 0 samples/bpf: Remove unneeded variable bpf: Remove redundant assignment to pointer t selftests/bpf: Fix a compilation warning perf/bpf_counter: Use bpf_map_create instead of bpf_create_map samples: bpf: Fix 'unknown warning group' build warning on Clang samples: bpf: Fix xdp_sample_user.o linking with Clang ... ==================== Link: https://lore.kernel.org/r/20211210234746.2100561-1-andrii@kernel.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Shuyi Cheng authored
Fix error: "failed to pin map: Bad file descriptor, path: /sys/fs/bpf/_rodata_str1_1." In the old kernel, the global data map will not be created, see [0]. So we should skip the pinning of the global data map to avoid bpf_object__pin_maps returning error. Therefore, when the map is not created, we mark “map->skipped" as true and then check during relocation and during pinning. Fixes: 16e0c35c ("libbpf: Load global data maps lazily on legacy kernels") Signed-off-by:
Shuyi Cheng <chengshuyi@linux.alibaba.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org>
-
Vincent Minet authored
The btf__dedup_deprecated name was misspelled in the definition of the compat symbol for btf__dedup. This leads it to be missing from the shared library. This fixes it. Fixes: 957d350a ("libbpf: Turn btf_dedup_opts into OPTS-based struct") Signed-off-by:
Vincent Minet <vincent@vincent-minet.net> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211210063112.80047-1-vincent@vincent-minet.net
-
Alexei Starovoitov authored
Andrii Nakryiko says: ==================== Add new open options and per-program setters to control BTF and program loading log verboseness and allow providing custom log buffers to capture logs of interest. Note how custom log_buf and log_level are orthogonal, which matches previous (alas less customizable) behavior of libbpf, even though it sort of worked by accident: if someone specified log_level = 1 in bpf_object__load_xattr(), first attempt to load any BPF program resulted in wasted bpf() syscall with -EINVAL due to !!log_buf != !!log_level. Then on retry libbpf would allocated log_buffer and try again, after which prog loading would succeed and libbpf would print verbose program loading log through its print callback. This behavior is now documented and made more efficient, not wasting unnecessary syscall. But additionally, log_level can be controlled globally on a per-bpf_object level through bpf_object_open_opts, as well as on a per-program basis with bpf_program__set_log_buf() and bpf_program__set_log_level() APIs. Now that we have a more future-proof way to set log_level, deprecate bpf_object__load_xattr(). v2->v3: - added log_buf selftests for bpf_prog_load() and bpf_btf_load(); - fix !log_buf in bpf_prog_load (John); - fix log_level==0 in bpf_btf_load (thanks selftest!); v1->v2: - fix log_level == 0 handling of bpf_prog_load, add as patch #1 (Alexei); - add comments explaining log_buf_size overflow prevention (Alexei). ==================== Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org>
-
Andrii Nakryiko authored
Switch all the uses of to-be-deprecated bpf_object__load_xattr() into a simple bpf_object__load() calls with optional log_level passed through open_opts.kernel_log_level, if -d option is specified. Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-13-andrii@kernel.org
-
Andrii Nakryiko authored
Switch from bpf_object__load_xattr() to bpf_object__load() and kernel_log_level in bpf_object_open_opts. Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-12-andrii@kernel.org
-
Andrii Nakryiko authored
Add a selftest that validates that per-program and per-object log_buf overrides work as expected. Also test same logic for low-level bpf_prog_load() and bpf_btf_load() APIs. Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-11-andrii@kernel.org
-
Andrii Nakryiko authored
Switch all selftests uses of to-be-deprecated bpf_load_btf() with equivalent bpf_btf_load() calls. Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-10-andrii@kernel.org
-
Andrii Nakryiko authored
Deprecate non-extensible bpf_object__load_xattr() in v0.8 ([0]). With log_level control through bpf_object_open_opts or bpf_program__set_log_level(), we are finally at the point where bpf_object__load_xattr() doesn't provide any functionality that can't be accessed through other (better) ways. The other feature, target_btf_path, is also controllable through bpf_object_open_opts. [0] Closes: https://github.com/libbpf/libbpf/issues/289 Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-9-andrii@kernel.org
-
Andrii Nakryiko authored
Allow to set user-provided log buffer on a per-program basis ([0]). This gives great deal of flexibility in terms of which programs are loaded with logging enabled and where corresponding logs go. Log buffer set with bpf_program__set_log_buf() overrides kernel_log_buf and kernel_log_size settings set at bpf_object open time through bpf_object_open_opts, if any. Adjust bpf_object_load_prog_instance() logic to not perform own log buf allocation and load retry if custom log buffer is provided by the user. [0] Closes: https://github.com/libbpf/libbpf/issues/418 Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-8-andrii@kernel.org
-
Andrii Nakryiko authored
Instead of rewriting error code returned by the kernel of prog load with libbpf-sepcific variants pass through the original error. There is now also no need to have a backup generic -LIBBPF_ERRNO__LOAD fallback error as bpf_prog_load() guarantees that errno will be properly set no matter what. Also drop a completely outdated and pretty useless BPF_PROG_TYPE_KPROBE guess logic. It's not necessary and neither it's helpful in modern BPF applications. Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-7-andrii@kernel.org
-
Andrii Nakryiko authored
Add missing "prog '%s': " prefixes in few places and use consistently markers for beginning and end of program load logs. Here's an example of log output: libbpf: prog 'handler': BPF program load failed: Permission denied libbpf: -- BEGIN PROG LOAD LOG --- arg#0 reference type('UNKNOWN ') size cannot be determined: -22 ; out1 = in1; 0: (18) r1 = 0xffffc9000cdcc000 2: (61) r1 = *(u32 *)(r1 +0) ... 81: (63) *(u32 *)(r4 +0) = r5 R1_w=map_value(id=0,off=16,ks=4,vs=20,imm=0) R4=map_value(id=0,off=400,ks=4,vs=16,imm=0) invalid access to map value, value_size=16 off=400 size=4 R4 min value is outside of the allowed memory range processed 63 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 -- END PROG LOAD LOG -- libbpf: failed to load program 'handler' libbpf: failed to load object 'test_skeleton' The entire verifier log, including BEGIN and END markers are now always youtput during a single print callback call. This should make it much easier to post-process or parse it, if necessary. It's not an explicit API guarantee, but it can be reasonably expected to stay like that. Also __bpf_object__open is renamed to bpf_object_open() as it's always an adventure to find the exact function that implements bpf_object's open phase, so drop the double underscored and use internal libbpf naming convention. Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-6-andrii@kernel.org
-
Andrii Nakryiko authored
Allow users to provide their own custom log_buf, log_size, and log_level at bpf_object level through bpf_object_open_opts. This log_buf will be used during BTF loading. Subsequent patch will use same log_buf during BPF program loading, unless overriden at per-bpf_program level. When such custom log_buf is provided, libbpf won't be attempting retrying loading of BTF to try to provide its own log buffer to capture kernel's error log output. User is responsible to provide big enough buffer, otherwise they run a risk of getting -ENOSPC error from the bpf() syscall. See also comments in bpf_object_open_opts regarding log_level and log_buf interactions. Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-5-andrii@kernel.org
-
Andrii Nakryiko authored
Add libbpf-internal btf_load_into_kernel() that allows to pass preallocated log_buf and custom log_level to be passed into kernel during BPF_BTF_LOAD call. When custom log_buf is provided, btf_load_into_kernel() won't attempt an retry with automatically allocated internal temporary buffer to capture BTF validation log. It's important to note the relation between log_buf and log_level, which slightly deviates from stricter kernel logic. From kernel's POV, if log_buf is specified, log_level has to be > 0, and vice versa. While kernel has good reasons to request such "sanity, this, in practice, is a bit unconvenient and restrictive for libbpf's high-level bpf_object APIs. So libbpf will allow to set non-NULL log_buf and log_level == 0. This is fine and means to attempt to load BTF without logging requested, but if it failes, retry the load with custom log_buf and log_level 1. Similar logic will be implemented for program loading. In practice this means that users can provide custom log buffer just in case error happens, but not really request slower verbose logging all the time. This is also consistent with libbpf behavior when custom log_buf is not set: libbpf first tries to load everything with log_level=0, and only if error happens allocates internal log buffer and retries with log_level=1. Also, while at it, make BTF validation log more obvious and follow the log pattern libbpf is using for dumping BPF verifier log during BPF_PROG_LOAD. BTF loading resulting in an error will look like this: libbpf: BTF loading error: -22 libbpf: -- BEGIN BTF LOAD LOG --- magic: 0xeb9f version: 1 flags: 0x0 hdr_len: 24 type_off: 0 type_len: 1040 str_off: 1040 str_len: 2063598257 btf_total_size: 1753 Total section length too long -- END BTF LOAD LOG -- libbpf: Error loading .BTF into kernel: -22. BTF is optional, ignoring. This makes it much easier to find relevant parts in libbpf log output. Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-4-andrii@kernel.org
-
Andrii Nakryiko authored
Similar to previous bpf_prog_load() and bpf_map_create() APIs, add bpf_btf_load() API which is taking optional OPTS struct. Schedule bpf_load_btf() for deprecation in v0.8 ([0]). This makes naming consistent with BPF_BTF_LOAD command, sets up an API for extensibility in the future, moves options parameters (log-related fields) into optional options, and also allows to pass log_level directly. It also removes log buffer auto-allocation logic from low-level API (consistent with bpf_prog_load() behavior), but preserves a special treatment of log_level == 0 with non-NULL log_buf, which matches low-level bpf_prog_load() and high-level libbpf APIs for BTF and program loading behaviors. [0] Closes: https://github.com/libbpf/libbpf/issues/419 Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-3-andrii@kernel.org
-
Andrii Nakryiko authored
To unify libbpf APIs behavior w.r.t. log_buf and log_level, fix bpf_prog_load() to follow the same logic as bpf_btf_load() and high-level bpf_object__load() API will follow in the subsequent patches: - if log_level is 0 and non-NULL log_buf is provided by a user, attempt load operation initially with no log_buf and log_level set; - if successful, we are done, return new FD; - on error, retry the load operation with log_level bumped to 1 and log_buf set; this way verbose logging will be requested only when we are sure that there is a failure, but will be fast in the common/expected success case. Of course, user can still specify log_level > 0 from the very beginning to force log collection. Suggested-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211209193840.1248570-2-andrii@kernel.org
-
Ye Guojin authored
'sys/ioctl.h' included in 'mptcp_inq.c' is duplicated. Reported-by:
ZealRobot <zealci@zte.com.cn> Signed-off-by:
Ye Guojin <ye.guojin@zte.com.cn> Reviewed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Link: https://lore.kernel.org/r/20211210071424.425773-1-ye.guojin@zte.com.cn Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Steffen Klassert <steffen.klassert@secunet.com> Link: https://lore.kernel.org/r/20211209154451.4184050-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- Dec 10, 2021
-
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: netns refcount tracking, base series We have 100+ syzbot reports about netns being dismantled too soon, still unresolved as of today. We think a missing get_net() or an extra put_net() is the root cause. In order to find the bug(s), and be able to spot future ones, this patch adds CONFIG_NET_NS_REFCNT_TRACKER and new helpers to precisely pair all put_net() with corresponding get_net(). To use these helpers, each data structure owning a refcount should also use a "netns_tracker" to pair the get() and put(). Small sections of codes where the get()/put() are in sight do not need to have a tracker, because they are short lived, but in theory it is also possible to declare an on-stack tracker. v2: Include core networking patches only. ==================== Link: https://lore.kernel.org/r/20211210074426.279563-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
We have 100+ syzbot reports about netns being dismantled too soon, still unresolved as of today. We think a missing get_net() or an extra put_net() is the root cause. In order to find the bug(s), and be able to spot future ones, this patch adds CONFIG_NET_NS_REFCNT_TRACKER and new helpers to precisely pair all put_net() with corresponding get_net(). To use these helpers, each data structure owning a refcount should also use a "netns_tracker" to pair the get and put. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Geert Uytterhoeven authored
Use the dev_err_probe() helper, instead of open-coding the same operation. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/2576cc15bdbb5be636640f491bcc087a334e2c02.1638959463.git.geert+renesas@glider.be Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jean Sacren authored
'more' is checked first. When !more is checked immediately after that, it is always true. We should drop this check. Signed-off-by:
Jean Sacren <sakiwit@gmail.com> Acked-by:
Martin Schiller <ms@dev.tdt.de> Link: https://lore.kernel.org/r/20211208024732.142541-5-sakiwit@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
No conflicts. Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Kees Cook authored
Under both -Warray-bounds and the object_size sanitizer, the compiler is upset about accessing prev/next of sk_buff when the object it thinks it is coming from is sk_buff_head. The warning is a false positive due to the compiler taking a conservative approach, opting to warn at casting time rather than access time. However, in support of enabling -Warray-bounds globally (which has found many real bugs), arrange things for sk_buff so that the compiler can unambiguously see that there is no intention to access anything except prev/next. Introduce and cast to a separate struct sk_buff_list, which contains _only_ the first two fields, silencing the warnings: In file included from ./include/net/net_namespace.h:39, from ./include/linux/netdevice.h:37, from net/core/netpoll.c:17: net/core/netpoll.c: In function 'refill_skbs': ./include/linux/skbuff.h:2086:9: warning: array subscript 'struct sk_buff[0]' is partly outside array bounds of 'struct sk_buff_head[1]' [-Warray-bounds] 2086 | __skb_insert(newsk, next->prev, next, list); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/core/netpoll.c:49:28: note: while referencing 'skb_pool' 49 | static struct sk_buff_head skb_pool; | ^~~~~~~~ This change results in no executable instruction differences. Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20211207062758.2324338-1-keescook@chromium.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Russell King (Oracle) authored
The PHY settings table is supposed to be sorted by descending match priority - in other words, earlier entries are preferred over later entries. The order of 1000baseKX/Full and 1000baseT/Full is such that we prefer 1000baseKX/Full over 1000baseT/Full, but 1000baseKX/Full is a lot rarer than 1000baseT/Full, and thus is much less likely to be preferred. This causes phylink problems - it means a fixed link specifying a speed of 1G and full duplex gets an ethtool linkmode of 1000baseKX/Full rather than 1000baseT/Full as would be expected - and since we offer userspace a software emulation of a conventional copper PHY, we want to offer copper modes in preference to anything else. However, we do still want to allow the rarer modes as well. Hence, let's reorder these two modes to prefer copper. Tested-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reported-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/E1muvFO-00F6jY-1K@rmk-PC.armlinux.org.uk Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
xfrm4_fill_dst() and xfrm6_fill_dst() build dst, getting a device reference that will likely be released by standard dst_release() code. We have to track these references or risk a warning if CONFIG_NET_DEV_REFCNT_TRACKER=y Note to XFRM maintainers : Error path in xfrm6_fill_dst() releases the reference, but does not clear xdst->u.dst.dev, so I wonder if this could lead to double dev_put() in some cases, where a dst_release() _is_ called by the callers in their error path. This extra dev_put() was added in commit 84c4a9df ("xfrm6: release dev before returning error") Fixes: 9038c320 ("net: dst: add net device refcount tracking to dst_entry") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Cong Wang <amwang@redhat.com> Acked-by:
Steffen Klassert <steffen.klassert@secunet.com> Link: https://lore.kernel.org/r/20211207193203.2706158-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-