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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5509DC433EF for ; Tue, 7 Dec 2021 11:15:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234901AbhLGLTD (ORCPT ); Tue, 7 Dec 2021 06:19:03 -0500 Received: from verein.lst.de ([213.95.11.211]:55809 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235629AbhLGLTB (ORCPT ); Tue, 7 Dec 2021 06:19:01 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id D841E68B05; Tue, 7 Dec 2021 12:15:26 +0100 (CET) Date: Tue, 7 Dec 2021 12:15:26 +0100 From: Christoph Hellwig To: Matthew Wilcox Cc: Christoph Hellwig , Amit Daniel Kachhap , linux-kernel@vger.kernel.org, Vincenzo Frascino , Kevin Brodsky , linux-fsdevel , kexec , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Young , Baoquan He , Vivek Goyal , x86 Subject: Re: [RFC PATCH 01/14] fs/proc/vmcore: Update read_from_oldmem() for user pointer Message-ID: <20211207111526.GA18554@lst.de> References: <20211203104231.17597-1-amit.kachhap@arm.com> <20211203104231.17597-2-amit.kachhap@arm.com> <20211206140451.GA4936@lst.de> <20211206145422.GA8794@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 06, 2021 at 03:07:15PM +0000, Matthew Wilcox wrote: > > > What do you think to adding a generic copy_pfn_to_iter()? Not sure > > > which APIs to use to implement it ... some architectures have weird > > > requirements about which APIs can be used for what kinds of PFNs. > > > > Hmm. I though kmap_local_pfn(_prot) is all we need? > > In the !HIGHMEM case, that calls pfn_to_page(), and I think the > point of this path is that we don't have a struct page for this pfn. Indeed. But to me this suggest that the !highmem stub is broken and we should probably fix it rather than adding yet another interface.