From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C771C433E6 for ; Wed, 24 Feb 2021 15:50:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 28CF464EEC for ; Wed, 24 Feb 2021 15:50:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233529AbhBXPtw (ORCPT ); Wed, 24 Feb 2021 10:49:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235144AbhBXPlP (ORCPT ); Wed, 24 Feb 2021 10:41:15 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC305C061574 for ; Wed, 24 Feb 2021 07:40:32 -0800 (PST) From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1614181224; 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=KuEArnJDZcZaDgSDX5/Jl/hUB3QBLTeDqaL/WpUed8Q=; b=NxWBgzelLXW5lBZUKy34rybtn/aJGItegqH441WqEG2Bqu/A9o+ZydKjQmetkicjGxZVw6 yyvSEVhbAZZfW11KvkOKzLt8//ZCb9E/Cd7MPppKVHYY5x/j8rgMYoyLZTmwQtbv0+1SU4 1xOImHC1h3xFLm81XjYvrmGFVYN6Tcce6Bj3I3RAmYWAjCsCjcorNT/aqIt8YK9F+IwFBz k39SWwyUkuliwKnWYDGmHwmNi0xOxzf60fclpmfFMIMzLSEQDC1hwCKZovsdb1Z3ow+WUi JpR31ZZgshU4nznbpL/yZZI/QK5KQYSJrQc/7eAVpK0gd4cKbBknn2BqJ9Hj7w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1614181224; 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=KuEArnJDZcZaDgSDX5/Jl/hUB3QBLTeDqaL/WpUed8Q=; b=9fRQ8NbeXZc3jc2GRuKG/n2w8m1sYkW+ffBCX/qKNFn8W9xLloFDmsiDWVSdcSEE8mUTxR VZX+PQGPMRvqOwBg== To: Petr Mladek Cc: Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: synchronization model: was: Re: [PATCH printk-rework 09/14] printk: introduce a kmsg_dump iterator In-Reply-To: <87eeh51wht.fsf@jogness.linutronix.de> References: <20210218081817.28849-1-john.ogness@linutronix.de> <20210218081817.28849-10-john.ogness@linutronix.de> <87eeh51wht.fsf@jogness.linutronix.de> Date: Wed, 24 Feb 2021 16:40:24 +0100 Message-ID: <878s7d1nkn.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-02-24, John Ogness wrote: > The @active flag is useless. It should be removed. I would like to clarify my statement, because the @active flag _did_ protect the arch/um dumper until now. (Although it didn't actually matter because arch/um does not have SMP or preemption support.) In mainline we have 6 dumpers. They can be classified as follows: 1. Dumpers that provide their own synchronization to protect against parallel or nested dump() calls. - arch/powerpc/kernel/nvram_64.c - fs/pstore/platform.c - arch/um/kernel/kmsg_dump.c (after this series) 2. Dumpers that are safe because they only dump on KMSG_DUMP_PANIC, which (currently) can never happen in parallel or nested. - arch/powerpc/platforms/powernv/opal-kmsg.c - drivers/hv/vmbus_drv.c 3. Dumpers that are unsafe and even @active did not provide the needed synchronization. - drivers/mtd/mtdoops.c In all 6 dumpers, @action does not provide any help. That is why it can be removed. But I am concerned about drivers/mtd/mtdoops.c that does not have any synchronization. Since my series is adding sychronization to arch/um/kernel/kmsg_dump.c, I suppose it should also add it to drivers/mtd/mtdoops.c also. And rather than moving the useless @active from kmsg_dumper to kmsg_dump_iter, I should just drop it. Unless there are any objections, I will make these changes for my v3. John Ogness