From owner-freebsd-x11@FreeBSD.ORG Thu Nov 11 11:27:53 2010 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44DD1106566B; Thu, 11 Nov 2010 11:27:53 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 47EF08FC25; Thu, 11 Nov 2010 11:27:51 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA11008; Thu, 11 Nov 2010 13:27:49 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PGVJl-000EhC-7i; Thu, 11 Nov 2010 13:27:49 +0200 Message-ID: <4CDBD333.5040007@freebsd.org> Date: Thu, 11 Nov 2010 13:27:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD9139D.9060302@freebsd.org> <20101109140518.GV2392@deviant.kiev.zoral.com.ua> <4CDA2B3E.9030402@freebsd.org> <20101110083408.GC2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101110083408.GC2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 11:27:53 -0000 on 10/11/2010 10:34 Kostik Belousov said the following: > On Wed, Nov 10, 2010 at 07:18:54AM +0200, Andriy Gapon wrote: >> on 09/11/2010 16:05 Kostik Belousov said the following: >>> Easiest would be for DRM to provide wrappers for copyin/copyout that >>> unlock, do operation and lock. >> >> I am a little bit worried about this approach in general. >> Driver state may be changed by a process running in parallel while the lock is >> dropped. And I don't think that we have any mechanism in DRM to check for that >> and to restart operations or otherwise account for the state change. The code >> seems to be written with an assumption that it runs in exclusive mode from DRM >> ioctl start to its completion. >> >>> Where is the reverse order (user map -> drm) ? >> >> You mean the following or the opposite? >> >> 1st 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:791 >> 2nd 0xffffff000a621510 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 >> KDB: stack backtrace: >> db_trace_self_wrapper() at 0xffffffff801b8b3a = db_trace_self_wrapper+0x2a >> kdb_backtrace() at 0xffffffff803a7a8a = kdb_backtrace+0x3a >> _witness_debugger() at 0xffffffff803bd42c = _witness_debugger+0x2c >> witness_checkorder() at 0xffffffff803be899 = witness_checkorder+0x959 >> _sx_slock() at 0xffffffff80378af8 = _sx_slock+0x88 >> _vm_map_lock_read() at 0xffffffff80510a06 = _vm_map_lock_read+0x36 >> vm_map_lookup() at 0xffffffff805127d4 = vm_map_lookup+0x54 >> vm_fault() at 0xffffffff80509819 = vm_fault+0xf9 >> trap_pfault() at 0xffffffff80545d6f = trap_pfault+0x11f >> trap() at 0xffffffff805465f7 = trap+0x657 >> calltrap() at 0xffffffff80530628 = calltrap+0x8 >> --- trap 0xc, rip = 0xffffffff805440bd, rsp = 0xffffff8123fe37f0, rbp = >> 0xffffff8123fe3870 --- >> copyin() at 0xffffffff805440bd = copyin+0x3d >> radeon_cp_texture() at 0xffffffff8022fbd7 = radeon_cp_texture+0x167 >> drm_ioctl() at 0xffffffff8020fa38 = drm_ioctl+0x318 >> devfs_ioctl_f() at 0xffffffff802dd649 = devfs_ioctl_f+0x109 >> kern_ioctl() at 0xffffffff803c1127 = kern_ioctl+0x1f7 >> ioctl() at 0xffffffff803c12e8 = ioctl+0x168 >> syscallenter() at 0xffffffff803b57de = syscallenter+0x26e >> syscall() at 0xffffffff80545eb2 = syscall+0x42 >> Xfast_syscall() at 0xffffffff80530902 = Xfast_syscall+0xe2 >> >> If you meant the opposite order, how can I check it? >> I guess that it could be in a mmap() call for drm cdev. > > Explicitely insert the reversed order into the witness array and watch. Here it is: lock order reversal: 1st 0xffffff0001a51b30 user map (user map) @ /usr/src/sys/vm/vm_map.c:1400 2nd 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_vm.c:84 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801b8b3a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff803a7a8a = kdb_backtrace+0x3a _witness_debugger() at 0xffffffff803bd42c = _witness_debugger+0x2c witness_checkorder() at 0xffffffff803be899 = witness_checkorder+0x959 _sx_xlock() at 0xffffffff803789b8 = _sx_xlock+0x88 drm_mmap() at 0xffffffff8021587a = drm_mmap+0x18a dev_pager_getpages() at 0xffffffff804fdcce = dev_pager_getpages+0xce vm_object_populate() at 0xffffffff80515c2f = vm_object_populate+0x9f pmap_object_init_pt() at 0xffffffff8053d600 = pmap_object_init_pt+0xa0 vm_map_pmap_enter() at 0xffffffff8050f1b7 = vm_map_pmap_enter+0x97 vm_map_insert() at 0xffffffff8050fa5d = vm_map_insert+0x45d vm_map_find() at 0xffffffff8051097d = vm_map_find+0xdd vm_mmap() at 0xffffffff80514158 = vm_mmap+0x578 mmap() at 0xffffffff80514903 = mmap+0x383 syscallenter() at 0xffffffff803b57de = syscallenter+0x26e syscall() at 0xffffffff80545f92 = syscall+0x42 Xfast_syscall() at 0xffffffff805309e2 = Xfast_syscall+0xe2 -- Andriy Gapon