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] [day] [month] [year] [list]
Message-ID: <BN8PR12MB3266EC19F5E12FE94FF153E4D30E0@BN8PR12MB3266.namprd12.prod.outlook.com>
Date:   Fri, 24 Jan 2020 09:06:38 +0000
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     "Ong, Boon Leong" <boon.leong.ong@...el.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

From: Ong, Boon Leong <boon.leong.ong@...el.com>
Date: Jan/24/2020, 08:56:28 (UTC+00:00)

> >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? 

Can't you just wrap all the HW related logic in stmmac_resume() and 
stmmac_suspend() with the rtnl lock ? Seems like the right thing to do and 
you won't need the boolean.

---
Thanks,
Jose Miguel Abreu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ