Date: Wed, 10 Nov 2010 10:34:08 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held Message-ID: <20101110083408.GC2392@deviant.kiev.zoral.com.ua> In-Reply-To: <4CDA2B3E.9030402@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzaWP8ACgkQC3+MBN1Mb4h4ugCcDp3xrnYTuWHdQZYtdlk1D78A kPMAnRQ4Kr+WltgIDSyaNiKGb7vExGe3 =VeFf -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101110083408.GC2392>