From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Tokunori Ikegami" <ikegami_to@yahoo.co.jp>
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, "'liujian \(CE\)'" <liujian56@huawei.com>,
vigneshr@ti.com
Subject: Re: [PATCH v3] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
Date: Fri, 1 Mar 2019 17:07:15 +0100 [thread overview]
Message-ID: <20190301170715.68d89e84@collabora.com> (raw)
In-Reply-To: <005a01d4d03e$39b0e0f0$ad12a2d0$@yahoo.co.jp>
Hi Ikegami,
On Fri, 1 Mar 2019 23:51:16 +0900
"Tokunori Ikegami" <ikegami_to@yahoo.co.jp> wrote:
> > 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.
Let me show you how they are different:
>
> 1. Original Vignesh-san suggestion
>
> if (chip_good(map, adr, datum)) {
> xip_enable(map, chip, adr);
> goto op_done;
> }
--> thread preempted here
==> chip_good() test becomes valid here
--> thread resumed here, but timeout has expired
>
> if (time_after(jiffies, timeo)) {
you enter this branch
> /* Test chip_good() if TRUE incorrectly again so write failure by time_after() can be avoided. */
> if (chip_good(map, adr, datum)) {
chip_good() returns true
> xip_enable(map, chip, adr);
> goto op_done;
> }
> break;
> }
>
> 2. Liujian-san v3 patch
>
> /* Test chip_good() if FALSE correctly so write failure by time_after() can be avoided. */
--> thread preempted here
==> chip_good() test becomes valid here
--> thread resumed here, but timeout has expired
> if (time_after(jiffies, timeo) && !chip_good(map, adr))
You do not enter this branch because the chip_good() test is done once
more in case of timeout.
> break;
>
> if (chip_good(map, adr, datum)) {
> xip_enable(map, chip, adr);
> goto op_done;
> }
>
> 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;
> }
>
--> thread preempted here
==> chip_good() test becomes valid here
--> thread resumed here, but timeout has expired
> if (time_after(now, timeo))
You do enter this branch, and erroneously report a failure.
> break;
>
See now why your version is not correct?
Regards,
Boris
______________________________________________________
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_to@yahoo.co.jp>
Cc: "'liujian \(CE\)'" <liujian56@huawei.com>,
"'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>, <vigneshr@ti.com>
Subject: Re: [PATCH v3] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
Date: Fri, 1 Mar 2019 17:07:15 +0100 [thread overview]
Message-ID: <20190301170715.68d89e84@collabora.com> (raw)
In-Reply-To: <005a01d4d03e$39b0e0f0$ad12a2d0$@yahoo.co.jp>
Hi Ikegami,
On Fri, 1 Mar 2019 23:51:16 +0900
"Tokunori Ikegami" <ikegami_to@yahoo.co.jp> wrote:
> > 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.
Let me show you how they are different:
>
> 1. Original Vignesh-san suggestion
>
> if (chip_good(map, adr, datum)) {
> xip_enable(map, chip, adr);
> goto op_done;
> }
--> thread preempted here
==> chip_good() test becomes valid here
--> thread resumed here, but timeout has expired
>
> if (time_after(jiffies, timeo)) {
you enter this branch
> /* Test chip_good() if TRUE incorrectly again so write failure by time_after() can be avoided. */
> if (chip_good(map, adr, datum)) {
chip_good() returns true
> xip_enable(map, chip, adr);
> goto op_done;
> }
> break;
> }
>
> 2. Liujian-san v3 patch
>
> /* Test chip_good() if FALSE correctly so write failure by time_after() can be avoided. */
--> thread preempted here
==> chip_good() test becomes valid here
--> thread resumed here, but timeout has expired
> if (time_after(jiffies, timeo) && !chip_good(map, adr))
You do not enter this branch because the chip_good() test is done once
more in case of timeout.
> break;
>
> if (chip_good(map, adr, datum)) {
> xip_enable(map, chip, adr);
> goto op_done;
> }
>
> 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;
> }
>
--> thread preempted here
==> chip_good() test becomes valid here
--> thread resumed here, but timeout has expired
> if (time_after(now, timeo))
You do enter this branch, and erroneously report a failure.
> break;
>
See now why your version is not correct?
Regards,
Boris
next prev parent reply other threads:[~2019-03-01 16:07 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 [this message]
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
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=20190301170715.68d89e84@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=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 \
--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.