[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20211207111526.GA18554@lst.de>
Date: Tue, 7 Dec 2021 12:15:26 +0100
From: Christoph Hellwig <hch@....de>
To: Matthew Wilcox <willy@...radead.org>
Cc: Christoph Hellwig <hch@....de>,
Amit Daniel Kachhap <amit.kachhap@....com>,
linux-kernel@...r.kernel.org,
Vincenzo Frascino <Vincenzo.Frascino@....com>,
Kevin Brodsky <kevin.brodsky@....com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
kexec <kexec@...ts.infradead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Young <dyoung@...hat.com>, Baoquan He <bhe@...hat.com>,
Vivek Goyal <vgoyal@...hat.com>, x86 <x86@...nel.org>
Subject: Re: [RFC PATCH 01/14] fs/proc/vmcore: Update read_from_oldmem()
for user pointer
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.
Powered by blists - more mailing lists