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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 64838C76190 for ; Thu, 25 Jul 2019 20:21:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 310C921849 for ; Thu, 25 Jul 2019 20:21:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="icwWCIiU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726691AbfGYUVZ (ORCPT ); Thu, 25 Jul 2019 16:21:25 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:44667 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726651AbfGYUVY (ORCPT ); Thu, 25 Jul 2019 16:21:24 -0400 Received: by mail-pf1-f194.google.com with SMTP id t16so23273336pfe.11 for ; Thu, 25 Jul 2019 13:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t0Cra5QTZMEsQQCWtg/IrgmE1EkzXk2wzdHi6GNLFH4=; b=icwWCIiUgBV1wHTICVJ8PDBYNM56j1SL56zOuqzadtL/FTJftG29M/5i37umQn5pat 98vgN9o4wCCUl6zlUntg1M2/HAqBcuf46VrRvHnBderCK2JzVC1N/QGeaiGfSXK9s4n5 D6RwN5DHnLXKOq4Ny6b8fOnc2KVD7SZxUUSdcyUfbAIVnumy+pkl0n1aZfxPSnWyIL72 hfdMtqkGubCbZVDRysKpCuE9QGl7AC7BSboaOfM49zJPp3eOwApBz0fXZ3/p4ovL/zBt OQN9pJSLbaG8HsrL0EiinQXd3Ip1iSW8gF7p8zWj9INScAI2FFyHb72jeSzAyZtgcUhN wuPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t0Cra5QTZMEsQQCWtg/IrgmE1EkzXk2wzdHi6GNLFH4=; b=W2jFodAdYyhIHEyyrTY3OIU9zs3I9Piui3n5nb+9r65OAjgeA1d8ZwBPnbMO6xuArA n7UchpTtHEh2pvwuVX0NIaykXqfCj47TZw/E+GD5eWLxtq70Z57L1pWdyywIlXyZiz9N h582C6LMIVBbCeHqWctUc45k0flsiGrjMRIRC5ukYVNY8NKKsZWbAgzuO+/FsJqWchNc koPDDJ7+gbDEJkIcrHOtajijopMjD+jrB2rZ5dYFGgJRmXYq2/SmiYomgwQ+nDQBWsnU KZviU32iNtErkZ4IIIphjz2oyeQJiMV9q+O/ecAv6GQSmivFoj5uU2hQ5sj+pSUhMDhL dinw== X-Gm-Message-State: APjAAAXi3fsKSM8QrdxcUh7jQcQxWaoME8LAIJHE4KkptKZUE7gwAC+Z lmT1CIPTlqpU45kK21ld1yKj/TpFyUk6BWlMaz8/nA== X-Google-Smtp-Source: APXvYqxzvrolA8VKWhh/PCWTspZ6X1ImHyHFsNde4xNXJqWmdb4kpAbmdfPWVY+GfuBUC1O9mftgHi7aVHIiE4jBL10= X-Received: by 2002:a63:b919:: with SMTP id z25mr87114130pge.201.1564086083398; Thu, 25 Jul 2019 13:21:23 -0700 (PDT) MIME-Version: 1.0 References: <20190716175021.9CA412173C@mail.kernel.org> <20190718175024.C3EC421019@mail.kernel.org> <20190719000834.GA3228@google.com> <20190722200347.261D3218C9@mail.kernel.org> <20190722235411.06C1320840@mail.kernel.org> <20190724073125.xyzfywctrcvg6fmh@pathway.suse.cz> In-Reply-To: <20190724073125.xyzfywctrcvg6fmh@pathway.suse.cz> From: Brendan Higgins Date: Thu, 25 Jul 2019 13:21:12 -0700 Message-ID: Subject: Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger To: Petr Mladek Cc: Stephen Boyd , Jeff Dike , Kevin Hilman , Logan Gunthorpe , Michael Ellerman , Daniel Vetter , Amir Goldstein , Frank Rowand , Steven Rostedt , Kees Cook , David Rientjes , kunit-dev@googlegroups.com, Kieran Bingham , Peter Zijlstra , Randy Dunlap , Joel Stanley , Luis Chamberlain , Rob Herring , shuah , wfg@linux.intel.com, Greg KH , Julia Lawall , linux-nvdimm , dri-devel , linux-um@lists.infradead.org, Sasha Levin , "Theodore Ts'o" , Richard Weinberger , Dan Carpenter , Knut Omang , Josh Poimboeuf , Masahiro Yamada , Timothy Bird , devicetree , "open list:DOCUMENTATION" , linux-fsdevel@vger.kernel.org, linux-kbuild , Linux Kernel Mailing List , "open list:KERNEL SELFTEST FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Sender: linux-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On Wed, Jul 24, 2019 at 12:31 AM Petr Mladek wrote: > > On Mon 2019-07-22 16:54:10, Stephen Boyd wrote: > > Quoting Brendan Higgins (2019-07-22 15:30:49) > > > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd wrote: > > > > > > > > > > > > What's the calling context of the assertions and expectations? I still > > > > don't like the fact that string stream needs to allocate buffers and > > > > throw them into a list somewhere because the calling context matters > > > > there. > > > > > > The calling context is the same as before, which is anywhere. > > > > Ok. That's concerning then. > > > > > > > > > I'd prefer we just wrote directly to the console/log via printk > > > > instead. That way things are simple because we use the existing > > > > buffering path of printk, but maybe there's some benefit to the string > > > > stream that I don't see? Right now it looks like it builds a string and > > > > then dumps it to printk so I'm sort of lost what the benefit is over > > > > just writing directly with printk. > > > > > > It's just buffering it so the whole string gets printed uninterrupted. > > > If we were to print out piecemeal to printk, couldn't we have another > > > call to printk come in causing it to garble the KUnit message we are > > > in the middle of printing? > > > > Yes, printing piecemeal by calling printk many times could lead to > > interleaving of messages if something else comes in such as an interrupt > > printing something. Printk has some support to hold "records" but I'm > > not sure how that would work here because KERN_CONT talks about only > > being used early on in boot code. I haven't looked at printk in detail > > though so maybe I'm all wrong and KERN_CONT just works? > > KERN_CONT does not guarantee that the message will get printed > together. The pieces get interleaved with messages printed in > parallel. > > Note that KERN_CONT was originally really meant to be used only during > boot. It was later used more widely and ended in the best effort category. > > There were several attempts to make it more reliable. But it was > always either too complicated or error prone or both. > > You need to use your own buffering if you rely want perfect output. > The question is if it is really worth the complexity. Also note that > any buffering reduces the chance that the messages will reach > the console. Seems like that settles it then. Thanks! > BTW: There is a work in progress on a lockless printk ring buffer. > It will make printk() more secure regarding deadlocks. But it might > make transparent handling of continuous lines even more tricky. > > I guess that local buffering, before calling printk(), will be > even more important then. Well, it might really force us to create > an API for it. Cool! Can you CC me on that discussion? > > Can printk be called once with whatever is in the struct? Otherwise if > > this is about making printk into a structured log then maybe printk > > isn't the proper solution anyway. Maybe a dev interface should be used > > instead that can handle starting and stopping tests (via ioctl) in > > addition to reading test results, records, etc. with read() and a > > clearing of the records. Then the seqfile API works naturally. All of > > this is a bit premature, but it looks like you're going down the path of > > making something akin to ftrace that stores binary formatted > > assertion/expectation records in a lockless ring buffer that then > > formats those records when the user asks for them. > > IMHO, ftrace postpones the text formatting primary because it does not > not want to slow down the traced code more than necessary. It is yet > another layer and there should be some strong reason for it. Noted. Yeah, I would prefer avoiding printing out the info at a separate time. > > I can imagine someone wanting to write unit tests that check conditions > > from a simulated hardirq context via irq works (a driver mock > > framework?), so this doesn't seem far off. > > Note that stroring the messages into the printk log is basically safe in any > context. It uses temporary per-CPU buffers for recursive messages and > in NMI. The only problem is panic() when some CPU gets stuck with the > lock taken. This will get solved by the lockless ringbuffer. Also > the temporary buffers will not be necessary any longer. Sure, I think Stephen's concern is all the supporting code that is involved. Not printk specifically. It just means a lot more of KUnit has to be IRQ safe. > Much bigger problems are with consoles. There are many of them. It > means a lot of code and more locks involved, including scheduler > locks. Note that console lock is a semaphore. That shouldn't affect us though, right? As long as we continue to use the printk interface?