Thorsten,
I am currently testing a patch on scsi.c to close
all of those scsi_init_malloc() calls that don't
check for a NULL return. The patch will go to
Alan Cox today or tomorrow.
It is not so obvious what to do in some of
these contexts when NULL is returned, given
the way the code is designed. Also if you
look at the code you will see that the memset()
is redundant, since one is done inside
scsi_init_malloc()!
Doug Gilbert
P.S. Email me if you wish to try my patch.
Thorsten Knabe wrote:
>
> [1.] One line summary of the problem:
> Obvious(?) bug in scsi.c
>
> [2.] Full description of the problem/report:
> The following Oops was raised by issueing the command
> echo "scsi add-single-device 0 0 1 0" >/proc/scsi/scsi
> Afterwards the shell hung in D state.
>
> [3.] Keywords (i.e., modules, networking, kernel):
> scsi
>
> [4.] Kernel version (from /proc/version):
> Linux version 2.2.9 (root@tek01) (gcc version 2.7.2.3)
>
> [5.] Output of Oops.. message (if applicable) with symbolic information
> resolved (see Documentation/oops-tracing.txt)
> kernel: Oops: 0002
> kernel: CPU: 0
> kernel: EIP: 0010:[<d0945594>] (scan_scsis+84)
> kernel: EFLAGS: 00010246
> kernel: eax: 00000000 ebx: 00000001 ecx: 00000046 edx: 00000000
> kernel: esi: cfc40000 edi: 00000000 ebp: 00000001 esp: ce5addd4
> kernel: ds: 0018 es: 0018 ss: 0018
> kernel: Process bash (pid: 26452, process nr: 52, stackpage=ce5ad000)
> kernel: Stack: 00000000 00000001 c01cff18 fffffff8 6f686365 00000000 61206900
> 732d6401
> kernel: 6c676e00 65642d65 65636976 30203020 30203120 2f3e2022 636f7270
> ffffffff
> kernel: c01eaceb d094c867 00000002 ce5adfc4 ce5adee8 00000038 ce5ade3c
> c01c2b90
> kernel: Call Trace: [<d094c867>] [<c01c2b90>] [<c0128aa2>]
> [<c012ee93>] [<c01add9f>] [<d094c84b>] [<c010e98e>]
> kernel: [<c010f037>] [<c01118be>] [<d094c84b>]
> [<d094745f>] [<d094c84c>] [<d09474f4>] [<d094954e>] [<c0147576>]
> kernel: [<c0147508>] [<c0122bb0>] [<c0107a54>]
> kernel: Code: f3 ab 6a 08 6a 58 e8 a5 19 00 00 89 c7 89 7c 24 34 83 c4 08
>
> [6.] A small shell script or example program which triggers the
> problem (if possible)
> not (easily) reproduceable
>
> [7.] Environment
> SCSI stuff is build as module and has been loaded successfully loaded at
> boot time. Other stuff seems to be irrelevant.
>
> [X.] Other notes, patches, fixes, workarounds:
>
> The Oops occured at scan_scsis+84 (d0945594), which seems to match the
> following code in drivers/scsi/scsi.c:
>
> static void scan_scsis (struct Scsi_Host *shpnt,
> unchar hardcoded,
> unchar hchannel,
> unchar hid,
> unchar hlun)
> {
> int channel;
> int dev;
> int lun;
> int max_dev_lun;
> Scsi_Cmnd * SCpnt;
> unsigned char * scsi_result;
> unsigned char scsi_result0[256];
> Scsi_Device * SDpnt;
> Scsi_Device * SDtail;
> int sparse_lun;
>
> SCpnt = (Scsi_Cmnd *) scsi_init_malloc (sizeof (Scsi_Cmnd), GFP_ATOMIC |
> GFP_D
> MA);
> memset (SCpnt, 0, sizeof (Scsi_Cmnd)); /* Oops */
>
> SDpnt = (Scsi_Device *) scsi_init_malloc (sizeof (Scsi_Device),
> GFP_ATOMIC);
> memset (SDpnt, 0, sizeof (Scsi_Device));
>
> /* Make sure we have something that is valid for DMA purposes */
> scsi_result = ( ( !shpnt->unchecked_isa_dma )
> ? &scsi_result0[0] : scsi_init_malloc (512, GFP_DMA));
>
> Obviously scsi_init_malloc has failed and returned NULL. Then trying to
> clear the the memory block using memset caused the Oops. Maybe we should
> check if allocation succeeded before we clear the allocated area. ;) Btw.
> memsetting the allocated area seems to be redundant. It is already cleard
> by scsi_init_malloc.
>
> Regards
> Thorsten
>
> I�m not subscribed to linux-scsi, so please CC me.
> --
> E-Mail: [EMAIL PROTECTED]
> ___ WWW: http://www.student.informatik.tu-darmstadt.de/~tek
> | | / ICQ: 5472045
> |horsten |/\nabe
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
