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: <1697efab0661c4c80831544f84c9e520f33962e7.camel@kernel.org>
Date: Thu, 30 Oct 2025 08:59:56 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Jori Koolstra <jkoolstra@...all.nl>, 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

On Thu, 2025-10-30 at 13:22 +0100, Jori Koolstra wrote:
> Hi Jan,
> 
> > 
> > The patch looks ok to me but since minix filesystem driver is in the kernel
> > mostly to allow mounting ancient unix filesystems I don't quite understand
> > the motivation for adding the new mount options. Why not just fixup
> > minix_rmdir() to better handle corrupted filesystems?
> > 
> > 								Honza
> 
> I am doing the Linux kernel mentorship program, and was looking to contribute
> to fs. Since I saw a lot bugs on syzbot related to minix (and jfs too) not
> handling corruptions well (yielding warnings in drop_nlink e.g.) I figured
> it was a low stakes project, not completely trivial, yet within my scope, to
> attempt to implement what ext4 does for these kind of problems (and jfs
> implements the same opts too).
> 
> I would have asked about the exact status of minix, but was told not to
> bother maintainers without a patch. I would be open with trying to improve
> minix further, but of course if there are better options to get it out of
> the kernel altogether that may be better. Sad for me, since that means still
> zero patches, but that is not your problem :)
> 

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.

> Anyway, I hope this clarifies why I submitted this patch.

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.
-- 
Jeff Layton <jlayton@...nel.org>