On 08/16/12 07:52, Bart Van Assche wrote:
> On 08/16/12 01:35, Chanho Min wrote:
>>> functions will occur in line. I also don't see why the sdev reference
>>> couldn't drop to zero here.
>> scsi_request_fn is called under the lock of request_queue->queue_lock.
>> If we drop the sdev reference to
On 08/16/12 07:52, Bart Van Assche wrote:
On 08/16/12 01:35, Chanho Min wrote:
functions will occur in line. I also don't see why the sdev reference
couldn't drop to zero here.
scsi_request_fn is called under the lock of request_queue-queue_lock.
If we drop the sdev reference to zero here,
On Thu, 2012-08-16 at 07:52 +, Bart Van Assche wrote:
> On 08/16/12 01:35, Chanho Min wrote:
> >> functions will occur in line. I also don't see why the sdev reference
> >> couldn't drop to zero here.
> > scsi_request_fn is called under the lock of request_queue->queue_lock.
> > If we drop
On Thu, 2012-08-16 at 10:35 +0900, Chanho Min wrote:
> > functions will occur in line. I also don't see why the sdev reference
> > couldn't drop to zero here.
> scsi_request_fn is called under the lock of request_queue->queue_lock.
> If we drop the sdev reference to zero here,
>
On 08/16/12 01:35, Chanho Min wrote:
>> functions will occur in line. I also don't see why the sdev reference
>> couldn't drop to zero here.
> scsi_request_fn is called under the lock of request_queue->queue_lock.
> If we drop the sdev reference to zero here,
> scsi_device_dev_release_usercontext
On 08/16/12 01:35, Chanho Min wrote:
functions will occur in line. I also don't see why the sdev reference
couldn't drop to zero here.
scsi_request_fn is called under the lock of request_queue-queue_lock.
If we drop the sdev reference to zero here,
scsi_device_dev_release_usercontext is
On Thu, 2012-08-16 at 10:35 +0900, Chanho Min wrote:
functions will occur in line. I also don't see why the sdev reference
couldn't drop to zero here.
scsi_request_fn is called under the lock of request_queue-queue_lock.
If we drop the sdev reference to zero here,
On Thu, 2012-08-16 at 07:52 +, Bart Van Assche wrote:
On 08/16/12 01:35, Chanho Min wrote:
functions will occur in line. I also don't see why the sdev reference
couldn't drop to zero here.
scsi_request_fn is called under the lock of request_queue-queue_lock.
If we drop the sdev
> functions will occur in line. I also don't see why the sdev reference
> couldn't drop to zero here.
scsi_request_fn is called under the lock of request_queue->queue_lock.
If we drop the sdev reference to zero here,
scsi_device_dev_release_usercontext is
invoked and make request_queue to NULL.
functions will occur in line. I also don't see why the sdev reference
couldn't drop to zero here.
scsi_request_fn is called under the lock of request_queue-queue_lock.
If we drop the sdev reference to zero here,
scsi_device_dev_release_usercontext is
invoked and make request_queue to NULL. When
On Tue, 2012-08-14 at 18:48 +0900, Chanho Min wrote:
> We don't need to unlock the queue before put_device in scsi_request_fn()
> If we trigger the ->remove() function, It occur a oops from the caller.
> So sdev reference count should not be dropped to zero here.
> Also It was added before
On Tue, 2012-08-14 at 18:48 +0900, Chanho Min wrote:
We don't need to unlock the queue before put_device in scsi_request_fn()
If we trigger the -remove() function, It occur a oops from the caller.
So sdev reference count should not be dropped to zero here.
Also It was added before
12 matches
Mail list logo
