From: Ira Weiny <ira.weiny@intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
Evgeniy Dushistov <dushistov@mail.ru>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] fs/ufs: Replace kmap() with kmap_local_page()
Date: Wed, 25 May 2022 08:12:35 -0700 [thread overview]
Message-ID: <Yo5HY3dzjVigCJ7i@iweiny-desk3> (raw)
In-Reply-To: <YoJl+lh0QELbv/TL@casper.infradead.org>
On Mon, May 16, 2022 at 03:55:54PM +0100, Matthew Wilcox wrote:
> On Mon, May 16, 2022 at 12:19:25PM +0200, Fabio M. De Francesco wrote:
> > The use of kmap() is being deprecated in favor of kmap_local_page(). With
> > kmap_local_page(), the mapping is per thread, CPU local and not globally
> > visible.
> >
> > The usage of kmap_local_page() in fs/ufs is pre-thread, therefore replace
> > kmap() / kunmap() calls with kmap_local_page() / kunmap_local().
> >
> > kunmap_local() requires the mapping address, so return that address from
> > ufs_get_page() to be used in ufs_put_page().
> >
> > These changes are essentially ported from fs/ext2 and are largely based on
> > commit 782b76d7abdf ("fs/ext2: Replace kmap() with kmap_local_page()").
> >
> > Suggested-by: Ira Weiny <ira.weiny@intel.com>
> > Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
>
> Have you done more than compile-tested this? I'd like to know that it's
> been tested on a machine with HIGHMEM enabled (in a VM, presumably).
> UFS doesn't get a lot of testing, and it'd be annoying to put out a
> patch that breaks the kmap_local() rules.
Do you know of any real users of UFS?
Fabio and I have been looking into how to test this and it seems like UFS
support has been dropped in my system. For example, there is no mkfs.ufs in my
fc35 system.
Searching google, I see that mkfs.ufs turns up a couple of Oracle documents.
And some other links mention something called newfs which I've never heard of.
The patches follow the same pattern which was added to ext2 a while back and
have not caused an issue. So I'm pretty confident they will be ok.
However, if it is critical that these be tested I think Fabio will have to hold
off on these patches for now as there are plenty of other kmap() call sites
which are more important to be fixed.
Ira
next prev parent reply other threads:[~2022-05-25 15:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 10:19 Fabio M. De Francesco
2022-05-16 14:55 ` Matthew Wilcox
2022-05-16 19:53 ` Ira Weiny
2022-05-16 21:59 ` Fabio M. De Francesco
2022-05-25 15:12 ` Ira Weiny [this message]
2022-08-02 7:06 ` Fabio M. De Francesco
2022-08-03 19:04 ` 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=Yo5HY3dzjVigCJ7i@iweiny-desk3 \
--to=ira.weiny@intel.com \
--cc=dushistov@mail.ru \
--cc=fmdefrancesco@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--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®