From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Miller <davem@davemloft.net>
Subject: Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
Date: Mon, 23 Jul 2018 21:41:09 -0700 (PDT)
Message-ID: <20180723.214109.32924668491950691.davem@davemloft.net>
References: <20180719162613.27184-4-vakul.garg@nxp.com>
        <20180721.192532.520509909556885779.davem@davemloft.net>
        <20180723163509.GA91424@davejwatson-mba.local>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: vakul.garg@nxp.com, netdev@vger.kernel.org, borisp@mellanox.com,
        aviadye@mellanox.com, doronrk@fb.com
To: davejwatson@fb.com
Return-path: <netdev-owner@vger.kernel.org>
Received: from shards.monkeyblade.net ([23.128.96.9]:53538 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2388166AbeGXFpm (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 24 Jul 2018 01:45:42 -0400
In-Reply-To: <20180723163509.GA91424@davejwatson-mba.local>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

From: Dave Watson <davejwatson@fb.com>
Date: Mon, 23 Jul 2018 09:35:09 -0700

> 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.

Ok I see what you are saying.

So it means that, when a non-NULL sgout is passed into decrypt_skb(),
via decrypt_skb_update(), via tls_sw_recvmsg() it means that it is the
zerocopy case and you know that you only have page frags and no SKB
frag list, right?

I agree with you that this change is therefore incorrect.