summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-03-20tty: serial: 8250: Add some more device IDsCameron Williams
These card IDs got missed the first time around. Cc: stable <stable@kernel.org> Signed-off-by: Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DB7PR02MB380295BCC879CCF91315AC38C4C12@DB7PR02MB3802.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20dt-bindings: serial: samsung: add exynos7870-uart compatibleKaustabh Chakraborty
Document the compatible string for Exynos7870's UART driver. The devicetree property samsung,uart-fifosize must be mandatory, as the driver enquires about the FIFO sizes. This feature makes it compatible with Exynos8895's UART. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250219-exynos7870-uart-v2-1-c8c67f3a936c@disroot.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20serial: 8250_dw: Comment possible corner cases in serial_out() implementationAndy Shevchenko
8250 DesignWare driver uses a few custom implementations of the serial_out(). These implementations are carefully made to avoid infinite loops. But this is not obvious from looking at the code. Comment the possible corner cases in the respective functions. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250317094021.1201512-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20serial: switch change_irq and change_port to bool in uart_set_info()Jiri Slaby (SUSE)
change_irq and change_port are boolean variables. Mark them as such (instead of uint). Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-32-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20serial: 8250_port: simplify serial8250_request_std_resource()Jiri Slaby (SUSE)
Return immediately from the error locations or switch-case ends. It is therefore easier to see the flow. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-31-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20serial: 8250_port: do not use goto for UPQ_NO_TXEN_TEST code flowJiri Slaby (SUSE)
This is unnecessary here and makes the code harder to follow. Invert the condition and drop the goto+label. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-30-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20serial: 8250_rsa: simplify rsa8250_{request/release}_resource()Jiri Slaby (SUSE)
* Use already defined 'port' for fetching start/offset, and size. * Return from the switch immediately -- so it is clear what is returned and when. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-29-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20serial: 8250: use serial_port_in/out() helpersJiri Slaby (SUSE)
There are serial_port_in/out() helpers to be used instead of direct p->serial_in/out(). Use them in various 8250 drivers. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> -- [v2] * Use serial_port_in/out() and not serial_in/out() [Andy] Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # 8250_dw Link: https://lore.kernel.org/r/20250317070046.24386-28-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20serial: pass struct uart_state to uart_line_info()Jiri Slaby (SUSE)
uart_line_info() wants to work with struct uart_state. Do not pass a driver and an index. Pass the precomputed struct directly. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-27-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20serial: remove redundant tty_port_link_device()Jiri Slaby (SUSE)
The linking is done implicitly by tty_port_register_device_attr_serdev() few lines below. So drop this explicit tty_port_link_device(). Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-26-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: sunsu: remove unused serial_icr_read()Jiri Slaby (SUSE)
It is commented and never used. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Link: https://lore.kernel.org/r/20250317070046.24386-25-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: sunsu: drop serial_{in,out}p()Jiri Slaby (SUSE)
They are simple wrappers around serial_{in/out}() without actually pausing the execution. Since ever. So drop these useless wrappers. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Link: https://lore.kernel.org/r/20250317070046.24386-24-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: staging/greybus: pass tty_driver flags to tty_alloc_driver()Jiri Slaby (SUSE)
tty_alloc_driver() is supposed to receive tty driver flags. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Acked-by: Johan Hovold <johan@kernel.org> Cc: David Lin <dtwlin@gmail.com> Cc: Alex Elder <elder@kernel.org> Cc: greybus-dev@lists.linaro.org Cc: linux-staging@lists.linux.dev Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://lore.kernel.org/r/20250317070046.24386-23-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: srmcons: fix retval from srmcons_init()Jiri Slaby (SUSE)
The value returned from srmcons_init() was -ENODEV for over 2 decades. But it does not matter, given device_initcall() ignores retvals. But to be honest, return 0 in case the tty driver was registered properly. To do that, the condition is inverted and a short path taken in case of error. err_free_drv is introduced as it will be used from more places later. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Tested-by: Magnus Lindholm <linmag7@gmail.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Matt Turner <mattst88@gmail.com> Cc: linux-alpha@vger.kernel.org Link: https://lore.kernel.org/r/20250317070046.24386-22-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: moxa: carve out special ioctls and extra tty_portJiri Slaby (SUSE)
These ioctls are undocumented and not exposed -- they are defined locally. Given they need a special tty_port just for them, this is very ugly. So drop this whole functionality. It is barely used for something real. (And if it is, we'd need a common functionality to all drivers.) Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-21-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: moxa: drop ISA supportJiri Slaby (SUSE)
I doubt anyone actually uses this driver (unlike mxser.c and serial moxa driven devices). Even less there is anyone with a moxa ISA card. The newer mxser dropped the support for ISA in 2021. Let this moxa follow now. Good diet. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-20-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: moxa: drop version dump to logsJiri Slaby (SUSE)
The arbitrary MOXA_VERSION is dumped to the logs when the driver is loaded. Avoid this as a driver should be silent unless something breaks. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-19-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: mmc: sdio: use bool for cts and remove parenthesesJiri Slaby (SUSE)
'cts' in sdio_uart_check_modem_status() is considered a 'bool', but typed as signed 'int'. Make it 'bool' so it is clear the code does not care about the masked value, but true/false. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: linux-mmc@vger.kernel.org Link: https://lore.kernel.org/r/20250317070046.24386-18-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: serdev: drop serdev_controller_ops::write_room()Jiri Slaby (SUSE)
In particular, serdev_device_write_room() is not called, so the whole serdev's write_room() can go. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-17-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: tty_driver: introduce TTY driver sub/types enumsJiri Slaby (SUSE)
Convert TTY_DRIVER_TYPE_*, and subtype macros to two enums: tty_driver_type and tty_driver_subtype. This allows for easier kernel-doc (later), grouping of these nicely, and proper checking. The tty_driver's ::type and ::subtype now use these enums instead of bare "short". Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-16-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: tty_driver: document both {,__}tty_alloc_driver() properlyJiri Slaby (SUSE)
__tty_alloc_driver()'s kernel-doc needed some care: describe the return value using the standard "Returns:", and use the new enum tty_driver_flag for @flags. Then, the tty_alloc_driver() macro was undocumented, but referenced many times in the docs. Copy the docs from the above (except the @owner parameter, obviously). Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-15-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: tty_driver: convert "TTY Driver Flags" to an enumJiri Slaby (SUSE)
Convert TTY_DRIVER_* macros (flags) to an enum. This allows for easier kernel-doc (the comment needed fine tuning), grouping of these nicely, and proper checking. Given these are flags, define them using modern BIT() instead of hex constants. It turns out (thanks, kernel-doc checker) that internal TTY_DRIVER_INSTALLED was undocumented. Fix that too. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-14-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: tty_driver: move TTY macros to the topJiri Slaby (SUSE)
So that they can be referenced in structs once converted to enums (in the next patches). Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-13-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: n_tty: move more_to_be_read to the end of n_tty_read()Jiri Slaby (SUSE)
n_tty_read() contains "we need more data" handling deep in that function. And there is also a label (more_to_be_read) as we handle this situation from two places. It makes more sense to have all "return"s accumulated at the end of functions. And "goto" from multiple places there. Therefore, do this with the "more_to_be_read" label in n_tty_read(). After this and the previous changes, n_tty_read() is now much more easier to follow. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-12-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: n_tty: extract n_tty_wait_for_input()Jiri Slaby (SUSE)
n_tty_read() is a very long function doing too much of different stuff. Extract the "wait for input" to a separate function: n_tty_wait_for_input(). It returns an error (< 0), no input (0), or has potential input (1). Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-11-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: n_tty: extract n_tty_continue_cookie() from n_tty_read()Jiri Slaby (SUSE)
n_tty_read() is a very long function doing too much of different stuff. Extract the "cookie" (continuation read) handling to a separate function: n_tty_continue_cookie(). Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-10-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: n_tty: drop n_tty_trace()Jiri Slaby (SUSE)
This n_tty_trace() is an always disabled debugging macro. It comes from commit 32f13521ca68 ("n_tty: Line copy to user buffer in canonical mode"). Drop it as it is dead for over a decade. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-9-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: n_tty: clean up process_output_block()Jiri Slaby (SUSE)
* Use guard(mutex), which results in: - the function can return directly when "space == 0". - "i" can now be "unsigned" as it is no longer abused to hold a retval from tty->ops->write(). Note the compared-to "nr" is already "unsigned". * The end label is now dubbed "do_write" as that is what happens there. Unlike the uncertain "break_out" name. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-8-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: n_tty: simplify process_output()Jiri Slaby (SUSE)
Using guard(mutex), the function can be written in a much more efficient way. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-7-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: n_tty: use uint for space returned by tty_write_room()Jiri Slaby (SUSE)
tty_write_room() returns an "unsigned int". So in case some insane driver (like my tty test driver) returns (legitimate) UINT_MAX from its tty_operations::write_room(), n_tty is confused on several places. For example, in process_output_block(), the result of tty_write_room() is stored into (signed) "int". So this UINT_MAX suddenly becomes -1. And that is extended to ssize_t and returned from process_output_block(). This causes a write() to such a node to receive -EPERM (which is -1). Fix that by using proper "unsigned int" and proper "== 0" test. And return 0 constant directly in that "if", so that it is immediately clear what is returned ("space" equals to 0 at that point). Similarly for process_output() and __process_echoes(). Note this does not fix any in-tree driver as of now. If you want "Fixes: something", it would be commit 03b3b1a2405c ("tty: make tty_operations::write_room return uint"). I intentionally do not mark this patch by a real tag below. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-6-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: move N_TTY_BUF_SIZE to n_ttyJiri Slaby (SUSE)
"N_TTY_BUF_SIZE" is private to n_tty and shall not be exposed to the world. Definitely not in tty.h somewhere in the middle of "struct tty_struct". This is a remnant of moving "read_flags" to "struct n_tty_data" in commit 3fe780b379fa ("TTY: move ldisc data from tty_struct: bitmaps"). But some cleanup was needed first (in previous patches). Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-5-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: caif: do not use N_TTY_BUF_SIZEJiri Slaby (SUSE)
N_TTY_BUF_SIZE -- as the name suggests -- is the N_TTY's buffer size. There is no reason to couple that to caif's tty->receive_room. Use 4096 directly -- even though, it should be some sort of "SKB_MAX_ALLOC" or alike. But definitely not N_TTY_BUF_SIZE. N_TTY_BUF_SIZE is private and will be moved to n_tty.c later. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Acked-by: Jakub Kicinski <kuba@kernel.org> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: David S. Miller <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20250317070046.24386-4-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: audit: do not use N_TTY_BUF_SIZEJiri Slaby (SUSE)
N_TTY_BUF_SIZE -- as the name suggests -- is the N_TTY's buffer size. There is no reason to couple that to audit's buffer size, so define an own TTY_AUDIT_BUF_SIZE macro (with the same size). N_TTY_BUF_SIZE is private and will be moved to n_tty.c later. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20tty: convert "TTY Struct Flags" to an enumJiri Slaby (SUSE)
Convert TTY_* macros (flags) to an enum. This allows for easier kernel-doc (the comment needed fine tuning), grouping of these nicely, and proper checking. Note that these are bit positions. So they are used such as test_bit(TTY_THROTTLED, ...). Given these are not the user API (only in-kernel API/ABI), the bit positions are NOT preserved in this patch. All are renumbered naturally using the enum-auto-numbering. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250317070046.24386-2-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20MAINTAINERS: Add Andrea Mayer as a maintainer of SRv6David Ahern
Andrea has made significant contributions to SRv6 support in Linux. Acknowledge the work and on-going interest in Srv6 support with a maintainers entry for these files so hopefully he is included on patches going forward. Signed-off-by: David Ahern <dsahern@kernel.org> Acked-by: Andrea Mayer <andrea.mayer@uniroma2.it> Link: https://patch.msgid.link/20250312092212.46299-1-dsahern@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-20printk/panic: Add option to allow non-panic CPUs to write to the ring buffer.Donghyeok Choe
Commit 779dbc2e78d7 ("printk: Avoid non-panic CPUs writing to ringbuffer") aimed to isolate panic-related messages. However, when panic() itself malfunctions, messages from non-panic CPUs become crucial for debugging. While commit bcc954c6caba ("printk/panic: Allow cpu backtraces to be written into ringbuffer during panic") enables non-panic CPU backtraces, it may not provide sufficient diagnostic information. Introduce the "debug_non_panic_cpus" command-line option, enabling non-panic CPU messages to be stored in the ring buffer during a panic. This also prevents discarding non-finalized messages from non-panic CPUs during console flushing, providing a more comprehensive view of system state during critical failures. Link: https://lore.kernel.org/all/Z8cLEkqLL2IOyNIj@pathway/ Signed-off-by: Donghyeok Choe <d7271.choe@samsung.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20250318022320.2428155-1-d7271.choe@samsung.com [pmladek@suse.com: Added documentation, added module_parameter, removed printk_ prefix.] Tested-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com>
2025-03-20Merge branch 'gre-revert-ipv6-link-local-address-fix'Paolo Abeni
Guillaume Nault says: ==================== gre: Revert IPv6 link-local address fix. Following Paolo's suggestion, let's revert the IPv6 link-local address generation fix for GRE devices. The patch introduced regressions in the upstream CI, which are still under investigation. Start by reverting the kselftest that depend on that fix (patch 1), then revert the kernel code itself (patch 2). ==================== Link: https://patch.msgid.link/cover.1742418408.git.gnault@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-20Revert "gre: Fix IPv6 link-local address generation."Guillaume Nault
This reverts commit 183185a18ff96751db52a46ccf93fff3a1f42815. This patch broke net/forwarding/ip6gre_custom_multipath_hash.sh in some circumstances (https://lore.kernel.org/netdev/Z9RIyKZDNoka53EO@mini-arch/). Let's revert it while the problem is being investigated. Fixes: 183185a18ff9 ("gre: Fix IPv6 link-local address generation.") Signed-off-by: Guillaume Nault <gnault@redhat.com> Link: https://patch.msgid.link/8b1ce738eb15dd841aab9ef888640cab4f6ccfea.1742418408.git.gnault@redhat.com Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-20Revert "selftests: Add IPv6 link-local address generation tests for GRE ↵Guillaume Nault
devices." This reverts commit 6f50175ccad4278ed3a9394c00b797b75441bd6e. Commit 183185a18ff9 ("gre: Fix IPv6 link-local address generation.") is going to be reverted. So let's revert the corresponding kselftest first. Signed-off-by: Guillaume Nault <gnault@redhat.com> Link: https://patch.msgid.link/259a9e98f7f1be7ce02b53d0b4afb7c18a8ff747.1742418408.git.gnault@redhat.com Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-20rust: platform: require Send for Driver trait implementersDanilo Krummrich
The instance of Self, returned and created by Driver::probe() is dropped in the bus' remove() callback. Request implementers of the Driver trait to implement Send, since the remove() callback is not guaranteed to run from the same thread as probe(). Fixes: 683a63befc73 ("rust: platform: add basic platform device / driver abstractions") Cc: stable <stable@kernel.org> Reported-by: Alice Ryhl <aliceryhl@google.com> Closes: https://lore.kernel.org/lkml/Z9rDxOJ2V2bPjj5i@google.com/ Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250319145350.69543-2-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20rust: pci: require Send for Driver trait implementersDanilo Krummrich
The instance of Self, returned and created by Driver::probe() is dropped in the bus' remove() callback. Request implementers of the Driver trait to implement Send, since the remove() callback is not guaranteed to run from the same thread as probe(). Fixes: 1bd8b6b2c5d3 ("rust: pci: add basic PCI device / driver abstractions") Cc: stable <stable@kernel.org> Reported-by: Alice Ryhl <aliceryhl@google.com> Closes: https://lore.kernel.org/lkml/Z9rDxOJ2V2bPjj5i@google.com/ Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250319145350.69543-1-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-20Merge tag 'ipsec-2025-03-19' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2025-03-19 1) Fix tunnel mode TX datapath in packet offload mode by directly putting it to the xmit path. From Alexandre Cassen. 2) Force software GSO only in tunnel mode in favor of potential HW GSO. From Cosmin Ratiu. ipsec-2025-03-19 * tag 'ipsec-2025-03-19' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: xfrm_output: Force software GSO only in tunnel mode xfrm: fix tunnel mode TX datapath in packet offload mode ==================== Link: https://patch.msgid.link/20250319065513.987135-1-steffen.klassert@secunet.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-20Merge patch series "pidfs: handle multi-threaded exec and premature ↵Christian Brauner
thread-group leader exit" Christian Brauner <brauner@kernel.org> says: This is another attempt at trying to make pidfd polling for multi-threaded exec and premature thread-group leader exit consistent. A quick recap of these two cases: (1) During a multi-threaded exec by a subthread, i.e., non-thread-group leader thread, all other threads in the thread-group including the thread-group leader are killed and the struct pid of the thread-group leader will be taken over by the subthread that called exec. IOW, two tasks change their TIDs. (2) A premature thread-group leader exit means that the thread-group leader exited before all of the other subthreads in the thread-group have exited. Both cases lead to inconsistencies for pidfd polling with PIDFD_THREAD. Any caller that holds a PIDFD_THREAD pidfd to the current thread-group leader may or may not see an exit notification on the file descriptor depending on when poll is performed. If the poll is performed before the exec of the subthread has concluded an exit notification is generated for the old thread-group leader. If the poll is performed after the exec of the subthread has concluded no exit notification is generated for the old thread-group leader. The correct behavior would be to simply not generate an exit notification on the struct pid of a subhthread exec because the struct pid is taken over by the subthread and thus remains alive. But this is difficult to handle because a thread-group may exit premature as mentioned in (2). In that case an exit notification is reliably generated but the subthreads may continue to run for an indeterminate amount of time and thus also may exec at some point. This tiny series tries to address this problem. If that works correctly then no exit notifications are generated for a PIDFD_THREAD pidfd for a thread-group leader until all subthreads have been reaped. If a subthread should exec before no exit notification will be generated until that task exits or it creates subthreads and repeates the cycle. * patches from https://lore.kernel.org/r/20250320-work-pidfs-thread_group-v4-0-da678ce805bf@kernel.org: selftests/pidfd: third test for multi-threaded exec polling selftests/pidfd: second test for multi-threaded exec polling selftests/pidfd: first test for multi-threaded exec polling pidfs: improve multi-threaded exec and premature thread-group leader exit polling Link: https://lore.kernel.org/r/20250320-work-pidfs-thread_group-v4-0-da678ce805bf@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-03-20selftests/pidfd: third test for multi-threaded exec pollingChristian Brauner
Ensure that during a multi-threaded exec and premature thread-group leader exit no exit notification is generated. Link: https://lore.kernel.org/r/20250320-work-pidfs-thread_group-v4-4-da678ce805bf@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-03-20selftests/pidfd: second test for multi-threaded exec pollingChristian Brauner
Ensure that during a multi-threaded exec and premature thread-group leader exit no exit notification is generated. Link: https://lore.kernel.org/r/20250320-work-pidfs-thread_group-v4-3-da678ce805bf@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-03-20selftests/pidfd: first test for multi-threaded exec pollingChristian Brauner
Add first test for premature thread-group leader exit. Link: https://lore.kernel.org/r/20250320-work-pidfs-thread_group-v4-2-da678ce805bf@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-03-20pidfs: improve multi-threaded exec and premature thread-group leader exit ↵Christian Brauner
polling This is another attempt trying to make pidfd polling for multi-threaded exec and premature thread-group leader exit consistent. A quick recap of these two cases: (1) During a multi-threaded exec by a subthread, i.e., non-thread-group leader thread, all other threads in the thread-group including the thread-group leader are killed and the struct pid of the thread-group leader will be taken over by the subthread that called exec. IOW, two tasks change their TIDs. (2) A premature thread-group leader exit means that the thread-group leader exited before all of the other subthreads in the thread-group have exited. Both cases lead to inconsistencies for pidfd polling with PIDFD_THREAD. Any caller that holds a PIDFD_THREAD pidfd to the current thread-group leader may or may not see an exit notification on the file descriptor depending on when poll is performed. If the poll is performed before the exec of the subthread has concluded an exit notification is generated for the old thread-group leader. If the poll is performed after the exec of the subthread has concluded no exit notification is generated for the old thread-group leader. The correct behavior would be to simply not generate an exit notification on the struct pid of a subhthread exec because the struct pid is taken over by the subthread and thus remains alive. But this is difficult to handle because a thread-group may exit prematurely as mentioned in (2). In that case an exit notification is reliably generated but the subthreads may continue to run for an indeterminate amount of time and thus also may exec at some point. So far there was no way to distinguish between (1) and (2) internally. This tiny series tries to address this problem by discarding PIDFD_THREAD notification on premature thread-group leader exit. If that works correctly then no exit notifications are generated for a PIDFD_THREAD pidfd for a thread-group leader until all subthreads have been reaped. If a subthread should exec aftewards no exit notification will be generated until that task exits or it creates subthreads and repeates the cycle. Co-Developed-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20250320-work-pidfs-thread_group-v4-1-da678ce805bf@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-03-20Merge tag 'batadv-net-pullrequest-20250318' of ↵Paolo Abeni
git://git.open-mesh.org/linux-merge Simon Wunderlich says: ==================== Here is batman-adv bugfix: - Ignore own maximum aggregation size during RX, Sven Eckelmann * tag 'batadv-net-pullrequest-20250318' of git://git.open-mesh.org/linux-merge: batman-adv: Ignore own maximum aggregation size during RX ==================== Link: https://patch.msgid.link/20250318150035.35356-1-sw@simonwunderlich.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-20net/neighbor: add missing policy for NDTPA_QUEUE_LENBYTESLin Ma
Previous commit 8b5c171bb3dc ("neigh: new unresolved queue limits") introduces new netlink attribute NDTPA_QUEUE_LENBYTES to represent approximative value for deprecated QUEUE_LEN. However, it forgot to add the associated nla_policy in nl_ntbl_parm_policy array. Fix it with one simple NLA_U32 type policy. Fixes: 8b5c171bb3dc ("neigh: new unresolved queue limits") Signed-off-by: Lin Ma <linma@zju.edu.cn> Link: https://patch.msgid.link/20250315165113.37600-1-linma@zju.edu.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-20fs: sort out fd allocation vs dup2 race commentary, take 2Mateusz Guzik
fd_install() has a questionable comment above it. While it correctly points out a possible race against dup2(), it states: > We need to detect this and fput() the struct file we are about to > overwrite in this case. > > It should never happen - if we allow dup2() do it, _really_ bad things > will follow. I have difficulty parsing the above. The first sentence would suggest fd_install() tries to detect and recover from the race (it does not), the next one claims the race needs to be dealt with (it is, by dup2()). Given that fd_install() does not suffer the burden, this patch removes the above and instead expands on the race in dup2() commentary. While here tidy up the docs around fd_install(). Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://lore.kernel.org/r/20250320102637.1924183-1-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-19 14:41:57 +0000