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: <dceefe7e-4cd3-464d-b5b4-f80c02b4331d@linuxfoundation.org>
Date: Thu, 30 Oct 2025 09:44:40 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: Jeff Layton <jlayton@...nel.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,
 Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH] Add error handling to minix filesystem similar to ext4

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?

> 
> 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?

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