From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 06ED9A0540;
Tue, 14 Jul 2020 11:34:11 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id D0F7F1D163;
Tue, 14 Jul 2020 11:34:10 +0200 (CEST)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
by dpdk.org (Postfix) with ESMTP id F11A81BEBC
for <dev@dpdk.org>; Tue, 14 Jul 2020 11:34:08 +0200 (CEST)
IronPort-SDR: Odk8a5zcJEFU5kHDZHkTtjnoM5Q2FQiw22feQ5MrZeozxLLPQ0obVb2HDoS9eeL2Bt5appPwhF
3iN/DTw32u2g==
X-IronPort-AV: E=McAfee;i="6000,8403,9681"; a="136992866"
X-IronPort-AV: E=Sophos;i="5.75,350,1589266800"; d="scan'208";a="136992866"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21])
by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
14 Jul 2020 02:34:07 -0700
IronPort-SDR: JLJZK7yjynFI7OzYJ2jmm9uV77y4tfSgRxpE7d42SmBk+/5DSQv/AoaBlzaZ481NvmtIP/wvGl
qmWRrJgdrhLg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.75,350,1589266800"; d="scan'208";a="299476041"
Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.55.216])
([10.252.55.216])
by orsmga002.jf.intel.com with ESMTP; 14 Jul 2020 02:34:06 -0700
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, David Hunt <david.hunt@intel.com>, reshma.pattan@intel.com
References: <c568269db57a81ab8fecac06f81c1054f6439100.1594642553.git.anatoly.burakov@intel.com>
<42bebf7cebd2b635a60b626faf605df6d8a277c1.1594652063.git.anatoly.burakov@intel.com>
<20200713153321.GJ694@bricha3-MOBL.ger.corp.intel.com>
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <8f11d232-1484-c62b-f970-53c114518d15@intel.com>
Date: Tue, 14 Jul 2020 10:34:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20200713153321.GJ694@bricha3-MOBL.ger.corp.intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v2 1/2] power: fix power management env
detection
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On 13-Jul-20 4:33 PM, Bruce Richardson wrote:
> On Mon, Jul 13, 2020 at 03:54:27PM +0100, Anatoly Burakov wrote:
>> Anything coming from sysfs has a newline at the end. Cut it off before
>> comparing the strings.
>>
>> Fixes: 20ab67608a39 ("power: add environment capability probing")
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>> Acked-by: David Hunt <david.hunt@intel.com>
>> ---
>> lib/librte_power/power_common.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/lib/librte_power/power_common.c b/lib/librte_power/power_common.c
>> index 59023d986b..22b016ca9d 100644
>> --- a/lib/librte_power/power_common.c
>> +++ b/lib/librte_power/power_common.c
>> @@ -15,6 +15,7 @@ int
>> cpufreq_check_scaling_driver(const char *driver_name)
>> {
>> unsigned int lcore_id = 0; /* always check core 0 */
>> + size_t end_idx;
>> char fullpath[PATH_MAX];
>> char readbuf[PATH_MAX];
>> char *s;
>> @@ -39,6 +40,13 @@ cpufreq_check_scaling_driver(const char *driver_name)
>> if (s == NULL)
>> return 0;
>>
>> + /* when read from sysfs, driver name has an extra newline at the end */
>> + end_idx = strnlen(readbuf, sizeof(readbuf));
>> + /* prevent underflow if len is zero */
>> + if (end_idx > 0)
>> + end_idx--;
>> + readbuf[end_idx] = '\0';
>> +
> Would it not be safer to add " && readbuf[end_idx - 1] == '\n'" to the
> condition, to check that it's terminated as expected? Theoretically if we
> had a long string returned which was truncated, or only just fit, there
> would not be a '\n' at the end.
>
> /Bruce
>
Yep, true, however unlikely :) I'll submit a v3.
--
Thanks,
Anatoly