lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YQlKAeXS9MPmE284@smile.fi.intel.com>
Date:   Tue, 3 Aug 2021 16:52:01 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Petr Mladek <pmladek@...e.com>, Tony Lindgren <tony@...mide.com>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Jason Wessel <jason.wessel@...driver.com>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Douglas Anderson <dianders@...omium.org>,
        Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
        "Gautham R. Shenoy" <ego@...ux.vnet.ibm.com>,
        Chengyang Fan <cy.fan@...wei.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Bhaskar Chowdhury <unixbhaskar@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Cédric Le Goater <clg@...d.org>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        linuxppc-dev@...ts.ozlabs.org,
        kgdb-bugreport@...ts.sourceforge.net,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Vitor Massaru Iha <vitor@...saru.org>,
        Sedat Dilek <sedat.dilek@...il.com>,
        Changbin Du <changbin.du@...el.com>,
        Sumit Garg <sumit.garg@...aro.org>,
        Cengiz Can <cengiz@...nel.wtf>,
        Jiri Slaby <jirislaby@...nel.org>,
        Paul Cercueil <paul@...pouillou.net>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Andrew Jeffery <andrew@...id.au>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        kuldip dwivedi <kuldip.dwivedi@...esoftware.com>,
        Wang Qing <wangqing@...o.com>, Andrij Abyzov <aabyzov@....com>,
        Johan Hovold <johan@...nel.org>,
        Eddie Huang <eddie.huang@...iatek.com>,
        Claire Chang <tientzu@...omium.org>,
        Hsin-Yi Wang <hsinyi@...omium.org>,
        Zhang Qilong <zhangqilong3@...wei.com>,
        "Maciej W. Rozycki" <macro@...am.me.uk>,
        Guenter Roeck <linux@...ck-us.net>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Serge Semin <Sergey.Semin@...kalelectronics.ru>,
        Al Cooper <alcooperx@...il.com>, linux-serial@...r.kernel.org,
        linux-mips@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH printk v1 00/10] printk: introduce atomic consoles and
 sync mode

On Tue, Aug 03, 2021 at 03:18:51PM +0206, John Ogness wrote:
> Hi,
> 
> This is the next part of our printk-rework effort (points 3 and
> 4 of the LPC 2019 summary [0]).
> 
> Here the concept of "atomic consoles" is introduced through  a
> new (optional) write_atomic() callback for console drivers. This
> callback must be implemented as an NMI-safe variant of the
> write() callback, meaning that it can function from any context
> without relying on questionable tactics such as ignoring locking
> and also without relying on the synchronization of console
> semaphore.
> 
> As an example of how such an atomic console can look like, this
> series implements write_atomic() for the 8250 UART driver.
> 
> This series also introduces a new console printing mode called
> "sync mode" that is only activated when the kernel is about to
> end (such as panic, oops, shutdown, reboot). Sync mode can only
> be activated if atomic consoles are available. A system without
> registered atomic consoles will be unaffected by this series.
> 
> When in sync mode, the console printing behavior becomes:
> 
> - only consoles implementing write_atomic() will be called
> 
> - printing occurs within vprintk_store() instead of
>   console_unlock(), since the console semaphore is irrelevant
>   for atomic consoles
> 
> For systems that have registered atomic consoles, this series
> improves the reliability of seeing crash messages by using new
> locking techniques rather than "ignoring locks and hoping for
> the best". In particular, atomic consoles rely on the
> CPU-reentrant spinlock (i.e. the printk cpulock) for
> synchronizing console output.

If console is runtime suspended, who will bring it up?
Does it mean that this callback can't be implemented on the consoles that
do runtime suspend (some of 8250 currently, for example)?

-- 
With Best Regards,
Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ