Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2479560imu; Thu, 29 Nov 2018 05:46:52 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vqz3Cb5Bd0wIt1tIAMent8fTE2fzDB7LYOEPYwCvChNDJ/9zgb5OSPF1Cu0aiRYlmQ5nUZ X-Received: by 2002:aa7:87ce:: with SMTP id i14mr1465549pfo.20.1543499212049; Thu, 29 Nov 2018 05:46:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543499212; cv=none; d=google.com; s=arc-20160816; b=h5HwOphcd3crBvbdL7NwuTpLy0CD2jmQ4A2dEWonWIedTZgUyDWS3VFM/c6oilOiEr gnZ0eJVlV6aBb6mqrhkhonDFonL9nzFIVwGC3m0+xBs6EyMl+bohI6YBfGXc6XIy+Bq8 OO2HhyxzWIsSo0epOJHZCzQ/9u9XwT5siibX3Z1AqixTcIKTWBtMQInXZk5fa2LzfTlJ jukH9EFK3s26Nv6iYZwbixgwBMtTsbk79oiMliSjmDiPtAcIjNjr6vEqkHUrsno9J7yN CsaDXMp7VN2dsqxDi7ySc2Jkz59X14MLL6vvhQ8V8pWxF5OSuJ+mTOG4rz8xbf05i95t I/eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=mGWhneo6rPiu3VVJlPWlpF6WY1PKLe+0ArpEk0GVBI0=; b=fi5Q656imxSjsu4F0nOJlv59nG1uf3xawDB8CfZUUaTpAU6kd7GlFBamzyOHpg8uy+ 6ibDv5AbWQr1IP3kp7umBUeem3S7UewwZh6+ODfrh8vwUBhREsJ3CPPnKe2tBqijSkAj mDIcbsQA8Za4U/RiYDLKpWg5YMK/biueGa3Feh0+g7p2LKVTnU2gKb4fM7DOMgUJFuGL doIMJ6e8v1sUo8HF1iFMUhKL7gxQUj0kF2AKsbD+l1AAXGZ5f1IW6fOHZEH6RjVh3yrG uqa3DRqsFBpmZyY1oF1jVMI9SI4p6lHcwIZFsx4A829PBFhyFZWrcu9GNH+U4cc4+6ZL lvsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=qsBgEKca; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a68si2370701pla.267.2018.11.29.05.46.36; Thu, 29 Nov 2018 05:46:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=qsBgEKca; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728301AbeK3AvG (ORCPT + 99 others); Thu, 29 Nov 2018 19:51:06 -0500 Received: from merlin.infradead.org ([205.233.59.134]:42714 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726724AbeK3AvF (ORCPT ); Thu, 29 Nov 2018 19:51:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mGWhneo6rPiu3VVJlPWlpF6WY1PKLe+0ArpEk0GVBI0=; b=qsBgEKca9TjNxSqtN9hsJrk+O xcj3zvqvh1mdsA0ZqV7GRZat0Ms/q3Lm/M9JhIRnatwMLCnY/zoXk7JsjPbaI2L3Ck3k/crgBPR+K Qle7HDJRsnP9FOfl5lQvJEkET5xbZkd81/heb6aA4QHlhIo7IaWhcsQSd6R7qUE0HH4BQPC+Q32Oj So85tFbWozNtZAwgd7FWwhcAh7N1wk8v1RWxQMYYrXY5KsvBIHtsujcVCcVAdYHcWSq8og1NCbXFN pJdorQto0c9PPRsU2I9uqSyMQ+cG5POtDEJQmOu4E/SC8F8uFfy1lRAnEep3SLa3ejNQdu313piM/ 2qLvio9Mg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1gSMdB-0000CL-II; Thu, 29 Nov 2018 13:45:26 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 9C22B2029FD58; Thu, 29 Nov 2018 14:44:49 +0100 (CET) Date: Thu, 29 Nov 2018 14:44:49 +0100 From: Peter Zijlstra To: Yongji Xie Cc: mingo@redhat.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, xieyongji@baidu.com, zhangyu31@baidu.com, liuqi16@baidu.com, yuanlinsi01@baidu.com, nixun@baidu.com, lilin24@baidu.com, Davidlohr Bueso , Waiman Long , Thomas Gleixner Subject: Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil Message-ID: <20181129134449.GH2149@hirez.programming.kicks-ass.net> References: <1543495830-2644-1-git-send-email-xieyongji@baidu.com> <20181129131232.GN2131@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181129131232.GN2131@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 29, 2018 at 02:12:32PM +0100, Peter Zijlstra wrote: > > +Cc davidlohr and waiman > Urgh; so the case where the cmpxchg() fails because it already has a > wakeup in progress, which then 'violates' our expectation of when the > wakeup happens. > > Yes, I think this is real, and worse, I think we need to go audit all > wake_q_add() users and document this behaviour. > > In the ideal case we'd delay the actual wakeup to the last wake_up_q(), > but I don't think we can easily fix that. See commit: 1d0dcb3ad9d3 ("futex: Implement lockless wakeups"), I think that introduces the exact same bug. Something like the below perhaps, altough this pattern seems to want a wake_a_add() variant that already assumes get_task_struct(). diff --git a/kernel/futex.c b/kernel/futex.c index f423f9b6577e..d14971f6ed3d 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -1387,11 +1387,7 @@ static void mark_wake_futex(struct wake_q_head *wake_q, struct futex_q *q) if (WARN(q->pi_state || q->rt_waiter, "refusing to wake PI futex\n")) return; - /* - * Queue the task for later wakeup for after we've released - * the hb->lock. wake_q_add() grabs reference to p. - */ - wake_q_add(wake_q, p); + get_task_struct(p); __unqueue_futex(q); /* * The waiting task can free the futex_q as soon as q->lock_ptr = NULL @@ -1401,6 +1397,13 @@ static void mark_wake_futex(struct wake_q_head *wake_q, struct futex_q *q) * plist_del in __unqueue_futex(). */ smp_store_release(&q->lock_ptr, NULL); + + /* + * Queue the task for later wakeup for after we've released + * the hb->lock. wake_q_add() grabs reference to p. + */ + wake_q_add(wake_q, p); + put_task_struct(p); } /*