From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave Watson <davejwatson@fb.com>
Subject: Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
Date: Mon, 23 Jul 2018 09:35:09 -0700
Message-ID: <20180723163509.GA91424@davejwatson-mba.local>
References: <20180719162613.27184-1-vakul.garg@nxp.com>
 <20180719162613.27184-4-vakul.garg@nxp.com>
 <20180721.192532.520509909556885779.davem@davemloft.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: <vakul.garg@nxp.com>, <netdev@vger.kernel.org>,
        <borisp@mellanox.com>, <aviadye@mellanox.com>,
        Doron Roberts-Kedes <doronrk@fb.com>
To: David Miller <davem@davemloft.net>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:57768 "EHLO
        mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-FAIL)
        by vger.kernel.org with ESMTP id S2388261AbeGWRhs (ORCPT
        <rfc822;netdev@vger.kernel.org>); Mon, 23 Jul 2018 13:37:48 -0400
Content-Disposition: inline
In-Reply-To: <20180721.192532.520509909556885779.davem@davemloft.net>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On 07/21/18 07:25 PM, David Miller wrote:
> From: Vakul Garg <vakul.garg@nxp.com>
> Date: Thu, 19 Jul 2018 21:56:13 +0530
> 
> > In function decrypt_skb(), array allocation in case when sgout is NULL
> > is unnecessary. Instead, local variable sgin_arr[] can be used.
> > 
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> 
> Hmmm...
> 
> Dave, can you take a look at this?  Do you think there might have
> been a reason you felt that you needed to dynamically allocate
> the scatterlists when you COW and skb and do in-place decryption?
> 
> I guess this change is ok, nsg can only get smaller when the SKB
> is COW'd.
> 

> >         memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
> >         if (!sgout) {
> >                 nsg = skb_cow_data(skb, 0, &unused) + 1;
> > -               sgin = kmalloc_array(nsg, sizeof(*sgin), sk->sk_allocation);
> >                 sgout = sgin;
> >         }

I don't think this patch is safe as-is.  sgin_arr is a stack array of
size MAX_SKB_FRAGS (+ overhead), while my read of skb_cow_data is that
it walks the whole chain of skbs from skb->next, and can return any
number of segments.  Therefore we need to heap allocate.  I think I
copied the IPSEC code here.

For perf though, we could use the stack array if skb_cow_data returns
<= MAX_SKB_FRAGS.

This code is slightly confusing though, since we don't heap allocate
in the zerocopy case - what happens is that skb_to_sgvec returns
-EMSGSIZE, and we fall back to the non-zerocopy case, and return again
to this function, where we then hit the skb_cow_data path and heap
allocate.