Re: Badness in device_release at drivers/base/core.c:84

Mike Anderson
2003-08-01T23:27:22Z

Andrew Morton [akpm@osdl.org] wrote:
> This patch should fix the oops.
>
> As for why the proc reading code was unable to locate the HBA: dunno, but
> this is a first step.
>
> Or maybe you don't have any adaptec controllers in the machine?
>
> (jejb, please apply..)
>
>
> 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix drivers/scsi/aic7xxx_old/aic7xxx_proc.c
> --- 25/drivers/scsi/aic7xxx_old/aic7xxx_proc.c~aic7xxx_old-oops-fix Fri Aug 1 14:41:14 2003
> +++ 25-akpm/drivers/scsi/aic7xxx_old/aic7xxx_proc.c Fri Aug 1 14:41:20 2003
> @@ -92,7 +92,7 @@ aic7xxx_proc_info ( struct Scsi_Host *HB
>
> HBAptr = NULL;
>
> - for(p=first_aic7xxx; p->host != HBAptr; p=p->next)
> + for(p=first_aic7xxx; p && p->host != HBAptr; p=p->next)
> ;
>
> if (!p)

Is this really the right thing to add. The only purpose of these few lines
is a poor sanity check as down further in the code a pointer to the
structure is already present in hostdata.

Adding the "p" is an indication that this drivers list got corrupted some
where.

I agree it may be better than an oops, but what else is invalid?

You need to have adaptec controllers in the system to get a procfs node
to read / write, but this error could be related to the node not getting
cleaned up correctly on a remove which a patch has previously been
posted.

-andmike
--
Michael Anderson
andmike@us.ibm.com