On 6/17/19 8:13 AM, Stefano Brivio wrote:
>>
>> With strict checking (5.0 and forward):
>> - RTM_F_CLONED NOT set means dump only FIB entries
>> - RTM_F_CLONED set means dump only exceptions
>
> Okay. Should we really ignore the RFC and NLM_F_MATCH though? If we add
> field(s) to the filter, it comes almost for free, something like:
>
> if (nlh->nlmsg_flags & NLM_F_MATCH)
> filter->dump_exceptions = rtm->rtm_flags & RTM_F_CLONED;
>
> instead of:
>
> filter->dump_exceptions = rtm->rtm_flags & RTM_F_CLONED;
This is where you keep losing me. iproute2 has always set NLM_F_MATCH on
dump requests, so that flag can not be used as a discriminator here.
>
>> Without strict checking (old iproute2 on any kernel):
>> - dump all, userspace has to sort
>>
>> Kernel side this can be handled with new field, dump_exceptions, in the
>> filter that defaults to true and then is reset in the strict path if the
>> flag is not set.
>
> I guess we need to add two fields, we'll need a 'dump_routes' too.
>
> Otherwise, the dump functions can't distinguish between the three cases
> ('no strict checking', 'strict checking and RTM_F_CLONED', 'strict
> checking and no RTM_F_CLONED'). How would you do this with a single
> additional field?
>
sure, separate fields are needed for the pre-strict mode use case. So, I
take it we are converging on this:
1. non-strict mode, dump both (FIB entries and exceptions). Userspace
has to filter. This is the legacy behavior you are trying to restore.
2. strict mode:
a. dump only FIB entries if RTM_F_CLONED is not set
b. dump only exception entries if RTM_F_CLONED is set
Agreed?
Martin, others, ok with this?
