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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 085AFC77B73 for ; Wed, 19 Apr 2023 12:03:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 743938E0003; Wed, 19 Apr 2023 08:03:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F3588E0001; Wed, 19 Apr 2023 08:03:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E3628E0003; Wed, 19 Apr 2023 08:03:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4FF5F8E0001 for ; Wed, 19 Apr 2023 08:03:35 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2CD48802AD for ; Wed, 19 Apr 2023 12:03:35 +0000 (UTC) X-FDA: 80698005990.09.576781C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf25.hostedemail.com (Postfix) with ESMTP id CB5CBA0017 for ; Wed, 19 Apr 2023 12:03:31 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=MOWHkpdE; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=pmladek@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681905812; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zcbbH9f/2oMNPoZxU2kXYRve4Q/BaeK2CpvhClmUfIQ=; b=vPZ4YarSccTe9yCQpF1AQu3ZUPfCS46SYtKr5odTAgKTQFsOkxL072MPxEFuPldtFpR/d9 L49s0iYmgv2zFH3iTfWwnSVJ+2QM9KWC+Xu0Vdpr4jtT7Nna5e75ORGQrLCyNUFcaCmexQ GoQAlgdu8LDOrWybvM6E6QYx6ZCn3Wg= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=MOWHkpdE; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=pmladek@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681905812; a=rsa-sha256; cv=none; b=iD/DjWQjl0vn875Sh7XdoGIg4E3EWdXOBdyTqH6DDR9742VFyn6VC8+EwMaTXZvaIhn0vo Bn0C9NlfjtBW5cPScnMtVL9S5TCHTTH0WSjT79YMcJuzY//MpWwYAN25aqelIB0DlAAVQD lrI5m/0DLs3mZU7scHGzP0/Q2ap4SL0= Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 46A18219A0; Wed, 19 Apr 2023 12:03:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1681905810; h=from:from:reply-to: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=zcbbH9f/2oMNPoZxU2kXYRve4Q/BaeK2CpvhClmUfIQ=; b=MOWHkpdEXMRZsgsLOlmkzSybu7a621wg5cincJDavuBB/6fqT3E8XJxmn9TfXn6oRlloCq rJ5bKBB2YltirfBEr1m4f11CTS89Caf1Z6S4m1nDmWf0AbNfbeXwX8XdCFiJA+cnulN+1N MWcjHbLRAq9QISsp1BgsYaEAVNZTO0I= Received: from suse.cz (unknown [10.100.208.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id BC7C32C141; Wed, 19 Apr 2023 12:03:29 +0000 (UTC) Date: Wed, 19 Apr 2023 14:03:29 +0200 From: Petr Mladek To: John Ogness Cc: Sergey Senozhatsky , Steven Rostedt , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] printk: Enough to disable preemption in printk deferred context Message-ID: References: <20230419074210.17646-1-pmladek@suse.com> <87r0sg5jin.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r0sg5jin.fsf@jogness.linutronix.de> X-Rspamd-Queue-Id: CB5CBA0017 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: ckrj94c7xxi5yn6hrfz7e5cibiaremke X-HE-Tag: 1681905811-412863 X-HE-Meta: U2FsdGVkX1/pIIy1/lZXd9dPR1xgZ/LkgAJr1AYxRxB8DtFAPNBBcWSctgWTpRGSj10QJUsuRq/khJg6tzXMTq2IzuNeZYmZ8ADJDQNsG8iMHxWiSIbe7SNYrd7GDnPuo8pm6Sy+KKNCu9PIsvgJankLIH3NFpWK2dlhs8+5JKIbd/0vDB83soj2panhVIDSyrxoNJBWva1/b39mR/3u9z/VWmj6cykFcBTIEGF8iW6m6b+hqzuCkAEMIKqNOinjQQ9fs1ONSnhPXrWrSQ+5zepXq+A3qBL73zkMmAlqn0fT54cTYj158y9zus78dOqn2xT14Mlnq2UN130dxNldSX0DmmrU+H9tZ8a3orQDbAYOgNUX0SslUhTF93Es5+dYrz5kD97gROjSo0HiDkIdv9NlGbCDbI7soJxpVA43Rh8HDLbRJi82WCvxciSx2gtniWn84R3KhCHPeHQw/vP6KNBYQrP/0MsKD9df0IZb+2373ynq+RVcGf9KmpbZp5qcJk1qRmbuP2WQ9tLJcd3yTxWFV26Bn4AFFhGkHmYk3GQ54V9lPC+P9bn/ARDQRIAXCzlGxKvVMcp+evHADo1VUnRA7d8lLlVSC0vNfqv94QHOFOhgmafucz2ThpuzBdP3r0uFMTOqRbSEiFEA1vLWmhsQWCWtq5B44K7Dac39Q3q+7/H+BdBUXOaz/bE4elRX1GdFFl3tajRus7e7FexIf9DT4i2/Kj0Se0d/kwJ1HfSjJTkaEZu1hMC6GnMP6SbtA64zxLndY0o/EA1qJwRSCaCF9VwQHQcLPuFAeLIdpXukrtHtGD6SkaRt3r2wZWm5TvLCQ1vczLthPp1XX7hKFgUASKLoEWh5+tdP87XpPqnDpLMYFI39MuhpboZLaqMUl/26EuiqGhr2tOdPcfEiQTwzEBewmnkhvpGCDl2p795AGwWvaMvuseS1v+2xDBea1dPFUKi/pOdFd8K5J3c zT6tFi3j +9T3K4nmXXPbe2Kl5wEknGoqrolKRd+z0YtWegsouztTVjrFApdHLk1Mp2LUC7s0K92WlhwpvTwuoEjqgglDGsSLg/J9GXflkGPZ3GqQTav0jRXadaUq8K11cZjrQ99xp9cwZvcQ7LlU+CYxx2egN+Cbshg+XLxzFPR4Nd6qdRidHwN5u+imPKH/RFw1EEnNbwfZmxjjn4SbyJ19yeY/u243slA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 2023-04-19 11:11:52, John Ogness wrote: > On 2023-04-19, Petr Mladek wrote: > > it is safe to interrupt one writer now. The preemption still > > has to be disabled because the deferred context is CPU specific. > > Really it is enough to disable migration. True. But it gets too far to my taste. As you describe below. It affects all printk's on the CPU. Sigh, even the enabled intrrupts might be questionable. For example, when the iterrupt is from a watchdog and want's to report a stall. > We need to keep an eye on the usage of this function. By allowing > interrupts and preemption, it means that other printk's on that CPU will > also be deferred if the context interrupted within the deferred block. A solution would be to make this more clear in the comment. Something like: /* * The printk_deferred_enter/exit macros are available only as a hack. * They define a per-CPU context where all printk console printing is * deferred because it might cause a deadlock otherwise. * * The API user is responsible for calling the corresponding enter/exit * pair on the same CPU. It is highly recommended to use them only in * a context with interrupts disabled. Otherwise, other unrelated * printk() calls might be deferred when they interrupt/preempt * the deferred code section. */ Another solution would be to stay on the "safe" side and keep the comment as is or even enforce disabling interrupts by the API. I would personally just improve the comment. It is good to describe the situation correctly. We could always add restrictions when there are problems in practice. Best Regards, Petr