linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


  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