libnvme: mi: reject async events that carry the RSP bit in nmp

[prabhakarpujeri]

Problem

Port of linux-nvme/libnvme#1131. The same inverted ROR check reached this tree:

if (!(resp->hdr->nmp & ~(NVME_MI_ROR_REQ << 7)))   /* ~(0 << 7) == all-ones */
	... reject

With NVME_MI_ROR_REQ == 0 the expression reduces to !nmp: a message is rejected only when all of nmp is clear, while a message with the RSP bit (bit 7) set — precisely the condition the error message describes — passes.

Fix

Test bit 7 with NVME_MI_ROR_RSP, matching the polarity of the command-response verification a few dozen lines down.

Testing

• Full meson suite green.
• One-line polarity fix; validated by review against the parallel implementation (and by the corresponding 1.x PR).

[igaw]

dropped libnvme 1 reference.

[Copilot]

Pull request overview

Fixes an inverted Request-or-Response (ROR) bit check in the NVMe-MI async event read path so that incoming async events with the RSP bit set in NMP are correctly rejected (matching the intent of the existing error handling and the command/response verification logic elsewhere in mi.c).

Changes:

• Replace the broken ~(NVME_MI_ROR_REQ << 7)-based check with an explicit test for the RSP bit via NVME_MI_ROR_RSP.
• Ensure async events with nmp bit 7 set are rejected as invalid in libnvme_mi_async_read().

Suppressed comments (1)

libnvme/src/nvme/mi.c:524

• The debug message here is tautological ("in response indicates a response") and doesn’t clearly explain what is wrong with the incoming async event. Since this path rejects messages with the RSP bit set in NMP, the log should explicitly mention the unexpected RSP bit and ideally include the observed NMP value to aid troubleshooting.

	if (resp->hdr->nmp & (NVME_MI_ROR_RSP << 7)) {
		libnvme_msg(ep->ctx, LIBNVME_LOG_DEBUG,
			 "ROR value in response indicates a response\n");
		return -EIO;
	}

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[igaw]

Thanks!