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 7109EC433EF for ; Fri, 27 May 2022 03:33:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA3628D0003; Thu, 26 May 2022 23:33:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D51DD8D0002; Thu, 26 May 2022 23:33:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C17738D0003; Thu, 26 May 2022 23:33:53 -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 B370E8D0002 for ; Thu, 26 May 2022 23:33:53 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8505060934 for ; Fri, 27 May 2022 03:33:53 +0000 (UTC) X-FDA: 79510103946.11.8EE2C01 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf19.hostedemail.com (Postfix) with ESMTP id 529261A0035 for ; Fri, 27 May 2022 03:33:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653622432; x=1685158432; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=OxmGEChvIx5CI+pn+iwBQjiJad9I69F+vtNWDsYHv0E=; b=cxGS2yieiYgZBLwmmKBi/gTMCm88wluLU271WcvFQlAqQu0jsFlRRMXT DmD0WVNz6wu6d02r0jexfa30yJCWnlk1iz9RPvrl5kK3+GgTX6Nc7HNC7 Vgq0zOtWNuGhLtwmskvS0DIihkPAQh7JQkjYP9ddTHSFZOnmv+Hzc/pQg MLnqJ1Ykp6DA3fRx+80O1lrikdGUfgO14y/bP4Fdxdd1eH/PVdmtVfTw6 G6HEmHlTw53uTNdjwJU/E/7Oarxdk11DJOmsslFQCj1DXM8B3RiKPrqS+ GhdkUsOctyl4chmUV5QuP0+kBlT9DwZT84L11FaIrN6CgM+tB9mIVhHXN Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10359"; a="261986433" X-IronPort-AV: E=Sophos;i="5.91,254,1647327600"; d="scan'208";a="261986433" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 May 2022 20:33:49 -0700 X-IronPort-AV: E=Sophos;i="5.91,254,1647327600"; d="scan'208";a="704920724" Received: from leticiar-mobl.amr.corp.intel.com (HELO localhost) ([10.213.173.228]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 May 2022 20:33:49 -0700 Date: Thu, 26 May 2022 20:33:49 -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: tn85gufczjrkfqqt7bus1qjbkm94qssh X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cxGS2yie; spf=none (imf19.hostedemail.com: domain of ira.weiny@intel.com has no SPF policy when checking 134.134.136.20) smtp.mailfrom=ira.weiny@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 529261A0035 X-HE-Tag: 1653622419-77103 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 Fri, May 27, 2022 at 02:26:52AM +0100, Matthew Wilcox wrote: > On Thu, May 26, 2022 at 05:40:44PM -0700, Ira Weiny wrote: > > 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. > > I don't understand what you mean ... Nevermind. I missed the fact that arch_kmap_local_map_idx() does not actually use the pfn except on xtensa. > you can unmap the address, it's > just that memmove can't know that the two virtual ranges actually > overlap physically. I was thinking that the index returned would be the same for both kmaps. > > > 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. > > Umm? They're all using memcpy(), so the caller must guarantee that the > physical addresses are different. Exactly. But how does the caller know that? The memcpy() call is buried inside the copy_user_page() and/or copy_page(). Users of these functions should not need to dig that far into an implementation to use this interface IMO. Adding some kdoc helps I think. > > > 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. > > Excellent! I advised Fabio last year, and I think he'll do a sterling > job this year. Me too! > > > Would you like Fabio or I to send a patch? I think the main thing right now is > > to just drop the memmove_page() > > Sure, just stick my Reported-by: on it. Absolutely! Thanks for the report, Ira