| 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
| ||
|
Message-ID: <55F8A71A.3030001@codeaurora.org> Date: Tue, 15 Sep 2015 16:17:46 -0700 From: Nikhilesh Reddy <reddyn@...eaurora.org> To: Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org Subject: Using Cache barriers in lieu of REQ_FLUSH | REQ_FUA for emmc 5.1 (jdec spec JESD84-B51) Hi The eMMC 5.1 spec defines cache "barrier" capability of the eMMC device as defined in JESD84-B51 I was wondering if there were any downsides to replacing the WRITE_FLUSH_FUA with the cache barrier? I understand that REQ_FLUSH is used to ensure that the current cache be flushed to prevent any reordering but I dont seem to be clear on why REQ_FUA is used. Can someone please help me understand this part? But as far as I understand it ... the cache barriers can be used to replace all the flush requests. Please let me know if there is any downside to this ? I know there there was a big decision in 2010 https://lwn.net/Articles/400541/ and http://lwn.net/Articles/399148/ to remove the software based barrier support... but with the hardware supporting "barriers" is there a downside to using them to replace the flushes? -- Thanks Nikhilesh Reddy Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists