kernel/linux.git/net/tipc/link.c, branch v6.19.11

tipc: adjust tipc_nodeid2string() to return string length

2025-09-30T09:22:39+00:00

Since the value returned by 'tipc_nodeid2string()' is not used, the function may be adjusted to return the length of the result, which is helpful to drop a few calls to 'strlen()' in 'tipc_link_create()' and 'tipc_link_bc_create()'. Compile tested only. Signed-off-by: Dmitry Antipov Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250926074113.914399-1-dmantipov@yandex.ru Signed-off-by: Paolo Abeni

tipc: Removing deprecated strncpy()

2025-04-15T11:37:14+00:00

This patch suggests the replacement of strncpy with strscpy as per Documentation/process/deprecated. The strncpy() fails to guarantee NULL termination, The function adds zero pads which isn't really convenient for short strings as it may cause performance issues. strscpy() is a preferred replacement because it overcomes the limitations of strncpy mentioned above. Compile Tested Signed-off-by: Kevin Paul Reddy Janagari Reviewed-by: Tung Nguyen Tested-by: Tung Nguyen Link: https://patch.msgid.link/20250411085010.6249-1-kevinpaul468@gmail.com Signed-off-by: Paolo Abeni

tipc: fix memory leak in tipc_link_xmit

2025-04-08T08:15:33+00:00

In case the backlog transmit queue for system-importance messages is overloaded, tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to memory leak and failure when a skb is allocated. This commit fixes this issue by purging the skb list before tipc_link_xmit() returns. Fixes: 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") Signed-off-by: Tung Nguyen Link: https://patch.msgid.link/20250403092431.514063-1-tung.quang.nguyen@est.tech Signed-off-by: Paolo Abeni

tipc: Reduce scope for the variable “fdefq” in tipc_link_tnl_prepare()

2025-03-05T01:19:49+00:00

The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “tipc_link_tnl_prepare”. Thus avoid the risk for undefined behaviour by moving the definition for the local variable “fdefq” into an if branch at the end. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring Link: https://patch.msgid.link/08fe8fc3-19c3-4324-8719-0ee74b0f32c9@web.de Signed-off-by: Jakub Kicinski

tipc: Consolidate redundant functions

2024-07-12T02:47:43+00:00

link_is_up() and tipc_link_is_up() have the same functionality. Consolidate these functions. Signed-off-by: Shigeru Yoshida Reviewed-by: Tung Nguyen Signed-off-by: David S. Miller

tipc: Remove some excess struct member documentation

2023-12-22T23:14:43+00:00

Remove documentation for nonexistent struct members, addressing these warnings: ./net/tipc/link.c:228: warning: Excess struct member 'media_addr' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'timer' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'refcnt' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'proto_msg' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'pmsg' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'backlog_limit' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'exp_msg_count' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'reset_rcv_checkpt' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'transmitq' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'snt_nxt' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'deferred_queue' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'unacked_window' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'next_out' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'long_msg_seq_no' description in 'tipc_link' ./net/tipc/link.c:228: warning: Excess struct member 'bc_rcvr' description in 'tipc_link' Signed-off-by: Jonathan Corbet Reviewed-by: Randy Dunlap Signed-off-by: David S. Miller

tipc: Use size_add() in calls to struct_size()

2023-09-18T08:38:32+00:00

If, for any reason, the open-coded arithmetic causes a wraparound, the protection that `struct_size()` adds against potential integer overflows is defeated. Fix this by hardening call to `struct_size()` with `size_add()`. Fixes: e034c6d23bc4 ("tipc: Use struct_size() helper") Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Signed-off-by: David S. Miller

minmax: add in_range() macro

2023-08-24T23:20:18+00:00

Patch series "New page table range API", v6. This patchset changes the API used by the MM to set up page table entries. The four APIs are: set_ptes(mm, addr, ptep, pte, nr) update_mmu_cache_range(vma, addr, ptep, nr) flush_dcache_folio(folio) flush_icache_pages(vma, page, nr) flush_dcache_folio() isn't technically new, but no architecture implemented it, so I've done that for them. The old APIs remain around but are mostly implemented by calling the new interfaces. The new APIs are based around setting up N page table entries at once. The N entries belong to the same PMD, the same folio and the same VMA, so ptep++ is a legitimate operation, and locking is taken care of for you. Some architectures can do a better job of it than just a loop, but I have hesitated to make too deep a change to architectures I don't understand well. One thing I have changed in every architecture is that PG_arch_1 is now a per-folio bit instead of a per-page bit when used for dcache clean/dirty tracking. This was something that would have to happen eventually, and it makes sense to do it now rather than iterate over every page involved in a cache flush and figure out if it needs to happen. The point of all this is better performance, and Fengwei Yin has measured improvement on x86. I suspect you'll see improvement on your architecture too. Try the new will-it-scale test mentioned here: https://lore.kernel.org/linux-mm/20230206140639.538867-5-fengwei.yin@intel.com/ You'll need to run it on an XFS filesystem and have CONFIG_TRANSPARENT_HUGEPAGE set. This patchset is the basis for much of the anonymous large folio work being done by Ryan, so it's received quite a lot of testing over the last few months. This patch (of 38): Determine if a value lies within a range more efficiently (subtraction + comparison vs two comparisons and an AND). It also has useful (under some circumstances) behaviour if the range exceeds the maximum value of the type. Convert all the conflicting definitions of in_range() within the kernel; some can use the generic definition while others need their own definition. Link: https://lkml.kernel.org/r/20230802151406.3735276-1-willy@infradead.org Link: https://lkml.kernel.org/r/20230802151406.3735276-2-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Andrew Morton

tipc: do not update mtu if msg_max is too small in mtu negotiation

2023-05-15T09:21:20+00:00

When doing link mtu negotiation, a malicious peer may send Activate msg with a very small mtu, e.g. 4 in Shuang's testing, without checking for the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then n->links[bearer_id].mtu is set to 4294967228, which is a overflow of '4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss(). With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4! And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in named_distribute(), and when purging it in tipc_link_xmit(), a crash was even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0 This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(), and not updating mtu if it is too small. Fixes: ed193ece2649 ("tipc: simplify link mtu negotiation") Reported-by: Shuang Li Signed-off-by: Xin Long Acked-by: Jon Maloy Signed-off-by: David S. Miller

tipc: Fix potential OOB in tipc_link_proto_rcv()

2022-12-06T11:58:38+00:00

Fix the potential risk of OOB if skb_linearize() fails in tipc_link_proto_rcv(). Fixes: 5cbb28a4bf65 ("tipc: linearize arriving NAME_DISTR and LINK_PROTO buffers") Signed-off-by: YueHaibing Link: https://lore.kernel.org/r/20221203094635.29024-1-yuehaibing@huawei.com Signed-off-by: Paolo Abeni