Bug 178488 - endianness issues in mpath_prio_alua
endianness issues in mpath_prio_alua
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ben Marzinski
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-20 17:35 EST by Brian Wong
Modified: 2010-01-11 21:23 EST (History)
6 users (show)

See Also:
Fixed In Version: U3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-08 10:48:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch made with cg-mkpatch -r 0803439535ea30ad1951d3deb0c5eaf894470d43 99c1a2e54868ab81b958fbe56858f1f889fd6e90 (10.54 KB, patch)
2006-02-03 18:22 EST, Brian Wong
no flags Details | Diff

  None (edit)
Description Brian Wong 2006-01-20 17:35:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
mpath_prio_alua mishandles endianness in inquiry data, due to a struct definition that does not apply to both big-endian and little-endian architectures.

Version-Release number of selected component (if applicable):
device-mapper-multipath-0.4.5-6.0.RHEL4

How reproducible:
Always

Steps to Reproduce:
1. run mpath_prio_alua on a storage target supporting ALUA on i386 platform
  

Actual Results:  when run with the -v option, mpath_prio_alua claims that 

Target port groups are not supported.

when in fact they really are.

Expected Results:  the program should go on and do the RTPG and return a proper prio.

Additional info:

the struct definition of inquiry_data in spc3.h should handle both big-endian and little-endian architectures.
Comment 1 Ben Marzinski 2006-02-03 17:35:55 EST
I do not have a target that supports ALUA handy, so I can't be sure of this, but
I can't see any problems with the inquiry_data structure.

This is my reasoning. Please reply if I'm misunderstanding something:
You are seeing a message saying "Target port groups are not supported" To get
that, mpath_prio_alua sends a SCSI inquiry command to the target. If the command
failed, this message would not be printed, so if there is a problem, it would
show up in the inquiry_data_get_tpgs() function.  According to the SPC-3 spec,
byte 5 of the standard inquiry data format is exactly what b5 of inquiry_data
says it is. inquiry_data_get_tpgs() looks at the fourth and fifth bit in the
byte. Since inquire_data_get_tpgs() is only dealing with a single byte, I cannot
see how there could be an endianness issue.  Some computers place the most
significant byte of a multibyte value first (big endian), some computers place
the least significant byte of a multibyte value first (little endian). All
computers see the individual bytes the same way.  So inquire_data_get_tpgs will
always see the same data in the fourth and fifth bits of b5, regardless of
whether the machine is big endian or little endian.

I apologize if I'm overlooking some endianness issue.  But in case I am not,
what type of storage target are you using?

Have you tried using the sq_inq command from the sg3_utils package on your
storage?

On my storage, I get

[root@cypher-05 sg3_utils-1.19]# sg_inq /dev/sda
standard INQUIRY:
  PQual=0  Device_type=0  RMB=0  version=0x02  [SCSI-2]
  [AERC=0]  [TrmTsk=1]  NormACA=0  HiSUP=0  Resp_data_format=2
  SCCS=0  ACC=0  TGPS=0  3PC=0  Protect=0  BQue=0
  EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=1  Sync=1  Linked=0  [TranDis=0]  CmdQue=1
    length=36 (0x24)   Peripheral device type: disk
 Vendor identification: Tornado-
 Product identification: F8 V2.0         
 Product revision level:     
 Unit serial number: 009408910001032 


The "TGPS=0" means that Target port groups are not supported on my storage.  If
this command also comes back saying that Target port groups are not supported on
your storage, then they probably aren't.  If TGPS is not zero, then there
probably is a bug in mpath_prio_alua 
Comment 2 Brian Wong 2006-02-03 18:07:04 EST
this does work in christophe's git tree HOL mpath_prio_alua.


[root@ca-devapm-73 lib]# ls -l /sbin/mpath_prio_alua
/sb/bwong/git-multipath-tools-inst/sbin/mpath_prio_alua
-rwxr-xr-x  1 root root 12088 Feb  3 12:49
/sb/bwong/git-multipath-tools-inst/sbin/mpath_prio_alua
-rwxr-xr-x  1 root root 12056 Sep  2 23:03 /sbin/mpath_prio_alua
[root@ca-devapm-73 lib]# /sbin/mpath_prio_alua -v /dev/sdh 
Target port groups are not supported.
[root@ca-devapm-73 lib]# /sb/bwong/git-multipath-tools-inst/sbin/mpath_prio_alua
-v /dev/sdh
Target port groups are implicitly supported.
Reported target port group is 1 [active/non-optimized]
10
[root@ca-devapm-73 lib]# sg_inq /dev/sdh
standard INQUIRY:
  PQual=0  Device_type=0  RMB=0  [ANSI_version=5]  version=0x05
  [AERC=0]  [TrmTsk=0]  NormACA=1  HiSUP=1  Resp_data_format=2
  SCCS=0  ACC=0  ALUA=1  3PC=0  Protect=0
  BQue=0  EncServ=0  MultiP=1  MChngr=0  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=0  Sync=0  Linked=0  [TranDis=0]  CmdQue=1
  Clocking=0x0  QAS=0  IUS=0
    length=182 (0xb6)   Peripheral device type: disk
 Vendor identification: Pillar
 Product identification: Axiom 500
 Product revision level: 0000
 Product serial number: 000B080000001321


I notice that sg_inq parses the relevant bit as ALUA=1 probably due to the
different inquiry spec revision.


Here's the relevant git commit log from Christophe's git tree...

commit 0803439535ea30ad1951d3deb0c5eaf894470d43
tree 1463069c297b2b5605bb03f394b26c0c1372ff03
parent fe99930b75ea5211ffb3916d6a38edd9a05e2af9
author root <root@zezette.localdomain> Fri, 26 Aug 2005 22:19:56 +0200
committer root <root@zezette.localdomain> Fri, 26 Aug 2005 22:19:56 +0200

    * path_priority/pp_alua/main.c, path_priority/pp_alua/rtpg.c,
      path_priority/pp_alua/spc3.h:

    [priority] update the alua prioritizer

    Removes bitfields in the SCSI structs.
    This didn't work on i386.

    From Stefan Bader, IBM

*****

I'll add to stefan's note that the bitfields broke x86_64 too ;-)


HTH,

brian
Comment 3 Brian Wong 2006-02-03 18:22:25 EST
Created attachment 124134 [details]
patch made with cg-mkpatch -r 0803439535ea30ad1951d3deb0c5eaf894470d43 99c1a2e54868ab81b958fbe56858f1f889fd6e90 

try this patch.  it's the fix from the git tree.
Comment 4 Ben Marzinski 2006-02-03 18:50:43 EST
Ahhh.. Everything makes more sense now.... I was looking at the current code,
not the U2 code.  This change got picked up for the U3 release.
Comment 5 Brian Wong 2006-02-03 19:08:26 EST
when is U3 getting released?  it wasn't obvious to me how to locate this
information via the website.

Note You need to log in before you can comment on or make changes to this bug.