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 F0833EB64D7 for ; Mon, 26 Jun 2023 11:35:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D38F8D0003; Mon, 26 Jun 2023 07:35:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 883668D0001; Mon, 26 Jun 2023 07:35:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74A608D0003; Mon, 26 Jun 2023 07:35:44 -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 632AC8D0001 for ; Mon, 26 Jun 2023 07:35:44 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3908B80684 for ; Mon, 26 Jun 2023 11:35:44 +0000 (UTC) X-FDA: 80944694208.10.3D2C9BF Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf08.hostedemail.com (Postfix) with ESMTP id 2EEC1160004 for ; Mon, 26 Jun 2023 11:35:41 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=cH4xcOtv; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687779342; 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=5yjlh7t2dHVVBraoSHmCUGOPQgG+BcdKVJI9xyylaX8=; b=c0RpIq8L7B2w2Nz6iU0AaAClR3pDnBy9gtGTCfjsqfBBqI3JBXjl3XVKYJhq/n5VQdoToc BfY9JoXCggKlKdlwVRpHTgM9KQrqE1eHL9RrK9HMnsPH1s+V580ELsCA2LQOKXy/KcbOdr E8NvQ/a9hC4OkNaRZpzvYGnSP5Tfg6g= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687779342; a=rsa-sha256; cv=none; b=hfmrlgsiRTkiDbRdcRuYNX60+OBt818tqSwTnXQKIrzNDAQMJRlrxwoQPdVD/VXDwNTw85 vPAoki3YpKf4SlNFSR7Y45at2+KufgQsPwHMr/57lxpe6HYsGUM8wHIGIUeL5cmTEHfxla e7yUaxiJy39YVpP4jKl4PJFCr9qX2oM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=cH4xcOtv; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 5D18A1F898; Mon, 26 Jun 2023 11:35:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1687779340; 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=5yjlh7t2dHVVBraoSHmCUGOPQgG+BcdKVJI9xyylaX8=; b=cH4xcOtv7Yr0d7bOW5jXEdf7ghUZJQse/1knIS9JBIDZBCaACgjvlI934NgpqNseQXZOd9 flSxVvGHZuMRupc5h7tF0be1GiQK47CDKm/rSyBabbguA139nyrfCjoMi90vemEfXbStez 7zB4MXym+7PjEpnmDyqwtFVep2NPbCw= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 3A25713483; Mon, 26 Jun 2023 11:35:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id x2IKDAx4mWTILwAAMHmgww (envelope-from ); Mon, 26 Jun 2023 11:35:40 +0000 Date: Mon, 26 Jun 2023 13:35:39 +0200 From: Michal Hocko To: Tetsuo Handa Cc: Peter Zijlstra , Sebastian Andrzej Siewior , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Luis Claudio R. Goncalves" , Andrew Morton , Boqun Feng , Ingo Molnar , John Ogness , Mel Gorman , Petr Mladek , 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: References: <20230623171232.892937-1-bigeasy@linutronix.de> <20230623171232.892937-2-bigeasy@linutronix.de> <20230626081254.XmorFrhs@linutronix.de> <0a0c768c-227d-c0cd-1b91-5a884d161c1b@I-love.SAKURA.ne.jp> <20230626104831.GT4253@hirez.programming.kicks-ass.net> <3a4ad958-a9a5-c367-a16d-bd89a173a628@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a4ad958-a9a5-c367-a16d-bd89a173a628@I-love.SAKURA.ne.jp> X-Rspamd-Queue-Id: 2EEC1160004 X-Rspam-User: X-Stat-Signature: zjxhseiswhe8uok6me5etrnbcdqr6k9n X-Rspamd-Server: rspam03 X-HE-Tag: 1687779341-103298 X-HE-Meta: U2FsdGVkX19zMDsOHS6zG8liiepvfXZ2pgk9ZQDlrjv411UZV/PEWxG2NofhnS3LeaNIY7VpdMavCcbwMIKqRdNJtL6TSucKS+w3IPQH0H8IvNbCJ+E1dXTlnSxMITLBAU0+VKjxyLy0Hk3ZGNoKkIvnPjKQUDH3MKAWxCd3PLdGKuj4HI9wHUni/dFg4wf1oilrD08QSew3GCKGsKB3MYH05yfKPEMJSVps/FMf+eISaBixtBqVIlKWAXU25P2DvafsjAF+CsdpJA3OZsG2grYgDXu08dfcvT3Mb/Y8eiTcSDUAWmg16qdxdd0o5Ne/10I9o/K8vCuyoAC8Rg9GbW5J9QSIv4tehgnGr5SdqDfRA3b9cZllJMlCo/D/g28zPmPRJ2P467TGGk+rR/k8R04VdUSQNyw+iHagP/eyMEilsowZfSKuJxNbkWSoG6aqXG5NWCGaZyobGwypSbxNid0Ub0jLo/6NtHfA/ffluEXn1D67j2Df7w3eZ3qsn1wW7E7Xk3B7gDqASC6T5XWgtiwpYIPJuPBqVB8Otl7TwVNXGvrFH+QRtHU8eVReavS601FWuvIdfz4CFsQY3dL8R+PiRLgk5VslpOb9Qrii4VUZNTPn7jWXwThfmpmLQApJe9t9xNwQrJuMKPjo2EsmjxeeLsd/1FfRsh2v+8LfovRFt24vweuGYH5LwbTc694lp412bMRsufH3CRVlRC6MzETI6itVHB3UB9HhN7RJUsPNBURECzO4Js4KSOsNdpQPcpLDCcgdiQin2JjKueyGhJtstV2Lh+JSi8uruaAS2kgngWnBf423uCWEKNjOSEasCvnJKpt+GSCPE+cyrrgMVd5BnHTHCGCf22OOmIRajZP27DRMvkTBHcIYMRQEUNx+WdotCx2Fg5BWgsGwVgYF50sMIWGgTKcAqfZRSSuzuu70sbg8Lrz6FhnAC7FkgKIykJkmodE4sEm/Nd8jPPU LyZYZ3Wv MfYg22DIIENHarIWzjPu5FqeLkWTyOHXDxk+nuv4woOpBd4CUgICflcJCZwTkdxTgBdVEWHu9GOOsgo92u5sy5+YdO2cOepeH1YT4UIFu7uDpUhgDGsk+BsGMMKsfwIG893uxZCvjA9dYyiqEp3YXz6+FxE44LZJtU47PjhuM5EsIlvFHwvrzwMOTPCl57/YEbMz7LlKRkQSATjq/ktw07WWCnAgNeVhp2MQlrY9I72NaSLobGWuBW4Z16niLLI61Be6cAX9BSk2rYW8= 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 Mon 26-06-23 20:26:02, Tetsuo Handa wrote: > On 2023/06/26 19:48, Peter Zijlstra wrote: > > On Mon, Jun 26, 2023 at 06:25:56PM +0900, Tetsuo Handa wrote: > >> On 2023/06/26 17:12, Sebastian Andrzej Siewior wrote: > >>> On 2023-06-24 15:54:12 [+0900], Tetsuo Handa wrote: > >>>> Why not to do the same on the end side? > >>>> > >>>> static inline void do_write_seqcount_end(seqcount_t *s) > >>>> { > >>>> - seqcount_release(&s->dep_map, _RET_IP_); > >>>> do_raw_write_seqcount_end(s); > >>>> + seqcount_release(&s->dep_map, _RET_IP_); > >>>> } > >>> > >>> I don't have a compelling argument for doing it. It is probably better > >>> to release the lock from lockdep's point of view and then really release > >>> it (so it can't be acquired before it is released). > >> > >> We must do it because this is a source of possible printk() deadlock. > >> Otherwise, I will nack on PATCH 2/2. > > > > Don't be like that... just hate on prink like the rest of us. In fact, > > i've been patching out the actual printk code for years because its > > unusable garbage. > > > > Will this actually still be a problem once all the fancy printk stuff > > lands? That shouldn't do synchronous prints except to 'atomic' consoles > > by default IIRC. > > Commit 1007843a9190 ("mm/page_alloc: fix potential deadlock on zonelist_update_seq > seqlock") was applied to 4.14-stable trees, and CONFIG_PREEMPT_RT is available > since 5.3. Thus, we want a fix which can be applied to 5.4-stable and later. > This means that we can't count on all the fancy printk stuff being available. Is there any reason to backport RT specific fixup to stable trees? I mean seriously, is there any actual memory hotplug user using PREEMPT_RT? I would be more than curious to hear the usecase. -- Michal Hocko SUSE Labs