From: Al Viro <viro@zeniv.linux.org.uk>
To: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
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: Mon, 6 Mar 2023 17:27:59 +0000 [thread overview]
Message-ID: <20230306172759.GB3390869@ZenIV> (raw)
In-Reply-To: <20230306125150.12166-1-fmdefrancesco@gmail.com>
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.
>
> Therefore, delete the rounding down of "page_addr" when passed to
> kunmap_local() in dir_put_page().
>
> Don't backport without commit 88d7b12068b9 ("highmem: round down the
> address passed to kunmap_flush_on_unmap()").
Applied (#work.misc). FWIW, I've rebased the ext2 series to -rc1 (and
realized what got Jan confused about ext2_rename() changes).
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.
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).
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".
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.
Anyway, I've slapped together a counterpart of your sysv series,
see #work.minix
next prev parent reply other threads:[~2023-03-06 17:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 12:51 Fabio M. De Francesco
2023-03-06 17:27 ` Al Viro [this message]
2023-03-07 12:22 ` Fabio M. De Francesco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230306172759.GB3390869@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=dchinner@redhat.com \
--cc=fmdefrancesco@gmail.com \
--cc=ira.weiny@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®