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