Jens Axboe <jens.axboe@xxxxxxxxxx> wrote: > On Fri, Oct 10 2008, Elias Oltmanns wrote: >> Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx> wrote: > >> > From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx> >> > Subject: [PATCH] ide: ide_hwgroup_t.rq doesn't need an ide_lock held >> > >> > While at it: >> > - no need to check for hwgroup presence in ide_dump_opcode() >> > >> > Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx> >> > --- >> [...] >> > Index: b/drivers/ide/ide-io.c >> > =================================================================== >> > --- a/drivers/ide/ide-io.c >> > +++ b/drivers/ide/ide-io.c >> [...] >> > @@ -274,7 +269,11 @@ static void ide_complete_pm_request (ide >> > drive->dev_flags &= ~IDE_DFLAG_BLOCKED; >> > blk_start_queue(drive->queue); >> > } >> > - HWGROUP(drive)->rq = NULL; >> > + spin_unlock_irqrestore(&ide_lock, flags); >> > + >> > + drive->hwif->hwgroup->rq = NULL; >> > + >> > + spin_lock_irqsave(&ide_lock, flags); >> > if (__blk_end_request(rq, 0, 0)) >> > BUG(); >> > spin_unlock_irqrestore(&ide_lock, flags); >> >> Is it really an improvement to release the lock here? > > And more importantly, is it even safe? What serializes ->rq assignments > and checks without the ide_lock? Looks fishy. Well, I haven't quite made up my mind whether it'll work in all cases, but I think the hwgroup->busy flag is supposed to take care of that. Regards, Elias -- 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
