From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers" Date: Thu, 31 May 2018 10:51:13 -0700 Message-ID: <87po1br9wu.fsf@anholt.net> References: <20180519065243.27600-1-yuq825@gmail.com> <20180519065243.27600-6-yuq825@gmail.com> <874lj0u7fn.fsf@anholt.net> <20180523090439.GS3438@phenom.ffwll.local> <20180524075134.GA3438@phenom.ffwll.local> <87zi0hhv0l.fsf@anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1216691795==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 265BF6E4EF for ; Thu, 31 May 2018 17:51:16 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Qiang Yu Cc: Simon Shields , Marek Vasut , Connor Abbott , Neil Armstrong , Andrei Paulau <7134956@gmail.com>, dri-devel , Vasily Khoruzhick , Erico Nunes List-Id: dri-devel@lists.freedesktop.org --===============1216691795== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Qiang Yu writes: >>> >>> It is OK if evil user free/unmap the buffer when task is not done >>> in my implementation. It will generate a MMU fault in that case and kernel >>> driver will do recovery. >>> >>> So does the Ctrl+C case, if don't deal with it, just get some noisy MMU >>> fault warning and a HW reset recovery. >> >> How about an app rendering to shared buffers, which glFlush()es and >> exits cleanly but doesn't close the DRI screen? What would cause that >> app's rendering to get completed succesfully instead of faulting to >> death? > Do you mean the same case as Ctrl+C when an app exit without waiting > all task finished in userspace? Basically the same, but I'm saying that the app is doing everything right and terminating successfully, rather than being interrupted (which you might otherwise use to justify its rendering failing) >> You really do need to refcount the buffers used in a rendering job so >> they don't get freed early. > Do you mean refcount the buffers in kernel space job? This is OK but > not necessary, I can wait task complete in gem_close_object which > will be called by drm_release for each buffer too (I still think better > waiting in preclose at once but it's gone). Just wait for all tasks to complete when any object is freed? That's going to be bad for performance. Or are you saying that you already have the connection between the task and its objects (and, if so, why aren't you just doing refcounting correctly through that path?) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlsQNhIACgkQtdYpNtH8 nuio/w//cw+n4KvD0Ry3wgfOMBtoV2x9Cad3ZTt6HRwkR2+wjgPpCDxBUzb1Wm40 j8c75NyKWh8Tg9aGTroWgnJ5yme38jFQBIosPOJvhMKNQynrKDCYL33wlj6xHBgE pHq0VT/5kChdan/TQbfEaEadXY+vdDieNVrgSBZQdtWeC04xR1Y+ME7KXE0Lmpx1 m9+WLZ9ooqxcwk910vwHvlWEyE5KYcLgWE2oROwvdIubTMUBJZcRqRsxTyKWg/PH LfUXltZdteyoNGy6f53PQoPNCt5CY3SupWaThykeq/JHo439MMJNuyeN8V9bbwYX wZzfU/aOtnB4SuvZJv37LFt55es/XdeaMnt6smPsO5CAAm+2KraGM+iP7kx7YF30 ViL/eAY0FOmn+rVocw7LzQhmRK84I7NZLzXqQo5y487WzbK8XEOvVAutQHmBrAwG a9SIBC0Z783xeInHlpSoDqseUBBaDFDNXLieG5GZ8UVrGXT0jdOqkZErDAYnGXwJ cG0iYxzoUWmtnbICH0wcqGOeXk1Om56ZaFZu7GsZVaziREC+jOJm6iip+fEaddF0 PoeyR2iqUlAHBH1Djz23WTppqEdIMbbhqtLuwBzesVdMPqbhd0VuZdj9x6ZFsBxM kOTNzd4+2dqmzx4PaAbTAP8Np2vLMY6bqHfqr2XJvQJ+fQoOwLE= =ZJ1x -----END PGP SIGNATURE----- --=-=-=-- --===============1216691795== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1216691795==--