Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1479511
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/2] ramoops: move spin_lock_init after kmalloc error checking |
| Date | 2016-09-08 22:50 +0200 |
| Message-ID | <sfeqK-2at-35@gated-at.bofh.it> (permalink) |
| References | <sbQkW-4K2-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[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
csiph-web