lkml.org 
[lkml]   [2005]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH scsi-misc-2.6 07/08] scsi: remove bogus {get|put}_device() calls
On Wed, Mar 23, 2005 at 06:13:26PM +0900, Tejun Heo wrote:
> Hi,
>
> James Bottomley wrote:
> >On Wed, 2005-03-23 at 11:14 +0900, Tejun Heo wrote:
> >
> >> So, basically, SCSI high-level object (scsi_disk) and
> >> mid-level object (scsi_device) are reference counted by users,
> >> not the requests they submit. Reference count cannot go zero
> >> with active users and users cannot access the object once the
> >> reference count reaches zero.
> >
> >
> >Actually, no. Unfortunately we still have some fire and forget APIs, so
> >the contention that we always have an open refcounted descriptor isn't
> >always true.

What API's, and what usage?

> Yeap, you're right. So, what we have is

> * All high-level users have open access to the scsi high-level
> object on issueing requests, but may close it before its requests
> complete.

> * All mid-layer users do get_device() before submitting requests,
> but may put_device() before its requests complete.

Any LLDD's issuing requests should be doing a get/put around the request.

Any upper level drivers calling scsi_device_put() before a request
completes is likely a bug. sg has code in place to handle the
post-release/close completion of IO (IMO, a bad design).

Are any upper level drivers calling scsi_device_put() while they have
outstanding IO?

The scan code never calls upper level drivers probe functions via
device_add unless we are going to keep the scsi_device (well, there are
error paths in scsi_sysfs_add_sdev that look bad - we don't check the
result of scsi_sysfs_add_sdev). But for completeness, we could add
get/puts to the scan code.

As you pointed out, the current get_device() will never return NULL when
called via:

get_device(&sdev->sdev_gendev)

The current code only narrows the window where problems might occur, I
don't see how it can completely avoid races with removal.

And the patch removes code from the mainline scsi IO paths.

-- Patrick Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.085 / U:1.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site