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 S1752709AbcELMTN (ORCPT <rfc822;w@1wt.eu>);
	Thu, 12 May 2016 08:19:13 -0400
Received: from mail-wm0-f48.google.com ([74.125.82.48]:38048 "EHLO
	mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752010AbcELMTK (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 12 May 2016 08:19:10 -0400
Date: Thu, 12 May 2016 14:19:07 +0200
From: Michal Hocko <mhocko@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
        LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>,
        "David S. Miller" <davem@davemloft.net>,
        Tony Luck <tony.luck@intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Chris Zankel <chris@zankel.net>, Max Filippov <jcmvbkbc@gmail.com>,
        Davidlohr Bueso <dave@stgolabs.net>, Waiman Long <Waiman.Long@hpe.com>
Subject: Re: [PATCH 03/11] locking, rwsem: introduce basis for
 down_write_killable
Message-ID: <20160512121907.GG4200@dhcp22.suse.cz>
References: <20160511072357.GC16677@dhcp22.suse.cz>
 <20160511082853.GF16677@dhcp22.suse.cz>
 <20160511084401.GH3193@twins.programming.kicks-ass.net>
 <20160511090442.GH16677@dhcp22.suse.cz>
 <20160511091733.GC3192@twins.programming.kicks-ass.net>
 <20160511093127.GI16677@dhcp22.suse.cz>
 <20160511094128.GB3190@twins.programming.kicks-ass.net>
 <20160511135938.GA19577@dhcp22.suse.cz>
 <20160511180345.GA27728@dhcp22.suse.cz>
 <20160512121204.GQ3192@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160512121204.GQ3192@twins.programming.kicks-ass.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu 12-05-16 14:12:04, Peter Zijlstra wrote:
> On Wed, May 11, 2016 at 08:03:46PM +0200, Michal Hocko wrote:
> > I still cannot say I would understand why the pending
> > RWSEM_WAITING_BIAS matters but I would probably need to look at the code
> > again with a clean head, __rwsem_wake is quite tricky...
> 
> Ah, you're asking why an unconditional __rwsem_wake(ANY) isn't enough?
> 
> Because; if at that point there's nobody waiting, we're left with an
> empty list and WAITER_BIAS set. This in turn will make all fast paths
> fail.
> 
> Look at rwsem_down_read_failed() for instance; if we enter that we'll
> unconditionally queue ourself, with nobody left to come wake us.

This is still not clear to me because rwsem_down_read_failed will call
__rwsem_do_wake if the count is RWSEM_WAITING_BIAS so we shouldn't go to
sleep and get the lock. So you are right that we would force everybody
to the slow path which is not great but shouldn't cause incorrect
behavior. I guess I must be missing something obvious here...
-- 
Michal Hocko
SUSE Labs