| Message ID | CAGa+x864VYoGvOxoK0XnxXH9hKNq9WAZ16XHiFawZY7_2WJttw@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <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
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;