linux-kernel - Re: [PATCH RFC 0/7] block: Introduce CBD (CXL Block Device)

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZivS86BrfPHopkru@memverge.com>
Date: Fri, 26 Apr 2024 12:14:43 -0400
From: Gregory Price <gregory.price@...verge.com>
To: Dongsheng Yang <dongsheng.yang@...ystack.cn>
Cc: Dan Williams <dan.j.williams@...el.com>, axboe@...nel.dk,
	John Groves <John@...ves.net>, linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-cxl@...r.kernel.org
Subject: Re: [PATCH RFC 0/7] block: Introduce CBD (CXL Block Device)

On Fri, Apr 26, 2024 at 10:53:43PM +0800, Dongsheng Yang wrote:
> 
> 
> 在 2024/4/26 星期五 下午 9:48, Gregory Price 写道:
> > 
> > Also, on a tangential note, you're using pmem/qemu to emulate the
> > behavior of shared CXL memory.  You should probably explain the
> > coherence implications of the system more explicitly.
> > 
> > The emulated system implements what amounts to hardware-coherent
> > memory (i.e. the two QEMU machines run on the same physical machine,
> > so coherency is managed within the same coherence domain).
> > 
> > If there is no explicit coherence control in software, then it is
> > important to state that this system relies on hardware that implements
> > snoop back-invalidate (which is not a requirement of a CXL 3.x device,
> > just a feature described by the spec that may be implemented).
> 
> In (5) of the cover letter, I mentioned that cbd addresses cache coherence
> at the software level:
> 
> (5) How do blkdev and backend interact through the channel?
> 	a) For reader side, before reading the data, if the data in this channel
> may be modified by the other party, then I need to flush the cache before
> reading to ensure that I get the latest data. For example, the blkdev needs
> to flush the cache before obtaining compr_head because compr_head will be
> updated by the backend handler.
> 	b) For writter side, if the written information will be read by others,
> then after writing, I need to flush the cache to let the other party see it
> immediately. For example, after blkdev submits cbd_se, it needs to update
> cmd_head to let the handler have a new cbd_se. Therefore, after updating
> cmd_head, I need to flush the cache to let the backend see it.
> 

Flushing the cache is insufficient.  All that cache flushing guarantees
is that the memory has left the writer's CPU cache.  There are potentially
many write buffers between the CPU and the actual backing media that the
CPU has no visibility of and cannot pierce through to force a full
guaranteed flush back to the media.

for example:

memcpy(some_cacheline, data, 64);
mfence();

Will not guarantee that after mfence() completes that the remote host
will have visibility of the data.  mfence() does not guarantee a full
flush back down to the device, it only guarantees it has been pushed out
of the CPU's cache.

similarly:

memcpy(some_cacheline, data, 64);
mfence();
memcpy(some_other_cacheline, data, 64);
mfence()

Will not guarantee that some_cacheline reaches the backing media prior
to some_other_cacheline, as there is no guarantee of write-ordering in
CXL controllers (with the exception of writes to the same cacheline).

So this statement:

> I need to flush the cache to let the other party see it immediately.

Is misleading.  They will not see is "immediately", they will see it
"eventually at some completely unknowable time in the future".

~Gregory