[PATCH v3] nvme-tcp: fix a possible UAF when failing to allocate an io queue

[Chaitanya Kulkarni]

> +static void nvme_tcp_setup_sock_ops(struct nvme_tcp_queue *queue)
> +{
> +	write_lock_bh(&queue->sock->sk->sk_callback_lock);
> +	queue->sock->sk->sk_user_data = queue;
> +	queue->state_change = queue->sock->sk->sk_state_change;
> +	queue->data_ready = queue->sock->sk->sk_data_ready;
> +	queue->write_space = queue->sock->sk->sk_write_space;
> +	queue->sock->sk->sk_data_ready = nvme_tcp_data_ready;
> +	queue->sock->sk->sk_state_change = nvme_tcp_state_change;
> +	queue->sock->sk->sk_write_space = nvme_tcp_write_space;
> +#ifdef CONFIG_NET_RX_BUSY_POLL
> +	queue->sock->sk->sk_ll_usec = 1;
> +#endif
> +	write_unlock_bh(&queue->sock->sk->sk_callback_lock);
> +}
> +

since its is not in the fast path, is there a particular reason not
to use following ?

if (IS_ENABLED(CONFIG_NET_RX_BUSY_POLL)
	queue->sock->sk->sk_ll_usec = 1;

-ck