On 05/22/2012 08:05 AM, Peter Krempa wrote:

>>> +
>>> +struct remote_connect_list_all_domains_ret {
>>> +    remote_nonnull_domain domains<>;
>>
>> This is an unbounded array; we aren't using any of these anywhere else.
>>   I wonder if reusing REMOTE_DOMAIN_ID_LIST_MAX would be reasonable
>> instead.  Then again, we are returning more information per domain: a
>> name, uuid, and id, so maybe REMOTE_DOMAIN_NAME_LIST_MAX is the best we
>> can do (currently 1024, but then again there is the pending patch to
>> raise that limit).  The name element may make us run into RPC limits
>> even if we don't otherwise enforce a limit.
>>
> 
> I chose the unbounded array intentionaly as I don't see any point in
> applying two limits on the size of the RPC message. I agree that the
> global message size limit is good for avoiding DoS attacks.

Interesting point - maybe it's worth re-evaluating which of our existing
limits should be made unbounded, under the umbrella of the overall RPC
limits being good enough.

> 
> I'll add the limit to conform with the rest of the code and hopefuly
> nobody will need more than 1024 machines soon.

Yeah, if we decide to go with unbounded structs within the scope of a
bounded maximum message, we should probably do it across the entire .x
file at once.

-- 
Eric Blake   ebl...@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to