From mboxrd@z Thu Jan 1 00:00:00 1970 From: Francisco Jerez Subject: Re: deadlock possiblity introduced by "drm/nouveau: use drm_mm in preference to custom code doing the same thing" Date: Mon, 26 Jul 2010 19:15:47 +0200 Message-ID: <877hkii2po.fsf@riseup.net> References: <20100710232432.GA4137@joi.lan> <1278810132.2324.6.camel@nisroch> <20100726115933.GA2799@joi.lan> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0021559512==" Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Marcin Slusarz Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Dave Airlie List-Id: nouveau.vger.kernel.org --===============0021559512== Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Marcin Slusarz writes: > On Sun, Jul 11, 2010 at 11:02:12AM +1000, Ben Skeggs wrote: >> On Sun, 2010-07-11 at 01:24 +0200, Marcin Slusarz wrote: >> > Hi >> >=20 >> > Patch "drm/nouveau: use drm_mm in preference to custom code doing the = same thing" >> > in nouveau tree introduced new deadlock possibility, for which lockdep= complains loudly: >> >=20 >> > (...) >> >=20 >> Hey, >>=20 >> Thanks for the report, I'll look at this more during the week. >>=20 >> > Deadlock scenario looks like this: >> > CPU1 CPU2 >> > nouveau code calls some drm_mm.c >> > function which takes mm->unused_lock >> >=20 >> > nouveau_channel_free disab= les irqs and takes dev_priv->context_switch_lock >> > calls nv50= _graph_destroy_context which >> > (... backt= race above) >> > calls drm_= mm_put_block which tries to take mm->unused_lock (spins) >> > nouveau interrupt raises >> >=20 >> > nouveau_irq_handler tries to take >> > dev_priv->context_switch_lock (spins) >> >=20 >> > deadlock >> It's important to note that the drm_mm referenced eventually by >> nv50_graph_destroy_context is per-channel on the card, so for the >> deadlock to happen it'd have to be multiple threads from a single >> process, one thread creating/destroying and object on the channel while >> another was trying to destroy the channel. >>=20 Yeah, and that situation is impossible ATM because those functions are called with the BKL held. >> >=20 >> > Possible solutions: >> > - reverting "drm/nouveau: use drm_mm in preference to custom code doin= g the same thing" >> > - disabling interrupts before calling drm_mm functions - unmaintainabl= e and still >> > deadlockable in multicard setups (nouveau and eg radeon) >> Agreed it's unmaintainable, but, as mentioned above, the relevant locks >> can't be touched by radeon. >>=20 >> > - making mm->unused_lock HARDIRQ-safe (patch below) - simple but with = slight overhead >> I'll look more during the week, there's other solutions to be explored. > > So, did you find other solution? Some random ideas: - Make context_switch_lock HARDIRQ-unsafe. To avoid racing with the IRQ handler we'd have to disable interrupt dispatch on the card before taking context_switch_lock (i.e. at channel creation and destruction time), and the interrupt control registers would have to be protected with a IRQ safe spinlock. - Split the current destroy_context() hooks in two halves, the first one would be in charge of the PFIFO/PGRAPH-poking tasks (e.g. disable_context()), and the second one would take care of releasing the allocated resources (and it wouldn't need locking). > > Marcin > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAkxNwsQACgkQg5k4nX1Sv1vbRAEAh3/N/kyA1Ij0dk1aFoYl3Qu6 n7UKwH9Qk1JaWWgQDVkBAJDZu9ur27L+cGX50Y2ntzDRbVBKtpYvdhChEFtbHpIY =Bg1m -----END PGP SIGNATURE----- --==-=-=-- --===============0021559512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0021559512==--