linux-kernel - Re: [PATCH] Use a zero-size array in the struct devres

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:	Tue, 06 Mar 2007 23:58:23 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Catalin Marinas <catalin.marinas@....com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Use a zero-size array in the struct devres

Catalin Marinas wrote:
> Chapter 5.31 (http://gcc.gnu.org/onlinedocs/gcc/Alignment.html) states
> that "it is an error to ask for the alignment of an incomplete type"
> and flexible array members have incomplete type (according to ISO C99
> as described in http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html).
> 
> It sounds to me like the alignment of an incomplete type is not
> guaranteed (as you can't even enquire about it, though I might be
> wrong). This is probably dependent on the compiler as well - with
> gcc-3.3 on x86, __alignof__(unsigned long long) is 8 but the
> "offsetof(struct test, data)" below is 12 (and it doesn't make any
> difference whether it is a 0-size array or not):
> 
> struct test {
>     unsigned long a;
>     unsigned long b;
>     unsigned long c;
>     unsigned long long data[];
> };

data[0] and data[1] or whatever will also give you offset of 12.  Dunno
why, but it is.  Anyways, whatever the wording in the manual is,
flexible arrays just have to have the required alignment to do its job
as advertised.  :-)

>>> I came across this when trying to build kmemleak as the modified
>>> container_of macro tries to get the size of the devres.data member and
>>> sizeof cannot be applied to incomplete types.
>> If kmemleak's container_of cannot deal with the current struct devres,
>> it means it can't deal with flexible arrays at all.  Flexible array
>> being the standard as opposed to 0 size array gcc extension, I guess a
>> lot of people would prefer flexible array.
> 
> I'm OK with flexible arrays (kmemleak uses them as well) but not as a
> member of structure getting passed to the container_of macro.
> 
> I did a quick grep through the kernel and it looks like Linux mainly
> uses 0-size rather than flexible arrays at the end of a structure
> (>500 vs ~14). This might be for historical reasons but it's not a big
> issue in modifying them.

I think it's mostly historical.  Flexible array is still a relatively
new thing.  I don't mind changing devres to zero sized array, but please
explain in the commit message and as a comment that the choice is for
kmemleak's container_of(), and cc Greg K-H as the change should probably
go through his tree.

Thanks.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/