From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752140AbbCJLAW (ORCPT ); Tue, 10 Mar 2015 07:00:22 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:43288 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750848AbbCJLAT (ORCPT ); Tue, 10 Mar 2015 07:00:19 -0400 Date: Tue, 10 Mar 2015 11:59:39 +0100 From: Peter Zijlstra To: Oleg Nesterov Cc: linux-tip-commits@vger.kernel.org, dave@stgolabs.net, hpa@zytor.com, sasha.levin@oracle.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, jason.low2@hp.com, walken@google.com, akpm@linux-foundation.org, mingo@kernel.org, paulmck@linux.vnet.ibm.com, davej@codemonkey.org.uk, ming.lei@canonical.com, torvalds@linux-foundation.org, tim.c.chen@linux.intel.com Subject: Re: [tip:locking/core] locking/rwsem: Fix lock optimistic spinning when owner is not running Message-ID: <20150310105939.GV2896@worktop.programming.kicks-ass.net> References: <1425714331.2475.388.camel@j-VirtualBox> <20150307171347.GA30365@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150307171347.GA30365@redhat.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 07, 2015 at 06:13:47PM +0100, Oleg Nesterov wrote: > I think the patch is fine, but this reminds me... > > On 03/07, tip-bot for Jason Low wrote: > > > > bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct *owner) > > { > > long count; > > > > rcu_read_lock(); > > - while (owner_running(sem, owner)) { > > - /* abort spinning when need_resched */ > > - if (need_resched()) { > > + while (sem->owner == owner) { > > + /* > > + * Ensure we emit the owner->on_cpu, dereference _after_ > > + * checking sem->owner still matches owner, if that fails, > > + * owner might point to free()d memory, if it still matches, > > + * the rcu_read_lock() ensures the memory stays valid. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Yes, this is another case when we wrongly assume this. > > Peter, should I resend > > [PATCH 3/3] introduce task_rcu_dereference() > http://marc.info/?l=linux-kernel&m=141443631413914 > > ? or should we add another call_rcu() in finish_task_switch() (like -rt does) > to make this true? Yeah, I think the extra call_rcu() makes most sense.