From patchwork Thu Jun 9 18:50:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jesse Gross X-Patchwork-Id: 633134 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from archives.nicira.com (archives.nicira.com [96.126.127.54]) by ozlabs.org (Postfix) with ESMTP id 3rQZC06SXMz9s4x for ; Fri, 10 Jun 2016 04:51:08 +1000 (AEST) Received: from archives.nicira.com (localhost [127.0.0.1]) by archives.nicira.com (Postfix) with ESMTP id 25E8010BDA; Thu, 9 Jun 2016 11:51:08 -0700 (PDT) X-Original-To: dev@openvswitch.org Delivered-To: dev@openvswitch.org Received: from mx1e3.cudamail.com (mx1.cudamail.com [69.90.118.67]) by archives.nicira.com (Postfix) with ESMTPS id 8AFF310BD0 for ; Thu, 9 Jun 2016 11:51:06 -0700 (PDT) Received: from bar5.cudamail.com (localhost [127.0.0.1]) by mx1e3.cudamail.com (Postfix) with ESMTPS id 181214200C7 for ; Thu, 9 Jun 2016 12:51:06 -0600 (MDT) X-ASG-Debug-ID: 1465498265-09eadd2ecf05ca0001-byXFYA Received: from mx1-pf1.cudamail.com ([192.168.24.1]) by bar5.cudamail.com with ESMTP id 1XYcwBrF6I6I0BNw (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 09 Jun 2016 12:51:05 -0600 (MDT) X-Barracuda-Envelope-From: jesse@kernel.org X-Barracuda-RBL-Trusted-Forwarder: 192.168.24.1 Received: from unknown (HELO mail.kernel.org) (198.145.29.136) by mx1-pf1.cudamail.com with ESMTPS (DHE-RSA-AES256-SHA encrypted); 9 Jun 2016 18:51:05 -0000 Received-SPF: none (mx1-pf1.cudamail.com: domain at kernel.org does not designate permitted sender hosts) X-Barracuda-Apparent-Source-IP: 198.145.29.136 X-Barracuda-RBL-IP: 198.145.29.136 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2422320222 for ; Thu, 9 Jun 2016 18:51:04 +0000 (UTC) Received: from localhost.localdomain (c-71-202-123-143.hsd1.ca.comcast.net [71.202.123.143]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6EC302021F for ; Thu, 9 Jun 2016 18:51:03 +0000 (UTC) X-CudaMail-Envelope-Sender: jesse@kernel.org From: Jesse Gross To: dev@openvswitch.org X-CudaMail-Whitelist-To: dev@openvswitch.org X-CudaMail-MID: CM-E1-608060969 X-CudaMail-DTE: 060916 X-CudaMail-Originating-IP: 198.145.29.136 Date: Thu, 9 Jun 2016 11:50:32 -0700 X-ASG-Orig-Subj: [##CM-E1-608060969##][PATCH] tun-metadata: Use correct offset when accessing fragmented metadata. Message-Id: <1465498232-96859-1-git-send-email-jesse@kernel.org> X-Mailer: git-send-email 2.5.0 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, UNPARSEABLE_RELAY autolearn=ham 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 X-Barracuda-Connect: UNKNOWN[192.168.24.1] X-Barracuda-Start-Time: 1465498265 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://web.cudamail.com:443/cgi-mod/mark.cgi X-ASG-Whitelist: Header =?UTF-8?B?eFwtY3VkYW1haWxcLXdoaXRlbGlzdFwtdG8=?= X-Virus-Scanned: by bsmtpd at cudamail.com X-Barracuda-BRTS-Status: 1 Subject: [ovs-dev] [PATCH] tun-metadata: Use correct offset when accessing fragmented metadata. X-BeenThere: dev@openvswitch.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dev-bounces@openvswitch.org Sender: "dev" Since tunnel metadata is stored in a fixed area in the flow match field, we must allocate space for options as they are registered with the switch. In order to avoid exposing implementation complexity to the controller, we support fragmentation when we run out of contiguous blocks that are large enough to handle new requests. When reading or writing to these fragmented blocks, there is a bug that would cause us to keep on using the area after the allocated space rather than moving to the next offset. This corrects that to use the offset for each block. Unfortunately, while we did have a test for this exact use case, since the same bug was present in both reading and writing code, everything appeared to work as normal from the outside. Signed-off-by: Jesse Gross Acked-by: Jarno Rajahalme --- lib/tun-metadata.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/tun-metadata.c b/lib/tun-metadata.c index a773aea..7a2a84f 100644 --- a/lib/tun-metadata.c +++ b/lib/tun-metadata.c @@ -490,7 +490,7 @@ memcpy_to_metadata(struct tun_metadata *dst, const void *src, int addr = 0; while (chain) { - memcpy(dst->opts.u8 + loc->c.offset + addr, (uint8_t *)src + addr, + memcpy(dst->opts.u8 + chain->offset, (uint8_t *)src + addr, chain->len); addr += chain->len; chain = chain->next; @@ -507,7 +507,7 @@ memcpy_from_metadata(void *dst, const struct tun_metadata *src, int addr = 0; while (chain) { - memcpy((uint8_t *)dst + addr, src->opts.u8 + loc->c.offset + addr, + memcpy((uint8_t *)dst + addr, src->opts.u8 + chain->offset, chain->len); addr += chain->len; chain = chain->next;