On Wed, 2014-01-08 at 10:57 -0500, Alan Stern wrote:
> On Wed, 8 Jan 2014, James Bottomley wrote:
>
> > OK, Agreed, but that means modifying the 1/2 patch with the below. This
> > should make the proposed diff to 2/2 correct.
> >
> > James
> >
> > ---
> > diff --git a/drivers/scsi/scsi_scan.c b
On Wed, 8 Jan 2014, James Bottomley wrote:
> OK, Agreed, but that means modifying the 1/2 patch with the below. This
> should make the proposed diff to 2/2 correct.
>
> James
>
> ---
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index ef3f958..5fad646 100644
> --- a/drive
On Sat, 2014-01-04 at 11:27 -0500, Alan Stern wrote:
> On Fri, 3 Jan 2014, James Bottomley wrote:
>
> > > I'm still concerned about one thing. The previous patch does this in
> > > scsi_alloc_target():
> > >
> > > > found:
> > > > - found_target->reap_ref++;
> > > > + if (!kref_get
On Fri, 3 Jan 2014, James Bottomley wrote:
> > I'm still concerned about one thing. The previous patch does this in
> > scsi_alloc_target():
> >
> > > found:
> > > - found_target->reap_ref++;
> > > + if (!kref_get_unless_zero(&found_target->reap_ref))
> > > + /*
> > > + * rele
On Fri, 2014-01-03 at 10:58 -0500, Alan Stern wrote:
> On Thu, 2 Jan 2014, James Bottomley wrote:
>
> > In the highly unusual case where two threads are running concurrently
> > through
> > the scanning code scanning the same target, we run into the situation where
> > one may allocate the targe
On Thu, 2 Jan 2014, James Bottomley wrote:
> In the highly unusual case where two threads are running concurrently through
> the scanning code scanning the same target, we run into the situation where
> one may allocate the target while the other is still using it. In this case,
> because the rea
