All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vignesh Raghavendra <vigneshr@ti.com>
To: Tokunori Ikegami <ikegami_to@yahoo.co.jp>,
	"'liujian (CE)'" <liujian56@huawei.com>
Cc: "'Boris Brezillon'" <boris.brezillon@collabora.com>,
	"'Tokunori Ikegami'" <ikegami.t@gmail.com>,
	"bbrezillon@kernel.org" <bbrezillon@kernel.org>,
	"ikegami@allied-telesis.co.jp" <ikegami@allied-telesis.co.jp>,
	"richard@nod.at" <richard@nod.at>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"marek.vasut@gmail.com" <marek.vasut@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"keescook@chromium.org" <keescook@chromium.org>
Subject: Re: [PATCH v3] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
Date: Sat, 2 Mar 2019 14:27:54 +0530	[thread overview]
Message-ID: <de75d4f6-dfff-26e0-e191-6240ffc20223@ti.com> (raw)
In-Reply-To: <001c01d4d057$f68572e0$e39058a0$@yahoo.co.jp>



On 01-Mar-19 11:25 PM, Tokunori Ikegami wrote:
>>>> [...]
>>>>>>>>> In function do_write_buffer(), in the for loop, there is a
>>>>>>>>> case chip_ready() returns 1 while chip_good() returns 0, so
>>>>>>>>> it never break the loop.
>>>>>>>>> To fix this, chip_good() is enough and it should timeout if
>>>>>>>>> it stay bad for a while.
>>>>>>>>>
>>>>>>>>> Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write
>>>>>>>>> buffer to check correct value")
>>>>>>>>> Signed-off-by: Yi Huaijie <yihuaijie@huawei.com>
>>>>>>>>> Signed-off-by: Liu Jian <liujian56@huawei.com>
>>>>>>>>> Reviewed-by: Tokunori Ikegami <ikegami_to@yahoo.co.jp>
>>>>>>>>> ---
>>>>>>>>> v2->v3:
>>>>>>>>> Follow Vignesh's advice:
>>>>>>>>> add one more check for check_good() even when time_after()
>>>>>>>>> returns
>>>>>> true.
>>>>>>>>>
>>>>>>>>>  drivers/mtd/chips/cfi_cmdset_0002.c | 2 +-
>>>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
>>>>>>>>> b/drivers/mtd/chips/cfi_cmdset_0002.c
>>>>>>>>> index 72428b6..3da2376 100644
>>>>>>>>> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
>>>>>>>>> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
>>>>>>>>> @@ -1876,7 +1876,7 @@ static int __xipram
>>>>>>>>> do_write_buffer(struct map_info *map, struct flchip *chip,
>>>>>>>>>  			continue;
>>>>>>>>>  		}
>>>>>>>>>
>>>>>>>>> -		if (time_after(jiffies, timeo)
>>>>>>>>> && !chip_ready(map, adr))
>>>>>>>>> +		if (time_after(jiffies, timeo)
>>>>>>>>> && !chip_good(map, adr, datum))
>>>>>>>>
>>>>>>>>   Just another idea to understand easily.
>>>>>>>>
>>>>>>>>     unsigned long now = jiffies;
>>>>>>>>
>>>>>>>>     if (chip_good(map, adr, datum)) {
>>>>>>>>         xip_enable(map, chip, adr);
>>>>>>>>         goto op_done;
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     if (time_after(now, timeo) {
>>>>>>>>         break;
>>>>>>>>     }
>>>>>>>>
>>>>>>>
>>>>>>> Thank you~. It is more easier to understand!
>>>>>>> If there are no other comments, I will send new patch again ):
>>>>>>
>>>>>> Except this version no longer does what Vignesh suggested. See
>>>>>> how you no longer test if chip_good() is true if time_after()
>>>>>> returns true. So, imagine the thread entering this function is
>>>>>> preempted just after the first chip_good() test, and resumed a
>>>>>> few ms later. time_after() will return true, but chip_good()
>>>>>> might also return true, and you ignore it.
>>>>>
>>>>> I think that the following 3 versions will be worked for
>>>>> time_after()
>>>> as a same result and follow the Vignesh-san suggestion.
>>>>>
>>>>
>>>> As Boris explained above version 3 does not really follow my
>>>> suggestion... Please see below
>>>>
>>>>> 1. Original Vignesh-san suggestion
>>>>>
>>>>> 	if (chip_good(map, adr, datum)) {
>>>>> 		xip_enable(map, chip, adr);
>>>>> 		goto op_done;
>>>>> 	}
>>>>>
>>>>> 	if (time_after(jiffies, timeo)) {
>>>>> 		/* Test chip_good() if TRUE incorrectly again so
>>>>> write
>>>> failure by time_after() can be avoided. */
>>>>> 		if (chip_good(map, adr, datum)) {
>>>>> 			xip_enable(map, chip, adr);
>>>>> 			goto op_done;
>>>>> 		}
>>>>> 		break;
>>>>> 	}
>>>>>
>>>>
>>>>
>>>> Right, here we check chip_good() once _even when time_after() is
>>>> true_ to avoid _spurious_ timeout
>>>>
>>>>> 2. Liujian-san v3 patch
>>>>>
>>>>> 	/* Test chip_good() if FALSE correctly so write failure
>>>>> by
>>>> time_after() can be avoided. */
>>>>> 	if (time_after(jiffies, timeo) && !chip_good(map, adr))
>>>>> 		break;
>>>>>
>>>>> 	if (chip_good(map, adr, datum)) {
>>>>> 		xip_enable(map, chip, adr);
>>>>> 		goto op_done;
>>>>> 	}
>>>>>
>>>>
>>>> This is a better version of 1
>>>>
>>>>> 3. My idea
>>>>>
>>>>> 	/* Save current jiffies value before chip_good() to avoid
>>>>> write
>>>> failure by time_after() without testing chip_good() again. */
>>>>> 	unsigned long now = jiffies;
>>>>>
>>>>> 	if (chip_good(map, adr, datum)) {
>>>>> 		xip_enable(map, chip, adr);
>>>>> 		goto op_done;
>>>>> 	}
>>>>>
>>>>
>>>> What if thread gets pre-empted at this point and is re-scheduled
>>>> exactly after timeo jiffies have elapsed? Below check would be true
>>>> and exit loop
>>>
>>>   I think that the jiffies value now is save before chip_good() so
>>> below check would be false and not exit loop.
>>

Ok, I get it now.

>> True, I overlooked that part, and so Vignesh did. This proves one
>> thing: code is not easier to follow with your version. IMO, if we want
>> to make things clear, we should add a comment to Liujian's explaining
>> why the extra test after time_after(jiffies, timeo) is needed.
> 
> I see so I am okay with the change of Liujian-san v3 patch.
> Also agree with the comment to be added.
> 

Right, I like the current patch from Liujian, because its more
consistent with the existing code in this file.

Liujian, Could you re-post with a comment added as suggested above?

Regards
Vignesh

WARNING: multiple messages have this Message-ID (diff)
From: Vignesh Raghavendra <vigneshr@ti.com>
To: Tokunori Ikegami <ikegami_to@yahoo.co.jp>,
	"'liujian (CE)'" <liujian56@huawei.com>
Cc: 'Tokunori Ikegami' <ikegami.t@gmail.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"bbrezillon@kernel.org" <bbrezillon@kernel.org>,
	"ikegami@allied-telesis.co.jp" <ikegami@allied-telesis.co.jp>,
	"richard@nod.at" <richard@nod.at>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"marek.vasut@gmail.com" <marek.vasut@gmail.com>,
	'Boris Brezillon' <boris.brezillon@collabora.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>
Subject: Re: [PATCH v3] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
Date: Sat, 2 Mar 2019 14:27:54 +0530	[thread overview]
Message-ID: <de75d4f6-dfff-26e0-e191-6240ffc20223@ti.com> (raw)
In-Reply-To: <001c01d4d057$f68572e0$e39058a0$@yahoo.co.jp>



On 01-Mar-19 11:25 PM, Tokunori Ikegami wrote:
>>>> [...]
>>>>>>>>> In function do_write_buffer(), in the for loop, there is a
>>>>>>>>> case chip_ready() returns 1 while chip_good() returns 0, so
>>>>>>>>> it never break the loop.
>>>>>>>>> To fix this, chip_good() is enough and it should timeout if
>>>>>>>>> it stay bad for a while.
>>>>>>>>>
>>>>>>>>> Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write
>>>>>>>>> buffer to check correct value")
>>>>>>>>> Signed-off-by: Yi Huaijie <yihuaijie@huawei.com>
>>>>>>>>> Signed-off-by: Liu Jian <liujian56@huawei.com>
>>>>>>>>> Reviewed-by: Tokunori Ikegami <ikegami_to@yahoo.co.jp>
>>>>>>>>> ---
>>>>>>>>> v2->v3:
>>>>>>>>> Follow Vignesh's advice:
>>>>>>>>> add one more check for check_good() even when time_after()
>>>>>>>>> returns
>>>>>> true.
>>>>>>>>>
>>>>>>>>>  drivers/mtd/chips/cfi_cmdset_0002.c | 2 +-
>>>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
>>>>>>>>> b/drivers/mtd/chips/cfi_cmdset_0002.c
>>>>>>>>> index 72428b6..3da2376 100644
>>>>>>>>> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
>>>>>>>>> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
>>>>>>>>> @@ -1876,7 +1876,7 @@ static int __xipram
>>>>>>>>> do_write_buffer(struct map_info *map, struct flchip *chip,
>>>>>>>>>  			continue;
>>>>>>>>>  		}
>>>>>>>>>
>>>>>>>>> -		if (time_after(jiffies, timeo)
>>>>>>>>> && !chip_ready(map, adr))
>>>>>>>>> +		if (time_after(jiffies, timeo)
>>>>>>>>> && !chip_good(map, adr, datum))
>>>>>>>>
>>>>>>>>   Just another idea to understand easily.
>>>>>>>>
>>>>>>>>     unsigned long now = jiffies;
>>>>>>>>
>>>>>>>>     if (chip_good(map, adr, datum)) {
>>>>>>>>         xip_enable(map, chip, adr);
>>>>>>>>         goto op_done;
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     if (time_after(now, timeo) {
>>>>>>>>         break;
>>>>>>>>     }
>>>>>>>>
>>>>>>>
>>>>>>> Thank you~. It is more easier to understand!
>>>>>>> If there are no other comments, I will send new patch again ):
>>>>>>
>>>>>> Except this version no longer does what Vignesh suggested. See
>>>>>> how you no longer test if chip_good() is true if time_after()
>>>>>> returns true. So, imagine the thread entering this function is
>>>>>> preempted just after the first chip_good() test, and resumed a
>>>>>> few ms later. time_after() will return true, but chip_good()
>>>>>> might also return true, and you ignore it.
>>>>>
>>>>> I think that the following 3 versions will be worked for
>>>>> time_after()
>>>> as a same result and follow the Vignesh-san suggestion.
>>>>>
>>>>
>>>> As Boris explained above version 3 does not really follow my
>>>> suggestion... Please see below
>>>>
>>>>> 1. Original Vignesh-san suggestion
>>>>>
>>>>> 	if (chip_good(map, adr, datum)) {
>>>>> 		xip_enable(map, chip, adr);
>>>>> 		goto op_done;
>>>>> 	}
>>>>>
>>>>> 	if (time_after(jiffies, timeo)) {
>>>>> 		/* Test chip_good() if TRUE incorrectly again so
>>>>> write
>>>> failure by time_after() can be avoided. */
>>>>> 		if (chip_good(map, adr, datum)) {
>>>>> 			xip_enable(map, chip, adr);
>>>>> 			goto op_done;
>>>>> 		}
>>>>> 		break;
>>>>> 	}
>>>>>
>>>>
>>>>
>>>> Right, here we check chip_good() once _even when time_after() is
>>>> true_ to avoid _spurious_ timeout
>>>>
>>>>> 2. Liujian-san v3 patch
>>>>>
>>>>> 	/* Test chip_good() if FALSE correctly so write failure
>>>>> by
>>>> time_after() can be avoided. */
>>>>> 	if (time_after(jiffies, timeo) && !chip_good(map, adr))
>>>>> 		break;
>>>>>
>>>>> 	if (chip_good(map, adr, datum)) {
>>>>> 		xip_enable(map, chip, adr);
>>>>> 		goto op_done;
>>>>> 	}
>>>>>
>>>>
>>>> This is a better version of 1
>>>>
>>>>> 3. My idea
>>>>>
>>>>> 	/* Save current jiffies value before chip_good() to avoid
>>>>> write
>>>> failure by time_after() without testing chip_good() again. */
>>>>> 	unsigned long now = jiffies;
>>>>>
>>>>> 	if (chip_good(map, adr, datum)) {
>>>>> 		xip_enable(map, chip, adr);
>>>>> 		goto op_done;
>>>>> 	}
>>>>>
>>>>
>>>> What if thread gets pre-empted at this point and is re-scheduled
>>>> exactly after timeo jiffies have elapsed? Below check would be true
>>>> and exit loop
>>>
>>>   I think that the jiffies value now is save before chip_good() so
>>> below check would be false and not exit loop.
>>

Ok, I get it now.

>> True, I overlooked that part, and so Vignesh did. This proves one
>> thing: code is not easier to follow with your version. IMO, if we want
>> to make things clear, we should add a comment to Liujian's explaining
>> why the extra test after time_after(jiffies, timeo) is needed.
> 
> I see so I am okay with the change of Liujian-san v3 patch.
> Also agree with the comment to be added.
> 

Right, I like the current patch from Liujian, because its more
consistent with the existing code in this file.

Liujian, Could you re-post with a comment added as suggested above?

Regards
Vignesh

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2019-03-02  8:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26 14:00 [PATCH v3] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer Liu Jian
2019-02-26 14:00 ` Liu Jian
2019-02-28 14:25 ` Tokunori Ikegami
2019-02-28 14:25   ` Tokunori Ikegami
2019-02-28 15:12   ` liujian (CE)
2019-02-28 15:12     ` liujian (CE)
2019-02-28 15:42     ` Boris Brezillon
2019-02-28 15:42       ` Boris Brezillon
2019-03-01 14:51       ` Tokunori Ikegami
2019-03-01 16:07         ` Boris Brezillon
2019-03-01 16:07           ` Boris Brezillon
2019-03-01 16:54           ` Tokunori Ikegami
2019-03-01 16:54             ` Tokunori Ikegami
2019-03-01 16:47         ` Vignesh Raghavendra
2019-03-01 16:47           ` Vignesh Raghavendra
2019-03-01 16:59           ` Tokunori Ikegami
2019-03-01 16:59             ` Tokunori Ikegami
2019-03-01 17:43             ` Boris Brezillon
2019-03-01 17:43               ` Boris Brezillon
2019-03-01 17:55               ` Tokunori Ikegami
2019-03-02  8:57                 ` Vignesh Raghavendra [this message]
2019-03-02  8:57                   ` Vignesh Raghavendra
2019-03-01 19:56 ` Boris Brezillon
2019-03-01 19:56   ` Boris Brezillon

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=de75d4f6-dfff-26e0-e191-6240ffc20223@ti.com \
    --to=vigneshr@ti.com \
    --cc=bbrezillon@kernel.org \
    --cc=boris.brezillon@collabora.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ikegami.t@gmail.com \
    --cc=ikegami@allied-telesis.co.jp \
    --cc=ikegami_to@yahoo.co.jp \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=liujian56@huawei.com \
    --cc=marek.vasut@gmail.com \
    --cc=richard@nod.at \
    /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.