Message-ID: <58ce03be10ba5adc2b3896e9f5872ff26a74c195.camel@kernel.org>
Date: Thu, 30 Oct 2025 13:40:15 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Shuah Khan <skhan@...uxfoundation.org>, Jori Koolstra
 <jkoolstra@...all.nl>
Cc: Christian Brauner <brauner@...nel.org>, Khalid Aziz <khalid@...nel.org>,
  Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, Jan Kara
 <jack@...e.cz>, 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 09:44 -0600, Shuah Khan wrote:
> On 10/30/25 09:12, Jeff Layton wrote:
> > On Thu, 2025-10-30 at 15:09 +0100, Jori Koolstra wrote:
> > > > 
> > > > I don't see a licensing issue. It's BSD licensed. Also, this is a
> > > > userland code, so we wouldn't need to worry about that too much.
> > > > 
> > > 
> > > Oh, my bad. I thought Minix (the OS) had some licensing incompatibilities
> > > with Linux, and this repo takes code from Minix. But that may be long in
> > > the past.
> > > 
> > 
> > Minix is BSD licensed too. That's not completely incompatible with the
> > GPL, but IANAL.
> > 
> > > > 
> > > > You're quite right though that userland replacements will need to meet
> > > > some criteria before we can rip out the in-kernel versions. This might
> > > > be a good discussion topic for next year's LSF/MM!
> > > 
> > > Would an in-tree but out of kernel implementation be an idea? Like how
> > > kselftest is integrated in the code, even though most of that also takes
> > > place in userland. That would guarantee a level of support, at least for
> > > the time being. I could take the code, verify it, and write some tests
> > > for in selftest.
> > > 
> > 
> > That's not a bad idea. We already have some userland code in the kernel
> > tree (the tools/ directory comes to mind). A directory with replacement
> > FUSE drivers for in-kernel filesystems could be a reasonable thing to
> > add. Anything we keep in-tree will need to be GPL-compatible though.
> 
> Jori, if you want to continue working on userland slotions and working
> to initiate deprecating, working - please do.> 
> > > And there is still the issue of what we do for the syzbot bugs until a
> > > more permanent solution is achieved.
> > > 
> > 
> > Yeah, that's a different issue.  Most likely we'll need to fix those in
> > the near term. Replacing minix.ko with a FUSE fs will take time
> > (years), even once we have a new driver in hand.
> Does this mean Jori can work on fixing these while replacing minix.ko
> with fuse progresses?
> 

Caveat: I have no real connection to minixfs. All of my contributions
are drive-bys where I was changing some other vfs layer interface.

I see no problem with fixing real bugs in the minixfs driver.
Personally, I'd focus on things that are actual security problems --
crashes that are triggerable by non-privileged users.

In this case, the problem involves a deliberately corrupted filesystem.
As a community, we have deprioritized fixing these sorts of bugs.
Someone with the access to mount a deliberately corrupt fs like this is
in a position to crash the kernel in any number of other ways. With a
legacy filesystem like this, fixing problems of this nature is usually
not worth developer/reviewer time.

> > 
> > We'll need to mark the old driver deprecated and then wait a few
> > releases before we can rip it out.
> Jori could work on patches for deprecating perhaps?
> 

That's probably premature until we have feature-complete replacement to
point users toward.

> > 
> > > Anyway, this probably goes over my head as a clueless beginner. Just
> > > trying to see where I can help. Thanks a lot Jeff for you answers, I
> > > appreciate it.
> > > 
> > 
> > You're welcome. We all start out as beginners!
> 
> +1
> 
> thanks,
> -- Shuah

-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists