linux-kernel - Re: [PATCH] mmc: block: enable cache-flushing when mmc cache is on

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: <a39e9f71-7a9c-bf0e-50d0-d45de3c2e132@allwinnertech.com>
Date:   Fri, 25 Mar 2022 13:45:52 +0800
From:   Michael Wu <michael@...winnertech.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Adrian Hunter <adrian.hunter@...el.com>,
        Christian Löhle <CLoehle@...erstone.com>,
        Avri Altman <avri.altman@....com>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "porzio@...il.com" <porzio@...il.com>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        allwinner-opensource-support 
        <allwinner-opensource-support@...winnertech.com>
Subject: Re: [PATCH] mmc: block: enable cache-flushing when mmc cache is on

On 24/03/2022 19:27, Ulf Hansson wrote:
> On Thu, 17 Mar 2022 at 10:14, Ulf Hansson <ulf.hansson@...aro.org> wrote:
>>
>> On Wed, 16 Mar 2022 at 17:08, Adrian Hunter <adrian.hunter@...el.com> wrote:
>>>
>>> On 16.3.2022 16.46, Christian Löhle wrote:
>>>>> So we are not going to let the block layer know about SD cache?
>>>>> Or is it a separate change?
>>>>
>>>> I have some code for this laying around, but as it requires reading, parsing and writing Function Registers,
>>>> in particular PEH, it's a lot of boilerplate code to get the functionality, but I'll clean it up and send a patch in the coming weeks.
>>>>
>>>
>>> We have the sd cache flush.  We would presumably just need to call blk_queue_write_cache()
>>> for the !mmc_card_mmc(card) case e.g.
>>>
>>>          if (mmc_has_reliable_write(card)) {
>>>                  md->flags |= MMC_BLK_REL_WR;
>>>                  enable_fua = true;
>>>          }
>>>
>>>          if (mmc_cache_enabled(card->host))
>>>                  enable_cache = true;
>>>
>>>          blk_queue_write_cache(md->queue.queue, enable_cache, enable_fua);
>>
>> To me, this seems like the most reasonable thing to do.
>>
>> However, I have to admit that it's not clear to me, if there was a
>> good reason to why commit f4c5522b0a88 ("mmc: Reliable write
>> support.") also added support for REQ_FLUSH (write back cache) and why
>> not only REQ_FUA. I assumed this was wrong too, right?
>>

Hi Ulf,

1. I've found the reason. If we only enable REQ_FUA, there won't be any 
effect -- The block layer won't send any request with FUA flag to the 
driver.
If we want REQ_FUA to take effect, we must enable REQ_FLUSH. But on the 
contrary, REQ_FLUSH does not rely on REQ_FUA.
In the previous patch(commit f4c5522b0a88 ("mmc: Reliable write 
support.")), REQ_FLUSH was added to make REQ_FUA effective. I've done 
experiments to prove this.

2. Why block layer requires REQ_FLUSH to make REQ_FUA effective? I did 
not find the reason. Does anyone know about this? Thank you.

>> When it comes to patches for stable kernels. mmc_cache_enabled() was
>> introduced quite recently in v5.13, so for older kernels that call
>> needs to be replaced with something else.
>>
>> In any case, the relevant commits that can be considered as needs to
>> be fixed seems like these:
>> commit f4c5522b0a88 ("mmc: Reliable write support.")
>> commit 881d1c25f765 ("mmc: core: Add cache control for eMMC4.5 device")
>> commit 130206a615a9 ("mmc: core: Add support for cache ctrl for SD cards")
>>
>> [...]
> 
> Michael, are you planning to send a v2 for this? Or are there any
> parts that are still unclear to you?

Dear Ulf, Sorry for the delay. I was trying to figure out the SD cache 
stuff, so a few day was taken...

> 
> Kind regards
> Uffe

-- 
Best Regards,
Michael Wu