Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2343202ybz; Thu, 23 Apr 2020 16:23:41 -0700 (PDT) X-Google-Smtp-Source: APiQypKQFjPUBooONcXG+79G5B8iY5TqejXQMHLpNxq44Gw/2Ik2nR1Lghwcu7d0Q2iaCSJOxLBU X-Received: by 2002:a50:f61b:: with SMTP id c27mr4640399edn.256.1587684221756; Thu, 23 Apr 2020 16:23:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587684221; cv=none; d=google.com; s=arc-20160816; b=0HvLSUpB1jEvoroJF/BMZE1jodpSqN/vXDqQeoA7ua9AiB9rN3IB1gqQMCR5SoIkhE G1BxP0tSymNIRFvVi5V4QqEqoxaUWo5IYkyljCS3ScmYHJMWJRcB9yW4cJ6gvH1ksbHh Jy5cc8EBET0VbPE7HoJAdcGv700znKtnJMfQA9VPts54i3fkgF5asXgHhPny018ykHt4 fBp5Jp8RWtBPINfoGH1LnsFwJ1kaJ34BGGmRYtYoZ4QfdwHCMSnCDG3tasdoR7l12tVj 9gzCxiHaRGqbIYLAzCjRlsw7i+mdGHcLogpGLXpZBdLShfxrnq9A9e91JdZmk/fuRYus +UOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=ZZfRPxAQdHaZomQC7sUN9nJJCdJ657fBTf+oS+FU9FA=; b=Pv+USMoTy/KATyQaqP72SYy2aY970/TXsGFHJKn0rBOpUf6ITPuSEKlXO+LxSz4eAV Pj9OnJICIvr2UNw5myqaUqR6dvf8PwjJkhTpx+RURK4JCJ8q06uYJnRZ3tt1F88nvjuU bPDmyJtE0VDc3eRUmBNmK09fp4exrnVoFW7XC5NEBAaNKiT0nGsogAuGjwBrV2NQ8Cqu 2oxo/DTQXf8ZHEbXVf5AzewgIdI759341+BROn+7aNAF3Gra8axApbVG5Y+ujyv8RXjw jXt0XiDBtQHbSwd+9p+9KnFo3mHpfXMjcW+ea/pRYku5qeVEk14PgyJLtMLfKYkvNVHC pjeg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l4si2068872ede.294.2020.04.23.16.23.18; Thu, 23 Apr 2020 16:23:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729137AbgDWXT7 (ORCPT + 99 others); Thu, 23 Apr 2020 19:19:59 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:48662 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728227AbgDWXGe (ORCPT ); Thu, 23 Apr 2020 19:06:34 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvL-0004bv-Qp; Fri, 24 Apr 2020 00:06:27 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvK-00E6j1-BH; Fri, 24 Apr 2020 00:06:26 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Simon Wunderlich" , "Sven Eckelmann" Date: Fri, 24 Apr 2020 00:04:48 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 061/245] batman-adv: Fix DAT candidate selection on little endian systems In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Sven Eckelmann commit 4cc4a1708903f404d2ca0dfde30e71e052c6cbc9 upstream. The distributed arp table is using a DHT to store and retrieve MAC address information for an IP address. This is done using unicast messages to selected peers. The potential peers are looked up using the IP address and the VID. While the IP address is always stored in big endian byte order, this is not the case of the VID. It can (depending on the host system) either be big endian or little endian. The host must therefore always convert it to big endian to ensure that all devices calculate the same peers for the same lookup data. Fixes: be1db4f6615b ("batman-adv: make the Distributed ARP Table vlan aware") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- net/batman-adv/distributed-arp-table.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/net/batman-adv/distributed-arp-table.c +++ b/net/batman-adv/distributed-arp-table.c @@ -207,9 +207,11 @@ static uint32_t batadv_hash_dat(const vo { uint32_t hash = 0; const struct batadv_dat_entry *dat = data; + __be16 vid; hash = batadv_hash_bytes(hash, &dat->ip, sizeof(dat->ip)); - hash = batadv_hash_bytes(hash, &dat->vid, sizeof(dat->vid)); + vid = htons(dat->vid); + hash = batadv_hash_bytes(hash, &vid, sizeof(vid)); hash += (hash << 3); hash ^= (hash >> 11);