[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Joe Perches]

Currently, devm_ managed memory only supports kzalloc.

Convert the devm_kzalloc implementation to devm_kmalloc
and remove the complete memset to 0 but still set the
initial struct devres header and whatever padding before
data to 0.

Add the other normal alloc variants as static inlines with
__GFP_ZERO added to the gfp flag where appropriate:

	devm_kzalloc
	devm_kcalloc
	devm_kmalloc_array

Add gfp.h to device.h for the newly added static inlines.

Signed-off-by: Joe Perches <joe@perches.com>
---
 drivers/base/devres.c  | 27 ++++++++++++++++-----------
 include/linux/device.h | 21 +++++++++++++++++++--
 2 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 507379e..37e67a2 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -91,7 +91,8 @@ static __always_inline struct devres * alloc_dr(dr_release_t release,
 	if (unlikely(!dr))
 		return NULL;
 
-	memset(dr, 0, tot_size);
+	memset(dr, 0, offsetof(struct devres, data));
+
 	INIT_LIST_HEAD(&dr->node.entry);
 	dr->node.release = release;
 	return dr;
@@ -745,58 +746,62 @@ void devm_remove_action(struct device *dev, void (*action)(void *), void *data)
 EXPORT_SYMBOL_GPL(devm_remove_action);
 
 /*
- * Managed kzalloc/kfree
+ * Managed kmalloc/kfree
  */
-static void devm_kzalloc_release(struct device *dev, void *res)
+static void devm_kmalloc_release(struct device *dev, void *res)
 {
 	/* noop */
 }
 
-static int devm_kzalloc_match(struct device *dev, void *res, void *data)
+static int devm_kmalloc_match(struct device *dev, void *res, void *data)
 {
 	return res == data;
 }
 
 /**
- * devm_kzalloc - Resource-managed kzalloc
+ * devm_kmalloc - Resource-managed kmalloc
  * @dev: Device to allocate memory for
  * @size: Allocation size
  * @gfp: Allocation gfp flags
  *
- * Managed kzalloc.  Memory allocated with this function is
+ * Managed kmalloc.  Memory allocated with this function is
  * automatically freed on driver detach.  Like all other devres
  * resources, guaranteed alignment is unsigned long long.
  *
  * RETURNS:
  * Pointer to allocated memory on success, NULL on failure.
  */
-void * devm_kzalloc(struct device *dev, size_t size, gfp_t gfp)
+void * devm_kmalloc(struct device *dev, size_t size, gfp_t gfp)
 {
 	struct devres *dr;
 
 	/* use raw alloc_dr for kmalloc caller tracing */
-	dr = alloc_dr(devm_kzalloc_release, size, gfp);
+	dr = alloc_dr(devm_kmalloc_release, size, gfp);
 	if (unlikely(!dr))
 		return NULL;
 
+	/*
+	 * This is named devm_kzalloc_release for historical reasons
+	 * The initial implementation did not support kmalloc, only kzalloc
+	 */
 	set_node_dbginfo(&dr->node, "devm_kzalloc_release", size);
 	devres_add(dev, dr->data);
 	return dr->data;
 }
-EXPORT_SYMBOL_GPL(devm_kzalloc);
+EXPORT_SYMBOL_GPL(devm_kmalloc);
 
 /**
  * devm_kfree - Resource-managed kfree
  * @dev: Device this memory belongs to
  * @p: Memory to free
  *
- * Free memory allocated with devm_kzalloc().
+ * Free memory allocated with devm_kmalloc().
  */
 void devm_kfree(struct device *dev, void *p)
 {
 	int rc;
 
-	rc = devres_destroy(dev, devm_kzalloc_release, devm_kzalloc_match, p);
+	rc = devres_destroy(dev, devm_kmalloc_release, devm_kmalloc_match, p);
 	WARN_ON(rc);
 }
 EXPORT_SYMBOL_GPL(devm_kfree);
diff --git a/include/linux/device.h b/include/linux/device.h
index ce690ea..46540f8 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -26,6 +26,7 @@
 #include <linux/atomic.h>
 #include <linux/ratelimit.h>
 #include <linux/uidgid.h>
+#include <linux/gfp.h>
 #include <asm/device.h>
 
 struct device;
@@ -614,8 +615,24 @@ extern void devres_close_group(struct device *dev, void *id);
 extern void devres_remove_group(struct device *dev, void *id);
 extern int devres_release_group(struct device *dev, void *id);
 
-/* managed kzalloc/kfree for device drivers, no kmalloc, always use kzalloc */
-extern void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp);
+/* managed devm_k.alloc/kfree for device drivers */
+extern void *devm_kmalloc(struct device *dev, size_t size, gfp_t gfp);
+static inline void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp)
+{
+	return devm_kmalloc(dev, size, gfp | __GFP_ZERO);
+}
+static inline void *devm_kmalloc_array(struct device *dev,
+				       size_t n, size_t size, gfp_t flags)
+{
+	if (size != 0 && n > SIZE_MAX / size)
+		return NULL;
+	return devm_kmalloc(dev, n * size, flags);
+}
+static inline void *devm_kcalloc(struct device *dev,
+				 size_t n, size_t size, gfp_t flags)
+{
+	return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
+}
 extern void devm_kfree(struct device *dev, void *p);
 
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Greg KH]

On Tue, Oct 08, 2013 at 10:32:27PM -0700, Joe Perches wrote:
> Currently, devm_ managed memory only supports kzalloc.
> 
> Convert the devm_kzalloc implementation to devm_kmalloc
> and remove the complete memset to 0 but still set the
> initial struct devres header and whatever padding before
> data to 0.
> 
> Add the other normal alloc variants as static inlines with
> __GFP_ZERO added to the gfp flag where appropriate:
> 
> 	devm_kzalloc
> 	devm_kcalloc
> 	devm_kmalloc_array
> 
> Add gfp.h to device.h for the newly added static inlines.
> 
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>  drivers/base/devres.c  | 27 ++++++++++++++++-----------
>  include/linux/device.h | 21 +++++++++++++++++++--
>  2 files changed, 35 insertions(+), 13 deletions(-)

Makes sense to me, does this let other drivers start to use this where
they were not able to in the past?

thanks,

greg k-h

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Joe Perches]

On Tue, 2013-10-08 at 22:43 -0700, Greg KH wrote:
> On Tue, Oct 08, 2013 at 10:32:27PM -0700, Joe Perches wrote:
> > Currently, devm_ managed memory only supports kzalloc.
> > 
> > Convert the devm_kzalloc implementation to devm_kmalloc
> > and remove the complete memset to 0 but still set the
> > initial struct devres header and whatever padding before
> > data to 0.
> > 
> > Add the other normal alloc variants as static inlines with
> > __GFP_ZERO added to the gfp flag where appropriate:
> > 
> > 	devm_kzalloc
> > 	devm_kcalloc
> > 	devm_kmalloc_array
> > 
> > Add gfp.h to device.h for the newly added static inlines.
> > 
> > Signed-off-by: Joe Perches <joe@perches.com>
> > ---
> >  drivers/base/devres.c  | 27 ++++++++++++++++-----------
> >  include/linux/device.h | 21 +++++++++++++++++++--
> >  2 files changed, 35 insertions(+), 13 deletions(-)
> 
> Makes sense to me, does this let other drivers start to use this where
> they were not able to in the past?

Yes.

There are some existing uses of devm_kzalloc(dev, n*size, gfp)
that could/should be converted.

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Greg KH]

On Tue, Oct 08, 2013 at 11:16:44PM -0700, Joe Perches wrote:
> On Tue, 2013-10-08 at 22:43 -0700, Greg KH wrote:
> > On Tue, Oct 08, 2013 at 10:32:27PM -0700, Joe Perches wrote:
> > > Currently, devm_ managed memory only supports kzalloc.
> > > 
> > > Convert the devm_kzalloc implementation to devm_kmalloc
> > > and remove the complete memset to 0 but still set the
> > > initial struct devres header and whatever padding before
> > > data to 0.
> > > 
> > > Add the other normal alloc variants as static inlines with
> > > __GFP_ZERO added to the gfp flag where appropriate:
> > > 
> > > 	devm_kzalloc
> > > 	devm_kcalloc
> > > 	devm_kmalloc_array
> > > 
> > > Add gfp.h to device.h for the newly added static inlines.
> > > 
> > > Signed-off-by: Joe Perches <joe@perches.com>
> > > ---
> > >  drivers/base/devres.c  | 27 ++++++++++++++++-----------
> > >  include/linux/device.h | 21 +++++++++++++++++++--
> > >  2 files changed, 35 insertions(+), 13 deletions(-)
> > 
> > Makes sense to me, does this let other drivers start to use this where
> > they were not able to in the past?
> 
> Yes.
> 
> There are some existing uses of devm_kzalloc(dev, n*size, gfp)
> that could/should be converted.

Ok, great, want me to take the "RFC" off of this and apply it to my
tree?

greg k-h

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Joe Perches]

On Tue, 2013-10-08 at 23:54 -0700, Greg KH wrote:
> On Tue, Oct 08, 2013 at 11:16:44PM -0700, Joe Perches wrote:
> > On Tue, 2013-10-08 at 22:43 -0700, Greg KH wrote:
> > > On Tue, Oct 08, 2013 at 10:32:27PM -0700, Joe Perches wrote:
> > > > Currently, devm_ managed memory only supports kzalloc.
> > > > 
> > > > Convert the devm_kzalloc implementation to devm_kmalloc
> > > > and remove the complete memset to 0 but still set the
> > > > initial struct devres header and whatever padding before
> > > > data to 0.
> > > > 
> > > > Add the other normal alloc variants as static inlines with
> > > > __GFP_ZERO added to the gfp flag where appropriate:
> > > > 
> > > > 	devm_kzalloc
> > > > 	devm_kcalloc
> > > > 	devm_kmalloc_array
> > > > 
> > > > Add gfp.h to device.h for the newly added static inlines.
> > > > 
> > > > Signed-off-by: Joe Perches <joe@perches.com>
> > > > ---
> > > >  drivers/base/devres.c  | 27 ++++++++++++++++-----------
> > > >  include/linux/device.h | 21 +++++++++++++++++++--
> > > >  2 files changed, 35 insertions(+), 13 deletions(-)
> > > 
> > > Makes sense to me, does this let other drivers start to use this where
> > > they were not able to in the past?
> > 
> > Yes.
> > 
> > There are some existing uses of devm_kzalloc(dev, n*size, gfp)
> > that could/should be converted.
> 
> Ok, great, want me to take the "RFC" off of this and apply it to my
> tree?

Unless Tejun has an objection soon, yes.

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Tejun Heo]

Hello,

On Wed, Oct 09, 2013 at 12:04:42AM -0700, Joe Perches wrote:
> > > > > 	devm_kzalloc
> > > > > 	devm_kcalloc
> > > > > 	devm_kmalloc_array
> > > > > 
> > > > > Add gfp.h to device.h for the newly added static inlines.
...
> Unless Tejun has an objection soon, yes.

Do we really need devm_kmalloc_array() for devm interface?  The
reasonsing behind only having kzalloc was that it's not worthwhile
skipping zeroing for stuff happening during driver init/exit paths.
The resource management overhead itself is already significant and
unscalable compared to the raw cost of alloc/free and the interface
isn't supposed to be used in super-hot paths.  Shouldn't
devm_kzalloc() and devm_kcalloc() be enough?

Thanks.

-- 
tejun

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Joe Perches]

On Wed, 2013-10-09 at 12:30 -0400, Tejun Heo wrote:
> Hello,
> 
> On Wed, Oct 09, 2013 at 12:04:42AM -0700, Joe Perches wrote:
> > > > > > 	devm_kzalloc
> > > > > > 	devm_kcalloc
> > > > > > 	devm_kmalloc_array
> > > > > > 
> > > > > > Add gfp.h to device.h for the newly added static inlines.
> ...
> > Unless Tejun has an objection soon, yes.
> 
> Do we really need devm_kmalloc_array() for devm interface?  The
> reasonsing behind only having kzalloc was that it's not worthwhile
> skipping zeroing for stuff happening during driver init/exit paths.
> The resource management overhead itself is already significant and
> unscalable compared to the raw cost of alloc/free and the interface
> isn't supposed to be used in super-hot paths.  Shouldn't
> devm_kzalloc() and devm_kcalloc() be enough?

I think API symmetry is a good thing and I think
that API dissymmetry is not a good thing when the
creation and support cost is very low.

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Andrew Morton]

On Tue, 08 Oct 2013 22:32:27 -0700 Joe Perches <joe@perches.com> wrote:

> Currently, devm_ managed memory only supports kzalloc.
> 
> Convert the devm_kzalloc implementation to devm_kmalloc
> and remove the complete memset to 0 but still set the
> initial struct devres header and whatever padding before
> data to 0.
> 
> Add the other normal alloc variants as static inlines with
> __GFP_ZERO added to the gfp flag where appropriate:
> 
> 	devm_kzalloc
> 	devm_kcalloc
> 	devm_kmalloc_array
> 
> Add gfp.h to device.h for the newly added static inlines.
> 
> ...
>
> --- a/drivers/base/devres.c
> +++ b/drivers/base/devres.c
> @@ -91,7 +91,8 @@ static __always_inline struct devres * alloc_dr(dr_release_t release,
>  	if (unlikely(!dr))
>  		return NULL;
>  
> -	memset(dr, 0, tot_size);
> +	memset(dr, 0, offsetof(struct devres, data));

Well, this does make some assumptions about devres layout.  It would
have been cleaner to do

	memset(&dr.node, 0, sizeof(dr.node));

but whatever.

I made some changelog changes.

I agree that including devm_kmalloc_array() might be going a bit far
(it's the lack of devm_kmalloc which matters most).  But
devm_kmalloc_array() is inlined and is hence basically cost-free until
someone actually uses it.




From: Joe Perches <joe@perches.com>
Subject: devres: add kernel standard devm_k.alloc functions

Currently, devm_ managed memory only supports kzalloc.

Convert the devm_kzalloc implementation to devm_kmalloc and remove the
complete memset to 0 but still set the initial struct devres header and
whatever padding before data to 0.

Add the other normal alloc variants as static inlines with __GFP_ZERO
added to the gfp flag where appropriate:

	devm_kzalloc
	devm_kcalloc
	devm_kmalloc_array

Add gfp.h to device.h for the newly added static inlines.

akpm: the current API forces us to replace kmalloc() with kzalloc() when
performing devm_ conversions.  This adds a relatively minor overhead. 
More significantly, it will defeat kmemcheck used-uninitialized checking,
and for a particular driver, losing used-uninitialised checking for their
core controlling data structures will significantly degrade kmemcheck
usefulness.

Signed-off-by: Joe Perches <joe@perches.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Sangjung Woo <sangjung.woo@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/base/devres.c  |   27 ++++++++++++++++-----------
 include/linux/device.h |   21 +++++++++++++++++++--
 2 files changed, 35 insertions(+), 13 deletions(-)

diff -puN drivers/base/devres.c~device-add-kernel-standard-devm_kalloc-functions drivers/base/devres.c
--- a/drivers/base/devres.c~device-add-kernel-standard-devm_kalloc-functions
+++ a/drivers/base/devres.c
@@ -91,7 +91,8 @@ static __always_inline struct devres * a
 	if (unlikely(!dr))
 		return NULL;
 
-	memset(dr, 0, tot_size);
+	memset(dr, 0, offsetof(struct devres, data));
+
 	INIT_LIST_HEAD(&dr->node.entry);
 	dr->node.release = release;
 	return dr;
@@ -745,58 +746,62 @@ void devm_remove_action(struct device *d
 EXPORT_SYMBOL_GPL(devm_remove_action);
 
 /*
- * Managed kzalloc/kfree
+ * Managed kmalloc/kfree
  */
-static void devm_kzalloc_release(struct device *dev, void *res)
+static void devm_kmalloc_release(struct device *dev, void *res)
 {
 	/* noop */
 }
 
-static int devm_kzalloc_match(struct device *dev, void *res, void *data)
+static int devm_kmalloc_match(struct device *dev, void *res, void *data)
 {
 	return res == data;
 }
 
 /**
- * devm_kzalloc - Resource-managed kzalloc
+ * devm_kmalloc - Resource-managed kmalloc
  * @dev: Device to allocate memory for
  * @size: Allocation size
  * @gfp: Allocation gfp flags
  *
- * Managed kzalloc.  Memory allocated with this function is
+ * Managed kmalloc.  Memory allocated with this function is
  * automatically freed on driver detach.  Like all other devres
  * resources, guaranteed alignment is unsigned long long.
  *
  * RETURNS:
  * Pointer to allocated memory on success, NULL on failure.
  */
-void * devm_kzalloc(struct device *dev, size_t size, gfp_t gfp)
+void * devm_kmalloc(struct device *dev, size_t size, gfp_t gfp)
 {
 	struct devres *dr;
 
 	/* use raw alloc_dr for kmalloc caller tracing */
-	dr = alloc_dr(devm_kzalloc_release, size, gfp);
+	dr = alloc_dr(devm_kmalloc_release, size, gfp);
 	if (unlikely(!dr))
 		return NULL;
 
+	/*
+	 * This is named devm_kzalloc_release for historical reasons
+	 * The initial implementation did not support kmalloc, only kzalloc
+	 */
 	set_node_dbginfo(&dr->node, "devm_kzalloc_release", size);
 	devres_add(dev, dr->data);
 	return dr->data;
 }
-EXPORT_SYMBOL_GPL(devm_kzalloc);
+EXPORT_SYMBOL_GPL(devm_kmalloc);
 
 /**
  * devm_kfree - Resource-managed kfree
  * @dev: Device this memory belongs to
  * @p: Memory to free
  *
- * Free memory allocated with devm_kzalloc().
+ * Free memory allocated with devm_kmalloc().
  */
 void devm_kfree(struct device *dev, void *p)
 {
 	int rc;
 
-	rc = devres_destroy(dev, devm_kzalloc_release, devm_kzalloc_match, p);
+	rc = devres_destroy(dev, devm_kmalloc_release, devm_kmalloc_match, p);
 	WARN_ON(rc);
 }
 EXPORT_SYMBOL_GPL(devm_kfree);
diff -puN include/linux/device.h~device-add-kernel-standard-devm_kalloc-functions include/linux/device.h
--- a/include/linux/device.h~device-add-kernel-standard-devm_kalloc-functions
+++ a/include/linux/device.h
@@ -26,6 +26,7 @@
 #include <linux/atomic.h>
 #include <linux/ratelimit.h>
 #include <linux/uidgid.h>
+#include <linux/gfp.h>
 #include <asm/device.h>
 
 struct device;
@@ -602,8 +603,24 @@ extern void devres_close_group(struct de
 extern void devres_remove_group(struct device *dev, void *id);
 extern int devres_release_group(struct device *dev, void *id);
 
-/* managed kzalloc/kfree for device drivers, no kmalloc, always use kzalloc */
-extern void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp);
+/* managed devm_k.alloc/kfree for device drivers */
+extern void *devm_kmalloc(struct device *dev, size_t size, gfp_t gfp);
+static inline void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp)
+{
+	return devm_kmalloc(dev, size, gfp | __GFP_ZERO);
+}
+static inline void *devm_kmalloc_array(struct device *dev,
+				       size_t n, size_t size, gfp_t flags)
+{
+	if (size != 0 && n > SIZE_MAX / size)
+		return NULL;
+	return devm_kmalloc(dev, n * size, flags);
+}
+static inline void *devm_kcalloc(struct device *dev,
+				 size_t n, size_t size, gfp_t flags)
+{
+	return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
+}
 extern void devm_kfree(struct device *dev, void *p);
 
 void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
_

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Kevin Hilman]

On Fri, Oct 11, 2013 at 1:11 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 08 Oct 2013 22:32:27 -0700 Joe Perches <joe@perches.com> wrote:
>
>> Currently, devm_ managed memory only supports kzalloc.
>>
>> Convert the devm_kzalloc implementation to devm_kmalloc
>> and remove the complete memset to 0 but still set the
>> initial struct devres header and whatever padding before
>> data to 0.
>>
>> Add the other normal alloc variants as static inlines with
>> __GFP_ZERO added to the gfp flag where appropriate:
>>
>>       devm_kzalloc
>>       devm_kcalloc
>>       devm_kmalloc_array
>>
>> Add gfp.h to device.h for the newly added static inlines.
>>
>> ...
>>
>> --- a/drivers/base/devres.c
>> +++ b/drivers/base/devres.c
>> @@ -91,7 +91,8 @@ static __always_inline struct devres * alloc_dr(dr_release_t release,
>>       if (unlikely(!dr))
>>               return NULL;
>>
>> -     memset(dr, 0, tot_size);
>> +     memset(dr, 0, offsetof(struct devres, data));
>
> Well, this does make some assumptions about devres layout.  It would
> have been cleaner to do
>
>         memset(&dr.node, 0, sizeof(dr.node));
>
> but whatever.
>
> I made some changelog changes.
>
> I agree that including devm_kmalloc_array() might be going a bit far
> (it's the lack of devm_kmalloc which matters most).  But
> devm_kmalloc_array() is inlined and is hence basically cost-free until
> someone actually uses it.

A handful of boot panics on ARM platforms were bisected to point at
the version of this commit that's in linux-next (commit
64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
makes things happy again.

Upon further digging, it seems that users of devres_alloc() are
relying on the previous behavior of having the memory zero'd which is
no longer the case after $SUBJECT patch.  The change below on top of
-next makes these ARM boards happy again.

Kevin

[1]
>From 16489e16c8efdda791e96bd591e455e7c7739f98 Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()

commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated
memory.  However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO
which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong
assumptions
about memory being zero'd upon allocation.

To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.

Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
 drivers/base/devres.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..e3fe8be 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
size, gfp_t gfp)
 {
  struct devres *dr;

- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
  if (unlikely(!dr))
  return NULL;
  return dr->data;
-- 
1.8.3

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Kevin Hilman]

On Fri, Oct 11, 2013 at 1:11 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 08 Oct 2013 22:32:27 -0700 Joe Perches <joe@perches.com> wrote:
>
>> Currently, devm_ managed memory only supports kzalloc.
>>
>> Convert the devm_kzalloc implementation to devm_kmalloc
>> and remove the complete memset to 0 but still set the
>> initial struct devres header and whatever padding before
>> data to 0.
>>
>> Add the other normal alloc variants as static inlines with
>> __GFP_ZERO added to the gfp flag where appropriate:
>>
>>       devm_kzalloc
>>       devm_kcalloc
>>       devm_kmalloc_array
>>
>> Add gfp.h to device.h for the newly added static inlines.
>>
>> ...
>>
>> --- a/drivers/base/devres.c
>> +++ b/drivers/base/devres.c
>> @@ -91,7 +91,8 @@ static __always_inline struct devres * alloc_dr(dr_release_t release,
>>       if (unlikely(!dr))
>>               return NULL;
>>
>> -     memset(dr, 0, tot_size);
>> +     memset(dr, 0, offsetof(struct devres, data));
>
> Well, this does make some assumptions about devres layout.  It would
> have been cleaner to do
>
>         memset(&dr.node, 0, sizeof(dr.node));
>
> but whatever.
>
> I made some changelog changes.
>
> I agree that including devm_kmalloc_array() might be going a bit far
> (it's the lack of devm_kmalloc which matters most).  But
> devm_kmalloc_array() is inlined and is hence basically cost-free until
> someone actually uses it.

A handful of boot panics on ARM platforms were bisected to point at
the version of this commit that's in linux-next (commit
64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
makes things happy again.

Upon further digging, it seems that users of devres_alloc() are
relying on the previous behavior of having the memory zero'd which is
no longer the case after $SUBJECT patch.  The change below on top of
-next makes these ARM boards happy again.

Kevin

[1]
>From 16489e16c8efdda791e96bd591e455e7c7739f98 Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()

commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated
memory.  However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO
which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong
assumptions
about memory being zero'd upon allocation.

To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.

Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
 drivers/base/devres.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..e3fe8be 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
size, gfp_t gfp)
 {
  struct devres *dr;

- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
  if (unlikely(!dr))
  return NULL;
  return dr->data;
-- 
1.8.3

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Kevin Hilman]

> A handful of boot panics on ARM platforms were bisected to point at
> the version of this commit that's in linux-next (commit
> 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> makes things happy again.
>
> Upon further digging, it seems that users of devres_alloc() are
> relying on the previous behavior of having the memory zero'd which is
> no longer the case after $SUBJECT patch.  The change below on top of
> -next makes these ARM boards happy again.

Oops, it should've fixed __devres_alloc() also.  Updated patch below.

Kevin

>From a1962ed4a999fb630a48f75a5ecaf84401d5dbfc Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()

commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated
memory.  However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO
which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong
assumptions
about memory being zero'd upon allocation.

To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.

Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
 drivers/base/devres.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..545c4de 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -111,7 +111,7 @@ void * __devres_alloc(dr_release_t release, size_t
size, gfp_t gfp,
 {
  struct devres *dr;

- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
  if (unlikely(!dr))
  return NULL;
  set_node_dbginfo(&dr->node, name, size);
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
size, gfp_t gfp)
 {
  struct devres *dr;

- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
  if (unlikely(!dr))
  return NULL;
  return dr->data;
-- 
1.8.3

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Kevin Hilman]

> A handful of boot panics on ARM platforms were bisected to point at
> the version of this commit that's in linux-next (commit
> 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> makes things happy again.
>
> Upon further digging, it seems that users of devres_alloc() are
> relying on the previous behavior of having the memory zero'd which is
> no longer the case after $SUBJECT patch.  The change below on top of
> -next makes these ARM boards happy again.

Oops, it should've fixed __devres_alloc() also.  Updated patch below.

Kevin

>From a1962ed4a999fb630a48f75a5ecaf84401d5dbfc Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()

commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated
memory.  However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO
which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong
assumptions
about memory being zero'd upon allocation.

To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.

Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
 drivers/base/devres.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..545c4de 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -111,7 +111,7 @@ void * __devres_alloc(dr_release_t release, size_t
size, gfp_t gfp,
 {
  struct devres *dr;

- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
  if (unlikely(!dr))
  return NULL;
  set_node_dbginfo(&dr->node, name, size);
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
size, gfp_t gfp)
 {
  struct devres *dr;

- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
  if (unlikely(!dr))
  return NULL;
  return dr->data;
-- 
1.8.3

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Joe Perches]

On Fri, 2013-10-18 at 09:57 -0700, Kevin Hilman wrote:
[]
> A handful of boot panics on ARM platforms were bisected to point at
> the version of this commit that's in linux-next (commit
> 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> makes things happy again.
> 
> Upon further digging, it seems that users of devres_alloc() are
> relying on the previous behavior of having the memory zero'd which is
> no longer the case after $SUBJECT patch.  The change below on top of
> -next makes these ARM boards happy again.
[]
> commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
> the default behavior of alloc_dr() to no longer zero the allocated
> memory.  However,
> only the devm.k.alloc() function were modified to pass in __GFP_ZERO
> which leaves
> any users of devres_alloc() or __devres_alloc() with potentially wrong
> assumptions
> about memory being zero'd upon allocation.
> 
> To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
> behavior of zero'ing memory upon allocation.
[]
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
[]
> @@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
> size, gfp_t gfp)
>  {
>   struct devres *dr;
> 
> - dr = alloc_dr(release, size, gfp);
> + dr = alloc_dr(release, size, gfp | __GFP_ZERO);
>   if (unlikely(!dr))
>   return NULL;
>   return dr->data;

Wouldn't the __devres_alloc need that too?


#ifdef CONFIG_DEBUG_DEVRES
void * __devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
		      const char *name)
{
	struct devres *dr;

	dr = alloc_dr(release, size, gfp);
	if (unlikely(!dr))
		return NULL;
	set_node_dbginfo(&dr->node, name, size);
	return dr->data;
}
EXPORT_SYMBOL_GPL(__devres_alloc);

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Joe Perches]

On Fri, 2013-10-18 at 09:57 -0700, Kevin Hilman wrote:
[]
> A handful of boot panics on ARM platforms were bisected to point at
> the version of this commit that's in linux-next (commit
> 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> makes things happy again.
> 
> Upon further digging, it seems that users of devres_alloc() are
> relying on the previous behavior of having the memory zero'd which is
> no longer the case after $SUBJECT patch.  The change below on top of
> -next makes these ARM boards happy again.
[]
> commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
> the default behavior of alloc_dr() to no longer zero the allocated
> memory.  However,
> only the devm.k.alloc() function were modified to pass in __GFP_ZERO
> which leaves
> any users of devres_alloc() or __devres_alloc() with potentially wrong
> assumptions
> about memory being zero'd upon allocation.
> 
> To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
> behavior of zero'ing memory upon allocation.
[]
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
[]
> @@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
> size, gfp_t gfp)
>  {
>   struct devres *dr;
> 
> - dr = alloc_dr(release, size, gfp);
> + dr = alloc_dr(release, size, gfp | __GFP_ZERO);
>   if (unlikely(!dr))
>   return NULL;
>   return dr->data;

Wouldn't the __devres_alloc need that too?


#ifdef CONFIG_DEBUG_DEVRES
void * __devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
		      const char *name)
{
	struct devres *dr;

	dr = alloc_dr(release, size, gfp);
	if (unlikely(!dr))
		return NULL;
	set_node_dbginfo(&dr->node, name, size);
	return dr->data;
}
EXPORT_SYMBOL_GPL(__devres_alloc);

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Kevin Hilman]

On Fri, Oct 18, 2013 at 10:06 AM, Joe Perches <joe@perches.com> wrote:
> On Fri, 2013-10-18 at 09:57 -0700, Kevin Hilman wrote:
> []
>> A handful of boot panics on ARM platforms were bisected to point at
>> the version of this commit that's in linux-next (commit
>> 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
>> makes things happy again.
>>
>> Upon further digging, it seems that users of devres_alloc() are
>> relying on the previous behavior of having the memory zero'd which is
>> no longer the case after $SUBJECT patch.  The change below on top of
>> -next makes these ARM boards happy again.
> []
>> commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
>> the default behavior of alloc_dr() to no longer zero the allocated
>> memory.  However,
>> only the devm.k.alloc() function were modified to pass in __GFP_ZERO
>> which leaves
>> any users of devres_alloc() or __devres_alloc() with potentially wrong
>> assumptions
>> about memory being zero'd upon allocation.
>>
>> To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
>> behavior of zero'ing memory upon allocation.
> []
>> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> []
>> @@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
>> size, gfp_t gfp)
>>  {
>>   struct devres *dr;
>>
>> - dr = alloc_dr(release, size, gfp);
>> + dr = alloc_dr(release, size, gfp | __GFP_ZERO);
>>   if (unlikely(!dr))
>>   return NULL;
>>   return dr->data;
>
> Wouldn't the __devres_alloc need that too?

Yeah,  I had mentioned __devres_alloc() in the changelog, but missed
it in the actual patch. :(
Anyways, I had quickly sent an updated patch, but our mails must've
crossed paths.

Kevin

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Kevin Hilman]

On Fri, Oct 18, 2013 at 10:06 AM, Joe Perches <joe@perches.com> wrote:
> On Fri, 2013-10-18 at 09:57 -0700, Kevin Hilman wrote:
> []
>> A handful of boot panics on ARM platforms were bisected to point at
>> the version of this commit that's in linux-next (commit
>> 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
>> makes things happy again.
>>
>> Upon further digging, it seems that users of devres_alloc() are
>> relying on the previous behavior of having the memory zero'd which is
>> no longer the case after $SUBJECT patch.  The change below on top of
>> -next makes these ARM boards happy again.
> []
>> commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
>> the default behavior of alloc_dr() to no longer zero the allocated
>> memory.  However,
>> only the devm.k.alloc() function were modified to pass in __GFP_ZERO
>> which leaves
>> any users of devres_alloc() or __devres_alloc() with potentially wrong
>> assumptions
>> about memory being zero'd upon allocation.
>>
>> To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
>> behavior of zero'ing memory upon allocation.
> []
>> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> []
>> @@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
>> size, gfp_t gfp)
>>  {
>>   struct devres *dr;
>>
>> - dr = alloc_dr(release, size, gfp);
>> + dr = alloc_dr(release, size, gfp | __GFP_ZERO);
>>   if (unlikely(!dr))
>>   return NULL;
>>   return dr->data;
>
> Wouldn't the __devres_alloc need that too?

Yeah,  I had mentioned __devres_alloc() in the changelog, but missed
it in the actual patch. :(
Anyways, I had quickly sent an updated patch, but our mails must've
crossed paths.

Kevin

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Greg KH]

On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> > A handful of boot panics on ARM platforms were bisected to point at
> > the version of this commit that's in linux-next (commit
> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> > makes things happy again.
> >
> > Upon further digging, it seems that users of devres_alloc() are
> > relying on the previous behavior of having the memory zero'd which is
> > no longer the case after $SUBJECT patch.  The change below on top of
> > -next makes these ARM boards happy again.
> 
> Oops, it should've fixed __devres_alloc() also.  Updated patch below.

Can you send this in a format that I can apply it in?  It was whitespace
damaged.

thanks,

greg k-h

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Greg KH]

On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> > A handful of boot panics on ARM platforms were bisected to point at
> > the version of this commit that's in linux-next (commit
> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> > makes things happy again.
> >
> > Upon further digging, it seems that users of devres_alloc() are
> > relying on the previous behavior of having the memory zero'd which is
> > no longer the case after $SUBJECT patch.  The change below on top of
> > -next makes these ARM boards happy again.
> 
> Oops, it should've fixed __devres_alloc() also.  Updated patch below.

Can you send this in a format that I can apply it in?  It was whitespace
damaged.

thanks,

greg k-h

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Kevin Hilman]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
>> > A handful of boot panics on ARM platforms were bisected to point at
>> > the version of this commit that's in linux-next (commit
>> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
>> > makes things happy again.
>> >
>> > Upon further digging, it seems that users of devres_alloc() are
>> > relying on the previous behavior of having the memory zero'd which is
>> > no longer the case after $SUBJECT patch.  The change below on top of
>> > -next makes these ARM boards happy again.
>> 
>> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
>
> Can you send this in a format that I can apply it in?  It was whitespace
> damaged.

hmm, sorry about that.  This one should work, though I wonder if Andrew
should pick this up since I think the patch that causes the breakage
came through his tree.

Kevin

---------------8<----------------------------------------------------
>From a1962ed4a999fb630a48f75a5ecaf84401d5dbfc Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()

commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated memory.  However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong assumptions
about memory being zero'd upon allocation.

To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.

Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
 drivers/base/devres.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..545c4de 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -111,7 +111,7 @@ void * __devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
 {
 	struct devres *dr;
 
-	dr = alloc_dr(release, size, gfp);
+	dr = alloc_dr(release, size, gfp | __GFP_ZERO);
 	if (unlikely(!dr))
 		return NULL;
 	set_node_dbginfo(&dr->node, name, size);
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t size, gfp_t gfp)
 {
 	struct devres *dr;
 
-	dr = alloc_dr(release, size, gfp);
+	dr = alloc_dr(release, size, gfp | __GFP_ZERO);
 	if (unlikely(!dr))
 		return NULL;
 	return dr->data;
-- 
1.8.3

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Kevin Hilman]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
>> > A handful of boot panics on ARM platforms were bisected to point at
>> > the version of this commit that's in linux-next (commit
>> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
>> > makes things happy again.
>> >
>> > Upon further digging, it seems that users of devres_alloc() are
>> > relying on the previous behavior of having the memory zero'd which is
>> > no longer the case after $SUBJECT patch.  The change below on top of
>> > -next makes these ARM boards happy again.
>> 
>> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
>
> Can you send this in a format that I can apply it in?  It was whitespace
> damaged.

hmm, sorry about that.  This one should work, though I wonder if Andrew
should pick this up since I think the patch that causes the breakage
came through his tree.

Kevin

---------------8<----------------------------------------------------
>From a1962ed4a999fb630a48f75a5ecaf84401d5dbfc Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()

commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated memory.  However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong assumptions
about memory being zero'd upon allocation.

To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.

Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
 drivers/base/devres.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..545c4de 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -111,7 +111,7 @@ void * __devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
 {
 	struct devres *dr;
 
-	dr = alloc_dr(release, size, gfp);
+	dr = alloc_dr(release, size, gfp | __GFP_ZERO);
 	if (unlikely(!dr))
 		return NULL;
 	set_node_dbginfo(&dr->node, name, size);
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t size, gfp_t gfp)
 {
 	struct devres *dr;
 
-	dr = alloc_dr(release, size, gfp);
+	dr = alloc_dr(release, size, gfp | __GFP_ZERO);
 	if (unlikely(!dr))
 		return NULL;
 	return dr->data;
-- 
1.8.3

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Greg KH]

On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> >> > A handful of boot panics on ARM platforms were bisected to point at
> >> > the version of this commit that's in linux-next (commit
> >> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> >> > makes things happy again.
> >> >
> >> > Upon further digging, it seems that users of devres_alloc() are
> >> > relying on the previous behavior of having the memory zero'd which is
> >> > no longer the case after $SUBJECT patch.  The change below on top of
> >> > -next makes these ARM boards happy again.
> >> 
> >> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
> >
> > Can you send this in a format that I can apply it in?  It was whitespace
> > damaged.
> 
> hmm, sorry about that.  This one should work, though I wonder if Andrew
> should pick this up since I think the patch that causes the breakage
> came through his tree.

No, the patch is in my tree, not Andrew's.

Joe, can I get a signed-off-by for this?

thanks,

greg k-h

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Greg KH]

On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> >> > A handful of boot panics on ARM platforms were bisected to point at
> >> > the version of this commit that's in linux-next (commit
> >> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> >> > makes things happy again.
> >> >
> >> > Upon further digging, it seems that users of devres_alloc() are
> >> > relying on the previous behavior of having the memory zero'd which is
> >> > no longer the case after $SUBJECT patch.  The change below on top of
> >> > -next makes these ARM boards happy again.
> >> 
> >> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
> >
> > Can you send this in a format that I can apply it in?  It was whitespace
> > damaged.
> 
> hmm, sorry about that.  This one should work, though I wonder if Andrew
> should pick this up since I think the patch that causes the breakage
> came through his tree.

No, the patch is in my tree, not Andrew's.

Joe, can I get a signed-off-by for this?

thanks,

greg k-h

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Joe Perches]

On Sat, 2013-10-19 at 19:57 -0700, Greg KH wrote:
> On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
> > Greg KH <gregkh@linuxfoundation.org> writes:
> > 
> > > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> > >> > A handful of boot panics on ARM platforms were bisected to point at
> > >> > the version of this commit that's in linux-next (commit
> > >> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> > >> > makes things happy again.
> > >> >
> > >> > Upon further digging, it seems that users of devres_alloc() are
> > >> > relying on the previous behavior of having the memory zero'd which is
> > >> > no longer the case after $SUBJECT patch.  The change below on top of
> > >> > -next makes these ARM boards happy again.
> > >> 
> > >> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
> > >
> > > Can you send this in a format that I can apply it in?  It was whitespace
> > > damaged.
> > 
> > hmm, sorry about that.  This one should work, though I wonder if Andrew
> > should pick this up since I think the patch that causes the breakage
> > came through his tree.
> 
> No, the patch is in my tree, not Andrew's.
> 
> Joe, can I get a signed-off-by for this?

If you want.

Signed-off-by: Joe Perches <joe@perches.com>

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Joe Perches]

On Sat, 2013-10-19 at 19:57 -0700, Greg KH wrote:
> On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
> > Greg KH <gregkh@linuxfoundation.org> writes:
> > 
> > > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> > >> > A handful of boot panics on ARM platforms were bisected to point at
> > >> > the version of this commit that's in linux-next (commit
> > >> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> > >> > makes things happy again.
> > >> >
> > >> > Upon further digging, it seems that users of devres_alloc() are
> > >> > relying on the previous behavior of having the memory zero'd which is
> > >> > no longer the case after $SUBJECT patch.  The change below on top of
> > >> > -next makes these ARM boards happy again.
> > >> 
> > >> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
> > >
> > > Can you send this in a format that I can apply it in?  It was whitespace
> > > damaged.
> > 
> > hmm, sorry about that.  This one should work, though I wonder if Andrew
> > should pick this up since I think the patch that causes the breakage
> > came through his tree.
> 
> No, the patch is in my tree, not Andrew's.
> 
> Joe, can I get a signed-off-by for this?

If you want.

Signed-off-by: Joe Perches <joe@perches.com>

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Olof Johansson]

On Sun, Oct 20, 2013 at 8:22 AM, Joe Perches <joe@perches.com> wrote:
> On Sat, 2013-10-19 at 19:57 -0700, Greg KH wrote:
>> On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
>> > Greg KH <gregkh@linuxfoundation.org> writes:
>> >
>> > > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
>> > >> > A handful of boot panics on ARM platforms were bisected to point at
>> > >> > the version of this commit that's in linux-next (commit
>> > >> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
>> > >> > makes things happy again.
>> > >> >
>> > >> > Upon further digging, it seems that users of devres_alloc() are
>> > >> > relying on the previous behavior of having the memory zero'd which is
>> > >> > no longer the case after $SUBJECT patch.  The change below on top of
>> > >> > -next makes these ARM boards happy again.
>> > >>
>> > >> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
>> > >
>> > > Can you send this in a format that I can apply it in?  It was whitespace
>> > > damaged.
>> >
>> > hmm, sorry about that.  This one should work, though I wonder if Andrew
>> > should pick this up since I think the patch that causes the breakage
>> > came through his tree.
>>
>> No, the patch is in my tree, not Andrew's.
>>
>> Joe, can I get a signed-off-by for this?
>
> If you want.
>
> Signed-off-by: Joe Perches <joe@perches.com>

Acked-by: Olof Johansson <olof@lixom.net>


Greg, would you mind picking this up? It's still broken in -next and I
don't want it to mask other issues that might be introduced.


-Olof

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Olof Johansson]

On Sun, Oct 20, 2013 at 8:22 AM, Joe Perches <joe@perches.com> wrote:
> On Sat, 2013-10-19 at 19:57 -0700, Greg KH wrote:
>> On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
>> > Greg KH <gregkh@linuxfoundation.org> writes:
>> >
>> > > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
>> > >> > A handful of boot panics on ARM platforms were bisected to point at
>> > >> > the version of this commit that's in linux-next (commit
>> > >> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
>> > >> > makes things happy again.
>> > >> >
>> > >> > Upon further digging, it seems that users of devres_alloc() are
>> > >> > relying on the previous behavior of having the memory zero'd which is
>> > >> > no longer the case after $SUBJECT patch.  The change below on top of
>> > >> > -next makes these ARM boards happy again.
>> > >>
>> > >> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
>> > >
>> > > Can you send this in a format that I can apply it in?  It was whitespace
>> > > damaged.
>> >
>> > hmm, sorry about that.  This one should work, though I wonder if Andrew
>> > should pick this up since I think the patch that causes the breakage
>> > came through his tree.
>>
>> No, the patch is in my tree, not Andrew's.
>>
>> Joe, can I get a signed-off-by for this?
>
> If you want.
>
> Signed-off-by: Joe Perches <joe@perches.com>

Acked-by: Olof Johansson <olof@lixom.net>


Greg, would you mind picking this up? It's still broken in -next and I
don't want it to mask other issues that might be introduced.


-Olof

Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Greg KH]

On Fri, Oct 25, 2013 at 05:59:56AM -0700, Olof Johansson wrote:
> On Sun, Oct 20, 2013 at 8:22 AM, Joe Perches <joe@perches.com> wrote:
> > On Sat, 2013-10-19 at 19:57 -0700, Greg KH wrote:
> >> On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
> >> > Greg KH <gregkh@linuxfoundation.org> writes:
> >> >
> >> > > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> >> > >> > A handful of boot panics on ARM platforms were bisected to point at
> >> > >> > the version of this commit that's in linux-next (commit
> >> > >> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> >> > >> > makes things happy again.
> >> > >> >
> >> > >> > Upon further digging, it seems that users of devres_alloc() are
> >> > >> > relying on the previous behavior of having the memory zero'd which is
> >> > >> > no longer the case after $SUBJECT patch.  The change below on top of
> >> > >> > -next makes these ARM boards happy again.
> >> > >>
> >> > >> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
> >> > >
> >> > > Can you send this in a format that I can apply it in?  It was whitespace
> >> > > damaged.
> >> >
> >> > hmm, sorry about that.  This one should work, though I wonder if Andrew
> >> > should pick this up since I think the patch that causes the breakage
> >> > came through his tree.
> >>
> >> No, the patch is in my tree, not Andrew's.
> >>
> >> Joe, can I get a signed-off-by for this?
> >
> > If you want.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
> 
> Acked-by: Olof Johansson <olof@lixom.net>
> 
> 
> Greg, would you mind picking this up? It's still broken in -next and I
> don't want it to mask other issues that might be introduced.

I picked it up early this morning already, so it will be in the next
-next whenever it gets created...

thanks,

greg k-h

[RFC PATCH] device: Add kernel standard devm_k.alloc functions

[Greg KH]

On Fri, Oct 25, 2013 at 05:59:56AM -0700, Olof Johansson wrote:
> On Sun, Oct 20, 2013 at 8:22 AM, Joe Perches <joe@perches.com> wrote:
> > On Sat, 2013-10-19 at 19:57 -0700, Greg KH wrote:
> >> On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
> >> > Greg KH <gregkh@linuxfoundation.org> writes:
> >> >
> >> > > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> >> > >> > A handful of boot panics on ARM platforms were bisected to point at
> >> > >> > the version of this commit that's in linux-next (commit
> >> > >> > 64c862a839a8db2c02bbaa88b923d13e1208919d).  Reverting this commit
> >> > >> > makes things happy again.
> >> > >> >
> >> > >> > Upon further digging, it seems that users of devres_alloc() are
> >> > >> > relying on the previous behavior of having the memory zero'd which is
> >> > >> > no longer the case after $SUBJECT patch.  The change below on top of
> >> > >> > -next makes these ARM boards happy again.
> >> > >>
> >> > >> Oops, it should've fixed __devres_alloc() also.  Updated patch below.
> >> > >
> >> > > Can you send this in a format that I can apply it in?  It was whitespace
> >> > > damaged.
> >> >
> >> > hmm, sorry about that.  This one should work, though I wonder if Andrew
> >> > should pick this up since I think the patch that causes the breakage
> >> > came through his tree.
> >>
> >> No, the patch is in my tree, not Andrew's.
> >>
> >> Joe, can I get a signed-off-by for this?
> >
> > If you want.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
> 
> Acked-by: Olof Johansson <olof@lixom.net>
> 
> 
> Greg, would you mind picking this up? It's still broken in -next and I
> don't want it to mask other issues that might be introduced.

I picked it up early this morning already, so it will be in the next
-next whenever it gets created...

thanks,

greg k-h