aboutsummaryrefslogtreecommitdiff
path: root/contrib/rdmacm-mux
AgeCommit message (Collapse)AuthorFilesLines
2020-12-18contrib/rdmacm-mux: Fix error condition in hash_tbl_search_fd_by_ifid()AlexChen1-1/+1
When fd is not found according to ifid, the _hash_tbl_search_fd_by_ifid() returns 0 and assigns the result to *fd, so We have to check that *fd is 0, not that fd is 0. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: AlexChen <alex.chen@huawei.com> Message-Id: <5F9AC6FF.4000301@huawei.com> Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2020-08-21contrib/rdmacm-mux: convert to MesonPaolo Bonzini2-3/+9
We can use config-host.mak to decide whether the tool has to be built, apart from that the conversion is straightforward. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-18contrib/rdmacm-mux: Remove superfluous semicolonPhilippe Mathieu-Daudé1-1/+1
Fixes: a5d2f6f8773 Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200218094402.26625-14-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2019-07-15rdmacm-mux: fix strcpy string warningMarc-André Lureau1-1/+1
../contrib/rdmacm-mux/main.c: In function ‘parse_args’: ../contrib/rdmacm-mux/main.c:118:13: error: ‘strncpy’ specified bound 3835 equals destination size [-Werror=stringop-truncation] 118 | strncpy(unix_socket_path, optarg, SOCKET_PATH_MAX); Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190712165154.11504-1-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-05-13Use #include "..." for our own headers, <...> for othersMarkus Armbruster2-13/+13
Also delete a few redundant #include. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190315145123.28030-2-armbru@redhat.com>
2019-03-16contrib/rdmacm-mux: Fix out-of-bounds riskYuval Shaia1-2/+33
The function get_fd extract context from the received MAD message and uses it as a key to fetch the destination fd from the mapping table. A context can be dgid in case of CM request message or comm_id in case of CM SIDR response message. When MAD message with a smaller size as expected for the message type received we are hitting out-of-bounds where we are looking for the context out of message boundaries. Fix it by validating the message size. Reported-by Sam Smith <sam.j.smith@oracle.com> Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> Message-Id: <20190212112347.1605-1-yuval.shaia@oracle.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2019-01-19contrib/rdmacm-mux: fix clang compilationMarcel Apfelbaum1-1/+0
Fix Commit a5d2f6f877 (contrib/rdmacm-mux: Add implementation of RDMA User MAD multiplexer). The above commit introduces a new contrib target, adding a global dependency to libumad library in case pvrdma configuration option is enabled. Clang forbids it: clang-6.0: error: -libumad: 'linker' input unused [-Werror,-Wunused-command-line-argument] Fix by limiting the scope to the rdmacm-mux target itself. Reported-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com> Tested-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190118124614.24548-4-marcel.apfelbaum@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2019-01-19hw/rdma: modify struct initializationMarcel Apfelbaum1-3/+3
Do not initialize structs with {0} since some CLANG versions do not support it. Use {} construct instead. Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com> Tested-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190118124614.24548-3-marcel.apfelbaum@gmail.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2019-01-19contrib/rdmacm-mux: remove Wno-format-truncation flagMarcel Apfelbaum2-3/+5
The flag is not recognized by some CLANG versions. Add proper constraints in code instead. Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com> Tested-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190118124614.24548-2-marcel.apfelbaum@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
2018-12-22contrib/rdmacm-mux: Add implementation of RDMA User MAD multiplexerYuval Shaia3-0/+863
RDMA MAD kernel module (ibcm) disallow more than one MAD-agent for a given MAD class. This does not go hand-by-hand with qemu pvrdma device's requirements where each VM is MAD agent. Fix it by adding implementation of RDMA MAD multiplexer service which on one hand register as a sole MAD agent with the kernel module and on the other hand gives service to more than one VM. Design Overview: Reviewed-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com> ---------------- A server process is registered to UMAD framework (for this to work the rdma_cm kernel module needs to be unloaded) and creates a unix socket to listen to incoming request from clients. A client process (such as QEMU) connects to this unix socket and registers with its own GID. TX: ---- When client needs to send rdma_cm MAD message it construct it the same way as without this multiplexer, i.e. creates a umad packet but this time it writes its content to the socket instead of calling umad_send(). The server, upon receiving such a message fetch local_comm_id from it so a context for this session can be maintain and relay the message to UMAD layer by calling umad_send(). RX: ---- The server creates a worker thread to process incoming rdma_cm MAD messages. When an incoming message arrived (umad_recv()) the server, depending on the message type (attr_id) looks for target client by either searching in gid->fd table or in local_comm_id->fd table. With the extracted fd the server relays to incoming message to the client. Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> Reviewed-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>