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 6044EC761A6 for ; Tue, 4 Apr 2023 11:20:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF1616B0071; Tue, 4 Apr 2023 07:20:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA1E86B0072; Tue, 4 Apr 2023 07:20:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B69C96B0074; Tue, 4 Apr 2023 07:20:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A7A0A6B0071 for ; Tue, 4 Apr 2023 07:20:06 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 78366C0D54 for ; Tue, 4 Apr 2023 11:20:06 +0000 (UTC) X-FDA: 80643464412.29.9F94EEA Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf15.hostedemail.com (Postfix) with ESMTP id CD2B6A0013 for ; Tue, 4 Apr 2023 11:20:03 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=none (imf15.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=1680607204; 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=e6XFuke+JTbEnJq4r+EQ3mxQDPp6kULxrUOUBZzMFn4=; b=5Caj9xkEkNxuJKY/yPc5pWbxAwVIpROIEPAA9ay+6NXOcOWRbnkmcSk7a9ZHzzGrvYgeUY qltZlU8vPuSU7WtwOsxhzzajmYOQ3iultn7VYLhFl/1xVTpqDtPaE8tQMzI/646CxAeECT ovWiAn+/VTgDFSjNsatt5Ax8xyShHVs= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=none (imf15.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=1680607204; a=rsa-sha256; cv=none; b=FlwtI+G0dTK0SJQTsYBBDa+t6+BLMXtwkRajY/8C8uwCyiyZaWoPsr9u3WPAS5PeUgJfwX /rUMl2zyHDqV8jfdiZ/yQSw9yrqnGwDshWhZmPZQTl5TrhoFe1aoM+xFnQqYq3U7/QjI9J COiGz3RfbNogqqZFOvpOQuUg2P7fTQU= 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 334BJm5f039010; Tue, 4 Apr 2023 20:19:48 +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); Tue, 04 Apr 2023 20:19:48 +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 334BJlZL039005 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Apr 2023 20:19:48 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: Date: Tue, 4 Apr 2023 20:19:45 +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: fix potential deadlock on zonelist_update_seq seqlock Content-Language: en-US To: Michal Hocko Cc: Petr Mladek , Patrick Daly , Mel Gorman , David Hildenbrand , Andrew Morton , Sergey Senozhatsky , Steven Rostedt , John Ogness , syzkaller-bugs@googlegroups.com, =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= , syzbot , linux-mm 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> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 44tsrkmi8s45zkiimx4dynwjkb1k86u7 X-Rspam-User: X-Rspamd-Queue-Id: CD2B6A0013 X-Rspamd-Server: rspam06 X-HE-Tag: 1680607203-160868 X-HE-Meta: U2FsdGVkX1+At+30h87j6hS43Q40UB/0L0nfUY0UsX/BJcE2hrqjU5n3ngTzkRaX1MpfYnA6lm3gw4PsFi71PHtaYAJorhVwElC1CRJDpTuYwCT0U1t1Cxv2TK5LJFVVgLWxldBpeKx5mZHp5E3oczLuqCGnGMYGNYk/9RGPqsdEqNRVYk+sw8SghniKA1BZSZdpUZ6Y+wAtdIBSJLk+YdY/OtTKhXAnqStZ5wtGa69IOd6c01TTX47rbyMDGrOtlhGZ/se9lDEVWsz6+1AiXhxxRGTZKkNxL1Jqa5ra0P/gEheSTN/2efgkqY4UxYSmCpOhIHSqilUux4W02w34ZUfNXYHO8XMKFeQX5sXYhU17BzzYiZaHvn6OALi2Bs6VVovEGyoMcQToaTWcSi4Rp7+1uu1cjZfeeHc9uCSJJgtna3uXaK1PIQMyX3Y/EYWLRDGWBbOditbCwRKG3EJ0ufZXyIlHkX+DfOAQpxC42T47FMO7ma+RwBK791bVq5pLav1Jq/23dbHerEpLyDR/t/zuwovH3Fz035PG5xHgTp8uB2ry48c30rjvJSa1btDrlvhgc4OGFyG1HrFNOCYp37gUWSVARkMgisk30RRIjt65VTYOXrS+Ia/WOkzOd43BVne3jhntLcPOVQIfzqLobkxjMUNeUzA3nTRQDKpc/mE8oPYw4jTlhf8r5JhlXFOlB8b63lPpNTSYwb4waY6sksCKKaPWJCL6ewdk8nd0cZw+8mrrR3Bzy6mkmZkPQnzrPR0lOdAL3CkJtUuhNFkxCW/AbLzkCBTgsz5/QAZqur5kWBjtOqjwxfvv/pAn3XAfkNXAWN6XxS/7J3m3aK8SnOvkMaczjQgTDdktY1rCOUxLtS2oEWF/y5+MBRdBgCaclzehKA2nl4Bb5dAT3B6QZfpeShab8mU1nDoO01TCYmxL9iNnOu7fw8hgUJNV9iFKv3X3chdeAkpLKHrE9uN AlKgqT0k SeZqCQaqL/pnfAMpx/yRgYPBmYDI+htWXjCRRwOCjvIQaRyhx6+Zg142jpD5DIDKGB2L6doZ3HBxIqZD8auUDNdqcrNA/yRQcp+ntnXYOBApZgCMXgf0syCcqIKo1XGON9Ft0KZIrfJliSDt2IDcqCB5qJajq4ZP9H4JAKma6ppcWu1+Yq7vi16dAlCliNRRTRb/Tv15er1+QPPAtlPzd0SCI5ePhl6ycr2URUXlvqPuKNb1nMUnJYPI/a6ffJvtarYhFkNDHba0uD7SvREBmEqePdT8b9hA2iiI4W4CrN2849hXgztJBhosOeXvL/0FgoEP3rNPWM7gdKk00BttPmjvox9HwGQVKr62YFqUbJ6qa/xc3g0yCKWf9rGn1aSDtbLH4 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/04 20:05, Michal Hocko wrote: > But you are right that GFP_ATOMIC allocations from IRQ context are quite > common so this is a more general situation that doesn't really need to > involve TTY and some locking oddities there. Yes, that's why "[PATCH] mm/page_alloc: don't check zonelist_update_seq from atomic allocations" was proposed; I consider that zonelist_update_seq should not be checked from atomic context. From lockdep perspective, keeping locking dependency simpler is the better, even if we go with printk_deferred_enter()/printk_deferred_exit() approach.