[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210315104350.GY62598@gauss3.secunet.de>
Date: Mon, 15 Mar 2021 11:43:50 +0100
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Antony Antony <antony.antony@...unet.com>
CC: Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Yossi Kuperman <yossiku@...lanox.com>,
Guy Shapiro <guysh@...lanox.com>, <netdev@...r.kernel.org>,
<antony@...nome.org>
Subject: Re: [PATCH] xfrm: return error when esp offload is requested and not
supported
On Wed, Mar 10, 2021 at 10:36:11AM +0100, Antony Antony wrote:
> When ESP offload is not supported by the device return an error,
> -EINVAL, instead of silently ignoring it, creating a SA without offload,
> and returning success.
>
> with this fix ip x s a would return
> RTNETLINK answers: Invalid argument
>
> Also, return an error, -EINVAL, when CONFIG_XFRM_OFFLOAD is
> not defined and the user is trying to create an SA with the offload.
>
> Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API")
> Signed-off-by: Antony Antony <antony.antony@...unet.com>
I feal a bit unease about this one. When we designed the offloading
API, we decided to fallback to software if HW offload is not available.
Not sure if that was a good idea, but changing this would also change
the userspace ABI. So if we change this, we should at least not
consider it as a fix because it would be backported to -stable
in that case. Thoughts?
Powered by blists - more mailing lists