netdev - [PATCH] net: Make synchronize_net() be expedited only when it's really need

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-next>] [day] [month] [year] [list]

Date:   Mon, 22 Jan 2018 12:41:41 +0300
From:   Kirill Tkhai <ktkhai@...tuozzo.com>
To:     edumazet@...gle.com, netdev@...r.kernel.org, davem@...emloft.net,
        ktkhai@...tuozzo.com
Cc:     dsahern@...il.com, fw@...len.de, lucien.xin@...il.com,
        daniel@...earbox.net, mschiffer@...verse-factory.net,
        jakub.kicinski@...ronome.com, vyasevich@...il.com, jbenc@...hat.com
Subject: [PATCH] net: Make synchronize_net() be expedited only when it's
 really need

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@...tuozzo.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);