> On Sep 21, 2015, at 7:11 AM, Tomas Henzl wrote:
> On 16.9.2015 23:27, Matthew R. Ochs wrote:
>> When a LUN is removed, the sdev that is associated with the LUN
>> remains intact until its reference count drops to 0. In order
>> to prevent an sdev from being removed while a
On 16.9.2015 23:27, Matthew R. Ochs wrote:
> When a LUN is removed, the sdev that is associated with the LUN
> remains intact until its reference count drops to 0. In order
> to prevent an sdev from being removed while a context is still
> associated with it, obtain an additional reference
> On Sep 17, 2015, at 8:26 PM, Brian King wrote:
>
> On 09/16/2015 04:27 PM, Matthew R. Ochs wrote:
>>
>> lun_access = kzalloc(sizeof(*lun_access), GFP_KERNEL);
>> if (unlikely(!lun_access)) {
>> dev_err(dev, "%s: Unable to allocate
On 09/16/2015 04:27 PM, Matthew R. Ochs wrote:
> When a LUN is removed, the sdev that is associated with the LUN
> remains intact until its reference count drops to 0. In order
> to prevent an sdev from being removed while a context is still
> associated with it, obtain an additional reference
When a LUN is removed, the sdev that is associated with the LUN
remains intact until its reference count drops to 0. In order
to prevent an sdev from being removed while a context is still
associated with it, obtain an additional reference per-context
for each LUN attached to the context.
This
When a LUN is removed, the sdev that is associated with the LUN
remains intact until its reference count drops to 0. In order
to prevent an sdev from being removed while a context is still
associated with it, obtain an additional reference per-context
for each LUN attached to the context.
This
6 matches
Mail list logo