[RFC5040 question] RDMA/siw: received Terminate is reported only as a CM close
alu a <[email protected]> Mon, 3 Aug 2026 22:48:20 +0800
| Newsgroups | org.kernel.vger.linux-rdma |
|---|---|
| Message-ID | <CAH+L_5ZsxEAM3y8PmVQi1rMQhdRu3PKX9JWGD5N1hC2rkP9wDg@mail.gmail.com> |
Hello, RFC 5040 Section 5.4 says that the RDMAP layer MUST deliver a received Terminate Message to the ULP. Section 2.1 defines Delivery as informing the ULP or consumer that a particular Message is available for use. https://www.rfc-editor.org/rfc/rfc5040.html#section-5.4 On Linux master commit 075b74841bd0065a3bda3440873c747938e69b68, siw_proc_terminate() logs the Terminate layer, error type, and error code, optionally parses the reported header for debugging, and returns -ECONNRESET: https://github.com/torvalds/linux/blob/075b74841bd0065a3bda3440873c747938e69b68/drivers/infiniband/sw/siw/siw_qp_rx.c#L887-L957 The receive loop treats that return specially: it suppresses the normal RDMAP completion and schedules the LLP close: https://github.com/torvalds/linux/blob/075b74841bd0065a3bda3440873c747938e69b68/drivers/infiniband/sw/siw/siw_qp_rx.c#L1409-L1469 The close worker reports only IW_CM_EVENT_CLOSE with status zero: https://github.com/torvalds/linux/blob/075b74841bd0065a3bda3440873c747938e69b68/drivers/infiniband/sw/siw/siw_cm.c#L1119-L1129 The CLOSE upcall does not include Terminate-specific information: https://github.com/torvalds/linux/blob/075b74841bd0065a3bda3440873c747938e69b68/drivers/infiniband/sw/siw/siw_cm.c#L351-L409 Based on static source analysis, the consumer appears to receive only a generic connection-close indication and flushed work requests. I could not find a path that identifies the received Terminate to the consumer or makes its information available for later query. I have not reproduced this at runtime. Is IW_CM_EVENT_CLOSE considered sufficient delivery of the Terminate Message under RFC 5040 Section 5.4, or is a Terminate-specific indication expected? Is there another path exposing the received Terminate that I missed? I realize that RFC 5040 does not prescribe a particular Linux API, so I am asking about the intended mapping rather than proposing a specific fix. This finding came from an academic source-level RFC consistency review. Best regards