Bug 669961 - [NetApp 5.6 Bug] Erroneous TPG ID check in SCSI ALUA Handler
Summary: [NetApp 5.6 Bug] Erroneous TPG ID check in SCSI ALUA Handler
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.6
Hardware: All
OS: All
high
high
Target Milestone: rc
: ---
Assignee: Mike Snitzer
QA Contact: Gris Ge
URL:
Whiteboard:
Depends On:
Blocks: 670572 681795
TreeView+ depends on / blocked
 
Reported: 2011-01-16 08:23 UTC by Martin George
Modified: 2011-07-21 09:39 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
For a device that used a Target Portal Group (TPG) ID which occupied the full 2 bytes in the RTPG (Report Target Port Groups) response (with either byte exceeding the maximum value that may be stored in a signed char), the kernel's calculated TPG ID would never match the group_id that it should. As a result, this signed char overflow also caused the ALUA handler to incorrectly identify the AAS (Asymmetric Access State) of the specified device as well as incorrectly interpret the supported AAS of the target. With this update, the aforementioned issue has been addressed and no longer occurs.
Clone Of:
: 670572 (view as bug list)
Environment:
Last Closed: 2011-07-21 09:39:46 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1065 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.7 kernel security and bug fix update 2011-07-21 09:21:37 UTC

Description Martin George 2011-01-16 08:23:20 UTC
Description of problem:
For Target Portal Group IDs occupying the full 2 bytes in the RTPG response, the following group_id check in the alua_rtpg routine always fails in scsi_dh_alua.c:

if (h->group_id == (ucp[2] << 8) + ucp[3]) {

This causes the ALUA handler to wrongly identify the AAS of a specified device as well as incorrectly interpreting the supported AAS of the target as seen by the following entries in the /var/log/messages:

"alua: port group 3ea state A supports tousna"
"alua: port group 3e9 state A supports tousna"

Version-Release number of selected component (if applicable):
RHEL 5.6 (2.6.18-238.el5)

Notes:
This is because 'ucp' is wrongly defined in alua_rtpg as a character pointer instead of an unsigned character pointer. The below patch fixes the problem:

--- scsi_dh_alua.c.orig 2011-01-14 16:48:37.000000000 +0530
+++ scsi_dh_alua.c      2011-01-16 10:27:54.000000000 +0530
@@ -535,7 +535,7 @@ static int alua_rtpg(struct scsi_device
 {
        struct scsi_sense_hdr sense_hdr;
        int len, k, off, valid_states = 0;
-       char *ucp;
+       unsigned char *ucp;
        unsigned err;
        unsigned long expiry, interval = 10;

Comment 2 Martin George 2011-01-18 17:37:34 UTC
This bug could break AAS handling in the ALUA handler. So it's important the fix makes it to 5.6.z itself.

Comment 3 RHEL Product and Program Management 2011-02-01 16:56:40 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 5 Jarod Wilson 2011-02-09 14:58:01 UTC
in kernel-2.6.18-243.el5
You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.

Comment 8 Martin Prpič 2011-04-14 10:17:29 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
For a device that used a Target Portal Group (TPG) ID which occupied the full 2 bytes in the RTPG (Report Target Port Groups) response (with either byte exceeding the maximum value that may be stored in a signed char), the kernel's calculated TPG ID would never match the group_id that it should. As a result, this signed char overflow also caused the ALUA handler to incorrectly identify the AAS (Asymmetric Access State) of the specified device as well as incorrectly interpret the supported AAS of the target. With this update, the aforementioned issue has been addressed and no longer occurs.

Comment 9 Gris Ge 2011-05-31 07:01:38 UTC
Mike,

I've setup a ALUA NetApp ONTAP LUN via 8 path, but noticed that multipath is still using scsi_dh for hardware handler and scsi_dh_alua.ko is not loaded.

Does this bug need any special NetApp storage?
If possible, please also provide a way for test this bug.
Thanks

Comment 10 Martin George 2011-05-31 07:22:02 UTC
(In reply to comment #9)
> Mike,
> 
> I've setup a ALUA NetApp ONTAP LUN via 8 path, but noticed that multipath is
> still using scsi_dh for hardware handler and scsi_dh_alua.ko is not loaded.
> 
You would have to set hardware_handler to '1 alua' in the multipath.conf for that. And then of course restart the multipathd daemon to let the new setting take effect.

Comment 12 Gris Ge 2011-05-31 15:14:02 UTC
I am curious why we don't enable it in default setting.
Does scsi_dh_alua.ko doesn't work well when ALUA disabled in ONTAP side (by igroup)?
If so, it's understandable for not using "1 alua" in default setting of multipath

Comment 13 Gris Ge 2011-06-27 03:02:19 UTC
Not able to hit the problem of alua_rtpg or incorrect AAS issue.

Sanity Check for following test:
1. ALUA correctly indentify AAS.
1. ALUA correctly group link.
1. multipath failover test with alua handler.

Comment 14 errata-xmlrpc 2011-07-21 09:39:46 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-1065.html


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