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 64EACC7EE23 for ; Mon, 22 May 2023 02:14:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 029816B0075; Sun, 21 May 2023 22:14:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F1C18280001; Sun, 21 May 2023 22:14:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE40D900003; Sun, 21 May 2023 22:14:47 -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 D09526B0075 for ; Sun, 21 May 2023 22:14:47 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A4B74120389 for ; Mon, 22 May 2023 02:14:47 +0000 (UTC) X-FDA: 80816272614.05.53D94C1 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf04.hostedemail.com (Postfix) with ESMTP id 3D1B540002 for ; Mon, 22 May 2023 02:14:44 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=hE912IBC; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf04.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684721685; a=rsa-sha256; cv=none; b=korXtxA0ukvn+cd/Lx1aLUwdbIBjwtvhvDsXxzkJxEr2N1xa04dLzHONRd7pvEE49wQONS Y5DaaTPBnl0VYkvvX6wRMwcYyI2bcnn+4pXcAuoXcF9jAgC4KUk+TyjJqLvZhw8hJ3LoOm jZK+FdzYe0LK9TnX1p9ulaa8jih35CU= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=hE912IBC; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf04.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684721685; 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=We3jTxvIVde71cTLw2VX8M1hrldlnhZiWJe07joqnEc=; b=RJLF+UlWUWtmQYVjBiM8bPjER57Hl8bkiPPU/SFtT8oLfYxt//LGYQ81ItFvxyiT15ilJj XBwZShqdiqYCbwqv80WSLbFGGkq2sViz6TRNevgZLkL18IZJ9ts7UeEFQavLR49QyV4Sj8 TgIzKdS5mEFgjRQp4uPptRhiheHl3e4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684721684; x=1716257684; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=iLaLGiScCv0Sza/apk8NwHqop/0p87h6vymCiZTDuQA=; b=hE912IBCYlMXWAvUGIAWA/Lyhd+dxkixBvdpQUiFjVwFHoi8qeKvtOoZ IQiDE3YApbzj5vr1s1E8z7Xgk38rEXRfnsJ7dZSWieM8P+HxHDMZ1E8EI 5yi4D71DzgFfdhs3JKC6uG3ECBF1AQ6hI/ApyDNwCPnEP9Aw0ByMCAP4+ kchkIZcGe30tkBcynVEDQekF1lffdhxRZQGEcCfQPTM7ggoJ9TPegHfzQ TfUOPC5hyWNTGTMBWOSnsk9aXww8LIpVax/WVdWScKGK0DDiVF+tEU9sG Z/8dtyluMEpex+uGN11etyWSVHvI8MrvcEeJt9q9kH9qt8itCDPQyLI6M g==; X-IronPort-AV: E=McAfee;i="6600,9927,10717"; a="351654949" X-IronPort-AV: E=Sophos;i="6.00,183,1681196400"; d="scan'208";a="351654949" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2023 19:14:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10717"; a="1033427960" X-IronPort-AV: E=Sophos;i="6.00,183,1681196400"; d="scan'208";a="1033427960" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2023 19:14:39 -0700 From: "Huang, Ying" To: Tetsuo Handa Cc: syzbot , , Mel Gorman , Vlastimil Babka , Andrew Morton , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Andrey Ryabinin , kasan-dev , linux-mm , Johannes Weiner Subject: Re: [PATCH] lib/stackdepot: stackdepot: don't use __GFP_KSWAPD_RECLAIM from __stack_depot_save() if atomic context References: <000000000000cef3a005fc1bcc80@google.com> <48a6a627-183d-6331-0d8d-ae4b1d4b0101@I-love.SAKURA.ne.jp> <9c44eba9-5979-ee78-c9c8-626edc00f975@I-love.SAKURA.ne.jp> Date: Mon, 22 May 2023 10:13:36 +0800 In-Reply-To: <9c44eba9-5979-ee78-c9c8-626edc00f975@I-love.SAKURA.ne.jp> (Tetsuo Handa's message of "Sun, 21 May 2023 07:44:20 +0900") Message-ID: <87edn92jvz.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3D1B540002 X-Stat-Signature: 9ub5bf6g9r6s7fj3xejst8eqz9soi37k X-HE-Tag: 1684721684-2315 X-HE-Meta: U2FsdGVkX1/k/4o5t+T+msHaoq33xbmnLXO/ydp6nyV7ISSXmuoeeAtupeVuZdftrhMUKL8MRtaR+tTQu6FSN6wP6+WBtjMbXLdhk6ZB1COAbKcsd6xso7E1ozeOwZUBCCi9UCQ5zbq4XQg5HKTBek6RJnSia2DM9KuzPLFUvuZgISuQuGQazJ9hg0LXJit50mYbdc/DSm8eRbkg1SYGIFTxrQBA3bsuEHFWx7NJCb5cTayzALHgA46EJ6MK7B61UDRbRFJljc99Z/F2ioYWJyRSHdjrJn6C7FyWvLOgscJbvfEhxuKFyQ5UBLkscv+T7a/gssXac0dJmPvne3ZRaYJEPD9jjSnrpBhrVXZGpSDeUhEbajYL+CW5XtGG7e5V6uamqWVf+kBCvTDhZPfqixDXVI7nEdHugxdfolL2aES2Do1fljWeBNk3RlQTfrTfcfRhZC4FKt35iTSG/o9rShP2D0lDVsTgSf4BgZDc/MleW7daFM6X5wkJylvMDJgRcgXscv6/hpSFMe5uZMBEcDN467qMOeTB5eVps6V7wlNkcqTxlGaWEelUeYmvHUSfvhjllUIfvUKMTpSZUeaoiPrcuWBTG/V1qgBVUhP6MHvHlR6mUS3KjDZGWJopaM/YfVL2HGhu5+EjDn2u1PgnmRiV5F7IgvpT1ACprJdMyhom7ARZ0YiXLw7qJ/Y2oTyrTmXOFlLQHw+cyRJpeTh4iwlsYtAPFgI7qY4ULuOpIM3gZWG0JidPuvz8245hzJOAvs4CvH5wAD44Y0A/4w2XhZYUbUq/HPzTztpw6k2vAFYBLcuIM44cH8J3tU6ORoxSXlP/S/VvVOOITrPWsnCQe3apzmFs5TcIEIWEd7HbDQEiQqEly7YwdTmOLtb1PnRXwKs+pOLQVyOTzR6ku3Yf1okpvmonHbLpaV7xtfduiwWcZ0ocIdXNBxz0qOQr7tiFf4RnpBhhqFvV2qSL9QA PqkQb3aX rPJCMeZgxGFjFP8f31ix1wq4hN8ZBuhBOKYIULsJLcjH8OI2Ip8hSzRzG2GkDCoyEK5c5ST9vAJCNuuHuqvOz2tBM2laUlLzYByr8FScWQ1MZOJAfXUwYmo/0/n+tRHAN+fyTJ/B4IqPTomrs6P+2ohRw7tUo9Sbchr/oPn4kuB76sl3Lhb2N4UA24qwTiqTHvCiLikS0suIukpz/5c38VtiSwzttTtlhUABKapkZry3VS9+Ta8punFAUx/bGL+9MSo44C3PQUNMX5G2swOhsuGrcE1Gnvf5H9BTajZpuYWeO1/+1RRp58eELAe66B+9Zxza7mFe0rN04d/IOelsLqBUevsMsYbzwrIwQ 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: Tetsuo Handa writes: > On 2023/05/20 22:14, Tetsuo Handa wrote: >> On 2023/05/20 20:33, Tetsuo Handa wrote: >>> @@ -405,7 +405,10 @@ depot_stack_handle_t __stack_depot_save(unsigned long *entries, >>> * contexts and I/O. >>> */ >>> alloc_flags &= ~GFP_ZONEMASK; >>> - alloc_flags &= (GFP_ATOMIC | GFP_KERNEL); >>> + if (!(alloc_flags & __GFP_DIRECT_RECLAIM)) >>> + alloc_flags &= __GFP_HIGH; >>> + else >>> + alloc_flags &= GFP_KERNEL; >>> alloc_flags |= __GFP_NOWARN; >> >> Well, comparing with a report which reached __stack_depot_save() via fill_pool() >> ( https://syzkaller.appspot.com/bug?extid=358bb3e221c762a1adbb ), I feel that >> above lines might be bogus. >> >> Maybe we want to enable __GFP_HIGH even if alloc_flags == GFP_NOWAIT because >> fill_pool() uses __GFPHIGH | __GFP_NOWARN regardless of the caller's context. >> Then, these lines could be simplified like below. >> >> if (!(alloc_flags & __GFP_DIRECT_RECLAIM)) >> alloc_flags = __GFP_HIGH | __GFP_NOWARN; >> else >> alloc_flags = (alloc_flags & GFP_KERNEL) | __GFP_NOWARN; >> >> How is the importance of memory allocation in __stack_depot_save() ? >> If allocation failure is welcome, maybe we should not trigger OOM killer >> by clearing __GFP_NORETRY when alloc_flags contained __GFP_FS ... >> >>> page = alloc_pages(alloc_flags, DEPOT_POOL_ORDER); >>> if (page) >> > > Well, since stackdepot itself simply use GFP flags supplied by kasan, > this should be considered as a kasan's problem? > > __kasan_record_aux_stack() { > alloc_meta->aux_stack[0] = kasan_save_stack(GFP_NOWAIT, can_alloc); // May deadlock due to including __GFP_KSWAPD_RECLAIM bit. > } > > Any atomic allocation used by KASAN needs to drop __GFP_KSWAPD_RECLAIM bit. > Where do we want to drop this bit (in the caller side, or in the callee side)? Yes. I think we should fix the KASAN. Maybe define a new GFP_XXX (instead of GFP_ATOMIC) for debug code? The debug code may be called at almost arbitrary places, and wakeup_kswap() isn't safe to be called in some situations. BTW: I still think that it's better to show the circular lock order in the patch description. I know the information is in syzkaller report. It will make reader's life easier if the patch description is self-contained. Best Regards, Huang, Ying