public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Andrew McKay <amckay@iders.ca>
Cc: linux-mtd@lists.infradead.org, JiSheng Zhang <jszhang3@gmail.com>
Subject: Re: nand_update_bbt fix
Date: Tue, 11 Aug 2009 18:39:19 +0300	[thread overview]
Message-ID: <1250005159.25202.11.camel@localhost> (raw)
In-Reply-To: <4A80A760.20901@iders.ca>

On Mon, 2009-08-10 at 18:04 -0500, Andrew McKay wrote:
> Hello,
> 
> For NAND parts with 2K pages or larger, kmalloc of one erase block will exceed 
> 128K and fail.  A vmalloc is used in nand_scan_bbt to allocate enough memory for 
> one erase block.  This should likely be the case for nand_update_bbt as well.

I think this is not about parts with 2K pages, but about parts with
256KiB eraseblocks.

> diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
> index 55c23e5..43b8d08 100644
> --- a/drivers/mtd/nand/nand_bbt.c
> +++ b/drivers/mtd/nand/nand_bbt.c
> @@ -1030,7 +1030,7 @@ int nand_update_bbt(struct mtd_info *mtd, loff_t offs)
>    /* Allocate a temporary buffer for one eraseblock incl. oob */
>    len = (1 << this->bbt_erase_shift);
>    len += (len >> this->page_shift) * mtd->oobsize;
> - buf = kmalloc(len, GFP_KERNEL);
> + buf = vmalloc(len);
>    if (!buf) {
>      printk(KERN_ERR "nand_update_bbt: Out of memory\n");
>      return -ENOMEM;
> @@ -1063,7 +1063,7 @@ int nand_update_bbt(struct mtd_info *mtd, loff_t offs)
>    }
> 
>    out:
> - kfree(buf);
> + vfree(buf);
>    return res;
>   }

I would disagree with this patch. Other people are fighting against
vmalloc, because they want to do DMA in their drivers, but they cannot.
I've CCed Zhang who is doing the opposite to what you do.

I think you should instead split the array on several smaller parts
and work with those parts. And since this is a very common task in
MTD, it is better to create a helper library.

You may also take a look at what I suggested to Zhang:
http://lists.infradead.org/pipermail/linux-mtd/2009-August/026845.html

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  reply	other threads:[~2009-08-11 15:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-10 23:04 nand_update_bbt fix Andrew McKay
2009-08-11 15:39 ` Artem Bityutskiy [this message]
2009-08-11 16:03   ` Andrew McKay
2009-08-12  5:51     ` Artem Bityutskiy
2009-08-12 17:37       ` David Brownell
2009-08-13  5:48         ` Artem Bityutskiy

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=1250005159.25202.11.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=amckay@iders.ca \
    --cc=jszhang3@gmail.com \
    --cc=linux-mtd@lists.infradead.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