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 <[email protected]>
---
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);
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 <[email protected]>
> ---
> 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
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 <[email protected]>
> > ---
> > 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.
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 <[email protected]>
> > > ---
> > > 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
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 <[email protected]>
> > > > ---
> > > > 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.
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
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.
On Tue, 08 Oct 2013 22:32:27 -0700 Joe Perches <[email protected]> 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 <[email protected]>
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 <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: Greg KH <[email protected]>
Cc: Sangjung Woo <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
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);
_
On Fri, Oct 11, 2013 at 1:11 PM, Andrew Morton
<[email protected]> wrote:
> On Tue, 08 Oct 2013 22:32:27 -0700 Joe Perches <[email protected]> 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 <[email protected]>
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 <[email protected]>
---
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
> 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 <[email protected]>
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 <[email protected]>
---
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
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);
On Fri, Oct 18, 2013 at 10:06 AM, Joe Perches <[email protected]> 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
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
Greg KH <[email protected]> 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 <[email protected]>
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 <[email protected]>
---
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
On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
> Greg KH <[email protected]> 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
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 <[email protected]> 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 <[email protected]>
On Sun, Oct 20, 2013 at 8:22 AM, Joe Perches <[email protected]> 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 <[email protected]> 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 <[email protected]>
Acked-by: Olof Johansson <[email protected]>
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
On Fri, Oct 25, 2013 at 05:59:56AM -0700, Olof Johansson wrote:
> On Sun, Oct 20, 2013 at 8:22 AM, Joe Perches <[email protected]> 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 <[email protected]> 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 <[email protected]>
>
> Acked-by: Olof Johansson <[email protected]>
>
>
> 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