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:	Sun, 7 Sep 2014 21:51:15 -0700
From:	Mahesh Bandewar <maheshb@...gle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Nikolay Aleksandrov <nikolay@...hat.com>,
	Jay Vosburgh <j.vosburgh@...il.com>,
	Veaceslav Falico <vfalico@...hat.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Maciej Zenczykowski <maze@...gle.com>
Subject: Re: [PATCH net-next v1 2/2] bonding: Simplify the xmit function for
 modes that use xmit_hash

On Sun, Sep 7, 2014 at 9:41 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Sun, 2014-09-07 at 19:23 -0700, Mahesh Bandewar wrote:
>> >
>> I'm not expecting any writer protection here since all the paths are
>> covered with some or the other lock at this moment. Just though that
>> performing array manipulation in RCU context would be useful.
>
>
> It is not useful. It is confusing only.
>
> If you think of RCU as a replacement for reader/writer lock, its obvious
> that once you get the writer lock, there is no need to get the reader
> lock.
>
As I had mentioned earlier, simultaneous writers are taken care. The
xmit is lockless and was thinking about how not to get the xmit into
the scenario where this array manipulation is partially done and that
partial value is used by the xmitter and result may not be desirable.
Hence thought that rcu-read-lock will protect the xmitter getting into
that state. I guess that was incorrect so I'll remove the
read-lock/unlock from the code. Thanks for the clarification Eric.

> Extract from Documentation/RCU/whatisRCU.txt :
>
> Use rcu_read_lock() and rcu_read_unlock() to guard RCU
> read-side critical sections.
>
> Use some solid scheme (such as locks or semaphores) to
> keep concurrent updates from interfering with each other.
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists