[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180131190749.Horde.bsc7GhewsZwdnkmDtMlSwWO@gator4166.hostgator.com>
Date: Wed, 31 Jan 2018 19:07:49 -0600
From: "Gustavo A. R. Silva" <garsilva@...eddedor.com>
To: Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc: "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
"Wong Hoi Sing, Edison" <hswong3i@...il.com>,
"Hung Hing Lun, Mike" <hlhung3i@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tcp_lp: use 64-bit arithmetic instead of 32-bit
Hi Alan,
Quoting Alan Cox <gnomes@...rguk.ukuu.org.uk>:
> On Wed, 31 Jan 2018 18:24:07 -0600
> "Gustavo A. R. Silva" <gustavo@...eddedor.com> wrote:
>
>> Cast to s64 some variables and a macro in order to give the
>> compiler complete information about the proper arithmetic to
>> use. Notice that these elements are used in contexts that
>> expect expressions of type s64 (64 bits, signed).
>>
>> Currently such expression are being evaluated using 32-bit
>> arithmetic.
>
> The question you need to ask is 'can it overflow 32bit maths', otherwise
> you are potentially making the system do extra work for no reason.
>
Yeah, I get your point and it seems that in this particular case there
is no risk of a 32bit overflow, but in general and IMHO as the code
evolves, the use of incorrect arithmetic may have security
implications in the future, so I advocate for code correctness in this
case.
Thanks
--
Gustavo
Powered by blists - more mailing lists