Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3285403pxk; Tue, 15 Sep 2020 15:21:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8XojbOeiCQAV/PMSib7FPSQ+JmjVBFoWaPbAg6ysC+SC/sNReMvAJTgPtu+hEyVm3JybA X-Received: by 2002:a17:906:850e:: with SMTP id i14mr22050604ejx.168.1600208498290; Tue, 15 Sep 2020 15:21:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600208498; cv=none; d=google.com; s=arc-20160816; b=QRZgCCUwmQCt60Yzjzw1P8osB0/79zhSo1h0SkBMKU7AncGS1Ig/guHFjM4pby3bPx evUxG6BIaQOhG1qPLcja+JiPy1Tx0/lbSuOLjudNuD+upVL6m385jqiEDVrcM/OM/HGj 1Dlv91ZLHv936megMG6lbHqwMgcDrEu8SgkWO5IK+FYQPITv9Mt0kquBHMl6IrY4t72b RGoGUWM94kZ6oFIfDsS4/J6KV5igToY8DDMMlDwmwcBR9TL9A/1M01q60z8sufKMPpOP cvPnljzQ/rMI+K54f0ZSDiM9avL0Pbjd6UQChe4jIvf1qQWNt74zjBGFOR0dyyJiJC7Z wXKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=gmRfhl0zVqM19BJLbrFhaB+tlpuWH7TN/PvY9E+maBw=; b=F12nNBTfUSsSmPuo9Lcj5O01RHWbq8+k+caKhwOyHa6GgvntMsqVLuefMeR8EUVneV kOrSntUEr5GMb9Yxf+2ZFfXofXj7sGjACjtK3JrgyUDJ1zEeBRSRfbqY9mMBO3V8mvBI L2HgNe8yU7fbvj8xYWVA13dYjm++KkuNol4besd+DjGYj2S5A4Q5vdN7UDeUdjXQnebT wVxwzDf7vZ+hCl/czpo2uLOQ+a3dTfZfJQJ/Ww5Ayi4fM+RhjCS8ybIUxtQY0IEFGyzF AMUFNkD2XGSTztThrJm4cUwVIpzmOFSSJSRBl2D4AyjhORSljYTdq/odGIsr7Wa3rOoI BDzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=FF5mc2aJ; 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 rk18si9909238ejb.599.2020.09.15.15.21.15; Tue, 15 Sep 2020 15:21:38 -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; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=FF5mc2aJ; 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 S1727689AbgIOWUe (ORCPT + 99 others); Tue, 15 Sep 2020 18:20:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727640AbgIOQ3o (ORCPT ); Tue, 15 Sep 2020 12:29:44 -0400 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1CBBC061226; Tue, 15 Sep 2020 09:04:02 -0700 (PDT) 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; bh=gmRfhl0zVqM19BJLbrFhaB+tlpuWH7TN/PvY9E+maBw=; b=FF5mc2aJQN3WXXp0KhgrGxlZvC 2kfepRAiCwew9sJzhjmD3ARsGPBWDDlwf+Tlh+PRLxGkemp7ZANYZW8HqmPW/ZFP8l6xymmhVBoUt J3mY/w5aiAYUPIRvKUX3BcoCK6nQijkjBVE7NEo3oM5IrTET490HcTnmgUH25mXC2QK6e6mgogCwd 00VgONh4RgQzCSkY2YUOs7HN6SfnVqh79c4wyoiZZ42sIwQp91pUKUPm69KHFEaB+0hvNZU7Ivark RcRRKO8/JUOKJcMULRFNERftqqAtH5BgKYS2YxcpBIeJ+MbwLMoJ+NFcnoPR+voul25T1CfmKha8l oW8WA1sg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIDQo-0002Ac-5g; Tue, 15 Sep 2020 16:03:47 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id AA959301E02; Tue, 15 Sep 2020 18:03:44 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 50BEB205A5BA8; Tue, 15 Sep 2020 18:03:44 +0200 (CEST) Date: Tue, 15 Sep 2020 18:03:44 +0200 From: peterz@infradead.org To: Oleg Nesterov Cc: Hou Tao , Ingo Molnar , Will Deacon , Dennis Zhou , Tejun Heo , Christoph Lameter , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jan Kara Subject: Re: [RFC PATCH] locking/percpu-rwsem: use this_cpu_{inc|dec}() for read_count Message-ID: <20200915160344.GH35926@hirez.programming.kicks-ass.net> References: <20200915140750.137881-1-houtao1@huawei.com> <20200915150610.GC2674@hirez.programming.kicks-ass.net> <20200915153113.GA6881@redhat.com> <20200915155150.GD2674@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200915155150.GD2674@hirez.programming.kicks-ass.net> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 15, 2020 at 05:51:50PM +0200, peterz@infradead.org wrote: > Anyway, I'll rewrite the Changelog and stuff it in locking/urgent. How's this? --- Subject: locking/percpu-rwsem: Use this_cpu_{inc,dec}() for read_count From: Hou Tao Date: Tue, 15 Sep 2020 22:07:50 +0800 From: Hou Tao The __this_cpu*() accessors are (in general) IRQ-unsafe which, given that percpu-rwsem is a blocking primitive, should be just fine. However, file_end_write() is used from IRQ context and will cause load-store issues. Fixing it by using the IRQ-safe this_cpu_*() for operations on read_count. This will generate more expensive code on a number of platforms, which might cause a performance regression for some of the other percpu-rwsem users. If any such is reported, we can consider alternative solutions. Fixes: 70fe2f48152e ("aio: fix freeze protection of aio writes") Signed-off-by: Hou Tao Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200915140750.137881-1-houtao1@huawei.com --- include/linux/percpu-rwsem.h | 8 ++++---- kernel/locking/percpu-rwsem.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) --- a/include/linux/percpu-rwsem.h +++ b/include/linux/percpu-rwsem.h @@ -60,7 +60,7 @@ static inline void percpu_down_read(stru * anything we did within this RCU-sched read-size critical section. */ if (likely(rcu_sync_is_idle(&sem->rss))) - __this_cpu_inc(*sem->read_count); + this_cpu_inc(*sem->read_count); else __percpu_down_read(sem, false); /* Unconditional memory barrier */ /* @@ -79,7 +79,7 @@ static inline bool percpu_down_read_tryl * Same as in percpu_down_read(). */ if (likely(rcu_sync_is_idle(&sem->rss))) - __this_cpu_inc(*sem->read_count); + this_cpu_inc(*sem->read_count); else ret = __percpu_down_read(sem, true); /* Unconditional memory barrier */ preempt_enable(); @@ -103,7 +103,7 @@ static inline void percpu_up_read(struct * Same as in percpu_down_read(). */ if (likely(rcu_sync_is_idle(&sem->rss))) { - __this_cpu_dec(*sem->read_count); + this_cpu_dec(*sem->read_count); } else { /* * slowpath; reader will only ever wake a single blocked @@ -115,7 +115,7 @@ static inline void percpu_up_read(struct * aggregate zero, as that is the only time it matters) they * will also see our critical section. */ - __this_cpu_dec(*sem->read_count); + this_cpu_dec(*sem->read_count); rcuwait_wake_up(&sem->writer); } preempt_enable(); --- a/kernel/locking/percpu-rwsem.c +++ b/kernel/locking/percpu-rwsem.c @@ -45,7 +45,7 @@ EXPORT_SYMBOL_GPL(percpu_free_rwsem); static bool __percpu_down_read_trylock(struct percpu_rw_semaphore *sem) { - __this_cpu_inc(*sem->read_count); + this_cpu_inc(*sem->read_count); /* * Due to having preemption disabled the decrement happens on @@ -71,7 +71,7 @@ static bool __percpu_down_read_trylock(s if (likely(!atomic_read_acquire(&sem->block))) return true; - __this_cpu_dec(*sem->read_count); + this_cpu_dec(*sem->read_count); /* Prod writer to re-evaluate readers_active_check() */ rcuwait_wake_up(&sem->writer);