From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756046AbbDISjg (ORCPT <rfc822;w@1wt.eu>);
	Thu, 9 Apr 2015 14:39:36 -0400
Received: from e39.co.us.ibm.com ([32.97.110.160]:52260 "EHLO
	e39.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755680AbbDISjd (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 9 Apr 2015 14:39:33 -0400
Date: Thu, 9 Apr 2015 11:39:26 -0700
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>, Jason Low <jason.low2@hp.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Aswin Chandramouleeswaran <aswin@hp.com>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] locking/rwsem: Use a return variable in
 rwsem_spin_on_owner()
Message-ID: <20150409183926.GM6464@linux.vnet.ibm.com>
Reply-To: paulmck@linux.vnet.ibm.com
References: <1428521960-5268-1-git-send-email-jason.low2@hp.com>
 <1428521960-5268-3-git-send-email-jason.low2@hp.com>
 <20150409053725.GB13871@gmail.com>
 <1428561611.3506.78.camel@j-VirtualBox>
 <20150409075311.GA4645@gmail.com>
 <CA+55aFz6KKxGVxPAbsmw9GsKJfy85P2C0EmYBrGpn+aJDjZJWw@mail.gmail.com>
 <20150409175652.GI6464@linux.vnet.ibm.com>
 <CA+55aFzXMDjQQ7jTjsPdh1RikXfgV7OCd-+13cz06MOmDBA33w@mail.gmail.com>
 <CA+55aFwZWi6ecDmVsMBQJTrgrW3GD2DaRtpiOspe=5amR1=dNg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFwZWi6ecDmVsMBQJTrgrW3GD2DaRtpiOspe=5amR1=dNg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 15040918-0033-0000-0000-0000043012EB
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Apr 09, 2015 at 11:16:24AM -0700, Linus Torvalds wrote:
> On Thu, Apr 9, 2015 at 11:08 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > The pointer is a known-safe kernel pointer - it's just that it was
> > "known safe" a few instructions ago, and might be rcu-free'd at any
> > time.
> 
> Actually, we could even do something like this:
> 
>  static inline int sem_owner_on_cpu(struct semaphore *sem, struct
> task_struct *owner)
>  {
>         int on_cpu;
> 
>     #ifdef CONFIG_DEBUG_PAGEALLOC
>         rcu_read_lock();
>     #endif
>         on_cpu = sem->owner == owner && owner->on_cpu;
>     #ifdef CONFIG_DEBUG_PAGEALLOC
>         rcu_read_unlock();
>     #endif
>         return on_cpu;
>     }
> 
> because we really don't need to hold the RCU lock over the whole loop,
> we just need to validate that the semaphore owner still matches, and
> if so, check that it's on_cpu.

Much better from an RCU grace-period-latency perspective.

> And if CONFIG_DEBUG_PAGEALLOC is set, we don't care about performance
> *at*all*. We will have worse performance problems than doing some RCU
> read-locking inside the loop.
> 
> And if CONFIG_DEBUG_PAGEALLOC isn't set, we don't really care about
> locking, since at worst we just access stale memory for one iteration.

But if we are running on a hypervisor, mightn't our VCPU be preempted
just before accessing ->on_cpu, the task exit and its structures be
freed and unmapped?  Or is the task structure in memory that is never
unmapped?  (If the latter, clearly not a problem.)

							Thanx, Paul

> Hmm. It's not pretty, but neither is the current "let's just take a
> rcu lock that we don't really need over a loop that doesn't have very
> strict bounding".
> 
> Comments?
> 
>                                     Linus
>