[PATCH] nvmet-tcp: don't restore null sk_state_change
Alistair Francis
alistair23 at gmail.com
Wed Apr 23 14:47:02 PDT 2025
On Wed, Apr 23, 2025 at 4:21 PM Hannes Reinecke <hare at suse.de> wrote:
>
> On 4/23/25 08:06, Alistair Francis wrote:
> > queue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if
> > the TCP connection isn't established when nvmet_tcp_set_queue_sock() is
> > called then queue->state_change isn't set and sock->sk->sk_state_change
> > isn't replaced.
> >
> > As such we don't need to restore sock->sk->sk_state_change if
> > queue->state_change is NULL.
> >
> Good catch!
>
> [ .. ]
>
> > Resolves: https://lore.kernel.org/linux-nvme/5hdonndzoqa265oq3bj6iarwtfk5dewxxjtbjvn5uqnwclpwt6@a2n6w3taxxex/
> > Signed-off-by: Alistair Francis <alistair.francis at wdc.com>
> > ---
> > We could also remove the `sock->sk->sk_state != TCP_ESTABLISHED` check
> > in nvmet_tcp_set_queue_sock() if that's prefered.
> >
> Please do.
> We cannot influence what the network stack did, so if there ever were a
> modification which caused the ->state_change callback _not_ to be set
> the whole issue pops up again.
If queue->state_change isn't set for any other reason this patch
should also work, but I'll remove the `sock->sk->sk_state !=
TCP_ESTABLISHED` check as well
Alistair
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke Kernel Storage Architect
> hare at suse.de +49 911 74053 688
> SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
> HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
More information about the Linux-nvme
mailing list