From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C538C433ED for ; Tue, 6 Apr 2021 11:17:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD160613C6 for ; Tue, 6 Apr 2021 11:17:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241564AbhDFLSC (ORCPT ); Tue, 6 Apr 2021 07:18:02 -0400 Received: from mx2.suse.de ([195.135.220.15]:54486 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233034AbhDFLSB (ORCPT ); Tue, 6 Apr 2021 07:18:01 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1617707873; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fSuO/VW+4decWYFfrvqFXfusfZIlDNCC7v2+c0XWZNo=; b=PAPEhIZfLegtekKTZbyfOl81UNz8pz/kgdVoCWlQ7KlRomwHba9R9oKWB7w9Fro7JYGctH JBUkAnWeVgDeuUYHC5hWZE8psWje/FUDf0OHOZlEGwVr885jT6I0PNz7c4TKgneYv7NhyW okifsrMShl9eL/r1m+KFPF8Amq2bFnw= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C581FB155; Tue, 6 Apr 2021 11:17:52 +0000 (UTC) Date: Tue, 6 Apr 2021 13:17:48 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: John Ogness , Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , linux-kernel@vger.kernel.org, Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Eric Biederman , Christophe Leroy , Nicholas Piggin , Alistair Popple , Jordan Niethe , Peter Zijlstra , "Aneesh Kumar K.V" , Andrew Morton , Kees Cook , Tiezhu Yang , Alexey Kardashevskiy , Yue Hu , Rafael Aquini , "Guilherme G. Piccoli" , "Paul E. McKenney" , linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org Subject: Re: [PATCH printk v2 2/5] printk: remove safe buffers Message-ID: References: <20210330153512.1182-1-john.ogness@linutronix.de> <20210330153512.1182-3-john.ogness@linutronix.de> <87a6qiqgzr.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 2021-04-02 11:14:18, Sergey Senozhatsky wrote: > On (21/04/01 16:17), Petr Mladek wrote: > > > For the long term, we should introduce a printk-context API that allows > > > callers to perfectly pack their multi-line output into a single > > > entry. We discussed [0][1] this back in August 2020. > > > > We need a "short" term solution. There are currently 3 solutions: > > > > 1. Keep nmi_safe() and all the hacks around. > > > > 2. Serialize nmi_cpu_backtrace() by a spin lock and later by > > the special lock used also by atomic consoles. > > > > 3. Tell complaining people how to sort the messed logs. > > Are we talking about nmi_cpu_backtrace()->dump_stack() or some > other path? It is about serializing if (regs) show_regs(regs); else dump_stack(); in nmi_cpu_backtrace() when it is triggered on many(all) CPUs at the same time. > dump_stack() seems to be already serialized by `dump_lock`. Hmm, > show_regs() is not serialized, seems like it should be under the > same `dump_lock` as dump_stack(). Ah, I think that you already mentioned it in the past and I forget it. Yes, we would need to synchronize all these dump/show functions using the same lock. It is already the lock that might be taken recursively on the same CPU. In each case, we must not introduce another lock in nmi_cpu_backtrace() because it might cause deadlock with @dump_lock. Anyway, I would really like to keep the dumps serialized. So, we either need to use the same lock everywhere or we need to keep nmi_safe buffers for now. I would like to remove the nmi_safe buffers in the long term but I am fine with doing it later after the consoles rework. I'll leave the prioritization for John who is doing the work and might have some preferences. Best Regards, Petr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D992C433ED for ; Tue, 6 Apr 2021 11:18:27 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EF3286128B for ; Tue, 6 Apr 2021 11:18:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF3286128B Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FF4lP3S78z3br2 for ; Tue, 6 Apr 2021 21:18:25 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=suse.com header.i=@suse.com header.a=rsa-sha256 header.s=susede1 header.b=PAPEhIZf; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=suse.com (client-ip=195.135.220.15; helo=mx2.suse.de; envelope-from=pmladek@suse.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=suse.com header.i=@suse.com header.a=rsa-sha256 header.s=susede1 header.b=PAPEhIZf; dkim-atps=neutral Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FF4kt4Xqdz2yx1 for ; Tue, 6 Apr 2021 21:17:57 +1000 (AEST) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1617707873; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fSuO/VW+4decWYFfrvqFXfusfZIlDNCC7v2+c0XWZNo=; b=PAPEhIZfLegtekKTZbyfOl81UNz8pz/kgdVoCWlQ7KlRomwHba9R9oKWB7w9Fro7JYGctH JBUkAnWeVgDeuUYHC5hWZE8psWje/FUDf0OHOZlEGwVr885jT6I0PNz7c4TKgneYv7NhyW okifsrMShl9eL/r1m+KFPF8Amq2bFnw= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C581FB155; Tue, 6 Apr 2021 11:17:52 +0000 (UTC) Date: Tue, 6 Apr 2021 13:17:48 +0200 From: Petr Mladek To: Sergey Senozhatsky Subject: Re: [PATCH printk v2 2/5] printk: remove safe buffers Message-ID: References: <20210330153512.1182-1-john.ogness@linutronix.de> <20210330153512.1182-3-john.ogness@linutronix.de> <87a6qiqgzr.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sergey Senozhatsky , Peter Zijlstra , Paul Mackerras , Tiezhu Yang , Rafael Aquini , "Paul E. McKenney" , "Aneesh Kumar K.V" , Alexey Kardashevskiy , Yue Hu , Jordan Niethe , Kees Cook , John Ogness , Alistair Popple , "Guilherme G. Piccoli" , Nicholas Piggin , Steven Rostedt , Thomas Gleixner , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky , Eric Biederman , Andrew Morton , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri 2021-04-02 11:14:18, Sergey Senozhatsky wrote: > On (21/04/01 16:17), Petr Mladek wrote: > > > For the long term, we should introduce a printk-context API that allows > > > callers to perfectly pack their multi-line output into a single > > > entry. We discussed [0][1] this back in August 2020. > > > > We need a "short" term solution. There are currently 3 solutions: > > > > 1. Keep nmi_safe() and all the hacks around. > > > > 2. Serialize nmi_cpu_backtrace() by a spin lock and later by > > the special lock used also by atomic consoles. > > > > 3. Tell complaining people how to sort the messed logs. > > Are we talking about nmi_cpu_backtrace()->dump_stack() or some > other path? It is about serializing if (regs) show_regs(regs); else dump_stack(); in nmi_cpu_backtrace() when it is triggered on many(all) CPUs at the same time. > dump_stack() seems to be already serialized by `dump_lock`. Hmm, > show_regs() is not serialized, seems like it should be under the > same `dump_lock` as dump_stack(). Ah, I think that you already mentioned it in the past and I forget it. Yes, we would need to synchronize all these dump/show functions using the same lock. It is already the lock that might be taken recursively on the same CPU. In each case, we must not introduce another lock in nmi_cpu_backtrace() because it might cause deadlock with @dump_lock. Anyway, I would really like to keep the dumps serialized. So, we either need to use the same lock everywhere or we need to keep nmi_safe buffers for now. I would like to remove the nmi_safe buffers in the long term but I am fine with doing it later after the consoles rework. I'll leave the prioritization for John who is doing the work and might have some preferences. Best Regards, Petr