From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752932AbcJAB4w (ORCPT ); Fri, 30 Sep 2016 21:56:52 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:36771 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751164AbcJAB4n (ORCPT ); Fri, 30 Sep 2016 21:56:43 -0400 From: Sean Hudson X-Google-Original-From: Sean Hudson Subject: Re: [RFC PATCH v1 0/2] printk: Shared kernel logging To: Kees Cook References: <1475196956-32274-1-git-send-email-sean_hudson@mentor.com> Cc: LKML , Andrew Morton , Thomas Gleixner , Yang Shi , Ingo Molnar , Prarit Bhargava , Rasmus Villemoes , "Paul E. McKenney" , Yaowei Bai , Andrey Ryabinin , Johannes Weiner , Tejun Heo , Arnd Bergmann , Ard Biesheuvel , Thomas Garnier , Petr Mladek , Nicolas Pitre , Sergey Senozhatsky , Borislav Petkov , Tim Bird , Steven Rostedt , Grant Likely Organization: Mentor Graphics - Embedded Software Division Message-ID: <64e98e70-7325-3398-100d-a9868fd1bb6a@mentor.com> Date: Fri, 30 Sep 2016 20:56:38 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8kPoetws3n6djJCN6FnxR8lBjrRlpRwJC" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8kPoetws3n6djJCN6FnxR8lBjrRlpRwJC Content-Type: multipart/mixed; boundary="v4oC3mkohPAF5XufuvuDLOCF3mOQln8d7"; protected-headers="v1" From: Sean Hudson To: Kees Cook Cc: LKML , Andrew Morton , Thomas Gleixner , Yang Shi , Ingo Molnar , Prarit Bhargava , Rasmus Villemoes , "Paul E. McKenney" , Yaowei Bai , Andrey Ryabinin , Johannes Weiner , Tejun Heo , Arnd Bergmann , Ard Biesheuvel , Thomas Garnier , Petr Mladek , Nicolas Pitre , Sergey Senozhatsky , Borislav Petkov , Tim Bird , Steven Rostedt , Grant Likely Message-ID: <64e98e70-7325-3398-100d-a9868fd1bb6a@mentor.com> Subject: Re: [RFC PATCH v1 0/2] printk: Shared kernel logging References: <1475196956-32274-1-git-send-email-sean_hudson@mentor.com> In-Reply-To: --v4oC3mkohPAF5XufuvuDLOCF3mOQln8d7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/29/2016 8:36 PM, Kees Cook wrote: > On Thu, Sep 29, 2016 at 5:55 PM, Sean Hudson > wrote: >> This patch set is based on Linus' v4.8-rc8 tag. >>=20 >> This debug feature allows the kernel to use an external buffer and >> control block for kernel log messages. The feature is controlled by >> an optional command line parameter. The existing buffer and control >> block can contain existing log messages from previous boot cycles >> and/or the bootloader. The command line parameter was chosen for >> flexibility, cross arch portability, and the ability to dynamically >> enable/disable this feature. The parameter specifies the address of >> a control block used to replace the default log buffer. Existing >> bootloader and kernel log messages are kept, in order, inside the >> new buffer. After a boot that preserves the buffer contents, a=20 >> bootloader can display both kernel and bootloader log entries from >> multiple, previous boots. It also allows the kernel to display >> bootloader log entries along with its own messages. >>=20 >> This feature is intended for debug purposes and has no effect >> unless the command line parameter is specified. Further, it >> validates the passed control block carefully and if any checks >> fail, it falls back to the default behaviour. As such, it can be >> left enabled by default. >>=20 >> Memory Reservation >>=20 >> This feature expects the bootloader to reserve/preserve the shared >> buffer memory. This reservation needs to prevent the kernel from >> overwriting the external log control block and log entries. In my >> testing, I've used the 'fdt' commands in uboot to dynamically >> inject reserved memory regions via the DT to the kernel. >=20 > Interesting! I wonder if this can be adjusted to incorporate the=20 > existing console logging feature in the pstore which does a similar=20 > thing? Though pstore doesn't know about bootloader logs, really, > it's just storing kernel logs in a ring buffer. Maybe this can > provide a backend to pstore or something, especially since pstore > initialization happens "too late" for this to really be very > sensible. It just seems like it'd be nice to have a single persistent > console memory region... >=20 I don't know that much about pstore. From your description though, it sounds feasible to put the two together at some point. How arch specific is pstore? --=20 Sean --v4oC3mkohPAF5XufuvuDLOCF3mOQln8d7-- --8kPoetws3n6djJCN6FnxR8lBjrRlpRwJC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX7xfWAAoJEC2KalNZVFwRuFwP/jSImFOxrkW1Vpq6WNCifDHx uMLlt2s2HEiB2tU74uL5UYWxek1CdUTWuIlwDoxQe68SNXveBDXN8F3lCStJWztn gIhDJpo/bZYdJ6P88vinaDwUpOx3eYKvmQHPmVITINo1f7/wDPqquUxQ6TWP7E50 evI2lJXqRq+Y9I93GeqmCa7NVbkHw3OXOecl1WwWvjPDmwM+WEiYCsvS6k//7Aot 6bUUAtSsoAsQz7bifsSI/cgOsAH+hZUh7WOzmtzm2VOUM2BoNeo0GpVTAT1iYQta mhVhpwJEMDYyRd5Lw4Xv+oSX37K3Qj34eZLzAmns/RrivbxEwWzEdzIrR/+79hfg mXWwHXUNCkna6w/jru0W3k3tZqoG34a3kOEskCqTILftK/FoF8GXs9wqQ8kajydK XNLLQUk5vH7VHuGmzpn3M+i5dC7GxNjyTp/GHSqAh7P8HfWrR323HU9INxs8i2kN bMwYv9fEYKevxxyr61fjxGyEC0eVbT59hAJvBYBTQRQIa1R4vI5hGqifKYUkKIr7 tsoYRcXHPayQEAxSy8mB06haLzL2Ty0F5h4zrJIKhfUpLCfupScvODucaivVtyBM Dey2RJ0JT5ib62UBURmZMMyv11tpXu1XKLSKxA1Ysk1PhQXsLUwVT+R4T6gJTxQA 70pfXI+LKIdG8L0S43pm =/rpJ -----END PGP SIGNATURE----- --8kPoetws3n6djJCN6FnxR8lBjrRlpRwJC--