linux-kernel - Re: [PATCH 1/2] device.h: pack struct dev_links

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:   Wed, 27 Feb 2019 11:59:51 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Johan Hovold <johan@...nel.org>, linux-kernel@...r.kernel.org,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH 1/2] device.h: pack struct dev_links_info

On Wed, Feb 27, 2019 at 10:54:24AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 27, 2019 at 10:40:21AM +0100, Johan Hovold wrote:
> > On Wed, Feb 27, 2019 at 10:31:04AM +0100, Greg Kroah-Hartman wrote:
> > > On Wed, Feb 27, 2019 at 10:23:18AM +0100, Johan Hovold wrote:
> > > > On Tue, Feb 26, 2019 at 03:41:07PM +0100, Greg Kroah-Hartman wrote:
> > > > > The dev_links_info structure has 4 bytes of padding at the end of it
> > > > > when embedded in struct device (which is the only place it lives).  To
> > > > > help reduce the size of struct device pack this structure so we can take
> > > > > advantage of the hole with later structure reorganizations.
> > > > > 
> > > > > Cc: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > > > ---
> > > > >  include/linux/device.h | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > > > index 6cb4640b6160..b63165276a09 100644
> > > > > --- a/include/linux/device.h
> > > > > +++ b/include/linux/device.h
> > > > > @@ -884,7 +884,7 @@ struct dev_links_info {
> > > > >  	struct list_head suppliers;
> > > > >  	struct list_head consumers;
> > > > >  	enum dl_dev_state status;
> > > > > -};
> > > > > +} __packed;
> > > > 
> > > > This seems like a bad idea. You're changing the alignment of these
> > > > fields to one byte, something which may cause the compiler to generate
> > > > less efficient code to deal with unaligned accesses (even if they happen
> > > > to currently be naturally aligned in struct device).
> > > 
> > > No, all this changes is the trailing "space" is gone.  The alignment of
> > > the fields did not change at all as they are all naturally aligned
> > > (list_head is just 2 pointers).
> > 
> > Yes, currently and in struct device, but given a pointer to a struct
> > dev_links_info the compiler must assume it is unaligned and act
> > accordingly for example.
> 
> Packing the structure doesn't mean that the addressing of it is not also
> aligned, that should just depend on the location of the pointer in the
> first place, right?

Packing a structure per definition means changing the alignment
requirement of each field of the struct to 1-byte alignment.

Another example of unintended consequences would obviously be that if
someone later adds a short field, say 1-byte, field before the
dev_links_info struct, all its fields would be non-naturally aligned
also in struct device.

Sure that can be avoided by inspection (and refusal to add new holes),
but again, not obvious when the link structure is defined elsewhere.

> Surely compilers are not that foolish :)
> 
> And accessing this field should not be an issue of "slow", hopefully the
> memory savings would offset any compiler mess.

There are other subtleties like atomicity that may come into play.

And even if any penalties are deemed acceptable in this case, you're
also setting a precedent for others. Note that we do not seem to use
__packed this way currently

> > > So this allows us to save 4 bytes in struct device by putting something in that
> > > trailing "hole" that can be aligned with it better (i.e. an integer or
> > > something else).
> > 
> > I understand that, but I don't think it is worth to start using packed
> > liked this for internal structures as it may have subtle and unintended
> > consequences.
> 
> I'm not understanding what the consequences are here, sorry.  Does the
> compiler output change given that the structure is still aligned
> properly in the "parent" structure?  I can't see any output changed
> here, but maybe I am not looking properly?

It's all arch dependent, and you won't see any difference on x86-64.

The following example produces additional instructions even on 32-bit
arm here:

struct a1 {
	void *p;
	void *q;
	int i;
} __attribute__((__packed__));

struct a2 {
	void *p;
	void *q;
	int i;
};

int f(struct a1 *a)
{
	return a->i;
}

int g(struct a2 *a)
{
	return a->i;
}

Johan