linux-ext4 - Is fsmap supposed to use open or closed intervals?

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>] [day] [month] [year] [list]

Message-ID: <20241022014742.GA3570993@mit.edu>
Date: Mon, 21 Oct 2024 21:47:42 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Linux Filesystem Development List <linux-fsdevel@...r.kernel.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        "Darrick J. Wong" <djwong@...nel.org>
Subject: Is fsmap supposed to use open or closed intervals?

I was debugging ext4's failure with the new test generic/365, which
was testing the regressions fixed by commits 68415b349f3f ("xfs: Fix
the owner setting issue for rmap query in xfs fsmap") and ca6448aed4f1
("xfs: Fix missing interval for missing_owner in xfs fsmap").  It
appears that ext4 has a similar bug, but then when I started looking
at how XFS handles fsmap, it's a bit unclear whether the intervals
queried are supposed to be open, closed, or half-open.

Looking at how 6.11-rc4's xfs handles fsmap, these two results seem to
be a bit contradictory:

root@...-xfstests:~# xfs_io -i -c "fsmap -d 104 127" /vdd
        0: 254:48 [104..126]: free space 23

OK, so it looks like fsmap returns the half-open interval [104 127).

But then I tried this:

root@...-xfstests:~# xfs_io -i -c "fsmap -d 104 128" /vdd
        0: 254:48 [104..127]: free space 24
        1: 254:48 [128..191]: inodes 64

and the fact that this query returns the region between [128, 191] is
surprising.

Is this a bug?  Is it OK if we expand the interval and return more
blocks than what the application program queried?

Thanks,

						- Ted