Received: by 10.192.165.148 with SMTP id m20csp375443imm; Wed, 2 May 2018 01:40:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrJEl6IIXkaaIzNLDLgw+/jL+Wb1gfni7FO5zA1pFvUm8jwBIzsMnmTmAblav0qMl9vYlTm X-Received: by 2002:a65:5504:: with SMTP id f4-v6mr1264464pgr.177.1525250429386; Wed, 02 May 2018 01:40:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525250429; cv=none; d=google.com; s=arc-20160816; b=ILbqyu3tur8bLkeofv8ogXvbxNVIL8kZq+ESaxvgOZ3EzAJ5hKFe7g+MhrAl/E/e/c Jd4jE6Zk4KwVPhbdDyaq2zu7aTaQ5/8x49cR6xqnSOBl3RXEcFdXLEOv9J8yVb2xenq/ RyL64LQQeynE81S9rAJNMteFBxwXRWbeCPsc6wEy1RRhhHgohk4ob1XSKSheYI+oXj35 VH86dvhgYzZ7nPp6F1pIyZZrokJeMAUBG0H/i5F8BO5q90Egg9nBgpVihmjVC9ZTdNQX 3X127cOOVWEv0uJdnzmd/YykzozvsjN1EWpAT5qSf74QvbFocjMGKZfvqXTLxFUVni/v Faqg== 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:arc-authentication-results; bh=w+JyoRQkfGqawBKk6bDhSsOVnVagYM8dTAKXnG5ieak=; b=MCfkQnHWIlVslDhbcLZz++jueEyazc9jC0cifSWHhSZG7HDnaL+frM1ZTNUTcYJdIh pKAeKadxkZpMBqGavBYoD/k1UaVGgzy48b8d34YhqGV+kSjr5qFzEw9FG0z7DE8lrZXg mWhFi5q+vXw4EZGWiZAgkFJFkd0igVd2cD/nGAvuRah/LVkg26X84vhHDINWGSGVC9LU nsH7v/l4lOsKtBWTr5CqSES7CBKG3AAX8C+8CzFtFf9RqKPjGGs+K5ynyJ+gcuBUArQB /ml8vSQOJdZHXfqSbZhgKz8JnIrd2Pzrff8Wqj4Mvb5izik2ZDDiKucPgP2dnPz8N4ZT mlXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=dTM5DNob; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c196-v6si9349533pga.494.2018.05.02.01.40.13; Wed, 02 May 2018 01:40:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=dTM5DNob; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751080AbeEBIkD (ORCPT + 99 others); Wed, 2 May 2018 04:40:03 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:51038 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750897AbeEBIkB (ORCPT ); Wed, 2 May 2018 04:40:01 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w427LNij018779; Wed, 2 May 2018 08:39:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2017-10-26; bh=w+JyoRQkfGqawBKk6bDhSsOVnVagYM8dTAKXnG5ieak=; b=dTM5DNob8/504K+DU/OcqsPQk1CWW0vXb4SbhmQ8MbnRHeWzm25HqAAsKN9htdSrMcnt a+m3wVTp45KHLJeowVfbAHxAcsWpKtQboToTHSlhb30ZHI9k3lpjJuRwhSmfoMMAkFO9 GoMJ7N/RbDf+NKzhNG8CIF7pA8E+C/1uF5tOoQrYxGyzOTnShhncd917EEH1kGA3Q4u0 V6bBKJwg3/+7yUpbTmV/+92Xd/QnGf/E26gytBpB2eeQD/Ez2TagLV6Dpym7/8sv7GlX kPuukM/ENJ4qdWgZrrUqbMtiCinzx4hNgDJ+RopEK7nS/7AePO9LVORHPI8Zg2UHqdxF vg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2hmgdjjp3v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 02 May 2018 08:39:46 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w428djlq026212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 May 2018 08:39:46 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w428diHB021087; Wed, 2 May 2018 08:39:45 GMT Received: from mwanda (/197.254.35.146) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2018 01:39:44 -0700 Date: Wed, 2 May 2018 11:39:36 +0300 From: Dan Carpenter To: Ajay Singh Cc: devel@driverdev.osuosl.org, "Gustavo A. R. Silva" , linux-wireless@vger.kernel.org, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, Ganesh Krishna , Greg Kroah-Hartman Subject: Re: [PATCH] staging: wilc1000: fix infinite loop and out-of-bounds access Message-ID: <20180502083935.uw4mxvcgnpayv3h3@mwanda> References: <20180430125040.GA19050@embeddedor.com> <20180430195916.596a93eb@ajaysk-VirtualBox> <20180430152321.7pq4ol2ed7tzsrl4@mwanda> <20180502111735.5a2c6faa@ajaysk-VirtualBox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180502111735.5a2c6faa@ajaysk-VirtualBox> User-Agent: NeoMutt/20170609 (1.8.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8880 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805020074 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We're mainly discussing readability, right? To me when people use "int" that tells me as a reader that we don't need to think about the type. It's going to be a small number. Say you have data which the user can control, then it's super important to focus on the data types. We don't focus on it enough. There is some kind of idea that good developers should just be super focused on everything all the time, but I don't think humans can do it. So to me it's useful when the author tells me, "This an int type. It's fine. This is not critical." If you make request->n_ssids a u8 or u16, that isn't going to save any memory because the struct is padded. You'd also need to audit a bunch of code to make sure that we don't overflow the u16. If you wanted to overflow the int, you'd need to allocate several gigs of memory but kmalloc() is capped at KMALLOC_MAX_SIZE (4MB) so that's not possible. How many of these structs do we allocate? Is it really worth optimizing the heck out of it? There are times where want to be very deliberate with our types because we're dealing the large numbers, or user data or fast paths. But there are other times where int is fine... regards, dan carpenter