[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <792975039.3142581.1761826973320@kpc.webmail.kpnmail.nl>
Date: Thu, 30 Oct 2025 13:22:53 +0100 (CET)
From: Jori Koolstra <jkoolstra@...all.nl>
To: 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>,
	Jeff Layton <jlayton@...nel.org>, 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
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 :)
Anyway, I hope this clarifies why I submitted this patch.
Powered by blists - more mailing lists
 
