[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180312142850.3067969f@epycfail>
Date: Mon, 12 Mar 2018 14:28:50 +0100
From: Stefano Brivio <sbrivio@...hat.com>
To: Atul Gupta <atul.gupta@...lsio.com>
Cc: davejwatson@...com, davem@...emloft.net,
herbert@...dor.apana.org.au, sd@...asysnail.net,
linux-crypto@...r.kernel.org, netdev@...r.kernel.org,
ganeshgr@...lsio.com
Subject: Re: [PATCH v10 crypto 08/11] chtls: CPL handler definition
On Sat, 10 Mar 2018 00:40:13 +0530
Atul Gupta <atul.gupta@...lsio.com> wrote:
> Exchange CPL messages with hardware to program the TLS session
> CPL handlers defined to process messages received from chip.
>
> Signed-off-by: Atul Gupta <atul.gupta@...lsio.com>
> ---
> drivers/crypto/chelsio/chtls/chtls_cm.c | 2041 +++++++++++++++++++++++++++++++
> net/ipv4/tcp_minisocks.c | 1 +
> 2 files changed, 2042 insertions(+)
> create mode 100644 drivers/crypto/chelsio/chtls/chtls_cm.c
>
> diff --git a/drivers/crypto/chelsio/chtls/chtls_cm.c b/drivers/crypto/chelsio/chtls/chtls_cm.c
>
> [...]
>
> +static void send_defer_abort_rpl(struct chtls_dev *cdev, struct sk_buff *skb)
> +{
> + struct cpl_abort_req_rss *req = cplhdr(skb);
> + struct sk_buff *reply_skb;
> +
> + reply_skb = alloc_skb(sizeof(struct cpl_abort_rpl),
> + GFP_KERNEL | __GFP_NOFAIL);
> + if (!reply_skb)
> + return;
This will never happen. By the way, is there really no way to handle a
failure here?
--
Stefano
Powered by blists - more mailing lists