Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp426583imm; Thu, 31 May 2018 03:06:25 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLM49WxdqJq51uOLqDZvzBSyAe6w5TN7cnj0b4YLcn0jW1MDZv1Ydxn125Qw6sTfap0agjI X-Received: by 2002:a63:744c:: with SMTP id e12-v6mr5050648pgn.4.1527761185826; Thu, 31 May 2018 03:06:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527761185; cv=none; d=google.com; s=arc-20160816; b=qKGjFltLTwj9+96I4Vq5rswzCbluu8UN9UiO8gqTJQ2BXf4vTCNwGB7J0LZz9dq1Lm YXeVP6WPZwKeFOQmgqV22iYyubNm/Z/f8AlwkyIxolEQDAn8ZUqfqLD0g/7PAn4plRHP +OPLagLOUcNn6JrbICI+DagsNW/x6O2imV91M2Qc9UU1nEG87KPPdc9iVJzbFASteEES YHREfD8Qfmj/BKSosLimQQK5KGKobZxqO+auD/AaG8yI+f7V93SWBS8Jp2iC2x6Qcbf0 rCQVCXCnwj2sX8YUoKdHUvmgNkP680AEv11eijjjv/41SxHYdtKQI7FVpBOcBXjpiPWS 8q1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=t0VT/MdTPonNW69Q6yYStH/1SIZierLK9lttP1BCRC0=; b=MpYbD56bMuCvU+MJ/23WNHPFiNBmg0VQ1JNgZTN3s8qWP5WvoVJddB78NZT7Asbqfg VV58ASUa1tzsbTH+9QKd7HSkNrQKGYdZxkZSEg4rcwQT3Wk7OaC3kmSc6leBNpNKRLei 8yl2a5lXL8fPk/IN+EC9DgcRdZHX2sCg214zAi/sOU5qOY6BElhSm4sJ9nxYCGMlLHF8 NjBOeP256YJ1eDiQwrIefM0i04AILowSm6SAhurhovf6wyk0VvsXmGhGxLWyWLsNMbqH mGDegGlCF5VwSG1zi4rLwPMzzRIcvta5wWtYi11vH73H1r/+B05VOdOrqBvhOhZzxRh1 89EA== 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 1-v6si36284863plk.521.2018.05.31.03.06.11; Thu, 31 May 2018 03:06:25 -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 S1754409AbeEaKFE (ORCPT + 99 others); Thu, 31 May 2018 06:05:04 -0400 Received: from mx2.suse.de ([195.135.220.15]:36442 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754273AbeEaKFB (ORCPT ); Thu, 31 May 2018 06:05:01 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4FC35ACDC; Thu, 31 May 2018 10:05:00 +0000 (UTC) Date: Thu, 31 May 2018 12:04:57 +0200 From: Petr Mladek To: Jia-Ju Bai Cc: bhelgaas@google.com, sergey.senozhatsky@gmail.com, rostedt@goodmis.org, Al Viro , Greg KH , corbet@lwn.net, Linus Torvalds , Linux Kernel Mailing List , Thomas Gleixner , Geert Uytterhoeven , Stephen Boyd , Michael Turquette Subject: Re: Can printk() sleep at runtime? Message-ID: <20180531100457.fncibp5cxdozvbjh@pathway.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Adding Geert and timer people into Cc. On Thu 2018-05-31 17:08:49, Jia-Ju Bai wrote: > Hello, > > I write a static analysis tool (DSAC), and it finds that printk can sleep. > According to this finding, there is an example bug in drivers/pci/pci.c in > Linux-4.16.7. > > Here is the call path for this bug. > Please look at it *from the bottom up*. > > ========== BUG ========== > [FUNC] __might_sleep > kernel/locking/mutex.c: 747: __might_sleep in __mutex_lock_common > kernel/locking/mutex.c: 893: __mutex_lock_common in __mutex_lock > kernel/locking/mutex.c: 908: __mutex_lock in mutex_lock_nested > drivers/clk/clk.c, 123: mutex_lock_nested in clk_prepare_lock > drivers/clk/clk.c, 1369: clk_prepare_lock in clk_core_get_rate > drivers/clk/clk.c, 1393: clk_core_get_rate in clk_get_rate > lib/vsprintf.c, 1450: clk_get_rate in clock The problem is in %pCr print format implementation. It calls clk_get_rate() that might sleep. I wonder if we could use some lock-less alternative instead. Anyway, we need to fix or remove this format. vsprintf-like functions are called in any context and nobody expect that they might sleep. In each case, printk() must call it under logbuf_lock spinlock. Otherwise, it would need to allocate a buffer for the formatted string and it is not acceptable. Best Regards, Petr > lib/vsprintf.c, 1944: clock in pointer > lib/vsprintf.c, 2286: pointer in vsnprintf > lib/vsprintf.c, 2385: vsnprintf in vscnprintf > kernel/printk/printk.c, 1853: vscnprintf in vprintk_emit > kernel/printk/printk.c, 1947: vprintk_emit in vprintk_default > kernel/printk/printk_safe.c, 379: vprintk_default in vprintk_func > kernel/printk/printk.c, 1980: vprintk_func in printk > drivers/pci/pci.c, 5364: printk in pci_specified_resource_alignment > drivers/pci/pci.c, 5313: spin_lock in pci_specified_resource_alignment > > In fact, I suspect that my report is false, because I always have an > impression that printk() cannot sleep. > But according to the call path, I cannot find where I make the mistake... > > So could someone please help me to point the mistake? > > > Best wishes, > Jia-Ju Bai