Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp6402604imm; Mon, 27 Aug 2018 15:25:36 -0700 (PDT) X-Google-Smtp-Source: ANB0VdailuR4lyxrGmFOYF7Boo2ty2152dUvMIEbOokxBPoQSG226UvxE4Drg7plB0QG4pAtkb+R X-Received: by 2002:a63:790b:: with SMTP id u11-v6mr13946388pgc.111.1535408735973; Mon, 27 Aug 2018 15:25:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535408735; cv=none; d=google.com; s=arc-20160816; b=PBKYkC17CFPdzZAL7HZowbgdTZot5hL51iE2nVDM9z1TVQ9ToArR72IYV4IE+uhtx6 Nw/xhEdX5zQs1H9Z7mI3pqcqAFGQ+gfBRbfDLpxh3gH/cdUoRSocVoFNqeif0clz0SYZ ib/iAdWHAfLCVsG9ZtU7YU2tXf5tOffN1WQ4jIvgMajHxdjLb9h/6TU8sB3covB/MVGr hU98+6dJmSAAr7ktPtdpf6T2IYyVA9lrQijx4YIs8vDObczsIPOmLQLp9dmA6y5RkmzV IUF83UDM6qLUnI03xxm0i3DS2LNIfioCixwhiylisnfO/6lwScG2box9D03EvK3jTFPU XbSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date :arc-authentication-results; bh=T+Cy2vHktvV0gdTXzA37hejVcXya8+OGHHJRrOWD+K8=; b=tGz/DFpPaWOw8/vnbZlr5kU3zQBXT3dAP4K5mwCXWFoWocAadgsMRrlBqo8H/8OukF jhxeGVcMgM2URrY4dYALi/PdPEyGqWCU6ZrenG7gwQeFMHbmd9RrEAQqErgoBJBi7fw1 c6LQCiGtr19QVeRpBBsraucbjtljaLlZ4W/mJjUw/b7vSIDkbtHOAJlHWAgSbRSGpNSh yQjiVjvkekmYTowJ7qUdVZu9tw5eHw2bZmdflg+0jpYoyVaBTSnZYUlDJz1SVDypYij6 abhQjgHSt/tWOQ0iy7xf4c1/MrMoYl/Z/9qLUW6UZ5TJUhTk6qkdHmVD7ZIOYs9Zy7wE PyMg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r12-v6si131485pgm.141.2018.08.27.15.25.18; Mon, 27 Aug 2018 15:25:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727271AbeH1CMh (ORCPT + 99 others); Mon, 27 Aug 2018 22:12:37 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:33688 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727013AbeH1CMh (ORCPT ); Mon, 27 Aug 2018 22:12:37 -0400 Received: from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net [74.93.104.98]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id CE6A71474BECB; Mon, 27 Aug 2018 15:24:02 -0700 (PDT) Date: Mon, 27 Aug 2018 15:24:02 -0700 (PDT) Message-Id: <20180827.152402.1358178279473378697.davem@davemloft.net> To: Haiqing.Bai@windriver.com Cc: netdev@vger.kernel.org, jon.maloy@ericsson.com, ying.xue@windriver.com, zhenbo.gao@windriver.com, linux-kernel@vger.kernel.org Subject: Re: [V2][PATCH net] tipc: fix the big/little endian issue in tipc_dest From: David Miller In-Reply-To: <1535333546-16753-1-git-send-email-Haiqing.Bai@windriver.com> References: <1535333546-16753-1-git-send-email-Haiqing.Bai@windriver.com> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 27 Aug 2018 15:24:03 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Haiqing Bai Date: Mon, 27 Aug 2018 09:32:26 +0800 > In function tipc_dest_push, the 32bit variables 'node' and 'port' > are stored separately in uppper and lower part of 64bit 'value'. > Then this value is assigned to dst->value which is a union like: > union > { > struct { > u32 port; > u32 node; > }; > u64 value; > } > This works on little-endian machines like x86 but fails on big-endian > machines. > > The fix remove the 'value' stack parameter and even the 'value' > member of the union in tipc_dest, assign the 'node' and 'port' member > directly with the input parameter to avoid the endian issue. > > Fixes: a80ae5306a73 ("tipc: improve destination linked list") > > Signed-off-by: Zhenbo Gao > Acked-by: Jon Maloy > Signed-off-by: Haiqing Bai Applied and queued up for -stable.