From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 05:18:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A7C4106566B; Wed, 10 Nov 2010 05:18:59 +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 28BA18FC15; Wed, 10 Nov 2010 05:18:57 +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 HAA09247; Wed, 10 Nov 2010 07:18:55 +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 1PG35C-000Abe-Vx; Wed, 10 Nov 2010 07:18:55 +0200 Message-ID: <4CDA2B3E.9030402@freebsd.org> Date: Wed, 10 Nov 2010 07:18:54 +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> In-Reply-To: <20101109140518.GV2392@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-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:18:59 -0000 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. -- Andriy Gapon