linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marco Elver <elver@google.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2][next] printk: ringbuffer: support dataless records
Date: Tue, 4 Aug 2020 12:14:00 +0200	[thread overview]
Message-ID: <20200804101400.GB24529@alley> (raw)
In-Reply-To: <20200721132528.9661-1-john.ogness@linutronix.de>

On Tue 2020-07-21 15:31:28, John Ogness wrote:
> With commit ("printk: use the lockless ringbuffer"), printk()
> started silently dropping messages without text because such
> records are not supported by the new printk ringbuffer.
> 
> Add support for such records.
> 
> Currently dataless records are denoted by INVALID_LPOS in order
> to recognize failed prb_reserve() calls. Change the ringbuffer
> to instead use two different identifiers (FAILED_LPOS and
> NO_LPOS) to distinguish between failed prb_reserve() records and
> successful dataless records, respectively.
> 
> diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c
> index 7355ca99e852..0659b50872b5 100644
> --- a/kernel/printk/printk_ringbuffer.c
> +++ b/kernel/printk/printk_ringbuffer.c
>  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. Such records
> -	 * are used only internally by the ringbuffer to denote records where
> -	 * their data failed to allocate or have been lost.
> -	 */
>  	if (size == 0)
> -		return false;
> +		return true;

Nit: This might deserve a comment why size == 0 is handled
     a special way.specially. I think about something like:

	/*
	 * Empty data blocks are handled by special lpos values in
	 * the record descriptor. No space is needed in the data ring.
	 */

or simply

	/* Data-less records take no space in the data ring. */

>  	/*
>  	 * Ensure the alignment padded size could possibly fit in the data

> @@ -1025,6 +1020,10 @@ static char *data_alloc(struct printk_ringbuffer *rb,
>  static unsigned int space_used(struct prb_data_ring *data_ring,
>  			       struct prb_data_blk_lpos *blk_lpos)
>  {
> +	/* Data-less blocks take no space. */
> +	if (LPOS_DATALESS(blk_lpos->begin))
> +		return 0;

Nit: It seems that all the other locations check also blk_lpos->next,
     for example, get_data() does:

	if (LPOS_DATALESS(blk_lpos->begin) && LPOS_DATALESS(blk_lpos->next)) {


     Both approaches are error prone. I would either simplify the
     other locations and check only lpos->begin. But better might
     be to be on the safe side do a paranoid check, like:

bool is_dataless(struct prb_data_blk_lpos *blk_lpos)
{
	if (LPOS_DATALESS(blk_lpos->begin) || LPOS_DATALESS(blk_lpos->next)) {
		WARN_ON_ONCE(blk_lpos->begin != blk_lpos->next);
		return true;
	}

	return false;
}

> +
>  	if (DATA_WRAPS(data_ring, blk_lpos->begin) == DATA_WRAPS(data_ring, blk_lpos->next)) {
>  		/* Data block does not wrap. */
>  		return (DATA_INDEX(data_ring, blk_lpos->next) -

Anyway, the patch looks fine. It is already pushed in
printk/linux.git. So, if you agree with my nits, we should
solve them with separate patches on top of the existing ones.

Best Regards,
Petr

      parent reply	other threads:[~2020-08-04 10:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21 13:25 [PATCH v2][next] printk: ringbuffer: support dataless records John Ogness
2020-07-27  8:53 ` Sergey Senozhatsky
2020-08-04 10:14 ` Petr Mladek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200804101400.GB24529@alley \
    --to=pmladek@suse.com \
    --cc=elver@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).