Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp516520ybz; Fri, 17 Apr 2020 05:27:51 -0700 (PDT) X-Google-Smtp-Source: APiQypJz616ohIAix97kFk2bkut17GkUaK0GkQQiVf5rRs+ztJ8HVSbXHfE1Y7fYTfQ0L3ti3iyS X-Received: by 2002:aa7:d14e:: with SMTP id r14mr2785151edo.200.1587126471001; Fri, 17 Apr 2020 05:27:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587126470; cv=none; d=google.com; s=arc-20160816; b=z/doKoOHSdHKdwN8Y9LwYPJCspcaMCnWVU9JkefnBV3lG7/rjsXQMCf7B6enIufj8Y 9/CU2g0DKj6ZQ/Et6GpVB1pspP6NbDy0Zk313D49hUScP7dtzH+5Ztagj1x37SX0nHpf jBxiuU8+1vdziyMVfjdTiXspLY2SGHW5IUUPIIRm93PocSadX7OKfjUQ4GBH6vyfyOf6 BuLJpvv4cDtQb6DX/0Puho1zUSCBZr5K4TJbLz6HkJRrxZHLATONwOEwbmsZ7o4aPjGO DVE3KpY4dJufQGQBm9LZSXPJfIVPQQhHbNR03Sxvevc0afe3vjV8E3PwJzlavE3sHV7m 0WYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=b3iFtRhJs5VqWIfspmC5p02IfQnZ1OBoJDiilSZitow=; b=QTERGGYpgMI3gXBbhkyms20BHrIrxWdp15CalsbxXbqcEjqiYFXSvdacFwvLNJSkl0 iArNUlW552CubBGOzlDoRSLHKWJ0RzERsnC8jf+d19lEOBEVwhKAcfknVrWW4FcG2oZc 1fe0YU3ywc1HNyrJj8j6tEXyl/9dq2TZRIsVT8H308lYuNqUHGpMuzqxXzM1m31g0LQm CsHqVEGXU8tdEmg3vu+PsjpwUJGrKULHnERwioortiC04JVyoEn9dqPCnoswz+w136Ll NDIMLDk7jquppEr4d1jGaJlxoROoc1tHj0Uox1RakdRjqM+6zqeulT4pAJJ2JCbq/UDv zFsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=Z9Ljm0d8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jz18si13839981ejb.112.2020.04.17.05.27.27; Fri, 17 Apr 2020 05:27:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=Z9Ljm0d8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729079AbgDQMZq (ORCPT + 99 others); Fri, 17 Apr 2020 08:25:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1728958AbgDQMZp (ORCPT ); Fri, 17 Apr 2020 08:25:45 -0400 Received: from mail-qv1-xf41.google.com (mail-qv1-xf41.google.com [IPv6:2607:f8b0:4864:20::f41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61439C061A0F for ; Fri, 17 Apr 2020 05:25:45 -0700 (PDT) Received: by mail-qv1-xf41.google.com with SMTP id q73so757228qvq.2 for ; Fri, 17 Apr 2020 05:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=b3iFtRhJs5VqWIfspmC5p02IfQnZ1OBoJDiilSZitow=; b=Z9Ljm0d8QguBsl++bS9kVtdhIXM4iGBa3wZPoDF+/p5QDbbf+Ecx1WOeV/KWVqEAXj ABy5J6+w2bDlgPY3w06H5Xmi/cS0kRvv5T8Ra6TZWtYIBGQu5I4Rx4AHl3+T2gROjJUI 0J0m16+FNgCJ90BwzGrj3pRV6Zus7SXB4Rjqp3UWJLn4YHfKIy4u4rXgTAeGs3KE6EUt wQD9z1iG0OEn/tMOLZCt4+Kkayd7XfuvCsNuXdb4ntlg7V35JxLrywkpo+GJvWBjweCZ Ep0gCRUjFRU+1N/O3lHk6ytDkXA+SH1mGrPuTDCuKZHiafjG1shCNAuJ0aW6sHAig3B0 xd2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=b3iFtRhJs5VqWIfspmC5p02IfQnZ1OBoJDiilSZitow=; b=jfFpmLi4AK32yKP6DfIbaQA4sONVG2MShj+TnumPiNp3PC0w0DOkv/oWdy24JQ1Q1W vdw91v7XJBWT2hrB7W9dvXLmB9sfOVx/BhCyDlYTmw55qf52qaSUrOxdLefrLpmqdvOH GccZ8lPfidLucErKu80b1zrTntmNvatDrUjN/AR2sLmzxKq8IMpQ8lcUFJ5B3k/vnffT 2vkVxdbnNpGAxnbEYN7X7QSKj4z0w1xqU/ZbeEENvvKZ+Dl14o3NAUtXnoxrpSXkezol swx6i1PrNl5nnTRSyRH4+Qn9MaGb2AXKpAbGRUuXS/nWCbOz40YW7Icu1jZx+r5HwthV IQJw== X-Gm-Message-State: AGi0Pua3gT/OH+/hgixIC4XcWA2AIE+6mxv0wXICE5unmtbrHeskBPLz pnsFo/Kb23HtbYDWl2opFzt10Q== X-Received: by 2002:ad4:4c4d:: with SMTP id cs13mr2347165qvb.207.1587126344506; Fri, 17 Apr 2020 05:25:44 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-68-57-212.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.57.212]) by smtp.gmail.com with ESMTPSA id k2sm17252465qte.16.2020.04.17.05.25.43 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 Apr 2020 05:25:43 -0700 (PDT) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1jPQ3y-0006eb-6h; Fri, 17 Apr 2020 09:25:42 -0300 Date: Fri, 17 Apr 2020 09:25:42 -0300 From: Jason Gunthorpe To: Dan Carpenter , g@ziepe.ca Cc: Christophe JAILLET , selvin.xavier@broadcom.com, devesh.sharma@broadcom.com, dledford@redhat.com, leon@kernel.org, colin.king@canonical.com, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [PATCH] RDMA/ocrdma: Fix an off-by-one issue in 'ocrdma_add_stat' Message-ID: <20200417122542.GC5100@ziepe.ca> References: <20200328073040.24429-1-christophe.jaillet@wanadoo.fr> <20200414183441.GA28870@ziepe.ca> <20200416130847.GP1163@kadam> <20200416184754.GZ5100@ziepe.ca> <20200417112624.GS1163@kadam> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200417112624.GS1163@kadam> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 17, 2020 at 02:26:24PM +0300, Dan Carpenter wrote: > On Thu, Apr 16, 2020 at 03:47:54PM -0300, Jason Gunthorpe wrote: > > On Thu, Apr 16, 2020 at 04:08:47PM +0300, Dan Carpenter wrote: > > > On Tue, Apr 14, 2020 at 03:34:41PM -0300, Jason Gunthorpe wrote: > > > > The memcpy is still kind of silly right? What about this: > > > > > > > > static int ocrdma_add_stat(char *start, char *pcur, char *name, u64 count) > > > > { > > > > size_t len = (start + OCRDMA_MAX_DBGFS_MEM) - pcur; > > > > int cpy_len; > > > > > > > > cpy_len = snprintf(pcur, len, "%s: %llu\n", name, count); > > > > if (cpy_len >= len || cpy_len < 0) { > > > > > > The kernel version of snprintf() doesn't and will never return > > > negatives. It would cause a huge security headache if it started > > > returning negatives. > > > > Begs the question why it returns an int then :) > > People should use "int" as their default type. "int i;". It means > "This is a normal number. Nothing special about it. It's not too high. > It's not defined by hardware requirements." Other types call attention > to themselves, but int is the humble datatype. No, I strongly disagree with this, it is one of my pet peeves to see 'int' being used for data which is known to be only ever be positive just to save typing 'unsigned'. Not only is it confusing, but allowing signed values has caused tricky security bugs, unfortuntely. Jason