lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <A3B90CCA-6C9F-4459-AE11-02AB93BDF25A@oracle.com>
Date:   Fri, 20 May 2022 16:39:50 +0000
From:   Chuck Lever III <chuck.lever@...cle.com>
To:     Hannes Reinecke <hare@...e.de>
CC:     Alexander Krizhanovsky <ak@...pesta-tech.com>,
        Boris Pismenny <borisp@...dia.com>,
        netdev <netdev@...r.kernel.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        CIFS <linux-cifs@...r.kernel.org>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH RFC 2/5] tls: build proto after context has been
 initialized



> On Apr 18, 2022, at 12:49 PM, Chuck Lever <chuck.lever@...cle.com> wrote:
> 
> From: Hannes Reinecke <hare@...e.de>
> 
> We have to build the proto ops only after the context has been
> initialized, as otherwise we might crash when I/O is ongoing
> during initialisation.
> 
> Signed-off-by: Hannes Reinecke <hare@...e.de>
> Signed-off-by: Chuck Lever <chuck.lever@...cle.com>
> ---
> net/tls/tls_main.c |    3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
> index 7b2b0e7ffee4..7eca4d9a83c4 100644
> --- a/net/tls/tls_main.c
> +++ b/net/tls/tls_main.c
> @@ -836,8 +836,6 @@ static int tls_init(struct sock *sk)
> 	struct tls_context *ctx;
> 	int rc = 0;
> 
> -	tls_build_proto(sk);
> -
> #ifdef CONFIG_TLS_TOE
> 	if (tls_toe_bypass(sk))
> 		return 0;
> @@ -862,6 +860,7 @@ static int tls_init(struct sock *sk)
> 
> 	ctx->tx_conf = TLS_BASE;
> 	ctx->rx_conf = TLS_BASE;
> +	tls_build_proto(sk);
> 	update_sk_prot(sk, ctx);
> out:
> 	write_unlock_bh(&sk->sk_callback_lock);
> 
> 

While we're working on a better upcall mechanism, I'm dropping
this one from the series. tls_build_proto() can grab a mutex,
so tls_init() can't call it while holding sk_callback_lock.


--
Chuck Lever



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ