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: <aoppzgcsml33slovgn2cz4ntmdxczk3yu5zlajh7d5bnsdav7o@lhszynfelx4b>
Date: Thu, 30 Oct 2025 18:01:05 +0100
From: Jan Kara <jack@...e.cz>
To: Jori Koolstra <jkoolstra@...all.nl>
Cc: Jan Kara <jack@...e.cz>, 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 Jori!

On Thu 30-10-25 13:22:53, Jori Koolstra wrote:
> > 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).

Well, one thing is handling corruption well - that part of your patch was
fine and I think it is still useful - another thing are the mount options
that allow to configure what happens when we find a corruption - and that
is the part I don't think really makes a lot of sense for minix.

> 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 :)

Your fix for minix_rmdir() is needed. If minix is going out of the kernel
is uncertain and even if that happens it will certainly need some
deprecation period so functional fixes are still wanted in that period.

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

Fully, thanks for the clarification and your work on Linux :)

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR