psock patch

psock patch

[Hannes Reinecke]

Hi Chuck,

for the previous accept()-based patch series you had a
patch 'net: Add distinct sk_psock field', claiming that it
was required to get kTLS and any other ULP using sk_user_data
to run.
What happened to it?
Is it still required?

Reason I'm asking is that I'm seeing odd stalls during encrypted traffic
(command timeouts etc), whereas the TLS connection itself seems
to be happy.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman

Re: psock patch

[Chuck Lever III]

> On Mar 10, 2023, at 12:11 PM, Hannes Reinecke <hare@suse.de> wrote:
> 
> Hi Chuck,
> 
> for the previous accept()-based patch series you had a
> patch 'net: Add distinct sk_psock field', claiming that it
> was required to get kTLS and any other ULP using sk_user_data
> to run.
> What happened to it?

commit 2a0133723f9e ("net: fix refcount bug in sk_psock_get (2)")
in v6.0 made it safer to share the sk_user_data field, and broke
the patch that I had.


> Is it still required?

It appears to be unnecessary now for for the RPC consumers. Likely
unnecessary for anyone else using sk_user_data, but YMMV.

But as I said, my old patch won't apply after v6.0, IIRC.


> Reason I'm asking is that I'm seeing odd stalls during encrypted traffic
> (command timeouts etc), whereas the TLS connection itself seems
> to be happy.


--
Chuck Lever