LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ajay Singh <ajay.kathat@microchip.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: devel@driverdev.osuosl.org,
"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
linux-wireless@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org,
Ganesh Krishna <ganesh.krishna@microchip.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] staging: wilc1000: fix infinite loop and out-of-bounds access
Date: Wed, 2 May 2018 15:12:29 +0530 [thread overview]
Message-ID: <20180502151229.4be29ec8@ajaysk-VirtualBox> (raw)
In-Reply-To: <20180502083935.uw4mxvcgnpayv3h3@mwanda>
On Wed, 2 May 2018 11:39:36 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> 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...
>
As in this case, its fine to be of 'int' type.
So we can retain the current data type('int') for 'i' and 'slot_id'.
Thank you for sharing your insights,it was very helpful.
Regards,
Ajay
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
prev parent reply other threads:[~2018-05-02 9:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 12:50 Gustavo A. R. Silva
2018-04-30 14:29 ` Ajay Singh
2018-04-30 15:23 ` Dan Carpenter
2018-05-02 5:47 ` Ajay Singh
2018-05-02 8:39 ` Dan Carpenter
2018-05-02 9:42 ` Ajay Singh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180502151229.4be29ec8@ajaysk-VirtualBox \
--to=ajay.kathat@microchip.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=ganesh.krishna@microchip.com \
--cc=gregkh@linuxfoundation.org \
--cc=gustavo@embeddedor.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--subject='Re: [PATCH] staging: wilc1000: fix infinite loop and out-of-bounds access' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).