From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id 8B7FA5A65 for ; Tue, 7 Jul 2015 11:00:55 +0200 (CEST) Received: by wgbgr6 with SMTP id gr6so7714440wgb.3 for ; Tue, 07 Jul 2015 02:00:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=+/uM7IXixugr4npyFBbHtEkB6uLg3WW4AQVCJDmlEgY=; b=IDtBXwdPc0VvQF2MDhwDtpx7COQfO3qBJW6Y+hE9Jg19GIoU6HSxQ114+wS6biHz71 bxiIifQrjDVm3R2dn3n/giAJ5CQboWi40Dpj8k1j8qFHmlzJ2BBJoXRbZBgzmHST3sR9 QjP4lhm31HQJWamsixrX7blIP7OCUP8yJIrY9ZXsWa04+UAIqCzw/gTQZxG1vVT4nAyK UQiD0Vkn1jY0U/Tl4/5CN68cOzFpgYlSbjj29quSSXECBpMRcqQTaL8RzBnmbRztunG9 y2I+3S+WRmkEP1bWdojUmkDY8TyezEl3jl4JXYcNZonbXkF7vzYQk/cVTocxFC7bL2Cl IT+w== X-Gm-Message-State: ALoCoQkTQFvIdxx1MYOfbbv9dBqIikg8mPRirghDQQXGMc5LigFGTL7fhy+IQUlSXvcrEZmq9BFl X-Received: by 10.180.75.198 with SMTP id e6mr48684047wiw.37.1436259655446; Tue, 07 Jul 2015 02:00:55 -0700 (PDT) Received: from alcyon.dev.6wind.com (6wind.net2.nerim.net. [213.41.151.210]) by mx.google.com with ESMTPSA id y19sm32737674wia.15.2015.07.07.02.00.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 02:00:54 -0700 (PDT) From: David Marchand To: dev@dpdk.org Date: Tue, 7 Jul 2015 11:00:34 +0200 Message-Id: <1436259634-7077-7-git-send-email-david.marchand@6wind.com> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: <1436259634-7077-1-git-send-email-david.marchand@6wind.com> References: <1436259634-7077-1-git-send-email-david.marchand@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] =?utf-8?q?=5BPATCH_6/6=5D_eal/linux=3A_avoid_out_of_bo?= =?utf-8?q?und_access?= X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 09:00:55 -0000 Using IBM advance toolchain on Ubuntu 14.04 (package 8.0-3), gcc is complaining about out of bound accesses. CC eal_hugepage_info.o lib/librte_eal/linuxapp/eal/eal_hugepage_info.c: In function ‘eal_hugepage_info_init’: lib/librte_eal/linuxapp/eal/eal_hugepage_info.c:350:35: error: array subscript is above array bounds [-Werror=array-bounds] internal_config.hugepage_info[j].hugepage_sz) ^ lib/librte_eal/linuxapp/eal/eal_hugepage_info.c:350:35: error: array subscript is above array bounds [-Werror=array-bounds] lib/librte_eal/linuxapp/eal/eal_hugepage_info.c:349:37: error: array subscript is above array bounds [-Werror=array-bounds] if (internal_config.hugepage_info[j-1].hugepage_sz < ^ lib/librte_eal/linuxapp/eal/eal_hugepage_info.c:350:35: error: array subscript is above array bounds [-Werror=array-bounds] internal_config.hugepage_info[j].hugepage_sz) Looking at the code, these warnings are invalid from my pov and they disappeared when upgrading the toolchain to new version (8.0-4). However, the code was buggy (sorting code is wrong), so fix this by using qsort and adding a check on num_sizes to avoid potential out of bound accesses. Signed-off-by: David Marchand --- lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 31 ++++++++++------------- 1 file changed, 14 insertions(+), 17 deletions(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c index df60f6e..2f96164 100644 --- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c +++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c @@ -184,15 +184,6 @@ get_hugepage_dir(uint64_t hugepage_sz) return retval; } -static inline void -swap_hpi(struct hugepage_info *a, struct hugepage_info *b) -{ - char buf[sizeof(*a)]; - memcpy(buf, a, sizeof(buf)); - memcpy(a, b, sizeof(buf)); - memcpy(b, buf, sizeof(buf)); -} - /* * Clear the hugepage directory of whatever hugepage files * there are. Checks if the file is locked (i.e. @@ -263,6 +254,15 @@ error: return -1; } +static int +compare_hpi(const void *a, const void *b) +{ + const struct hugepage_info *hpi_a = a; + const struct hugepage_info *hpi_b = b; + + return hpi_b->hugepage_sz - hpi_a->hugepage_sz; +} + /* * when we initialize the hugepage info, everything goes * to socket 0 by default. it will later get sorted by memory @@ -289,6 +289,9 @@ eal_hugepage_info_init(void) dirent_start_len) != 0) continue; + if (num_sizes >= MAX_HUGEPAGE_SIZES) + break; + hpi = &internal_config.hugepage_info[num_sizes]; hpi->hugepage_sz = rte_str_to_size(&dirent->d_name[dirent_start_len]); @@ -343,14 +346,8 @@ eal_hugepage_info_init(void) internal_config.num_hugepage_sizes = num_sizes; /* sort the page directory entries by size, largest to smallest */ - for (i = 0; i < num_sizes; i++) { - unsigned j; - for (j = i+1; j < num_sizes; j++) - if (internal_config.hugepage_info[j-1].hugepage_sz < - internal_config.hugepage_info[j].hugepage_sz) - swap_hpi(&internal_config.hugepage_info[j-1], - &internal_config.hugepage_info[j]); - } + qsort(&internal_config.hugepage_info[0], num_sizes, + sizeof(internal_config.hugepage_info[0]), compare_hpi); /* now we have all info, check we have at least one valid size */ for (i = 0; i < num_sizes; i++) -- 1.7.10.4