From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Tokunori Ikegami" <ikegami.t@gmail.com>
Cc: 'Vignesh Raghavendra' <vigneshr@ti.com>,
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,
"'liujian \(CE\)'" <liujian56@huawei.com>,
keescook@chromium.org
Subject: Re: [PATCH v3] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
Date: Fri, 1 Mar 2019 18:43:17 +0100 [thread overview]
Message-ID: <20190301184317.6bad546f@collabora.com> (raw)
In-Reply-To: <000501d4d050$38eca160$aac5e420$@gmail.com>
On Sat, 2 Mar 2019 01:59:41 +0900
"Tokunori Ikegami" <ikegami.t@gmail.com> 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.
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.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Tokunori Ikegami" <ikegami.t@gmail.com>
Cc: "'Vignesh Raghavendra'" <vigneshr@ti.com>,
"'liujian \(CE\)'" <liujian56@huawei.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: Fri, 1 Mar 2019 18:43:17 +0100 [thread overview]
Message-ID: <20190301184317.6bad546f@collabora.com> (raw)
In-Reply-To: <000501d4d050$38eca160$aac5e420$@gmail.com>
On Sat, 2 Mar 2019 01:59:41 +0900
"Tokunori Ikegami" <ikegami.t@gmail.com> 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.
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.
next prev parent reply other threads:[~2019-03-01 17:43 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 [this message]
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=20190301184317.6bad546f@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=bbrezillon@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ikegami.t@gmail.com \
--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.