All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Kirill Tkhai <ktkhai@virtuozzo.com>,
	edumazet@google.com, netdev@vger.kernel.org, davem@davemloft.net
Cc: dsahern@gmail.com, fw@strlen.de, lucien.xin@gmail.com,
	daniel@iogearbox.net, mschiffer@universe-factory.net,
	jakub.kicinski@netronome.com, vyasevich@gmail.com,
	jbenc@redhat.com
Subject: Re: [PATCH] net: Make synchronize_net() be expedited only when it's really need
Date: Mon, 22 Jan 2018 09:15:17 -0800	[thread overview]
Message-ID: <1516641317.3478.8.camel@gmail.com> (raw)
In-Reply-To: <151661402727.29441.3116565394148374460.stgit@localhost.localdomain>

On Mon, 2018-01-22 at 12:41 +0300, Kirill Tkhai wrote:
> Commit be3fc413da9e "net: use synchronize_rcu_expedited()" introducing
> synchronize_net() says:
> 
>     >When we hold RTNL mutex, we would like to spend some cpu cycles but not
>     >block too long other processes waiting for this mutex.
>     >We also want to setup/dismantle network features as fast as possible at
>     >boot/shutdown time.
>     >This patch makes synchronize_net() call the expedited version if RTNL is
>     >locked.
> 
> At the time of the commit (May 23 2011) there was no possible to differ,
> who is the actual owner of the mutex. Only the fact that it's locked
> by someone at the moment. So (I guess) this is the only reason the generic
> primitive mutex_is_locked() was used.
> 
> But now mutex owner is available outside the locking subsystem and
> __mutex_owner() may be used instead (there is an example in audit_log_start()).
> So, let's make expensive synchronize_rcu_expedited() be used only
> when a caller really owns rtnl_mutex().
> 
> There are several possibilities to fix that. The first one is
> to fix synchronize_net(), the second is to change rtnl_is_locked().
> 
> I prefer the second, as it seems it's more intuitive for people
> to think that rtnl_is_locked() is about current process, not
> about the fact mutex is locked in general. Grep over kernel
> sources just proves this fact:
> 
> drivers/staging/rtl8723bs/os_dep/osdep_service.c:297
> drivers/staging/rtl8723bs/os_dep/osdep_service.c:316
> 
>         if (!rtnl_is_locked())
>                 ret = register_netdev(pnetdev);
>         else
>                 ret = register_netdevice(pnetdev);
> 
> drivers/staging/wilc1000/linux_mon.c:310
> 
> 	if (rtnl_is_locked()) {
> 		rtnl_unlock();
> 		rollback_lock = true;
> 	}
> 
> Side effect of this patch is three BUGs in above examples
> become fixed.
> 
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
> ---
>  net/core/rtnetlink.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 16d644a4f974..a5ddf373ffa9 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -117,7 +117,7 @@ EXPORT_SYMBOL(rtnl_trylock);
>  
>  int rtnl_is_locked(void)
>  {
> -	return mutex_is_locked(&rtnl_mutex);
> +	return __mutex_owner(&rtnl_mutex) == current;
>  }
>  EXPORT_SYMBOL(rtnl_is_locked);
>  
> 

Seems good to me, but this looks a net-next candidate to me.

Note that this does not catch illegal uses from BH, where current is
not related to our context of execution.

  reply	other threads:[~2018-01-22 17:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-22  9:41 [PATCH] net: Make synchronize_net() be expedited only when it's really need Kirill Tkhai
2018-01-22 17:15 ` Eric Dumazet [this message]
2018-01-23 14:41   ` Kirill Tkhai
2018-01-23 15:12     ` Eric Dumazet
2018-01-23 15:29       ` Kirill Tkhai
2018-01-23 15:45         ` Eric Dumazet
2018-01-23 15:57           ` Kirill Tkhai
2018-01-23 16:05             ` Eric Dumazet
2018-01-23 16:31               ` Kirill Tkhai
2018-01-23 16:58                 ` Eric Dumazet
2018-01-23 17:09                   ` Kirill Tkhai
2018-01-23 17:13                     ` Eric Dumazet
2018-01-23 17:22                       ` Kirill Tkhai
2018-01-23 17:34                         ` Eric Dumazet
2018-01-23 17:43                           ` Kirill Tkhai
2018-01-23 16:26 ` Stephen Hemminger
2018-01-23 16:36   ` Kirill Tkhai
2018-01-24  2:16   ` Kirill Tkhai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1516641317.3478.8.camel@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=jakub.kicinski@netronome.com \
    --cc=jbenc@redhat.com \
    --cc=ktkhai@virtuozzo.com \
    --cc=lucien.xin@gmail.com \
    --cc=mschiffer@universe-factory.net \
    --cc=netdev@vger.kernel.org \
    --cc=vyasevich@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.