Date:   Mon, 27 Feb 2023 15:53:52 -0800
From:   Jakub Kicinski <kuba@kernel.org>
To:     Eric Dumazet <edumazet@google.com>
Cc:     syzbot <syzbot+9c0268252b8ef967c62e@syzkaller.appspotmail.com>,
        borisp@nvidia.com, bpf@vger.kernel.org, davem@davemloft.net,
        john.fastabend@gmail.com, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, pabeni@redhat.com,
        syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [net?] INFO: task hung in tls_sw_sendpage (3)
Message-ID: <20230227155352.3399bb10@kernel.org>
In-Reply-To: <CANn89iJ_kLaF0tVVUfzKQwVkQ0VtCca1dL8eF+RrXCVDTK6h2Q@mail.gmail.com>
References: <000000000000e412e905f5b46201@google.com>
        <CANn89iJ_kLaF0tVVUfzKQwVkQ0VtCca1dL8eF+RrXCVDTK6h2Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Mon, 27 Feb 2023 21:35:41 +0100 Eric Dumazet wrote:
> This looks suspicious to me
> 
> commit 79ffe6087e9145d2377385cac48d0d6a6b4225a5
> Author: Jakub Kicinski <kuba@kernel.org>
> Date:   Tue Nov 5 14:24:35 2019 -0800
> 
>     net/tls: add a TX lock
> 
> 
> If tls_sw_sendpage() has to call sk_stream_wait_memory(),
> sk_stream_wait_memory() is properly releasing the socket lock,
> but knows nothing about mutex_{un}lock(&tls_ctx->tx_lock);

That's supposed to be the point of the lock, prevent new writers from
messing with the partially pushed records when the original writer
is waiting for write space.

Obvious hack but the async crypto support makes TLS a bit of a mess :|

sendpage_lock not taking tx_lock may lead to obvious problems, I'm not
seeing where the deadlock is, tho..