All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liang Yang <liang.yang@amlogic.com>
To: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Jianxin Pan <jianxin.pan@amlogic.com>,
	<linux-mtd@lists.infradead.org>,
	Yixun Lan <yixun.lan@amlogic.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Carlo Caione <carlo@caione.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Rob Herring <robh@kernel.org>, Jian Hu <jian.hu@amlogic.com>,
	Hanjie Lin <hanjie.lin@amlogic.com>,
	Victor Wan <victor.wan@amlogic.com>,
	<linux-amlogic@lists.infradead.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
Date: Fri, 19 Oct 2018 17:01:51 +0800	[thread overview]
Message-ID: <0b07e022-60f5-6263-bfa7-779e7aa3cbe1@amlogic.com> (raw)
In-Reply-To: <20181019104248.528a3409@bbrezillon>



On 2018/10/19 16:42, Boris Brezillon wrote:
> On Fri, 19 Oct 2018 16:29:40 +0800
> Liang Yang <liang.yang@amlogic.com> wrote:
> 
>> On 2018/10/19 4:50, Boris Brezillon wrote:
>>> On Thu, 18 Oct 2018 13:09:05 +0800
>>> Jianxin Pan <jianxin.pan@amlogic.com> wrote:
>>>    
>>>> +static int meson_nfc_buffer_init(struct mtd_info *mtd)
>>>> +{
>>>> +	struct nand_chip *nand = mtd_to_nand(mtd);
>>>> +	struct meson_nfc *nfc = nand_get_controller_data(nand);
>>>> +	static int max_page_bytes, max_info_bytes;
>>>> +	int page_bytes, info_bytes;
>>>> +	int nsectors;
>>>> +
>>>> +	nsectors = mtd->writesize / nand->ecc.size;
>>>> +	page_bytes =  mtd->writesize + mtd->oobsize;
>>>> +	info_bytes = nsectors * PER_INFO_BYTE;
>>>> +
>>>> +	if (nfc->data_buf && nfc->info_buf) {
>>>> +		if (max_page_bytes < page_bytes)
>>>> +			meson_nfc_free_buffer(nfc);
>>>> +		else
>>>> +			return 0;
>>>> +	}
>>>> +
>>>> +	max_page_bytes = max_t(int, max_page_bytes, page_bytes);
>>>> +	max_info_bytes = max_t(int, max_info_bytes, info_bytes);
>>>> +
>>>> +	nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);
>>>
>>> Is there a good reason for not using chip->data_buf and allocating a
>>> new buffer here?
>>>    
>> when calling read_oob or write_oob, i need a mid-buffer which is used in
>> meson_nfc_prase_data_oob(). i.e. after reading a page data into
>> nfc->data_buf, I will format it and transfer to chip->data_buf.
>>
>>
>>>> +	if (!nfc->data_buf)
>>>> +		return -ENOMEM;
>>>> +
>>>> +	nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
>>>> +	if (!nfc->info_buf) {
>>>> +		kfree(nfc->data_buf);
>>>> +		return -ENOMEM;
>>>> +	}
>>>
>>> I'd recommend moving this info_buf in the priv chip struct, otherwise
>>> you'll have to protect nfc->info_buf with a lock to prevent an already
>>> register chip from using this pointer while you're reallocating the
>>> buffer. Also, I think you have a memleak here.
>>>    
>> ok, i will move it in the chip struct .
>>
>> but how memleak happens even i have called meson_nfc_free_buffer before
>> and free data_buf if info_buf alloc faied.
> 
> You're right, I missed the call to meson_nfc_free_buffer() when
> max_page_bytes < page_bytes. Still, this part is racy, just like the
> nfc->data_buf replacement is if you have several NAND chips. I'd
> recommend moving those bufs to the priv chip struct.
> 

ok. i will move data_duf and info_buf to priv chip struct.

>>
>>>> +
>>>> +	return 0;
>>>> +}
>>>
>>> .
>>>    
> 
> .
> 

WARNING: multiple messages have this Message-ID (diff)
From: liang.yang@amlogic.com (Liang Yang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
Date: Fri, 19 Oct 2018 17:01:51 +0800	[thread overview]
Message-ID: <0b07e022-60f5-6263-bfa7-779e7aa3cbe1@amlogic.com> (raw)
In-Reply-To: <20181019104248.528a3409@bbrezillon>



On 2018/10/19 16:42, Boris Brezillon wrote:
> On Fri, 19 Oct 2018 16:29:40 +0800
> Liang Yang <liang.yang@amlogic.com> wrote:
> 
>> On 2018/10/19 4:50, Boris Brezillon wrote:
>>> On Thu, 18 Oct 2018 13:09:05 +0800
>>> Jianxin Pan <jianxin.pan@amlogic.com> wrote:
>>>    
>>>> +static int meson_nfc_buffer_init(struct mtd_info *mtd)
>>>> +{
>>>> +	struct nand_chip *nand = mtd_to_nand(mtd);
>>>> +	struct meson_nfc *nfc = nand_get_controller_data(nand);
>>>> +	static int max_page_bytes, max_info_bytes;
>>>> +	int page_bytes, info_bytes;
>>>> +	int nsectors;
>>>> +
>>>> +	nsectors = mtd->writesize / nand->ecc.size;
>>>> +	page_bytes =  mtd->writesize + mtd->oobsize;
>>>> +	info_bytes = nsectors * PER_INFO_BYTE;
>>>> +
>>>> +	if (nfc->data_buf && nfc->info_buf) {
>>>> +		if (max_page_bytes < page_bytes)
>>>> +			meson_nfc_free_buffer(nfc);
>>>> +		else
>>>> +			return 0;
>>>> +	}
>>>> +
>>>> +	max_page_bytes = max_t(int, max_page_bytes, page_bytes);
>>>> +	max_info_bytes = max_t(int, max_info_bytes, info_bytes);
>>>> +
>>>> +	nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);
>>>
>>> Is there a good reason for not using chip->data_buf and allocating a
>>> new buffer here?
>>>    
>> when calling read_oob or write_oob, i need a mid-buffer which is used in
>> meson_nfc_prase_data_oob(). i.e. after reading a page data into
>> nfc->data_buf, I will format it and transfer to chip->data_buf.
>>
>>
>>>> +	if (!nfc->data_buf)
>>>> +		return -ENOMEM;
>>>> +
>>>> +	nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
>>>> +	if (!nfc->info_buf) {
>>>> +		kfree(nfc->data_buf);
>>>> +		return -ENOMEM;
>>>> +	}
>>>
>>> I'd recommend moving this info_buf in the priv chip struct, otherwise
>>> you'll have to protect nfc->info_buf with a lock to prevent an already
>>> register chip from using this pointer while you're reallocating the
>>> buffer. Also, I think you have a memleak here.
>>>    
>> ok, i will move it in the chip struct .
>>
>> but how memleak happens even i have called meson_nfc_free_buffer before
>> and free data_buf if info_buf alloc faied.
> 
> You're right, I missed the call to meson_nfc_free_buffer() when
> max_page_bytes < page_bytes. Still, this part is racy, just like the
> nfc->data_buf replacement is if you have several NAND chips. I'd
> recommend moving those bufs to the priv chip struct.
> 

ok. i will move data_duf and info_buf to priv chip struct.

>>
>>>> +
>>>> +	return 0;
>>>> +}
>>>
>>> .
>>>    
> 
> .
> 

WARNING: multiple messages have this Message-ID (diff)
From: liang.yang@amlogic.com (Liang Yang)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
Date: Fri, 19 Oct 2018 17:01:51 +0800	[thread overview]
Message-ID: <0b07e022-60f5-6263-bfa7-779e7aa3cbe1@amlogic.com> (raw)
In-Reply-To: <20181019104248.528a3409@bbrezillon>



On 2018/10/19 16:42, Boris Brezillon wrote:
> On Fri, 19 Oct 2018 16:29:40 +0800
> Liang Yang <liang.yang@amlogic.com> wrote:
> 
>> On 2018/10/19 4:50, Boris Brezillon wrote:
>>> On Thu, 18 Oct 2018 13:09:05 +0800
>>> Jianxin Pan <jianxin.pan@amlogic.com> wrote:
>>>    
>>>> +static int meson_nfc_buffer_init(struct mtd_info *mtd)
>>>> +{
>>>> +	struct nand_chip *nand = mtd_to_nand(mtd);
>>>> +	struct meson_nfc *nfc = nand_get_controller_data(nand);
>>>> +	static int max_page_bytes, max_info_bytes;
>>>> +	int page_bytes, info_bytes;
>>>> +	int nsectors;
>>>> +
>>>> +	nsectors = mtd->writesize / nand->ecc.size;
>>>> +	page_bytes =  mtd->writesize + mtd->oobsize;
>>>> +	info_bytes = nsectors * PER_INFO_BYTE;
>>>> +
>>>> +	if (nfc->data_buf && nfc->info_buf) {
>>>> +		if (max_page_bytes < page_bytes)
>>>> +			meson_nfc_free_buffer(nfc);
>>>> +		else
>>>> +			return 0;
>>>> +	}
>>>> +
>>>> +	max_page_bytes = max_t(int, max_page_bytes, page_bytes);
>>>> +	max_info_bytes = max_t(int, max_info_bytes, info_bytes);
>>>> +
>>>> +	nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);
>>>
>>> Is there a good reason for not using chip->data_buf and allocating a
>>> new buffer here?
>>>    
>> when calling read_oob or write_oob, i need a mid-buffer which is used in
>> meson_nfc_prase_data_oob(). i.e. after reading a page data into
>> nfc->data_buf, I will format it and transfer to chip->data_buf.
>>
>>
>>>> +	if (!nfc->data_buf)
>>>> +		return -ENOMEM;
>>>> +
>>>> +	nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
>>>> +	if (!nfc->info_buf) {
>>>> +		kfree(nfc->data_buf);
>>>> +		return -ENOMEM;
>>>> +	}
>>>
>>> I'd recommend moving this info_buf in the priv chip struct, otherwise
>>> you'll have to protect nfc->info_buf with a lock to prevent an already
>>> register chip from using this pointer while you're reallocating the
>>> buffer. Also, I think you have a memleak here.
>>>    
>> ok, i will move it in the chip struct .
>>
>> but how memleak happens even i have called meson_nfc_free_buffer before
>> and free data_buf if info_buf alloc faied.
> 
> You're right, I missed the call to meson_nfc_free_buffer() when
> max_page_bytes < page_bytes. Still, this part is racy, just like the
> nfc->data_buf replacement is if you have several NAND chips. I'd
> recommend moving those bufs to the priv chip struct.
> 

ok. i will move data_duf and info_buf to priv chip struct.

>>
>>>> +
>>>> +	return 0;
>>>> +}
>>>
>>> .
>>>    
> 
> .
> 

  reply	other threads:[~2018-10-19  9:02 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-18  5:09 [PATCH v5 0/2] mtd: rawnand: meson: add Amlogic NAND driver support Jianxin Pan
2018-10-18  5:09 ` Jianxin Pan
2018-10-18  5:09 ` Jianxin Pan
2018-10-18  5:09 ` Jianxin Pan
2018-10-18  5:09 ` [PATCH v5 1/2] dt-bindings: nand: meson: add Amlogic NAND controller driver Jianxin Pan
2018-10-18  5:09   ` Jianxin Pan
2018-10-18  5:09   ` Jianxin Pan
2018-10-18  5:09   ` Jianxin Pan
2018-10-18 16:48   ` Rob Herring
2018-10-18 16:48     ` Rob Herring
2018-10-18 16:48     ` Rob Herring
2018-10-18 16:48     ` Rob Herring
2018-10-18  5:09 ` [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller Jianxin Pan
2018-10-18  5:09   ` Jianxin Pan
2018-10-18  5:09   ` Jianxin Pan
2018-10-18 14:24   ` Boris Brezillon
2018-10-18 14:24     ` Boris Brezillon
2018-10-18 14:24     ` Boris Brezillon
2018-10-19  7:29     ` Liang Yang
2018-10-19  7:29       ` Liang Yang
2018-10-19  7:29       ` Liang Yang
2018-10-18 19:33   ` Boris Brezillon
2018-10-18 19:33     ` Boris Brezillon
2018-10-18 19:33     ` Boris Brezillon
2018-10-19  7:29     ` Liang Yang
2018-10-19  7:29       ` Liang Yang
2018-10-19  7:29       ` Liang Yang
2018-10-19  8:10       ` Boris Brezillon
2018-10-19  8:10         ` Boris Brezillon
2018-10-19  8:10         ` Boris Brezillon
2018-10-19  8:30         ` Liang Yang
2018-10-19  8:30           ` Liang Yang
2018-10-19  8:30           ` Liang Yang
2018-10-18 20:34   ` Boris Brezillon
2018-10-18 20:34     ` Boris Brezillon
2018-10-18 20:34     ` Boris Brezillon
2018-10-18 20:39   ` Boris Brezillon
2018-10-18 20:39     ` Boris Brezillon
2018-10-18 20:39     ` Boris Brezillon
2018-10-19  8:04     ` Liang Yang
2018-10-19  8:04       ` Liang Yang
2018-10-19  8:04       ` Liang Yang
2018-10-18 20:50   ` Boris Brezillon
2018-10-18 20:50     ` Boris Brezillon
2018-10-18 20:50     ` Boris Brezillon
2018-10-19  8:29     ` Liang Yang
2018-10-19  8:29       ` Liang Yang
2018-10-19  8:29       ` Liang Yang
2018-10-19  8:42       ` Boris Brezillon
2018-10-19  8:42         ` Boris Brezillon
2018-10-19  8:42         ` Boris Brezillon
2018-10-19  9:01         ` Liang Yang [this message]
2018-10-19  9:01           ` Liang Yang
2018-10-19  9:01           ` Liang Yang

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=0b07e022-60f5-6263-bfa7-779e7aa3cbe1@amlogic.com \
    --to=liang.yang@amlogic.com \
    --cc=boris.brezillon@bootlin.com \
    --cc=carlo@caione.org \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=hanjie.lin@amlogic.com \
    --cc=jbrunet@baylibre.com \
    --cc=jian.hu@amlogic.com \
    --cc=jianxin.pan@amlogic.com \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=narmstrong@baylibre.com \
    --cc=richard@nod.at \
    --cc=robh@kernel.org \
    --cc=victor.wan@amlogic.com \
    --cc=yixun.lan@amlogic.com \
    /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.