[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZPiFW6H-umxxB4CE@alley>
Date: Wed, 6 Sep 2023 15:57:47 +0200
From: Petr Mladek <pmladek@...e.com>
To: John Ogness <john.ogness@...utronix.de>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk v3 4/7] printk: nbcon: Add ownership state
functions
On Sun 2023-09-03 17:11:36, John Ogness wrote:
> From: Thomas Gleixner <tglx@...utronix.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@...utronix.de>
> Signed-off-by: John Ogness <john.ogness@...utronix.de>
> Signed-off-by: Thomas Gleixner (Intel) <tglx@...utronix.de>
Reviewed-by: Petr Mladek <pmladek@...e.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
Powered by blists - more mailing lists