linux-kernel - Re: [PATCH-v2 0/4] target: Eliminate se_port + t10_alua_tg_pt_gp

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: <1432703582.26863.33.camel@haakon3.risingtidesystems.com>
Date:	Tue, 26 May 2015 22:13:02 -0700
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	Bart Van Assche <bart.vanassche@...disk.com>
Cc:	"Nicholas A. Bellinger" <nab@...erainc.com>,
	target-devel <target-devel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@....de>, Hannes Reinecke <hare@...e.de>,
	Sagi Grimberg <sagig@...lanox.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH-v2 0/4] target: Eliminate se_port +
 t10_alua_tg_pt_gp_member

On Tue, 2015-05-26 at 14:44 +0200, Bart Van Assche wrote:
> On 05/26/15 08:57, Nicholas A. Bellinger wrote:
> >    - Add various rcu_dereference and lockless_dereference RCU notation
> 
> Hello Nic,
> 
> Feedback from an RCU expert (which I'm not) would be appreciated here. 
> But my understanding is that lockless_dereference(p) should be used for 
> a pointer p that has *not* been annotated as an RCU pointer. I think in 
> the for-next branch of the target repository that this macro is used to 
> access RCU-annotated pointers. Is that why sparse complains about how 
> lockless_dereference() is used in the target tree ?
> 

Was curious about this myself..  Thanks for raising the question!

The intention of lockless_dereference() in both this and preceding
series is for __rcu protected pointers that are accessed outside of
rcu_read_lock() protection, and who's lifetime is controlled by a:

  - struct kref
  - struct percpu_ref
  - struct config_group symlink
  - RCU updater path with some manner of mutex or spinlock held

This is supposed to be following Paul's comment in rcupdate.h:

 * Similar to rcu_dereference(), but for situations where the pointed-to
 * object's lifetime is managed by something other than RCU.  That
 * "something other" might be reference counting or simple immortality.

Paul, would you be to kind to clarify the intention for us..?

Thank you,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/