linux-kernel - Re: [ANNOUNCE] DAXFS: A zero-copy, dmabuf-friendly filesystem for shared memory

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: <CAGHCLaSe8g+BQ5OtRv0_Ft3o-G0gR4oVSOW0DtdsQJdwuJsDCA@mail.gmail.com>
Date: Mon, 26 Jan 2026 11:48:20 -0800
From: Cong Wang <cwang@...tikernel.io>
To: Matthew Wilcox <willy@...radead.org>
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:16 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Mon, Jan 26, 2026 at 09:38:23AM -0800, Cong Wang wrote:
> > If you are interested in adding multikernel support to EROFS, here is
> > the codebase you could start with:
> > https://github.com/multikernel/linux. PR is always welcome.
>
> I think the onus is rather the other way around.  Adding a new filesystem
> to Linux has a high bar to clear because it becomes a maintenance burden
> to the rest of us.  Convince us that what you're doing here *can't*
> be done better by modifying erofs.
>
> Before I saw the email from Gao Xiang, I was also going to suggest that
> using erofs would be a better idea than supporting your own filesystem.
> Writing a new filesystem is a lot of fun.  Supporting a new filesystem
> and making it production-quality is a whole lot of pain.  It's much
> better if you can leverage other people's work.  That's why DAX is a
> support layer for filesystems rather than its own filesystem.

Great question.

The core reason is multikernel assumes little to none compatibility.

Specifically for this scenario, struct inode is not compatible. This
could rule out a lot of existing filesystems, except read-only ones.

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.

Regards,
Cong