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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Zlndc8NI0eK3MmuR@memverge.com>
Date: Fri, 31 May 2024 10:23:47 -0400
From: Gregory Price <gregory.price@...verge.com>
To: Dongsheng Yang <dongsheng.yang@...ystack.cn>
Cc: Dan Williams <dan.j.williams@...el.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	John Groves <John@...ves.net>, axboe@...nel.dk,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-cxl@...r.kernel.org, nvdimm@...ts.linux.dev
Subject: Re: [PATCH RFC 0/7] block: Introduce CBD (CXL Block Device)

On Thu, May 30, 2024 at 02:59:38PM +0800, Dongsheng Yang wrote:
> 
> 
> 在 2024/5/29 星期三 下午 11:25, Gregory Price 写道:
> > 
> > There are some (FAMFS, for example). The coherence state of these
> > systems tend to be less volatile (e.g. mappings are read-only), or
> > they have inherent design limitations (cacheline-sized message passing
> > via write-ahead logging only).
> 
> Can you explain more about this? I understand that if the reader in the
> writer-reader model is using a readonly mapping, the interaction will be
> much simpler. However, after the writer writes data, if we don't have a
> mechanism to flush and invalidate puncturing all caches, how can the
> readonly reader access the new data?

This is exactly right, so the coherence/correctness of the data needs to
be enforced in some other way.

Generally speaking, the WPQs will *eventually* get flushed.  As such,
the memory will *eventually* become coherent.  So if you set up the
following pattern, you will end up with an "eventually coherent" system

1) Writer instantiates the memory to be used
2) Writer calculates and records a checksum of that data into memory
3) Writer invalidates everything
4) Reader maps the memory
5) Reader reads the checksum and calculates the checksum of the data
   a) if the checksums match, the data is coherent
   b) if they don't, we must wait longer for the queues to flush

This is just one example of a system design which enforces coherence by
placing the limitation on the system that the data will never change
once it becomes coherent.

Whatever the case, regardless of the scheme you come up with, you will
end up with a system where the data must be inspected and validated
before it can be used.  This has the limiting factor of performance:
throughput will be limited by how fast you can validate the data.

~Gregory