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 B730DC7EE29 for ; Tue, 23 May 2023 00:08:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 28550900003; Mon, 22 May 2023 20:08:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2350C900002; Mon, 22 May 2023 20:08:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D601900003; Mon, 22 May 2023 20:08:59 -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 EF20E900002 for ; Mon, 22 May 2023 20:08:58 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A25A0A056E for ; Tue, 23 May 2023 00:08:58 +0000 (UTC) X-FDA: 80819584356.22.EFE5E52 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf20.hostedemail.com (Postfix) with ESMTP id 657C11C0012 for ; Tue, 23 May 2023 00:08:55 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NgnaFKBP; spf=pass (imf20.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684800536; a=rsa-sha256; cv=none; b=MG+zOHKtrVeE6VbcLUrUfImXDWUK4VF2Tczb8PELiZnzl2QgipM0hhjMeR6NUfoXlxO3Lx 6KES5S9Qon9kvswfdZg5gGQRehHWvnFVNiPfdHbBaEQu+oRunhoV0PWxPp5far4RSISO9z bYGEpHq4jTArhdYXBRe5dxOG23BpO+I= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NgnaFKBP; spf=pass (imf20.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684800536; 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=WpzNURW6NGvTWyKiQwgw/9T+89+wqu7OptNQSdR7V3Q=; b=UZteh113TY2NIEaBGqh1UDbsVZ1jfvKKQdc7MEYHjQ/UE9J840z+emv41C8FfZebWwnRle F3OReTuQ9du3pY14MMLK+kKOStxxqkyaOQgqnxrfJkebnuBbNdG+iP/2dfum98DILuo/sz jA02VibzcgT6TUDKXyT5PIU3bf82svk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684800535; x=1716336535; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=uwoU75N9OF7ta+Tpt6hBw+zrwy3jnCVLcdPZpHlsctc=; b=NgnaFKBPiEu4uIyawyZ+TLJSfUMUTJrh6azYdQKlxUDqiWd6dz3xaAo0 UrVPNCqNDHs0+PzZGzfOHtk0RptUTsABtQSFys3FA+fNhdLQEy9VtLles J6GY14wtRghVsa7SMR04+yrv7USJwUWa2Ees3XMpj7RV9IWE0FqExnwRH 7mPMVWtDrv5/391FQ+y0HM3hcbfi39NMC6zNrNgMTR6B/aejfPi7kLM71 JRk6ErHHMGWrvG1Ew9blEjcq8a0UOSpXST2eBtB9GSWh/iwb3udi16Un5 OwAhPrN91TZogtTRd/kO40eNVOrqob/lwGmXCOEm/VdWUS+/nKGCRfSjU g==; X-IronPort-AV: E=McAfee;i="6600,9927,10718"; a="355427849" X-IronPort-AV: E=Sophos;i="6.00,184,1681196400"; d="scan'208";a="355427849" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 May 2023 17:08:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10718"; a="734534410" X-IronPort-AV: E=Sophos;i="6.00,184,1681196400"; d="scan'208";a="734534410" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 May 2023 17:08:50 -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 , Michal Hocko 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> <87edn92jvz.fsf@yhuang6-desk2.ccr.corp.intel.com> <0471c62b-7047-050a-14f5-f47dfaffaba7@I-love.SAKURA.ne.jp> <87a5xx2hdk.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Tue, 23 May 2023 08:07:40 +0800 In-Reply-To: (Tetsuo Handa's message of "Mon, 22 May 2023 20:33:49 +0900") Message-ID: <871qj7zz8z.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-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 657C11C0012 X-Stat-Signature: b7fquwsy3ymyxyocmux96icb53wnqdgc X-Rspam-User: X-HE-Tag: 1684800535-384418 X-HE-Meta: U2FsdGVkX1+EIF9cyeVKvCXPERKtMt2sVtXChmOVIkxemD52qnrBgN/FnJxczgRgSfMXibxaJWhCm0V1v6cE+mYtdAZvJuIz1Ml3OD49JimxbipPBeSnpzXt2IlCvNMn1c6L+CadckYMewNO7f9Kf2whCGbzUtAMtcjrlfTEOapWcpA/bTX35arAAq5f1gXYQVyy16COo1fx2tWXzdbiD6CZ56LluCWIG8bDRrHgY3j6XCdnf+W/3qUACFdlkWUEr4u3hSvW+GT9Aq1tm4ApTmzpatzv8X9Xg2ZU0sBi6GHDriNe4fwVwkhdNIEoNKAinRZW+m43+HgBP8wjNOKFv78Q2mRGf6KWutAEiVFF1kbOiys2qeQRVIByiaGndH7lZYDQOUu3KexLkCb85QKKwkKbisM0lkOaY/b5aM6+0ZdAs2bXKaH9vQx8VYNIrVzi/i+jnEOwm8ixbfh3AdY9v39kT/Ke9crFsxirGNg15nV8o/ene3ez44p4eqPNf0pa05jou/DNBVk+loQzPmlp9XuuSbLZKeLO+aoitmjRwDkgqtOdHxlAvQsTKIeIWik033ANN29JpPVx+TqiYVdo9fj9qe2y4Bpwk6DWSWicMMhXy6zoVbZkOumC2sfEXN3yBfgEaH7Ei6C4q2HbLgXc4l720oi+x8T156j9Y7D38Qog94c1fYm8aUOaBP7yBH5LTWxvF2evXzZDGcN2jtl4qIUiEC71YiSHaTucmAgzr9PjvQYfA+uO2mqn/etn/ec9oYrnHNttHZ9ngHdrvK/CNmLH1CW3IOLTY3gmFOheiW3CQRijIyo7Jj4gv0PunYB3r5fdrYsPGB8ScF0S+lSed8Fbz/xE+OW7e4wOc4XiKEHIXaC1eU9tcwJ4yCvp3cDIuR7F5Fut6XpN/r0X6Qvi5lLJoO26C7bgBweqLhxU+QxSUrM3gFTpbI0BioFEvrthjrtW3je1Jn0HHZdqB7k 4p/XsLIO +fYzFk7NsJk9b+1XHOJ2crsBRaGUPaVgXx7BOwTRY9knKM9/t6VqujRnnYUsOh7EkZHuzS/Um29LgmJ5FN/CBuOPNiaIhYDuiAp5akBdr+8Q51bPlrj0nIfKdOAyyV0w9xolk2warg5ZXHKTr4PmLCz/BxOtxU4jBI+P4ulutEb1fOQG78Stko/P+S9s4QJuppdUwWfRQJcJY49XhtJFDSoXfAStLVK9buxjT8qRiNto7ADRsoW9U463WpV5DWJHs5VsXM7tib0EvSfwNxVRqCxyIG6AVc+AQNFdAvL6pIFaSpjiX+12Dnk4MkBREtBcS+QgS7zSeERxSx8bwRCd6qyBGohXwzydIcpWD 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/22 12:07, Huang, Ying wrote: >> Tetsuo Handa writes: >> >>> On 2023/05/22 11:13, Huang, Ying wrote: >>>>> 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. >>> >>> What do you think about removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC and GFP_NOWAIT? >>> Recent reports indicate that atomic allocations (GFP_ATOMIC and GFP_NOWAIT) are not safe >>> enough to think "atomic". They just don't do direct reclaim, but they do take spinlocks. >>> Removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC and GFP_NOWAIT simplifies locking dependency and >>> reduces latency of atomic allocations (which is important when called from "atomic" context). >>> I consider that memory allocations which do not do direct reclaim should be geared towards >>> less locking dependency. >> >> Except debug code, where do you find locking issues for waking up kswapd? > > I'm not aware of lockdep reports except debug code. > > But due to too many locking dependency, lockdep gives up tracking all dependency (e.g. > > https://syzkaller.appspot.com/bug?extid=8a249628ae32ea7de3a2 > https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f > https://syzkaller.appspot.com/bug?extid=9bbbacfbf1e04d5221f7 > https://syzkaller.appspot.com/bug?extid=b04c9ffbbd2f303d00d9 > > ). I want to reduce locking patterns where possible. pgdat->{kswapd,kcompactd}_wait.lock > and zonelist_update_seq are candidates which need not to be held from interrupt context. Why is it not safe to wake up kswapd/kcompactd from interrupt context? Best Regards, Huang, Ying