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 BAEECC76188 for ; Wed, 5 Apr 2023 09:02:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0458C6B0071; Wed, 5 Apr 2023 05:02:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F37ED6B0072; Wed, 5 Apr 2023 05:02:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E001A6B0074; Wed, 5 Apr 2023 05:02:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D05B66B0071 for ; Wed, 5 Apr 2023 05:02:52 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B078EAC6D4 for ; Wed, 5 Apr 2023 09:02:52 +0000 (UTC) X-FDA: 80646747384.20.6D5F9C5 Received: from outbound-smtp26.blacknight.com (outbound-smtp26.blacknight.com [81.17.249.194]) by imf22.hostedemail.com (Postfix) with ESMTP id B24E1C002A for ; Wed, 5 Apr 2023 09:02:50 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.194 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680685371; 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; bh=l+Z56AXqPLpPA4hYd8uFiql96690GkSblUnAXx2l/W8=; b=mKzgvxNj236K0HFkl58zbhOdgGrEtTalszKMHCb4OLNGfIjp6wSgfiA3kBkwmxiK1tjb8v cPGtyr5STxTDPq9X0JmyPhB1+UK8C14Xk4+aVoEusGBNpHsyghqM9Y1AVvDwUTLXWnKEjE xmS4/ULl3HiZcReMiMsGmr6YHuZRMeA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.194 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680685371; a=rsa-sha256; cv=none; b=1onwOtMzEU3aH4lQcAabR1NXi8PBd8vnlYpmCD2MGZ5nX2LOO0VryLRTZRNEHQrLYk0ck3 h+yOjOdkf1NhfwI5yKRENFCATnxZhaGP+DLaPoVmdl3hmnfuRuPTqCwkHM5P1hxVvf+Lp/ aDQcOYS0gEDAcfLtgEW9UkXODiYPP+k= Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp26.blacknight.com (Postfix) with ESMTPS id D6606CADD1 for ; Wed, 5 Apr 2023 10:02:48 +0100 (IST) Received: (qmail 8146 invoked from network); 5 Apr 2023 09:02:48 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.21.103]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 5 Apr 2023 09:02:48 -0000 Date: Wed, 5 Apr 2023 10:02:44 +0100 From: Mel Gorman To: Michal Hocko Cc: Tetsuo Handa , Petr Mladek , Patrick Daly , David Hildenbrand , Andrew Morton , Sergey Senozhatsky , Steven Rostedt , John Ogness , syzkaller-bugs@googlegroups.com, Ilpo =?iso-8859-15?Q?J=EF=BF=BDrvinen?= , syzbot , linux-mm Subject: Re: [PATCH v2] mm/page_alloc: fix potential deadlock on zonelist_update_seq seqlock Message-ID: <20230405090244.y7p2x2yaht3hwg3e@techsingularity.net> References: <78ff6e70-e986-1fcb-eafb-3edd5f2bceae@I-love.SAKURA.ne.jp> <6266b161-e4c3-7d65-6590-da6cc04d93ec@I-love.SAKURA.ne.jp> <0585ddb9-5de8-8cdd-202e-53887bbb6b5f@I-love.SAKURA.ne.jp> <8796b95c-3da3-5885-fddd-6ef55f30e4d3@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B24E1C002A X-Stat-Signature: 1r5se17fxuxugoeeo95459qcgxx13w7t X-Rspam-User: X-HE-Tag: 1680685370-516061 X-HE-Meta: U2FsdGVkX193dj0eDybvTgK0jmwn3dHHmm91qLgG61QaOP+GGv/K5kuUjtB/zUqB0r9g6RT6kqTf63yHjFrSbS4ZNM9gR7gmcSd1s7nJTTjoDXAEriKnDgYfpQKkxC+Urdzyme7doUuvjEli8Ka4IQ/kgYYBbtEGBkPCqNoASRgPXaPARUnhCcagrsR9xk6gu2vxEc+qsxqvIXJhINm52eJKDAjMp7fW+6aEIWt7qrUqoF9xNKDMeer1JN8LdejKeD4CYu+xBFddPIRPCt3OCWHZMh49qgQXLx575W6NkGB+t+hbR/n6aE0JtIO8x9le9nC8hV4tct3eDK3JSawZz2aBKB0xQZfHpwBa4nmCIOXoxrA/ad/9nFbnUTachkZS0hS50dyjdW9qY6W54v+AC9jEO7OYCSGa7nDgUFYLqk34V7zPcl6X132ujsGBfzMbvn/Is1R3DNnx8KTSBJKo1fP3Xe39nil2cKKQOLVItQ3Ewa+uC66iSbLGSSl8SHyVD77ZL45xEnDy02nBdnZTrHF5HBlC/Qmdf1Ul5Qe51XXD3Z+rthUFZxp/Vgd2gRWWTyL0AEXehmqLzWQzcgJ9mzEx9h3zMYrtUI/EB/rRLTbtd3Grux25LAOv6lMJSzlReu0qUn991CJTmjCtfz+nUMlUljjaZ9CWGoOr+s4aC75ThCKmS40QY2ta0qTszU5un5np0K2a64HteOvEVa6ozN2k8ozn1OE+2JOKLh/oki2WCRKOea+7ygfKOIjcf45dxcRTInN9YttN9s+1XTKyhkt7sajJvHBbOAwEINPOATPqRGun0nQzESxVn95tDXvjhwZLGE9V+6VK4uXlvzrkk+e3LFV8u4CrkFHuFoy4ajYxtMV/fL5RkycvqVnegu0Tzq9uXKgauJ1MQSWqP8C69yfS6qKKCFxUgOqwuvK0BYDAjIv5xBQQOSxGAVhTyHxiHO+Hy1GgRvKSTKMyx9P vYoAGcPY uSvKKyfIv0xfI0OxIJY/A5TRImri5TEahWeEPzs2gdJDYW6hZgb3nI/csEGmdk3cNhmjlJCr9GIjdhn77/zRFg/JERiAp6Nv6B6wF+do3GgOH3F1WH7ycgvoY4rxmxCnRMP3iEVDLDcwUGYzwAMOa8T93c6pOBk1RuanB5e6dOSfRdSwymHdebbVVg9Pmu2Ug1RQX8cnBF7GPDOBUdGT088l+NvB3BTXkH9kIHWv9qMt0BSsq6SmeZDZuXANPoFQPIBrXL1cwMcxbTjIkwu58XKBkMdAsaaVtEGIoXLpu8MPw83vLGvSG3jBh61bXeN8jBlEErvzqWicwq1TXp//sZi29Te+2g0jbKo96tLFhcVxfpjiGICUZQw1QKL9sd7uWAq2RzcY2LvzqH7c= 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 Tue, Apr 04, 2023 at 05:20:35PM +0200, Michal Hocko wrote: > On Tue 04-04-23 23:31:58, Tetsuo Handa wrote: > > syzbot is reporting circular locking dependency which involves > > zonelist_update_seq seqlock [1], for this lock is checked by memory > > allocation requests which do not need to be retried. > > > > One deadlock scenario is kmalloc(GFP_ATOMIC) from an interrupt handler. > > > > CPU0 > > ---- > > __build_all_zonelists() { > > write_seqlock(&zonelist_update_seq); // makes zonelist_update_seq.seqcount odd > > // e.g. timer interrupt handler runs at this moment > > some_timer_func() { > > kmalloc(GFP_ATOMIC) { > > __alloc_pages_slowpath() { > > read_seqbegin(&zonelist_update_seq) { > > // spins forever because zonelist_update_seq.seqcount is odd > > } > > } > > } > > } > > // e.g. timer interrupt handler finishes > > write_sequnlock(&zonelist_update_seq); // makes zonelist_update_seq.seqcount even > > } > > > > This deadlock scenario can be easily eliminated by not calling > > read_seqbegin(&zonelist_update_seq) from !__GFP_DIRECT_RECLAIM allocation > > requests, for retry is applicable to only __GFP_DIRECT_RECLAIM allocation > > requests. But Michal Hocko does not know whether we should go with this > > approach. > > It would have been more useful to explain why that is not preferred or > desirable. > It would have undesirable side-effects. !__GFP_DIRECT_RECLAIM does not mean that the caller is happening from interrupt context or is a re-entrant allocation request from IRQ context. Special casing __GFP_DIRECT_RECLAIM could allow a speculative allocation to simply prematurely fail due to memory hotplug. This deadlock could be mitigated by not calling read_seqbegin(&zonelist_update_seq) from !__GFP_DIRECT_RECLAIM allocation request but it has undesirable consequences. !GFP_DIRECT_RECLAIM applies to allocations other than atomic allocations from interrupt context such as GFP_NOWAIT allocations. These type of allocations could prematurely fail due to a memory hotplug race or cpuset update and while this is probably harmless and recoverable, it's undesirable and unnecessary to fix the deadlock. I imagine there could also be checks for callers from IRQ context but on some older chips, checking if IRQs are disabled is expensive so also is an undesirable fix. Maybe the same is true for newer CPUs, but I didn't check. The printk_deferred option seems the most harmless option for now and maybe printk_deferred will ultimately go away. Other than potential changelog updates Acked-by: Mel Gorman -- Mel Gorman SUSE Labs