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

[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]

> 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

[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

[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

[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

[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

[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

[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

[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

[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