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: <aXfRUlu61nrIqCZS@casper.infradead.org>
Date: Mon, 26 Jan 2026 20:40:50 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Cong Wang <cwang@...tikernel.io>
Cc: Gao Xiang <hsiangkao@...ux.alibaba.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, Cong Wang <xiyou.wangcong@...il.com>,
	multikernel@...ts.linux.dev
Subject: Re: [ANNOUNCE] DAXFS: A zero-copy, dmabuf-friendly filesystem for
 shared memory

On Mon, Jan 26, 2026 at 11:48:20AM -0800, Cong Wang wrote:
> Specifically for this scenario, struct inode is not compatible. This
> could rule out a lot of existing filesystems, except read-only ones.

I don't think you understand that there's a difference between *on disk*
inode and *in core* inode.  Compare and contrast struct ext2_inode and
struct inode.

> Now back to EROFS, it is still based on a block device, which
> itself can't be shared among different kernels. ramdax is actually
> a perfect example here, its label_area can't be shared among
> different kernels.
> 
> Let's take one step back: even if we really could share a device
> with multiple kernels, it still could not share the memory footprint,
> with DAX + EROFS, we would still get:
> 1) Each kernel creates its own DAX mappings
> 2) And faults pages independently
> 
> There is no cross-kernel page sharing accounting.
> 
> I hope this makes sense.

No, it doesn't.  I'm not suggesting that you use erofs unchanged, I'm
suggesting that you modify erofs to support your needs.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ