Subject: Re: Race in scsipi_execute_xs()? (Was: Re: More on se0)
To: Leo Weppelman <leo@wau.mis.ah.nl>
From: Julian Coleman <J.D.Coleman@newcastle.ac.uk>
List: tech-kern
Date: 08/13/1998 23:24:19
Leo Weppelman wrote:
> One way that might work to get around this is the addition of a FREEWHENDONE
> flag. So the code in scsipi_execute_xs() looks like:
> ....
> switch (scsipi_command_direct(xs)) {
> case SUCCESSFULLY_QUEUED:
> if ((xs->flags & (SCSI_NOSLEEP | SCSI_POLL)) == SCSI_NOSLEEP) {
> xs->flags |= SCSI_FREEWHENDONE;
> return (EJUSTRETURN);
> }
> .....
>
> The tail of scsipi_done() will look like:
>
> .....
> if (xs->flags & SCSI_FREEWHENDONE)
> scsipi_free_xs(xs, SCSI_NOSLEEP);
> if (bp)
> .....
It appears that not running scsipi_free_xs() from scsipi_done() has other
effects - i.e. the kernel doesn't boot :
sd0(ncrscsi0:0:0); Does not support linked commands
sd0: mode sense (4) returned nonsense: using fictitious geometry
<machine is locked solid at this point>
This is the same result as trying to make scsipi_free_xs() conditional
on SCSI_NOSLEEP. I tried to call scsipi_free_xs() from scsipi_execute_xs()
too, but that didn't help either :(
As the problem seems to occur when handle_message() is called between
information_transfer() and the return to scsipi_execute_xs(), is it safe
to block SCSI interrupts until the return?
J
--
1024/55A5BC19 0F 3F 62 56 18 10 8B 84 43 8F F4 94 93 37 76 AA
S.E.P.