> -----Original Message----- > From: [email protected] <linux-acpi- > [email protected]> On Behalf Of Kees Cook > Sent: Wednesday, May 20, 2020 8:41 AM > To: Rafael J. Wysocki <[email protected]> > Cc: Gustavo A. R. Silva <[email protected]>; Moore, Robert > <[email protected]>; Kaneda, Erik <[email protected]>; Wysocki, > Rafael J <[email protected]>; Len Brown <[email protected]>; ACPI > Devel Maling List <[email protected]>; open list:ACPI COMPONENT > ARCHITECTURE (ACPICA) <[email protected]>; Linux Kernel Mailing List > <[email protected]>; Gustavo A. R. Silva > <[email protected]> > Subject: Re: [PATCH] ACPICA: Replace one-element array and use > struct_size() helper > > On Wed, May 20, 2020 at 11:15:18AM +0200, Rafael J. Wysocki wrote: > > On Wed, May 20, 2020 at 12:46 AM Gustavo A. R. Silva > > <[email protected]> wrote: > > > > > > On Tue, May 19, 2020 at 12:25:13PM +0200, Rafael J. Wysocki wrote: > > > > On Tue, May 19, 2020 at 12:22 AM Gustavo A. R. Silva > > > > <[email protected]> wrote: > > > > > > > > > > The current codebase makes use of one-element arrays in the > > > > > following > > > > > form: > > > > > > > > > > struct something { > > > > > int length; > > > > > u8 data[1]; > > > > > }; > > > > > > > > > > struct something *instance; > > > > > > > > > > instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL); > > > > > instance->length = size; > > > > > memcpy(instance->data, source, size); > > > > > > > > > > but the preferred mechanism to declare variable-length types > > > > > such as these ones is a flexible array member[1][2], introduced in > > > > > C99: > > > > > > > > > > struct foo { > > > > > int stuff; > > > > > struct boo array[]; > > > > > }; > > > > > > > > > > By making use of the mechanism above, we will get a compiler > > > > > warning in case the flexible array does not occur last in the > > > > > structure, which will help us prevent some kind of undefined > > > > > behavior bugs from being inadvertently introduced[3] to the > codebase from now on. > > > > > > > > However, the ACPICA code in the kernel comes from an external > > > > project and changes of this type are generally not applicable to > > > > it unless accepted upstream. > > > > > > Hi Rafael, > > > > > > By _accepted upstream_, in this case, you mean the adoption of the > > > flexible-arrays in the whole codebase, first? > > > > I meant whether or not the patch is accepted by the ACPICA upstream. > > Is that here? https://github.com/acpica/acpica/commits/master > > > > > > If this is the case > > > notice that there are hundreds of these flexible-array conversions > > > in mainline, already: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/l > > > og/?qt=grep&q=flexible-array > > > > > > Is this what you mean? > > > > I'm not actually sure what you mean here. > > I think this was just a misunderstanding about what "upstream" meant. :) > > I hope ACPICA will take these changes -- it seems like we keep running into > these issues with the kernel's language feature clean-ups and ACPICA > upstream, though each have been resolved so far! :) Flexible array members > are a C99 feature, so it's hardly a new way to express things. > In fact, it looks like ACPICA already builds with -c99 by default: > https://github.com/acpica/acpica/blob/master/generate/unix/Makefile.conf > ig#L202 > https://github.com/acpica/acpica/blob/master/generate/efi/Makefile.config > #L93 > > MSVC has supported them (called "unsized arrays") since 7.1 in 2003. > > Gustavo, can you build a merge request for the ACPICA project directly? The flexible array members will be fine. The struct_size helper uses the typeof operator which is a GCC extension. ACPICA codebase is intended to be compiled by many different compilers (not just GCC and MSVC) so we cannot support struct_size. Erik > > -- > Kees Cook
