netdev - Re: [PATCH net 1/3] hv_netvsc: Correct the max receive buffer size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20171208.110313.260350833079787907.davem@davemloft.net>
Date:   Fri, 08 Dec 2017 11:03:13 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     dan.carpenter@...cle.com
Cc:     stephen@...workplumber.org, kys@...rosoft.com,
        haiyangz@...rosoft.com, sthemmin@...rosoft.com,
        devel@...uxdriverproject.org, netdev@...r.kernel.org
Subject: Re: [PATCH net 1/3] hv_netvsc: Correct the max receive buffer size

From: Dan Carpenter <dan.carpenter@...cle.com>
Date: Fri, 8 Dec 2017 13:33:25 +0300

> On Thu, Dec 07, 2017 at 04:10:53PM -0800, Stephen Hemminger wrote:
>> From: Haiyang Zhang <haiyangz@...rosoft.com>
>> 
>> It should be 31 MB on recent host versions.
>> 
>> Signed-off-by: Haiyang Zhang <haiyangz@...rosoft.com>
>> Signed-off-by: Stephen Hemminger <sthemmin@...rosoft.com>
> 
> This is very vague.  What does "recent" mean in this context?  There are
> also some unrelated white space changes here which make the patch harder
> to read.
> 
> This patch kind of makes the bug fixed by patch 2 even worse because
> before the receive buffer was capped at around 16MB and now we can set
> the receive buffer to 31MB.  It might make sense to fold the two
> patches together.
> 
> Is patch 2 a memory corruption bug?  The changelog doesn't really say
> what the user visible effects of the bug are.  Basically if you make the
> buffer too small then it's a performance issue but if you make it too
> large what happens?  It's not clear to me.

Agreed with Dan, we definitely need more verbose and detailed commit
log messages for this series.