On Wed, Aug 28, 2019 at 09:36:41PM -0700, Roopa Prabhu wrote: > > yes, correct. I mentioned that because I was wondering if we can > think along the same lines for this API. > eg > (a) RTM_NEWLINK always replaces the list attribute > (b) RTM_SETLINK with NLM_F_APPEND always appends to the list attribute > (c) RTM_DELLINK with NLM_F_APPEND updates the list attribute > > (It could be NLM_F_UPDATE if NLM_F_APPEND sounds weird in the del > case. I have not looked at the full dellink path if it will work > neatly..its been a busy day )
AFAICS rtnl_dellink() calls nlmsg_parse_deprecated() so that even current code would ignore any future attribute in RTM_DELLINK message (any kernel before the strict validation was introduced definitely will) and it does not seem to check NLM_F_APPEND or NLM_F_UPDATE either. So unless I missed something, such message would result in deleting the network device (if possible) with any kernel not implementing the feature. Michal
