From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 00/18] dev->struct_mutex crusade Date: Mon, 10 Aug 2015 13:35:58 +0200 Message-ID: <20150810113556.GT1262@ulmo.nvidia.com> References: <1436477570-4936-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1755878946==" Return-path: In-Reply-To: <1436477570-4936-1-git-send-email-daniel.vetter@ffwll.ch> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Intel Graphics Development , DRI Development List-Id: dri-devel@lists.freedesktop.org --===============1755878946== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4Kq+wHeKEs1nwG7z" Content-Disposition: inline --4Kq+wHeKEs1nwG7z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 09, 2015 at 11:32:32PM +0200, Daniel Vetter wrote: > Hi all, >=20 > I wanted to take another look at struct_mutex usage in modern (gem) drive= rs and > noticed that for a fair lot we're very to be completely struct_mutex free. >=20 > This pile here is the the simple part, which mostly just removes code and > mutex_lock/unlock calls. All the patches here are independent and can be = merged > in any order whatsoever. My plan is to send out a pull request for all th= ose not > picked up by driver maintainers in 2-3 weeks or so, assuming no one compl= ains. >=20 > Of course review & comments still very much welcome. >=20 > The more tricky 2nd part of this (and that one's not yet done) is to rewo= rk the > gem mmap handler to use the same kref_get_unless_zero trick as ttm. With = that > there's no core requirement to hold struct_mutex over the final unref, wh= ich > means we can make that one lockless. I plan to add a gem_object_free_unlo= cked > for all the drivers which don't have any need for this lock. >=20 > Also there's a few more drivers which can be made struct_mutex free easil= y, I'll > propably stitch together poc patches for those. There's a concurrency bug in Tegra DRM currently because we don't lock accesses to drm_mm (I guess this demonstrates how badly we need better testing...) and it seems like this is typically protected by the very same struct_mutex that you're on a crusade to remove. If your goal is to get rid of it for good, should we simply add a separate lock just for the drm_mm? We don't have another one that would fit. Thierry --4Kq+wHeKEs1nwG7z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJVyIycAAoJEN0jrNd/PrOh1lIQAIzKOdlNyLg3eQEWQH6EIFWN XMxPPWqyiX45RF+I8xXXJJvKOJ50QEvJzfYM1ciDr0GzteyS6kb9OCjmVBeUW0U9 C5PtmG1muuy2o7rJgKUOdm9+1V0GaedXyoRbmLfN/4joMYQOlx2R8w0RthN9Gi6n 0Kdiw+rUTTCwM/L19HH66aqS09631nU2CqhHCpLpTonR47M/R1+eTDcP/9oJ5v6Q IX4pamNWz8XniNAmmdToGEmR7c9ixUEalzWw2bA/kABI5JOCe3MAprVbjlXoEjvu s5DC4eviN3SeLw1HI3ocp4Os/HLm/LpBNPhZ03twWkva1bmQli8QbtlWPfHdJ7eW zj8KCCxsWUxEtb3CwqY6OuNvhitNZpkxEB3WsfMT66cSXSG83sivj8l604gBPmf7 GR5JxD5wmveinNm6ECx85XBF3sWa+C+bk+VploaeU3j7HB+R6w8bF77GbLFowaw3 DZMTlDBNKfxDvRPCi7IBGATEc0r9V7bRl6qQFtFByyOzBoe9X2nGxMF5/qe/3yyz UL7AcklevGlA1G0Q6ukuHGdapVKt0/whCsnTxCn3RmW2KdixpKUqC+PhV84YUwh8 qp6iEB4CderoqmV7e/86ATPkH2L/AvUO2cHpsHzV5iGTFKg95mAUl15XWPP6jDf7 MKnzwgmLd+XI5w536GKT =jwdR -----END PGP SIGNATURE----- --4Kq+wHeKEs1nwG7z-- --===============1755878946== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZngK --===============1755878946==--