linux-kernel - Re: [PATCH v2] mmc: Add quirk MMC_QUIRK_BROKEN_CACHE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c66810ae52446db41fd187ee4be24d04d40c1abb.camel@iokpp.de>
Date:   Sun, 17 Sep 2023 22:11:24 +0200
From:   Bean Huo <beanhuo@...pp.de>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     adrian.hunter@...el.com, beanhuo@...ron.com,
        jakub.kwapisz@...adex.com, rafael.beims@...adex.com,
        linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH v2] mmc: Add quirk MMC_QUIRK_BROKEN_CACHE_FLUSH for
 Micron eMMC Q2J54A


Hi Ulf,

Thanks for your comment, much appreciated!


On Fri, 2023-09-15 at 00:09 +0200, Ulf Hansson wrote:
> On Thu, 14 Sept 2023 at 22:28, Bean Huo <beanhuo@...pp.de> wrote:
> > 
> > From: Bean Huo <beanhuo@...ron.com>
> > 
> > Micron MTFC4GACAJCN eMMC supports cache but requires that flush
> > cache
> > operation be allowed only after a write has occurred. Otherwise,
> > the
> > cache flush command or subsequent commands will time out.
> 
> For my information, more exactly, how can we trigger this problem?
> 

This issue may be likely reproduced in this command sequence:

eMMC power-cycle/reset-->...(other operations, but no data write)...-
>cache flush-->...... ->write data, must say, it is not 100%
reproducable.

> > 
> > Signed-off-by: Bean Huo <beanhuo@...ron.com>
> > Co-developed-by: Rafael Beims <rafael.beims@...adex.com>
> > Tested-by: Rafael Beims <rafael.beims@...adex.com>
> > Cc: stable@...r.kernel.org
> > ---
> > Changelog:
> > 
> > v1--v2:
> >     1. Add Rafael's test-tag, and Co-developed-by.
> >     2. Check host->card whether NULL or not in
> > __mmc_start_request() before asserting host->card->->quirks
> > 
> > ---
> >  drivers/mmc/core/core.c   | 7 +++++++
> >  drivers/mmc/core/mmc.c    | 5 +++++
> >  drivers/mmc/core/quirks.h | 7 ++++---
> >  include/linux/mmc/card.h  | 2 ++
> >  4 files changed, 18 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> > index 3d3e0ca52614..86a669b35b91 100644
> > --- a/drivers/mmc/core/core.c
> > +++ b/drivers/mmc/core/core.c
> > @@ -259,6 +259,13 @@ static void __mmc_start_request(struct
> > mmc_host *host, struct mmc_request *mrq)
> >                 host->cqe_ops->cqe_off(host);
> > 
> >         host->ops->request(host, mrq);
> > +
> > +       if (host->card && host->card->quirks &
> > MMC_QUIRK_BROKEN_CACHE_FLUSH &&
> > +           !host->card->written_flag) {
> > +               if (mrq->cmd->opcode == MMC_WRITE_MULTIPLE_BLOCK ||
> > +                   mrq->cmd->opcode == MMC_WRITE_BLOCK)
> > +                       host->card->written_flag = true;
> > +       }
> 
> I don't quite like that we are adding the above code here - as it's
> used for *all* requests.
> 
> Seems like the flag is better set from the mmc block device driver
> instead. Somewhere in the path when we serve I/O write requests.
> 

yes, you are correct, I will update the patch and add this flag set in
mmc block driver mmc_blk_mq_issue_rq().

> >  }
> > 
> >  static void mmc_mrq_pr_debug(struct mmc_host *host, struct
> > mmc_request *mrq,
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> > index 89cd48fcec79..a2edd065fa1b 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -1929,6 +1929,8 @@ static int mmc_init_card(struct mmc_host
> > *host, u32 ocr,
> >         if (!oldcard)
> >                 host->card = card;
> > 
> > +       card->written_flag = false;
> > +
> 
> According to your earlier reply, it sounds like the problem isn't
> really about the card being re-initialized, but rather that we
> actually need a write request to happen before a flush. No matter
> what, no?
> 
> See more about this below.
> 

Actually, it matters that the first cache flush command after
reboot/reset. means that for the first cache flush command, before
execution, the write data operation should occur,
After that, there is no problem even if there are no writes before the
cache is flushed.


> >         return 0;
> > 
> >  free_card:
> > @@ -2081,6 +2083,9 @@ static int _mmc_flush_cache(struct mmc_host
> > *host)
> >  {
> >         int err = 0;
> > 
> > +       if (host->card->quirks & MMC_QUIRK_BROKEN_CACHE_FLUSH &&
> > !host->card->written_flag)
> > +               return err;
> > +
> 
> Could an option to the above, be to reset the flag here instead.
> After
> a successful cache flush has been done.
> 
> 

As I explained above, the first cache flush after a power cycle/reset
is important. We just want to eliminate the first unnecessary cache
flush.
We can eliminate all unnecessary cache flushes when the cache is empty.
But I don't want to change the current logic too much, only want to
focus on the first unnecessary cache flush, how do you think?

Kind regards,
Bean