mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, greg@kroah.com
Subject: Re: [patch] fix BUG: in fw_realloc_buffer
Date: Mon, 13 Feb 2006 18:00:10 -0500	[thread overview]
Message-ID: <17393.3962.489843.651537@segfault.boston.redhat.com> (raw)
In-Reply-To: <20060213145231.0e8863e8.akpm@osdl.org>

==> Regarding Re: [patch] fix BUG: in fw_realloc_buffer; Andrew Morton <akpm@osdl.org> adds:

akpm> Jeff Moyer <jmoyer@redhat.com> wrote:
>> 
>> Hi,
>> 
>> The fw_realloc_buffer routine does not handle an increase in buffer size of
>> more than 4k.  It's not clear to me why it expects that it will only get an
>> extra 4k of data.  The attached patch modifies fw_realloc_buffer to vmalloc
>> as much memory as is requested, instead of what we previously had + 4k.
>> 
>> I've tested this on my laptop, which would crash occaisionally on boot
>> without the patch.  With the patch, it hasn't crashed, but I can't be
>> certain that this code path is exercised.
>> 
>> Comments are very welcome.
>> 
[snip]

akpm> A little bit neater this way, I think?

> --- devel/drivers/base/firmware_class.c~firmware-fix-bug-in-fw_realloc_buffer	2006-02-13 14:45:52.000000000 -0800
> +++ devel-akpm/drivers/base/firmware_class.c	2006-02-13 14:52:05.000000000 -0800
> @@ -211,18 +211,20 @@ static int
>  fw_realloc_buffer(struct firmware_priv *fw_priv, int min_size)
>  {
>  	u8 *new_data;
> +	int new_size = fw_priv->alloc_size;

>  	if (min_size <= fw_priv->alloc_size)
>  		return 0;

> -	new_data = vmalloc(fw_priv->alloc_size + PAGE_SIZE);
> +	new_size = ALIGN(min_size, PAGE_SIZE);
> +	new_data = vmalloc(new_size);
>  	if (!new_data) {
>  		printk(KERN_ERR "%s: unable to alloc buffer\n", __FUNCTION__);
>  		/* Make sure that we don't keep incomplete data */
>  		fw_load_abort(fw_priv);
>  		return -ENOMEM;
>  	}
> -	fw_priv->alloc_size += PAGE_SIZE;
> +	fw_priv->alloc_size = new_size;
>  	if (fw_priv->fw->data) {
>  		memcpy(new_data, fw_priv->fw->data, fw_priv->fw->size);
>  		vfree(fw_priv->fw->data);
> _

Well, I wasn't sure that you would only need to increase by a PAGE.  If you
only need to account for page_size + alignment, then yes, this is better.
It simply wasn't clear to me that this is how we are called.  If I'm not
mistaken, this is the write routine for a file in sysfs.  If that is the
case, why should we assume that writes are broken up into PAGE_SIZE chunks?

Thanks,

Jeff

  reply	other threads:[~2006-02-13 23:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-13 22:31 Jeff Moyer
2006-02-13 22:52 ` Andrew Morton
2006-02-13 23:00   ` Jeff Moyer [this message]
2006-02-13 23:09     ` Jeff Moyer
2006-02-13 23:12     ` Andrew Morton

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=17393.3962.489843.651537@segfault.boston.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /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®