search for: do_munmap

...7115b>] ? arch_local_irq_disable+0x7/0x8 [354008.101083] [<ffffffff81049f57>] ? do_exit+0x245/0x713 [354008.101088] [<ffffffff81039a92>] ? finish_task_switch+0x4e/0xb9 [354008.101093] [<ffffffff8134f0e9>] ? __schedule+0x5f9/0x610 [354008.101098] [<ffffffff810d5c58>] ? do_munmap+0x2da/0x2f3 [354008.101102] [<ffffffff8104a6a5>] ? do_group_exit+0x74/0x9e [354008.101107] [<ffffffff8104a6de>] ? sys_exit_group+0xf/0xf [354008.101112] [<ffffffff81355452>] ? system_call_fastpath+0x16/0x1b [354008.101115] Code: cc 51 41 53 b8 10 00 00 00 0f 05 41 5b 59 c3 cc c...

...cal_irq_disable+0x7/0x8 > [354008.101083] [<ffffffff81049f57>] ? do_exit+0x245/0x713 > [354008.101088] [<ffffffff81039a92>] ? finish_task_switch+0x4e/0xb9 > [354008.101093] [<ffffffff8134f0e9>] ? __schedule+0x5f9/0x610 > [354008.101098] [<ffffffff810d5c58>] ? do_munmap+0x2da/0x2f3 > [354008.101102] [<ffffffff8104a6a5>] ? do_group_exit+0x74/0x9e > [354008.101107] [<ffffffff8104a6de>] ? sys_exit_group+0xf/0xf > [354008.101112] [<ffffffff81355452>] ? system_call_fastpath+0x16/0x1b > [354008.101115] Code: cc 51 41 53 b8 10 00 00 00 0f...

These mappings are in fact special and require special handling in privcmd, which already exists. Failure to mark the PTE as special on arm64 causes all sorts of bad PTE fun. x86 already gets this correct. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: xen-devel@lists.xenproject.org --- arch/arm/xen/enlighten.c |

...unref+0x29/0x30 [ttm] Oct 10 10:36:18 adam.happyassassin.net kernel: [<ffffffffa008bd14>] ttm_bo_vm_close+0x34/0x60 [ttm] Oct 10 10:36:18 adam.happyassassin.net kernel: [<ffffffff811c6a72>] remove_vma+0x32/0x70 Oct 10 10:36:18 adam.happyassassin.net kernel: [<ffffffff811c9047>] do_munmap+0x247/0x440 Oct 10 10:36:18 adam.happyassassin.net kernel: [<ffffffff811c9281>] vm_munmap+0x41/0x60 Oct 10 10:36:18 adam.happyassassin.net kernel: [<ffffffff811ca2b2>] SyS_munmap+0x22/0x30 Oct 10 10:36:18 adam.happyassassin.net kernel: [<ffffffff81743469>] system_call_fastpath+...

...+ addr = vm_mmap(filp, addr, len, prot, flags, pgoff << PAGE_SHIFT); return IS_ERR_VALUE(addr) ? addr : 0; } @@ -230,8 +230,7 @@ addr = MMAP_VADDR(ring->user_vstart, request->usr_idx, 0); len = request->nr_pages << PAGE_SHIFT; - err = do_munmap(current->mm, addr, len); - + err = vm_munmap(addr, len); WARN_ON_ONCE(err); } -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) F...

...01 lh10 kernel: <ffffffff8016d921>{__vma_link+66} <ffffffff8016dd53>{vma_adjust+815} Mar 22 22:03:01 lh10 kernel: <ffffffff80165e4b>{__pagevec_mark_accessed+394} <ffffffff80166091>{lru_add_drain+91} Mar 22 22:03:01 lh10 kernel: <ffffffff8016e971>{do_munmap+355} <ffffffff8016f55e>{sys_brk+136} Mar 22 22:03:01 lh10 kernel: <ffffffff801102f6>{system_call+126} Mar 22 22:03:01 lh10 kernel: Trying to fix it up, but a reboot is needed star had been running about 20 to 30 minutes at the time of the crash. I have seen two or three crashe...

...b79cd000 d1d5b134 b79cd000 c015a7e3 c13eef00 d1d5b134 b79cc000 b79cd000 00000000 Call Trace: [<c015a487>] zap_pte_range+0x1a7/0x280 [<c015a5e5>] unmap_page_range+0x85/0xc0 [<c015a7e3>] unmap_vmas+0x1c3/0x290 [<c015f8f5>] unmap_region+0xb5/0x170 [<c015fc87>] do_munmap+0x107/0x150 [<c015fd2a>] sys_munmap+0x5a/0x80 [<c0109493>] syscall_call+0x7/0xb I suspect the oops in set_page_dirty is because of either a junk page->mapping pointer, or a junk mapping->aops pointer, since neither are touched by the code that maps the page into the VMA: int f...

...rror_interval_invalidate+0x7d/0xc0 [test_hmm] [ 138.074174] __mmu_notifier_release+0x1a6/0x370 [ 138.078714] ? mmu_notifier_unregister+0x1e0/0x1e0 [ 138.083520] ? lock_downgrade+0x380/0x380 [ 138.087535] ? uprobe_clear_state+0x2e/0x150 [ 138.091823] exit_mmap+0x24d/0x2a0 [ 138.095229] ? do_munmap+0x10/0x10 [ 138.098635] ? __x64_sys_io_setup+0x200/0x200 [ 138.102995] ? __mutex_unlock_slowpath+0xb4/0x3f0 [ 138.107704] ? wait_for_completion+0x250/0x250 [ 138.112158] ? lock_downgrade+0x380/0x380 [ 138.116176] ? check_flags.part.0+0x82/0x210 [ 138.120463] mmput+0xb5/0x210 [ 138.1234...

On 3/17/20 5:59 AM, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote: >> I've been using v7 of Ralph's tester and it is working well - it has >> DEVICE_PRIVATE support so I think it can test this flow too. Ralph are >> you able? >> >> This hunk seems trivial enough to me, can we include it now? > > I can send

...Dock (Docking Station). My OS is Debian Buster (Debian Testing). When using Nouveau and i915 as drivers while using both graphic cards, a kernel error occurs (bios is set to hybrid graphics): ---[ end trace 0f5b1e9bbdb82fb3 ]--- ? system_call_fast_compare_end+0xc/0x9b ? SyS_ioctl+0x74/0x80 ? do_munmap+0x353/0x430 ? do_vfs_ioctl+0x9f/0x600 ? nouveau_drm_ioctl+0x66/0xc0 [nouveau] ? signal_setup_done+0x67/0xb0 ? drm_gem_handle_create+0x40/0x40 [drm] ? drm_ioctl+0x1ef/0x440 [drm] ? drm_gem_handle_delete+0x57/0x80 [drm] ? drm_gem_object_release_handle+0x50/0x90 [drm] ? nouveau_gem_object_del+...

Hi, This is a proof of concept of GPU forwarding for Linux guest on Linux host. I'd like to get comments and suggestions from community before I put more time on it. To summarize what it is: 1. It's a solution to bring GPU acceleration for Linux vm guest on Linux host. It could works with different GPU although the current proof of concept only works with Intel GPU. 2. The basic idea

https://bugs.freedesktop.org/show_bug.cgi?id=59069 Priority: medium Bug ID: 59069 Assignee: nouveau at lists.freedesktop.org Summary: nouveau E[ DRM] fail ttm_validate QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: Linux (All) Reporter: kees.bakker at xs4all.nl

Greetings, Last night I manually unpresented and deleted a LUN (a SAN snapshot) that was presented to one node in a four node RAC environment running OCFS2 v1.4.1-1. The system then rebooted with the following error: Oct 21 16:45:34 ausracdb03 kernel: (27,1):o2hb_write_timeout:166 ERROR: Heartbeat write timeout to device dm-24 after 120000 milliseconds Oct 21 16:45:34 ausracdb03 kernel:

...56.582180] nouveau_bo_del_ttm+0x7f/0x90 [nouveau] [ 56.582184] ttm_bo_release_list+0xdb/0x210 [ttm] [ 56.582188] ttm_bo_release+0x23d/0x340 [ttm] [ 56.582191] ttm_bo_unref+0x24/0x30 [ttm] [ 56.582194] ttm_bo_vm_close+0x34/0x60 [ttm] [ 56.582197] remove_vma+0x45/0x80 [ 56.582199] do_munmap+0x2b2/0x460 [ 56.582201] SyS_munmap+0x53/0x70 [ 56.582204] entry_SYSCALL_64_fastpath+0x1f/0xc2 [ 56.582205] RIP: 0033:0x7f989734d237 [ 56.582206] RSP: 002b:00007fffe1fb82f8 EFLAGS: 00003206 ORIG_RAX: 000000000000000b [ 56.582208] RAX: ffffffffffffffda RBX: 000000000165d170 RCX: 00007f98...

...2311.861269] Call Trace: Jul 20 20:14:16 placka kernel: [ 2311.861269] [<ffffffff810d0b19>] ? unmap_vmas+0x4e2/0x6ca Jul 20 20:14:16 placka kernel: [ 2311.861269] [<ffffffff810d4b40>] ? unmap_region+0x9f/0xf1 Jul 20 20:14:16 placka kernel: [ 2311.861269] [<ffffffff810d5c10>] ? do_munmap+0x292/0x2f3 Jul 20 20:14:16 placka kernel: [ 2311.861269] [<ffffffff810d647b>] ? sys_brk+0xa6/0xfc Jul 20 20:14:16 placka kernel: [ 2311.861269] [<ffffffff81355592>] ? system_call_fastpath+0x16/0x1b Jul 20 20:14:16 placka kernel: [ 2311.861269] Code: 08 75 4c 48 8b 47 10 48 8b 00 48 8...

Greetings, I got the below dmesg and the first bad commit is commit cf39c8e5352b4fb9efedfe7e9acb566a85ed847c Merge: 3398d25 23b7eaf Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Sep 4 17:45:39 2013 -0700 Merge tag ''stable/for-linus-3.12-rc0-tag'' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull Xen updates from Konrad