From: Leon Romanovsky <leon@kernel.org>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Herbert Xu <herbert@gondor.apana.org.au>,
netdev@vger.kernel.org
Subject: Re: [PATCH ipsec-next] xfrm: delete not-used XFRM_OFFLOAD_IPV6 define
Date: Tue, 1 Feb 2022 09:22:17 +0200 [thread overview]
Message-ID: <YfjfqWRVr4KpkQC8@unreal> (raw)
In-Reply-To: <20220201065836.GT1223722@gauss3.secunet.de>
On Tue, Feb 01, 2022 at 07:58:36AM +0100, Steffen Klassert wrote:
> On Thu, Jan 27, 2022 at 08:24:58PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > XFRM_OFFLOAD_IPV6 define was exposed in the commit mentioned in the
> > fixes line, but it is never been used both in the kernel and in the
> > user space. So delete it.
>
> How can you be sure that is is not used in userspace? At least some
> versions of strongswan set that flag. So even if it is meaningless
> in the kernel, we can't remove it.
I looked over all net/* and include/uapi/* code with "git log -p" and didn't
see any use of this flag ever.
Looking in strongsswan, I see that they bring kernel header files [1] for the build
and removal won't break build of old strongsswan versions.
We just can't use this bit anymore, because of this commit [2]. I have
no clue why it was used there.
So yes, we can remove, but worth to add a comment about old strongsswan.
And if we are talking about xfrm_user_offload flags, there is a
well-known API mistake in xfrm_dev_state_add() of not checking validity
of flags. So *theoretically* we can find some software in the wild that
uses other bits too.
I would like to see it is fixed.
[1] 5bfae68670f2 ("include: Update xfrm.h to include hardware offloading extensions")
[2] d42948fc057e ("kernel-netlink: Enable hardware offloading if configured for an SA")
Thanks
>
> >
> > Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API")
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> > include/uapi/linux/xfrm.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
> > index 4e29d7851890..2c822671cc32 100644
> > --- a/include/uapi/linux/xfrm.h
> > +++ b/include/uapi/linux/xfrm.h
> > @@ -511,7 +511,6 @@ struct xfrm_user_offload {
> > int ifindex;
> > __u8 flags;
> > };
> > -#define XFRM_OFFLOAD_IPV6 1
> > #define XFRM_OFFLOAD_INBOUND 2
> >
> > struct xfrm_userpolicy_default {
> > --
> > 2.34.1
next prev parent reply other threads:[~2022-02-01 7:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 18:24 [PATCH ipsec-next] xfrm: delete not-used XFRM_OFFLOAD_IPV6 define Leon Romanovsky
2022-02-01 6:58 ` Steffen Klassert
2022-02-01 7:22 ` Leon Romanovsky [this message]
2022-02-01 7:53 ` Leon Romanovsky
2022-02-03 6:49 ` Steffen Klassert
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=YfjfqWRVr4KpkQC8@unreal \
--to=leon@kernel.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.