Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1173010imm; Fri, 22 Jun 2018 11:34:04 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLcaJRJGksXF5aPXKrzlrkqGzcJbpg5BZFtFSn46aXMZpQMlTYMOaqu9eHt7EK/QYjPwvZU X-Received: by 2002:a63:bd01:: with SMTP id a1-v6mr2380967pgf.319.1529692444209; Fri, 22 Jun 2018 11:34:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529692444; cv=none; d=google.com; s=arc-20160816; b=dTzEeHi1gIxL2XupAT8bmh6pHcJx6v7rgZZ55sCy92QNV6Cy7cYMp5CQDFxyVrwfMN QBO9e2eY9/YUC0F/vpW2B4JlOld+BXa/k9ckGt1r9e/9Qke9bRzzqHP1b/jGnZCs0oI4 FBAjtg+foOcdA0qKE+Tw2Ju1RQM0i3/geZa+ZqwPbWpzxfyMjKQj8szIevqzNhsxcH6o sKn3WWpbvLIVrx60VVZqmS1xmK1/8QFyQTH52FeDBVabPKt4o0VTqpc9lanYsTbJXiGK qGufz1dpPbgDBGbAqd53n7e5d35MMy9wEowF5SYXmIvXAao7zKcZDNQAd56Y+GvzSb0k qB3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=23DC5i89Zfo70tHZaz+d64rQ3FTPvj7wYfS5DX2aoQQ=; b=U0fiJAYSY+/gNUlnSS3Ycpp2z6YKOlkolM6RKxwSTK9nA2fPnFpPxEkTPEbDLBZkFN vi0F/HeAR/1s/IS/E4ztg9MJm1jT9u11AOGcIV/Q2jWKrZRy4WtajnXYAoBcu85vMOJB u7JfD/KYyq1GSbFLp6ihsiVndgwl6BUOv1AlpIRJ/FI38T3JeGSm11d6tVzp0arsGPgL KEKwrhyrEpxVspVT3mKomnL74OjuJIkaWN0od9Fn7KdeKJtWBec/XQF7pUYLqwYLf8IG JmPapG9tqsecOXeroHKHFUNiHoqo8QsJEer/ZlIb327xfa1uhPP2Vnl0q2hhgYFDrBdk T7Dg== 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 s4-v6si6343606pgq.454.2018.06.22.11.33.40; Fri, 22 Jun 2018 11:34:04 -0700 (PDT) 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 S934205AbeFVScv (ORCPT + 99 others); Fri, 22 Jun 2018 14:32:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:36812 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933869AbeFVScu (ORCPT ); Fri, 22 Jun 2018 14:32:50 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 25AEE2473E; Fri, 22 Jun 2018 18:32:49 +0000 (UTC) Date: Fri, 22 Jun 2018 14:32:47 -0400 From: Steven Rostedt To: Joel Fernandes Cc: "Paul E. McKenney" , Byungchul Park , Byungchul Park , jiangshanlai@gmail.com, josh@joshtriplett.org, Mathieu Desnoyers , linux-kernel@vger.kernel.org, kernel-team@lge.com, luto@kernel.org Subject: Re: [RFC 2/2] rcu: Remove ->dynticks_nmi_nesting from struct rcu_dynticks Message-ID: <20180622143247.781028b1@gandalf.local.home> In-Reply-To: <20180622181916.GA13628@joelaf.mtv.corp.google.com> References: <1529484440-20634-1-git-send-email-byungchul.park@lge.com> <1529484440-20634-2-git-send-email-byungchul.park@lge.com> <20180620145814.GQ3593@linux.vnet.ibm.com> <20180620164902.GW3593@linux.vnet.ibm.com> <20180622055659.GA255098@joelaf.mtv.corp.google.com> <20180622132843.GN3593@linux.vnet.ibm.com> <20180622181916.GA13628@joelaf.mtv.corp.google.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Jun 2018 11:19:16 -0700 Joel Fernandes wrote: > Sure. So in a later thread you mentioned "usermode helpers". I took a closer > look at that subsystem, and it seems you can execute usermode helpers from > atomic sections with help of UMH_NO_WAIT flag. > > Then I checked where this flag is used and it turns out its from the > mce_work_trigger function in x86/kernel/cpu/mcheck/dev-mcelog.c which can be > called infact from an interrupt context (mce_notify_irq). > > Is this the usecase you remember causing this weird transitions to userspace? But this case still looks like it uses work queues, it just doesn't wait for the result. I'll have to look at the code from what it looked like back in 2011, to see if there was an actual issue here back then. -- Steve