linux-kernel - Re: [PATCH] cgroup: reorder flexible array members of struct cgroup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 18 Oct 2017 06:30:10 -0700
From:   Tejun Heo <tj@...nel.org>
To:     Nick Desaulniers <nick.desaulniers@...il.com>
Cc:     Li Zefan <lizefan@...wei.com>,
        Johannes Weiner <hannes@...xchg.org>, cgroups@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cgroup: reorder flexible array members of struct
 cgroup_root

Hello,

On Mon, Oct 16, 2017 at 11:33:21PM -0700, Nick Desaulniers wrote:
> When compiling arch/x86/boot/compressed/eboot.c with HOSTCC=clang, the
> following warning is observed:
> 
> ./include/linux/cgroup-defs.h:391:16: warning: field 'cgrp' with
> variable sized type 'struct cgroup' not at the end of a struct or class
> is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
>         struct cgroup cgrp;
>                       ^
> Flexible array members are a C99 feature, but must be the last member of
> a struct. Structs with flexible members composed in other structs must
> also be the final members, unless using GNU C extensions.
> 
> struct cgroup_root's member cgrp is a struct cgroup, struct cgroup's
> member ancestor_ids is a flexible member.

This is silly tho.  We know the the root group embedded there won't
have any ancestor_ids.  Also, in general, nothing prevents us from
doing something like the following.

	struct outer_struct {
		blah blah;
		struct inner_struct_with_flexible_array_member inner;
		unsigned long storage_for_flexible_array[NR_ENTRIES];
		blah blah;
	};

I think we should just silence the bogus warning.

Thanks.

-- 
tejun