[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151123154013.GB3049@mtj.duckdns.org>
Date: Mon, 23 Nov 2015 10:40:13 -0500
From: Tejun Heo <tj@...nel.org>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Florian Westphal <fw@...len.de>, davem@...emloft.net,
pablo@...filter.org, kaber@...sh.net, kadlec@...ckhole.kfki.hu,
daniel.wagner@...-carit.de, nhorman@...driver.co,
lizefan@...wei.com, hannes@...xchg.org, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org, kernel-team@...com, ninasc@...com,
Neil Horman <nhorman@...driver.com>,
Jan Engelhardt <jengelh@...i.de>
Subject: Re: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match
Hello, Daniel.
On Mon, Nov 23, 2015 at 02:43:12PM +0100, Daniel Borkmann wrote:
...
> 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.
That works in one direction but not in the other. ie. You can tell
the kernel the path that way but can't retrieve. If using path string
is unacceptable, the best alternative would be an inode number rather
than a fd; however, using an inode number would be quite cumbersome
and painful too.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists