On Fri, 28 Jun 2019 17:59:25 -0700, Jakub Kicinski wrote:
> > > Sorry for all the questions, I'm not really able to fully wrap my head
> > > around this. I also feel like I'm missing the sockmap piece that may
> > > be why you prefer unhash over disconnect.
> >
> > Yep, if we try to support li
On Fri, 28 Jun 2019 17:20:23 -0700, John Fastabend wrote:
> > Why can't tls sockets exist outside of established state? If shutdown
> > doesn't call close, perhaps we can add a shutdown callback? It doesn't
> > seem to be called from BH?
> >
>
> Because the ulp would be shared in this case,
>
Jakub Kicinski wrote:
> On Fri, 28 Jun 2019 12:40:29 -0700, John Fastabend wrote:
> > The lock() is already held when entering unhash() side so need to
> > handle this case as well,
> >
> > CPU 0 (free) CPU 1 (wq)
> >
> > lock(sk) ctx = tls_get_ctx(sk) <- need to be check nu
On Fri, 28 Jun 2019 12:40:29 -0700, John Fastabend wrote:
> The lock() is already held when entering unhash() side so need to
> handle this case as well,
>
> CPU 0 (free) CPU 1 (wq)
>
> lock(sk) ctx = tls_get_ctx(sk) <- need to be check null ptr
> sk_prot->unhash()
> set_b
Jakub Kicinski wrote:
> On Fri, 28 Jun 2019 07:12:07 -0700, John Fastabend wrote:
> > Yeah seems possible although never seen in my testing. So I'll
> > move the test_bit() inside the lock and do a ctx check to ensure
> > still have the reference.
> >
> > CPU 0 (free) CPU 1 (wq)
> >
>
On Fri, 28 Jun 2019 07:12:07 -0700, John Fastabend wrote:
> Yeah seems possible although never seen in my testing. So I'll
> move the test_bit() inside the lock and do a ctx check to ensure
> still have the reference.
>
> CPU 0 (free) CPU 1 (wq)
>
> lock(sk)
>
Jakub Kicinski wrote:
> On Thu, 27 Jun 2019 10:36:42 -0700, John Fastabend wrote:
> > The tls close() callback currently drops the sock lock, makes a
> > cancel_delayed_work_sync() call, and then relocks the sock. This
> > seems suspect at best. The lock_sock() is applied to stop concurrent
> > ope
On Thu, 27 Jun 2019 10:36:42 -0700, John Fastabend wrote:
> The tls close() callback currently drops the sock lock, makes a
> cancel_delayed_work_sync() call, and then relocks the sock. This
> seems suspect at best. The lock_sock() is applied to stop concurrent
> operations on the socket while tear
The tls close() callback currently drops the sock lock, makes a
cancel_delayed_work_sync() call, and then relocks the sock. This
seems suspect at best. The lock_sock() is applied to stop concurrent
operations on the socket while tearing the sock down. Further we
will need to add support for unhash(
