Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1472458 > unrolled thread

[PATCH 1/2] ramoops: move spin_lock_init after kmalloc error checking

Started byGeliang Tang <geliangtang@gmail.com>
First post2016-08-30 14:30 +0200
Last post2016-09-08 22:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 1/2] ramoops: move spin_lock_init after kmalloc error checking Geliang Tang <geliangtang@gmail.com> - 2016-08-30 14:30 +0200
    Re: [PATCH 1/2] ramoops: move spin_lock_init after kmalloc error checking Kees Cook <keescook@chromium.org> - 2016-09-08 22:50 +0200

#1472458 — [PATCH 1/2] ramoops: move spin_lock_init after kmalloc error checking

FromGeliang Tang <geliangtang@gmail.com>
Date2016-08-30 14:30 +0200
Subject[PATCH 1/2] ramoops: move spin_lock_init after kmalloc error checking
Message-ID<sbQkW-4K2-27@gated-at.bofh.it>
If cxt->pstore.buf allocated failed, no need to initialize
cxt->pstore.buf_lock. So this patch moves spin_lock_init() after the
error checking.

Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
 fs/pstore/ram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 7a034d6..ec1c9e5 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -608,12 +608,12 @@ static int ramoops_probe(struct platform_device *pdev)
 		cxt->pstore.bufsize = 1024; /* LOG_LINE_MAX */
 	cxt->pstore.bufsize = max(cxt->record_size, cxt->pstore.bufsize);
 	cxt->pstore.buf = kmalloc(cxt->pstore.bufsize, GFP_KERNEL);
-	spin_lock_init(&cxt->pstore.buf_lock);
 	if (!cxt->pstore.buf) {
 		pr_err("cannot allocate pstore buffer\n");
 		err = -ENOMEM;
 		goto fail_clear;
 	}
+	spin_lock_init(&cxt->pstore.buf_lock);
 
 	err = pstore_register(&cxt->pstore);
 	if (err) {
-- 
2.7.4

[toc] | [next] | [standalone]


#1479511

FromKees Cook <keescook@chromium.org>
Date2016-09-08 22:50 +0200
Message-ID<sfeqK-2at-35@gated-at.bofh.it>
In reply to#1472458
On Tue, Aug 30, 2016 at 5:24 AM, Geliang Tang <geliangtang@gmail.com> wrote:
> If cxt->pstore.buf allocated failed, no need to initialize
> cxt->pstore.buf_lock. So this patch moves spin_lock_init() after the
> error checking.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
> ---
>  fs/pstore/ram.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 7a034d6..ec1c9e5 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -608,12 +608,12 @@ static int ramoops_probe(struct platform_device *pdev)
>                 cxt->pstore.bufsize = 1024; /* LOG_LINE_MAX */
>         cxt->pstore.bufsize = max(cxt->record_size, cxt->pstore.bufsize);
>         cxt->pstore.buf = kmalloc(cxt->pstore.bufsize, GFP_KERNEL);
> -       spin_lock_init(&cxt->pstore.buf_lock);
>         if (!cxt->pstore.buf) {
>                 pr_err("cannot allocate pstore buffer\n");
>                 err = -ENOMEM;
>                 goto fail_clear;
>         }
> +       spin_lock_init(&cxt->pstore.buf_lock);

Seems fine to me. No harm either way, but better to save on the work.
:) Applied for -next.

Thanks!

-Kees

>
>         err = pstore_register(&cxt->pstore);
>         if (err) {
> --
> 2.7.4
>



-- 
Kees Cook
Nexus Security

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web