From nobody Tue Oct 7 19:59:40 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 961741C5F14 for ; Mon, 7 Jul 2025 10:24:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751883894; cv=none; b=B5dHbdXAjPS6TR1e9T1APxKhGU6ec86+vCSkpsixHTH9oXFoTKH6cyfm5weQ74YpTtf/Z6PLlSRongNwDCn4TM3rBZeg74+979KceqCu5j3/YB+vxruT4/hSs1hNgbp3ULAqrl6DM1pdliIZd9cbd+VokzHwl2UFg/DwHr/qhmY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751883894; c=relaxed/simple; bh=5hUESjLxUFC1ShxxEVQTV2GFkVfPYLnwrUSx57ytBxc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=A3nQpo6MoQqOBF+7ZYTmcVLL5eT5XOPoYZCDYkYx7hsDeSJ7xjpIgt1Jv1YU6VIUsj4ItDOpHjcQPnYzbwPCQumZ3qgGzic6XRoLk5QbFZ56HsYNAA7at33SO26lyECciyrP0op7V6blNEb6uec2ccKDV7DAhHYQpHjSyKLtZGM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=J4hMpvAX; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="J4hMpvAX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1751883891; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=41yP/MGOPD24t3eqgJmcH7ObsMSXti+X7G8qHnMnBMY=; b=J4hMpvAXYjRIhuvLjSpgMkjuIsN/UCPf2wz5PitgZ01iIUfJI/NWs89sDIvC/lSM4joSDs HhjIVWrxX1mdBUHt/XvKNopVHu0ojpVvE6ozaxQUU3Igcu9Qx9dUBSvrDhblEF0T98OkHE vNcAquD+jVJdcvPwEl6Sz62IvAXJw6Y= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-228-qLoPwFUNNhCbufjI6_0h4Q-1; Mon, 07 Jul 2025 06:24:49 -0400 X-MC-Unique: qLoPwFUNNhCbufjI6_0h4Q-1 X-Mimecast-MFC-AGG-ID: qLoPwFUNNhCbufjI6_0h4Q_1751883888 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A11B91944AA6; Mon, 7 Jul 2025 10:24:47 +0000 (UTC) Received: from warthog.procyon.org.com (unknown [10.42.28.81]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 5C3D4180045C; Mon, 7 Jul 2025 10:24:44 +0000 (UTC) From: David Howells To: netdev@vger.kernel.org Cc: David Howells , Marc Dionne , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org, kernel test robot , Simon Horman Subject: [PATCH net 1/2] rxrpc: Fix over large frame size warning Date: Mon, 7 Jul 2025 11:24:33 +0100 Message-ID: <20250707102435.2381045-2-dhowells@redhat.com> In-Reply-To: <20250707102435.2381045-1-dhowells@redhat.com> References: <20250707102435.2381045-1-dhowells@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" Under some circumstances, the compiler will emit the following warning for rxrpc_send_response(): net/rxrpc/output.c: In function 'rxrpc_send_response': net/rxrpc/output.c:974:1: warning: the frame size of 1160 bytes is large= r than 1024 bytes This occurs because the local variables include a 16-element scatterlist array and a 16-element bio_vec array. It's probably not actually a problem as this function is only called by the rxrpc I/O thread function in a kernel thread and there won't be much on the stack before it. Fix this by overlaying the bio_vec array over the kvec array in the rxrpc_local struct. There is one of these per I/O thread and the kvec array is intended for pointing at bits of a packet to be transmitted, typically a DATA or an ACK packet. As packets for a local endpoint are only transmitted by its specific I/O thread, there can be no race, and so overlaying this bit of memory should be no problem. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for = a RESPONSE") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202506240423.E942yKJP-lkp@int= el.com/ Signed-off-by: David Howells cc: Marc Dionne cc: "David S. Miller" cc: Eric Dumazet cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org --- net/rxrpc/ar-internal.h | 15 +++++++++------ net/rxrpc/output.c | 5 ++++- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h index 5bd3922c310d..376e33dce8c1 100644 --- a/net/rxrpc/ar-internal.h +++ b/net/rxrpc/ar-internal.h @@ -361,12 +361,15 @@ struct rxrpc_local { struct list_head new_client_calls; /* Newly created client calls need con= nection */ spinlock_t client_call_lock; /* Lock for ->new_client_calls */ struct sockaddr_rxrpc srx; /* local address */ - /* Provide a kvec table sufficiently large to manage either a DATA - * packet with a maximum set of jumbo subpackets or a PING ACK padded - * out to 64K with zeropages for PMTUD. - */ - struct kvec kvec[1 + RXRPC_MAX_NR_JUMBO > 3 + 16 ? - 1 + RXRPC_MAX_NR_JUMBO : 3 + 16]; + union { + /* Provide a kvec table sufficiently large to manage either a + * DATA packet with a maximum set of jumbo subpackets or a PING + * ACK padded out to 64K with zeropages for PMTUD. + */ + struct kvec kvec[1 + RXRPC_MAX_NR_JUMBO > 3 + 16 ? + 1 + RXRPC_MAX_NR_JUMBO : 3 + 16]; + struct bio_vec bvec[3 + 16]; + }; }; =20 /* diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c index 0af19bcdc80a..ef7b3096c95e 100644 --- a/net/rxrpc/output.c +++ b/net/rxrpc/output.c @@ -924,7 +924,7 @@ void rxrpc_send_response(struct rxrpc_connection *conn,= struct sk_buff *response { struct rxrpc_skb_priv *sp =3D rxrpc_skb(response); struct scatterlist sg[16]; - struct bio_vec bvec[16]; + struct bio_vec *bvec =3D conn->local->bvec; struct msghdr msg; size_t len =3D sp->resp.len; __be32 wserial; @@ -938,6 +938,9 @@ void rxrpc_send_response(struct rxrpc_connection *conn,= struct sk_buff *response if (ret < 0) goto fail; nr_sg =3D ret; + ret =3D -EIO; + if (WARN_ON_ONCE(nr_sg > ARRAY_SIZE(conn->local->bvec))) + goto fail; =20 for (int i =3D 0; i < nr_sg; i++) bvec_set_page(&bvec[i], sg_page(&sg[i]), sg[i].length, sg[i].offset); From nobody Tue Oct 7 19:59:40 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 75586293C7F for ; Mon, 7 Jul 2025 10:25:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751883905; cv=none; b=IueOMPGOo/P/hmc7aQFqyEGRdwsEqid9FuQUSX36H00Zcc5rxV+ah6wnUnGfbd5E1umYwlvNKo0nVtoIonKf1Yq8okpwQcN2NAzYtnXz98MCZILCgmrevIA+l16SU4TW4mnOnJEi5RDttCpAQP9LBROH0Gk2Xl0MvNRdTQaVboA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751883905; c=relaxed/simple; bh=CSkzHkSLZb85ATDXN1XVNRPwM4yhfT0dut0dQqFmWDM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aDxVRmoL3TGfkQOzEwlTQUVcCCSnqb+0uWP8+pnZH1OTQgae7uenQZGSdCyExM+AZn/kEjXVWRlslZf8LQueRZ1rcp1LNEWRNRrhxucTWe3s6HPlCAOlX5uxmFQCo0JhdKs4VHr8vY5HYlp13rR4DmH78i7GBm8Qv8aTJgGSEy0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=UidLbdOF; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UidLbdOF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1751883902; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=c8uLvrdEI8a2tyD8FkZ5ui0XQcinAdyYHyFTkQHvcGo=; b=UidLbdOFOtG9fHwzr/8MShac8oWJPGHNr9bDTsoOaTlU2wrbOqBZW4sEhbf+1hrh/3RToB sXnMM1RorYJb+F9/8G8ulOacgpdcHiL3fYxuBhPA+PO5qR+yqrGTaHki4+X4QWSxLM4/an YWcrIp66zXpT6o1jpm+YoLn17ms5L2c= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-438-l6sWfO9qNL2mFig5armnMg-1; Mon, 07 Jul 2025 06:24:56 -0400 X-MC-Unique: l6sWfO9qNL2mFig5armnMg-1 X-Mimecast-MFC-AGG-ID: l6sWfO9qNL2mFig5armnMg_1751883893 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 89B71180028A; Mon, 7 Jul 2025 10:24:53 +0000 (UTC) Received: from warthog.procyon.org.com (unknown [10.42.28.81]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 849661956087; Mon, 7 Jul 2025 10:24:49 +0000 (UTC) From: David Howells To: netdev@vger.kernel.org Cc: David Howells , Marc Dionne , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org, "Junvyyang, Tencent Zhuque Lab" , Simon Horman Subject: [PATCH net 2/2] rxrpc: Fix bug due to prealloc collision Date: Mon, 7 Jul 2025 11:24:34 +0100 Message-ID: <20250707102435.2381045-3-dhowells@redhat.com> In-Reply-To: <20250707102435.2381045-1-dhowells@redhat.com> References: <20250707102435.2381045-1-dhowells@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 Content-Type: text/plain; charset="utf-8" When userspace is using AF_RXRPC to provide a server, it has to preallocate incoming calls and assign to them call IDs that will be used to thread related recvmsg() and sendmsg() together. The preallocated call IDs will automatically be attached to calls as they come in until the pool is empty. To the kernel, the call IDs are just arbitrary numbers, but userspace can use the call ID to hold a pointer to prepared structs. In any case, the user isn't permitted to create two calls with the same call ID (call IDs become available again when the call ends) and EBADSLT should result from sendmsg() if an attempt is made to preallocate a call with an in-use call ID. However, the cleanup in the error handling will trigger both assertions in rxrpc_cleanup_call() because the call isn't marked complete and isn't marked as having been released. Fix this by setting the call state in rxrpc_service_prealloc_one() and then marking it as being released before calling the cleanup function. Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incomin= g service requests") Reported-by: Junvyyang, Tencent Zhuque Lab Signed-off-by: David Howells cc: LePremierHomme kwqcheii@proton.me cc: Marc Dionne cc: Jakub Kicinski cc: Paolo Abeni cc: "David S. Miller" cc: Eric Dumazet cc: Simon Horman cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org --- net/rxrpc/call_accept.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c index a4b363b47cca..32af666547f8 100644 --- a/net/rxrpc/call_accept.c +++ b/net/rxrpc/call_accept.c @@ -149,6 +149,8 @@ static int rxrpc_service_prealloc_one(struct rxrpc_sock= *rx, =20 id_in_use: write_unlock(&rx->call_lock); + rxrpc_prefail_call(call, RXRPC_CALL_LOCAL_ERROR, -EBADSLT); + __set_bit(RXRPC_CALL_RELEASED, &call->flags); rxrpc_cleanup_call(call); _leave(" =3D -EBADSLT"); return -EBADSLT;