From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH] drm: Don't reference objects in the flink name idr Date: Tue, 3 Dec 2013 21:44:33 +0100 Message-ID: <20131203204433.GR27344@phenom.ffwll.local> References: <1386034577-9195-1-git-send-email-krh@bitplanet.net> <20131203152622.GE27344@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by gabe.freedesktop.org (Postfix) with ESMTP id 65152FB85B for ; Tue, 3 Dec 2013 12:43:47 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id d49so1840801eek.18 for ; Tue, 03 Dec 2013 12:43:46 -0800 (PST) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Kristian =?iso-8859-1?Q?H=F8gsberg?= Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org On Tue, Dec 03, 2013 at 08:33:46AM -0800, Kristian H=F8gsberg wrote: > On Tue, Dec 3, 2013 at 7:26 AM, Daniel Vetter wrote: > > On Mon, Dec 02, 2013 at 05:36:17PM -0800, Kristian H=F8gsberg wrote: > >> There's no reason to keep a reference to objects in the name idr. Each > >> handle to an object has a reference to the object and just before we > >> destroy the last handle we take the object out of the name idr. Thus, > >> if an object is in the name idr, there's at least one reference to the > >> object. > >> > >> Or to put it another way, the name idr reference will never keep the > >> object alive. It just looks like it, which is confusing. > >> > >> Signed-off-by: Kristian H=F8gsberg > > > > I expect this to blow up when you race gem_close ioctl calls with flink > > open. i-g-t/gem_flink_close tests actually have been written specifical= ly > > to exercise these races. > > -Daniel > = > Can you be more specific about what race you see? The one thing that > could go wrong is that the last handle is delete after we enter > drm_gem_flink_ioctl() and look up the object but before taking the > object_name_lock, but that's handled by checking obj->handle_count > under the lock. Deleting handles and removing the name is always done > under the object_name_lock from > drm_gem_object_handle_unreference_unlocked(). Too many nightmares around lifetime rules, I've imagined some monster that isn't ther and stand corrected. Reviewed-by: Daniel Vetter -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch