All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: netdev@vger.kernel.org, Marc Dionne <marc.dionne@auristor.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org,
	Jeffrey Altman <jaltman@auristor.com>,
	"Junvyyang, Tencent Zhuque Lab" <zhuque@tencent.com>,
	LePremierHomme <kwqcheii@proton.me>,
	stable@vger.kernel.org
Subject: Re: [PATCH net 3/5] rxrpc: Fix notification vs call-release vs recvmsg
Date: Wed, 16 Jul 2025 20:00:01 +0100	[thread overview]
Message-ID: <20250716190001.GR721198@horms.kernel.org> (raw)
In-Reply-To: <20250716115307.3572606-4-dhowells@redhat.com>

On Wed, Jul 16, 2025 at 12:53:02PM +0100, David Howells wrote:
> When a call is released, rxrpc takes the spinlock and removes it from
> ->recvmsg_q in an effort to prevent racing recvmsg() invocations from
> seeing the same call.  Now, rxrpc_recvmsg() only takes the spinlock when
> actually removing a call from the queue; it doesn't, however, take it in
> the lead up to that when it checks to see if the queue is empty.  It *does*
> hold the socket lock, which prevents a recvmsg/recvmsg race - but this
> doesn't prevent sendmsg from ending the call because sendmsg() drops the
> socket lock and relies on the call->user_mutex.
> 
> Fix this by firstly removing the bit in rxrpc_release_call() that dequeues
> the released call and, instead, rely on recvmsg() to simply discard
> released calls (done in a preceding fix).
> 
> Secondly, rxrpc_notify_socket() is abandoned if the call is already marked
> as released rather than trying to be clever by setting both pointers in
> call->recvmsg_link to NULL to trick list_empty().  This isn't perfect and
> can still race, resulting in a released call on the queue, but recvmsg()
> will now clean that up.
> 
> Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
> Signed-off-by: David Howells <dhowells@redhat.com>
> Reviewed-by: Jeffrey Altman <jaltman@auristor.com>

...

> diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c

...

> @@ -638,6 +628,12 @@ void rxrpc_release_calls_on_socket(struct rxrpc_sock *rx)
>  		rxrpc_put_call(call, rxrpc_call_put_release_sock);
>  	}
>  
> +	while ((call = list_first_entry_or_null(&rx->recvmsg_q,
> +						struct rxrpc_call, recvmsg_link))) {
> +		list_del_init(&call->recvmsg_link);
> +		rxrpc_put_call(call, rxrpc_call_put_release_recvmsg_q);
> +	}
> +
>  	_leave("");
>  }
>  

Hi David,

I believe it is addressed in patch 5/5.
But unfortunately this change breaks bisection.

  .../call_object.c:634:24: error: use of undeclared identifier 'rxrpc_call_put_release_recvmsg_q'
    634 |                 rxrpc_put_call(call, rxrpc_call_put_release_recvmsg_q);
        |                                      ^

-- 
pw-bot: changes-requested


  reply	other threads:[~2025-07-16 19:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-16 11:52 [PATCH net 0/5] rxrpc: Miscellaneous fixes David Howells
2025-07-16 11:53 ` [PATCH net 1/5] rxrpc: Fix irq-disabled in local_bh_enable() David Howells
2025-07-16 11:53 ` [PATCH net 2/5] rxrpc: Fix recv-recv race of completed call David Howells
2025-07-16 11:53 ` [PATCH net 3/5] rxrpc: Fix notification vs call-release vs recvmsg David Howells
2025-07-16 19:00   ` Simon Horman [this message]
2025-07-16 11:53 ` [PATCH net 4/5] rxrpc: Fix transmission of an abort in response to an abort David Howells
2025-07-16 11:53 ` [PATCH net 5/5] rxrpc: Fix to use conn aborts for conn-wide failures David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250716190001.GR721198@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=edumazet@google.com \
    --cc=jaltman@auristor.com \
    --cc=kuba@kernel.org \
    --cc=kwqcheii@proton.me \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.dionne@auristor.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=zhuque@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.