On 5/24/19 2:59 AM, Nicolas Dichtel wrote:
> Before the patch:
> $ ip netns add foo
> $ ip link add name veth1 address 2a:a5:5c:b9:52:89 type veth peer name veth2 
> address 2a:a5:5c:b9:53:90 netns foo
> RTNETLINK answers: No such device
> RTNETLINK answers: No such device
> 
> But the command was successful. This may break script. Let's remove those
> error messages.
> 
> Fixes: 55870dfe7f8b ("Improve batch and dump times by caching link lookups")
> Reported-by: Philippe Guibert <philippe.guib...@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dich...@6wind.com>
> ---
>  lib/ll_map.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/ll_map.c b/lib/ll_map.c
> index 2d7b65dcb8f7..e0ed54bf77c9 100644
> --- a/lib/ll_map.c
> +++ b/lib/ll_map.c
> @@ -177,7 +177,7 @@ static int ll_link_get(const char *name, int index)
>               addattr_l(&req.n, sizeof(req), IFLA_IFNAME, name,
>                         strlen(name) + 1);
>  
> -     if (rtnl_talk(&rth, &req.n, &answer) < 0)
> +     if (rtnl_talk_suppress_rtnl_errmsg(&rth, &req.n, &answer) < 0)
>               goto out;
>  
>       /* add entry to cache */
> 

In general, ll_link_get suppressing the error message seems like the
right thing to do.

For the example above, seems like nl_get_ll_addr_len is the cause of the
error messages, and it should not be called for this use case (NEWLINK
with NLM_F_CREATE set)

Reply via email to