Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp2060563pxt; Sun, 8 Aug 2021 10:07:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxu/RuhIAKlqIifD/oCB6mu9zhzub/V0mYT0CyAW4LPPlNGVTDwc6pwlXaegRUNE/RSWR4M X-Received: by 2002:a05:6402:c01:: with SMTP id co1mr1826598edb.156.1628442469980; Sun, 08 Aug 2021 10:07:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628442469; cv=none; d=google.com; s=arc-20160816; b=lyo9l5tvR6Yc+p7KQrtEmEHTyhVQRzFCi7lg6XZ6zurJ+FOKZE4D4kTLTHjFeQL5Xf yRUMM02WGrbqiX/vV3h8kaWexdxSmLmueRd/whDqkW8hgHWX+v4Yx1FxfISOz2yttX8Q ctv2lJAtA8PPVNJUGyMMiPNaNtqC2OG2Z9nfCdvGXTcTrMTJ26QVvKCeKaJ1FzbTbmHx 8H2QJMQ+QrZ0OvYcHsntP73n64k/yVlfRS78gYPm2ni8ii2QABsr9X+L3/TqSgQJy2wM ERGIm5xn4I3nk3WphkLdsjFTN+yn6xIbeaKMST5coL23g0d5rAnw6NS59pw4WTGJ64Uf wGgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ZtNfVjmoyISS/vODGTXJZiSb7ih9ExbYplUXWtjgH6o=; b=kux6Y0lmSbX72ZyFBbmYuNhi2NVu+vfADkSaVwb/xEdwO5uTVAlyh3Jao5WPfSfzEu bQuKV9Zp1iBCll0V/dXyG74QJ364YHYMmeSXtMl4SjNcT9dEwanShrp6vAUm0p1HcyiM +mZmWkWqHj61Km+5vXybJa3jpCkxganqArFaTD1pN00zzQ4C0vbyBk37V7LSUL3E17oR xlFGJiaMcR08F/W5KwEp1/f8aYF5TBqn6ayxKYpST3eokEWdqWFnUEgDbfawXRUJ3xCU HeCe2iK3yzZJTXiZ2s0xSZ+BBttBfShAgzgm+F9W4VymJCtaof9rdXdG2ypHFwoAXsM/ OsNA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c34si16005652edf.258.2021.08.08.10.07.26; Sun, 08 Aug 2021 10:07:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232051AbhHHRGD (ORCPT + 99 others); Sun, 8 Aug 2021 13:06:03 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:37856 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230169AbhHHRGC (ORCPT ); Sun, 8 Aug 2021 13:06:02 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 4C7261FFE9; Sun, 8 Aug 2021 17:05:42 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6BC1B13398; Sun, 8 Aug 2021 17:05:39 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id IT3FB+MOEGH8DQAAMHmgww (envelope-from ); Sun, 08 Aug 2021 17:05:39 +0000 Date: Sun, 8 Aug 2021 10:05:35 -0700 From: Davidlohr Bueso To: Thomas Gleixner Cc: LKML , Peter Zijlstra , Ingo Molnar , Juri Lelli , Steven Rostedt , Daniel Bristot de Oliveira , Will Deacon , Waiman Long , Boqun Feng , Sebastian Andrzej Siewior , Mike Galbraith Subject: Re: [patch V3 56/64] futex: Correct the number of requeued waiters for PI Message-ID: <20210808170535.kotqd5t677tijh4o@offworld> References: <20210805151300.330412127@linutronix.de> <20210805153956.051961951@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20210805153956.051961951@linutronix.de> User-Agent: NeoMutt/20201120 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 05 Aug 2021, Thomas Gleixner wrote: >From: Thomas Gleixner > >The accounting is wrong when either the PI sanity check or the >requeue PI operation fails. Adjust it in the failure path. Ok fortunately these accounting errors are benign considering they are in error paths. This also made me wonder about the requeue PI top-waiter wakeup from futex_proxy_trylock_atomic(), which is always required with nr_wakers == 1. We account for it on the successful case we acquired the lock on it's behalf (and thus requeue_pi_wake_futex was called), but if the corresponding lookup_pi_state fails, we'll retry. So, shouldn't the task_count++ only be considered when we know the requeueing is next (a successful top_waiter acquiring the lock+pi state)? @@ -2260,7 +2260,6 @@ static int futex_requeue(u32 __user *uaddr1, unsigned int flags, */ if (ret > 0) { WARN_ON(pi_state); - task_count++; /* * If we acquired the lock, then the user space value * of uaddr2 should be vpid. It cannot be changed by @@ -2275,6 +2274,8 @@ static int futex_requeue(u32 __user *uaddr1, unsigned int flags, */ ret = lookup_pi_state(uaddr2, ret, hb2, &key2, &pi_state, &exiting); + if (!ret) + task_count++; } switch (ret) { Also, looking at the code, I think we can use the goto retry_private optimization for private futexes upon futex_proxy_trylock_atomic lookup_pi_state errors: @@ -2290,8 +2290,11 @@ static int futex_requeue(u32 __user *uaddr1, unsigned int flags, double_unlock_hb(hb1, hb2); hb_waiters_dec(hb2); ret = fault_in_user_writeable(uaddr2); - if (!ret) + if (!ret) { + if (!(flags & FLAGS_SHARED)) + goto retry_private; goto retry; + } return ret; case -EBUSY: case -EAGAIN: Thanks, Davidlohr