Re: linux-next: build failure after merge of the scsi-mkp tree

2017-12-11 Thread Paul E. McKenney
On Thu, Dec 07, 2017 at 08:00:50PM -0500, Martin K. Petersen wrote: > > > I'm perfectly OK with taking it through the SCSI tree. Probably the > > path of least resistance. > > Applied to 4.16/scsi-queue and rebased so it sits before Bart's patch. Thank you! I have removed this patch from -rcu.

Re: linux-next: build failure after merge of the scsi-mkp tree

2017-12-07 Thread Paul E. McKenney
On Fri, Dec 08, 2017 at 07:34:39AM +1100, Stephen Rothwell wrote: > Hi all, > > On Thu, 7 Dec 2017 09:40:38 -0800 "Paul E. McKenney" > wrote: > > > > On Thu, Dec 07, 2017 at 05:30:03PM +, Bart Van Assche wrote: > > > However, what's not clear

Re: linux-next: build failure after merge of the scsi-mkp tree

2017-12-07 Thread Paul E. McKenney
On Thu, Dec 07, 2017 at 05:30:03PM +, Bart Van Assche wrote: > On Wed, 2017-12-06 at 20:42 -0800, Paul E. McKenney wrote: > > On Thu, Dec 07, 2017 at 03:25:21PM +1100, Stephen Rothwell wrote: > > > On Thu, 7 Dec 2017 03:59:30 + Bart Van Assche > > > wr

Re: [PATCH v3 1/3] rcu: Introduce rcu_swap_protected()

2017-08-28 Thread Paul E. McKenney
On Mon, Aug 28, 2017 at 09:39:18PM +, Bart Van Assche wrote: > On Mon, 2017-08-28 at 14:26 -0700, Paul E. McKenney wrote: > > On Mon, Aug 28, 2017 at 01:46:13PM -0700, Bart Van Assche wrote: > > > A common pattern in RCU code is to assign a new value to an RCU > > >

Re: [PATCH v3 1/3] rcu: Introduce rcu_swap_protected()

2017-08-28 Thread Paul E. McKenney
On Mon, Aug 28, 2017 at 01:46:13PM -0700, Bart Van Assche wrote: > A common pattern in RCU code is to assign a new value to an RCU > pointer after having read and stored the old value. Introduce a > macro for this pattern. > > Signed-off-by: Bart Van Assche > Cc: Paul E. Mc

Re: [PATCH] target: Wait RCU grace-period before backend/fabric unload

2015-07-30 Thread Paul E. McKenney
On Thu, Jul 30, 2015 at 05:23:43PM -0700, Nicholas A. Bellinger wrote: > On Thu, 2015-07-30 at 06:07 -0700, Paul E. McKenney wrote: > > On Thu, Jul 30, 2015 at 06:15:23AM +, Nicholas A. Bellinger wrote: > > > From: Nicholas Bellinger > > > > > > This p

Re: [PATCH] target: Wait RCU grace-period before backend/fabric unload

2015-07-30 Thread Paul E. McKenney
Thanx, Paul > Also, go ahead and do the same for target_unregister_template() > to ensure se_deve_entry->rcu_head -> kfree_rcu() grace period has > passed, before allowing target_core_fabric_ops->owner module exit > to proceed. > > Cc: P

Re: [PATCH-v2 2/4] target: Drop lun_sep_lock for se_lun->lun_se_dev RCU usage

2015-06-01 Thread Paul E. McKenney
On Sat, May 30, 2015 at 10:24:41PM -0700, Nicholas A. Bellinger wrote: > On Thu, 2015-05-28 at 08:57 -0700, Paul E. McKenney wrote: > > On Wed, May 27, 2015 at 11:02:10PM -0700, Nicholas A. Bellinger wrote: > > > On Wed, 2015-05-27 at 14:04 -0700, Paul E. McKenney wrote: >

Re: [PATCH-v2 0/4] target: Eliminate se_port + t10_alua_tg_pt_gp_member

2015-05-28 Thread Paul E. McKenney
On Wed, May 27, 2015 at 10:41:37PM -0700, Nicholas A. Bellinger wrote: > On Wed, 2015-05-27 at 13:36 -0700, Paul E. McKenney wrote: > > On Tue, May 26, 2015 at 10:13:02PM -0700, Nicholas A. Bellinger wrote: > > > On Tue, 2015-05-26 at 14:44 +0200, Bart Van Assche wrote: > &g

Re: [PATCH-v2 2/4] target: Drop lun_sep_lock for se_lun->lun_se_dev RCU usage

2015-05-28 Thread Paul E. McKenney
On Wed, May 27, 2015 at 11:02:10PM -0700, Nicholas A. Bellinger wrote: > On Wed, 2015-05-27 at 14:04 -0700, Paul E. McKenney wrote: > > On Tue, May 26, 2015 at 10:29:45PM -0700, Nicholas A. Bellinger wrote: > > > On Tue, 2015-05-26 at 16:30 +0200, Bart Van Assche wrote: > &g

Re: [PATCH-v2 2/4] target: Drop lun_sep_lock for se_lun->lun_se_dev RCU usage

2015-05-27 Thread Paul E. McKenney
On Tue, May 26, 2015 at 10:29:45PM -0700, Nicholas A. Bellinger wrote: > On Tue, 2015-05-26 at 16:30 +0200, Bart Van Assche wrote: > > On 05/26/15 08:57, Nicholas A. Bellinger wrote: > > > @@ -625,6 +626,7 @@ int core_dev_add_initiator_node_lun_acl( > > > u32 lun_access) > > > { > > >

Re: [PATCH-v2 0/4] target: Eliminate se_port + t10_alua_tg_pt_gp_member

2015-05-27 Thread Paul E. McKenney
On Tue, May 26, 2015 at 10:13:02PM -0700, Nicholas A. Bellinger wrote: > 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 f

Re: Another (ESP?) scsi blk-mq problem on sparc64

2014-11-24 Thread Paul E. McKenney
On Mon, Nov 24, 2014 at 10:33:37AM -0700, Jens Axboe wrote: > On 11/24/2014 10:31 AM, Paul E. McKenney wrote: > >On Mon, Nov 24, 2014 at 10:16:15AM -0700, Jens Axboe wrote: > >>On 11/24/2014 09:22 AM, Paul E. McKenney wrote: > >>>On Mon, Nov 24, 2014 at 08:35:46AM -07

Re: Another (ESP?) scsi blk-mq problem on sparc64

2014-11-24 Thread Paul E. McKenney
On Mon, Nov 24, 2014 at 10:16:15AM -0700, Jens Axboe wrote: > On 11/24/2014 09:22 AM, Paul E. McKenney wrote: > >On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote: > >>On 11/24/2014 01:21 AM, Christoph Hellwig wrote: > >>>On Fri, Nov 21, 2014 at 02:56:

Re: Another (ESP?) scsi blk-mq problem on sparc64

2014-11-24 Thread Paul E. McKenney
On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote: > On 11/24/2014 01:21 AM, Christoph Hellwig wrote: > >On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote: > >>I would suggest looking into the possibility that we allocate the memory > >>using the count of valid cpus, rather than

Re: blk_mq: suspicious RCU usage, rcu_read_lock() used illegally while idle!

2014-11-07 Thread Paul E. McKenney
On Fri, Nov 07, 2014 at 12:45:58PM -0500, David Miller wrote: > From: "Paul E. McKenney" > Date: Fri, 7 Nov 2014 07:06:28 -0800 > > > On Fri, Nov 07, 2014 at 12:50:02PM +0200, Meelis Roos wrote: > >> Perhaps DaveM can tell which one is coreect or if

Re: blk_mq: suspicious RCU usage, rcu_read_lock() used illegally while idle!

2014-11-07 Thread Paul E. McKenney
On Fri, Nov 07, 2014 at 12:50:02PM +0200, Meelis Roos wrote: > Added DaveM and sparclinux to CC. > > On Thu, 6 Nov 2014, Paul E. McKenney wrote: > > On Thu, Nov 06, 2014 at 07:46:16AM -0800, Christoph Hellwig wrote: > > > Without help from Paul I can't even make sense

Re: blk_mq: suspicious RCU usage, rcu_read_lock() used illegally while idle!

2014-11-06 Thread Paul E. McKenney
On Thu, Nov 06, 2014 at 07:46:16AM -0800, Christoph Hellwig wrote: > Without help from Paul I can't even make sense of the message.. It looks to me like the SUN4U architecture is failing to invoke rcu_irq_enter() on entry to the smp_call_function_single_client() IPI handler. And I am not seeing a

Re: memory-barriers.txt again (was Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK)

2014-02-24 Thread Paul E. McKenney
On Mon, Feb 24, 2014 at 01:32:54AM +0100, Stefan Richter wrote: > On Feb 23 Paul E. McKenney wrote: > >>> Please see below for a patch against the current version of > >>> Documentation/memory-barriers.txt. Does this update help? > > Thank you, this clarifies it.

Re: memory-barriers.txt again (was Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK)

2014-02-24 Thread Paul E. McKenney
On Sun, Feb 23, 2014 at 07:09:55PM -0500, Peter Hurley wrote: > On 02/23/2014 06:50 PM, Paul E. McKenney wrote: > >On Sun, Feb 23, 2014 at 03:35:31PM -0500, Peter Hurley wrote: > >>Hi Paul, > >> > >>On 02/23/2014 11:37 AM,

Re: memory-barriers.txt again (was Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK)

2014-02-23 Thread Paul E. McKenney
On Sun, Feb 23, 2014 at 03:35:31PM -0500, Peter Hurley wrote: > Hi Paul, > > On 02/23/2014 11:37 AM, Paul E. McKenney wrote: > >commit aba6b0e82c9de53eb032844f1932599f148ff68d > >Author: Paul E. McKenney > >Date: Sun Feb 23 08:34:24 2014 -0800 > > > >

Re: memory-barriers.txt again (was Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK)

2014-02-23 Thread Paul E. McKenney
rce the unlock operation to complete, again unraveling the deadlock. Please see below for a patch against the current version of Documentation/memory-barriers.txt. Does this update help? Thanx, Paul