Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932095AbbKWRiD (ORCPT ); Mon, 23 Nov 2015 12:38:03 -0500 Received: from smtp-out6.electric.net ([192.162.217.184]:61517 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754698AbbKWRiA convert rfc822-to-8bit (ORCPT ); Mon, 23 Nov 2015 12:38:00 -0500 From: David Laight To: "'Florian Westphal'" , Tejun Heo CC: "davem@davemloft.net" , "pablo@netfilter.org" , "kaber@trash.net" , "kadlec@blackhole.kfki.hu" , "daniel@iogearbox.net" , "daniel.wagner@bmw-carit.de" , "nhorman@tuxdriver.co" , "lizefan@huawei.com" , "hannes@cmpxchg.org" , "netdev@vger.kernel.org" , "netfilter-devel@vger.kernel.org" , "coreteam@netfilter.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 Thread-Topic: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match Thread-Index: AQHRJHfCboQaLKDdxU+0xUpIYdAX2p6mshYAgAMvNyA= Date: Mon, 23 Nov 2015 17:35:56 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CBDA8E2@AcuExch.aculab.com> References: <1448122441-9335-1-git-send-email-tj@kernel.org> <1448122441-9335-10-git-send-email-tj@kernel.org> <20151121165605.GC25336@breakpoint.cc> In-Reply-To: <20151121165605.GC25336@breakpoint.cc> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 867 Lines: 28 From: Florian Westphal > Sent: 21 November 2015 16:56 > > +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? I've not looked at the use, but could you put 'char path[];' as the last member an require any allocations to be long enough to contain the actual path? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/