netdev - RE: [PATCH net v3 1/5] net: stmmac: Fix incorrect location to set real_num_rx|tx

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]

Date:   Fri, 24 Jan 2020 08:56:28 +0000
From:   "Ong, Boon Leong" <boon.leong.ong@...el.com>
To:     Jose Abreu <Jose.Abreu@...opsys.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "Tan, Tee Min" <tee.min.tan@...el.com>,
        "Voon, Weifeng" <weifeng.voon@...el.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        "David S . Miller" <davem@...emloft.net>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        "Joao Pinto" <Joao.Pinto@...opsys.com>,
        Arnd Bergmann <arnd@...db.de>,
        "Alexandru Ardelean" <alexandru.ardelean@...log.com>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net v3 1/5] net: stmmac: Fix incorrect location to set
 real_num_rx|tx_queues



>-----Original Message-----
>From: Jose Abreu <Jose.Abreu@...opsys.com>
>Sent: Wednesday, January 22, 2020 5:56 PM
>To: Ong, Boon Leong <boon.leong.ong@...el.com>; netdev@...r.kernel.org
>Cc: Tan, Tee Min <tee.min.tan@...el.com>; Voon, Weifeng
><weifeng.voon@...el.com>; Giuseppe Cavallaro <peppe.cavallaro@...com>;
>Alexandre TORGUE <alexandre.torgue@...com>; David S . Miller
><davem@...emloft.net>; Maxime Coquelin <mcoquelin.stm32@...il.com>;
>Joao Pinto <Joao.Pinto@...opsys.com>; Arnd Bergmann <arnd@...db.de>;
>Alexandru Ardelean <alexandru.ardelean@...log.com>; linux-stm32@...md-
>mailman.stormreply.com; linux-arm-kernel@...ts.infradead.org; linux-
>kernel@...r.kernel.org
>Subject: RE: [PATCH net v3 1/5] net: stmmac: Fix incorrect location to set
>real_num_rx|tx_queues
>
>From: Ong Boon Leong <boon.leong.ong@...el.com>
>Date: Jan/22/2020, 09:09:32 (UTC+00:00)
>
>> For driver open(), rtnl_lock is acquired by network stack but not in the
>> resume(). Therefore, we introduce lock_acquired boolean to control when
>> to use rtnl_lock|unlock() within stmmac_hw_setup().
>
>Why not use rtnl_is_locked() instead of the boolean ?

We know that stmmac_open() is called with rtnl_mutex locked by caller.
And, stmmac_resume() is called without rtnl_mutex is locked by caller.
If we replace the boolean with rtnl_is_locked(), then we will have the
following logics in stmmac_hw_setup():-

     if (!rtnl_is_locked)   ---- (A)
         rtnl_lock();
     netif_set_real_num_rx_queues();
     netif_set_real_num_tx_queues();
     if (!rtnl_is_locked)   ---- (B)
         rtnl_unlock();

For stmmac_open(), (A) is false but (B) is true. 
So, the stmmac_open() exits with rtnl_mutex is released.
Here, the above logic does not perserve the original rtnl_mutex
is locked when stmmac_open() is called.

For stmmac_resume(), (A) is true, and (B) is also true.
So, the stmmac_resume() exits with rtnl_mutex is released.
Here, the above logic works well as the original rtnl_mutex is released
when stmmac_resume() is called.
 
So, as far as I can see, the proposed boolean approach works fine for both
stmmac_open() and stmmac_resume().

Do you agree?