From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Nick Desaulniers
<nick.desaulniers-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Michael Davidson <md-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Greg Hackmann <ghackmann-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
android-llvm-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH] cgroup: reorder flexible array members of struct cgroup_root
Date: Thu, 26 Oct 2017 07:32:22 -0700 [thread overview]
Message-ID: <20171026143222.GC59538@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <20171025215423.GD96615-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Hello,
On Wed, Oct 25, 2017 at 02:54:23PM -0700, Matthias Kaehlcke wrote:
> From your earlier comment I understand that there is no problem in
> this case because we know that cgroup_root->cgrp will always be
> empty.
>
> However in other instances the warning could point out actual errors
> in the code, so I think it is good to have this warning generally
> enabled. If cgroup_root was defined in a .c file we could consider to
> disable the warning locally, but since the definition is in a header
> that is widely included (indirectly through linux/cgroup.h and
> net/sock.h) this doesn't seem to be an option.
>
> Is there a good reason for the current position of cgrp within
> cgroup_root? If there are no drawbacks in moving it to the end of
> the struct I think Nick's patch is a reasonable solution.
This all sounds really bogus to me. Let's say we have something like
the following.
struct flex_struct {
int array[];
};
And the following two usages.
1.
struct flex_struct *fs =
kmalloc(sizeof(struct flex_struct) + N * sizeof(int));
2.
struct enclosing_struct es {
struct flex_struct fs;
int fs_array_storage[N];
};
struct enclosing_struct *es =
kmalloc(sizeof(struct enclosing_struct));
So, you're saying #1 is okay but #2 is not, which is just silly. The
compiler can't warn correctly about flex array members whether they're
embedded or not. Nothing prevents somebody accessing beyond N in #1
either.
This effort seems really pointless to me. Let's please not waste any
more bandwidth on this.
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: Nick Desaulniers <nick.desaulniers@gmail.com>,
Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
cgroups@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Michael Davidson <md@google.com>,
Greg Hackmann <ghackmann@google.com>,
android-llvm@google.com
Subject: Re: [PATCH] cgroup: reorder flexible array members of struct cgroup_root
Date: Thu, 26 Oct 2017 07:32:22 -0700 [thread overview]
Message-ID: <20171026143222.GC59538@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <20171025215423.GD96615@google.com>
Hello,
On Wed, Oct 25, 2017 at 02:54:23PM -0700, Matthias Kaehlcke wrote:
> From your earlier comment I understand that there is no problem in
> this case because we know that cgroup_root->cgrp will always be
> empty.
>
> However in other instances the warning could point out actual errors
> in the code, so I think it is good to have this warning generally
> enabled. If cgroup_root was defined in a .c file we could consider to
> disable the warning locally, but since the definition is in a header
> that is widely included (indirectly through linux/cgroup.h and
> net/sock.h) this doesn't seem to be an option.
>
> Is there a good reason for the current position of cgrp within
> cgroup_root? If there are no drawbacks in moving it to the end of
> the struct I think Nick's patch is a reasonable solution.
This all sounds really bogus to me. Let's say we have something like
the following.
struct flex_struct {
int array[];
};
And the following two usages.
1.
struct flex_struct *fs =
kmalloc(sizeof(struct flex_struct) + N * sizeof(int));
2.
struct enclosing_struct es {
struct flex_struct fs;
int fs_array_storage[N];
};
struct enclosing_struct *es =
kmalloc(sizeof(struct enclosing_struct));
So, you're saying #1 is okay but #2 is not, which is just silly. The
compiler can't warn correctly about flex array members whether they're
embedded or not. Nothing prevents somebody accessing beyond N in #1
either.
This effort seems really pointless to me. Let's please not waste any
more bandwidth on this.
Thanks.
--
tejun
next prev parent reply other threads:[~2017-10-26 14:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-17 6:33 [PATCH] cgroup: reorder flexible array members of struct cgroup_root Nick Desaulniers
2017-10-17 6:33 ` Nick Desaulniers
2017-10-17 6:40 ` Nick Desaulniers
[not found] ` <20171017064051.tudsi33f4spuyi25-i8pvpzbnxTwmroCTmvX//g@public.gmane.org>
2017-10-17 6:45 ` Nick Desaulniers
2017-10-17 6:45 ` Nick Desaulniers
2017-10-18 13:30 ` Tejun Heo
2017-10-20 7:15 ` Nick Desaulniers
[not found] ` <CAH7mPvjksNSDo4o=z51YkH4yX+gDnGXU-g59gTkOUS-pEva8sA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-10-21 15:32 ` Tejun Heo
2017-10-21 15:32 ` Tejun Heo
[not found] ` <20171021153253.GG1302522-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2017-10-21 15:59 ` Aleksa Sarai
2017-10-21 15:59 ` Aleksa Sarai
[not found] ` <85d7f6eb-7869-551d-01b1-fa1712f4bd40-l3A5Bk7waGM@public.gmane.org>
2017-10-21 16:03 ` Tejun Heo
2017-10-21 16:03 ` Tejun Heo
2017-10-21 19:08 ` Nick Desaulniers
2017-10-25 21:54 ` Matthias Kaehlcke
2017-10-25 21:54 ` Matthias Kaehlcke
[not found] ` <20171025215423.GD96615-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2017-10-26 14:32 ` Tejun Heo [this message]
2017-10-26 14:32 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171026143222.GC59538@devbig577.frc2.facebook.com \
--to=tj-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=android-llvm-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=ghackmann-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=md-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=nick.desaulniers-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.