From patchwork Tue Feb 14 16:56:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergey Senozhatsky X-Patchwork-Id: 9572243 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 252B660578 for ; Tue, 14 Feb 2017 16:57:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 04DD128428 for ; Tue, 14 Feb 2017 16:57:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EC2AD2842C; Tue, 14 Feb 2017 16:57:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1E22428428 for ; Tue, 14 Feb 2017 16:57:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754726AbdBNQ5a (ORCPT ); Tue, 14 Feb 2017 11:57:30 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:34085 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754725AbdBNQ5a (ORCPT ); Tue, 14 Feb 2017 11:57:30 -0500 Received: by mail-it0-f66.google.com with SMTP id r141so5895211ita.1; Tue, 14 Feb 2017 08:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=pZF6MypoSgwdNzeBikl1wxTH8YRY6DQALsfUHIcCijA=; b=BDlmE3hlAoum5tkDR2JyBzgmL4EStdvPmB/fhjBmT+qAWsYfy00QDYJOoyOf/xCiq9 X1VqcIqT4sHpSAOOBDKHqKxcel32DDbrJyk1Cw+gjSAe+XuhGkRCNPMoJ+hwhMEIWwCT 4+WDZ0LjhLM/FYQff0BzW9xiMzBJ1gKgYUM6rSqa3ejLnJ6/s6UgQ48JqGxVF2Oqw0NX blumhv6nJ+0Pj9bsPC/VdBLgL2nbsc1xURmqh/ORpv8czMMn+9LwdLVAFYFa8Id2Mnto eXkhQQvPuA3EFki6AZiKVGRXoUBYY7NvJIDDJEueFqTpJq5QkQySqH29+fcRZis4AYBu gSXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=pZF6MypoSgwdNzeBikl1wxTH8YRY6DQALsfUHIcCijA=; b=QImaXjGktrKSNaKoCpfS5x/CXhCTMrWRfWbbpk3u5klObEkF4aPo0k+gnSdRQZEKBl sCD3h/K+g4CuOGwakO/a/3+QRflzG9Z8hLptrMRGn00AxjnlUPZW5zn05Y6C4DTDxrls 4/zFR/9U0A4xv3d7ltNK8h+BFPj72kKTS/PbjUClUzJb0mNiBAwp2ybQRBJPz1QoKZ+4 o6tOGbbqs2I7NnThHiRxB66joeQS8aaTWP4bE6gWnNhodtynLD1ZisAiHZrALLIzxobg o3lhf/Paf0Bj+uS8Uk5c3eu1ytYwsxhLiZkyd4/1GtN51FHOKFKQt+CPQ4P7mqK8CcEa tUfw== X-Gm-Message-State: AMke39nmQr7DYSJSy+Uds/Ko61l/umoGLxSw4wQeBJ/REwaezD6H5W63jVC8XZeVxZ9nKw== X-Received: by 10.99.147.81 with SMTP id w17mr33758653pgm.111.1487091449092; Tue, 14 Feb 2017 08:57:29 -0800 (PST) Received: from localhost ([121.137.63.184]) by smtp.gmail.com with ESMTPSA id b83sm2436814pfe.12.2017.02.14.08.57.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 14 Feb 2017 08:57:28 -0800 (PST) Date: Wed, 15 Feb 2017 01:56:45 +0900 From: Sergey Senozhatsky To: Peter Zijlstra Cc: Sergey Senozhatsky , Tony Lindgren , Petr Mladek , Steven Rostedt , Thomas Gleixner , linux-kernel@vger.kernel.org, Sergey Senozhatsky , "Rafael J. Wysocki" , linux-pm@vger.kernel.org, John Stultz Subject: Re: Regression in next with use printk_safe buffers in printk Message-ID: <20170214165645.GB10321@tigerII.localdomain> References: <20170213185956.GM3897@atomide.com> <20170214160140.GA401@tigerII.localdomain> <20170214161809.GQ6500@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170214161809.GQ6500@twins.programming.kicks-ass.net> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On (02/14/17 17:18), Peter Zijlstra wrote: > On Wed, Feb 15, 2017 at 01:01:40AM +0900, Sergey Senozhatsky wrote: > > > > but I'm a bit confused by rt_b->rt_runtime_lock in this unsafe lock > > scenario (so it's not ABBA, but ABAD) > > > > > lock(hrtimer_bases.lock); > > > lock(&rt_b->rt_runtime_lock); > > > lock(hrtimer_bases.lock); > > > lock(tk_core); > > > > > > > > > Chain exists of: > > > > > > tk_core --> &rt_b->rt_runtime_lock --> hrtimer_bases.lock > > > > > > I'm lacking some knowledge here, sorry. where does the tk_core --> &rt_b->rt_runtime_lock > > come from? > > rt_b->rt_runtime_lock is one of the scheduler locks, since we do > printk() under tk_core, which does semaphore muck, which then includes > the entire scheduler chain of locks. thanks, Peter. that crossed my mind, but I kinda assumed that we do printk() from under tk_core using sched fair, and rt_runtime_lock is from sched rt. so something like below, perhaps. would be helpful if Tony can test it. (I'll send out this patch 'in a proper way' tomorrow, after some sleep, it's 2am here). 8< ==== From e1755b0bf7f8a0be5fdf4dd7303bf4cd150d9d20 Mon Sep 17 00:00:00 2001 From: Sergey Senozhatsky Date: Wed, 15 Feb 2017 01:42:18 +0900 Subject: [PATCH] time/timekeeping_debug: use printk_deferred() Do not call printk() from tk_debug_account_sleep_time(), because tk_debug_account_sleep_time() is called under tk_core seq lock. It's not safe to call printk() under tk_core, because console_sem invokes scheduled (via wake_up_process()->activate_task()), which, in turn, can call timekeeping code again, for instance, via get_time()->ktime_get(). This may result in infinite loop on tk_core. Signed-off-by: Sergey Senozhatsky Tested-by: Tony Lindgren --- kernel/time/timekeeping_debug.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/time/timekeeping_debug.c b/kernel/time/timekeeping_debug.c index ca9fb800336b..b8f7146c3538 100644 --- a/kernel/time/timekeeping_debug.c +++ b/kernel/time/timekeeping_debug.c @@ -75,7 +75,8 @@ void tk_debug_account_sleep_time(struct timespec64 *t) int bin = min(fls(t->tv_sec), NUM_BINS-1); sleep_time_bin[bin]++; - pr_info("Suspended for %lld.%03lu seconds\n", (s64)t->tv_sec, + printk_deferred(KERN_INFO "Suspended for %lld.%03lu seconds\n", + (s64)t->tv_sec, t->tv_nsec / NSEC_PER_MSEC); }