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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210112143710.nxpxnlcojhvqipw7@skbuf>
Date:   Tue, 12 Jan 2021 16:37:10 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Saeed Mahameed <saeed@...nel.org>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Eric Dumazet <edumazet@...gle.com>,
        George McCollister <george.mccollister@...il.com>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Jay Vosburgh <j.vosburgh@...il.com>,
        Veaceslav Falico <vfalico@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Arnd Bergmann <arnd@...db.de>, Taehee Yoo <ap420073@...il.com>,
        Jiri Pirko <jiri@...nulli.us>, Florian Westphal <fw@...len.de>,
        Nikolay Aleksandrov <nikolay@...dia.com>,
        Pravin B Shelar <pshelar@....org>,
        Sridhar Samudrala <sridhar.samudrala@...el.com>
Subject: Re: [PATCH v6 net-next 14/15] net: bonding: ensure .ndo_get_stats64
 can sleep

On Mon, Jan 11, 2021 at 03:38:49PM -0800, Saeed Mahameed wrote:
> GFP_ATOMIC is a little bit aggressive especially when user daemons are
> periodically reading stats. This can be avoided.
>
> You can pre-allocate with GFP_KERNEL an array with an "approximate"
> size.
> then fill the array up with whatever slaves the the bond has at that
> moment, num_of_slaves  can be less, equal or more than the array you
> just allocated but we shouldn't care ..
>
> something like:
> rcu_read_lock()
> nslaves = bond_get_num_slaves();
> rcu_read_unlock()
> sarray = kcalloc(nslaves, sizeof(struct bonding_slave_dev),
> GFP_KERNEL);
> rcu_read_lock();
> bond_fill_slaves_array(bond, sarray); // also do: dev_hold()
> rcu_read_unlock();
>
>
> bond_get_slaves_array_stats(sarray);
>
> bond_put_slaves_array(sarray);

I don't know what to say about acquiring RCU read lock twice and
traversing the list of interfaces three or four times.
On the other hand, what's the worst that can happen if the GFP_ATOMIC
memory allocation fails. It's not like there is any data loss.
User space will retry when there is less memory pressure.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ