From mboxrd@z Thu Jan 1 00:00:00 1970 From: Behan Webster Subject: Re: [PATCH v2] net: netfilter: LLVMLinux: vlais-netfilter Date: Tue, 18 Mar 2014 10:37:58 -0700 Message-ID: <53288476.10801@converseincode.com> References: <022D9517-4804-47BB-B789-CCF25F25C1ED@me.com> <1395123121-27053-1-git-send-email-behanw@converseincode.com> <063D6719AE5E284EB5DD2968C1650D6D0F6E0065@AcuExch.aculab.com> <53285C79.2060907@converseincode.com> <063D6719AE5E284EB5DD2968C1650D6D0F6E0286@AcuExch.aculab.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=converseincode.com; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PlOH0VthwGxaQFV2oGrU9d28/tWbE4DYPdEHUJj5Okw=; b=E+kmeywa3r3EfqmuiKV1viLzNTCSmKXSQ6FItfNrnLeDaCssWAxZqOZMSlq8RWr2IH Tp/gZ6782h5scz1dkDoDJrggvbvocr/Xa8z39JeKwBpXIqe4fH3vOySvuS90jlzAui/I 5MgxYfBcqlnqoM8JKlZru3rXyjA05vz4CZ1Us= In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6E0286@AcuExch.aculab.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: David Laight , "davem@davemloft.net" Cc: "pablo@netfilter.org" , "kaber@trash.net" , "kadlec@blackhole.kfki.hu" , "netfilter-devel@vger.kernel.org" , "netfilter@vger.kernel.org" , "coreteam@netfilter.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dwmw2@infradead.org" , "pageexec@freemail.hu" , Mark Charlebois , =?UTF-8?B?Vmluw61jaXVzIFRpbnRp?= On 03/18/14 08:24, David Laight wrote: > From: Behan Webster >> On 03/18/14 02:41, David Laight wrote: >>> From: behanw@converseincode.com >>>> From: Mark Charlebois >>>> >>>> Replaced non-standard C use of Variable Length Arrays In Structs (VLAIS) in >>>> xt_repldata.h with a C99 compliant flexible array member and then calculated >>>> offsets to the other struct members. These other members aren't referenced by >>>> name in this code, however this patch maintains the same memory layout and >>>> padding as was previously accomplished using VLAIS. >>>> >>>> Had the original structure been ordered differently, with the entries VLA at >>>> the end, then it could have been a flexible member, and this patch would have >>>> been a lot simpler. However since the data stored in this structure is >>>> ultimately exported to userspace, the order of this structure can't be changed. >>> Why not just remove the last element and allocate space for it after the >>> structure? >> Because that would still be employing VLAIS to solve the problem. The >> last element may be a zero-length array (a flexible member), not a VLA. >> Sadly both the last 2 elements in the struct need to be manually >> calculated, which is what we've done. > So make the last element a 'flexible member' and then work out where > the final field goes. > Something like: > struct p { > struct a a; > struct b b[]; > } p = malloc(sizeof *p + n * sizeof (struct b) + alignof (struct c) > + sizeof (struct c); > struct c *c = (void *)&p->b[n] + (-offsetof(struct p, b[n]) & (alignof(struct c) - 1); Oh, I see. Will fix. Thanks! Behan -- Behan Webster behanw@converseincode.com