[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1495813792.6465.120.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Fri, 26 May 2017 08:49:52 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: David Miller <davem@...emloft.net>
Cc: davejwatson@...com, ilyal@...lanox.com, aviadye@...lanox.com,
borisp@...lanox.com, liranl@...lanox.com, matanb@...lanox.com,
netdev@...r.kernel.org, tom@...bertland.com,
herbert@...dor.apana.org.au, linux-crypto@...r.kernel.org,
hannes@...essinduktion.org, alexei.starovoitov@...il.com,
nmav@...lts.org, fridolin.pokorny@...il.com
Subject: Re: [PATCH net-next 3/4] tls: kernel TLS support
On Fri, 2017-05-26 at 11:18 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Fri, 26 May 2017 07:16:59 -0700
>
> > On Wed, 2017-05-24 at 09:27 -0700, Dave Watson wrote:
> >> Software implementation of transport layer security, implemented using ULP
> >> infrastructure. tcp proto_ops are replaced with tls equivalents of sendmsg and
> >> sendpage.
> >
> > ...
> >
> >> +
> >> +int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> >> +{
> > ...
> >> +
> >> + lock_sock(sk);
> >> +
> >> + /* Only one writer at a time is allowed */
> >> + if (sk->sk_write_pending)
> >> + return -EBUSY;
> >
> > Ouch...
>
> Well, as I understand it, it is the same restriction userspace must
> itself enforce either in the application or in the SSL library.
The problem here is to lock_sock(sk), then returning without releasing
the socket.
Some basic lock imbalance really.
Powered by blists - more mailing lists