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 911C3C76196 for ; Mon, 3 Apr 2023 15:13:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA92A900006; Mon, 3 Apr 2023 11:13:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E321C900003; Mon, 3 Apr 2023 11:13:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF9B8900006; Mon, 3 Apr 2023 11:13:05 -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 BD709900003 for ; Mon, 3 Apr 2023 11:13:05 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5F9AC1C6C45 for ; Mon, 3 Apr 2023 15:13:05 +0000 (UTC) X-FDA: 80640422730.01.CE1EF72 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf12.hostedemail.com (Postfix) with ESMTP id 587FD4001C for ; Mon, 3 Apr 2023 15:13:03 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="qGAJg/fG"; spf=pass (imf12.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=pmladek@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=1680534783; 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=+XskoX27RUCdwiIvY6K0RBRORYcVHpEFRNpqrioyc5c=; b=QD0i6qsnCTs9OhVSiWSF2RE5JK0O804hbtECr7QEk7PhLopi5tXC9fNBjAqsU7tc2FsMu6 v74goVY7y4ogepJFh8ziRf4HjXWm/rxywmTr2pIDs8LJ3u348IBVA2M4J/1h1IokBRXMQU nLGluohRtHMq9to2r5GwyGTLds2kMN0= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="qGAJg/fG"; spf=pass (imf12.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=pmladek@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680534783; a=rsa-sha256; cv=none; b=Xe1O2mmTlqv8ge70nxSQQW0v2H/J07jqKECxXJbfAf9Pp85N0IjoZIIXUg9WkyowtZZuk2 U0eZ0m53MhG+3j/YJCUVKCpChwSxKkP9S+Mitrnow7Wk3fc1T9hfWsRP7CpPz6MfYETxLD 54CshQ9NTIsiKIICjlhkqjk9f4mQaM8= Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id D1CEC2000C; Mon, 3 Apr 2023 15:13:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1680534781; 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=+XskoX27RUCdwiIvY6K0RBRORYcVHpEFRNpqrioyc5c=; b=qGAJg/fGzZe1iCQG/7rBbCdZF2ao7mFwTRmaOHr3NOC/JH4B38Fn7KNczglDBFNBuGmowM EqhHvQU5wp4LjVP7ffIA4YFGoDLNsCFkprrpIcw7Rl/oD/Wcwh8As8ksaH9qviYerygrSj Be+Ep//i/cKq3YfCwQSy51ncOwbr4tE= Received: from suse.cz (unknown [10.100.201.202]) (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 CAC772C141; Mon, 3 Apr 2023 15:12:59 +0000 (UTC) Date: Mon, 3 Apr 2023 17:12:59 +0200 From: Petr Mladek To: Michal Hocko Cc: Tetsuo Handa , Sergey Senozhatsky , Steven Rostedt , John Ogness , Mel Gorman , Patrick Daly , David Hildenbrand , Andrew Morton , syzkaller-bugs@googlegroups.com, Ilpo =?iso-8859-1?Q?J=E4rvinen?= , syzbot , linux-mm Subject: Re: [PATCH] mm/page_alloc: don't check zonelist_update_seq from atomic allocations Message-ID: References: <000000000000b21f0a05e9ec310d@google.com> <78ff6e70-e986-1fcb-eafb-3edd5f2bceae@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 587FD4001C X-Stat-Signature: kikoz4zaoykjout6rkq9knzj3cgfhnwc X-HE-Tag: 1680534783-316566 X-HE-Meta: U2FsdGVkX18+YcLUHAoJ53petpIAz9cK5O+GXyRgOl/iOjovHIf9g3u3Qmr4AGYAAh6j94bSyhbQl6LivQja6VNGgii3cSTeX5uO5b0vBZthRHGNNz5bI6iI0HmrBKhdh6to/cDRplSZ+ngvSk1BscgZqF/RlITbVmBZINOOK1qZgNJATZSBOT6o8llfvpM42w8ppSQjR0fzZBhdB7zKpUH+BQeYCG6E4HJZAaY6GfeD6RRtNbrVvm8+WzCYr9q9XioJKIZ7M7ohCWPzEq0kyDRIe182JuhvyqJ3+fqT6f3C8FaWo8f1OEgpQ26slcHNAKNaW0WDUABSHdQ8llG4E4DmX3PEJv8LLF5Jw1Aa82fhht2ipKPTQOqrFvKZloi+EC59M10hdo3vV0olw6d6BYNNU4fx4JQv9aqMfh8Nq3uUJp3eZIn1uN/1Lio0BdlfkrZC5XVfqzkw5+Q2oPrFmISLAYIu09Sz+0J+a8XjoZSQDYhRnw7G5+l5Otr+WINxkhpEul97bCKvCZ2bszpHNBKEzRZRDFHEAYrbTL7ApXyzt+Cvvt+VpJdOyN7TKGIom343q6dua6QRCO4whPEc2hmtJeD/eOwN3reZjxChE4aSFOqb0J1laRY0FsPgZzYqh1vjRycHRRe4ll3/g5Trwz8zszHEcDuiN/ArNMDytWibGoV7RtoDxFe3wadF4vUvKBxMs9eEdmRWDtdZzI3AS25G+/Jl1KjGbzLGstwYUnmdbkRTKNhBMIzmxcowOzNAa94a+VkHdsMBAzFsFaLjG7LVf73LI+crXJ1xEXAN9sNbStsIn6t6s5apfLY9wR+ewZcgKgJGVo/GfOjOFKjAEosMB2En3FcUqtRuUYuB6MrrTF/6JHwXrt9zYWqlw3hpIM0xWsrp3oubGzsbeBAB5U6U/bFF3bCQF4CTcRkXGvzniR5c5g8XdbVM6jgD3EVhcT7Ya4fsOKErXJcOSc6 hg0/J99D nZbQ3B4HETMKwiH2ZIrtaziiooi8m8D+gUwb6jkdwecgcEFXrkk8l9PuALpQmuUe/CkF+P++tYbtJMdYjw5+fkCRY0VeOBk7bg8+jQHFC6Dn4Sye65Re0ipgA08wLzqNO5xRz/dIekoqkI8YFOdHIA74W7USEzHsejU64P+rb+JxG9iYlDmj/nA34rxSFn88B/3wpdju2G3YpU6ydXojZ2qDbPirNrFv7Xkk/SH3eZF2APj+eq/PLCZuAmMuKxAEFXUQi/afn9yyf9qRJAhMmLb097/kLPcziW33Na8yapI0rLWjD3/t+sZPYnQ== 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 2023-04-03 15:44:34, Michal Hocko wrote: > On Mon 03-04-23 21:51:29, Tetsuo Handa wrote: > > On 2023/04/03 21:09, Michal Hocko wrote: > > > On Mon 03-04-23 20:14:28, Tetsuo Handa wrote: > > >> Well, it seems that read_mems_allowed_begin() is protected by calling > > >> local_irq_save(flags) before write_seqcount_begin(¤t->mems_allowed_seq). > > >> > > >> Can zonelist_iter_begin() be protected as well (i.e. call local_irq_save(flags) > > >> before write_seqlock(&zonelist_update_seq)) ? > > >> > > >> But even if write_seqlock(&zonelist_update_seq) is called with local irq disabled, > > >> port_lock_key after all makes this warning again? > > > > Hmm, local_irq_save(flags) before write_seqlock(&zonelist_update_seq) won't help. > > Synchronous printk() will try to hold port->lock from process context even if local > > irq is disabled, won't it? Not limited to interrupt handler but any synchronous printk() > > inside write_seqlock(&zonelist_update_seq) / write_sequnlock(&zonelist_update_seq) > > section is not safe. > > > > > Thank you! IIUC this can only happen when there is a race with the > > > memory hotplug. So pretty much a very rare event. > > > > Right. > > > > > Also I am not really > > > sure this really requires any changes at the allocator level. I would > > > much rather sacrifice the printk in build_zonelists or pull it out of > > > the locked section. Or would printk_deferred help in this case? > > > > Just moving printk() out of write_seqlock(&zonelist_update_seq) / write_sequnlock(&zonelist_update_seq) > > section is not sufficient. This problem will happen as long as interrupt handler tries to hold port->lock. > > I do not follow. How is a printk outside of zonelist_update_seq going to > cause a dead/live lock? There shouldn't be any other locks (apart from > hotplug) taken in that path IIRC. > > > Also disabling local irq will be needed. > > Why? > > > By the way, is this case qualified as a user of printk_deferred(), for printk_deferred() says > > > > /* > > * Special printk facility for scheduler/timekeeping use only, _DO_NOT_USE_ ! > > */ > > __printf(1, 2) __cold int _printk_deferred(const char *fmt, ...); > > > > ? > > Dunno, question for printk maintainers. I know they want to limit the > usage. Maybe this qualifies as a exception worth case as well. Sigh, I am afraid that printk_deferred() is the best option at this moment. I see that there are more pr_info()/pr_cont() calls in build_zonelists. You might want to use printk_deferred_enter()/exit() around them. These problems should disappear once printk() messages get processesed in a kthread. And pr_info() is not critical information by definition and it is a perfect candidate for deferring. Unfortunately, introducing the kthreads takes ages. So, we will have to live with printk_deferred() for some time. Important: printk_deferred() still should be used with care. The messages will be pushed to the console in another random context that might be atomic. The more messages we deffer the bigger risk of softlockups we create. A rules of thumb: + printk_deferred() would make sense for printing few lines in a code where the dependency against the console driver code is really complicated. It seems to be this case. + printk_deferred() is not a good solution for long reports. It would just increase a risk of softlockups and could break the system. Best Regards, Petr