linux-kernel - Re: [PATCH 1/2] ramoops: move spin_lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGXu5jLiYWs6X17=v2m70K1egaEFRx5vops-SHB-jw2t+nYwfQ@mail.gmail.com>
Date:   Thu, 8 Sep 2016 13:45:06 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Geliang Tang <geliangtang@...il.com>
Cc:     Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] ramoops: move spin_lock_init after kmalloc error checking

On Tue, Aug 30, 2016 at 5:24 AM, Geliang Tang <geliangtang@...il.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@...il.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