Re: libata: big endian bug in VPD page 89 (ATA Information)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/14/21 3:28 AM, Douglas Gilbert wrote:
In drivers/ata/libata-scsi.c in function ata_scsiop_inq_89() there is
this line, just before the return:
       memcpy(&rbuf[60], &args->id[0], 512);

args->id[0] is the first u16 word of an array from the ATA IDENTIFY
DEVICE response while rbuf is an array of u8 that will become the
response to a SCSI INQUIRY(VPD=89h). Given the definition of VPD
page 89h:
   byte 60+0:  ATA IDENTIFY DEVICE data word 0 bits 7:0
   byte 60+1:  ATA IDENTIFY DEVICE data word 0 bits 15:8
   byte 60+2:  ATA IDENTIFY DEVICE data word 1 bits 7:0
   ........

then that memcpy is just fine and dandy on a little endian machine.
On a big endian machine, not so much.

Would this call after the memcpy fix things?
    swap_buf_le16((u16 *)(rbuf + 60), ATA_ID_WORDS);

That function (in libata-core.c) only swaps bytes in 16 bit words
on big endian machines.

It might. But probably no-one ever ran libata code on big-endian machines.
They are becoming rare these days; I wouldn't know where to look.
So if you had a chance to run it please give it a go.
Truth to be told, I won't be surprised if there would be more issues lurking in the libata code.

Cheers,

Hannes
--
Dr. Hannes Reinecke                Kernel Storage Architect
hare@xxxxxxx                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer



[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux