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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFoejcQz2jPgqzc+2W+mfaXOatGCdd8CdNYsk4FsUEb=7Q@mail.gmail.com>
Date:   Fri, 23 Apr 2021 10:14:15 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Avri Altman <avri.altman@....com>
Cc:     linux-mmc <linux-mmc@...r.kernel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Brendan Peter <bpeter@...x.com>
Subject: Re: [PATCH v4 1/2] mmc: block: Issue flush only if allowed

On Tue, 20 Apr 2021 at 15:46, Avri Altman <avri.altman@....com> wrote:
>
> The cache may be flushed to the nonvolatile storage by writing to
> FLUSH_CACHE byte (EXT_CSD byte [32]). When in command queueing mode, the
> cache may be flushed by issuing a CMDQ_TASK_ DEV_MGMT (CMD48) with a
> FLUSH_CACHE op-code.  Either way, verify that The cache function is
> turned ON before doing so.
>
> fixes: 1e8e55b67030 (mmc: block: Add CQE support)
>
> Reported-by: Brendan Peter <bpeter@...x.com>
> Tested-by: Brendan Peter <bpeter@...x.com>
> Signed-off-by: Avri Altman <avri.altman@....com>
> ---
>  drivers/mmc/core/block.c   | 9 +++++++++
>  drivers/mmc/core/mmc.c     | 2 +-
>  drivers/mmc/core/mmc_ops.h | 5 +++++
>  3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index 8bfd4d95b386..24e1ecbdd510 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -2186,6 +2186,11 @@ static int mmc_blk_wait_for_idle(struct mmc_queue *mq, struct mmc_host *host)
>         return mmc_blk_rw_wait(mq, NULL);
>  }
>
> +static bool mmc_blk_cache_disabled(struct mmc_card *card)
> +{
> +       return mmc_card_mmc(card) && !mmc_flush_allowed(card);

It's these kinds of use with mmc_card_mmc() that I think we need to
strive towards avoiding when going forward.

For example, newer SD cards support both cache and command queueing
nowadays, which means that we need to make the code in the mmc block
layer more agnostic. To do that, I think we should use the bus_ops
callbacks. That's why I started out by adding the ->flush_cache()
callback in the other patch.

> +}
> +
>  enum mmc_issued mmc_blk_mq_issue_rq(struct mmc_queue *mq, struct request *req)
>  {
>         struct mmc_blk_data *md = mq->blkdata;
> @@ -2225,6 +2230,10 @@ enum mmc_issued mmc_blk_mq_issue_rq(struct mmc_queue *mq, struct request *req)
>         case MMC_ISSUE_ASYNC:
>                 switch (req_op(req)) {
>                 case REQ_OP_FLUSH:
> +                       if (mmc_blk_cache_disabled(mq->card)) {

I suggest that you add a new bus ops callback ->cache_enabled() and
implement it for the mmc bus type.

>From the mmc block layer point of view, it would then mean that if the
callback isn't implemented, the cache ctrl isn't supported (which
would be the case for SD then)

> +                               blk_mq_end_request(req, BLK_STS_OK);
> +                               return MMC_REQ_FINISHED;
> +                       }
>                         ret = mmc_blk_cqe_issue_flush(mq, req);

>                         break;
>                 case REQ_OP_READ:
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 9ad4aa537867..e3da62ffcb5e 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -2037,7 +2037,7 @@ static int _mmc_flush_cache(struct mmc_card *card)
>  {
>         int err = 0;
>
> -       if (card->ext_csd.cache_size > 0 && card->ext_csd.cache_ctrl & 1) {
> +       if (mmc_flush_allowed(card)) {
>                 err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>                                  EXT_CSD_FLUSH_CACHE, 1,
>                                  CACHE_FLUSH_TIMEOUT_MS);
> diff --git a/drivers/mmc/core/mmc_ops.h b/drivers/mmc/core/mmc_ops.h
> index 5782fdf4e8e9..2682bf66708a 100644
> --- a/drivers/mmc/core/mmc_ops.h
> +++ b/drivers/mmc/core/mmc_ops.h
> @@ -19,6 +19,11 @@ enum mmc_busy_cmd {
>  struct mmc_host;
>  struct mmc_card;
>
> +static inline bool mmc_flush_allowed(struct mmc_card *card)
> +{
> +       return card->ext_csd.cache_size > 0 && card->ext_csd.cache_ctrl & 1;
> +}
> +
>  int mmc_select_card(struct mmc_card *card);
>  int mmc_deselect_cards(struct mmc_host *host);
>  int mmc_set_dsr(struct mmc_host *host);
> --
> 2.25.1
>

Having said the above, we clearly want to tag $subject patch for
stable kernels as well, which means we need a simple patch as
possible.

Clearly $subject patch should have come first, prior to my patch where
I added the ->flush_cache() bus ops callback, as it messes things up.

Therefore, I decided to rebase my next branch to drop the patch adding
the ->flush_cache() bus ops (I will re-post the patch after we have
got your changes in).

Can you please re-base $subject patch and address my comments? My
apologies for the mess!

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ