From owner-freebsd-x11@FreeBSD.ORG Wed Nov 10 08:34:12 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 4EF251065672; Wed, 10 Nov 2010 08:34:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D887C8FC12; Wed, 10 Nov 2010 08:34:11 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oAA8Y8JP000677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2010 10:34:08 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oAA8Y8p0036569; Wed, 10 Nov 2010 10:34:08 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oAA8Y8T8036568; Wed, 10 Nov 2010 10:34:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Nov 2010 10:34:08 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20101110083408.GC2392@deviant.kiev.zoral.com.ua> 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yOV8wujajMQrgQLM" Content-Disposition: inline In-Reply-To: <4CDA2B3E.9030402@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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: Wed, 10 Nov 2010 08:34:12 -0000 --yOV8wujajMQrgQLM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > I am a little bit worried about this approach in general. > Driver state may be changed by a process running in parallel while the lo= ck is > dropped. And I don't think that we have any mechanism in DRM to check fo= r 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 fro= m DRM > ioctl start to its completion. >=20 > > Where is the reverse order (user map -> drm) ? >=20 > You mean the following or the opposite? >=20 > 1st 0xffffff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:7= 91 > 2nd 0xffffff000a621510 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801b8b3a =3D db_trace_self_wrapper+0= x2a > kdb_backtrace() at 0xffffffff803a7a8a =3D kdb_backtrace+0x3a > _witness_debugger() at 0xffffffff803bd42c =3D _witness_debugger+0x2c > witness_checkorder() at 0xffffffff803be899 =3D witness_checkorder+0x959 > _sx_slock() at 0xffffffff80378af8 =3D _sx_slock+0x88 > _vm_map_lock_read() at 0xffffffff80510a06 =3D _vm_map_lock_read+0x36 > vm_map_lookup() at 0xffffffff805127d4 =3D vm_map_lookup+0x54 > vm_fault() at 0xffffffff80509819 =3D vm_fault+0xf9 > trap_pfault() at 0xffffffff80545d6f =3D trap_pfault+0x11f > trap() at 0xffffffff805465f7 =3D trap+0x657 > calltrap() at 0xffffffff80530628 =3D calltrap+0x8 > --- trap 0xc, rip =3D 0xffffffff805440bd, rsp =3D 0xffffff8123fe37f0, rbp= =3D > 0xffffff8123fe3870 --- > copyin() at 0xffffffff805440bd =3D copyin+0x3d > radeon_cp_texture() at 0xffffffff8022fbd7 =3D radeon_cp_texture+0x167 > drm_ioctl() at 0xffffffff8020fa38 =3D drm_ioctl+0x318 > devfs_ioctl_f() at 0xffffffff802dd649 =3D devfs_ioctl_f+0x109 > kern_ioctl() at 0xffffffff803c1127 =3D kern_ioctl+0x1f7 > ioctl() at 0xffffffff803c12e8 =3D ioctl+0x168 > syscallenter() at 0xffffffff803b57de =3D syscallenter+0x26e > syscall() at 0xffffffff80545eb2 =3D syscall+0x42 > Xfast_syscall() at 0xffffffff80530902 =3D Xfast_syscall+0xe2 >=20 > 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. --yOV8wujajMQrgQLM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzaWP8ACgkQC3+MBN1Mb4h4ugCcDp3xrnYTuWHdQZYtdlk1D78A kPMAnRQ4Kr+WltgIDSyaNiKGb7vExGe3 =VeFf -----END PGP SIGNATURE----- --yOV8wujajMQrgQLM--