From patchwork Thu Aug 21 05:07:11 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: dongmao zhang X-Patchwork-Id: 4755601 X-Patchwork-Delegate: snitzer@redhat.com Return-Path: X-Original-To: patchwork-dm-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 356F0C0338 for ; Thu, 21 Aug 2014 05:12:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6CF3D2015E for ; Thu, 21 Aug 2014 05:12:40 +0000 (UTC) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) by mail.kernel.org (Postfix) with ESMTP id 688842015A for ; Thu, 21 Aug 2014 05:12:39 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7L57vqg013869; Thu, 21 Aug 2014 01:07:58 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s7L57tZ4030527 for ; Thu, 21 Aug 2014 01:07:55 -0400 Received: from mx1.redhat.com (ext-mx16.extmail.prod.ext.phx2.redhat.com [10.5.110.21]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7L57sR1025329; Thu, 21 Aug 2014 01:07:55 -0400 Received: from victor.provo.novell.com (victor.provo.novell.com [137.65.250.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7L57qQw002169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Aug 2014 01:07:53 -0400 Received: from linux-ifim.site (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by victor.provo.novell.com with ESMTP (TLS encrypted); Wed, 20 Aug 2014 23:07:40 -0600 Message-ID: <53F57E7F.2090705@suse.com> Date: Thu, 21 Aug 2014 13:07:11 +0800 From: zhangdongmao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brassow Jonathan References: <1407459365-697-1-git-send-email-dmzhang@suse.com> <589E3349-24C0-4CBD-AA99-6F537BCDAAFB@redhat.com> <53F413A6.2000409@suse.com> <9FC3B4B3-9310-41FF-8E89-709A8790549E@redhat.com> In-Reply-To: <9FC3B4B3-9310-41FF-8E89-709A8790549E@redhat.com> X-RedHat-Spam-Score: -4.201 (BAYES_00,RCVD_IN_DNSWL_MED,SPF_PASS) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Scanned-By: MIMEDefang 2.68 on 10.5.110.21 X-loop: dm-devel@redhat.com Cc: device-mapper development Subject: Re: [dm-devel] [PATCH] convert dm_ulog_request data to little endian X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk Reply-To: device-mapper development List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > v5_endian_from_network() only gets called if it is needed. I suspect there is a bug here, 'clog_request_to_network' should detect if big endian is being used and switch it to little endian. In-coming communication must always be little endian. I'm not sure which end the problem is on (I think the send side). You could add some prints to detect the issue. > > lvm2/daemons/cmirrord/cluster.c:cluster_send() sets two version numbers - one is forced to be little endian via xlate64(). 'clog_request_to_network()' is then called and compares the two version numbers. If they are different, the machine is big endian and the contents must be converted. If this is not happening, it is bad. Then, *from_network() performs a similar action and test and then must xlate back to big endian. If this is not happening, it is bad. So, for big endian machines, ensure that v5_endian_*_network() is being called. (For little endian, it should not be.) > > brassow hi, brassow , There might be a bug in v5_endian_to_network when sending packet. If the machine were big-endian, v5_endian_to_network will convert request_type to little endian. But in v5_data_endian_switch, it will check request_type again, and this check will failed because request_type is already converted to little endian. So my solution to this is to delay xlate32 of u_rq->request_type. On the other hand, when receiving package in clog_request_from_network. I think the vp[0] will always be little endian. we could use xlate64(vp[0]) == vp[0] to decide if the local node is little endian or not. if local node is little endian, we do nothing, if the local node is big endian, we have to call v5_endian_from_network to convert little endian to big endian. But for now, I have not had a chance to test this patch on s390 here's the patch: @@ -187,7 +188,7 @@ int clog_request_from_network(void *data, size_t data_len) switch (version) { case 5: /* Upstream */ - if (version == unconverted_version) + if (version == vp[0]) return 0; break; case 4: /* RHEL 5.[45] */ Dongmao Zhang --- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel diff --git a/daemons/cmirrord/compat.c b/daemons/cmirrord/compat.c index 3f7a9b5..c9cb803 100644 --- a/daemons/cmirrord/compat.c +++ b/daemons/cmirrord/compat.c @@ -126,13 +126,14 @@ static int v5_endian_to_network(struct clog_request *rq) u_rq->error = xlate32(u_rq->error); u_rq->seq = xlate32(u_rq->seq); - u_rq->request_type = xlate32(u_rq->request_type); u_rq->data_size = xlate64(u_rq->data_size); rq->originator = xlate32(rq->originator); v5_data_endian_switch(rq, 1); + rq->u_rq.request_type = xlate32(rq->u_rq.request_type); + return size; }