From: Ira Weiny <ira.weiny@intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Subject: Re: Should we delete memmove_page?
Date: Thu, 26 May 2022 17:40:44 -0700 [thread overview]
Message-ID: <YpAeDE3ayStrx4Cv@iweiny-desk3> (raw)
In-Reply-To: <Yo+TPE2Zrg6czyBu@casper.infradead.org>
On Thu, May 26, 2022 at 03:48:28PM +0100, Matthew Wilcox wrote:
>
> I was looking at memmove_page() and it occurred to me that it can't
> actually work,
Oh wow yea. Because you can't unmap that address correctly.
>
> so we should probably delete it as being an attractive
> nuisance. It doesn't have any users.
>
> memmove() isn't magic. It compares the source address, source length,
> destination address and destination length, and then does either a
> forwards copy or a backwards copy, depending where the overlap is.
>
> But 'dst' and 'src' are guaranteed to be non-overlapping. They come from
> different calls to kmap_local_page(), so even if src_page and dst_page
> are the same, src and dst will be different.
>
> We could fix it up. Include a compare of 'dst_page' and 'src_page'
> and if they're the same only kmap_local_page() one of them. But since
> it has no users, perhaps just delete it?
Yes deletion is best. But...
copy_user_highpage()
copy_highpage()
... might suffer from the same potential issue should a user not realize. I
think memcpy_page() by virtue of the name.
Still perhaps a kernel doc may be in order.
I could not say anything at LSFmm because the Outreachy interns had not been
announced but I've selected Fabio to help with the highmem rework through that
program.
Would you like Fabio or I to send a patch? I think the main thing right now is
to just drop the memmove_page()
Ira
next prev parent reply other threads:[~2022-05-27 0:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 14:48 Matthew Wilcox
2022-05-27 0:40 ` Ira Weiny [this message]
2022-05-27 1:26 ` Matthew Wilcox
2022-05-27 3:33 ` Ira Weiny
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=YpAeDE3ayStrx4Cv@iweiny-desk3 \
--to=ira.weiny@intel.com \
--cc=fmdefrancesco@gmail.com \
--cc=linux-mm@kvack.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