All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tokunori Ikegami" <ikegami.t@gmail.com>
To: "'Vignesh Raghavendra'" <vigneshr@ti.com>,
	"'Boris Brezillon'" <boris.brezillon@collabora.com>,
	"'liujian \(CE\)'" <liujian56@huawei.com>
Cc: "'Tokunori Ikegami'" <ikegami.t@gmail.com>,
	<keescook@chromium.org>, <bbrezillon@kernel.org>,
	<ikegami@allied-telesis.co.jp>, <richard@nod.at>,
	<linux-kernel@vger.kernel.org>, <marek.vasut@gmail.com>,
	<linux-mtd@lists.infradead.org>, <computersforpeace@gmail.com>,
	<dwmw2@infradead.org>
Subject: RE: [PATCH v3] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
Date: Sat, 2 Mar 2019 01:59:41 +0900	[thread overview]
Message-ID: <000501d4d050$38eca160$aac5e420$@gmail.com> (raw)
In-Reply-To: <4b3bc01a-3632-5dde-f683-94744ee7179d@ti.com>

> [...]
> >>>>> 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.

Regards,
Ikegami

> 
> > 	if (time_after(now, timeo))
> > 		break;
> >
> 
> So, code does not check for check chip_good() after timeoout has
> elapsed. But chip_good() might be true at this point. Therefore leading
> to spurious timeout.  So this version is still not right.
> 
> >           Note: Some brackets have been fixed from the previous mail.
> >
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


WARNING: multiple messages have this Message-ID (diff)
From: "Tokunori Ikegami" <ikegami.t@gmail.com>
To: "'Vignesh Raghavendra'" <vigneshr@ti.com>,
	"'Boris Brezillon'" <boris.brezillon@collabora.com>,
	"'liujian \(CE\)'" <liujian56@huawei.com>
Cc: 'Tokunori Ikegami' <ikegami.t@gmail.com>,
	keescook@chromium.org, bbrezillon@kernel.org,
	ikegami@allied-telesis.co.jp, richard@nod.at,
	linux-kernel@vger.kernel.org, marek.vasut@gmail.com,
	linux-mtd@lists.infradead.org, computersforpeace@gmail.com,
	dwmw2@infradead.org
Subject: RE: [PATCH v3] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
Date: Sat, 2 Mar 2019 01:59:41 +0900	[thread overview]
Message-ID: <000501d4d050$38eca160$aac5e420$@gmail.com> (raw)
In-Reply-To: <4b3bc01a-3632-5dde-f683-94744ee7179d@ti.com>

> [...]
> >>>>> 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.

Regards,
Ikegami

> 
> > 	if (time_after(now, timeo))
> > 		break;
> >
> 
> So, code does not check for check chip_good() after timeoout has
> elapsed. But chip_good() might be true at this point. Therefore leading
> to spurious timeout.  So this version is still not right.
> 
> >           Note: Some brackets have been fixed from the previous mail.
> >
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


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

  reply	other threads:[~2019-03-01 17:00 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 [this message]
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
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='000501d4d050$38eca160$aac5e420$@gmail.com' \
    --to=ikegami.t@gmail.com \
    --cc=bbrezillon@kernel.org \
    --cc=boris.brezillon@collabora.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ikegami@allied-telesis.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 \
    --cc=vigneshr@ti.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.