[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210725162528.GK9904@breakpoint.cc>
Date: Sun, 25 Jul 2021 18:25:28 +0200
From: Florian Westphal <fw@...len.de>
To: Paul Moore <paul@...l-moore.com>
Cc: Florian Westphal <fw@...len.de>, Paolo Abeni <pabeni@...hat.com>,
Casey Schaufler <casey@...aufler-ca.com>,
netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
linux-security-module@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH RFC 0/9] sk_buff: optimize layout for GRO
Paul Moore <paul@...l-moore.com> wrote:
> > There is the skb extension infra, does that work for you?
>
> I was hopeful that when the skb_ext capability was introduced we might
> be able to use it for the LSM(s), but when I asked netdev if they
> would be willing to accept patches to leverage the skb_ext
> infrastructure I was told "no".
I found
https://lore.kernel.org/netdev/CAHC9VhSz1_KA1tCJtNjwK26BOkGhKGbPT7v1O82mWPduvWwd4A@mail.gmail.com/#r
and from what I gather from your comments and that of Casey
I think skb extensions is the correct thing for this (i.e., needs
netlabel/secid config/enablement so typically won't be active on
a distro kernel by default).
It certainly makes more sense to me than doing lookups
in a hashtable based on a ID (I tried to do that to get rid of skb->nf_bridge
pointer years ago and it I could not figure out how to invalidate an entry
without adding a new skb destructor callback).
Powered by blists - more mailing lists