lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  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:	Wed, 8 Dec 2010 10:19:47 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	gerald.schaefer@...ibm.com
Cc:	paulmck@...ux.vnet.ibm.com, Milton Miller <miltonm@....com>,
	Minchan Kim <minchan.kim@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm@...r.kernel.org,
	linux-ext4@...r.kernel.org, "Ted Ts'o" <tytso@....edu>,
	Arun Bhanu <ab@...nbhanu.com>, Mel Gorman <mel@....ul.ie>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [BUG?] memory hotplug: include/linux/radix-tree.h:145 invoked
 rcu_dereference_check() without protection!

On Tue, 07 Dec 2010 20:01:49 +0100
Gerald Schaefer <gerald.schaefer@...ibm.com> wrote:

> I got the same warning as reported by Arun Bhanu in "[BUG?] [Ext4] INFO:
> suspicious rcu_dereference_check() usage" during memory hotplug test on
> 2.6.37-rc5, see below.
> 
> migrate_pages() -> unmap_and_move() only calls rcu_read_lock() for anonymous
> pages, as introduced by git commit 989f89c57e6361e7d16fbd9572b5da7d313b073d.
> This should be ok, as the comment suggests, so the warning is probably a
> false positive. Eventually, migrate_page_move_mapping() will call
> radix_tree_deref_slot() with tree_lock held, but w/o rcu_read_lock() for
> non-anonymous pages.
> 
> As suggested by Milton before, a new version of radix_tree_deref_slot that
> uses rcu_dereference_protected could help, if this is a false positive, or
> maybe the rcu_read_lock() should be called for all pages, not just anonymous.
> Any thoughts?
> 

Hmm, in radix_tree_deref_slot() comment,

 140  * For use with radix_tree_lookup_slot().  Caller must hold tree at least read
 141  * locked across slot lookup and dereference.  More likely, will be used with
 142  * radix_tree_replace_slot(), as well, so caller will hold tree write locked.

racy update must not happen. rcu_dereference_protected() sounds nice.

Thanks,
-Kame

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ