[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <iy3wkjdtudq4m763oji7bhj6w7bj2pdst7sbtahtwgcjrhpx6i@a4cy47mlcnqf>
Date: Mon, 24 Mar 2025 19:01:14 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: netfilter-devel@...r.kernel.org, coreteam@...filter.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Jozsef Kadlecsik <kadlec@...filter.org>, "David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, cgroups@...r.kernel.org,
Jan Engelhardt <ej@...i.de>, Florian Westphal <fw@...len.de>
Subject: Re: [PATCH v2] netfilter: Make xt_cgroup independent from net_cls
On Mon, Mar 24, 2025 at 05:49:09PM +0100, Pablo Neira Ayuso <pablo@...filter.org> wrote:
> If !CONFIG_CGROUP_NET_CLASSID, then no classid matching is possible.
>
> So why allow a rule to match on cgroup with classid == 0?
It is conservative approach to supposed users who may have filtering
rules with classid=0 but never mkdir any net_cls group. Only those who
eventually need to mkdir would realize there's nowhere to mkdir on (with
!CONFIG_CGROUP_NET_CLASSID). Admittedly, I have no idea if this helps to
5% of net_cls users or 0.05% or 0%. Do you have any insights into that?
> Maybe simply do this instead?
>
> static bool possible_classid(u32 classid)
> {
> return IS_ENABLED(CONFIG_CGROUP_NET_CLASSID);
> }
Yes, if the above carefulness is unnecessary, I'd like to accompany this
with complete removal of sock_cgroup_classid() function then (to have it
compile-checked that it's really impossible to compare any classids w/o
CONFIG_CGROUP_NET_CLASSID).
Thanks,
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists