lkml.org 
[lkml]   [2009]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: lib/klist.c: bit 0 in pointer can't be used as flag
On Wed, Jan 14, 2009 at 11:45:28AM +0100, David Miller wrote:
> From: Jesper Nilsson <Jesper.Nilsson@axis.com>
> Date: Wed, 14 Jan 2009 11:36:24 +0100
>
> > On Wed, Jan 14, 2009 at 11:21:40AM +0100, David Miller wrote:
> > > From: Jesper Nilsson <Jesper.Nilsson@axis.com>
> > > Date: Wed, 14 Jan 2009 11:19:08 +0100
> > > > The following patch works for CRIS, and is less intrusive than
> > > > my earlier patch. If this the way to go I can resubmit a proper patch.
> > >
> > > Out of curiosity, is there a way to get gcc to output code such
> > > that data objects are aligned more naturally? Some option or
> > > similar?
> >
> > There's flags for alignment of objects, but no flags for changing
> > structure layout or size, which is probably what we run into here.
>
> Really?

Yes, after some more research, I found that the bug is indeed triggered by
the struct klist being aligned to odd bytes inside other structs.

Since CRIS uses packed structs, having a char * inside the kobjects
shifts the alignment for all data after any struct that contains
a kobject (and indeed inside the kobject itself)

In this case it was the class pointer of the struct device
that had a klist in the private pointer (struct class_private),
after a struct kset (which contains a kobject).

> I thought the problem is that the base object can have any odd
> alignment in the kernel image. And this is why the problem isn't run
> into for objects allocated using dynamic allocation.

Actually, it seems that the default is for objects to be aligned
at 16bits for CRIS, which may also explain why this is not seen more often.

Objects allocated dynamically may still trigger the bug, due to
the struct not being padded.

/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com


\
 
 \ /
  Last update: 2009-01-14 16:17    [W:0.514 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site