- 17 May, 2023 3 commits
-
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-6.5-20230515' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2023-05-15 The 1st patch is by Ji-Ze Hong and adds support for the Fintek F81604 USB-CAN adapter. Jiapeng Chong's patch removes unnecessary dev_err() functions from the bxcan driver. The next patch is by me an makes a CAN internal header file self contained. The remaining 19 patches are by Uwe Kleine-König, they all convert the platform driver remove callback to return void. * tag 'linux-can-next-for-6.5-20230515' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: (22 commits) can: xilinx: Convert to platform remove callback returning void can: ti_hecc: Convert to platform remove callback returning void can: sun4i_can: Convert to platform remove callback returning void can: softing: Convert to platform remove callback returning void can: sja1000_platform: Convert to platform remove callback returning void can: sja1000_isa: Convert to platform remove callback returning void can: rcar: Convert to platform remove callback returning void can: mscan: mpc5xxx_can: Convert to platform remove callback returning void can: m_can: Convert to platform remove callback returning void can: janz-ican3: Convert to platform remove callback returning void can: ifi_canfd: Convert to platform remove callback returning void can: grcan: Convert to platform remove callback returning void can: flexcan: Convert to platform remove callback returning void can: ctucanfd: Convert to platform remove callback returning void can: length: make header self contained can: cc770_platform: Convert to platform remove callback returning void can: bxcan: Remove unnecessary print function dev_err() can: cc770_isa: Convert to platform remove callback returning void can: usb: f81604: add Fintek F81604 support can: c_can: Convert to platform remove callback returning void ... ==================== Link: https://lore.kernel.org/r/20230515205759.1003118-1-mkl@pengutronix.deSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
This reverts commit b2cbac9b. We have multiple reports of obvious breakage from this patch. Reported-by:
Ido Schimmel <idosch@idosch.org> Link: https://lore.kernel.org/all/ZGIRWjNcfqI8yY8W@shredder/ Link: https://lore.kernel.org/all/CADJHv_sDK=0RrMA2FTZQV5fw7UQ+qY=HG21Wu5qb0V9vvx5w6A@mail.gmail.com/ Reported-by: syzbot+a5e719ac7c268e414c95@syzkaller.appspotmail.com Reported-by: syzbot+a03fd670838d927d9cd8@syzkaller.appspotmail.com Fixes: b2cbac9b ("net: Remove low_thresh in ip defrag") Link: https://lore.kernel.org/r/20230517034112.1261835-1-kuba@kernel.orgSigned-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2023-05-16 We've added 57 non-merge commits during the last 19 day(s) which contain a total of 63 files changed, 3293 insertions(+), 690 deletions(-). The main changes are: 1) Add precision propagation to verifier for subprogs and callbacks, from Andrii Nakryiko. 2) Improve BPF's {g,s}setsockopt() handling with wrong option lengths, from Stanislav Fomichev. 3) Utilize pahole v1.25 for the kernel's BTF generation to filter out inconsistent function prototypes, from Alan Maguire. 4) Various dyn-pointer verifier improvements to relax restrictions, from Daniel Rosenberg. 5) Add a new bpf_task_under_cgroup() kfunc for designated task, from Feng Zhou. 6) Unblock tests for arm64 BPF CI after ftrace supporting direct call, from Florent Revest. 7) Add XDP hint kfunc metadata for RX hash/timestamp for igc, from Jesper Dangaard Brouer. 8) Add several new dyn-pointer kfuncs to ease their usability, from Joanne Koong. 9) Add in-depth LRU internals description and dot function graph, from Joe Stringer. 10) Fix KCSAN report on bpf_lru_list when accessing node->ref, from Martin KaFai Lau. 11) Only dump unprivileged_bpf_disabled log warning upon write, from Kui-Feng Lee. 12) Extend test_progs to directly passing allow/denylist file, from Stephen Veiss. 13) Fix BPF trampoline memleak upon failure attaching to fentry, from Yafang Shao. 14) Fix emitting struct bpf_tcp_sock type in vmlinux BTF, from Yonghong Song. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (57 commits) bpf: Fix memleak due to fentry attach failure bpf: Remove bpf trampoline selector bpf, arm64: Support struct arguments in the BPF trampoline bpftool: JIT limited misreported as negative value on aarch64 bpf: fix calculation of subseq_idx during precision backtracking bpf: Remove anonymous union in bpf_kfunc_call_arg_meta bpf: Document EFAULT changes for sockopt selftests/bpf: Correctly handle optlen > 4096 selftests/bpf: Update EFAULT {g,s}etsockopt selftests bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen libbpf: fix offsetof() and container_of() to work with CO-RE bpf: Address KCSAN report on bpf_lru_list bpf: Add --skip_encoding_btf_inconsistent_proto, --btf_gen_optimized to pahole flags for v1.25 selftests/bpf: Accept mem from dynptr in helper funcs bpf: verifier: Accept dynptr mem as mem in helpers selftests/bpf: Check overflow in optional buffer selftests/bpf: Test allowing NULL buffer in dynptr slice bpf: Allow NULL buffers in bpf_dynptr_slice(_rw) selftests/bpf: Add testcase for bpf_task_under_cgroup bpf: Add bpf_task_under_cgroup() kfunc ... ==================== Link: https://lore.kernel.org/r/20230515225603.27027-1-daniel@iogearbox.netSigned-off-by:
-
- 16 May, 2023 7 commits
-
-
Paolo Abeni authored
Bagas Sanjaya says: ==================== SPDX conversion for bonding, 8390, and i825xx drivers This series is SPDX conversion for bonding, 8390, and i825xx driver subsystems. It is splitted from v2 of my SPDX conversion series in response to Didi's GPL full name fixes [1] to make it easily digestible. The conversion in this series is divided by each subsystem and by license type. [1]: https://lore.kernel.org/linux-spdx/20230512100620.36807-1-bagasdotme@gmail.com/ ==================== Link: https://lore.kernel.org/r/20230515060714.621952-1-bagasdotme@gmail.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Bagas Sanjaya authored
The boilerplate reads that sun3_8256 driver is an extension to Linux kernel core, hence add SPDX license identifier for GPL 2.0. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Michael Hipp <hippm@informatik.uni-tuebingen.de> Cc: Sam Creasey <sammy@sammy.net> Signed-off-by:
Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by:
-
Bagas Sanjaya authored
Replace unversioned GPL boilerplate notice with corresponding SPDX license identifier, which is GPL 1.0+. Cc: Donald Becker <becker@scyld.com> Cc: Richard Hirst <richard@sleepie.demon.co.uk> Cc: Sam Creasey <sammy@sammy.net> Signed-off-by:
-
Bagas Sanjaya authored
The boilerplate refers to COPYING in the top-level directory of kernel tree. Replace it with corresponding SPDX license identifier. Cc: Donald Becker <becker@scyld.com> Cc: Peter De Schrijver <p2@mind.be> Cc: Topi Kanerva <topi@susanna.oulu.fi> Cc: Alain Malek <Alain.Malek@cryogen.com> Cc: Bruce Abbott <bhabbott@inhb.co.nz> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Richard Fontana <rfontana@redhat.com> Acked-by:
Greg Ungerer <gerg@linux-m68k.org> Signed-off-by:
-
Bagas Sanjaya authored
Replace boilerplate notice for unversioned GPL to SPDX tag for GPL 1.0+. For ne2k-pci.c, only add SPDX tag and keep the boilerplate instead, since the boilerplate notes that it must be preserved. Cc: David A. Hinds <dahinds@users.sourceforge.net> Cc: Donald Becker <becker@scyld.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Richard Fontana <rfontana@redhat.com> Signed-off-by:
-
Bagas Sanjaya authored
Previous batches of SPDX conversion missed bond_main.c and bonding_priv.h because these files doesn't mention intended GPL version. Add SPDX identifier to these files, assuming GPL 1.0+. Cc: Thomas Davis <tadavis@lbl.gov> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Yunsheng Lin authored
__skb_fill_page_desc_noacc() is not doing any pfmemalloc propagating, and yet it has a comment about that, commit 84ce071e ("net: introduce __skb_fill_page_desc_noacc") may have accidentally moved it to __skb_fill_page_desc_noacc(), so move it back to __skb_fill_page_desc() which is supposed to be doing pfmemalloc propagating. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> CC: Pavel Begunkov <asml.silence@gmail.com> Reviewed-by:
Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/20230515050107.46397-1-linyunsheng@huawei.comSigned-off-by:
-
- 15 May, 2023 30 commits
-
-
Yafang Shao authored
If it fails to attach fentry, the allocated bpf trampoline image will be left in the system. That can be verified by checking /proc/kallsyms. This meamleak can be verified by a simple bpf program as follows: SEC("fentry/trap_init") int fentry_run() { return 0; } It will fail to attach trap_init because this function is freed after kernel init, and then we can find the trampoline image is left in the system by checking /proc/kallsyms. $ tail /proc/kallsyms ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf] ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf] $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'" [2522] FUNC 'trap_init' type_id=119 linkage=static $ echo $((6442453466 & 0x7fffffff)) 2522 Note that there are two left bpf trampoline images, that is because the libbpf will fallback to raw tracepoint if -EINVAL is returned. Fixes: e21aa341 ("bpf: Fix fexit trampoline.") Signed-off-by:Yafang Shao <laoar.shao@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Song Liu <song@kernel.org> Cc: Jiri Olsa <olsajiri@gmail.com> Link: https://lore.kernel.org/bpf/20230515130849.57502-2-laoar.shao@gmail.com
-
Marc Kleine-Budde authored
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> says: this series converts the drivers below drivers/net/can to the .remove_new() callback of struct platform_driver(). The motivation is to make the remove callback less prone for errors and wrong assumptions. See commit 5c5a7680 ("platform: Provide a remove callback that returns no value") for a more detailed rationale. All drivers already returned zero unconditionally in their .remove() callback, so converting them to .remove_new() is trivial. Link: https://lore.kernel.org/r/20230512212725.143824-1-u.kleine-koenig@pengutronix.deSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-20-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Gerhard Bertelsmann <info@gerhard-bertelsmann.de> Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20230512212725.143824-18-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert these drivers from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230512212725.143824-14-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Pavel Pisa <pisa@cmp.felk.cvut.cz> Link: https://lore.kernel.org/r/20230512212725.143824-7-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
Include the headers that "can/length.h" depends on. Fixes: bdd2e413 ("can: dev: move length related code into seperate file") Link: https://lore.kernel.org/all/20230509122854.350426-1-mkl@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Jiapeng Chong authored
The print function dev_err() is redundant because platform_get_irq_byname() already prints an error. ./drivers/net/can/bxcan.c:970:2-9: line 970 is redundant because platform_get_irq() already prints an error. ./drivers/net/can/bxcan.c:964:2-9: line 964 is redundant because platform_get_irq() already prints an error. ./drivers/net/can/bxcan.c:958:2-9: line 958 is redundant because platform_get_irq() already prints an error. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4878Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Ji-Ze Hong authored
This patch adds support for Fintek USB to 2CAN controller. Changelog: v7: https://lore.kernel.org/all/20230509073821.25289-1-peter_hong@fintek.com.tw 1. Fix consistency of coding style for "break" in f81604_register_urbs(). 2. Remove goto statement in f81604_open(). v6: https://lore.kernel.org/all/20230505022317.22417-1-peter_hong@fintek.com.tw 1. Remove non-used define and change constant mask to GENMASK(). 2. Move some variables declaration from function start to block start. 3. Move some variables initization into declaration. 4. Change variable "id" in f81604_start_xmit() only for CAN ID usage. v5: https://lore.kernel.org/all/20230420024403.13830-1-peter_hong@fintek.com.tw 1. Change all u8 *buff to struct f81604_int_data/f81604_can_frame. 2. Change all netdev->dev_id to netdev->dev_port. 3. Remove over design for f81604_process_rx_packet(). This device only report a frame at once, so the f81604_process_rx_packet() are reduced to process 1 frame. v4: https://lore.kernel.org/all/20230413084253.1524-1-peter_hong@fintek.com.tw 1. Remove f81604_prepare_urbs/f81604_remove_urbs() and alloc URB/buffer dynamically in f81604_register_urbs(), using "urbs_anchor" for manage all rx/int URBs. 2. Add F81604 to MAINTAINERS list. 3. Change handle_clear_reg_work/handle_clear_overrun_work to single clear_reg_work and using bitwise "clear_flags" to record it. 4. Move __f81604_set_termination in front of f81604_probe() to avoid rarely racing condition. 5. Add __aligned to struct f81604_int_data / f81604_sff / f81604_eff. 6. Add aligned operations in f81604_start_xmit/f81604_process_rx_packet(). 7. Change lots of CANBUS functions first parameter from struct usb_device* to struct f81604_port_priv *priv. But remain f81604_write / f81604_read / f81604_update_bits() as struct usb_device* for __f81604_set_termination() in probe() stage. 8. Simplify f81604_read_int_callback() and separate into f81604_handle_tx / f81604_handle_can_bus_errors() functions. v3: https://lore.kernel.org/all/20230327051048.11589-1-peter_hong@fintek.com.tw 1. Change CAN clock to using MEGA units. 2. Remove USB set/get retry, only remain SJA1000 reset/operation retry. 3. Fix all numberic constant to define. 4. Add terminator control. (only 0 & 120 ohm) 5. Using struct data to represent INT/TX/RX endpoints data instead byte arrays. 6. Error message reports changed from %d to %pe for mnemotechnic values. 7. Some bit operations are changed to FIELD_PREP(). 8. Separate TX functions from f81604_read_int_callback(). 9. cf->can_id |= CAN_ERR_CNT in f81604_read_int_callback to report valid TX/RX error counts. 10. Move f81604_prepare_urbs/f81604_remove_urbs() from CAN open/close() to USB probe/disconnect(). 11. coding style refactoring. v2: https://lore.kernel.org/all/20230321081152.26510-1-peter_hong@fintek.com.tw 1. coding style refactoring. 2. some const number are defined to describe itself. 3. fix wrong usage for can_get_echo_skb() in f81604_write_bulk_callback(). v1: https://lore.kernel.org/all/20230317093352.3979-1-peter_hong@fintek.com.twSigned-off-by:
Ji-Ze Hong (Peter Hong) <peter_hong@fintek.com.tw> Reviewed-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20230509073821.25289-1-peter_hong@fintek.com.tw [mkl: add changelog, fix printf format] Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20230512212725.143824-2-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Yafang Shao authored
After commit e21aa341 ("bpf: Fix fexit trampoline."), the selector is only used to indicate how many times the bpf trampoline image are updated and been displayed in the trampoline ksym name. After the trampoline is freed, the selector will start from 0 again. So the selector is a useless value to the user. We can remove it. If the user want to check whether the bpf trampoline image has been updated or not, the user can compare the address. Each time the trampoline image is updated, the address will change consequently. Jiri also pointed out another issue that perf is still using the old name "bpf_trampoline_%lu", so this change can fix the issue in perf. Fixes: e21aa341 ("bpf: Fix fexit trampoline.") Signed-off-by:
-
Florent Revest authored
This extends the BPF trampoline JIT to support attachment to functions that take small structures (up to 128bit) as argument. This is trivially achieved by saving/restoring a number of "argument registers" rather than a number of arguments. The AAPCS64 section 6.8.2 describes the parameter passing ABI. "Composite types" (like C structs) below 16 bytes (as enforced by the BPF verifier) are provided as part of the 8 argument registers as explained in the section C.12. Signed-off-by:
Florent Revest <revest@chromium.org> Signed-off-by:
Yonghong Song <yhs@fb.com> Acked-by:
Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/bpf/20230511140507.514888-1-revest@chromium.org
-
Alan Maguire authored
On aarch64, "bpftool feature" reports an incorrect BPF JIT limit: $ sudo /sbin/bpftool feature Scanning system configuration... bpf() syscall restricted to privileged users JIT compiler is enabled JIT compiler hardening is disabled JIT compiler kallsyms exports are enabled for root skipping kernel config, can't open file: No such file or directory Global memory limit for JIT compiler for unprivileged users is -201326592 bytes This is because /proc/sys/net/core/bpf_jit_limit reports $ sudo cat /proc/sys/net/core/bpf_jit_limit 68169519595520 ...and an int is assumed in read_procfs(). Change read_procfs() to return a long to avoid negative value reporting. Fixes: 7a4522bb ("tools: bpftool: add probes for /proc/ eBPF parameters") Reported-by:
Nicky Veitch <nicky.veitch@oracle.com> Signed-off-by:
Alan Maguire <alan.maguire@oracle.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Acked-by:
Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20230512113134.58996-1-alan.maguire@oracle.com
-
Andrii Nakryiko authored
Subsequent instruction index (subseq_idx) is an index of an instruction that was verified/executed by verifier after the currently processed instruction. It is maintained during precision backtracking processing and is used to detect various subprog calling conditions. This patch fixes the bug with incorrectly resetting subseq_idx to -1 when going from child state to parent state during backtracking. If we don't maintain correct subseq_idx we can misidentify subprog calls leading to precision tracking bugs. One such case was triggered by test_global_funcs/global_func9 test where global subprog call happened to be the very last instruction in parent state, leading to subseq_idx==-1, triggering WARN_ONCE: [ 36.045754] verifier backtracking bug [ 36.045764] WARNING: CPU: 13 PID: 2073 at kernel/bpf/verifier.c:3503 __mark_chain_precision+0xcc6/0xde0 [ 36.046819] Modules linked in: aesni_intel(E) crypto_simd(E) cryptd(E) kvm_intel(E) kvm(E) irqbypass(E) i2c_piix4(E) serio_raw(E) i2c_core(E) crc32c_intel) [ 36.048040] CPU: 13 PID: 2073 Comm: test_progs Tainted: G W OE 6.3.0-07976-g4d585f48-dirty #972 [ 36.048783] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 36.049648] RIP: 0010:__mark_chain_precision+0xcc6/0xde0 [ 36.050038] Code: 3d 82 c6 05 bb 35 32 02 01 e8 66 21 ec ff 0f 0b b8 f2 ff ff ff e9 30 f5 ff ff 48 c7 c7 f3 61 3d 82 4c 89 0c 24 e8 4a 21 ec ff <0f> 0b 4c0 With the fix precision tracking across multiple states works correctly now: mark_precise: frame0: last_idx 45 first_idx 38 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 44: (61) r7 = *(u32 *)(r10 -4) mark_precise: frame0: regs=r8 stack= before 43: (85) call pc+41 mark_precise: frame0: regs=r8 stack= before 42: (07) r1 += -48 mark_precise: frame0: regs=r8 stack= before 41: (bf) r1 = r10 mark_precise: frame0: regs=r8 stack= before 40: (63) *(u32 *)(r10 -48) = r1 mark_precise: frame0: regs=r8 stack= before 39: (b4) w1 = 0 mark_precise: frame0: regs=r8 stack= before 38: (85) call pc+38 mark_precise: frame0: parent state regs=r8 stack=: R0_w=scalar() R1_w=map_value(off=4,ks=4,vs=8,imm=0) R6=1 R7_w=scalar() R8_r=P0 R10=fpm mark_precise: frame0: last_idx 36 first_idx 28 subseq_idx 38 mark_precise: frame0: regs=r8 stack= before 36: (18) r1 = 0xffff888104f2ed14 mark_precise: frame0: regs=r8 stack= before 35: (85) call pc+33 mark_precise: frame0: regs=r8 stack= before 33: (18) r1 = 0xffff888104f2ed10 mark_precise: frame0: regs=r8 stack= before 32: (85) call pc+36 mark_precise: frame0: regs=r8 stack= before 31: (07) r1 += -4 mark_precise: frame0: regs=r8 stack= before 30: (bf) r1 = r10 mark_precise: frame0: regs=r8 stack= before 29: (63) *(u32 *)(r10 -4) = r7 mark_precise: frame0: regs=r8 stack= before 28: (4c) w7 |= w0 mark_precise: frame0: parent state regs=r8 stack=: R0_rw=scalar() R6=1 R7_rw=scalar() R8_rw=P0 R10=fp0 fp-48_r=mmmmmmmm mark_precise: frame0: last_idx 27 first_idx 16 subseq_idx 28 mark_precise: frame0: regs=r8 stack= before 27: (85) call pc+31 mark_precise: frame0: regs=r8 stack= before 26: (b7) r1 = 0 mark_precise: frame0: regs=r8 stack= before 25: (b7) r8 = 0 Note how subseq_idx starts out as -1, then is preserved as 38 and then 28 as we go up the parent state chain. Reported-by:
Alexei Starovoitov <ast@kernel.org> Fixes: fde2a388 ("bpf: support precision propagation in the presence of subprogs") Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20230515180710.1535018-1-andrii@kernel.orgSigned-off-by:
-
Dave Marchevsky authored
For kfuncs like bpf_obj_drop and bpf_refcount_acquire - which take user-defined types as input - the verifier needs to track the specific type passed in when checking a particular kfunc call. This requires tracking (btf, btf_id) tuple. In commit 7c50b1cb ("bpf: Add bpf_refcount_acquire kfunc") I added an anonymous union with inner structs named after the specific kfuncs tracking this information, with the goal of making it more obvious which kfunc this data was being tracked / expected to be tracked on behalf of. In a recent series adding a new user of this tuple, Alexei mentioned that he didn't like this union usage as it doesn't really help with readability or bug-proofing ([0]). In an offline convo we agreed to have the tuple be fields (arg_btf, arg_btf_id), with comments in bpf_kfunc_call_arg_meta definition enumerating the uses of the fields by kfunc-specific handling logic. Such a pattern is used by struct bpf_reg_state without trouble. Accordingly, this patch removes the anonymous union in favor of arg_btf and arg_btf_id fields and comment enumerating their current uses. The patch also removes struct btf_and_id, which was only being used by the removed union's inner structs. This is a mechanical change, existing linked_list and rbtree tests will validate that correct (btf, btf_id) are being passed. [0]: https://lore.kernel.org/bpf/20230505021707.vlyiwy57vwxglbka@dhcp-172-26-102-232.dhcp.thefacebook.comSigned-off-by:
Dave Marchevsky <davemarchevsky@fb.com> Link: https://lore.kernel.org/r/20230510213047.1633612-1-davemarchevsky@fb.comSigned-off-by:
-
Krzysztof Kozlowski authored
If sock->service_name is NULL, the local variable service_name_tlv_length will not be assigned by nfc_llcp_build_tlv(), later leading to using value frmo the stack. Smatch warning: net/nfc/llcp_commands.c:442 nfc_llcp_send_connect() error: uninitialized symbol 'service_name_tlv_length'. Fixes: de9e5aeb ("NFC: llcp: Fix usage of llcp_add_tlv()") Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
