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]

Message-ID: <20171021160308.GN1302522@devbig577.frc2.facebook.com>
Date:   Sat, 21 Oct 2017 09:03:08 -0700
From:   Tejun Heo <tj@...nel.org>
To:     Aleksa Sarai <asarai@...e.de>
Cc:     Nick Desaulniers <nick.desaulniers@...il.com>,
        Li Zefan <lizefan@...wei.com>,
        Johannes Weiner <hannes@...xchg.org>, cgroups@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Michael Davidson <md@...gle.com>,
        Greg Hackmann <ghackmann@...gle.com>, android-llvm@...gle.com
Subject: Re: [PATCH] cgroup: reorder flexible array members of struct
 cgroup_root

On Sun, Oct 22, 2017 at 02:59:33AM +1100, Aleksa Sarai wrote:
> >Here, not necessarily but I don't want to move it for a bogus reason.
> >Why would we disallow embedding structs with flexible members in the
> >middle when it can be done and is useful?  If we want to discuss
> >whether we want to avoid such usages in the kernel (but why?), sure,
> >let's have that discussion but we can't decide that on "clang warns on
> >it by default".
> 
> There was a talk a few years ago by the clang folks[1] saying that
> while trying to build a kernel with clang, they discovered that
> several places in the kernel uses "VLAIS" (variable Length Arrays In
> Structs") and argued that this is a violation of the C
> specification, despite it being a GNU extension. They also submitted
> several patches that removed this code (even working around a
> user-space visible usage of VLAIS).

The kernel is explicitly using GNU extended version of C and has
always from the beginning, so not-std-c isn't a valid argument.

Thanks.

-- 
tejun