linux-kernel - Re: [PATCH] Add error handling to minix filesystem similar to ext4

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: <1979215152.3123282.1761831106100@kpc.webmail.kpnmail.nl>
Date: Thu, 30 Oct 2025 14:31:46 +0100 (CET)
From: Jori Koolstra <jkoolstra@...all.nl>
To: Jeff Layton <jlayton@...nel.org>, Jan Kara <jack@...e.cz>
Cc: Christian Brauner <brauner@...nel.org>,
	"skhan@...uxfoundation.org" <skhan@...uxfoundation.org>,
	Khalid Aziz <khalid@...nel.org>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Taotao Chen <chentaotao@...iglobal.com>, NeilBrown <neil@...wn.name>,
	linux-kernel@...r.kernel.org,
	syzbot+4e49728ec1cbaf3b91d2@...kaller.appspotmail.com
Subject: Re: [PATCH] Add error handling to minix filesystem similar to ext4

> Not necessarily.
>
> I'm not sure if your internship covers this, but you could start a
> project to build a minixfs FUSE fs (if one doesn't already exist). If
> you get it working and stable, you can then submit patches to deprecate
> and remove it from the kernel.

I would have to ask Shuah but am open to it. But a quick search turns up
this: https://github.com/redcap97/fuse-mfs . I would have to see if it
actually works and it does not seem to support v1, v2 of minix fs either.
There might also be a licensing issue.

> For some background: this is a continuation of a discussion that we had
> at LSF/MM summit this year. A lot of these smaller, less-used
> filesystems represent a significant maintenance burden. Whenever we
> have to make changes at the VFS layer, they represent another fs that
> we have to touch.

> Many of these are not performance-critical and are hard to test. They
> would be _much_ easier to maintain in userland if we can make that
> work.

One question I would have about this is that if we move minix, for
instance, out of the kernel code, how can we be sure that it is
maintained. What if some Github repo suddenly disappears? Like I said,
I would be fine with helping maintain minix, otherwise what should be
the course of action from here? What demands do we place on a userland
replacement for minix before I submit a patch to deprecate and remove
the code?

Thanks,
Jori.

PS. Sorry for sending this twice. I am still having to remind myself to
"reply all". My apologies.