Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758760AbcDHRRG (ORCPT ); Fri, 8 Apr 2016 13:17:06 -0400 Received: from mail-yw0-f176.google.com ([209.85.161.176]:32831 "EHLO mail-yw0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758627AbcDHRRE (ORCPT ); Fri, 8 Apr 2016 13:17:04 -0400 Date: Fri, 8 Apr 2016 13:16:53 -0400 (EDT) From: martin@omnibond.com X-X-Sender: mkb@tp.mkb.name To: Andy Shevchenko cc: Mike Marshall , "linux-kernel@vger.kernel.org" , Linux FS Devel Subject: Re: [PATCH 2/3] orangefs: strncpy -> strlcpy In-Reply-To: Message-ID: References: <1459801598-12757-1-git-send-email-martin@martinbrandenburg.com> <1459801598-12757-2-git-send-email-martin@martinbrandenburg.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1709 Lines: 54 On Fri, 8 Apr 2016, Andy Shevchenko wrote: > On Fri, Apr 8, 2016 at 6:34 PM, wrote: > >> On Thu, Apr 7, 2016 at 2:39 PM, Andy Shevchenko > >> wrote: > >> > On Mon, Apr 4, 2016 at 11:26 PM, Martin Brandenburg wrote: > >> >> From: Martin Brandenburg > >> >> > >> >> Almost everywhere we use strncpy we should use strlcpy. This affects > >> >> path names (d_name mostly), symlink targets, and server names. > >> >> > >> >> Leave debugfs code as is for now, though it could use a review as well. > >> >> > >> > > >> > |Why not strscpy() as most robust one? > > > > Mostly because I hadn't heard about strscpy. > > It was nice story how he applied it to the tree. Just read it.. > > >> It looks like strscpy went in last October... there are > >> no users of it yet. I was just about to send in a pull request > >> that includes Martin's strncpy->strlcpy patch when I saw > >> Andy's comment. > >> > >> Linus said when he pulled strscpy: > > > After looking over strscpy I don't see a compelling > > reason not to go ahead and use it while we're fixing up > > this code. > > I recommend to mention that this is a fix explicitly in the commit > message, currently it sounds like a meaningless patch of trainee. I've decided to scrap most of this, but one change is important. Most of it is a no-op because the client-core buffer is larger than NAME_MAX and there is always room. Replying with patch in a minute. Thanks for the review! Mike, I think we can delay this one for later so we can look at the debugfs and superblock code in more detail. -- Martin > > -- > With Best Regards, > Andy Shevchenko >