From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753594AbbKWNvu (ORCPT ); Mon, 23 Nov 2015 08:51:50 -0500 Received: from www62.your-server.de ([213.133.104.62]:53090 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751429AbbKWNvt (ORCPT ); Mon, 23 Nov 2015 08:51:49 -0500 Message-ID: <565319EB.2090909@iogearbox.net> Date: Mon, 23 Nov 2015 14:51:39 +0100 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Florian Westphal , Tejun Heo CC: davem@davemloft.net, pablo@netfilter.org, kaber@trash.net, kadlec@blackhole.kfki.hu, daniel.wagner@bmw-carit.de, nhorman@tuxdriver.co, lizefan@huawei.com, hannes@cmpxchg.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, ninasc@fb.com, Neil Horman , Jan Engelhardt Subject: Re: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match References: <1448122441-9335-1-git-send-email-tj@kernel.org> <1448122441-9335-10-git-send-email-tj@kernel.org> <20151121165605.GC25336@breakpoint.cc> <20151121170425.GD3428@htj.duckdns.org> <20151121185419.GD25336@breakpoint.cc> <565317F0.2030502@iogearbox.net> In-Reply-To: <565317F0.2030502@iogearbox.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/23/2015 02:43 PM, Daniel Borkmann wrote: > On 11/21/2015 07:54 PM, Florian Westphal wrote: >> Tejun Heo 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. )