From: Liu ShuoX <shuox.liu@intel.com>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Anton Vorontsov <anton@enomsg.org>,
Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,
yanmin_zhang@linux.intel.com
Subject: Re: [PATCH 2/2] pstore: correct the max_dump_cnt clearing of ramoops
Date: Wed, 12 Mar 2014 17:48:53 +0800 [thread overview]
Message-ID: <20140312094853.GA3067@lskakaxi-intel> (raw)
In-Reply-To: <CAGXu5jLkAdy7ctHRf8Yr36gvOBeJNuph5r7M9HNfH4DxTXpF0g@mail.gmail.com>
On Tue 11.Mar'14 at 13:37:23 -0700, Kees Cook wrote:
>On Mon, Mar 10, 2014 at 11:17 PM, Liu ShuoX <shuox.liu@intel.com> wrote:
>> From: Liu ShuoX <shuox.liu@intel.com>
>>
>> In case that ramoops_init_przs failed, max_dump_cnt won't be reset to
>> zero in error handle path.
>>
>> Signed-off-by: Liu ShuoX <shuox.liu@intel.com>
>> ---
>> fs/pstore/ram.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
>> index 6f96d8c..522e530 100644
>> --- a/fs/pstore/ram.c
>> +++ b/fs/pstore/ram.c
>> @@ -326,6 +326,7 @@ static void ramoops_free_przs(struct ramoops_context
>> *cxt)
>> for (i = 0; !IS_ERR_OR_NULL(cxt->przs[i]); i++)
>> persistent_ram_free(cxt->przs[i]);
>> kfree(cxt->przs);
>> + cxt->max_dump_cnt = 0;
>> }
>> static int ramoops_init_przs(struct device *dev, struct ramoops_context
>> *cxt,
>> @@ -350,7 +351,7 @@ static int ramoops_init_przs(struct device *dev, struct
>> ramoops_context *cxt,
>> GFP_KERNEL);
>> if (!cxt->przs) {
>> dev_err(dev, "failed to initialize a prz array for
>> dumps\n");
>> - return -ENOMEM;
>> + goto fail_prz;
>
>This will have no effect. If cxt->przs == NULL, ramoops_free_przs will
>immediately exit too, not hitting your max_dump_cnt = 0 change.
>Perhaps move the =0 in that function to the top before the check and
>return?
Yes, you are right. Below has the latest patch which move the =0 to the
top of that function, just as you mentioned. Thanks.
>
>> }
>> for (i = 0; i < cxt->max_dump_cnt; i++) {
>> @@ -508,7 +509,6 @@ fail_buf:
>> kfree(cxt->pstore.buf);
>> fail_clear:
>> cxt->pstore.bufsize = 0;
>> - cxt->max_dump_cnt = 0;
>> fail_cnt:
>> kfree(cxt->fprz);
>> fail_init_fprz:
>> --
>> 1.8.3.2
>>
>
>Otherwise, yes, once fixed, this clean-up looks good -- it keeps the
>variable initialization and cleanup all in ramoops_init_przs() which
>is how it should be.
>
>Thanks!
>
>-Kees
-----
From: Liu ShuoX <shuox.liu@intel.com>
In case that ramoops_init_przs failed, max_dump_cnt won't be reset to
zero in error handle path.
Signed-off-by: Liu ShuoX <shuox.liu@intel.com>
---
fs/pstore/ram.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 6f96d8c..3b57443 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -320,6 +320,7 @@ static void ramoops_free_przs(struct ramoops_context *cxt)
{
int i;
+ cxt->max_dump_cnt = 0;
if (!cxt->przs)
return;
@@ -350,7 +351,7 @@ static int ramoops_init_przs(struct device *dev, struct ramoops_context *cxt,
GFP_KERNEL);
if (!cxt->przs) {
dev_err(dev, "failed to initialize a prz array for dumps\n");
- return -ENOMEM;
+ goto fail_prz;
}
for (i = 0; i < cxt->max_dump_cnt; i++) {
@@ -508,7 +509,6 @@ fail_buf:
kfree(cxt->pstore.buf);
fail_clear:
cxt->pstore.bufsize = 0;
- cxt->max_dump_cnt = 0;
fail_cnt:
kfree(cxt->fprz);
fail_init_fprz:
--
1.8.3.2
next prev parent reply other threads:[~2014-03-12 9:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-11 6:15 [PATCH 1/2] pstore: fix NULL pointer fault if get NULL prz in ramoops_get_next_prz Liu ShuoX
2014-03-11 6:17 ` [PATCH 2/2] pstore: correct the max_dump_cnt clearing of ramoops Liu ShuoX
2014-03-11 20:37 ` Kees Cook
2014-03-12 9:48 ` Liu ShuoX [this message]
2014-03-12 14:55 ` Kees Cook
2014-03-11 20:30 ` [PATCH 1/2] pstore: fix NULL pointer fault if get NULL prz in ramoops_get_next_prz Kees Cook
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=20140312094853.GA3067@lskakaxi-intel \
--to=shuox.liu@intel.com \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=yanmin_zhang@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®