On Sat, 18 Oct 2008, Michael Schmitz wrote: > > While working on ide_do_request() improvements I stumbled upon > > mismatched ide_get_lock() / ide_release_lock() calls. > > > > [ It seems to be known issue: > > http://marc.info/?l=linux-m68k&m=121423752829622&w=2 ] > > It is a known issue, and I submitted a simple fix to Geert a month or so ago. > It involves moving the ide_get_lock call inside the request loop instead of > doing it once at the start of the function. See http://marc.info/?l=linux-ide&m=121473433631934&w=2 In response to this patch, I wondered: > > If hwgroup->busy serves a similar purpose to falconide_intr_lock, what > > about > > moving the setting/clearing of hwgroup->busy into > > ide_{get,release}_lock() > > (and possibly renaming ide_{get,release}_lock() to e.g. > > ide_hwgroup_{set,clear}_busy())? > > > > What about the other places where hwgroup->busy is set/cleared? And Michael responsed: > Uh - that's where it gets a bit sticky again. hwgroup->busy is set and > cleared quite a lot 'preemptively' all over ide-io.c, f.e. in timeout > handling. I'm not sure > whether this would just reintroduce the bug message. > > The lock must be held as long as there are any interrupts to be expected > from IDE. If the hwgroup->busy semantics reflects just that, it's worth > a try. Bart, can you shed a light on the hwgroup->busy semantics? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
