From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: "Gustavo F. Padovan" Date: Thu, 8 Sep 2011 15:35:30 -0300 From: Gustavo Padovan To: Luiz Augusto von Dentz Cc: Marcel Holtmann , linux-bluetooth@vger.kernel.org Subject: Re: [PATCH 2/2] serial: Add support to Disconnect fd passing connections Message-ID: <20110908183530.GB2695@joana> References: <20110823164501.GB26522@joana> <1314129089.3373.218.camel@aeonflux> <20110906051657.GB13617@joana> <1315396567.1979.36.camel@aeonflux> <1315399602.1979.39.camel@aeonflux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-ID: * Luiz Augusto von Dentz [2011-09-07 18:05:08 +0300]: > Hi Marcel, > > On Wed, Sep 7, 2011 at 3:46 PM, Marcel Holtmann wrote: > > Hi Luiz, > > > >> > yes, you do have to keep track of the client. You wanna do a proper > >> > shutdown if the client exits unexpectedly. Or forgets to call shutdown. > >> > >> I guess the kernel would auto release the socket if the process exit > >> and nobody else has a reference to it, so if we close our fd after it > >> has been transferred the only one with reference is the client, iirc > >> this was a problem to tty because we have to release the devnode to > >> disconnect which involves ioctl but afaik that is not the case for > >> sockets and the client can basically call close and be done with it, > >> right? > > > > does dbus-daemon holds the reference for the time of D-Bus message to be > > in flight between bluetoothd and the client? If not, then we have a race > > condition here, because we dropped the reference before it ended up on > > the other side. > > Good question, iirc dbus-daemon does use dup but we better confirm > with Lennart how this is supposed to work. Anyway if it doesn't then I > guess it should be fixed in dbus-daemon to do it, otherwise as you > said it will be racy to transfer fd specially when fd is send in a > reply. It does use dup, I just checked on the source code. Gustavo