From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED8AEC433EF for ; Fri, 27 May 2022 00:40:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 119BB8D0003; Thu, 26 May 2022 20:40:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C8AF8D0002; Thu, 26 May 2022 20:40:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECCA48D0003; Thu, 26 May 2022 20:40:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D95C68D0002 for ; Thu, 26 May 2022 20:40:48 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A86523599E for ; Fri, 27 May 2022 00:40:48 +0000 (UTC) X-FDA: 79509667776.13.1D74126 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf18.hostedemail.com (Postfix) with ESMTP id 66AC51C0028 for ; Fri, 27 May 2022 00:40:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653612046; x=1685148046; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=o+btW3u8SomGEDAC6RruxsOcIfC/zxiiddj9HOKFIFk=; b=Sxp17GpthmwOMpgvT/OyKtjWvO5oyrA+N/5ai3xGozPFxJEmqcUAYLUp Z0bciZsd9OycmmIFBUGvE1nbMWC1Xlr8982uHPRYHBJfrIMSoKNUsLoyL ZmG9Qo4EXnygYG2IyX6F7x7jQwsN4D/xdUSJzLbVRZrlrwQnL40vEtZzb fwXcy6c5kXnGFe47THi/oGzlRLAzm+GovFF/Ndwn5v1Otcg192nWd6GI+ oZGyY6edW6HdqCvEi3pY0rNPiRUCJLB6c1+Nrxy6LTHzZvOh9vBK2iyk8 AzRSSaurAGUOQBdMRRz1BxALob+lO6zq5PK4vUcDZ+BP+9skfzGX7EVHp Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10359"; a="271911205" X-IronPort-AV: E=Sophos;i="5.91,252,1647327600"; d="scan'208";a="271911205" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 May 2022 17:40:45 -0700 X-IronPort-AV: E=Sophos;i="5.91,252,1647327600"; d="scan'208";a="609973173" Received: from leticiar-mobl.amr.corp.intel.com (HELO localhost) ([10.213.173.228]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 May 2022 17:40:44 -0700 Date: Thu, 26 May 2022 17:40:44 -0700 From: Ira Weiny To: Matthew Wilcox Cc: linux-mm@kvack.org, "Fabio M. De Francesco" Subject: Re: Should we delete memmove_page? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: kfymh9rz5pzaht19oowqozi5h7chr95x X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Sxp17Gpt; spf=none (imf18.hostedemail.com: domain of ira.weiny@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=ira.weiny@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 66AC51C0028 X-HE-Tag: 1653612029-776341 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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