From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 070D7C76188 for ; Mon, 22 Jul 2019 09:33:27 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 8E09121E6B for ; Mon, 22 Jul 2019 09:33:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E09121E6B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 894841BF5D; Mon, 22 Jul 2019 11:33:25 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 65F3E1BF48; Mon, 22 Jul 2019 11:33:23 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2019 02:33:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,294,1559545200"; d="scan'208";a="368461235" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.83]) ([10.237.220.83]) by fmsmga006.fm.intel.com with ESMTP; 22 Jul 2019 02:33:20 -0700 To: Ogawa Yasufumi , david.marchand@redhat.com Cc: dev@dpdk.org, stable@dpdk.org References: <1555379952-23517-1-git-send-email-ogawa.yasufumi@lab.ntt.co.jp> <20190711103148.9187-1-yasufum.o@gmail.com> <20190711103148.9187-2-yasufum.o@gmail.com> <99d2853d-f6f9-59f2-f853-0f9222e8cb5d@gmail.com> From: "Burakov, Anatoly" Message-ID: Date: Mon, 22 Jul 2019 10:33:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3 1/1] fbarray: get fbarrays from containerized secondary X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 22-Jul-19 2:06 AM, Ogawa Yasufumi wrote: > > > 2019年7月12日(金) 11:22 Yasufumi Ogawa >: > > On 2019/07/11 22:14, Burakov, Anatoly wrote: > > On 11-Jul-19 12:57 PM, Yasufumi Ogawa wrote: > >> On 2019/07/11 19:53, Burakov, Anatoly wrote: > >>> On 11-Jul-19 11:31 AM, yasufum.o@gmail.com > wrote: > >>>> From: Yasufumi Ogawa > > >>>> > >>> <...> > >>> > >>>> +    if (getpid() == 1) { > >>>> +        FILE *hn_fp; > >>>> +        hn_fp = fopen("/etc/hostname", "r"); > >>>> +        if (hn_fp == NULL) { > >>>> +            RTE_LOG(ERR, EAL, > >>>> +                "Cannot open '/etc/hostname' for secondary\n"); > >>>> +            return -1; > >>>> +        } > >>>> + > >>>> +        /* with docker, /etc/hostname just has one entry of > >>>> hostname */ > >>>> +        if (fscanf(hn_fp, "%s", proc_id) == EOF) { > >>> > >>> Apologies for not pointing this out earlier, but do i understand > >>> correctly that there's no bounds checking here, and fscanf() will > >>> write however many bytes it wants? > >> I understand "%s" is not appropriate. hostname is 12 bytes char > and I > >> thought proc_id[16] is enough, but it is unsafe. In addition, > hostname > >> can be defined by user with docker's option, so it should be enough > >> for user defined name. > >> > >> How do you think expecting max 32 chars of hostname and set > boundary > >> "%32s" as following? > >> > >>      proc_id[33];  /* define proc id from hostname less than 33 > bytes. */ > >>      ... > >>      if (fscanf(hn_fp, "%32s", proc_id) == EOF) { > >> > > > > As long as it takes NULL-termination into account as well, it > should be > > OK. I can't recall off the top of my head if %32s includes NULL > > terminator (probably not?). > Do you agree if initialize with NULL chars to ensure proc_id is > NULL-terminated? As tested on my environment, "%Ns" sets next of Nth > char as NULL, but it seems more reliable. >      proc_id[33] = { 0 }; > > Hi Anatoly, > > I would like to send v4 patch if it is agreeable. Yes, please do. As a side note, you don't need to ask anyone's permission to send a patch :) > > > Yasufumi > -- Thanks, Anatoly