Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1374333ybl; Tue, 3 Dec 2019 06:16:38 -0800 (PST) X-Google-Smtp-Source: APXvYqyB5caFS01BrQ57/B9V5BrsQBC71SU3GqafsSdWkHyB9R74p1c8RthvevG8x5B7GI7FkS7o X-Received: by 2002:a05:6830:11d3:: with SMTP id v19mr3309347otq.322.1575382598690; Tue, 03 Dec 2019 06:16:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575382598; cv=none; d=google.com; s=arc-20160816; b=OVK/p0HlvpKY54ehydfe8aJyu2AW5r0qsnhXZFfdXb9Ycft+0ls8775U67zx2Tsjji gKs5TYcRbZcD2nYwDj9eib2q9FIBfmjnfzdI16zoap5PX8mUFigjVsyqjiUXDT4s0v7P X07uutGdmG0TcHRSqNOOBWh5DHHuGAjxKPMd5k/VG/bN9rR/lu68jaFpLwJIebZtAhZ8 1yIfnz4+9714kEp0rPaZn5ECGpA9OcdO5+OJyRam+UTiPsKm+gN6o5DJK+khCOErSdHF EJxBHSBcPMQ4ocbKpJJQGwU7xUf7k10Wp8jhDG/vR9EYOSeG3XGlnHr/umgRMeJaaf2A vxzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=f32HpBLjleWrJmAtaLLeY5NZSLFgmohvbIdtn7DxpFg=; b=RfBzt8nWDuGqvlYKrKZa6cCFEUGm18Cyvz1AAI+CXXPt/jloG2/xm4eczpXg5CCmNZ AYemcuigppsPO5iYQi3A7mK5CDVoXx+YiK8GhrLv3q62cmO+OmuhHt4jkKY5yeKvhRGf nolUyrZb7zddwCpRO1YQ6qvKAz72+9i4K3+e6Pj0k0I0quFayRw1ALE1lwhmNTPIEguI fncHcslxrI7QMu319plnhbl6E+c25jsHsxFVDyY7tJKuYfj0Ebtpyn/tHdmjsfxyLzQ5 e0qJ9GtApUEsCIqpXU2p2sNGAZ6RQi6Ick7KA6YvnaOShfeFUrpsxxHOrNfFExYRb4Va 0jvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t18si1347970oij.133.2019.12.03.06.16.15; Tue, 03 Dec 2019 06:16:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726079AbfLCOOP (ORCPT + 99 others); Tue, 3 Dec 2019 09:14:15 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:54788 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727069AbfLCONr (ORCPT ); Tue, 3 Dec 2019 09:13:47 -0500 Received: from localhost ([127.0.0.1] helo=vostro.local) by Galois.linutronix.de with esmtp (Exim 4.80) (envelope-from ) id 1ic8vq-0002i0-2z; Tue, 03 Dec 2019 15:13:38 +0100 From: John Ogness To: Petr Mladek Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Sergey Senozhatsky , Steven Rostedt , Linus Torvalds , Greg Kroah-Hartman , Andrea Parri , Thomas Gleixner , Sergey Senozhatsky , Brendan Higgins , kexec@lists.infradead.org Subject: Re: [RFC PATCH v5 1/3] printk-rb: new printk ringbuffer implementation (writer) References: <20191128015235.12940-1-john.ogness@linutronix.de> <20191128015235.12940-2-john.ogness@linutronix.de> <20191202154841.qikvuvqt4btudxzg@pathway.suse.cz> Date: Tue, 03 Dec 2019 15:13:36 +0100 In-Reply-To: <20191202154841.qikvuvqt4btudxzg@pathway.suse.cz> (Petr Mladek's message of "Mon, 2 Dec 2019 16:48:41 +0100") Message-ID: <87fti1bipb.fsf@linutronix.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-12-02, Petr Mladek wrote: >> +/* >> + * Sanity checker for reserve size. The ringbuffer code assumes that a data >> + * block does not exceed the maximum possible size that could fit within the >> + * ringbuffer. This function provides that basic size check so that the >> + * assumption is safe. >> + */ >> +static bool data_check_size(struct prb_data_ring *data_ring, unsigned int size) >> +{ >> + struct prb_data_block *db = NULL; >> + >> + /* Writers are not allowed to write data-less records. */ >> + if (size == 0) >> + return false; > > I would personally let this decision to the API caller. > > The code actually have to support data-less records. They are used > when the descriptor is reserved but the data block can't get reserved. Exactly. Data-less records are how the ringbuffer identifies that data has been lost. If users were allowed to store data-less records, that destinction is no longer possible (unless I created some extra field in the descriptor). Does it even make sense for printk to store data-less records explicitly? The current printk implementation silently ignores empty messages. > The above statement might create false feeling that it could not > happen later in the code. It might lead to bugs in writer code. Then let me change the statement to describe that data-less records are used internally by the ringbuffer and cannot be explicitly created by writers. > Also reader API users might not expect to get a "valid" data-less > record. Readers will never see them. The reader API implementation skips over data-less records. John Ogness