Changes in Makefile

7e86845a - rpcrdma: Implement generic device removal

Tue, 04 Jun 2024 19:45:24 +0000

rpcrdma: Implement generic device removalCommit e87a911fed07 ("nvme-rdma: use ib_client API to detect deviceremoval") explains the benefits of handling device removal outsideof the CM event handler.Sketch in an IB device removal notification mechanism that can beused by both the client and server side RPC-over-RDMA transportimplementations.Suggested-by: Sagi Grimberg Signed-off-by: Chuck Lever Reviewed-by: Sagi Grimberg Signed-off-by: Anna Schumaker List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

78147ca8 - svcrdma: Add a "parsed chunk list" data structure

Mon, 22 Jun 2020 14:15:41 +0000

svcrdma: Add a "parsed chunk list" data structureThis simple data structure binds the location of each data payloadinside of an RPC message to the chunk that will be used to push itto or pull it from the client.There are several benefits to this small additional overhead: * It enables support for more than one chunk in incoming Read and Write lists. * It translates the version-specific on-the-wire format into a generic in-memory structure, enabling support for multiple versions of the RPC/RDMA transport protocol. * It enables the server to re-organize a chunk list if it needs to adjust where Read chunk data lands in server memory without altering the contents of the XDR-encoded Receive buffer.Construction of these lists is done while sanity checking eachincoming RPC/RDMA header. Subsequent patches will make use of thegenerated data structures.Signed-off-by: Chuck Lever List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

ba69cd12 - xprtrdma: Remove support for FMR memory registration

Wed, 19 Dec 2018 15:58:56 +0000

xprtrdma: Remove support for FMR memory registrationFMR is not supported on most recent RDMA devices. It is also lesssecure than FRWR because an FMR memory registration can exposeadjacent bytes to remote reading or writing. As discussed during theRDMA BoF at LPC 2018, it is time to remove support for FMR in theNFS/RDMA client stack.Note that NFS/RDMA server-side uses either local memory registrationor FRWR. FMR is not used.There are a few Infiniband/RoCE devices in the kernel tree that donot appear to support MEM_MGT_EXTENSIONS (FRWR), and therefore willnot support client-side NFS/RDMA after this patch. These are: - mthca - qib - hns (RoCE)Users of these devices can use NFS/TCP on IPoIB instead.Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker List of files: /linux-6.15/net/sunrpc/xprtrdma/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/sunrpc/xprtrdma/Makefile

a80a3234 - svcrdma: Remove svc_rdma_marshal.c

Fri, 23 Jun 2017 21:17:35 +0000

svcrdma: Remove svc_rdma_marshal.csvc_rdma_marshal.c has one remaining exported function --svc_rdma_xdr_decode_req -- and it has a single call site. Takethe same approach as the sendto path, and move this functioninto the source file where it is called.This is a refactoring change only.Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

f13193f5 - svcrdma: Introduce local rdma_rw API helpers

Sun, 09 Apr 2017 17:06:16 +0000

svcrdma: Introduce local rdma_rw API helpersThe plan is to replace the local bespoke code that constructs andposts RDMA Read and Write Work Requests with calls to the rdma_rwAPI. This shares code with other RDMA-enabled ULPs that manages thegory details of buffer registration and posting Work Requests.Some design notes: o The structure of RPC-over-RDMA transport headers is flexible, allowing multiple segments per Reply with arbitrary alignment, each with a unique R_key. Write and Send WRs continue to be built and posted in separate code paths. However, one whole chunk (with one or more RDMA segments apiece) gets exactly one ib_post_send and one work completion. o svc_xprt reference counting is modified, since a chain of rdma_rw_ctx structs generates one completion, no matter how many Write WRs are posted. o The current code builds the transport header as it is construct- ing Write WRs. I've replaced that with marshaling of transport header data items in a separate step. This is because the exact structure of client-provided segments may not align with the components of the server's reply xdr_buf, or the pages in the page list. Thus parts of each client-provided segment may be written at different points in the send path.Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

2dc3a69d - xprtrdma: Remove ALLPHYSICAL memory registration mode

Wed, 29 Jun 2016 17:53:11 +0000

xprtrdma: Remove ALLPHYSICAL memory registration modeNo HCA or RNIC in the kernel tree requires the use of ALLPHYSICAL.ALLPHYSICAL advertises in the clear on the network fabric an R_keythat is good for all of the client's memory. No known exploitexists, but theoretically any user on the server can use that R_keyon the client's QP to read or update any part of the client's memory.ALLPHYSICAL exposes the client to server bugs, including: o base/bounds errors causing data outside the i/o buffer to be accessed o RDMA access after reply causing data corruption and/or integrity failALLPHYSICAL can't protect application memory regions from serverupdate after a local signal or soft timeout has terminated an RPC.ALLPHYSICAL chunks are no larger than a page. Special cases tohandle small chunks and long chunk lists have been a source ofimplementation complexity and bugs.Signed-off-by: Chuck Lever Tested-by: Steve Wise Signed-off-by: Anna Schumaker List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

5d252f90 - svcrdma: Add class for RDMA backwards direction transport

Thu, 07 Jan 2016 19:50:10 +0000

svcrdma: Add class for RDMA backwards direction transportTo support the server-side of an NFSv4.1 backchannel on RDMAconnections, add a transport class that enables backwarddirection messages on an existing forward channel connection.Signed-off-by: Chuck Lever Acked-by: Bruce Fields Signed-off-by: Doug Ledford List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

f531a5db - xprtrdma: Pre-allocate backward rpc_rqst and send/receive buffers

Sat, 24 Oct 2015 21:27:43 +0000

xprtrdma: Pre-allocate backward rpc_rqst and send/receive buffersxprtrdma's backward direction send and receive buffers are the samesize as the forechannel's inline threshold, and must be pre-registered.The consumer has no control over which receive buffer the adapterchooses to catch an incoming backwards-direction call. Any receivebuffer can be used for either a forward reply or a backward call.Thus both types of RPC message must all be the same size.Signed-off-by: Chuck Lever Reviewed-by: Sagi Grimberg Tested-By: Devesh Sharma Signed-off-by: Anna Schumaker List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

ffe1f0df - rpcrdma: Merge svcrdma and xprtrdma modules into one

Thu, 04 Jun 2015 15:21:42 +0000

rpcrdma: Merge svcrdma and xprtrdma modules into oneBi-directional RPC support means code in svcrdma.ko invokes a bit ofcode in xprtrdma.ko, and vice versa. To avoid loader/linker loops,merge the server and client side modules together into a singlemodule.When backchannel capabilities are added, the combined module willregister all needed transport capabilities so that Upper Layerconsumers automatically have everything needed to create abi-directional transport connection.Module aliases are added for backwards compatibility with userspace, which still may expect svcrdma.ko or xprtrdma.ko to bepresent.This commit reverts commit 2e8c12e1b765 ("xprtrdma: add separateKconfig options for NFSoRDMA client and server support") andprovides a single CONFIG option for enabling the new module.Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

a0ce85f5 - xprtrdma: Add vector of ops for each memory registration strategy

Mon, 30 Mar 2015 18:34:21 +0000

xprtrdma: Add vector of ops for each memory registration strategyInstead of employing switch() statements, let's use the typicalLinux kernel idiom for handling behavioral variation: virtualfunctions.Start by defining a vector of operations for each supported memoryregistration mode, and by adding a source file for each mode.Signed-off-by: Chuck Lever Reviewed-by: Sagi Grimberg Tested-by: Devesh Sharma Tested-by: Meghana Cheripady Tested-by: Veeresh U. Kokatnur Signed-off-by: Anna Schumaker List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

2e8c12e1 - xprtrdma: add separate Kconfig options for NFSoRDMA client and server support

Tue, 18 Mar 2014 23:45:47 +0000

xprtrdma: add separate Kconfig options for NFSoRDMA client and server supportThere are two entirely separate modules under xprtrdma/ and there's noreason that enabling one should automatically enable the other. Addconfig options for each one so they can be enabled/disabled separately.Signed-off-by: Jeff Layton Signed-off-by: J. Bruce Fields List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

4b8449af - rdma: makefile

Wed, 12 Dec 2007 22:13:30 +0000

rdma: makefileAdd the svcrdma module to the xprtrdma makefile.Signed-off-by: Tom Tucker Acked-by: Neil Brown Signed-off-by: J. Bruce Fields List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile

f58851e6 - RPCRDMA: rpc rdma transport switch

Mon, 10 Sep 2007 17:50:12 +0000

RPCRDMA: rpc rdma transport switchThis implements the configuration and building of the core transportswitch implementation of the rpcrdma transport. Stubs are provided forthe rpcrdma protocol handling, and the infiniband/iwarp verbs interface.These are provided in following patches.Signed-off-by: Tom Talpey Signed-off-by: Trond Myklebust List of files: /linux-6.15/net/sunrpc/xprtrdma/Makefile