search for: do_wp_pag

...ffff80110833>{ret_from_intr+0} <5> <ffffffff8013c731>{__do_softirq+77} <ffffffff8013c7e5>{do_softirq+49} <5> <ffffffff80110bf5>{apic_timer_interrupt+133} <EOI> <ffffffff8011c21a>{flush_tlb_page+44} <5> <ffffffff80169106>{do_wp_page+1127} <ffffffff80123ed3>{do_page_fault+575} <5> <ffffffff80169ff2>{handle_mm_fault+1228} <ffffffff80123e9a>{do_page_fault+518} <5> <ffffffff8011026a>{system_call+126} <ffffffff80132bc6>{schedule_tail+202} <5> <ffffffff80110d91...

Hi, I have been able to run 32 bit virtual machines on a 64 bit machine quite nicely with xen3.1 but sometimes when running yum the messages "do_wp_page: bogus page at address 0070d638" and "kernel: VM: killing process yum" and yum just stops working. I also get Kernel Panic. Does anyone have any idea, what could be the probem? Thanks, Ricardo _______________________________________________ Xen-users mailing list Xen-users@lists....

Hi, I''m getting the following oops on startup, and I''m not quite sure why. It looks nasty though, with an invalid page being mapped into a process, and a strange looking EIP ... do_wp_page: bogus page at address 00000449 VM: killing process kmodule Unable to handle kernel NULL pointer dereference at virtual address 00000449 printing eip: 00001eca *pde = ma 0d183067 pa 0a583067 *pte = ma 00000025 pa 55555025 [<c010d91c>] syscall_call+0x7/0xb Oops: 0003 [#1] Modules linked...

...linux-2.6/mm/memory.c linux-2.6-patched/mm/memory.c --- linux-2.6/mm/memory.c 2006-09-01 12:50:23.000000000 +0200 +++ linux-2.6-patched/mm/memory.c 2006-09-01 12:50:23.000000000 +0200 @@ -2064,8 +2064,16 @@ static int do_swap_page(struct mm_struct unlock_page(page); if (write_access) { - if (do_wp_page(mm, vma, address, - page_table, pmd, ptl, pte) == VM_FAULT_OOM) + int rc = do_wp_page(mm, vma, address, page_table, + pmd, ptl, pte); + if (page_host_discards() && rc == VM_FAULT_MAJOR) + /* + * A discard removed the page, and do_wp_page called + * page_discard which re...

...linux-2.6/mm/memory.c linux-2.6-patched/mm/memory.c --- linux-2.6/mm/memory.c 2006-09-01 12:50:23.000000000 +0200 +++ linux-2.6-patched/mm/memory.c 2006-09-01 12:50:23.000000000 +0200 @@ -2064,8 +2064,16 @@ static int do_swap_page(struct mm_struct unlock_page(page); if (write_access) { - if (do_wp_page(mm, vma, address, - page_table, pmd, ptl, pte) == VM_FAULT_OOM) + int rc = do_wp_page(mm, vma, address, page_table, + pmd, ptl, pte); + if (page_host_discards() && rc == VM_FAULT_MAJOR) + /* + * A discard removed the page, and do_wp_page called + * page_discard which re...

..._read+0x1e0/0x20b [zaptel] Mar 29 09:38:24 pstn1 kernel: [<c04ea195>] copy_from_user+0x31/0x5d Mar 29 09:38:24 pstn1 kernel: [<c05ac4c4>] sys_sendto+0x116/0x140 Mar 29 09:38:24 pstn1 kernel: [<c0415d4f>] flush_tlb_page+0x74/0x77 Mar 29 09:38:24 pstn1 kernel: [<c0461331>] do_wp_page+0x3bf/0x40a Mar 29 09:38:24 pstn1 kernel: [<c04284f1>] current_fs_time+0x4a/0x55 Mar 29 09:38:24 pstn1 kernel: [<c0488f9b>] touch_atime+0x60/0x91 Mar 29 09:38:24 pstn1 kernel: [<c047d9d0>] pipe_readv+0x315/0x321 Mar 29 09:38:24 pstn1 kernel: [<c05acde4>] sys_socketcall+...

...0>] ? load_balance+0x550/0x7d0 [<c0431614>] ? _raw_spin_unlock_irq+0x4/0x20 [<c012d9ba>] ? finish_task_switch+0x3a/0x90 [<c042f5c9>] ? schedule+0x1c9/0x520 [<c0103d30>] ? common_interrupt+0x30/0x40 [<c042facf>] ? preempt_schedule+0x2f/0x50 [<c0198a60>] ? do_wp_page+0x160/0x960 [<c0199c02>] ? handle_mm_fault+0x5d2/0xaa0 [<c01244b0>] ? do_page_fault+0x0/0x370 [<c01245f0>] ? do_page_fault+0x140/0x370 [<c01b7b2f>] ? copy_strings+0x17f/0x1a0 [<c01b935e>] ? do_execve+0x2be/0x310 [<c01b935e>] ? do_execve+0x2be/0x310 [<c...

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

Hello, >On Sun, 5 Dec 2004, Rik van Riel wrote: > > > I"m getting the following oops on startup, and I"m not quite > > sure why. It looks nasty though, with an invalid page being > > mapped into a process, and a strange looking EIP ... > > > > do_wp_page: bogus page at address 00000449 > > VM: killing process kmodule > > Unable to handle kernel NULL pointer dereference at virtual address > > 00000449 > OK, figured it out. It"s kmodule, mmaping /dev/mem and > making vm86 calls. Select fragments from a strace: (...

...rd fault handler can remove the page cache reference and all mappers of a page. It cannot remove the page reference for any other user of the page. The transitions to stable are done by find_get_pages() and its variants, in get_user_pages if called with a pages parameter, by copy-on-write in do_wp_page, and by the early copy-on-write in do_no_page. To make enough pages discardable by the host an attempt to do the transition to volatile state is done when a page gets unlocked (unlock_page), when writeback has finished (test_clear_page_dirty), when the page reference counter is decreased (put_page...

...rd fault handler can remove the page cache reference and all mappers of a page. It cannot remove the page reference for any other user of the page. The transitions to stable are done by find_get_pages() and its variants, in get_user_pages if called with a pages parameter, by copy-on-write in do_wp_page, and by the early copy-on-write in do_no_page. To make enough pages discardable by the host an attempt to do the transition to volatile state is done when a page gets unlocked (unlock_page), when writeback has finished (test_clear_page_dirty), when the page reference counter is decreased (put_page...

...) || !is_zero_pfn(pte_pfn(pte))) @@ -1290,7 +1309,6 @@ split_fallthrough: */ mark_page_accessed(page); } -unlock: pte_unmap_unlock(ptep, ptl); out: return page; @@ -1489,17 +1507,13 @@ int __get_user_pages(struct task_struct * The VM_FAULT_WRITE bit tells us that * do_wp_page has broken COW when necessary, * even if maybe_mkwrite decided not to set - * pte_write. We can thus safely do subsequent - * page lookups as if they were reads. But only - * do so when looping for pte_write is futile: - * in some cases userspace may also be wanting - * t...

...drain_alien_cache |--2.56%-- ext4_do_update_inode |--2.54%-- try_to_wake_up |--2.46%-- pgd_free |--2.32%-- cache_alloc_refill |--2.32%-- pgd_alloc |--2.32%-- free_pcppages_bulk |--1.88%-- do_wp_page |--1.77%-- handle_pte_fault |--1.58%-- do_anonymous_page |--1.56%-- rmqueue_bulk.clone.0 |--1.35%-- copy_pte_range |--1.25%-- zap_pte_range |--1.13%-- cache_flusharray |--0.88%-- __pmd_a...

...drain_alien_cache |--2.56%-- ext4_do_update_inode |--2.54%-- try_to_wake_up |--2.46%-- pgd_free |--2.32%-- cache_alloc_refill |--2.32%-- pgd_alloc |--2.32%-- free_pcppages_bulk |--1.88%-- do_wp_page |--1.77%-- handle_pte_fault |--1.58%-- do_anonymous_page |--1.56%-- rmqueue_bulk.clone.0 |--1.35%-- copy_pte_range |--1.25%-- zap_pte_range |--1.13%-- cache_flusharray |--0.88%-- __pmd_a...

On Tue, 25 Oct 2016 10:06:12 +0200 Christian Anthon <anthon at rth.dk> wrote: > What is the best approach on centos 6 to mitigate the problem is > officially patched? As far as I can tell Centos 6 is vulnerable to > attacks using ptrace. I can confirm that c6 is vulnerable, we're running a patched kernel (local build) using a rhel6 adaptation of the upstream fix. Ask

...l); page_add_file_rmap(page); update_mmu_cache(vma, addr, pte_val); diff -urpN linux-2.6/mm/memory.c linux-2.6-patched/mm/memory.c --- linux-2.6/mm/memory.c 2006-09-01 12:50:24.000000000 +0200 +++ linux-2.6-patched/mm/memory.c 2006-09-01 12:50:24.000000000 +0200 @@ -1558,6 +1558,7 @@ static int do_wp_page(struct mm_struct * flush_cache_page(vma, address, pte_pfn(orig_pte)); entry = pte_mkyoung(orig_pte); entry = maybe_mkwrite(pte_mkdirty(entry), vma); + page_check_writable(old_page, entry); ptep_set_access_flags(vma, address, page_table, entry, 1); update_mmu_cache(vma, address, ent...

...l); page_add_file_rmap(page); update_mmu_cache(vma, addr, pte_val); diff -urpN linux-2.6/mm/memory.c linux-2.6-patched/mm/memory.c --- linux-2.6/mm/memory.c 2006-09-01 12:50:24.000000000 +0200 +++ linux-2.6-patched/mm/memory.c 2006-09-01 12:50:24.000000000 +0200 @@ -1558,6 +1558,7 @@ static int do_wp_page(struct mm_struct * flush_cache_page(vma, address, pte_pfn(orig_pte)); entry = pte_mkyoung(orig_pte); entry = maybe_mkwrite(pte_mkdirty(entry), vma); + page_check_writable(old_page, entry); ptep_set_access_flags(vma, address, page_table, entry, 1); update_mmu_cache(vma, address, ent...

...ep_new_page+0x24/0x3a Jul 3 04:02:03 lvs2 kernel: [<c014f51f>] buffered_rmqueue+0x1c4/0x1e7 Jul 3 04:02:03 lvs2 kernel: [<c014f5f5>] __alloc_pages+0xb3/0x29a Jul 3 04:02:03 lvs2 kernel: [<c01604df>] anon_vma_prepare+0x1f/0x1bf Jul 3 04:02:03 lvs2 kernel: [<c015ad3a>] do_wp_page+0x1d4/0x422 Jul 3 04:02:03 lvs2 kernel: [<c015bf5c>] handle_mm_fault+0x136/0x212 Jul 3 04:02:03 lvs2 kernel: [<c011d967>] do_page_fault+0x1ac/0x50c Jul 3 04:02:03 lvs2 kernel: [<c01345fe>] sys_rt_sigaction+0xdc/0xf0 Jul 3 04:02:03 lvs2 kernel: [<c016b77f>] filp_clos...

..._mask=0x200d2, order=0 Aug 4 18:36:51 [<c0105801>] show_trace+0x21/0x30 Aug 4 18:36:51 [<c010593e>] dump_stack+0x1e/0x20 Aug 4 18:36:51 [<c0140de0>] out_of_memory+0x90/0xc0 Aug 4 18:36:52 [<c014219d>] __alloc_pages+0x2ed/0x320 Aug 4 18:36:52 [<c014d0c0>] do_wp_page+0xa0/0x4c0 Aug 4 18:36:52 [<c014ddd8>] do_swap_page+0x2f8/0x480 Aug 4 18:36:52 [<c014e972>] __handle_mm_fault+0x302/0x430 Aug 4 18:36:53 [<c011581f>] do_page_fault+0x1df/0x906 Aug 4 18:36:53 [<c01054cb>] error_code+0x2b/0x30 Aug 4 18:36:53 [<c0104f91>]...

...49 aspirebox.fcshome.stoneham.ma.us kernel: [<ffffffff813bb2ba>] complete_change_console+0x5a/0xe0 Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: [<ffffffff813bc31b>] vt_ioctl+0xfdb/0x1200 Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: [<ffffffff81194fb7>] ? do_wp_page+0x3b7/0x800 Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: [<ffffffffa00b4b63>] ? drm_ioctl+0x1a3/0x6a0 [drm] Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us kernel: [<ffffffffa00b9200>] ? drm_setmaster_ioctl+0xe0/0xe0 [drm] Jun 30 12:47:49 aspirebox.fcshome.stoneham.ma.us...