Received: by 10.223.185.116 with SMTP id b49csp3417958wrg; Mon, 5 Mar 2018 21:34:42 -0800 (PST) X-Google-Smtp-Source: AG47ELvz98BgZPGMAFgsDjkpFeUt5gb+1nw9W/dD8qpnWABiSGAqD1B7tRaI0BvVzTYErULb/tq1 X-Received: by 10.167.130.133 with SMTP id s5mr17567854pfm.238.1520314481974; Mon, 05 Mar 2018 21:34:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520314481; cv=none; d=google.com; s=arc-20160816; b=HhbdyNa+BLKyAghKDcuIgISdtEsD2Bh5dmNVrCflnbWG5zuADHxZVqvZ8zUYwiiwkN 0hd5d3yabZrfOozUcMmS/17GMKxk3Rx8UUWHSDt05yrocjRX8K2yDNwM4beXmbZH+eW+ zW4im8PFjJxc/sHhucn1kAMMUJbXvojwOCzc9D7AJ3KUnfshfcaaDv+faBuCb4oEIDfw bhyY3Al393J+/VxoRdxgZR7ZkvBHRVuC93rUQBF+9HBd48NIamiICcILXmmei8yLQCTM 07vHllifMAvPYYYdrpqfVtJSCCRUORuXiREp1ej0Mup1AtME4rcG6NKuEYBX2VZSspo9 rLpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=8cMP0JR1CVk9rKDP1ueEBNyc04f3IGqCkS0ZPmw5m+E=; b=nmSVaQvwg2hR7Ge9PwEbB/CMLrbB4XsrNiyMCLed1MmH5Fz/Y7x3wa7NiN7WXCCwOH 9MsRBQ5n5pSGBkccel+4ZKI+WG01DGWQwj24zCRy3h86LGZDSGE6duABh9rROPjs08WG WV2o6DFt4WNOjakx7RDQ4/qICV7+wyDU4fsXwbmXHldwFe+Iy3/TGDMQa+eYNT++iU0k bSKr02JkRQnfXJxxlyUVTXrx0jhbjrsV8fUrdfQAgAK/dsRkrjq89FPjWYp/6sDzKghJ VALzBiOtNlUvoaMPJK1dQBFSmla6L10He/lyQ19sOG09WhV7Zr1PmeTSyxLLpMDa7rXG 42uQ== ARC-Authentication-Results: i=1; mx.google.com; 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 b12si9310859pgq.773.2018.03.05.21.34.15; Mon, 05 Mar 2018 21:34:41 -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; 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 S1750788AbeCFFcx (ORCPT + 99 others); Tue, 6 Mar 2018 00:32:53 -0500 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:47582 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750723AbeCFFcw (ORCPT ); Tue, 6 Mar 2018 00:32:52 -0500 Received: from unknown (HELO lgeamrelo01.lge.com) (156.147.1.125) by 156.147.23.52 with ESMTP; 6 Mar 2018 14:32:50 +0900 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: byungchul.park@lge.com Received: from unknown (HELO localhost.localdomain) (10.177.222.33) by 156.147.1.125 with ESMTP; 6 Mar 2018 14:32:50 +0900 X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com From: Byungchul Park To: jiangshanlai@gmail.com, paulmck@linux.vnet.ibm.com, josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com Cc: linux-kernel@vger.kernel.org, kernel-team@lge.com Subject: [RFC] rcu: Prevent expedite reporting within RCU read-side section Date: Tue, 6 Mar 2018 14:31:58 +0900 Message-Id: <1520314318-30916-1-git-send-email-byungchul.park@lge.com> X-Mailer: git-send-email 1.9.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Paul and RCU folks, I am afraid I correctly understand and fix it. But I really wonder why sync_rcu_exp_handler() reports the quiescent state even in the case that current task is within a RCU read-side section. Do I miss something? If I correctly understand it and you agree with it, I can add more logic which make it more expedited by boosting current or making it urgent when we fail to report the quiescent state on the IPI. ----->8----- From 0b0191f506c19ce331a1fdb7c2c5a00fb23fbcf2 Mon Sep 17 00:00:00 2001 From: Byungchul Park Date: Tue, 6 Mar 2018 13:54:41 +0900 Subject: [RFC] rcu: Prevent expedite reporting within RCU read-side section We report the quiescent state for this cpu if it's out of RCU read-side section at the moment IPI was just fired during the expedite process. However, current code reports the quiescent state even in the case: 1) the current task is still within a RCU read-side section 2) the current task has been blocked within the RCU read-side section Since we don't get to the quiescent state yet in the case, we shouldn't report it but check it another time. Signed-off-by: Byungchul Park --- kernel/rcu/tree_exp.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h index 73e1d3d..cc69d14 100644 --- a/kernel/rcu/tree_exp.h +++ b/kernel/rcu/tree_exp.h @@ -731,13 +731,13 @@ static void sync_rcu_exp_handler(void *info) /* * We are either exiting an RCU read-side critical section (negative * values of t->rcu_read_lock_nesting) or are not in one at all - * (zero value of t->rcu_read_lock_nesting). Or we are in an RCU - * read-side critical section that blocked before this expedited - * grace period started. Either way, we can immediately report - * the quiescent state. + * (zero value of t->rcu_read_lock_nesting). We can immediately + * report the quiescent state. */ - rdp = this_cpu_ptr(rsp->rda); - rcu_report_exp_rdp(rsp, rdp, true); + if (t->rcu_read_lock_nesting <= 0) { + rdp = this_cpu_ptr(rsp->rda); + rcu_report_exp_rdp(rsp, rdp, true); + } } /** -- 1.9.1