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 78094EB64DC for ; Wed, 21 Jun 2023 14:09:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 03BFD8D0003; Wed, 21 Jun 2023 10:09:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2E348D0002; Wed, 21 Jun 2023 10:09:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF56B8D0003; Wed, 21 Jun 2023 10:09:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CDD468D0002 for ; Wed, 21 Jun 2023 10:09:17 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 711BE1C8427 for ; Wed, 21 Jun 2023 14:09:17 +0000 (UTC) X-FDA: 80926937154.11.FFCAD7B Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf03.hostedemail.com (Postfix) with ESMTP id 9C16620178 for ; Wed, 21 Jun 2023 14:07:58 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; spf=none (imf03.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=1687356479; a=rsa-sha256; cv=none; b=dKu2LvVfgqMb3MKWIMgLeDN1TYJmDf0Mi67/pDCHWmoqKBZX1sXTEyuui8TBkU/aHsD26w OE7B6Bt3JpjiAEjWh3fTFcMvAikIcDZ95PHoKP90vqOPAfHXbGJ3QuolzXcitQuTE5qN6s LsBiGhKU7pjX4lv5rGaAqprkHrKxfrQ= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; spf=none (imf03.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=1687356479; 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=RSMQ3lxQasolpoKNN11oNzx11rJvmxMmW9tHIGaOx6E=; b=ckL17uflM1xaiODYjjtpTJaaatBkUURkamiXDLNZorsE/ui1nRvpkOQZiDJ6YHIfgqAKyt IYTSR4xhFdVkppDFZbLCuwQ4NyIykhYIQx7Vhhih5U+z+FlurIW0yg/+QxCRGOD3kotei2 qfWoSr6vzbpIEX/akrnEW6m/3sS9lWE= Received: from fsav313.sakura.ne.jp (fsav313.sakura.ne.jp [153.120.85.144]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 35LE79i6080261; Wed, 21 Jun 2023 23:07:09 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav313.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav313.sakura.ne.jp); Wed, 21 Jun 2023 23:07:09 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav313.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 35LE785S080258 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jun 2023 23:07:09 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <34aab39f-10c0-bb72-832b-d44a8ef96c2e@I-love.SAKURA.ne.jp> Date: Wed, 21 Jun 2023 23:07:07 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v3] lib/stackdepot: fix gfp flags manipulation in __stack_depot_save() Content-Language: en-US To: Alexander Potapenko Cc: Andrew Morton , "Huang, Ying" , syzbot , syzkaller-bugs@googlegroups.com, Mel Gorman , Vlastimil Babka , Andrey Konovalov , Dmitry Vyukov , Andrey Ryabinin , Vincenzo Frascino , Marco Elver , kasan-dev , linux-mm References: <000000000000cef3a005fc1bcc80@google.com> <656cb4f5-998b-c8d7-3c61-c2d37aa90f9a@I-love.SAKURA.ne.jp> <87353gx7wd.fsf@yhuang6-desk2.ccr.corp.intel.com> <20230609153124.11905393c03660369f4f5997@linux-foundation.org> <19d6c965-a9cf-16a5-6537-a02823d67c0a@I-love.SAKURA.ne.jp> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 9C16620178 X-Stat-Signature: 7wu9gdgnk8ia7w983fidmrxfbsnhhgm7 X-HE-Tag: 1687356478-687029 X-HE-Meta: U2FsdGVkX1/LTrOMhcSREkFas+SCf89iGUt/FrXK/Pf1VYtxl7Hj4tNSZeB7nhmQ7IGtS2FavIwlbjdcDfn0bzeqTd6lEIIjUMwXHatQUYVyROD+F9+rOaVV66YX1VqrzKG0BZQ0h8L5VVsToxA0GBCRS2dvSAZYqW6DIxFvaLV+GjbU+NwNWwCSdVH7SKjlTQHPvfEzfzyVz5J6TGxxQQ79GkfUpIyPX0pNmNMhXyPMSpSAgH1zzxLfrvsq/HZnIkdvvbk7xgQpYu7yMuoWYdV+FnVbnTOMBA3Pzmawo50Wu8ry3vACVg9QuWH/bOjX5dzYBWdIv8Al4RfnGFJjRnRaMStREg/LpG+lB4DNI2fxRSXkreUaUe39zGNCmrt86vO7UAgifOUYJgQXgV02I1qOQE6MXSdBI+8t1gff6//IBZxGDCgzAJD4QM57tCf5BazLyQ8KqfqB2nLpF6/ers9I7N1Gv7ZWNnm2EZ6WpqvV7a2KhM3ErWaIazDVsdlCu+FY48uYTZkpeIORdv0+wX4i6gbGl/ot3mWIGDdeeIsxRhCBjIhs5yM3qq4uPGRhwH5rYrXvbUvnBjnhEaW0GctFjYS4cDYutQ06ZfCB+Xpa7V6SPrDHCCk07UOkU/nXQFrSNzIk2xq6F6Dxwu2jWtwsdPfUCe4bM8iSWpu3bqy0ZDK8NZ9eU+VM775TzB9XaoS3WOYcmZu+lbWCDYyTz9vtFngTob8V47Jp2KwVYhOLLSxsEHuyc9M5CdRYiCQj6fFizGQAwHON0GWBoLrYKv7qCD0hG3v8foRAu9orKESPauqGvkGobGrMKfjtJJYAoRlG2gUKiZYMucFgNKGRpCDvIfJONrE65Hu8X5Hisuu6uCWNb9BBY8vxVcgDWhx8hnbHDMk10f5DOOxKJ/9berBd3YyktOesFSPUVG49pWpmyCTZwSaCRJ+cegYeyuwFANwAozS7wEGYRG1qlwq lZINMKfG 3PY8j60S4pnh0sr+oj/erRxcRgHQStIimIbtg1eq02O/wa2ril0CqRRCJE6HLECJFofiwRp92STLGmfXN6/1P9FwhwLcH1egMV1+cDbYYt+ANpIo07frvnZFdCcugjJTnV6f9AYf7jaB+i9SdDWRn/KrOSYT6FxcTIm6Ihnag+aHDVYxdE9IEJcOdMG/wqOp+ZBG1Z6jagIIZCRSRx9MqVpO+iam3FdWD8Tg90LPr0NbCWVDPqrHcHD4pkqXjutlrdXtJGctN8gB6x5AQESUlDQHD8pbTa+rzi+ulWVRX0kLVc7JOVzfbtJ4oV2NDHbru5CBgalKDozFsRnNAsIGoKG+q8StuAa25WjCNJnmABLKqiFc= 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/06/21 21:56, Alexander Potapenko wrote: >> But why is __stack_depot_save() >> trying to mask gfp flags supplied by the caller? >> >> I guess that __stack_depot_save() tried to be as robust as possible. But >> __stack_depot_save() is a debugging function where all callers have to >> be able to survive allocation failures. > > This, but also the allocation should not deadlock. > E.g. KMSAN can call __stack_depot_save() from almost any function in > the kernel, so we'd better avoid heavyweight memory reclaiming, > because that in turn may call __stack_depot_save() again. Then, isn't "[PATCH] kasan,kmsan: remove __GFP_KSWAPD_RECLAIM usage from kasan/kmsan" the better fix? >> Allocation for order-2 might stall if GFP_NOFS or GFP_NOIO is supplied >> by the caller, despite the caller might have passed GFP_NOFS or GFP_NOIO >> for doing order-0 allocation. > > What if the caller passed GFP_NOFS to avoid calling back into FS, and > discarding that flag would result in a recursion? > Same for GFP_NOIO. Excuse me, but "alloc_flags &= ~__GFP_NOFAIL;" will not discard flags in GFP_NOFS / GFP_NOIO ? >> Generally speaking, I feel that doing order-2 allocation from >> __stack_depot_save() with gfp flags supplied by the caller is an >> unexpected behavior for the callers. We might want to use only order-0 >> allocation, and/or stop using gfp flags supplied by the caller... > > Right now stackdepot allows the following list of flags: __GFP_HIGH, > __GFP_KSWAPD_RECLAIM, __GFP_DIRECT_RECLAIM, __GFP_IO, __GFP_FS. > We could restrict it further to __GFP_HIGH | __GFP_DIRECT_RECLAIM to > be on the safe side - plus allow __GFP_NORETRY and > __GFP_RETRY_MAYFAIL. I feel that making such change is killing more than needed; there is no need to discard __GFP_KSWAPD_RECLAIM when GFP_KERNEL is given. "[PATCH] kasan,kmsan: remove __GFP_KSWAPD_RECLAIM usage from kasan/kmsan" looks the better.