[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH-for-4.13 v4] Rationalize max_grant_frames and max_maptrack_frames handling



On 28.11.2019 17:47, Jürgen Groß wrote:
> On 28.11.19 17:36, Jan Beulich wrote:
>> On 28.11.2019 14:58, Paul Durrant wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -84,11 +84,43 @@ struct grant_table {
>>>       struct grant_table_arch arch;
>>>   };
>>>   
>>> +static int __init parse_gnttab_limit(const char *param, const char *arg,
>>
>> No __init please here and below, for this being runtime option
>> parsing functions.
>>
>>> +                                     unsigned int *valp)
>>> +{
>>> +    const char *e;
>>> +    unsigned long val;
>>> +
>>> +    val = simple_strtoul(arg, &e, 0);
>>> +    if ( *e )
>>> +        return -EINVAL;
>>> +
>>> +    if ( val <= INT_MAX )
>>> +        *valp = val;
>>> +    else
>>> +        printk("parameter \"%s\" value \"%s\" is out of range; using value 
>>> \"%u\"\n",
>>> +               param, arg, *valp);
>>
>> Better store INT_MAX in this case rather than leaving the value
> 
> No, INT_MAX is no good idea. In case of this happening at boot time we'd
> allocate an array of 2 billion pointers for dom0...

But we've been asked for even more. We should let the admin shoot
itself in the foot, I think.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.