From: Andrew Morton <akpm@osdl.org>
To: "Panagiotis Issaris" <panagiotis.issaris@mech.kuleuven.ac.be>
Cc: linux-kernel@vger.kernel.org, Matt Domsch <Matt_Domsch@dell.com>
Subject: Re: [PATCH 2.6.11-mm1] efi: fix failure handling
Date: Sun, 6 Mar 2005 02:06:27 -0800 [thread overview]
Message-ID: <20050306020627.2b9ca6d0.akpm@osdl.org> (raw)
In-Reply-To: <20050306094717.GA3843@mech.kuleuven.ac.be>
"Panagiotis Issaris" <panagiotis.issaris@mech.kuleuven.ac.be> wrote:
>
> The EFI driver allocates memory and writes into it without checking the
> success of the allocation. Furthermore, on failure of the firmware_register() it
> doesn't free the allocated memory and on failure of the subsys_create_file()
> calls it returns zero instead of the errorcode.
>
Fair enough. But there's potential for behavioural change here.
If subsys_create_file() returns an error then efivars_init() will now
propagate that error. I suspect we'll need a firmware_unregister() in that
case.
>
> diff -pruN linux-2.6.11-orig/drivers/firmware/efivars.c linux-2.6.11-pi/drivers/firmware/efivars.c
> --- linux-2.6.11-orig/drivers/firmware/efivars.c 2005-03-05 02:23:29.000000000 +0100
> +++ linux-2.6.11-pi/drivers/firmware/efivars.c 2005-03-05 21:09:33.000000000 +0100
> @@ -665,13 +665,19 @@ efivars_init(void)
> {
> efi_status_t status = EFI_NOT_FOUND;
> efi_guid_t vendor_guid;
> - efi_char16_t *variable_name = kmalloc(1024, GFP_KERNEL);
> + efi_char16_t *variable_name;
> struct subsys_attribute *attr;
> unsigned long variable_name_size = 1024;
> int i, rc = 0, error = 0;
>
> if (!efi_enabled)
> return -ENODEV;
> +
> + variable_name = kmalloc(variable_name_size, GFP_KERNEL);
> + if (!variable_name)
> + return -ENOMEM;
> +
> + memset(variable_name, 0, variable_name_size);
>
> printk(KERN_INFO "EFI Variables Facility v%s %s\n", EFIVARS_VERSION,
> EFIVARS_DATE);
> @@ -682,8 +688,10 @@ efivars_init(void)
>
> rc = firmware_register(&efi_subsys);
>
> - if (rc)
> + if (rc) {
> + kfree(variable_name);
> return rc;
> + }
>
> kset_set_kset_s(&vars_subsys, efi_subsys);
> subsystem_register(&vars_subsys);
> @@ -693,8 +701,6 @@ efivars_init(void)
> * the variable name and variable data is 1024 bytes.
> */
>
> - memset(variable_name, 0, 1024);
> -
> do {
> variable_name_size = 1024;
>
> @@ -735,7 +741,7 @@ efivars_init(void)
> }
>
> kfree(variable_name);
> - return 0;
> + return error;
> }
>
> static void __exit
next prev parent reply other threads:[~2005-03-06 10:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-06 9:47 Panagiotis Issaris
2005-03-06 10:06 ` Andrew Morton [this message]
2005-03-06 11:34 ` Panagiotis Issaris
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=20050306020627.2b9ca6d0.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=Matt_Domsch@dell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=panagiotis.issaris@mech.kuleuven.ac.be \
/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®