Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jun 2013 20:39:49 +0300
From:      Alexander Motin <mav@FreeBSD.org>
To:        "Kenneth D. Merry" <ken@FreeBSD.org>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r251649 - in head/sys/cam: ata scsi
Message-ID:  <51B8B265.8010306@FreeBSD.org>
In-Reply-To: <20130612170126.GA8081@nargothrond.kdm.org>
References:  <201306120907.r5C97FTN022047@svn.freebsd.org> <20130612170126.GA8081@nargothrond.kdm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12.06.2013 20:01, Kenneth D. Merry wrote:
> On Wed, Jun 12, 2013 at 09:07:15 +0000, Alexander Motin wrote:
>> Author: mav
>> Date: Wed Jun 12 09:07:15 2013
>> New Revision: 251649
>> URL: http://svnweb.freebsd.org/changeset/base/251649
>>
>> Log:
>>    Acquire periph reference when handling d_getattr() method call.
>>
>>    While GEOM in general has provider opened while sending BIO_GETATTR,
>>    GEOM DISK does not really need to open disk to read medium-unrelated
>>    attributes for own use.
>>
>>    Proposed by:	ken
>
> I forgot proposing that, but it seems like we probably don't need to
> acquire a reference there.

Ah, may be for this point it still was Justin. Sorry, if so.

> The primary thing we want to insure is that the
> peripheral is valid and doesn't go away.  We acquire a reference when we do
> the disk_create(), and then release that reference when our GEOM provider
> has gone away.  (GEOM calls the d_gone() callback, and so we know that it
> will not call into the CAM peripheral driver again.)
>
> I assume that once the provider has gone away, there won't be any more
> d_getattr() method calls.  If so, the existing reference should be enough
> to protect it.  (If we can get d_getattr() calls after the provider has
> gone away, then that needs to be fixed.)

You seems to be right. I've forgot about that d_gone() method. It wasn't 
there in original design. Then probably we don't need reference counting 
on d_open()/d_close() either any more.

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51B8B265.8010306>