Changes in Makefile

06e6bc1b - tipc: rename the module name diag to tipc_diag

Fri, 02 Feb 2024 20:11:09 +0000

tipc: rename the module name diag to tipc_diagIt is not appropriate for TIPC to use "diag" as its diag module namewhile the other protocols are using "$(protoname)_diag" like tcp_diag,udp_diag and sctp_diag etc.So this patch is to rename diag.ko to tipc_diag.ko in tipc's Makefile.Signed-off-by: Xin Long Reviewed-by: Tung Nguyen Link: https://lore.kernel.org/r/d909edeef072da1810bd5869fdbbfe84411efdb2.1706904669.git.lucien.xin@gmail.comSigned-off-by: Paolo Abeni List of files: /linux-6.15/net/tipc/Makefile

b969fee1 - tipc: remove meaningless assignment in Makefile

Mon, 06 Jan 2020 07:35:27 +0000

tipc: remove meaningless assignment in MakefileThere is no module named tipc_diag.The assignment to tipc_diag-y has no effect.Signed-off-by: Masahiro Yamada Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

ea04b445 - tipc: do not add socket.o to tipc-y twice

Mon, 06 Jan 2020 07:35:26 +0000

tipc: do not add socket.o to tipc-y twicenet/tipc/Makefile adds socket.o twice.tipc-y += addr.o bcast.o bearer.o \ core.o link.o discover.o msg.o \ name_distr.o subscr.o monitor.o name_table.o net.o \ netlink.o netlink_compat.o node.o socket.o eth_media.o \ ^^^^^^^^ topsrv.o socket.o group.o trace.o ^^^^^^^^Signed-off-by: Masahiro Yamada Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

fc1b6d6d - tipc: introduce TIPC encryption & authentication

Fri, 08 Nov 2019 05:05:11 +0000

tipc: introduce TIPC encryption & authenticationThis commit offers an option to encrypt and authenticate all messaging,including the neighbor discovery messages. The currently most advancedalgorithm supported is the AEAD AES-GCM (like IPSec or TLS). Allencryption/decryption is done at the bearer layer, just before leavingor after entering TIPC.Supported features:- Encryption & authentication of all TIPC messages (header + data);- Two symmetric-key modes: Cluster and Per-node;- Automatic key switching;- Key-expired revoking (sequence number wrapped);- Lock-free encryption/decryption (RCU);- Asynchronous crypto, Intel AES-NI supported;- Multiple cipher transforms;- Logs & statistics;Two key modes:- Cluster key mode: One single key is used for both TX & RX in allnodes in the cluster.- Per-node key mode: Each nodes in the cluster has one specific TX key.For RX, a node requires its peers' TX key to be able to decrypt themessages from those peers.Key setting from user-space is performed via netlink by a user program(e.g. the iproute2 'tipc' tool).Internal key state machine: Attach Align(RX) +-+ +-+ | V | V +---------+ Attach +---------+ | IDLE |---------------->| PENDING |(user = 0) +---------+ +---------+ A A Switch| A | | | | | | Free(switch/revoked) | | (Free)| +----------------------+ | |Timeout | (TX) | | |(RX) | | | | | | v | +---------+ Switch +---------+ | PASSIVE |<----------------| ACTIVE | +---------+ (RX) +---------+ (user = 1) (user >= 1)The number of TFMs is 10 by default and can be changed via the procfs'net/tipc/max_tfms'. At this moment, as for simplicity, this file isalso used to print the crypto statistics at runtime:echo 0xfff1 > /proc/sys/net/tipc/max_tfmsThe patch defines a new TIPC version (v7) for the encryption message (-backward compatibility as well). The message is basically encapsulatedas follows: +----------------------------------------------------------+ | TIPCv7 encryption | Original TIPCv2 | Authentication | | header | packet (encrypted) | Tag | +----------------------------------------------------------+The throughput is about ~40% for small messages (compared with non-encryption) and ~9% for large messages. With the support from hardwarecrypto i.e. the Intel AES-NI CPU instructions, the throughput increasesupto ~85% for small messages and ~55% for large messages.By default, the new feature is inactive (i.e. no encryption) until usersets a key for TIPC. There is however also a new option - "TIPC_CRYPTO"in the kernel configuration to enable/disable the new code when needed.MAINTAINERS | add two new files 'crypto.h' & 'crypto.c' in tipcAcked-by: Ying Xue Acked-by: Jon Maloy Signed-off-by: Tuong Lien Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

b4b9771b - tipc: enable tracepoints in tipc

Wed, 19 Dec 2018 02:17:56 +0000

tipc: enable tracepoints in tipcAs for the sake of debugging/tracing, the commit enables tracepoints inTIPC along with some general trace_events as shown below. It alsodefines some 'tipc_*_dump()' functions that allow to dump TIPC objectdata whenever needed, that is, for general debug purposes, ie. not justfor the trace_events.The following trace_events are now available:- trace_tipc_skb_dump(): allows to trace and dump TIPC msg & skb data, e.g. message type, user, droppable, skb truesize, cloned skb, etc.- trace_tipc_list_dump(): allows to trace and dump any TIPC buffers or queues, e.g. TIPC link transmq, socket receive queue, etc.- trace_tipc_sk_dump(): allows to trace and dump TIPC socket data, e.g. sk state, sk type, connection type, rmem_alloc, socket queues, etc.- trace_tipc_link_dump(): allows to trace and dump TIPC link data, e.g. link state, silent_intv_cnt, gap, bc_gap, link queues, etc.- trace_tipc_node_dump(): allows to trace and dump TIPC node data, e.g. node state, active links, capabilities, link entries, etc.How to use:Put the trace functions at any places where we want to dump TIPC dataor events.Note:a) The dump functions will generate raw data only, that is, to offloadthe trace event's processing, it can require a tool or script to parsethe data but this should be simple.b) The trace_tipc_*_dump() should be reserved for a failure cases only(e.g. the retransmission failure case) or where we do not expect tohappen too often, then we can consider enabling these events by defaultsince they will almost not take any effects under normal conditions,but once the rare condition or failure occurs, we get the dumped datafully for post-analysis.For other trace purposes, we can reuse these trace classes as templatebut different events.c) A trace_event is only effective when we enable it. To enable theTIPC trace_events, echo 1 to 'enable' files in the events/tipc/directory in the 'debugfs' file system. Normally, they are located at:/sys/kernel/debug/tracing/events/tipc/For example:To enable the tipc_link_dump event:echo 1 > /sys/kernel/debug/tracing/events/tipc/tipc_link_dump/enableTo enable all the TIPC trace_events:echo 1 > /sys/kernel/debug/tracing/events/tipc/enableTo collect the trace data:cat traceorcat trace_pipe > /trace.out &To disable all the TIPC trace_events:echo 0 > /sys/kernel/debug/tracing/events/tipc/enableTo clear the trace buffer:echo > traced) Like the other trace_events, the feature like 'filter' or 'trigger'is also usable for the tipc trace_events.For more details, have a look at:Documentation/trace/ftrace.txtMAINTAINERS | add two new files 'trace.h' & 'trace.c' in tipcAcked-by: Ying Xue Tested-by: Ying Xue Acked-by: Jon Maloy Signed-off-by: Tuong Lien Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

c30b70de - tipc: implement socket diagnostics for AF_TIPC

Wed, 21 Mar 2018 13:37:44 +0000

tipc: implement socket diagnostics for AF_TIPCThis commit adds socket diagnostics capability for AF_TIPC in netlinkfamily NETLINK_SOCK_DIAG in a new kernel module (diag.ko).The following are key design considerations:- config TIPC_DIAG has default y, like INET_DIAG.- only requests with flag NLM_F_DUMP is supported (dump all).- tipc_sock_diag_req message is introduced to send filter parameters.- the response attributes are of TLV, some nested.To avoid exposing data structures between diag and tipc modules andavoid code duplication, the following additions are required:- export tipc_nl_sk_walk function to reuse socket iterator.- export tipc_sk_fill_sock_diag to fill the tipc diag attributes.- create a sock_diag response message in __tipc_add_sock_diag defined in diag.c and use the above exported tipc_sk_fill_sock_diag to fill response.Acked-by: Jon Maloy Acked-by: Ying Xue Signed-off-by: GhantaKrishnamurthy MohanKrishna Signed-off-by: Parthasarathy Bhuvaragan Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

026321c6 - tipc: rename tipc_server to tipc_topsrv

Thu, 15 Feb 2018 09:40:51 +0000

tipc: rename tipc_server to tipc_topsrvWe rename struct tipc_server to struct tipc_topsrv. This reflect its nowspecialized role as topology server. Accoringly, we change or add functionprefixes to make it clearer which functionality those belong to.There are no functional changes in this commit.Acked-by: Ying.Xue Signed-off-by: Jon Maloy Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/net/tipc/Makefile

75da2163 - tipc: introduce communication groups

Fri, 13 Oct 2017 09:04:23 +0000

tipc: introduce communication groupsAs a preparation for introducing flow control for multicast and datagrammessaging we need a more strictly defined framework than we have now. Asocket must be able keep track of exactly how many and which othersockets it is allowed to communicate with at any moment, and keep thenecessary state for those.We therefore introduce a new concept we have named Communication Group.Sockets can join a group via a new setsockopt() call TIPC_GROUP_JOIN.The call takes four parameters: 'type' serves as group identifier,'instance' serves as an logical member identifier, and 'scope' indicatesthe visibility of the group (node/cluster/zone). Finally, 'flags' makesit possible to set certain properties for the member. For now, there isonly one flag, indicating if the creator of the socket wants to receivea copy of broadcast or multicast messages it is sending via the socket,and if wants to be eligible as destination for its own anycasts.A group is closed, i.e., sockets which have not joined a group willnot be able to send messages to or receive messages from members ofthe group, and vice versa.Any member of a group can send multicast ('group broadcast') messagesto all group members, optionally including itself, using the primitivesend(). The messages are received via the recvmsg() primitive. A socketcan only be member of one group at a time.Signed-off-by: Jon Maloy Acked-by: Ying Xue Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

35c55c98 - tipc: add neighbor monitoring framework

Tue, 14 Jun 2016 00:46:22 +0000

tipc: add neighbor monitoring frameworkTIPC based clusters are by default set up with full-mesh linkconnectivity between all nodes. Those links are expected to providea short failure detection time, by default set to 1500 ms. Becauseof this, the background load for neighbor monitoring in an N-nodecluster increases with a factor N on each node, while the overallmonitoring traffic through the network infrastructure increases ata ~(N * (N - 1)) rate. Experience has shown that such clusters don'tscale well beyond ~100 nodes unless we significantly increase failurediscovery tolerance.This commit introduces a framework and an algorithm that drasticallyreduces this background load, while basically maintaining the originalfailure detection times across the whole cluster. Using this algorithm,background load will now grow at a rate of ~(2 * sqrt(N)) per node, andat ~(2 * N * sqrt(N)) in traffic overhead. As an example, each node willnow have to actively monitor 38 neighbors in a 400-node cluster, insteadof as before 399.This "Overlapping Ring Supervision Algorithm" is completely distributedand employs no centralized or coordinated state. It goes as follows:- Each node makes up a linearly ascending, circular list of all its N known neighbors, based on their TIPC node identity. This algorithm must be the same on all nodes.- The node then selects the next M = sqrt(N) - 1 nodes downstream from itself in the list, and chooses to actively monitor those. This is called its "local monitoring domain".- It creates a domain record describing the monitoring domain, and piggy-backs this in the data area of all neighbor monitoring messages (LINK_PROTOCOL/STATE) leaving that node. This means that all nodes in the cluster eventually (default within 400 ms) will learn about its monitoring domain.- Whenever a node discovers a change in its local domain, e.g., a node has been added or has gone down, it creates and sends out a new version of its node record to inform all neighbors about the change.- A node receiving a domain record from anybody outside its local domain matches this against its own list (which may not look the same), and chooses to not actively monitor those members of the received domain record that are also present in its own list. Instead, it relies on indications from the direct monitoring nodes if an indirectly monitored node has gone up or down. If a node is indicated lost, the receiving node temporarily activates its own direct monitoring towards that node in order to confirm, or not, that it is actually gone.- Since each node is actively monitoring sqrt(N) downstream neighbors, each node is also actively monitored by the same number of upstream neighbors. This means that all non-direct monitoring nodes normally will receive sqrt(N) indications that a node is gone.- A major drawback with ring monitoring is how it handles failures that cause massive network partitionings. If both a lost node and all its direct monitoring neighbors are inside the lost partition, the nodes in the remaining partition will never receive indications about the loss. To overcome this, each node also chooses to actively monitor some nodes outside its local domain. Those nodes are called remote domain "heads", and are selected in such a way that no node in the cluster will be more than two direct monitoring hops away. Because of this, each node, apart from monitoring the member of its local domain, will also typically monitor sqrt(N) remote head nodes.- As an optimization, local list status, domain status and domain records are marked with a generation number. This saves senders from unnecessarily conveying unaltered domain records, and receivers from performing unneeded re-adaptations of their node monitoring list, such as re-assigning domain heads.- As a measure of caution we have added the possibility to disable the new algorithm through configuration. We do this by keeping a threshold value for the cluster size; a cluster that grows beyond this value will switch from full-mesh to ring monitoring, and vice versa when it shrinks below the value. This means that if the threshold is set to a value larger than any anticipated cluster size (default size is 32) the new algorithm is effectively disabled. A patch set for altering the threshold value and for listing the table contents will follow shortly.- This change is fully backwards compatible.Acked-by: Ying Xue Signed-off-by: Jon Maloy Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

d0f91938 - tipc: add ip/udp media type

Thu, 05 Mar 2015 09:23:49 +0000

tipc: add ip/udp media typeThe ip/udp bearer can be configured in a point-to-pointmode by specifying both local and remote ip/hostname,or it can be enabled in multicast mode, where links areestablished to all tipc nodes that have joined the samemulticast group. The multicast IP address is generatedbased on the TIPC network ID, but can be overridden byusing another multicast address as remote ip.Signed-off-by: Erik Hugne Reviewed-by: Jon Maloy Reviewed-by: Ying Xue Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

941787b8 - tipc: remove tipc_snprintf

Mon, 09 Feb 2015 08:50:19 +0000

tipc: remove tipc_snprintftipc_snprintf() was heavily utilized by the old netlink API which nolonger exists (now netlink compat).In this patch we swap tipc_snprintf() to the identical scnprintf() inthe only remaining occurrence.Signed-off-by: Richard Alpe Reviewed-by: Erik Hugne Reviewed-by: Ying Xue Reviewed-by: Jon Maloy Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

22ae7cff - tipc: nl compat add noop and remove legacy nl framework

Mon, 09 Feb 2015 08:50:18 +0000

tipc: nl compat add noop and remove legacy nl frameworkAdd TIPC_CMD_NOOP to compat layer and remove the old framework.All legacy nl commands are now converted to the compat layer innetlink_compat.c.Signed-off-by: Richard Alpe Reviewed-by: Erik Hugne Reviewed-by: Ying Xue Reviewed-by: Jon Maloy Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

bfb3e5dd - tipc: move and rename the legacy nl api to "nl compat"

Mon, 09 Feb 2015 08:50:03 +0000

tipc: move and rename the legacy nl api to "nl compat"The new netlink API is no longer "v2" but rather the standard API andthe legacy API is now "nl compat". We split them into separatestart/stop and put them in different files in order to furtherdistinguish them.Signed-off-by: Richard Alpe Reviewed-by: Erik Hugne Reviewed-by: Ying Xue Reviewed-by: Jon Maloy Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

a8f48af5 - tipc: remove node subscription infrastructure

Wed, 26 Nov 2014 03:41:45 +0000

tipc: remove node subscription infrastructureThe node subscribe infrastructure represents a virtual base class, soits users, such as struct tipc_port and struct publication, can deriveits implemented functionalities. However, after the removal of structtipc_port, struct publication is left as its only single user now. Sodefining an abstract infrastructure for one user becomes no longerreasonable. If corresponding new functions associated with theinfrastructure are moved to name_table.c file, the node subscriptioninfrastructure can be removed as well.Signed-off-by: Ying Xue Reviewed-by: Jon Maloy Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

808d90f9 - tipc: remove files ref.h and ref.c

Fri, 22 Aug 2014 22:09:19 +0000

tipc: remove files ref.h and ref.cThe reference table is now 'socket aware' instead of being generic,and has in reality become a socket internal table. In order to beable to minimize the API exposed by the socket layer towards the restof the stack, we now move the reference table definitions and functionsinto the file socket.c, and rename the functions accordingly.There are no functional changes in this commit.Signed-off-by: Jon Maloy Reviewed-by: Erik Hugne Reviewed-by: Ying Xue Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

0fc87aae - tipc: remove source file port.c

Fri, 22 Aug 2014 22:09:17 +0000

tipc: remove source file port.cIn this commit, we move the remaining functions in port.c tosocket.c, and give them new names that correspond to their newlocation. We then remove the file port.c.There are only cosmetic changes to the moved functions.Signed-off-by: Jon Maloy Reviewed-by: Erik Hugne Reviewed-by: Ying Xue Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

52ff8720 - tipc: purge signal handler infrastructure

Mon, 05 May 2014 00:56:18 +0000

tipc: purge signal handler infrastructureIn the previous commits of this series, we removed all asynchronousactions which were based on the tasklet handler - "tipc_k_signal()".So the moment has now come when we can completely remove the tasklethandler infrastructure. That is done with this commit.Signed-off-by: Ying Xue Reviewed-by: Erik Hugne Reviewed-by: Jon Maloy Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

c5fa7b3c - tipc: introduce new TIPC server infrastructure

Mon, 17 Jun 2013 14:54:39 +0000

tipc: introduce new TIPC server infrastructureTIPC has two internal servers, one providing a subscriptionservice for topology events, and another providing theconfiguration interface. These servers have previously been runningin BH context, accessing the TIPC-port (aka native) API directly.Apart from these servers, even the TIPC socket implementation ispartially built on this API.As this API may simultaneously be called via different paths and indifferent contexts, a complex and costly lock policiy is requiredin order to protect TIPC internal resources.To eliminate the need for this complex lock policiy, we introducea new, generic service API that uses kernel sockets for messagepassing instead of the native API. Once the toplogy and configurationservers are converted to use this new service, all code pertainingto the native API can be removed. This entails a significantreduction in code amount and complexity, and opens up for a completerework of the locking policy in TIPC.The new service also solves another problem:As the current topology server works in BH context, it cannot easilybe blocked when sending of events fails due to congestion. In suchcases events may have to be silently dropped, something that isunacceptable. Therefore, the new service keeps a dedicated outboundqueue receiving messages from BH context. Once messages areinserted into this queue, we will immediately schedule a work from aspecial workqueue. This way, messages/events from the topology serverare in reality sent in process context, and the server can blockif necessary.Analogously, there is a new workqueue for receiving messages. Once anotification about an arriving message is received in BH context, weschedule a work from the receive workqueue to do the job ofreceiving the message in process context.As both sending and receive messages are now finished in processes,subscribed events cannot be dropped any more.As of this commit, this new server infrastructure is built, butnot actually yet called by the existing TIPC code, but since theconversion changes required in order to use it are significant,the addition is kept here as a separate commit.Signed-off-by: Ying Xue Signed-off-by: Jon Maloy Signed-off-by: Paul Gortmaker Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile

cc79dd1b - tipc: change socket buffer overflow control to respect sk_rcvbuf

Mon, 17 Jun 2013 14:54:37 +0000

tipc: change socket buffer overflow control to respect sk_rcvbufAs per feedback from the netdev community, we change the bufferoverflow protection algorithm in receiving sockets so that italways respects the nominal upper limit set in sk_rcvbuf.Instead of scaling up from a small sk_rcvbuf value, which leads toviolation of the configured sk_rcvbuf limit, we now calculate theweighted per-message limit by scaling down from a much bigger value,still in the same field, according to the importance priority of thereceived message.To allow for administrative tunability of the socket receive buffersize, we create a tipc_rmem sysctl variable to allow the user toconfigure an even bigger value via sysctl command. It is a size ofthree (min/default/max) to be consistent with things like tcp_rmem.By default, the value initialized in tipc_rmem[1] is equal to thereceive socket size needed by a TIPC_CRITICAL_IMPORTANCE message.This value is also set as the default value of sk_rcvbuf.Originally-by: Jon Maloy Cc: Neil Horman Cc: Jon Maloy [Ying: added sysctl variation to Jon's original patch]Signed-off-by: Ying Xue [PG: don't compile sysctl.c if not config'd; add Documentation]Signed-off-by: Paul Gortmaker Signed-off-by: David S. Miller List of files: /linux-6.15/net/tipc/Makefile