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 4ABA5C0015E for ; Thu, 27 Jul 2023 15:11:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6AC1F6B0075; Thu, 27 Jul 2023 11:11:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 65C866B0078; Thu, 27 Jul 2023 11:11:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54C3A6B007B; Thu, 27 Jul 2023 11:11:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 472E76B0075 for ; Thu, 27 Jul 2023 11:11:36 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E1388810CC for ; Thu, 27 Jul 2023 15:11:35 +0000 (UTC) X-FDA: 81057730950.16.249C4C1 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf20.hostedemail.com (Postfix) with ESMTP id BDF4C1C029C for ; Thu, 27 Jul 2023 15:10:38 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=pE+oxar1; dkim=pass header.d=linutronix.de header.s=2020e header.b=4fLVNyMm; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf20.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690470639; 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=JmZUY5HL7mxzNObUMoolfY4LWdTMi99W9UaFt95hWy0=; b=4GlB6Cl8rDj9Zexwo6MqqAHl0opBEVNGuMXaHtw5uMS5fKRhYVlZpDUaVK6pa9SrUOvc2U g12vGIm8RhsR2otwEDz29mXXc1GM0V/6ViKR0v5DATtPwcknnzB1BiR2PogLR8UsDRFTYR F9jsRxQ97tm8edXtPLmFApKQBVVA05I= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=pE+oxar1; dkim=pass header.d=linutronix.de header.s=2020e header.b=4fLVNyMm; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf20.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690470639; a=rsa-sha256; cv=none; b=c+6NcMjsJzV0SrTMAxxFWLAlXMsE46cSfS6+WwQAZwnStwgB3rbt760pXER8mMOt/l1VjB FxCcFUj0gbkyoHt2B6mZHluiIZKliQjohd5yAqMOrz/rAVv5YyWaiGBcTBmNIXzZENWDs6 UlvQ0TuIxumuMBvZD9rhvFG+35IU+7A= Date: Thu, 27 Jul 2023 17:10:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1690470636; 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=JmZUY5HL7mxzNObUMoolfY4LWdTMi99W9UaFt95hWy0=; b=pE+oxar15oNKB0QzXGcEcfcCK04CDhxmdAeQyEJP1CewY5ty+ViRtoMT6xbK7rmp1IoVvg RRSPLn/CXhWJb+kNiCQWV944mTvO7c5H28A/AJRUeB+Z4C/0yQ6dQd8MqdpDOIp09btLhc Ou6NF4uVBI6a+XiI8mGlAfN3hgAthyzETbHU79ZLWOgwRxJX+YTS3/YEfQjUTy4eRjWboq uqq1FDWTK2DMp8WXq1ploJbvv43mQFWiqdSVmwQZVr6Z8uQ96qvKfTR28tU6h7RVV/muPv 8hg34Ojr2Rt+3/SfrQCgmR5MNUCtXTX3d8BjYG0hqnnS1LW+zM0bnfPnHlNfYw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1690470636; 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=JmZUY5HL7mxzNObUMoolfY4LWdTMi99W9UaFt95hWy0=; b=4fLVNyMmc+WQaVm3LN6OQZfOh2EoLerlauWoEk9JsijohOijLEVpDQ/IXFTXihIZ/gyk5I Pii9C6TPD1GRZdDA== From: Sebastian Andrzej Siewior To: Tetsuo Handa Cc: Petr Mladek , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Luis Claudio R. Goncalves" , Andrew Morton , Boqun Feng , Ingo Molnar , John Ogness , Mel Gorman , Michal Hocko , Peter Zijlstra , Thomas Gleixner , Waiman Long , Will Deacon Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() Message-ID: <20230727151029.e_M9bi8N@linutronix.de> References: <20230623171232.892937-1-bigeasy@linutronix.de> <20230623171232.892937-2-bigeasy@linutronix.de> <20230626081254.XmorFrhs@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: a9mun87pw3zxeu43uunihd78x8kbibjk X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BDF4C1C029C X-HE-Tag: 1690470638-675099 X-HE-Meta: U2FsdGVkX1848ixXjKjqwCXLK4dEFRyyzVMr/u3bYGiSzbjOw/Nd4pphHWW4CO8t1deJBbU6Tlxylh8May0hoQBmjPZpNiEwJIqGfaUI10WsSrtk4sEA+L5s8enPdg8hfINlbK7PyCm/nPLJMqy5AzVQRdhFhX5iN8CJIfan3H8GNIBGLpRC1pRKDmlrsBmqQRIPwXxrAaA+4m9Oz62NUMrDHxUdEK+6x5tfCisAKZoz2Z7K2rthnSm3aERxgggQGu9wFzmqyK0xnvPObHLneTqqghsYUlpvilUQhYemaRrX5xbWpY6HhW3JgSrDFnyCMbiIqrdx4Y6vjTc8G2GjnSOg5ltMZaNrlSNiDXJotAhH4TNWMEhM/kz0lPGPFX7SwTJEyT3pSjqzrSoJIilUHHsPGSNcDr7WXz3VGflFgU/UxNTz2cnQAcmXITFhcsYoU/SFSTwWoz2d0jYYp20kEPsqJCdcDrVNDHKRN5mObzszI1SvQJXP6TdPK1qAkZe2yskrdD2E7DkSclXCkWDpFzMhgHOfUDAfQuUoQbQg3gGG9S+dkFLGzlnIuxHtTRjzRswORoMYRYObu1KTZ4etVbvtOTbIT28FDrlOgPL5QVxVk3CxG0ZX5ysw3JQ6WIB9S3bBigVoxIgoufnpPyXsNuDiuiaoGHKXOWBPQgl+ZCTOeTr/kNvKNgzSf04mou+mexdNAlPlmVO2HTf4Qxuqm4AWuUpBRcBa31fnCM9+Hd/SA92K8J+le7D/Mavnil4d9mIRFDn1iQaizRZ9KZBQdtCLiJ6uAxSESBWa/6VeXmlXwr50OVY1jYXJhT1+ztSQOSm2dqgvBjqYaCVf5oxMFVhJ2aJbA9FTBBf7NQmWo5pky+BySnb4Lw54orgRBjSBjKoMAFcVurlukjR4lKWlbAI8cRwZzpy3TEL8EsWzpqQW6bXXFE9Yf4sR7ZDd9MzVkmfF79vwos7j+LiVYw+ kE6w2ILE NtFCLaIw2jWv6iR+TlUTwPiwGLpLkptzuDEPxEJpe9kzqSvlaGQ0nceGqwqNJanBXbqKcz75q+SU75NdpoWxiyy/0UYWTPGRsJVvzLUtcFEmGFP3kmNi/e89poT5rJjBxkGYVLSDYW6wg7WGaa0WjTBx/mlJ3VPBrvUiNFNlM4fMX1uIlIiyAQl9woSwe+t59ABrzOczSiUliE96+umrJrgsxTw== 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 2023-06-28 21:14:16 [+0900], Tetsuo Handa wrote: > > Anyway, please do not do this change only because of printk(). > > IMHO, the current ordering is more logical and the printk() problem > > should be solved another way. > > Then, since [PATCH 1/2] cannot be applied, [PATCH 2/2] is automatically > rejected. My understanding is that this patch gets applied and your objection will be noted. > I found > > /* > * Locking a pcp requires a PCP lookup followed by a spinlock. To avoid > * a migration causing the wrong PCP to be locked and remote memory being > * potentially allocated, pin the task to the CPU for the lookup+lock. > * preempt_disable is used on !RT because it is faster than migrate_disable. > * migrate_disable is used on RT because otherwise RT spinlock usage is > * interfered with and a high priority task cannot preempt the allocator. > */ > #ifndef CONFIG_PREEMPT_RT > #define pcpu_task_pin() preempt_disable() > #define pcpu_task_unpin() preempt_enable() > #else > #define pcpu_task_pin() migrate_disable() > #define pcpu_task_unpin() migrate_enable() > #endif > > in mm/page_alloc.c . Thus, I think that calling migrate_disable() if CONFIG_PREEMPT_RT=y > and calling local_irq_save() if CONFIG_PREEMPT_RT=n (i.e. Alternative 3) will work. > > But thinking again, since CONFIG_PREEMPT_RT=y uses special printk() approach where messages > are printed from a dedicated kernel thread, do we need to call printk_deferred_enter() if > CONFIG_PREEMPT_RT=y ? That is, isn't the fix as straightforward as below? That below will cause a splat with CONFIG_PROVE_RAW_LOCK_NESTING. That is because seqlock_t::lock is acquired without disabling interrupts. Additionally it is a bad example because the seqcount API is bypassed due to printk's limitations and the problems, that are caused on PREEMPT_RT, are "ifdefed away". None of this is documented/ explained. Let me summarize your remaining problem: - With (and only with) CONFIG_PROVE_LOCKING there can be a printk splat caused by a lock validation error noticed by lockdep during write_sequnlock_irqrestore(). - This can deadlock if there is a printing output on the tty which is using the same console as printk and memory hotplug is active at the same time. That is because the tty layer acquires the same lock as printk's console during memory allocation (of the tty layer). Now: - before this deadlocks (with CONFIG_PROVE_LOCKING) chances are high that a splat is seen first. - printk is reworked and the printk output should either happen from a dedicated thread or directly via a different console driver which is not using uart_port::lock. Thus avoiding the deadlock. Sebastian