[<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