* libata: big endian bug in VPD page 89 (ATA Information)
@ 2021-06-14 1:28 Douglas Gilbert
2021-06-14 6:00 ` Hannes Reinecke
0 siblings, 1 reply; 2+ messages in thread
From: Douglas Gilbert @ 2021-06-14 1:28 UTC (permalink / raw)
To: linux-scsi, linux-ide, Martin K. Petersen, Hannes Reinecke,
Tony Asleson
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.
Doug Gilbert
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: libata: big endian bug in VPD page 89 (ATA Information)
2021-06-14 1:28 libata: big endian bug in VPD page 89 (ATA Information) Douglas Gilbert
@ 2021-06-14 6:00 ` Hannes Reinecke
0 siblings, 0 replies; 2+ messages in thread
From: Hannes Reinecke @ 2021-06-14 6:00 UTC (permalink / raw)
To: dgilbert, linux-scsi, linux-ide, Martin K. Petersen, Tony Asleson
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@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-06-14 6:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-14 1:28 libata: big endian bug in VPD page 89 (ATA Information) Douglas Gilbert
2021-06-14 6:00 ` Hannes Reinecke
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.