From: khilman@linaro.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] device: Add kernel standard devm_k.alloc functions
Date: Fri, 18 Oct 2013 22:52:46 -0700 [thread overview]
Message-ID: <8761stu7rl.fsf@linaro.org> (raw)
In-Reply-To: <20131018225702.GA13090@kroah.com> (Greg KH's message of "Fri, 18 Oct 2013 15:57:02 -0700")
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
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@linaro.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Joe Perches <joe@perches.com>, Tejun Heo <tj@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Sangjung Woo <sangjung.woo@samsung.com>,
Olof Johansson <olof@lixom.net>,
Thierry Reding <thierry.reding@gmail.com>,
Guenter Roeck <linux@roeck-us.net>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions
Date: Fri, 18 Oct 2013 22:52:46 -0700 [thread overview]
Message-ID: <8761stu7rl.fsf@linaro.org> (raw)
In-Reply-To: <20131018225702.GA13090@kroah.com> (Greg KH's message of "Fri, 18 Oct 2013 15:57:02 -0700")
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
next prev parent reply other threads:[~2013-10-19 5:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-09 5:32 [RFC PATCH] device: Add kernel standard devm_k.alloc functions Joe Perches
2013-10-09 5:43 ` Greg KH
2013-10-09 6:16 ` Joe Perches
2013-10-09 6:54 ` Greg KH
2013-10-09 7:04 ` Joe Perches
2013-10-09 16:30 ` Tejun Heo
2013-10-09 17:49 ` Joe Perches
2013-10-11 20:11 ` Andrew Morton
2013-10-18 16:57 ` Kevin Hilman
2013-10-18 16:57 ` Kevin Hilman
2013-10-18 17:04 ` Kevin Hilman
2013-10-18 17:04 ` Kevin Hilman
2013-10-18 22:57 ` Greg KH
2013-10-18 22:57 ` Greg KH
2013-10-19 5:52 ` Kevin Hilman [this message]
2013-10-19 5:52 ` Kevin Hilman
2013-10-20 2:57 ` Greg KH
2013-10-20 2:57 ` Greg KH
2013-10-20 15:22 ` Joe Perches
2013-10-20 15:22 ` Joe Perches
2013-10-25 12:59 ` Olof Johansson
2013-10-25 12:59 ` Olof Johansson
2013-10-25 15:23 ` Greg KH
2013-10-25 15:23 ` Greg KH
2013-10-18 17:06 ` Joe Perches
2013-10-18 17:06 ` Joe Perches
2013-10-18 17:11 ` Kevin Hilman
2013-10-18 17:11 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8761stu7rl.fsf@linaro.org \
--to=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.