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 [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
