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 064FCC761A6 for ; Mon, 3 Apr 2023 11:14:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82B5F6B0072; Mon, 3 Apr 2023 07:14:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DBEB6B0074; Mon, 3 Apr 2023 07:14:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A2C66B0075; Mon, 3 Apr 2023 07:14:47 -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 5AFBF6B0072 for ; Mon, 3 Apr 2023 07:14:47 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0E7DB160917 for ; Mon, 3 Apr 2023 11:14:47 +0000 (UTC) X-FDA: 80639822214.04.2E1E2F7 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf07.hostedemail.com (Postfix) with ESMTP id D347C40016 for ; Mon, 3 Apr 2023 11:14:43 +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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680520484; 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=H+YE89L0e4vygztWdOQpL9T7oDucUFh8bumVl+ilR1M=; b=Iq9Qvzyeful2rSw8XbxAHpL4/M8ttNTjMvyeycuQA57qYDCn3kv+x7ZYotjfZvRpc2c4iU 9EwBY7UAeZyMjQQBgRgW5SJsRpNTW+kXjnPLh8MCYapcknJ6QxZ6QMefPXw7lp9V45Ctww 2IBi/f0P0tRXQC466X0c+1gxG6Iegi0= 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680520484; a=rsa-sha256; cv=none; b=zJeOSAmGn1y28ZFLdeU6jejr9vEbrjtm8Ug0zFMyUF1pm3cUwV3EDOr/OgNH0s3tGXeCmA a+kZ7tzGZSOktbW2vpzxVEuoxQrOVHU7Nr9zH3TnGa4nN2p98lKNwhRsIojDWPSuY8PGoP PDN2Ch+qySMk8fcz/LY5rCHdUdTxTk8= Received: from fsav311.sakura.ne.jp (fsav311.sakura.ne.jp [153.120.85.142]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 333BESIU029900; Mon, 3 Apr 2023 20:14:28 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav311.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav311.sakura.ne.jp); Mon, 03 Apr 2023 20:14:28 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav311.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 333BES4u029897 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Apr 2023 20:14:28 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: Date: Mon, 3 Apr 2023 20:14:28 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] mm/page_alloc: don't check zonelist_update_seq from atomic allocations Content-Language: en-US To: Michal Hocko Cc: Mel Gorman , Patrick Daly , David Hildenbrand , Andrew Morton , syzkaller-bugs@googlegroups.com, =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= , syzbot , linux-mm , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , John Ogness References: <000000000000b21f0a05e9ec310d@google.com> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D347C40016 X-Stat-Signature: 1oy7h6ehf17jw4e1wwg7zitqfz3tqg65 X-HE-Tag: 1680520483-369251 X-HE-Meta: U2FsdGVkX1+uq1MWAYo338dX222otEkrZL6DdVY78ouornHtgv/m7VrLv2PN01HjptLSht8LqCF+eOHztenNPJ3ZxXQbyg2BIlz4L3vf4HnWFYYSJU1aOqnV3WTcMXCOGbJRJMLMmgUeuFyvBr+jythlwFW1cRrZf6ApUK1GVC851HKEw3Nmei+LlQLeILi//c1LpuuvadnjK+JfMsBukX2vf2cLmD1HNTuinNHdWAyd12Agqf+gB0EI0nUMWtfspfHlAkXRqdfSneisZvuk95uSOXx5AIseN3VkPLjA0CeEfSHFfZCsUfeHfqkNFBFs9eRJinnJfA4Ema70oWnqqJu2FrzjTqsdqRDBFv+SA6rSFqrGNvAgGOp9CUplTj94XgYG9ufi8IpUbQoUDpV5htsN4VRUVCO+5ez0R0+Z/iJuy/kH22LsHKzggg7iJ5Ye9eBKHqRTKKtQkoYcr7zhQbmO8ZlgTTCnthxkz05xnnx2xys7UbkKC41fA+dqzHaP3kS7WVDUkUFsNvTLGKmKCE8EPweDFO8phBPFk8Omwjbo/SB+AQ/JOWzAh8smATXIG0hbIXmClXlZ2F3FkGJlUGQ2zjF0HoDDN4GNV2IM/03k4vnlBrHaeQzYAKN9n7xyi0HzQfmE+Pf0Acz9SGDg8BcgOmAqaulH3VKOCKg+aufAXKeT0xln3kjhSfvRuFcjHPqe3oonCtl2EA9w9Baob5gVXq5h4L19oFLNlKVbYrf0ZQJi/CKveI0CA3TgWgSRshmuDvBxWX6g9K7d4NgRvihYWTJiTyUzDIsfB2I1nkMm5I26hMFk/mpM4ZdxOmkjr8Q+4KGbg0StJHiqjJx1tWXkcF/pC+wzPgLbfhUbbknCI4xqf1XsKlhqopQBKUuXNddt7iTfE+w2eXerK4Yo/z64EJl28iKVX6WjwFO+5RBSJ/b4Sf4xnY0BhVhR1cqZ7NLowSjoOGxIqR1sc+V VafE/Avg rA9BhuUTy1/COS8Cv9kUqmVhcRnX7O9vejlEAACEWnAiIyFoZTtlkn9xQW90tZym36ROmCNDICjscOy2fCmSTmjh/GC1e/dJbGUEIqNmq17oN/MOGvlw7mrjB1okY5PI3AEo06WtHEDyti5mQ2JgA1ZNJE5G2hkcum4B3P00ooyQue2vYi0Wnf56Ge8IPth57x8d2AF/fCnXPFFzmgo+GgCfg7GtOKXZ5dfGV3RW/df5wKP3x1HA6IGx7C1577NloxfPVXslmwDwg+gOP3llrojMO/r/zY8jPpLkyG741PmZjZNZ18U8k5wo+ElLYVaka+Y4xL9+U5C9vDgpS1v3B37gsBsLA2dAVwG7EFBNkxBaHqCBXiPJQFp09igLRbfjhiZhqzuDWv8ZHNxx4ooZl0peWfM2msUnzwU6h4t0B+HM24KmES9BO/nIjol4qmumTZMy075JWKDwTdDJy0sCfOwKLQQ== 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/04/03 17:15, Michal Hocko wrote: > Is this > https://lore.kernel.org/all/0000000000001d74d205f7c1821f@google.com/ the > underlying report ? Yes. > Could you explain the the deadlock scenario? build_zonelists() from __build_all_zonelists() calls printk() with zonelist_update_seq held. printk() holds console_owner lock for synchronous printing, and then upon unlock of console_owner lock, printk() holds port_lock_key and port->lock. tty_insert_flip_string_and_push_buffer() from pty_write() conditionally calls kmalloc(GFP_ATOMIC | __GFP_NOWARN) with port->lock held. But since commit 3d36424b3b58, zonelist_update_seq is checked by GFP_ATOMIC allocation (i.e. a new locking dependency was added by that commit). CPU0 CPU1 pty_write() { tty_insert_flip_string_and_push_buffer() { __build_all_zonelists() { spin_lock_irqsave(&port->lock, flags); tty_insert_flip_string() { tty_insert_flip_string_fixed_flag() { __tty_buffer_request_room() { tty_buffer_alloc() { kmalloc(GFP_ATOMIC | __GFP_NOWARN) { __alloc_pages_slowpath() { write_seqlock(&zonelist_update_seq); // makes zonelist_update_seq.seqcount odd // interrupt handler starts handle_irq() { serial8250_interrupt() { serial8250_tx_chars() { tty_port_tty_get() { spin_lock_irqsave(&port->lock, flags); // spins here waiting for kmalloc() from tty_insert_flip_string() to complete zonelist_iter_begin() { read_seqbegin(&zonelist_update_seq) { // spins here waiting for interrupt handler to complete if zonelist_update_seq.seqcount is odd tty = tty_kref_get(port->tty); spin_unlock_irqrestore(&port->lock, flags); } } } } // interrupt handler ends write_sequnlock(&zonelist_update_seq); // makes zonelist_update_seq.seqcount even } } } } } } } } } spin_unlock_irqrestore(&port->lock, flags); } } 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? This bug report might be a suggestion that we want to use two versions of __alloc_pages_slowpath(), one for atomic context which is geared towards smaller kernel stack usage and simplified locking dependency (because atomic allocation can happen from subtle context including interrupt handler) and the other for noinline version for schedulable context which is geared towards larger kernel stack usage and complicated locking dependency for implementing rich retry paths including direct reclaim and OOM kill...