Re: [PATCH 5/7] lpfc 8.3.13: BSG management fixes

[James Smart <james.smart@emulex.com>]

Actually, it may be just checking the file->private_data pointer for NULL at 
the file entry points.  Although, the minor should not be deallocated from bsg 
until all releases are called.

-- james s


James Smart wrote:
> Slightly different. I believe it's ok relative to when there's a BSG request 
> in flight. But in this case there isn't, but there is a program w/ the bsg 
> node open, and the driver/transport/etc can all be unloaded as bsg_open 
> doesn't take a reference anywhere.
> 
> I look at it the other day, and it appears to be an issue with bsg itself. It 
> should just take a reference to the bsg class dev in open, and release it in 
> release. But the bsg_unregister_queue() path doesn't track whether the node 
> was open or not and the teardown needs to be split up so that it really is 
> reference based.
> 
> -- james s
> 
> 
> FUJITA Tomonori wrote:
>> On Wed, 12 May 2010 09:32:14 -0400
>> James Smart <james.smart@emulex.com> wrote:
>>
>>> - Add reference counting to prevent module removal when
>>>   there are outstanding BSG requests.
>> Didn't I worked on it about scsi_transport_sas?
>>
>> bsg holds the ref count on the device that passed in
>> bsg_register_queue() while there are outstanding bsg requests. It is
>> supposed to prevent the module of the hold device from be removed.
>>
>> Do you get the oops message?
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>