netdev - Re: [PATCH][RFC] cxgb4: Not need to hold the adap_rcu_lock lock when read adap_rcu

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]

Message-ID: <CAJFZqHzsEByhY02=4_WoGsGMTY1FPGzavNhnot6Bm-qiyOi3aA@mail.gmail.com>
Date:	Tue, 24 Jun 2014 08:20:44 +0800
From:	Li RongQing <roy.qing.li@...il.com>
To:	Casey Leedom <leedom@...lsio.com>
Cc:	David Miller <davem@...emloft.net>,
	Rongqing Li <rongqing.li@...driver.com>,
	netdev <netdev@...r.kernel.org>,
	Eric Dumazet <eric.dumazet@...il.com>, hariprasad@...lsio.com,
	Ben Greear <greearb@...delatech.com>
Subject: Re: [PATCH][RFC] cxgb4: Not need to hold the adap_rcu_lock lock when
 read adap_rcu_list

On Tue, Jun 24, 2014 at 6:35 AM, Casey Leedom <leedom@...lsio.com> wrote:
>> I think this change is fine, and correct, but I would like to see some
>> reviews from the cxgb4 maintainers.
>
>
>   Thanks David.  Hari is gone on PTO so I think I'm the next logical person
> ... :-)
>
>   I've gone back and reviewed the original patch, Eric Dumazet6's reply and
> revised patch and compared that against this proposed patch.  Li RongQing is
> submitting the same patch that Eric suggested with the addition of a call to
> synchronize_rcu() the in driver remove() function.  I'm not super familiar
> with the RCU system but that addition certainly seems innocuous enough.
> Other than that, everything looks fine.

I think the synchronize_rcu is needed, as explanation of
Documentation/RCU/whatisRCU.txt the RCU update sequence is:

So the typical RCU update sequence goes something like the following:

a.      Remove pointers to a data structure, so that subsequent
        readers cannot gain a reference to it.

b.      Wait for all previous readers to complete their RCU read-side
        critical sections.

c.      At this point, there cannot be any readers who hold references
        to the data structure, so it now may safely be reclaimed
        (e.g., kfree()d).


To achieve the step b, synchronize_rcu() or call_rcu() or kfree_rcu are needed,
since this removing happens little, I add a synchronize_rcu(), to
avoid to add the
rcu_head to struct adapter or to change codes largely.

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