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 2ADC0EB64D7 for ; Mon, 26 Jun 2023 12:27:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A6BE08D0002; Mon, 26 Jun 2023 08:27:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A1C158D0001; Mon, 26 Jun 2023 08:27:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E3AB8D0002; Mon, 26 Jun 2023 08:27:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7F1FD8D0001 for ; Mon, 26 Jun 2023 08:27:32 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2D154C04E5 for ; Mon, 26 Jun 2023 12:27:32 +0000 (UTC) X-FDA: 80944824744.30.33DFA0D Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf07.hostedemail.com (Postfix) with ESMTP id E991D40007 for ; Mon, 26 Jun 2023 12:27:27 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=none; spf=none (imf07.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687782449; a=rsa-sha256; cv=none; b=7TVyN1HGvSsqIBN92AvoB7k7xRnFjiwJxiiW5oJjIkCI+Mc06Ox/YMwKvaR5rjh4PoeRsP ZSF7EjW0v6uYLzGiSdd2FuvVORv7rxiJSyojXhXfcrsXESj/1mwr75LEabwZlT7C8bP7BI G+tKN1BIy0JopyNYQaTuvtwLZcdf6Qw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=none; spf=none (imf07.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687782449; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D5Tse9WJyew1QoH/Ow5Yo1ibKUj8l3UYpx4sKTopufw=; b=qT3INrOeh/RR3XvVZvtKEKKcTbgHxmUhI2CM2hm+18KvgieOH8NWHFhPCRUJ28GMclLVWX /tIMcfYtOxgkXzyWk6c5dWKu5bOV/17+7henF5HLFWQzA+hPjgx476ujh8FqzqN7ztv5+F yp/WBbiGLJ1VcjGbfnA+TqG7sntnwI4= Received: from fsav119.sakura.ne.jp (fsav119.sakura.ne.jp [27.133.134.246]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 35QCR6rY029034; Mon, 26 Jun 2023 21:27:06 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav119.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav119.sakura.ne.jp); Mon, 26 Jun 2023 21:27:06 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav119.sakura.ne.jp) Received: from [192.168.1.6] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 35QCR6Mp029030 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jun 2023 21:27:06 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: Date: Mon, 26 Jun 2023 21:27:05 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() Content-Language: en-US To: Michal Hocko , Sebastian Andrzej Siewior Cc: Peter Zijlstra , 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 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> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: E991D40007 X-Stat-Signature: hemjt8cn8f5fr1t98ye6m7mase1jca3g X-Rspam-User: X-HE-Tag: 1687782447-322141 X-HE-Meta: U2FsdGVkX19SoTo/CJ4IyRRy2CPQIG0QydYvabd9PRpjh47KZzeP6CTMT7c02yfRFYdwEuvnXxZm2iS3CJCqD0pdeUdkIDroXKZL3XDDBBPNhsQHw9FaQ4Y72J27GuVEBpdBFFuF+yqL0pnnMGbZ6XgUW+i1ZL0xXYAcHJLnQTHxOCBd8yiOKBunxzFQNz7EBS3rgY9ny81q2/OS20aVKw6NfX3a8Q3ZAZrlgGv0ohjjXhSXcwBHKfQs4daccrMq+4KDcdq/QPUeT96sojNrA4v7eZCRMrAz0XJrj9hTRgMT0ymXCWIFLoZVrTd8XVSBq1HqmqfeAF0LOjKN6f7CQH1EsiieRtwpNp96iUTZUqbJD8p8ulL44yyzwYMZvhbWnqQamWV0lYB1Gc0EQvM5VilsGq3VC9JqiyXj/XiK5m/sW5RCicZTeeyeTipmlRVYDbJZI0h+VaSgXHgmMy+U61jFoVrZdrBnMD7HRexG0xztCkI5ZX6Vvbmf7B+3pI7SlP6GcF0fri96xORSSQOV4vCv/BtDxp7diawMmc8RmUMGY37B3w+Wq1FyJUQ4Z4BjrZurC0yBezpOwtEEz8YqjIggrFBe0WkpHPkKpuiMdCL2VoQFRr0jCglaDRBJGu9sTJBewsQoNSa65NfjbnBwKNSYHwsdcZaY3MejIyRUnnKRMW4pmzw3zDi9elc6nyg0hAXKKhMFUzyFPUJIaWS7j4IWIRpMro9aRxo5Zlhfro0YSyalDjCYtUqqdGpXu+sb+waTfFFeMsVGWtan+NQCzS0Rn0Hgs8c3LU9XjZqaZwDmxB26I7Y8BcqpQCM1AHL1s2pIgyRoHdyFBkWPi6vLvn5PiEZ9S1h/b9s2CLpcvbsExMK+wykX6Cb7ELWHt6ROI8CtFq3BWHjtUoQLrbZRIln/B23KDAr75suP4IGoYt9MrWU+Jy2AIhjLmyb+4Blg0jH3pqEhwDnsntKKTqc 1UhkEGFa fawFFAwIJuuT7P6Q1NU8b8FnV29A1RPXZKLEPVglbNNe8vctpKMuC5LGr3nOnKP9O0LGo17apUQ4zdgNe23Pi1bBrqKHlh39c/c13qSMsPqSmq2c9qmseKiTkT3nL+GIsV20NRMrVMmQ8WvRS1l2W5fy1p23PX9X4LoedCNKiEsn7ebGX0dfFzRyMJHcCrqRky1kUqTg0CHmyl0F1gEpD3IZAbkzmH9qGWxdx8646bWJ3arAqijZI7frw0DWFF1fxGKzzZfX3eKWVeYwgbndOo1sHeVacO8hcZq5crTpRVgtDqDqwJ9lzOpFtnCttO2xzfsRq+qjbAai4VqxgBReENe3HFJHp48vaEDopcASZGX//mlHs8iy4JdTY/dvLUf/O1aLPyqxrZXzsdZg= 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/26 20:35, Michal Hocko wrote: > 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. Even if we don't backport RT specific fixup to stable trees, [PATCH 2/2] requires that [PATCH 1/2] guarantees that synchronous printk() never happens (for whatever reasons) between write_seqlock_irqsave(&zonelist_update_seq, flags) and write_sequnlock_irqrestore(&zonelist_update_seq, flags). If [PATCH 1/2] cannot guarantee it, [PATCH 2/2] will be automatically rejected. If [PATCH 2/2] cannot be applied, we have several alternatives. Alternative 1: Revert both commit 3d36424b3b58 ("mm/page_alloc: fix race condition between build_all_zonelists and page allocation") and commit 1007843a9190 ("mm/page_alloc: fix potential deadlock on zonelist_update_seq seqlock"). I don't think this will happen, for nobody will be happy. Alternative 2: Revert commit 1007843a9190 ("mm/page_alloc: fix potential deadlock on zonelist_update_seq seqlock") and apply "mm/page_alloc: don't check zonelist_update_seq from atomic allocations" at https://lkml.kernel.org/r/dfdb9da6-ca8f-7a81-bfdd-d74b4c401f11@I-love.SAKURA.ne.jp . I think this is reasonable, for this reduces locking dependency. But Michal Hocko did not like it. Alternative 3: Somehow preserve printk_deferred_enter() => write_seqlock(&zonelist_update_seq) and write_sequnlock(&zonelist_update_seq) => printk_deferred_exit() pattern. Something like below? ---------------------------------------- diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 47421bedc12b..ded3ac3856e7 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5805,6 +5805,7 @@ static void __build_all_zonelists(void *data) int nid; int __maybe_unused cpu; pg_data_t *self = data; +#ifndef CONFIG_PREEMPT_RT unsigned long flags; /* @@ -5813,6 +5814,9 @@ static void __build_all_zonelists(void *data) * (e.g. GFP_ATOMIC) that could hit zonelist_iter_begin and livelock. */ local_irq_save(flags); +#else + migrate_disable(); +#endif /* * Explicitly disable this CPU's synchronous printk() before taking * seqlock to prevent any printk() from trying to hold port->lock, for @@ -5859,7 +5863,11 @@ static void __build_all_zonelists(void *data) write_sequnlock(&zonelist_update_seq); printk_deferred_exit(); +#ifndef CONFIG_PREEMPT_RT local_irq_restore(flags); +#else + migrate_enable(); +#endif } static noinline void __init ----------------------------------------