From:   "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     Christian Brauner <brauner@kernel.org>,
        Dave Chinner <dchinner@redhat.com>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        linux-kernel@vger.kernel.org, Ira Weiny <ira.weiny@intel.com>
Subject: Re: [PATCH] fs/sysv: Don't round down address for kunmap_flush_on_unmap()
Date:   Tue, 07 Mar 2023 13:22:21 +0100
Message-ID: <1820093.atdPhlSkOF@suse>
In-Reply-To: <20230306172759.GB3390869@ZenIV>
References: <20230306125150.12166-1-fmdefrancesco@gmail.com>
 <20230306172759.GB3390869@ZenIV>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk

On luned=EC 6 marzo 2023 18:27:59 CET Al Viro wrote:
> On Mon, Mar 06, 2023 at 01:51:50PM +0100, Fabio M. De Francesco wrote:
> > The kernel virtual address passed to kunmap_flush_on_unmap() has no more
> > any need to be rounded down.
> >=20
> > Therefore, delete the rounding down of "page_addr" when passed to
> > kunmap_local() in dir_put_page().
> >=20
> > Don't backport without commit 88d7b12068b9 ("highmem: round down the
> > address passed to kunmap_flush_on_unmap()").
>=20
> Applied (#work.misc).

Thanks!

I'm using (again, sorry) this opportunity to remind you that I'd really=20
appreciate if you could also set aside some time to look at my patch to fs/
aio.c.

Instead I'm not sure yet who is at the moment responsible for the patches t=
o=20
fs/ufs...=20

> FWIW, I've rebased the ext2 series to -rc1 (and
> realized what got Jan confused about ext2_rename() changes).

I just git-clone(ed) your "vfs" tree and started with building and testing =
the =20
#work.ext2 branch, without and with your latest commits (from Linux 6.3-rc1=
=20
merge onward).

As said in the thread with the pull request of my fs/sysv related patches I=
'll=20
test with (x)fstests in a QEMU/KVM x86_32 VM, 6GB RAM, running an HIGHMEM64=
GB=20
kernel.

> Re minixfs: it's actually very close to sysv, so much that at one point
> I considered merging them - making minixfs one of sysvfs flavours.

OK, so porting fs/sysv (or fs/ufs) changes to fs/minix should be an easy ta=
sk.

> Think of it as v7 filesystem with the simpler improvements copied from
> FFS.  Cylinder groups and variable-sized directory entries - too
> complex for Minix purposes.  Lifting the name length limit from 14 to
> 30 - sure, why not?  32bit block numbers - eventually made it,
> so did 32bit inode numbers (in v3).
>=20
> The main advance compared to v7 is the use of bitmaps for block
> and inode allocation.  Unlike FFS it's all in one lump, but at least
> it's not the "free block list".
>=20
> For directory contents handling it doesn't matter at all - there minixfs
> is really just another sysvfs variant.  Directory is stored the same
> way as a regular file would've been, the data in it is an array of
> fixed-sized entries (16, 32 or 64 bytes, depending upon the filesystem
> version), each consisting of inode number (2 or 4 bytes) + array of
> characters representing the name; name shorter than the longest possible
> are NUL-terminated.
>=20
> Anyway, I've slapped together a counterpart of your sysv series,
> see #work.minix

I must admit that I don't yet own enough good knowledge of the details you =
are=20
mentioning above. However, thanks for sharing!

Those insights surely help me to better understand what details to look at=
=20
when trying to tell the differences and commonalities between filesystems.

I'll take a look at #work.minix in the next days (build, test, review), but=
=20
only when I'm done with #work.ext2 (I have little spare time because ATM I'=
m=20
attending some courses and, in the meantime, I'm also volunteering as a co-
mentor with Ira).

Again thanks,

=46abio