All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Shijie <b32955@freescale.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>,
	linux-mtd@lists.infradead.org, Fabio Estevam <festevam@gmail.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] mtd: gpmi: Fix NULL pointer dereference
Date: Tue, 12 Nov 2013 10:47:43 +0800	[thread overview]
Message-ID: <528196CF.9090404@freescale.com> (raw)
In-Reply-To: <20131111182324.GE20061@ld-irv-0074.broadcom.com>

于 2013年11月12日 02:23, Brian Norris 写道:
> (2) The second switched the whole NAND buffer over to a kzalloc'd
>     buffer, with NAND_OWN_BUFFERS. I'm not a huge fan of
>     NAND_OWN_BUFFERS, and I think drivers should only be using it if
>     they really need it, for special buffer placement or some other good
>     reason. You just happen to need a buffer "too early", where you can
>     really just allocate a small temporary buffer.
why I use the NAND_OWN_BUFFERS? just for a small temporary buffer?
the answer is no.

For imx23, the work flow is like this:
[1] first check the fingerprint, if we can find it, we will return
immediately.
[2] if [1] failed, such as you erase all the partitions, the gpmi will call
mx23_write_transcription_stamp() to write the fingerprint.

So the @chip->buffer is not only used by the
mx23_check_transcription_stamp(),
but _also_ used by the mx23_write_transcription_stamp() when the gpmi
can not find any
fingerprint in the NAND page.


That's why i use the NAND_OWN_BUFFERS, the buffer can be used by both
the mx23_check_transcription_stamp()
and mx23_write_transcription_stamp().

thanks
Huang Shijie

  reply	other threads:[~2013-11-12  2:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11 17:08 [PATCH] mtd: gpmi: Fix NULL pointer dereference Fabio Estevam
2013-11-11 18:23 ` Brian Norris
2013-11-12  2:47   ` Huang Shijie [this message]
2013-11-12  2:56     ` Brian Norris
2013-11-12  3:44     ` Fabio Estevam
2013-11-12  4:20       ` Huang Shijie
2013-11-12  4:24       ` Brian Norris

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=528196CF.9090404@freescale.com \
    --to=b32955@freescale.com \
    --cc=computersforpeace@gmail.com \
    --cc=fabio.estevam@freescale.com \
    --cc=festevam@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=stable@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.