netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net, borisp@nvidia.com,
	secdev@chelsio.com
Subject: Re: [PATCH net] net/tls: Fix kernel panic when socket is in TLS ULP
Date: Wed, 11 Nov 2020 01:19:24 +0530	[thread overview]
Message-ID: <4fdc9dd2-fbdf-2d5e-9836-74cb8dd3062c@chelsio.com> (raw)
In-Reply-To: <20201110082832.4ef61eff@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>



On 11/10/2020 9:58 PM, Jakub Kicinski wrote:
> On Tue, 10 Nov 2020 10:37:11 +0530 Vinay Kumar Yadav wrote:
>> It is not incompatible. It fits in k.org tls infrastructure (TLS-TOE
>> mode). For the current issue we have proposed a fix. What is the issue
>> with proposed fix, can you elaborate and we will address that?
> 
> Your lack of understanding of how netdev offloads are supposed to work
> is concerning. Application is not supposed to see any difference
> between offloaded and non-offloaded modes of operation.
> 
For application point of view there won't be any difference.
kernel tls in tcp offload mode works exactly similar to software
kTLS.

> Your offload was accepted based on the assumption that it works like
> the software kernel TLS mode. Nobody had the time to look at your
> thousands lines of driver code at the time.
> 
> Now you're telling us that the uAPI for the offload is completely
> different - it only works on listening sockets while software tls
> only works on established sockets. Ergo there is no software fallback
> for your offload.
>
We can consider adding the capability to working with established 
sockets.The TOE has not needed that capability to date since it can 
establish the socket itself, but it makes sense to provide uniformity 
with the kTLS approach so we will look into that.  For now, as you 
suggested replacing stack listen with toe listen makes more sense.

> Furthermore the severity of the bugs you just started to fix now, after
> the code has been in the kernel for over a year suggests there are no
> serious users and we can just remove this code.
> 
It’s been a slow process but with the new team it is picking up speed
and the quality of the code will continue to get better.

      reply	other threads:[~2020-11-10 19:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-03 10:47 [PATCH net] net/tls: Fix kernel panic when socket is in TLS ULP Vinay Kumar Yadav
2020-11-05  1:16 ` Jakub Kicinski
2020-11-05 17:50   ` Vinay Kumar Yadav
2020-11-05 17:53     ` Jakub Kicinski
2020-11-05 18:25       ` Vinay Kumar Yadav
2020-11-05 18:46         ` Jakub Kicinski
2020-11-06 20:32           ` Vinay Kumar Yadav
2020-11-06 20:28             ` Jakub Kicinski
2020-11-09 18:51               ` Vinay Kumar Yadav
2020-11-09 18:58                 ` Jakub Kicinski
2020-11-10  5:07                   ` Vinay Kumar Yadav
2020-11-10  5:58                     ` Vinay Kumar Yadav
2020-11-10 16:28                     ` Jakub Kicinski
2020-11-10 19:49                       ` Vinay Kumar Yadav [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4fdc9dd2-fbdf-2d5e-9836-74cb8dd3062c@chelsio.com \
    --to=vinay.yadav@chelsio.com \
    --cc=borisp@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=secdev@chelsio.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).