Re: SCSI woes (followup)

Patrick Mansfield
2002-09-25T17:22:54Z

Russel -

On Wed, Sep 25, 2002 at 09:41:37AM +0100, Russell King wrote:
> On Tue, Sep 24, 2002 at 05:08:57PM -0700, Patrick Mansfield wrote:
> > On Tue, Sep 24, 2002 at 11:39:42PM +0100, Russell King wrote:
> >
> > Looks nice. I have the same comment as before about no commands.
>
> I fail to see what the problem here is. I've repeatedly explained this.
> I'm not going to explain it again; maybe it would be wise to read the
> 2.4.19 code? Please re-read all my mails since Sunday.

OK, I understand those and the IO completion code.

I see now in your patch that if Scsi_Device::locked is set, we must
have Scsi_Device::cmd_blocks != 0, since we only set locked in upper
layers or via an ioctl to an upper layer device. So, checking for
cmd_blocks is redundant.

> > > +static void scsi_eh_lock_done(struct scsi_cmnd *SCpnt)
> > > +{
> > > + struct scsi_request *SRpnt = SCpnt->sc_request;
> > > +
> > > + SCpnt->sc_request = NULL;
> > > + SRpnt->sr_command = NULL;
> > > +
> > > + scsi_release_command(SCpnt);
> > > + scsi_release_request(SRpnt);
> > > +}
> >
> > This is back to my orginal point (i.e. case 1 in your other response
> > about "restarting operations after error handling", I haven't figured
> > out case 2 yet) - the above will not be called if there are no commands.

So, the above can never happen, since locked can't be set until after
cmd_blocks == 1.

-- Patrick Mansfield