From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage Date: Wed, 22 Nov 2017 13:16:08 -0800 Message-ID: <8760a2ko9z.fsf@anholt.net> References: <20171122203928.28135-1-boris.brezillon@free-electrons.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0647254219==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 556066E6B5 for ; Wed, 22 Nov 2017 21:16:12 +0000 (UTC) In-Reply-To: <20171122203928.28135-1-boris.brezillon@free-electrons.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Cc: David Airlie , Stefan Wahren , dri-devel@lists.freedesktop.org, Boris Brezillon List-Id: dri-devel@lists.freedesktop.org --===============0647254219== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Boris Brezillon writes: > With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's > passed a refcount object that has its counter set to 0. In this driver, > this is a valid use case since we want to increment ->usecnt only when > the BO object starts to be used by real HW components and this is > definitely not the case when the BO is created. > > Fix the problem by using refcount_inc_not_zero() instead of > refcount_inc() and fallback to refcount_set(1) when > refcount_inc_not_zero() returns false. Note that this 2-steps operation > is not racy here because the whole section is protected by a mutex > which guarantees that the counter does not change between the > refcount_inc_not_zero() and refcount_set() calls. If we're not following the model, and protecting the refcount by a mutex, shouldn't we just be using addition and subtraction instead of refcount's atomics? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAloV6RgACgkQtdYpNtH8 nujVuQ//T6QLJsRRysL6lpQduPJe42Wbjhw1hczANwKCSHYcj3SZ51RJ/IusKSS9 zZ9yArbzXcWCGvWEMsuQLxcKjliuHhaL9AvzIdnsTYpJGUrwi51cAR5GpuN1f1Dq B3GVFNBlWHiFK5Fx/Q6cZbRQLCz4+7NsUgIhXooPn6TyJlhqLNOPi71avfXeuqeM nzY6ALoyVhwqGOPGnJI4cH8WIFDXowtoSdCgVJdZTJiWPAz/hqLDcUsYnck/c8vt +VPftF7c5va7FlaVIG0dUx5gKnSZeCBrOdNWir8q/LOSNsVwP2WIju32K2jYzCp6 I7fhjGGzE+QyivkpTMCipCNhq4VKfH4EiDXzLAYznnpFkdkpa1werYva2XxeCFMb Xln77yJxGEmAc6LeIkj2egPS+mroy/RvnxG5I0DCCelAfKrWj3dOet0oB6DKlgTG 2IPVvR9WI3uwAQ6DmyVoV9wrmxltjpnAmiA2sx4eG7crijL9NrqUnkHiRz387zbK lOhYt0DKYCZY1a2q4fcVttwKoEDbnBJfZizTXL6aNnsTcxgLPCG2PIqb+7/YbrtQ z4Ez2vMyPve+ol+8Ep6KBB6KQpGUgXmgJQVIF8ARCA3+G2fefNdwxUXoNdU0HF+n DLC9vnziI9XYs67oLO7WQo3b/Z8NUwfAubDKd/Dm5EBS1Z85siQ= =aeWM -----END PGP SIGNATURE----- --=-=-=-- --===============0647254219== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0647254219==--