Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4101541pxb; Mon, 1 Feb 2021 12:28:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJwN1n32djAW3Bv+ROkDcBBI2VQ5FoGh9f5xCCtdaND3yXVZUBydJwOzJoKxGyuzr4Yx8zOJ X-Received: by 2002:a05:6402:c91:: with SMTP id cm17mr11510461edb.219.1612211288884; Mon, 01 Feb 2021 12:28:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612211288; cv=none; d=google.com; s=arc-20160816; b=SOdEntJ5cPXfGwfIpzGwTxYcrSXnV+F7tYvVXzvwdoOiZnetVfBbGo3R5/c4CBf20N wfW5txSuTZ19MhVLgJY6peLg5f7DiLa8DJ2PmL2ElGjubVu92YpDEI02cv3Ie9cx/Cbq L4F7Bj5cWslMI8EftPAvO6XF4kf5NB6S48oSVd0W1jKQkQLqjwtP4VfBoojD4GuqTPab cx4MMmf3U8GyogjZeVhWQVX/PzQMivQcz0DjxCahJl9+5jBiskfq8miB/AKhajMJ39Zh XJZoj9wQ4/n+nXjAUqW8mYiIFBSdbRqW2jbDug4julJt8FSIMoF41zg64WPFBADCRqXx kM1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=5OCK7idbG8XOABo1sGDGqpQvwitqz1CHdDHNPEdV+84=; b=kgLhCI1uEBuZuY4gwWQXbSbhzOM42NZItvxWVdjGDwCbCFkeVD1ERMee0NIWvIxyVW tLzZfS3wdDQM88FTIVEMAM93I/zNKEHzeLGUABrkiWpfRJwSOFyWMSU4Hzqs71HGKzTA 1YsfL6ZxuX7ys47Zmbvb6WZyrvUOjKASXaBDzPva3oEAWYedoTLBZGOCeSVxL3aRPegk +YNIMcWKoAsRGbDnRsx6/aJdnxWpM4ux3/UnH7fsTgR7Jy1l1daKzCHmV2uVb/m1CKHQ KjX7d9XPDunvzPClK3fYAcPMUXR6hm3n6cUkCB+sh9+1KguwDlLVKAe31j4W90BQOsfb eIgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=sRO98TWS; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=9FqUDXXl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a8si10595898ejk.646.2021.02.01.12.27.42; Mon, 01 Feb 2021 12:28:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=sRO98TWS; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=9FqUDXXl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229849AbhBAU0o (ORCPT + 99 others); Mon, 1 Feb 2021 15:26:44 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:59912 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231219AbhBAU0l (ORCPT ); Mon, 1 Feb 2021 15:26:41 -0500 From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1612211159; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5OCK7idbG8XOABo1sGDGqpQvwitqz1CHdDHNPEdV+84=; b=sRO98TWSBKbaVUEmX0yEqzNfSGhD+FZxBIAZyglkkrRje9+jsLRVZ0nPg/9x88j+bXnfQX XvklY1SCvnS5I2NG4O82pwquPp4OvTgs2cjGm776JhEYoamcrHQ6aTrxerMZMs6/Jx1EDa 8cDDHbsDsqihlrsu7X/Z52QXCebADKUJkFDgemMcog7SEdOAUsMoroLu5AWvgzsA3ZDu9b r6KMWOTlBabPhDy7xAES3AJR6PaXKxTlHEZIxwCdKHli4X4uMFaZvHs14GXazeuyfgFses dkL/gGilgKjHMHBu1480T/DcRrvAfEjobdtg+fYgXAlwg/ZszrF6SK3uIwO0Hw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1612211159; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5OCK7idbG8XOABo1sGDGqpQvwitqz1CHdDHNPEdV+84=; b=9FqUDXXl8e2PryHBggLgWqyCEMIZa0DYWUo9gC74ireBoOhJ1RJHXUsGgpYt/bAclYbJ/S trnIE39l4vj+KyDA== To: Richard Weinberger Cc: Petr Mladek , Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , tglx , linux-kernel , Thomas Meyer Subject: Re: [PATCH printk-rework 09/12] um: synchronize kmsg_dumper In-Reply-To: <1829482025.350347.1612198481059.JavaMail.zimbra@nod.at> References: <20210126211551.26536-1-john.ogness@linutronix.de> <20210126211551.26536-10-john.ogness@linutronix.de> <875z3bk9z1.fsf@jogness.linutronix.de> <1829482025.350347.1612198481059.JavaMail.zimbra@nod.at> Date: Mon, 01 Feb 2021 21:31:57 +0106 Message-ID: <87v9bbzga2.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Richard, On 2021-02-01, Richard Weinberger wrote: >>>> 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 and temporary buffer usage. >>>> >>>> Signed-off-by: John Ogness >>>> --- >>>> arch/um/kernel/kmsg_dump.c | 8 ++++++++ >>>> 1 file changed, 8 insertions(+) >>>> >>>> diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/kmsg_dump.c >>>> index f38349ad00ea..173999422ed8 100644 >>>> --- a/arch/um/kernel/kmsg_dump.c >>>> +++ b/arch/um/kernel/kmsg_dump.c >>>> @@ -1,5 +1,6 @@ >>>> // SPDX-License-Identifier: GPL-2.0 >>>> #include >>>> +#include >>>> #include >>>> #include >>>> #include >>>> @@ -9,8 +10,10 @@ static void kmsg_dumper_stdout(struct kmsg_dumper *dumper, >>>> enum kmsg_dump_reason reason, >>>> struct kmsg_dumper_iter *iter) >>>> { >>>> + static DEFINE_SPINLOCK(lock); >>>> static char line[1024]; >>>> struct console *con; >>>> + unsigned long flags; >>>> size_t len = 0; >>>> >>>> /* only dump kmsg when no console is available */ >>>> @@ -25,11 +28,16 @@ static void kmsg_dumper_stdout(struct kmsg_dumper *dumper, >>>> if (con) >>>> return; >>>> >>>> + if (!spin_trylock_irqsave(&lock, flags)) >>>> + return; >>>> + >>>> printf("kmsg_dump:\n"); >>>> while (kmsg_dump_get_line(iter, true, line, sizeof(line), &len)) { >>>> line[len] = '\0'; >>>> printf("%s", line); >>>> } >>>> + >>>> + spin_unlock_irqrestore(&lock, flags); >>> >>> What exactly is synchronized here, please? >>> Access to @line buffer or @iter or both? >> >> @line is being synchronized. @iter does not require synchronization. >> >>> It looks to me that the access to @line buffer was not synchronized >>> before. kmsg_dump_get_line() used a lock internally but >>> it was not synchronized with the later printf("%s", line); >> >> The line was previously synchronized for the kmsg_dump_get_line() >> call. But yes, it was not synchronized after the call, which is a bug if >> the dump is triggered on multiple CPUs simultaneously. The commit >> message should also mention that it is handling that bug. >> >>> IMHO, this patch is not needed. >> >> I am not familiar enough with ARCH=um to know if dumps can be triggered >> on multiple CPUs simultaneously. Perhaps ThomasM or Richard can chime in >> here. > > Well, uml has no SMP support, so no parallel dumps. :-) When I grep through arch/um, I see many uses of spinlocks. This would imply that uml at least has some sort of preemption model where they are needed. Dumps can trigger from any context and from multiple paths. If you are sure that this is no concern, then I will drop this patch from my series. John Ogness