Re: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

[Daniel Borkmann]

On 11/23/2015 02:43 PM, Daniel Borkmann wrote:
> On 11/21/2015 07:54 PM, Florian Westphal wrote:
> > Tejun Heo <tj@xxxxxxxxxx> wrote:
> > > On Sat, Nov 21, 2015 at 05:56:06PM +0100, Florian Westphal wrote:
> > > > > +struct xt_cgroup_info_v1 {
> > > > > +    __u8        has_path;
> > > > > +    __u8        has_classid;
> > > > > +    __u8        invert_path;
> > > > > +    __u8        invert_classid;
> > > > > +    char        path[PATH_MAX];
> > > > > +    __u32        classid;
> > > > > +
> > > > > +    /* kernel internal data */
> > > > > +    void        *priv __attribute__((aligned(8)));
> > > > > +};
> > > >
> > > > Ahem.  Am I reading this right? This struct is > 4k in size?
> > > > If so -- Ugh.  Does sizeof(path) really have to be PATH_MAX?
> > >
> > > Hmmm... yeap but would this be an acutual problem?
> >
> > Since rule blob can be allocated via vmalloc i guess "no", its not
> > really a problem unless someone needs realy insane amount of such rules.
> >
> > I don't have any better suggestion, so I guess its necessary evil.
> >
> > The only other question I have is wheter PATH_MAX might be a possible
> > ABI breaker in future.  It would have to be guaranteed that this is the
> > same size forever, else you'd get strange errors on rule insertion if
> > the sizes of the kernel and userspace version differs.
>
> Haven't looked deeply into kernfs, but if it's possible to get the object
> from the struct file eventually, you could let iptables frontend open that
> path and just pass the fd down. Would be sizeof(int) vs PATH_MAX then, i.e.
> when you have a large number of rules to load.

( ... but with the downside that things like save/restore wouldn't work. )
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/