| Message ID | 8761stu7rl.fsf@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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>
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
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
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;