usb-storage: wait for device scanning before mounting root
in [Kernel]
|
Prev: [PATCH] Hugetlb: stop race when reading proc meminfo
Next: usb-storage: wait for device scanning before mounting root
From: Matthew Wilcox on 19 Jun 2008 14:30 This discussion seemed to die off ... did anything ever come of it? On Fri, Apr 25, 2008 at 03:11:23AM -0600, Matthew Wilcox wrote: > On Fri, Apr 25, 2008 at 11:15:36AM +0300, Pekka J Enberg wrote: > > On Fri, 25 Apr 2008, Stefan Richter wrote: > > > Besides, can't you use the generic async scan facility of the SCSI stack for > > > your purpose? If not, can it be extended to make it usable? > > > > So you mean drivers/scsi/scsi_scan.c, right? We probably can and > > should so I'll take a look. > > The problem is that USB has one scsi_host per device (rather than, say, > having one scsi_host and adding new devices to it as they're found on > the USB bus). > > I'm certainly open to ideas of hooking into the mechanism -- it's just a > list of completions after all. Something like this: > > void *scsi_insert_into_scan_list(void) > { > return scsi_prep_async_scan(NULL); > } > > void scsi_scan_completed(void *cookie) > { > struct async_scan_data *data = cookie; > wait_for_completion(&data->prev_finished); > spin_lock(&async_scan_lock); > list_del(&data->list); > if (!list_empty(&scanning_hosts)) { > struct async_scan_data *next = list_entry(scanning_hosts.next, > struct async_scan_data, list); > complete(&next->prev_finished); > } > spin_unlock(&async_scan_lock); > > kfree(data); > } > > Perhaps refactor a little -- everything inside the async_scan_lock would > be common to scsi_scan_completed() and scsi_finish_async_scan(). > > with appropriate checks for shost being NULL in scsi_prep_async_scan: > > +++ b/drivers/scsi/scsi_scan.c > @@ -1698,7 +1698,7 @@ static struct async_scan_data *scsi_prep_async_scan(struct > if (strncmp(scsi_scan_type, "sync", 4) == 0) > return NULL; > > - if (shost->async_scan) { > + if (shost && shost->async_scan) { > printk("%s called twice for host %d", __FUNCTION__, > shost->host_no); > dump_stack(); > @@ -1708,16 +1708,19 @@ static struct async_scan_data *scsi_prep_async_scan(stru > data = kmalloc(sizeof(*data), GFP_KERNEL); > if (!data) > goto err; > - data->shost = scsi_host_get(shost); > - if (!data->shost) > - goto err; > init_completion(&data->prev_finished); > > - mutex_lock(&shost->scan_mutex); > - spin_lock_irqsave(shost->host_lock, flags); > - shost->async_scan = 1; > - spin_unlock_irqrestore(shost->host_lock, flags); > - mutex_unlock(&shost->scan_mutex); > + if (shost) { > + data->shost = scsi_host_get(shost); > + if (!data->shost) > + goto err; > + > + mutex_lock(&shost->scan_mutex); > + spin_lock_irqsave(shost->host_lock, flags); > + shost->async_scan = 1; > + spin_unlock_irqrestore(shost->host_lock, flags); > + mutex_unlock(&shost->scan_mutex); > + } > > spin_lock(&async_scan_lock); > if (list_empty(&scanning_hosts)) > > Would that work for you? > > -- > Intel are signing my paycheques ... these opinions are still mine > "Bill, look, we understand that you're interested in selling us this > operating system, but compare it to ours. We can't possibly take such > a retrograde step." -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Wilcox on 19 Jun 2008 15:00 On Thu, Jun 19, 2008 at 08:39:38PM +0200, Stefan Richter wrote: > The problem is AFAIU not exactly how many Scsi_Host instances (initiator > port representations, or something remotely related to that) are > instantiated, but rather _when_ they are instantiated. On multi > protocol buses or networks like USB and FireWire, it makes sense to > create the SCSI initiator port representation when we discovered that > there are actually SCSI targets on the bus or network. I'm not convinced of that. Why shouldn't we create one scsi host for all USB scsi devices? I know that today there's a certain amount of per-device state stored in the scsi_host, but that should be fixable. > scsi_scan's API is geared towards drivers which create one or more > initiator port representations right up front before going on target > discovery, right? Today, yes. The mail that I just pinged described a way to enhance the API -- letting you tell scsi "I've started scanning, save me a place in the queue" and "I've finished scanning, hook me up". The advantage to this is that you can spend a lot more time waiting for devices without increasing boot time significantly, since you wait while the rest of the system initialises. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Wilcox on 19 Jun 2008 16:30 On Thu, Jun 19, 2008 at 09:54:06PM +0200, Stefan Richter wrote: > [...] > > The mail that I just pinged described a way to enhance the > > API -- letting you tell scsi "I've started scanning, save me a place in > > the queue" and "I've finished scanning, hook me up". > > When would be the right time to say "I've started scanning"? SCSI > transport driver initialization? Or end of USB/FireWire/... HCD > registration? You would need to call it before you could attempt to register any devices. So fairly early on in the initialisation of sbp2/usb-storage. > When to say "I've finished scanning"? --- I think the answer is: When > (a) probing of a configurable number of SCSI targets or logical units > was finished or (b) a configurable timeout occurs, whatever of the two > happens first. > > (Explanation, if one is necessary: SCSI targets may pop out of the > woods any time; it is impossible to say "from this moment on there won't > show up any new ones anymore". This is just as true for cold boot and > warm boot as it is for subsequent operation.) Yes, I do see the problem. There's no way the SCSI core can know when a driver has finished scanning, so I've punted to the driver to set its own timeout here. I know that new devices really can show up at any time, but I think it's reasonable to say that if a machine is booted with the same configuration as last time, the drives should show up with the same names. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Dharm on 19 Jun 2008 16:40 On Thu, Jun 19, 2008 at 12:54:19PM -0600, Matthew Wilcox wrote: > On Thu, Jun 19, 2008 at 08:39:38PM +0200, Stefan Richter wrote: > > The problem is AFAIU not exactly how many Scsi_Host instances (initiator > > port representations, or something remotely related to that) are > > instantiated, but rather _when_ they are instantiated. On multi > > protocol buses or networks like USB and FireWire, it makes sense to > > create the SCSI initiator port representation when we discovered that > > there are actually SCSI targets on the bus or network. > > I'm not convinced of that. Why shouldn't we create one scsi host for > all USB scsi devices? I know that today there's a certain amount of > per-device state stored in the scsi_host, but that should be fixable. First, there are usb-storage devices which are USB<->SCSI bridges and therefore support multiple target devices. Second, you would still need multiple hosts when you have more than 15 target USB devices, anyway. Matt -- Matthew Dharm Home: mdharm-usb(a)one-eyed-alien.net Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998
From: Matthew Wilcox on 19 Jun 2008 17:00
On Thu, Jun 19, 2008 at 12:52:40PM -0700, Matthew Dharm wrote: > First, there are usb-storage devices which are USB<->SCSI bridges and > therefore support multiple target devices. This is true. > Second, you would still need multiple hosts when you have more than 15 > target USB devices, anyway. This isn't true. Look at topologies like fibre channel which can have thousands of targets on a single host. I would suggest that you want one 'channel' per usb endpoint. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |