From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [linux-usb-devel] Re: bug 2400 Date: 06 Apr 2004 09:03:32 -0500 Sender: linux-scsi-owner@vger.kernel.org Message-ID: <1081260215.1804.17.camel@mulgrave> References: <4071EA82.3020901@pacbell.net> <1081214360.1756.330.camel@mulgrave> <200404060852.34169.oliver@neukum.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from stat1.steeleye.com ([65.114.3.130]:22452 "EHLO hancock.sc.steeleye.com") by vger.kernel.org with ESMTP id S263832AbUDFOEY (ORCPT ); Tue, 6 Apr 2004 10:04:24 -0400 In-Reply-To: <200404060852.34169.oliver@neukum.org> List-Id: linux-scsi@vger.kernel.org To: Oliver Neukum Cc: David Brownell , Alan Stern , Mike Anderson , Andrew Morton , greg@kroah.com, Jens Axboe , linux-usb-devel@lists.sourceforge.net, SCSI Mailing List On Tue, 2004-04-06 at 01:52, Oliver Neukum wrote: > Pure refcounting can never protect you against races with freeing objects. > The counters themselves must be protected. Try as you might you need > locks for that and rules on how this locks are to be used. Which part of On Mon, 2004-04-05 at 20:19, James Bottomley wrote: > Now, if the subsystem is going to garbage collect its own object as a > result of the other object disconnect, then it is responsible for > synchronising that with reference gets on its own object. However, that > is easily achievable via *intra* subsystem synchronisation. didn't you understand? However, how a subsystem resolves this intra subsystem synchronisation is up to it ... and it doesn't have to do it with locks. So there are no exposed locks for this and no rules therefore, for how to use them. James