All of lore.kernel.org
 help / color / mirror / Atom feed
* [MPTCP] Re: [PATCH net-next 6/8] mptcp: avoid work queue scheduling if possible
@ 2020-02-25 12:40 Paolo Abeni
  0 siblings, 0 replies; 3+ messages in thread
From: Paolo Abeni @ 2020-02-25 12:40 UTC (permalink / raw)
  To: mptcp 

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

On Tue, 2020-02-25 at 13:05 +0100, Florian Westphal wrote:
> We can't grab the mptcp socket lock from the subflow data_ready
> callback, it would result in ABBA deadlock.
> 
> But we can try to grab the mptcp lock.
> If we can't, we can defer to work queue.
> If the lock succeeds however we can avoid the schedule_work()
> call and move all in-sequence skbs to the mptcp receive queue.
> 
> Signed-off-by: Florian Westphal <fw(a)strlen.de>
> ---
>  net/mptcp/protocol.c | 30 +++++++++++++++++++++++++++++-
>  net/mptcp/protocol.h |  2 +-
>  net/mptcp/subflow.c  |  4 ++--
>  3 files changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index c96489c5c875..c28c5cc49d65 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -201,17 +201,45 @@ static bool __mptcp_move_skbs_from_subflow(struct mptcp_sock *msk,
>  	return done;
>  }
>  
> -void mptcp_data_ready(struct sock *sk)
> +/* In most cases we will be able to lock the mptcp socket.  If its already
> + * owned, we need to defer to the work queue to avoid ABBA deadlock.
> + */
> +static bool move_skbs_to_msk(struct mptcp_sock *msk, struct sock *ssk)
> +{
> +	struct sock *sk = (struct sock *)msk;
> +	unsigned int moved = 0;
> +
> +	if (sock_owned_by_user_nocheck(sk))
> +		return false;
> +
> +	if (unlikely(!spin_trylock_bh(&sk->sk_lock.slock)))
> +		return false;
> +
> +	/* must re-check after taking the lock */
> +	if (!sock_owned_by_user_nocheck(sk))

Don't we additionally need a READ_ONCE() here and above ?
Otherwise the compiler and/or CPU could merge the read?

AFAICS sock_owned_by_user_nocheck() does not include the additional
annotation.

I think we could simply drop the first check (and always do the
trylock)

Cheers,

Paolo

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [MPTCP] Re: [PATCH net-next 6/8] mptcp: avoid work queue scheduling if possible
@ 2020-02-25 12:51 Florian Westphal
  0 siblings, 0 replies; 3+ messages in thread
From: Florian Westphal @ 2020-02-25 12:51 UTC (permalink / raw)
  To: mptcp 

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

Paolo Abeni <pabeni(a)redhat.com> wrote:
> > +/* In most cases we will be able to lock the mptcp socket.  If its already
> > + * owned, we need to defer to the work queue to avoid ABBA deadlock.
> > + */
> > +static bool move_skbs_to_msk(struct mptcp_sock *msk, struct sock *ssk)
> > +{
> > +	struct sock *sk = (struct sock *)msk;
> > +	unsigned int moved = 0;
> > +
> > +	if (sock_owned_by_user_nocheck(sk))
> > +		return false;
> > +
> > +	if (unlikely(!spin_trylock_bh(&sk->sk_lock.slock)))
> > +		return false;
> > +
> > +	/* must re-check after taking the lock */
> > +	if (!sock_owned_by_user_nocheck(sk))
> 
> Don't we additionally need a READ_ONCE() here and above ?
> Otherwise the compiler and/or CPU could merge the read?

Oh, right, at least first check needs READ_ONCE annotation, thanks.

> AFAICS sock_owned_by_user_nocheck() does not include the additional
> annotation.
> 
> I think we could simply drop the first check (and always do the
> trylock)

The trylock would succeed however when socket is owned, leading to
a uneeded lock operation.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [MPTCP] Re: [PATCH net-next 6/8] mptcp: avoid work queue scheduling if possible
@ 2020-02-25 12:55 Florian Westphal
  0 siblings, 0 replies; 3+ messages in thread
From: Florian Westphal @ 2020-02-25 12:55 UTC (permalink / raw)
  To: mptcp 

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

Florian Westphal <fw(a)strlen.de> wrote:
> +void mptcp_data_ready(struct sock *sk, struct sock *ssk)
>  {
>  	struct mptcp_sock *msk = mptcp_sk(sk);
>  
>  	set_bit(MPTCP_DATA_READY, &msk->flags);
>  	sk->sk_data_ready(sk);
>  
> +	if (atomic_read(&sk->sk_rmem_alloc) < READ_ONCE(sk->sk_rcvbuf) &&
> +	    move_skbs_to_msk(msk, ssk))
> +		return;
> +

It just occured to me that it might be better to move the
sk->sk_data_ready(sk); call to the end of mptcp_data_ready(),
I would do this for next iteration.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-02-25 12:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-25 12:51 [MPTCP] Re: [PATCH net-next 6/8] mptcp: avoid work queue scheduling if possible Florian Westphal
  -- strict thread matches above, loose matches on Subject: below --
2020-02-25 12:55 Florian Westphal
2020-02-25 12:40 Paolo Abeni

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.