netdev - Re: [PATCH RFC net-next 1/7] net: Fix fib notifer to return errno

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180325081632.GA11327@splinter>
Date:   Sun, 25 Mar 2018 11:16:32 +0300
From:   Ido Schimmel <idosch@...sch.org>
To:     David Ahern <dsa@...ulusnetworks.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        roopa@...ulusnetworks.com, shm@...ulusnetworks.com,
        jiri@...lanox.com, idosch@...lanox.com,
        jakub.kicinski@...ronome.com
Subject: Re: [PATCH RFC net-next 1/7] net: Fix fib notifer to return errno

On Thu, Mar 22, 2018 at 03:57:51PM -0700, David Ahern wrote:
> Notifier handlers use notifier_from_errno to convert any potential error
> to an encoded format. As a consequence the other side, call_fib_notifiers
> in this case, needs to use notifier_to_errno to return the error from
> the handler back to its caller.
> 
> Signed-off-by: David Ahern <dsa@...ulusnetworks.com>
> ---
>  net/core/fib_notifier.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/net/core/fib_notifier.c b/net/core/fib_notifier.c
> index 5ace0705a3f9..14ba52ebe8c9 100644
> --- a/net/core/fib_notifier.c
> +++ b/net/core/fib_notifier.c
> @@ -21,8 +21,11 @@ EXPORT_SYMBOL(call_fib_notifier);
>  int call_fib_notifiers(struct net *net, enum fib_event_type event_type,
>  		       struct fib_notifier_info *info)

There's another (less interesting case) - call_fib_notifier(), which is
used to dump the FIB tables for the caller registering to the
notification chain.

For example, if you have a non-default FIB rule in the system and you
modprobe mlxsw, you'll get a silent failure and routes will not be
offloaded. On the other hand, I'm not sure we want to fail the module
loading in such cases.

A possible solution is to have the driver emit a warning via extack for
each route/rule being notified after the abort mechanism was triggered.

>  {
> +	int err;
> +
>  	info->net = net;
> -	return atomic_notifier_call_chain(&fib_chain, event_type, info);
> +	err = atomic_notifier_call_chain(&fib_chain, event_type, info);
> +	return notifier_to_errno(err);
>  }
>  EXPORT_SYMBOL(call_fib_notifiers);
>  
> -- 
> 2.11.0
>