public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH printk v3 4/7] printk: nbcon: Add ownership state functions
Date: Wed, 6 Sep 2023 15:57:47 +0200	[thread overview]
Message-ID: <ZPiFW6H-umxxB4CE@alley> (raw)
In-Reply-To: <20230903150539.245076-5-john.ogness@linutronix.de>

On Sun 2023-09-03 17:11:36, John Ogness wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Provide functions that are related to the safe handover mechanism
> and allow console drivers to dynamically specify unsafe regions:
> 
>  - nbcon_context_can_proceed()
> 
>    Invoked by a console owner to check whether a handover request
>    is pending or whether the console has been taken over by another
>    context. If a handover request is pending, this function will
>    also perform the handover, thus cancelling its own ownership.
> 
>  - nbcon_context_update_unsafe()
> 
>    Invoked by a console owner to denote that the driver is about
>    to enter or leave a critical region where a take over is unsafe.
>    This function is also a cancellation point where loss of
>    ownership can occur.
> 
>    The unsafe state is stored in the console state and allows a
>    new context to make informed decisions whether to attempt a
>    takeover of such a console. The unsafe state is also available
>    to the driver so that it can make informed decisions about the
>    required actions and possibly take a special emergency path.
> 
> Co-developed-by: John Ogness <john.ogness@linutronix.de>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>

Reviewed-by: Petr Mladek <pmladek@suse.com>

See one comment below.

> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -518,6 +517,112 @@ static void nbcon_context_release(struct nbcon_context *ctxt)
>  	ctxt->pbufs = NULL;
>  }
>  
> +/**
> + * nbcon_context_can_proceed - Check whether ownership can proceed
> + * @ctxt:	The nbcon context from nbcon_context_try_acquire()
> + * @cur:	The current console state
> + *
> + * Return:	True if this context still owns the console. False if
> + *		ownership was handed over or taken.
> + *
> + * Must be invoked after the record was dumped into the assigned buffer
> + * and at appropriate safe places in the driver.
> + *
> + * When this function returns false then the calling context no longer owns
> + * the console and is no longer allowed to go forward. In this case it must
> + * back out immediately and carefully. The buffer content is also no longer
> + * trusted since it no longer belongs to the calling context.
> + */
> +static bool nbcon_context_can_proceed(struct nbcon_context *ctxt, struct nbcon_state *cur)
> +{
> +	unsigned int cpu = smp_processor_id();
> +
> +	/* Make sure this context still owns the console. */
> +	if (!nbcon_owner_matches(cur, cpu, ctxt->prio))
> +		return false;
> +
> +	/* The console owner can proceed if there is no waiter. */
> +	if (cur->req_prio == NBCON_PRIO_NONE)
> +		return true;
> +
> +	/*
> +	 * A console owner within an unsafe region is always allowed to
> +	 * proceed, even if there are waiters. It can perform a handover
> +	 * when exiting the unsafe region. Otherwise the waiter will
> +	 * need to perform an unsafe hostile takeover.
> +	 */
> +	if (cur->unsafe)
> +		return true;
> +
> +	/* Waiters always have higher priorities than owners. */
> +	WARN_ON_ONCE(cur->req_prio <= cur->prio);
> +
> +	/*
> +	 * Having a safe point for take over and eventually a few
> +	 * duplicated characters or a full line is way better than a
> +	 * hostile takeover. Post processing can take care of the garbage.
> +	 * Release and hand over.
> +	 */
> +	nbcon_context_release(ctxt);
> +
> +	/*
> +	 * It is not known whether the handover succeeded. The outermost

It was not immediately clear to me what exactly "handover succeeded" did mean.
I would write:

	* It is not clear whether the waiter really took the lock
	* and re-printed the record. The outermost calsite...

> +	 * callsite has to make the final decision whether printing
> +	 * should proceed or not (via reacquire, possibly hostile). The
> +	 * console is now unlocked so go back all the way instead of
> +	 * trying to implement heuristics in tons of places.
> +	 */
> +	return false;
> +}

Best Regards,
Petr

  reply	other threads:[~2023-09-06 13:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-03 15:05 [PATCH printk v3 0/7] provide nbcon base John Ogness
2023-09-03 15:05 ` [PATCH printk v3 1/7] printk: Add non-BKL (nbcon) console basic infrastructure John Ogness
2023-09-05 11:45   ` Petr Mladek
2023-09-03 15:05 ` [PATCH printk v3 2/7] printk: nbcon: Add acquire/release logic John Ogness
2023-09-03 16:32   ` kernel test robot
2023-09-05  9:07     ` John Ogness
2023-09-03 16:43   ` kernel test robot
2023-09-06 13:01   ` Petr Mladek
2023-09-03 15:05 ` [PATCH printk v3 3/7] printk: nbcon: Add buffer management John Ogness
2023-09-06 13:26   ` Petr Mladek
2023-09-08 13:03     ` John Ogness
2023-09-03 15:05 ` [PATCH printk v3 4/7] printk: nbcon: Add ownership state functions John Ogness
2023-09-06 13:57   ` Petr Mladek [this message]
2023-09-08 13:20     ` John Ogness
2023-09-03 15:05 ` [PATCH printk v3 5/7] printk: nbcon: Add sequence handling John Ogness
2023-09-07  7:45   ` Petr Mladek
2023-09-03 15:05 ` [PATCH printk v3 6/7] printk: nbcon: Add emit function and callback function for atomic printing John Ogness
2023-09-07  8:22   ` Petr Mladek
2023-09-03 15:05 ` [PATCH printk v3 7/7] printk: nbcon: Add functions for drivers to mark unsafe regions John Ogness
2023-09-07  8:24   ` Petr Mladek

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=ZPiFW6H-umxxB4CE@alley \
    --to=pmladek@suse.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tglx@linutronix.de \
    /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