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
