Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp5351214rwl; Sun, 8 Jan 2023 13:29:10 -0800 (PST) X-Google-Smtp-Source: AMrXdXsWodftFOYEzVgo4zJny878PjjFNY5lMaa4s/sfq00siTuKBCnb02TydqNgpoXIOf3qOwca X-Received: by 2002:a05:6402:3998:b0:46b:203:f388 with SMTP id fk24-20020a056402399800b0046b0203f388mr66408671edb.39.1673213350759; Sun, 08 Jan 2023 13:29:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673213350; cv=none; d=google.com; s=arc-20160816; b=tsCAuZG0YBa2yUD669yyhpoEq32r4nTW95CZvr5z28eeasooBGeCnpToW0uRItMptu STPSCo5PBiqybjqCDjKHOIv3uRDGhD+9B98+PkpmxNunk5CuoVxSHVS/vTjo0W8C+iFE SccNXGcfoFHkA8gQzivCNp77kSJxA6uqCthCsI5xhjCVxePGrne3KE8uHHLanOt6zb9x C+msXh2QOO2GRi6EAls5yQa3NM0MP3MyWMx9JrXMrEy0yQ5xBC4dAjQ1ewZg7Gb5TksK OZGbC0q/jckV1tdm9nZWTJmxfku9MCEQVAzr6Qw8RvDisUN84QIpY06n02pMOQoHLvAh MzHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=rD+xdC78MuBzPnH7D1acX1ZI1y5/EvHp/7v5fVb/k04=; b=Jrt3R+rYpZmqhEodXVm3jnh7eOufUytlM3V5J2gJE1dSUaEOM2ZTJG9VxB71BZPnv+ y+tncTBWagTYKTuY/QpBd3Jt5k0u+1ruBSjEnv9XMA2f875whf6sPlXG68fakmpOI/By x+/OjDoUNiljRREvh7TgxqVAE/83u6ZCZ3vZxWz8Z9baYp02pTsGhmIwCe3unifphoAN wENJx4z5zMdHz/vqh02kHlP/NMussSKvEyOa+IbqxxJH1V+MxiqkcJsuEniS5rYIuY1j 54thYO1ML7Gi8RMwnyKzMOz9U0ORP23KNTRGvHR/+d+YGwqptuwe50bJMgeQK/BHXTF7 xY3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=XjXQXUk5; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e25-20020a056402149900b0045c93142111si6576374edv.70.2023.01.08.13.28.57; Sun, 08 Jan 2023 13:29:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=XjXQXUk5; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231383AbjAHVMO (ORCPT + 53 others); Sun, 8 Jan 2023 16:12:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229503AbjAHVMC (ORCPT ); Sun, 8 Jan 2023 16:12:02 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15A79655F for ; Sun, 8 Jan 2023 13:12:01 -0800 (PST) From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1673212318; h=from:from:reply-to:subject:subject: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=rD+xdC78MuBzPnH7D1acX1ZI1y5/EvHp/7v5fVb/k04=; b=XjXQXUk53itPVCf02OZ87Zn/4GQV9c+cdSVuK7refuGH7sFCZ6bk+/uk2g5rbXGqKL7jo0 0uCNbzAb7qyPyCTDfuE8kBjZgOCqSuIRgLZ9RVp+G0tt+lH4DMa3yRgDFh2B92pYgVDRk+ b7eF2/dCWp3WqvIRSK9DyhPR6ZQThDrEiWACN82Ze5cX0q9zSOcComF5JqFHb3zDaS4hg8 OCA94edu7BN8WbVn58tvVpxWnuITa9eCHrnFrQLMTKqcrcHSpRMVCuKb7QXsOjtxpSGv+k TsIIAVLwDPame6f5iDbV8CNVGYCQDLoQQIn9iFVnwYImvJ7c8EKofqH4+Rco2w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1673212318; h=from:from:reply-to:subject:subject: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=rD+xdC78MuBzPnH7D1acX1ZI1y5/EvHp/7v5fVb/k04=; b=C0qrFVPvYRFJ3823IE9cyjOy0hzO+tTno4hqb2yDFF4GBpBYjPoxLuyHIjq+vi5isJCMPR WRXPq30rtI36QHCg== To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: [PATCH printk v4 7/8 v2] printk: use printk_buffers for devkmsg In-Reply-To: References: <20230105103735.880956-1-john.ogness@linutronix.de> <20230105103735.880956-8-john.ogness@linutronix.de> <87fscpch67.fsf@jogness.linutronix.de> <87cz7tch2n.fsf@jogness.linutronix.de> Date: Sun, 08 Jan 2023 22:17:15 +0106 Message-ID: <87pmbospe4.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,INVALID_DATE_TZ_ABSURD, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-01-06, Petr Mladek wrote: >> - if (!prb_read_valid(prb, atomic64_read(&user->seq), r)) { >> + while (!printk_get_next_message(&pmsg, atomic64_read(&user->seq), true)) { > > A problem is that printk_get_next_message() does not format the > message when it shoud get supressed on the console. Nice catch. I missed that. > I would solve it be adding a parameter to printk_get_next_message() > that will tell whether to suppress or not, e.g. @can_suppress. OK. >> if (file->f_flags & O_NONBLOCK) { >> ret = -EAGAIN; >> goto out; >> @@ -814,36 +814,31 @@ static ssize_t devkmsg_read(struct file *file, char __user *buf, >> * This pairs with __wake_up_klogd:A. >> */ >> ret = wait_event_interruptible(log_wait, >> - prb_read_valid(prb, >> - atomic64_read(&user->seq), r)); /* LMM(devkmsg_read:A) */ >> + prb_read_valid(prb, atomic64_read(&user->seq), >> + NULL)); /* LMM(devkmsg_read:A) */ > > The above change from "if" to "while" could be avoided if we use > printk_get_next_message() here as well. It looks slightly more > strightfoward to me. Yes, that is better. A loop is overkill here. John