2024-12-16, 15:09:17 +0100, Antonio Quartulli wrote:
> On 16/12/2024 14:59, Sabrina Dubroca wrote:
> > 2024-12-11, 22:15:15 +0100, Antonio Quartulli wrote:
> > > +static void ovpn_tcp_close(struct sock *sk, long timeout)
> > > +{
> > > + struct ovpn_socket *sock;
> > > +
> > > + rcu_read_lock();
> >
> > [can't sleep until unlock]
> >
> > > + sock = rcu_dereference_sk_user_data(sk);
> > > +
> > > + strp_stop(&sock->peer->tcp.strp);
> > > +
> > > + tcp_close(sk, timeout);
> >
> >
> > void tcp_close(struct sock *sk, long timeout)
> > {
> > lock_sock(sk);
> >
> > but this can sleep.
>
> Ouch.. I wonder why I have never seen the might_sleep() trigger this, but
> probably that's due to the fact that we hardly hit this cb in the classic
> use case.
Probably. You'd only see it when you close the TCP socket before
detaching (otherwise the close CB is restored to tcp_close), which I
guess ovpn never does.
>
> >
> > Is there anything that prevents delaying tcp_close until after
> > ovpn_peer_del and rcu_read_unlock?
>
> not really.
>
> >
> > > + ovpn_peer_del(sock->peer, OVPN_DEL_PEER_REASON_TRANSPORT_ERROR);
> > > + rcu_read_unlock();
>
> I will move the tcp_close() here.
Thanks.
--
Sabrina
