Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Mar 2017 17:53:12 +0200
From:      Toomas Soome <tsoome@me.com>
To:        Ian Lepore <ian@freebsd.org>
Cc:        Slawa Olhovchenkov <slw@zxy.spb.ru>, Toomas Soome <tsoome@FreeBSD.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r315653 - in head: lib/libstand sys/boot/common sys/boot/i386/libi386
Message-ID:  <EBAA7588-B735-438A-A851-77A8B7DC63CC@me.com>
In-Reply-To: <1490109312.13094.41.camel@freebsd.org>
References:  <201703202220.v2KMKHVP050735@repo.freebsd.org> <20170321123547.GC86500@zxy.spb.ru> <1490109312.13094.41.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help


> On 21. märts 2017, at 17:15, Ian Lepore <ian@freebsd.org> wrote:
> 
> On Tue, 2017-03-21 at 15:35 +0300, Slawa Olhovchenkov wrote:
>> On Mon, Mar 20, 2017 at 10:20:17PM +0000, Toomas Soome wrote:
>> 
>>> 
>>> Author: tsoome
>>> Date: Mon Mar 20 22:20:17 2017
>>> New Revision: 315653
>>> URL: https://svnweb.freebsd.org/changeset/base/315653
>>> 
>>> Log:
>>>   loader: verify the value from dhcp.interface-mtu and use snprintf
>>> to set mtu
>>>   
>>>   Since the uset can set dhcp.interface-mtu, we need to try to
>>> validate the
>>>   value. So we verify if the conversion to int is successful and we
>>> will not
>>>   allow to set value greater than max IPv4 packet size.
>>>   
>>> +				    tmp > USHRT_MAX) {
>>> +					printf("%s: bad value:
>>> \"%s\", "
>>> +					    "ignoring\n",
>>> +					    "dhcp.interface-mtu",
>>> val);
>> ===
>> USHRT_MAX	Maximum value for an object of type unsigned short
>> int
>> 65535 (216-1) or greater*
>> 
>> * the actual value depends on the particular system and library
>> implementation, but shall reflect the limits of these types in the
>> target platform.
>> ===
>> 
>> I mean IF_MAXMTU more correct.
>> 
> 
> The context here is libstand; because it is standalone by design, the
> code doesn't have access to IF_MAXMTU or other kernel/userland
> constants.  There is also no question that a short is 16 bits or that
> USHRT_MAX will be anything other than 65535 in that environment.  If
> some platform did appear that had a different-sized short by default,
> we would add whatever flags are necessary to force it back to 16 bits
> in src/share/mk/bsd.stand.mk.
> 


Also note the “upper” value is entirely fictional - we felt we need to pick some “sane” default, with current (common 1Gb/s) ethernet hardware you will be in trouble long before reaching that value;)

rgds,
toomas




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EBAA7588-B735-438A-A851-77A8B7DC63CC>