| Message ID | ZN02iLcZYgxHFrEN@work (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,next] cgroup: Avoid -Wstringop-overflow warnings | expand |
Hello, On Wed, Aug 16, 2023 at 02:50:16PM -0600, Gustavo A. R. Silva wrote: > Change the notation from pointer-to-array to pointer-to-pointer. > With this, we avoid the compiler complaining about trying > to access a region of size zero as an argument during function > calls. Haha, I thought the functions were actually accessing the memory. This can't be an intended behavior on the compiler's side, right? Thanks.
On Wed, Aug 16, 2023 at 10:51:12AM -1000, Tejun Heo wrote: > Hello, > > On Wed, Aug 16, 2023 at 02:50:16PM -0600, Gustavo A. R. Silva wrote: > > Change the notation from pointer-to-array to pointer-to-pointer. > > With this, we avoid the compiler complaining about trying > > to access a region of size zero as an argument during function > > calls. > > Haha, I thought the functions were actually accessing the memory. This can't > be an intended behavior on the compiler's side, right? I think it's a result of inlining -- the compiler ends up with a case where it looks like it might be possible to index a zero-sized array, but it is "accidentally safe".
On Wed, Aug 16, 2023 at 01:57:16PM -0700, Kees Cook wrote: > On Wed, Aug 16, 2023 at 10:51:12AM -1000, Tejun Heo wrote: > > Hello, > > > > On Wed, Aug 16, 2023 at 02:50:16PM -0600, Gustavo A. R. Silva wrote: > > > Change the notation from pointer-to-array to pointer-to-pointer. > > > With this, we avoid the compiler complaining about trying > > > to access a region of size zero as an argument during function > > > calls. > > > > Haha, I thought the functions were actually accessing the memory. This can't > > be an intended behavior on the compiler's side, right? > > I think it's a result of inlining -- the compiler ends up with a case > where it looks like it might be possible to index a zero-sized array, > but it is "accidentally safe". Ah I see. It's not that the compiler knows that ** access is safe. It's more that it only applies the check on arrays. Is that right? Gustavo, I don't mind the patch but can you update the patch description a bit explaining a bit more on what's going on with the complier? It doesn't have to be the full explanation but it'd be useful to explicitly point out that we're just working around the compiler being a bit silly. Thanks.
On 8/16/23 15:01, Tejun Heo wrote: > On Wed, Aug 16, 2023 at 01:57:16PM -0700, Kees Cook wrote: >> On Wed, Aug 16, 2023 at 10:51:12AM -1000, Tejun Heo wrote: >>> Hello, >>> >>> On Wed, Aug 16, 2023 at 02:50:16PM -0600, Gustavo A. R. Silva wrote: >>>> Change the notation from pointer-to-array to pointer-to-pointer. >>>> With this, we avoid the compiler complaining about trying >>>> to access a region of size zero as an argument during function >>>> calls. >>> >>> Haha, I thought the functions were actually accessing the memory. This can't >>> be an intended behavior on the compiler's side, right? >> >> I think it's a result of inlining -- the compiler ends up with a case >> where it looks like it might be possible to index a zero-sized array, >> but it is "accidentally safe". > > Ah I see. It's not that the compiler knows that ** access is safe. It's more > that it only applies the check on arrays. Is that right? Gustavo, I don't That's correct. > mind the patch but can you update the patch description a bit explaining a > bit more on what's going on with the complier? It doesn't have to be the > full explanation but it'd be useful to explicitly point out that we're just > working around the compiler being a bit silly. I just sent v3: https://lore.kernel.org/linux-hardening/ZN5WkbPelHUSTXOA@work/ Thanks -- Gustavo
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index ccbbba06da5b..68e2d9812e3f 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -929,7 +929,7 @@ static void css_set_move_task(struct task_struct *task, #define CSS_SET_HASH_BITS 7 static DEFINE_HASHTABLE(css_set_table, CSS_SET_HASH_BITS); -static unsigned long css_set_hash(struct cgroup_subsys_state *css[]) +static unsigned long css_set_hash(struct cgroup_subsys_state **css) { unsigned long key = 0UL; struct cgroup_subsys *ss; @@ -1070,7 +1070,7 @@ static bool compare_css_sets(struct css_set *cset, */ static struct css_set *find_existing_css_set(struct css_set *old_cset, struct cgroup *cgrp, - struct cgroup_subsys_state *template[]) + struct cgroup_subsys_state **template) { struct cgroup_root *root = cgrp->root; struct cgroup_subsys *ss;
Change the notation from pointer-to-array to pointer-to-pointer. With this, we avoid the compiler complaining about trying to access a region of size zero as an argument during function calls. Address the following -Wstringop-overflow warnings seen when built with ARM architecture and aspeed_g4_defconfig configuration (notice that under this configuration CGROUP_SUBSYS_COUNT == 0): kernel/cgroup/cgroup.c:1208:16: warning: 'find_existing_css_set' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=] kernel/cgroup/cgroup.c:1258:15: warning: 'css_set_hash' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=] kernel/cgroup/cgroup.c:6089:18: warning: 'css_set_hash' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=] kernel/cgroup/cgroup.c:6153:18: warning: 'css_set_hash' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=] This results in no differences in binary output. Link: https://github.com/KSPP/linux/issues/316 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> --- Changes in v2: - Use pointer-to-pointer instead of pointer-to-array. - Update changelog text. v1: - Link: https://lore.kernel.org/linux-hardening/ZIpm3pcs3iCP9UaR@work/ kernel/cgroup/cgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)