[PATCH] MAINTAINERS: add myself as UFS filesystem maintainer

[PATCH] MAINTAINERS: add myself as UFS filesystem maintainer

[Ali Ahmet Memis]

fs/ufs has no MAINTAINERS entry. get_maintainer.pl returns only the open
lists, so patches for it have no clear reviewer and tend to sit
unanswered. The archives show the cost of this: a truncate path memory
leak fix was posted in 2018 with a stable tag and was never applied [1],
and recent mount path hardening patches went weeks without a maintainer
to review or apply them [2][3].

The code needs attention. It parses on-disk BSD and Solaris layouts with
very little validation, so several crafted-image mount crashes are still
open. I have been reading it and fixing real bugs in the normal paths as
well, including the 2018 leak above and an rmdir path that treated an
unreadable directory block as empty and could drop a non-empty directory
[4].

I am willing to take responsibility for fs/ufs: review incoming patches,
carry the pending fixes, and keep it building and correct. Add a
Maintained entry to reflect that.

Link: https://lore.kernel.org/all/20180705150415.25070-1-lhenriques@suse.com/ [1]
Link: https://lore.kernel.org/all/20260717104033.38574-1-david.lee@trailofbits.com/ [2]
Link: https://lore.kernel.org/all/20260701215700.822003-1-kudo3228@gmail.com/ [3]
Link: https://lore.kernel.org/all/20260801013942.279992-1-ali@iusegentoo.com/ [4]
Signed-off-by: Ali Ahmet Memis <ali@iusegentoo.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 62d53465e..8a1dc78f0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27663,6 +27663,12 @@ L:	linux-input@vger.kernel.org
 S:	Maintained
 F:	drivers/hid/hid-udraw-ps3.c
 
+UFS FILESYSTEM
+M:	Ali Ahmet Memis <ali@iusegentoo.com>
+L:	linux-fsdevel@vger.kernel.org
+S:	Maintained
+F:	fs/ufs/
+
 UHID USERSPACE HID IO DRIVER
 M:	David Rheinsberg <david@readahead.eu>
 L:	linux-input@vger.kernel.org
-- 
2.54.0

Re: [PATCH] MAINTAINERS: add myself as UFS filesystem maintainer

[Matthew Wilcox]

On Sat, Aug 01, 2026 at 05:50:15AM +0300, Ali Ahmet Memis wrote:
> I am willing to take responsibility for fs/ufs: review incoming patches,
> carry the pending fixes, and keep it building and correct. Add a
> Maintained entry to reflect that.

Convince us you aren't Jia Tan.  You have almost no history with the
Linux kernel (one commit that I can find, and that has a different email
address attached to it).

Re: [PATCH] MAINTAINERS: add myself as UFS filesystem maintainer

[Ali Ahmet Memis]

On Sat, Aug 01, 2026 at 05:23:38AM +0100, Matthew Wilcox wrote:
> Convince us you aren't Jia Tan.  You have almost no history with the
> Linux kernel (one commit that I can find, and that has a different email
> address attached to it).

Fair question, and after xz it is the right one to ask, so no offence
taken.

Proving a negative is hard, so here is what I can actually show.

The commit you found is 607af438e643 ("tools/power/x86/
intel-speed-select: Harden daemon pidfile open"). I wrote it as Ali
Ahmet MEMIS <dev@unknownbbqr.xyz> and Srinivas Pandruvada applied it. I
still control that address and will confirm from it that
ali@iusegentoo.com is the same person if that is useful. I have moved my
kernel work to the iusegentoo.com address and will keep to one from here.

Past that, I would rather be judged on this week's work than on my word:
  - ufs: do not treat unreadable directory blocks as empty (rmdir data
    loss)
  - ufs: free the buffer head container in ubh_bforget (Luis Henriques
    posted this fix in 2018 and it was never applied)
  - reviews of the pending cgsize and cssize hardening patches
  - a two patch hardening series with KASAN reproducers, for a mount
    teardown NULL deref and an out of bounds write driven by on-disk
    cg_cgx

On the entry: point taken, adding myself as Maintained on this much
history is premature. Consider this patch dropped. I will keep sending
fixes and reviews, and if an entry ever looks warranted to you and the
other reviewers we can revisit it then. The fixes do not depend on it.

What I care about is ufs bugs not being ignored. If routing my fixes
through you or the vfs tree is the better path, that is fine by me.

Re: [PATCH] MAINTAINERS: add myself as UFS filesystem maintainer

[Jan Kara]

On Sat 01-08-26 10:30:59, Ali Ahmet Memis wrote:
> What I care about is ufs bugs not being ignored. If routing my fixes
> through you or the vfs tree is the better path, that is fine by me.

I'm a bit curious: Are you using UFS driver in Linux? Or do you know of
anybody using it?

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

Re: [PATCH] MAINTAINERS: add myself as UFS filesystem maintainer

[Ali Ahmet Memis]

On Mon, Aug 03, 2026 at 10:57:14AM +0200, Jan Kara wrote:
> I'm a bit curious: Are you using UFS driver in Linux? Or do you know of
> anybody using it?

Yes. I run FreeBSD on a second machine that I keep as a small server, and
its disks are UFS2. I mount those from my Linux box with the in-tree ufs
driver to read data off them, which on Linux is read-only for UFS2. So the
driver is not theoretical for me, it is how I reach my own data.

More generally that is what the driver is for: reading FreeBSD, NetBSD,
OpenBSD and Solaris disks from Linux. Anyone dual booting a BSD, migrating
data off one, or doing recovery or forensics on a BSD or Solaris volume
ends up here. It is a small user base but not an empty one, and it is the
only in-tree way to do it.

That is also why the mount path bugs bother me. The images I feed it are
real BSD volumes, sometimes left unclean after a crash, so an unusual but
legitimate on-disk layout should not panic the kernel. The fixes I have
been sending are all in that parse and mount path.

Thanks,
Ali

Re: [PATCH] MAINTAINERS: add myself as UFS filesystem maintainer

[Jan Kara]

On Mon 03-08-26 09:44:10, Ali Ahmet Memis wrote:
> On Mon, Aug 03, 2026 at 10:57:14AM +0200, Jan Kara wrote:
> > I'm a bit curious: Are you using UFS driver in Linux? Or do you know of
> > anybody using it?
> 
> Yes. I run FreeBSD on a second machine that I keep as a small server, and
> its disks are UFS2. I mount those from my Linux box with the in-tree ufs
> driver to read data off them, which on Linux is read-only for UFS2. So the
> driver is not theoretical for me, it is how I reach my own data.

Cool! When real users are fixing what they are using the results are
usually better than if it is just "close a couple of syzbot bugs" :).

> More generally that is what the driver is for: reading FreeBSD, NetBSD,
> OpenBSD and Solaris disks from Linux. Anyone dual booting a BSD, migrating
> data off one, or doing recovery or forensics on a BSD or Solaris volume
> ends up here. It is a small user base but not an empty one, and it is the
> only in-tree way to do it.

Yep, I was expecting some real users still do exist but I didn't hear about
anybody for a long time :).

> That is also why the mount path bugs bother me. The images I feed it are
> real BSD volumes, sometimes left unclean after a crash, so an unusual but
> legitimate on-disk layout should not panic the kernel. The fixes I have
> been sending are all in that parse and mount path.

Sure.

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