mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yann Droneaud <ydroneaud@opteya.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Yann Droneaud <ydroneaud@opteya.com>
Subject: Re: [PATCHv4] driver core/platform: don't leak memory allocated for dma_mask
Date: Sun, 09 Feb 2014 08:47:22 +0100	[thread overview]
Message-ID: <1391932042.11170.20.camel@localhost.localdomain> (raw)
In-Reply-To: <20140208150958.GK17045@pengutronix.de>

Hi,

Le samedi 08 février 2014 à 16:09 +0100, Uwe Kleine-König a écrit :
> On Fri, Feb 07, 2014 at 03:20:05PM -0800, Greg Kroah-Hartman wrote:
> > On Mon, Jan 27, 2014 at 11:05:52AM +0100, Yann Droneaud wrote:
> > > Since commit 01dcc60a7cb8, platform_device_register_full() is
> > > available to allocate and register a platform device.
> > > 
> > > If a dma_mask is provided as part of platform_device_info,
> > > platform_device_register_full() allocate memory for a u64 using
> > > kmalloc().
> > > 
> > > A comment in the code state that "[t]his memory isn't freed when the
> > > device is put".
> > > 
> > > It's never a good thing to leak memory, but there's only very few
> > > users of platform_device_info's dma_mask, and those are mostly
> > > "static" devices that are not going to be plugged/unplugged often.
> > > 
> > > So memory leak is not really an issue, but allocating 8 bytes through
> > > kmalloc() seems overkill.
> > > 
> > > And it's a pity to have to allocate 8 bytes for the dma_mask while up
> > > to 7 bytes are wasted at the end of struct platform_object in the form
> > > of padding after name field: unfortunately this padding is not used
> > > when allocating the memory to hold the name.
> > >
> > > To address theses issues, this patch adds dma_mask to platform_object
> > > struct so that it is always allocated for all struct platform_device
> > > allocated through platform_device_alloc() or platform_device_register_full().
> > > And since it's within struct platform_object, dma_mask won't be leaked
> > > anymore when struct platform_device got released. Storage for dma_mask
> > > is added almost for free by removing the padding at the end of struct
> > > platform_object.

> How does the padding of name change? The only thing that I see changing
> for .name is that it's a char[] now instead of a char[1]. As it was
> used as a flexible array already before the padding (which only applies
> to a stand alone struct platform_object) doesn't matter.
> I guess that is a tool problem that still some padding changes are
> reported?
> 

When name is defined as char name[1] at the end of the structure, the
compiler is required to add padding after it (since the structure is not
"packed" through some compiler extension).
This padding is added in order to have a size multiple of the highest
required alignement for types insided the structure. This is required so
that each item of an array of "struct platform_object" are aligned.

Changing name[1] to name[0] or name[] free the compiler from adding
storage space for name and thus remove the need for padding after it.

> Other than that the patch looks good.
> 

Thanks a lot.

-- 
Yann Droneaud
OPTEYA



  reply	other threads:[~2014-02-09  7:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12 22:10 [PATCH] " Yann Droneaud
2014-01-13 21:38 ` [PATCHv1] " Yann Droneaud
2014-01-13 22:56   ` Greg Kroah-Hartman
2014-01-14  7:18     ` [PATCHv2] " Yann Droneaud
2014-01-14  8:19       ` Uwe Kleine-König
2014-01-14  9:57         ` Yann Droneaud
2014-01-14 10:36           ` Uwe Kleine-König
2014-01-14 18:02             ` Greg Kroah-Hartman
2014-01-26 21:18               ` [PATCHv3] " Yann Droneaud
2014-01-27 10:05                 ` [PATCHv4] " Yann Droneaud
2014-02-07 23:20                   ` Greg Kroah-Hartman
2014-02-08 15:09                     ` Uwe Kleine-König
2014-02-09  7:47                       ` Yann Droneaud [this message]
2014-02-09  9:30                         ` Uwe Kleine-König
2014-02-15 19:39                           ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1391932042.11170.20.camel@localhost.localdomain \
    --to=ydroneaud@opteya.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome