lkml.org 
[lkml]   [2003]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: scsi_report_lun_scan bug?
    Patrick,

    In my case, I have 16 luns for which report lun
    command byte 3 has value 0x80. While doing the length
    calculation
    length = ((data[0] << 24) | (data[1] << 16) |
    (data[2] << 8) | (data[3] << 0));

    It calucates length as 0xffffff80 and actual number of
    luns is calculated as 536870896. I just write small
    program with signed and unsigned char array and it
    does evaluate as 0xffffff80 as Andrew mentioned.

    Thanks
    Amit


    #include<stdio.h>
    main()
    {
    char x[10]={0x00,0x00,0x00,0x80};
    char *p;
    unsigned char *q;

    int len;
    int ulen;

    p=(char *)x;
    q=(unsigned char *) x;
    len=((p[0] << 24) | (p[1] << 16) | (p[2] << 8)
    | (p[3] <<0));
    ulen=((q[0] << 24) |(q[1] << 16) | (q[2] << 8)
    | (q[3] <<0));
    printf("len= %d len=%x\n",len,len);
    printf("ulen= %d ulen=%x\n",ulen,ulen);
    }





    --- Andrew Morton <akpm@osdl.org> wrote:
    > Patrick Mansfield <patmans@us.ibm.com> wrote:
    > >
    > > On Mon, Nov 17, 2003 at 06:48:33PM -0800, Amit
    > Patel wrote:
    > > > Hi,
    > > >
    > > > I am using 2.6-test9-mm3. I noticed while doing
    > > > scsi_report_lun_scan(scsi_scan.c:891) the data
    > > > returned is assigned(scsi_scan.c:993) to signed
    > char
    > > > array which causes the reported number of luns
    > to be
    > > > huge while calculating num_luns to scan. Is
    > there any
    > > > particular reason to be data is signed or just a
    > bug?
    > > >
    > > > I changed it to unsigned char and it seems to
    > work
    > > > fine. I have attached a diff of scsi_scan.c. Let
    > me
    > > > know if I am missing something.
    > >
    > > I don't see why making it signed or unsigned would
    > make any difference.
    >
    >
    > length = ((data[0] << 24) | (data[1] << 16) |
    > (data[2] << 8) | (data[3] << 0));
    >
    > If data[3] is 0xff, this expression will always
    > evaluate to
    > 0xffffffff. etcetera.
    >
    > > It should really be a u8, since it is a pointer to
    > an array of bytes.
    > >
    > > (And all the scsi_cmd[]'s should be u8.)
    >
    > Yup.
    >
    > diff -puN
    > drivers/scsi/scsi_scan.c~scsi_report_lun-fix
    > drivers/scsi/scsi_scan.c
    > --- 25/drivers/scsi/scsi_scan.c~scsi_report_lun-fix
    > 2003-11-17 20:22:49.000000000 -0800
    > +++ 25-akpm/drivers/scsi/scsi_scan.c 2003-11-17
    > 20:22:49.000000000 -0800
    > @@ -899,7 +899,7 @@ static int
    > scsi_report_lun_scan(struct s
    > unsigned int retries;
    > struct scsi_lun *lunp, *lun_data;
    > struct scsi_request *sreq;
    > - char *data;
    > + u8 *data;
    >
    > /*
    > * Only support SCSI-3 and up devices.
    > @@ -990,7 +990,7 @@ static int
    > scsi_report_lun_scan(struct s
    > /*
    > * Get the length from the first four bytes of
    > lun_data.
    > */
    > - data = (char *) lun_data->scsi_lun;
    > + data = (u8 *) lun_data->scsi_lun;
    > length = ((data[0] << 24) | (data[1] << 16) |
    > (data[2] << 8) | (data[3] << 0));
    >
    >
    > _
    >


    __________________________________
    Do you Yahoo!?
    Protect your identity with Yahoo! Mail AddressGuard
    http://antispam.yahoo.com/whatsnewfree
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:58    [W:0.025 / U:119.656 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site