Re: [PATCH v5 5/6] nvme-tcp: Support KeyUpdate
Hannes Reinecke <[email protected]>
| Newsgroups | dev.linux.lists.kernel-tls-handshake,org.infradead.lists.linux-nvme,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
On 12/1/25 05:18, Alistair Francis wrote: > On Thu, Nov 27, 2025 at 11:31 PM Hannes Reinecke <[email protected]> wrote: >> >> On 11/12/25 05:27, [email protected] wrote: >>> From: Alistair Francis <[email protected]> [ .. ]>>> @@ -976,10 +986,26 @@ static int nvme_tcp_recvmsg_data(struct nvme_tcp_queue *queue) >>> >>> ret = sock_recvmsg(queue->sock, &msg, msg.msg_flags); >>> if (ret < 0) { >>> - dev_err(queue->ctrl->ctrl.device, >>> - "queue %d failed to receive request %#x data", >>> - nvme_tcp_queue_id(queue), rq->tag); >>> - return ret; >>> + /* If MSG_CTRUNC is set, it's a control message, >>> + * so let's read the control message. >>> + */ >>> + if (msg.msg_flags & MSG_CTRUNC) { >>> + memset(&msg, 0, sizeof(msg)); >>> + msg.msg_flags = MSG_DONTWAIT; >>> + msg.msg_control = cbuf; >>> + msg.msg_controllen = sizeof(cbuf); >>> + >> This is not correct; reading the control message implies a kernel >> memory allocation as message buffer, not an interator (as it's the >> case here). > > I don't follow what you mean > Ah, right. My comment refers to users of tls_alert_recv(), which we don't do here. Sorry for the noise. You can add my: Reviewed-by: Hannes Reinecke <[email protected]> Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect [email protected] +49 911 74053 688 SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich