On Thu, Jan 17, 2013 at 12:51 PM, Pravin Shelar <pshe...@nicira.com> wrote:
> On Wed, Jan 16, 2013 at 6:41 PM, Jesse Gross <je...@nicira.com> wrote:
>> On Wed, Jan 16, 2013 at 1:54 PM, Pravin B Shelar <pshe...@nicira.com> wrote:
>>> diff --git a/datapath/datapath.c b/datapath/datapath.c
>>> index ed69af8..4ed40e2 100644
>>> --- a/datapath/datapath.c
>>> +++ b/datapath/datapath.c
>>> +static struct nlattr *reserve_sfa_size(struct sw_flow_actions **sfa, int
>>> attr_len)
>>> +{
>>> +
>>> + struct sw_flow_actions *new;
>>> + struct nlattr *a;
>>> +
>>> + if (NLA_ALIGN(attr_len) <= (ksize(*sfa) - (*sfa)->actions_len))
>>> + goto out;
>>> +
>>> + if (ksize(*sfa) * 2 > MAX_ACTIONS_BUFSIZE)
>>> + return ERR_PTR(-EMSGSIZE);
>>
>> It's possible that the current size is smaller than
>> MAX_ACTIONS_BUFSIZE but 2 * size is larger. This probably is not
>> likely because kmalloc will round up to a power of two and
>> MAX_ACTIONS_BUFSIZE is a power of two but I'm not sure that we want to
>> implicitly assume that.
>>
> right , so max allocation will of size MAX_ACTIONS_BUFSIZE. should we
> increment size more slowly?
I don't mean to increment more slowly but to make sure that we
actually hit MAX_ACTIONS_BUFSIZE. If the initial allocation and
MAX_ACTIONS_BUFSIZE are powers of two and we increment by a factor of
two then this is guaranteed. However, if it's not then we could end
up in a situation where the current buffer is 10k and the max is 16k
so we wouldn't increase the size because that would put us over the
limit. I would either allow us to go to 16k in this case or ensure
that the safe conditions are always true.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
