linux-kernel - RE: [PATCH printk-rework 10/12] hv: synchronize kmsg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MWHPR21MB1593C37614E7F1334EB0AA7FD7BB9@MWHPR21MB1593.namprd21.prod.outlook.com>
Date:   Wed, 27 Jan 2021 21:32:52 +0000
From:   Michael Kelley <mikelley@...rosoft.com>
To:     John Ogness <john.ogness@...utronix.de>,
        Petr Mladek <pmladek@...e.com>
CC:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH printk-rework 10/12] hv: synchronize kmsg_dumper

From: John Ogness <john.ogness@...utronix.de> Sent: Tuesday, January 26, 2021 1:16 PM
> 
> In preparation for removing printk's @logbuf_lock, dumpers that have
> assumed to be protected against parallel calls must provide their own
> synchronization. Add a locally static spinlock to synchronize the
> kmsg_dump call.
> 
> Signed-off-by: John Ogness <john.ogness@...utronix.de>
> ---
>  drivers/hv/vmbus_drv.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index fbeddef90941..08db95e1a139 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1362,23 +1362,27 @@ static void hv_kmsg_dump(struct kmsg_dumper *dumper,
>  			 enum kmsg_dump_reason reason,
>  			 struct kmsg_dumper_iter *iter)
>  {
> +	static DEFINE_SPINLOCK(lock);
>  	size_t bytes_written;
>  	phys_addr_t panic_pa;
> +	unsigned long flags;
> 
>  	/* We are only interested in panics. */
>  	if ((reason != KMSG_DUMP_PANIC) || (!sysctl_record_panic_msg))
>  		return;
> 
> +	if (!spin_trylock_irqsave(&lock, flags))
> +		return;
> +
>  	panic_pa = virt_to_phys(hv_panic_page);
> 
> -	/*
> -	 * Write dump contents to the page. No need to synchronize; panic should
> -	 * be single-threaded.
> -	 */
> +	/* Write dump contents to the page. */
>  	kmsg_dump_get_buffer(iter, false, hv_panic_page, HV_HYP_PAGE_SIZE,
>  			     &bytes_written);
>  	if (bytes_written)
>  		hyperv_report_panic_msg(panic_pa, bytes_written);
> +
> +	spin_unlock_irqrestore(&lock, flags);
>  }
> 
>  static struct kmsg_dumper hv_kmsg_dumper = {
> --
> 2.20.1

I don't think this patch is needed.   Per some of the unmodified code
above, and the comment, we proceed to the call to kmsg_dump_get_buffer()
only in the panic path.  Code in the panic path prior to invoking kmsg_dump()
ensures that we are single-threaded on a single CPU.   So I think everything
is good here without the new spin lock.  The subsequent call to
hyperv_report_panic_msg() also assumes that we are single-threaded.

Michael