On Wed, Dec 14, 2016 at 10:39:35PM +0100, Łukasz Rząsik wrote: > I was not worrying about this problem because I assumed it was already > there. A user could provide a very long list of integers and this would > affect memory in similar way. There is a limit for how long the list could > get, kernel's limit on size of arguments, so in reality the list would not > get that long but this is outside of OVS control. > > Of course with the change it's much easier for a user to specify something > that will explode OVS memory.
That's the issue. Of course a user could provide a long list before, but it was obvious to him that he was doing so. Now, it's trivial and can be done without intent. > I would propose three possible solutions, starting from the easiest and > simplest: > 1. Specify an arbitrary limit for size of a range. If a user specifies a > range bigger than the limit, OVS will abort the command and inform the user > about the limit. Actually most of the columns in the database already have > a limit. Quickly looking through the schema I found only one without the > limit: cfm_remote_mpids in Interface table. > 2. Internally split very big ranges into smaller ones and commit each range > separately. > 3. Create a new struct, e.g. ovsdb_atom_range. Instead of adding every atom > separately to datum, add the struct, send it to the database and handle it > on the database side. > > What do you think about it? Maybe I'm missing something? Do you have a > solution in mind? I think a simple way to start out would be to introduce an arbitrary 4096-element maximum. That covers the common networking use case of a set of VLANs. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
