[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGXu5j+Oi_2SyUb=pZ37PtGyPCvuZqnxAaGKDMiTsO0qWE6Rtg@mail.gmail.com>
Date: Thu, 14 Feb 2019 08:22:32 -0800
From: Kees Cook <keescook@...omium.org>
To: Yue Hu <zbestahu@...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] pstore/ram: Avoid possible failure of dummy device unregister
On Thu, Feb 14, 2019 at 3:31 AM Yue Hu <zbestahu@...il.com> wrote:
>
> From 08ac260f36b4c11eb33fa58466462a5e1027bdb3 Mon Sep 17 00:00:00 2001
> From: Yue Hu <zbestahu@...il.com>
> Date: Thu, 14 Feb 2019 19:34:16 +0800
> Subject: [PATCH] pstore/ram: Avoid possible failure of dummy device unregister
>
> If create dummy platform device failed, dummy variable should not
> been set as NULL. Because the following platform_device_unregister()
> will judge if the dummy is NULL or not, if dummy is NULL nothing
> happen for unregister flow.
>
> Signed-off-by: Yue Hu <zbestahu@...il.com>
I've gotten this email a few times today. :)
I already replied that this isn't what we want to do: we have to mark
it NULL since prior to that it was an ERR_PTR, and will break the
unregister.
-Kees
> ---
> fs/pstore/ram.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 4a06675..61bc573 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -994,7 +994,6 @@ static void __init ramoops_register_dummy(void)
> if (IS_ERR(dummy)) {
> pr_info("could not create platform device: %ld\n",
> PTR_ERR(dummy));
> - dummy = NULL;
> ramoops_unregister_dummy();
> }
> }
> --
> 1.9.1
>
--
Kees Cook
Powered by blists - more mailing lists