search for: exit_mm

...t;] ? release_pages+0xf4/0x14d [354008.101038] [<ffffffff810de78b>] ? free_pages_and_swap_cache+0x48/0x60 [354008.101045] [<ffffffff810cf527>] ? tlb_flush_mmu+0x37/0x50 [354008.101049] [<ffffffff810cf54c>] ? tlb_finish_mmu+0xc/0x31 [354008.101054] [<ffffffff810d5e79>] ? exit_mmap+0xc4/0xe9 [354008.101060] [<ffffffff81044b82>] ? mmput+0x56/0xf8 [354008.101064] [<ffffffff81049d07>] ? exit_mm+0x117/0x122 [354008.101069] [<ffffffff8107115b>] ? arch_local_irq_disable+0x7/0x8 [354008.101074] [<ffffffff81350487>] ? _raw_spin_lock_irq+0xa/0x14 [354008....

On 2018/12/13 ??12:47, gchen.guomin at gmail.com wrote: > From: guomin chen <gchen.guomin at gmail.com> > > Under normal circumstances,When do_exit exits, mm->owner will > be updated on exit_mm(). but when the kernel process calls > unuse_mm() and then exits,mm->owner cannot be updated. And it > will point to a task that has been released. > > Below is my issue on vhost_net: > A, B are two kernel processes(such as vhost_worker), > C is a user space pro...

...<%p/%d>\n", > - dead_task->comm, > - dead_task->mm->context.ldt, > - dead_task->mm->context.size); > - BUG(); > - } > - } > - > + BUG_ON(dead_task->mm); This BUG_ON() has different semantics than old dead one. Is there a point? exit_mm() has already reset this to NULL, no? > release_vm86_irqs(dead_task); > }

...<%p/%d>\n", > - dead_task->comm, > - dead_task->mm->context.ldt, > - dead_task->mm->context.size); > - BUG(); > - } > - } > - > + BUG_ON(dead_task->mm); This BUG_ON() has different semantics than old dead one. Is there a point? exit_mm() has already reset this to NULL, no? > release_vm86_irqs(dead_task); > }

...0x14d > [354008.101038] [<ffffffff810de78b>] ? > free_pages_and_swap_cache+0x48/0x60 > [354008.101045] [<ffffffff810cf527>] ? tlb_flush_mmu+0x37/0x50 > [354008.101049] [<ffffffff810cf54c>] ? tlb_finish_mmu+0xc/0x31 > [354008.101054] [<ffffffff810d5e79>] ? exit_mmap+0xc4/0xe9 > [354008.101060] [<ffffffff81044b82>] ? mmput+0x56/0xf8 > [354008.101064] [<ffffffff81049d07>] ? exit_mm+0x117/0x122 > [354008.101069] [<ffffffff8107115b>] ? arch_local_irq_disable+0x7/0x8 > [354008.101074] [<ffffffff81350487>] ? _raw_spin_lock_i...

...em work stable in PAE mode. Havn''t seen problems without PAE, not sure whenever thats just pure luck or whenever there is a bug in my PAE xenlinux kernel. To me it looks like a generic bug though. I''ve actually trapped into problems with unpin only: A process exits, somewhere in exit_mm() the page tables are unpinned, shortly thereafter the mappings are cleared. While doing so the kernel oopses in zap_pte_range(), on page table write access. Probably due to some stale tlb entry where the page is still tagged read-only. cheers, Gerd Index: linux-2.6.11/arch/xen/i386/mm/pgtable...

Hi Xen folks! I''ve faced with one strange thing in ARM version of Xen: when I use xc_map_foreign_bulk() to map some memory from domU to dom0, after unmap() for previous returned address - memory is not freed at all. Let''s look at call stack: xc_map_foreign() -> linux_privcmd_map_foreign_bulk() -> { addr = mmap(fd); ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2 );

...kernel: Call Trace: Jul 11 10:14:01 mail kernel: [<c1078901>] ? print_bad_pte+0x13a/0x14b Jul 11 10:14:01 mail kernel: [<c107b206>] ? unmap_vmas+0x33b/0x62d Jul 11 10:14:01 mail kernel: [<c10272cc>] ? try_to_wake_up+0x206/0x210 Jul 11 10:14:01 mail kernel: [<c107ccc7>] ? exit_mmap+0x8c/0x107 Jul 11 10:14:01 mail kernel: [<c102976f>] ? mmput+0x1c/0x8c Jul 11 10:14:01 mail kernel: [<c102c850>] ? exit_mm+0xdc/0xe4 Jul 11 10:14:01 mail kernel: [<c103da3c>] ? hrtimer_try_to_cancel+0x55/0x5b Jul 11 10:14:01 mail kernel: [<c104dd0d>] ? acct_collect+0x7...

...00007fda18005018 CR3: 0000000001001000 CR4: 0000000000002660 [22077.213294] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [22077.213353] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [22077.213412] Call Trace: [22077.213466]  [<ffffffff8100dcff>] ? xen_exit_mmap+0xf8/0x136 [22077.213524]  [<ffffffff8100922a>] ? hypercall_page+0x22a/0x1001 [22077.213583]  [<ffffffff810d1000>] ? exit_mmap+0x5a/0x148 [22077.213641]  [<ffffffff8104b6f1>] ? __cond_resched+0x1d/0x26 [22077.213698]  [<ffffffff8104c9e9>] ? mmput+0x3c/0xdf [22077.213754] ...

...20 [1527071.224008] [<ffffffffa02a92a5>] ? blktap_device_end_request+0xbd/0x145 [blktap] [1527071.224008] [<ffffffffa02a7743>] ? blktap_ring_vm_close+0x60/0xd1 [blktap] [1527071.224008] [<ffffffff810d1394>] ? remove_vma+0x2c/0x72 [1527071.224008] [<ffffffff810d1503>] ? exit_mmap+0x129/0x148 [1527071.224008] [<ffffffff8104cc75>] ? mmput+0x3c/0xdf [1527071.224008] [<ffffffff8105087a>] ? exit_mm+0x102/0x10d [1527071.224008] [<ffffffff8132448a>] ? _spin_lock_irq+0x7/0x22 [1527071.224008] [<ffffffff810522a3>] ? do_exit+0x1f8/0x6c6 [1527071.224008]...

...[<ffffffff810dfd22>] __fput+0x18a/0x197 [<ffffffff810dfd47>] fput+0x18/0x1a [<ffffffff810c0ae1>] remove_vma+0x4f/0x85 [<ffffffff810c0c32>] exit_mmap+0x11b/0x13d [<ffffffff8104800f>] mmput+0x45/0xa4 [<ffffffff8104bf97>] exit_mm+0x114/0x120 [<ffffffff8104dc12>] do_exit+0x1da/0x8b4...

...e+0x1d5/0x280 Dec 18 23:32:21 userimap1 kernel: [263492.282448] [<ffffffff8110568a>] unmap_vmas+0xa1a/0xa20 Dec 18 23:32:21 userimap1 kernel: [263492.282458] [<ffffffff8137e501>] ? sch_direct_xmit+0x81/0x1d0 Dec 18 23:32:21 userimap1 kernel: [263492.282465] [<ffffffff8110b60d>] exit_mmap+0xbd/0x190 Dec 18 23:32:21 userimap1 kernel: [263492.282473] [<ffffffff81059cbd>] mmput+0x4d/0x120 Dec 18 23:32:21 userimap1 kernel: [263492.282481] [<ffffffff8105f282>] exit_mm+0x112/0x150 Dec 18 23:32:21 userimap1 kernel: [263492.282488] [<ffffffff8106104d>] do_exit+0x13d/0...

...931 May 19 12:19:19 ip-10-234-90-180 kernel: [<c01052ab>] error_code+0x2b/0x30 May 19 12:19:19 ip-10-234-90-180 kernel: [<c011bd9b>] __mmdrop+0x1b/0x50 May 19 12:19:19 ip-10-234-90-180 kernel: [<c011be50>] mmput+0x80/0xa0 May 19 12:19:19 ip-10-234-90-180 kernel: [<c011fdd0>] exit_mm+0x80/0x100 May 19 12:19:19 ip-10-234-90-180 kernel: [<c0120bc3>] do_exit+0xf3/0x8f0 May 19 12:19:19 ip-10-234-90-180 kernel: [<c01213fb>] do_group_exit+0x3b/0xd0 May 19 12:19:19 ip-10-234-90-180 kernel: [<c01214a5>] sys_exit_group+0x15/0x20 May 19 12:19:19 ip-10-234-90-180 kernel:...

...nux-2.6/kernel/exit.c =================================================================== --- linux-2.6.orig/kernel/exit.c 2007-06-13 20:30:15.000000000 -0400 +++ linux-2.6/kernel/exit.c 2007-06-25 13:50:32.000000000 -0400 @@ -943,6 +943,7 @@ taskstats_exit(tsk, group_dead); + exit_as(tsk); exit_mm(tsk); if (group_dead) Index: linux-2.6/mm/multias.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6/mm/multias.c 2007-06-26 07:05:21.000000000 -0400 @@ -0,0 +1,87 @@ +#include <linux/sched.h> +#include &lt...

...nux-2.6/kernel/exit.c =================================================================== --- linux-2.6.orig/kernel/exit.c 2007-06-13 20:30:15.000000000 -0400 +++ linux-2.6/kernel/exit.c 2007-06-25 13:50:32.000000000 -0400 @@ -943,6 +943,7 @@ taskstats_exit(tsk, group_dead); + exit_as(tsk); exit_mm(tsk); if (group_dead) Index: linux-2.6/mm/multias.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6/mm/multias.c 2007-06-26 07:05:21.000000000 -0400 @@ -0,0 +1,87 @@ +#include <linux/sched.h> +#include &lt...

changeset: 8830:fcc833cbaf82 tag: tip user: kaf24@firebug.cl.cam.ac.uk date: Mon Feb 13 10:41:23 2006 +0100 summary: Return real error code from Xen /dev/mem, not EAGAIN. x460: x86_32: Status: - dom0 boots fine - xend loads fine - single HVM domain loads fine - Multiple HVM domains load fine - destruction of any HVM domain causes dom0 to reboot Issues affecting

...[<ffffffff81145fa7>] __fput +0xe7/0x1f0 Sep 17 15:26:18 box6 kernel: [ 1948.826504] [<ffffffff811460d5>] fput +0x25/0x30 Sep 17 15:26:18 box6 kernel: [ 1948.826514] [<ffffffff81117efc>] remove_vma+0x3c/0x80 Sep 17 15:26:18 box6 kernel: [ 1948.826522] [<ffffffff81118038>] exit_mmap+0xf8/0x190 Sep 17 15:26:18 box6 kernel: [ 1948.826530] [<ffffffff81064bf2>] mmput +0x42/0x110 Sep 17 15:26:18 box6 kernel: [ 1948.826539] [<ffffffff8106b072>] exit_mm+0x112/0x150 Sep 17 15:26:18 box6 kernel: [ 1948.826547] [<ffffffff8155aa55>] ? _spin_lock_irq+0x15/0x20 Sep 1...

...call_page+0x22a/0x1000 Jul 17 06:25:51 placka kernel: [34973.949874] [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000 Jul 17 06:25:51 placka kernel: [34973.952119] [<ffffffff81044c7b>] ? mm_release+0x20/0xe0 Jul 17 06:25:51 placka kernel: [34973.954394] [<ffffffff81049c0c>] ? exit_mm+0x1c/0x122 Jul 17 06:25:51 placka kernel: [34973.956698] [<ffffffff8107115b>] ? arch_local_irq_disable+0x7/0x8 Jul 17 06:25:51 placka kernel: [34973.958961] [<ffffffff81049f57>] ? do_exit+0x245/0x713 Jul 17 06:25:51 placka kernel: [34973.961248] [<ffffffff8107115b>] ? arch_loca...

Hi everyone, I am very excited to see that dom0 pvops is finally coming close to working, so I wanted to give it a try. >From the description it was not clear to me which kernel to chose as base for the patches.hg, so I took the latest (that was ~ 2 weeks ago) kernel on git.kernel.org I could find (post-2.6.28 git tip at that point). I managed to more or less apply all of the patches in the

...621d4>] ? _cond_resched+0x12/0x1c [ 316.639675] [<ffffffff810d79ab>] ? unmap_single_vma+0x57e/0x620 [ 316.639683] [<ffffffff810c4e47>] ? del_page_from_lru_list+0x73/0x73 [ 316.639688] [<ffffffff810d812f>] ? unmap_vmas+0x58/0x9c [ 316.639694] [<ffffffff810dd0d8>] ? exit_mmap+0x8f/0xd9 [ 316.639700] [<ffffffff8103744a>] ? mmput+0x51/0xf8 [ 316.639706] [<ffffffff8103ccbe>] ? exit_mm+0x10e/0x119 [ 316.639711] [<ffffffff8103cf0d>] ? do_exit+0x244/0x7da [ 316.639717] [<ffffffff8136299c>] ? _raw_spin_lock_irqsave+0x1c/0x41 [ 316.639722] [&...