Linux MultiMedia Card development
 help / color / mirror / Atom feed
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

      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