From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Petr Cvek <petr.cvek@tul.cz>
Cc: ulf.hansson@linaro.org, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/4] mmc: pxamci: Fix race condition between pxamci_dma_irq() and pxamci_irq()
Date: Thu, 27 Apr 2017 15:14:28 +0200 [thread overview]
Message-ID: <87inlq0z7v.fsf@belgarion.home> (raw)
In-Reply-To: <43c3a3b4-75b5-613e-4e28-9c38271ccb63@tul.cz> (Petr Cvek's message of "Fri, 21 Apr 2017 03:30:10 +0200")
Petr Cvek <petr.cvek@tul.cz> writes:
> Dne 19.4.2017 v 21:22 Robert Jarzmik napsal(a):
>> Petr Cvek <petr.cvek@tul.cz> writes:
Hi Petr,
As promised, I though it a bit more, and I have a counter proposal, which looks
simpler (if it works for you).
Why not remove completely the call to pxamci_data_done() from pxamci_dma_irq() ?
The pxamci_dma_irq() will only remain for the partial full write, and for the
dev_err() part, but won't act on command completion, that part being full dealt
with by pxamci_data_done().
I still seeing a small race window, in that :
- DATA_TRAN_DONE is asserted for a MMC read transaction, because the MMC FIFO
was just emptied by the DMA IP
- imagine the memory is not yet written to by the DMA IP (ie. this is the race
window, the DATA being help in DMA IP internal FIFO)
- the pxamci_data_done() is called, and it calls dma_unmap_sg(), flushing the
cache
- the consumer reads this last data bit, which is still the old data, and then
the DMA finishes ...
I know the probability is almost 0 for this scenario to happen given the
timings, it's just to add fuel to the technical exchange.
> The patches 1, 1+2, 1+2+3 should boot, but the MMC will of course fail as only
> the 4 repairs it. Do you want me to send them independently? (or I can sort
> them that the race condition repair is the first one)
No no, I like it the way it is, and as far as Ulf is happy as his tree will
carry them, I'm happy too.
Cheers.
--
Robert
prev parent reply other threads:[~2017-04-27 13:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1492492523.git.petr.cvek@tul.cz>
2017-04-18 23:16 ` [PATCH 1/4] mmc: pxamci: Use the right flags for DMA callback init Petr Cvek
2017-04-21 0:31 ` Petr Cvek
2017-04-18 23:17 ` [PATCH 2/4] mmc: pxamci: Enhance error checking Petr Cvek
2017-04-19 19:12 ` Robert Jarzmik
2017-04-18 23:17 ` [PATCH 3/4] mmc: pxamci: Disable DATA_TRAN_DONE interrupt sooner Petr Cvek
2017-04-19 19:14 ` Robert Jarzmik
2017-04-20 23:37 ` Petr Cvek
2017-04-18 23:18 ` [PATCH 4/4] mmc: pxamci: Fix race condition between pxamci_dma_irq() and pxamci_irq() Petr Cvek
2017-04-19 19:22 ` Robert Jarzmik
2017-04-21 1:30 ` Petr Cvek
2017-04-27 13:14 ` Robert Jarzmik [this message]
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=87inlq0z7v.fsf@belgarion.home \
--to=robert.jarzmik@free.fr \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=petr.cvek@tul.cz \
--cc=ulf.hansson@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox