Message ID | 1466088738-16990-1-git-send-email-slawomirx.mrozowicz@intel.com (mailing list archive) |
---|---|
State | Changes Requested, archived |
Delegated to: | Thomas Monjalon |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 1F95CC6E4; Thu, 16 Jun 2016 15:52:34 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 1D3EBC66A for <dev@dpdk.org>; Thu, 16 Jun 2016 15:52:31 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 16 Jun 2016 06:52:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,480,1459839600"; d="scan'208";a="977043185" Received: from gklab-246-019.igk.intel.com (HELO intel.com) ([10.217.246.19]) by orsmga001.jf.intel.com with SMTP; 16 Jun 2016 06:52:12 -0700 Received: by intel.com (sSMTP sendmail emulation); Thu, 16 Jun 2016 16:52:21 +0200 From: Slawomir Mrozowicz <slawomirx.mrozowicz@intel.com> To: david.marchand@6wind.com Cc: dev@dpdk.org, Slawomir Mrozowicz <slawomirx.mrozowicz@intel.com> Date: Thu, 16 Jun 2016 16:52:18 +0200 Message-Id: <1466088738-16990-1-git-send-email-slawomirx.mrozowicz@intel.com> X-Mailer: git-send-email 1.9.1 Subject: [dpdk-dev] [PATCH v5] eal: out-of-bounds write X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Slawomir Mrozowicz
June 16, 2016, 2:52 p.m. UTC
Overrunning array mcfg->memseg of 256 44-byte elements
at element index 257 using index j.
Fixed by add condition with message information.
Fixes: af75078fece3 ("first public release")
Coverity ID 13282
Signed-off-by: Slawomir Mrozowicz <slawomirx.mrozowicz@intel.com>
---
v5:
- update message
v4:
- remove check condition from loop
v3:
- add check condition inside and outside the loop
v2:
- add message information
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 8 ++++++++
1 file changed, 8 insertions(+)
Comments
2016-06-16 16:52, Slawomir Mrozowicz: > Overrunning array mcfg->memseg of 256 44-byte elements > at element index 257 using index j. > Fixed by add condition with message information. > > Fixes: af75078fece3 ("first public release") > Coverity ID 13282 Please use this formatting: Coverity issue: 13282 > Signed-off-by: Slawomir Mrozowicz <slawomirx.mrozowicz@intel.com> > --- > v5: > - update message > v4: > - remove check condition from loop > v3: > - add check condition inside and outside the loop > v2: > - add message information The changelog is OK. Please use --in-reply-to when making a new revision to keep them in the same thread. > --- a/lib/librte_eal/linuxapp/eal/eal_memory.c > +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c > @@ -1301,6 +1301,14 @@ rte_eal_hugepage_init(void) > break; > } > No newline needed here. The check is directly related to the previous loop. > + if (j >= RTE_MAX_MEMSEG) { It is out of the scope of this patch but I REALLY HATE this variable j. Considering a more meaningful rename would be a nice patch. > + RTE_LOG(ERR, EAL, > + "All memory segments exhausted by IVSHMEM. " There is no evidence that it is related to IVSHMEM. "Not enough memory segments." would be more appropriate. > + "Try recompiling with larger RTE_MAX_MEMSEG " > + "then current %d\n", RTE_MAX_MEMSEG); then -> than
On 20/06/2016 10:14, Thomas Monjalon wrote: >> + RTE_LOG(ERR, EAL, >> + "All memory segments exhausted by IVSHMEM. " > There is no evidence that it is related to IVSHMEM. > "Not enough memory segments." would be more appropriate. Actually we would hit this issue when all memsegs have been used by IVSHMEM. So I think the message is accurate. Am I missing something? Sergio
2016-06-20 10:38, Sergio Gonzalez Monroy: > On 20/06/2016 10:14, Thomas Monjalon wrote: > >> + RTE_LOG(ERR, EAL, > >> + "All memory segments exhausted by IVSHMEM. " > > There is no evidence that it is related to IVSHMEM. > > "Not enough memory segments." would be more appropriate. > > Actually we would hit this issue when all memsegs have been used by IVSHMEM. > So I think the message is accurate. I think it's saner to avoid mixing "potential root cause of a use case" and "accurate description of the error". One day, the root cause could be different and the message will become wrong. Here there is not enough memory segment.
On 20/06/2016 11:09, Thomas Monjalon wrote: > 2016-06-20 10:38, Sergio Gonzalez Monroy: >> On 20/06/2016 10:14, Thomas Monjalon wrote: >>>> + RTE_LOG(ERR, EAL, >>>> + "All memory segments exhausted by IVSHMEM. " >>> There is no evidence that it is related to IVSHMEM. >>> "Not enough memory segments." would be more appropriate. >> Actually we would hit this issue when all memsegs have been used by IVSHMEM. >> So I think the message is accurate. > I think it's saner to avoid mixing "potential root cause of a use case" and > "accurate description of the error". > One day, the root cause could be different and the message will become wrong. > Here there is not enough memory segment. > Right. So the whole point of doing the check before the loop was to display the error message with its specific cause. I would think that if the code changes and the message is not accurate then it should also be updated. So if folks prefer a more generic error message probably we don't need the check before the loop and just change the check condition inside the loop that would end up printing the generic error message (after the loop). Basically v1 would do that. http://dpdk.org/dev/patchwork/patch/12241/ Sergio
Hi Thomas, As I understand Sergio suggested to come back to the solution similar to v1. Could you comment or better take decision which solution should be applied, please. Best Regards, SÅ‚awomir >-----Original Message----- >From: Gonzalez Monroy, Sergio >Sent: Monday, June 20, 2016 1:29 PM >To: Thomas Monjalon <thomas.monjalon@6wind.com> >Cc: Mrozowicz, SlawomirX <slawomirx.mrozowicz@intel.com>; >dev@dpdk.org; david.marchand@6wind.com >Subject: Re: [dpdk-dev] [PATCH v5] eal: out-of-bounds write > >On 20/06/2016 11:09, Thomas Monjalon wrote: >> 2016-06-20 10:38, Sergio Gonzalez Monroy: >>> On 20/06/2016 10:14, Thomas Monjalon wrote: >>>>> + RTE_LOG(ERR, EAL, >>>>> + "All memory segments exhausted by IVSHMEM. " >>>> There is no evidence that it is related to IVSHMEM. >>>> "Not enough memory segments." would be more appropriate. >>> Actually we would hit this issue when all memsegs have been used by >IVSHMEM. >>> So I think the message is accurate. >> I think it's saner to avoid mixing "potential root cause of a use >> case" and "accurate description of the error". >> One day, the root cause could be different and the message will become >wrong. >> Here there is not enough memory segment. >> > >Right. >So the whole point of doing the check before the loop was to display the error >message with its specific cause. > >I would think that if the code changes and the message is not accurate then it >should also be updated. > >So if folks prefer a more generic error message probably we don't need the >check before the loop and just change the check condition inside the loop that >would end up printing the generic error message (after the loop). > >Basically v1 would do that. >http://dpdk.org/dev/patchwork/patch/12241/ > >Sergio
2016-07-21 12:01, Mrozowicz, SlawomirX: > Hi Thomas, > > As I understand Sergio suggested to come back to the solution similar to v1. > Could you comment or better take decision which solution should be applied, please. > > Best Regards, > SÅ‚awomir > > > >-----Original Message----- > >From: Gonzalez Monroy, Sergio > >On 20/06/2016 11:09, Thomas Monjalon wrote: > >> 2016-06-20 10:38, Sergio Gonzalez Monroy: > >>> On 20/06/2016 10:14, Thomas Monjalon wrote: > >>>>> + RTE_LOG(ERR, EAL, > >>>>> + "All memory segments exhausted by IVSHMEM. " > >>>> There is no evidence that it is related to IVSHMEM. > >>>> "Not enough memory segments." would be more appropriate. > >>> Actually we would hit this issue when all memsegs have been used by > >IVSHMEM. > >>> So I think the message is accurate. > >> I think it's saner to avoid mixing "potential root cause of a use > >> case" and "accurate description of the error". > >> One day, the root cause could be different and the message will become > >wrong. > >> Here there is not enough memory segment. > >> > > > >Right. > >So the whole point of doing the check before the loop was to display the error > >message with its specific cause. > > > >I would think that if the code changes and the message is not accurate then it > >should also be updated. > > > >So if folks prefer a more generic error message probably we don't need the > >check before the loop and just change the check condition inside the loop that > >would end up printing the generic error message (after the loop). > > > >Basically v1 would do that. > >http://dpdk.org/dev/patchwork/patch/12241/ At this point of 16.07 we can apply the v1 if you agree. The message about IVSHMEM will be totally wrong when the ivshmem specific code will be removed. If we need more error messages, feel free to send another patch.
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c index 5b9132c..ffe069c 100644 --- a/lib/librte_eal/linuxapp/eal/eal_memory.c +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c @@ -1301,6 +1301,14 @@ rte_eal_hugepage_init(void) break; } + if (j >= RTE_MAX_MEMSEG) { + RTE_LOG(ERR, EAL, + "All memory segments exhausted by IVSHMEM. " + "Try recompiling with larger RTE_MAX_MEMSEG " + "then current %d\n", RTE_MAX_MEMSEG); + return -ENOMEM; + } + for (i = 0; i < nr_hugefiles; i++) { new_memseg = 0;