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 5BCF8C76196 for ; Mon, 3 Apr 2023 12:51:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91ED26B0072; Mon, 3 Apr 2023 08:51:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CE196B0074; Mon, 3 Apr 2023 08:51:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7BD186B0075; Mon, 3 Apr 2023 08:51:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6EB6C6B0072 for ; Mon, 3 Apr 2023 08:51:50 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0DA8F140ACB for ; Mon, 3 Apr 2023 12:51:49 +0000 (UTC) X-FDA: 80640066780.10.6C10143 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf25.hostedemail.com (Postfix) with ESMTP id B0470A000C for ; Mon, 3 Apr 2023 12:51:46 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=none (imf25.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; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680526307; a=rsa-sha256; cv=none; b=Ip4c+fbSJZjBeoTYxUY5no6MjITIr4kdZdhZ3I0xEsctaE5JiLY26WKphpsxZbdom4ZBRi jgLFY0HgkCUnB6UkPa67JkYW5B3cq3iYwbUsH0NMj5nI2vhjFjvnWRSMjngDJWm6PCEqju JmSHp6MoB31xsYFgHtm109b73fTCHiY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=none (imf25.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; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680526307; 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=B+HoDG54VkrKhXBO8rROIxWaBYY3IjhOjFJ+fufgqbQ=; b=0FsddbMob/PtTVkhr6cUiCSco932wcAQEdn/jYKBXtYitsRwojwaxiboF0XNvBTU7a7Zyy xvd0auyHUVhKs0x1ilAiB54olfPrsRTZcozRoZqDzs/EtEmiUWV+XpC7mBZF7pUVtJQKGc rQKtKIYKsY9kfewQcJEHcTj+iasT0Q8= Received: from fsav117.sakura.ne.jp (fsav117.sakura.ne.jp [27.133.134.244]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 333CpVQs051006; Mon, 3 Apr 2023 21:51:31 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav117.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav117.sakura.ne.jp); Mon, 03 Apr 2023 21:51:31 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav117.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 333CpV1V051002 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Apr 2023 21:51:31 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <78ff6e70-e986-1fcb-eafb-3edd5f2bceae@I-love.SAKURA.ne.jp> Date: Mon, 3 Apr 2023 21:51:29 +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 , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , John Ogness Cc: Mel Gorman , Patrick Daly , David Hildenbrand , Andrew Morton , syzkaller-bugs@googlegroups.com, =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= , syzbot , linux-mm 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-Queue-Id: B0470A000C X-Rspamd-Server: rspam01 X-Stat-Signature: krducpjc98xg6zywyggtddqxrogjogx6 X-HE-Tag: 1680526306-506240 X-HE-Meta: U2FsdGVkX1+a1wa55tDYuoZT80VUJyR7IqUJFr+1JPDCLX0d84jT2TQeAWm5xHMZVO7rFy6s3B/f/C8+x4OWk7dWyr0VzrmJeSShjD00T5LH+o8M3AE8WLbefMNsq4lvW34G6Iggz73T7fMeZ2qsV1UuFntpUovMQMhXg6RaqlBsFOFEjvU1j7CjFHwr0p1/74ACHRkvyvxxNirjJjyy1h/hNczebFwVRC4iYdTduZQ4qtpXhSyShIMZYrTpgKmsb5usiSW7woWwioPwdttOUvjqiZZ0pOxQgL2XaFpMQsrT4wPFWaPEPtoPHFu6IWWALCS9znBkbdunf44SFsw40aOvchAoNyqKmG3lN7caEy4y5xYByt9bE7Jiy6aWN668hH6p1sgNiWaN/YbbtAibomtXKJqwQsNDxGM3swTx25+eKGX0utsYCpg1FU6yWqgKTXQY8G8EEMJ1w13k/rOGCj0/4Uf7gR25BkKdCsBNIcDMfAfPylzrxiRrSOjl9vah5bLFDtybyXW4IBtOpQZEoGuuvlWj33kF7n5ayFcfHp9QgU+bzyTian8F8udd7lDC+QqHDTlJWgiUkCBW1pOGG0AcsJWyeM0BK3PUkfDmAnkVSBnCNgH/M+lep4m6858fawRZClqdgoCgvrolFCwmtUymEnwafu383JC/e4H/cBYC5GYxlHeGCJ9XORyN8MIVzv28OscHKk5XB5uRxBgxsw2F7OijGbTNuTInBbT7CD8lJCtEaQov7zjERq2JyrXkTDnfmZM9gT9qFnZ5j9Pyrv3W0fZ+ObEWO395K1EaSP7/7ob7XvSoqMkRFcvEYze8Ol1mi2n67Y4htz4BP2ClQHwsV2sJXkB6j+Vw+dSm8edVlOUSFCFnmC3R1dGIYe2irxEkztDKm5x3VlZgsDJufWiPwVpZ2mWU5covQMHvDg+DlvEjYMTI1JhJpSmKqzb0N/qLxpdib01spWKbZmR L3VtqWlq CMtF2DMBv04XkdTOLdiSpqKrp2M652t1I8HwdtQHLnMzYNutufnq3a2cQE+OcwfhdnmXtyEe1snoURw+YPjMVI5WNWRn4fi63SXDrfDL88/Jz3nBGbkX6RLaosRQuV0elcLE92ulfVzWps1Ft0LunpM6ROyVlJ4iMnY98eDALULdp15RcfdMcktZZv5E1oKOziuZ4OW+kV6QcYLax3LJj96CrUSG0CacFVPEzS5ko9YHCH4t5npWgzJTagi1g9uy6w2dq0uWqt3VJGjMmYRuUoUxhfHtTiuLEcq41+qYDV4VUooypV0T4X461SJfiskRK6P/UEzQLFHJbZQ5vVh6RHO4MXsyhqV7pIaiiIWLL7IpLsUW0kWG9mPe3ASG2K4M15d+L 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 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. Also disabling local irq will be needed. 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, ...); ? Since this is a problem introduced by mm change, I think fixing this problem on the mm side is the cleaner. Can't there be a different approach? For example, can't we replace cpuset_mems_cookie = read_mems_allowed_begin(); zonelist_iter_cookie = zonelist_iter_begin(); and if (check_retry_cpuset(cpuset_mems_cookie, ac) || check_retry_zonelist(zonelist_iter_cookie)) with different conditions, like recalculate cpuset/zonelist in the last second and check immediately before giving up allocation or OOM kill whether they have changed?