mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®