From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@osdl.org>
Cc: vgoyal@in.ibm.com, linux-kernel@vger.kernel.org,
fastboot@lists.osdl.org, ak@suse.de
Subject: Re: [PATCH 9/10] kdump: read previous kernel's memory
Date: Thu, 17 Nov 2005 16:14:43 -0700 [thread overview]
Message-ID: <m18xvmooik.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20051117142023.43764d8b.akpm@osdl.org> (Andrew Morton's message of "Thu, 17 Nov 2005 14:20:23 -0800")
Andrew Morton <akpm@osdl.org> writes:
> Vivek Goyal <vgoyal@in.ibm.com> wrote:
>>
>> +ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
>> + size_t csize, unsigned long offset, int userbuf)
>> +{
>> + void *vaddr;
>> +
>> + if (!csize)
>> + return 0;
>> +
>> + vaddr = kmap_atomic_pfn(pfn, KM_PTE0);
>> +
>> + if (userbuf) {
>> + if (copy_to_user(buf, (vaddr + offset), csize)) {
>> + kunmap_atomic(vaddr, KM_PTE0);
>> + return -EFAULT;
>
> The copy_*_user() inside kmap_atomic() is problematic.
>
> On some configs (eg, x86, highmem) the process is running atomically, hence
> the copy_*_user() will *refuse* to fault in the user's page if it's not
> present. Because pagefaulting involves doing things which sleep.
>
> So
>
> a) This code will generate might_sleep() warnings at runtime and
>
> b) It'll return -EFAULT for user pages which haven't been faulted in yet.
>
>
> We do all sorts of gruesome tricks in mm/filemap.c to get around all this.
> I don't think your code is as performance-sensitive, so a suitable fix
> might be to double-copy the data. Make sure that the same physical page is
> used as a bounce page for each copy (ie: get the caller to pass it in) and
> that page will be cache-hot and the performance should be acceptable.
>
> If it really is performance-sensitive then you'll need to play filemap.c
> games. It'd be better to use a sleeping kmap instead, if poss. That's
> kmap().
>
> Please send an incremental patch when it's sorted.
I'm going send my standard grumble that what is really needed
is to track why we can't use /dev/mem.
We could solve this with a normal kmap except that we
quite possibly don't have a struct page for this page of memory.
/dev/mem does not allow reads in this situation because of how
problematic getting I/O reads correct is. But not having a good
interface for mapping it into user space is similar.
Could we simply make this into a file that you can mmap
but you can't read? I think that would be cleaner, and simpler.
Eric
next prev parent reply other threads:[~2005-11-17 23:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-17 13:13 [PATCH 0/10] Kdump Update i386/x86_64 Vivek Goyal
2005-11-17 13:18 ` [PATCH 1/10] kdump: i386 save ss esp bug fix Vivek Goyal
2005-11-17 13:20 ` [PATCH 2/10] kdump: dynamic per cpu allocation of memory for saving cpu registers Vivek Goyal
2005-11-17 13:21 ` [PATCH 3/10] kdump: export per cpu crash notes pointer through sysfs Vivek Goyal
2005-11-17 13:23 ` [PATCH 4/10] kdump: save registers early (inline functions) Vivek Goyal
2005-11-17 13:24 ` [PATCH 5/10] kdump: x86_64 add memmmap command line option Vivek Goyal
2005-11-17 13:25 ` [PATCH 6/10] kdump: x86_64 add elfcorehdr " Vivek Goyal
2005-11-17 13:26 ` [PATCH 7/10] kdump: x86_64 kexec on panic Vivek Goyal
2005-11-17 13:28 ` [PATCH 8/10] kdump: x86_64 save cpu registers upon crash Vivek Goyal
2005-11-17 13:29 ` [PATCH 9/10] kdump: read previous kernel's memory Vivek Goyal
2005-11-17 13:30 ` [PATCH 10/10] kexec: increase max segment limit Vivek Goyal
2005-11-17 22:20 ` [PATCH 9/10] kdump: read previous kernel's memory Andrew Morton
2005-11-17 23:14 ` Eric W. Biederman [this message]
2005-11-23 14:04 ` [Fastboot] " Rachita Kothiyal
2005-11-18 0:47 ` [PATCH 8/10] kdump: x86_64 save cpu registers upon crash Haren Myneni
2005-11-18 21:52 ` Eric W. Biederman
2005-11-19 4:35 ` Vivek Goyal
2005-11-17 22:07 ` [PATCH 3/10] kdump: export per cpu crash notes pointer through sysfs Andrew Morton
2005-11-18 12:33 ` Vivek Goyal
2005-11-17 22:01 ` [PATCH 2/10] kdump: dynamic per cpu allocation of memory for saving cpu registers Andrew Morton
2005-11-18 3:37 ` Vivek Goyal
2005-11-18 12:32 ` Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m18xvmooik.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=fastboot@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox