[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230620100843.19569d60@kernel.org>
Date: Tue, 20 Jun 2023 10:08:43 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Sagi Grimberg <sagi@...mberg.me>
Cc: Hannes Reinecke <hare@...e.de>, Christoph Hellwig <hch@....de>, Keith
Busch <kbusch@...nel.org>, linux-nvme@...ts.infradead.org, Eric Dumazet
<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
netdev@...r.kernel.org, Boris Pismenny <boris.pismenny@...il.com>
Subject: Re: [PATCH 4/4] net/tls: implement ->read_sock()
On Tue, 20 Jun 2023 16:21:22 +0300 Sagi Grimberg wrote:
> > + err = tls_rx_reader_lock(sk, ctx, true);
> > + if (err < 0)
> > + return err;
>
> Unlike recvmsg or splice_read, the caller of read_sock is assumed to
> have the socket locked, and tls_rx_reader_lock also calls lock_sock,
> how is this not a deadlock?
Yeah :|
> I'm not exactly clear why the lock is needed here or what is the subtle
> distinction between tls_rx_reader_lock and what lock_sock provides.
It's a bit of a workaround for the consistency of the data stream.
There's bunch of state in the TLS ULP and waiting for mem or data
releases and re-takes the socket lock. So to stop the flow annoying
corner case races I slapped a lock around all of the reader.
IMHO depending on the socket lock for anything non-trivial and outside
of the socket itself is a bad idea in general.
The immediate need at the time was that if you did a read() and someone
else did a peek() at the same time from a stream of A B C D you may read
A D B C.
Powered by blists - more mailing lists