[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52E3A642.7010307@gmail.com>
Date: Sat, 25 Jan 2014 19:55:46 +0800
From: Chen Gang <gang.chen.5i5j@...il.com>
To: James Hogan <james.hogan@...tec.com>
CC: Dan Carpenter <dan.carpenter@...cle.com>,
devel@...verdev.osuosl.org, andreas.dilger@...el.com,
Greg KH <gregkh@...uxfoundation.org>, bergwolf@...il.com,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
oleg.drokin@...el.com, jacques-charles.lafoucriere@....fr,
jinshan.xiong@...el.com, linux-metag@...r.kernel.org,
Antonio Quartulli <antonio@...hcoding.com>,
David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))"
for the related union
On 01/21/2014 06:36 PM, James Hogan wrote:
> Hi Dan,
>
> On 20/01/14 21:13, Dan Carpenter wrote:
>> I made a quick and dirty sparse patch to check for this. I don't think
>> I will bother trying to send it to sparse upstream, but you can if you
>> want to.
>>
>> It found 289 unions which might need a __packed added. The lustre
>> unions were not in my allmodconfig so they're not listed.
>
> Thanks a lot for this, it seems to be useful. I'm adapting it to reduce
> false negatives (e.g. omitting the check if the struct/union is already
> packed), and I imagine it could be made to only warn about padded
> unpacked structs/unions which are used as nested members of packed
> structs/unions. It wouldn't catch everything but would probably catch a
> lot of cases that are most likely to be genuine since they would have
> been packed at the outer level for a reason.
>
>> Perhaps there could be a command line option or a pragma so that unions
>> will work in the kernel. We don't care about linking to outside
>> libraries.
>
> We still interact with userland via structs and unions, so it would
> probably have to exclude anything in uapi/.
>
Thank all of you firstly.
But excuse me, I am still not quit clear that: "what need we do enough
to solve this feature issue?"
So I guess our current result is:
- It is not a good idea to only let kernel to fit with compiler.
- It is not a good idea to only let compiler to fit with kernel.
- Need let compiler and kernel to fit with each other:
- compiler will print related warning, but not break compiling.
so metag compiler need be improvement (check and warn for it).
- if check alignment explicitly in kernel source code, it need be
fixed within kernel: "apply related patches (pack each struct or
union), but the related patch comments need be improved".
Is what I guess correct?
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
--
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/
Powered by blists - more mailing lists