From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 0D4FE3B5; Fri, 17 Feb 2017 17:53:53 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP; 17 Feb 2017 08:53:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,172,1484035200"; d="scan'208";a="48289633" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga002.jf.intel.com with ESMTP; 17 Feb 2017 08:53:52 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 17 Feb 2017 08:53:52 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.230]) by FMSMSX155.amr.corp.intel.com ([169.254.5.163]) with mapi id 14.03.0248.002; Fri, 17 Feb 2017 08:53:52 -0800 From: "Wiles, Keith" To: "Yigit, Ferruh" CC: "dev@dpdk.org" , dpdk stable Thread-Topic: [dpdk-dev] [PATCH v4] net/tap: fix coverity warning on strncpy Thread-Index: AQHSiTSWDr9dkBf1fE6a6BMvg8kxEaFt55mAgAADpQCAAAOogIAAAZ+A Date: Fri, 17 Feb 2017 16:53:51 +0000 Message-ID: <10785464-6EE2-460C-9B69-687B4F30609C@intel.com> References: <20170217154304.50214-1-keith.wiles@intel.com> <37245ce5-de84-27fb-14a7-36ad8934a8d6@intel.com> <93F4E359-E193-477D-97AD-E758BF755E75@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.93.69] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] net/tap: fix coverity warning on strncpy X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 16:53:54 -0000 > On Feb 17, 2017, at 10:48 AM, Yigit, Ferruh wrot= e: >=20 > On 2/17/2017 4:34 PM, Wiles, Keith wrote: >>=20 >>> On Feb 17, 2017, at 10:21 AM, Yigit, Ferruh wr= ote: >>>=20 >>> On 2/17/2017 3:43 PM, Keith Wiles wrote: >>>> Calling strncpy with a maximum size argument of 16 bytes on destinatio= n >>>> array "ifr.ifr_ifrn.ifrn_name" of size 16 bytes might leave the >>>> destination string unterminated. >>>>=20 >>>> Signed-off-by: Keith Wiles >>>=20 >>> net/tap: fix possibly unterminated string >>>=20 >>> Coverity issue: 1407499 >>> Fixes: 6b38b2725cdb ("net/tap: fix multi-queue support") >>> Cc: stable@dpdk.org >>>=20 >>> Applied to dpdk-next-net/master, thanks. >>>=20 >>>=20 >>> (Updates: >>> - patch title: >>> It is preferred to mention from problem solved instead of the tool that >>> found it. >>>=20 >>> - Added coverity tag: >>> This helps to trace coverity issues, defined syntax is: >>>=20 >>> Coverity issue: xxx >>> Fixes: yyyy >>>=20 >>> - Added Cc: tag for stable tree: >>> In case stable tree wants get this patch, to make patch visible. >>=20 >> I agree this is good, but to many rules not listed or checked in the too= ls. We need a much easier method to submit patches in the format that is de= fined and checked. >>=20 >> Today it is way to hard to know every little internal format for every t= ype of patch. We need to fix this problem to make it easier to submit patch= es to dpdk.org, we can not continue like this as we grow it will become way= to much work for the repo maintainers and the submitter. >=20 > That is why I am documenting what has been changed and the reasoning in > the mail, so I am hoping this is helping others that following the mail > list sync about rules. Also gives a discussion medium about rules.. Great, but we need to document this on the web site not in email. We can no= t expect someone (or a new person) to read millions of emails to find these= hidden gems, right? >=20 >>=20 >> Using a better tool then submitting via email seems like a better soluti= on as long as we can add the given checks to the tool. Using a tools should= also reduce the email traffic for most everyone, but we need to allow anyo= ne to ask for all of the commits to the repo or pull requests like patches. >>=20 >> How can we handle these types of issues in the future? >>=20 >>> ) >>=20 >> Regards, >> Keith Regards, Keith