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 32C3FEB64D7 for ; Wed, 21 Jun 2023 14:43:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BEFC88D0003; Wed, 21 Jun 2023 10:43:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B53BE8D0002; Wed, 21 Jun 2023 10:43:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F2F58D0003; Wed, 21 Jun 2023 10:43:10 -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 871E48D0002 for ; Wed, 21 Jun 2023 10:43:10 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4095E160520 for ; Wed, 21 Jun 2023 14:43:10 +0000 (UTC) X-FDA: 80927022540.20.FF6220A Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by imf25.hostedemail.com (Postfix) with ESMTP id 65F1EA001B for ; Wed, 21 Jun 2023 14:43:08 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=jtApsSkZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of glider@google.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=glider@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687358588; 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:dkim-signature; bh=YUu7+2/X84Xh+mwVKsmAtu1KtwVmCcdcD5w3fkw4k3M=; b=oduxx89rqRsFkjML5chzZtPpj2gJT1UB0XtOnkV60aH01u1bS/HOb9oz1Ruhs4YVabgAe+ TzQgTJihorYCteoy/H01hQjmZbRvoX8wvMXnqpI6JcxA/wfZQSAadhEYdWLOWGkhH+IIXv gxuO7e3qTbtIQDd14AHEe+6SmJHFtt4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=jtApsSkZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of glider@google.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=glider@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687358588; a=rsa-sha256; cv=none; b=z1VwdN0o6pHVNUbIMtf8Zq0oPOAE7hPL2asewSA9UhJmEnqR3dR6pT3X+XXmI0xu6XyNkn TrYTV1lDwYI/VKGAfM+AZb4VIt4p/AZWs00BNXQZMCW+8f17/Gtx4I1oZHRnDUqF4GD3RM 00j4mx/sbomH8foANXfepM7i1xKp5MM= Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-77e3f25446bso93134039f.1 for ; Wed, 21 Jun 2023 07:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687358587; x=1689950587; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YUu7+2/X84Xh+mwVKsmAtu1KtwVmCcdcD5w3fkw4k3M=; b=jtApsSkZuQmxXze0t0VMT0TlYcf+rRqosXiDhZ819vJAnlcwoBr3vrAT7SbGNFg8ft 3LkPUU+KyrQVyefNYXuAYzP6vkDJ9UtY5jqgbCBpwY7yuhjkHo3CD9MLM+vHwNRl18jR yqKRYsHuGkI82h+GELTtlLOKpEaGsPLSdCBrrANCCjaMuoFFY25GimxuutYzJs2IbSgH 2pD7vsIojZ/hCYotqdNl0kN+e/US8O5eB6+rBmnHc22Oudd8iQkISOCy23K/hO3ksYhS p4TXrsPwvXMgFKbd48xnS3bPfbPjeWCtXcEHvq/oOPQRtjlFyqtwf6cX1VmwUYYsLlh2 MRkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687358587; x=1689950587; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YUu7+2/X84Xh+mwVKsmAtu1KtwVmCcdcD5w3fkw4k3M=; b=L4LawsgUmyfFRgworqgoU+uTO7gQAHvDD20fP+QdWJ5CHL0iAwwdy8KpuS3imkQd4x D8XPVw5eQgzk6V9Y/gZgU1MGpVgOmz3MQ70Pesfe1fYGtBb2mryzgdTFM/j966UuEr3M Avdna+vpDGIBHN+P4ud63da3xBZIB+GbNqfImpweAqTWFerFXrQ40j34qCrnjHFwdHX1 GIckLMLrTGDzQpxUNC0+Zs+Y3LDJOJTjjkqzT2ax6drFBwqOsYwBq828SMr5WOysd7CN FFJC4d5j03bMImmY6qu/pdb871PC+nXi29RJDtAbQj/K7ZjnKIYtLvqJ9gINUZs9yUvb qIhg== X-Gm-Message-State: AC+VfDwBONs7knY9I+tSVsj/p1HkFHL6kCTGbgn7RKFKIIJMKSiDYLLM CFO/ir8fXrtemOQSRdAh1kKxb++GdnnaSsczfzTKOA== X-Google-Smtp-Source: ACHHUZ6niVe8ZQtp2BhY3xjyTIsDkWWA1NMc0UYYS22wLXvO5Ek1hf66k0tEADz5eGSDfyUy+xmsGhdivyWve26K4SE= X-Received: by 2002:a05:6602:218a:b0:77d:b45f:ee2d with SMTP id b10-20020a056602218a00b0077db45fee2dmr10009832iob.0.1687358587111; Wed, 21 Jun 2023 07:43:07 -0700 (PDT) MIME-Version: 1.0 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> <34aab39f-10c0-bb72-832b-d44a8ef96c2e@I-love.SAKURA.ne.jp> In-Reply-To: <34aab39f-10c0-bb72-832b-d44a8ef96c2e@I-love.SAKURA.ne.jp> From: Alexander Potapenko Date: Wed, 21 Jun 2023 16:42:30 +0200 Message-ID: Subject: Re: [PATCH v3] lib/stackdepot: fix gfp flags manipulation in __stack_depot_save() To: Tetsuo Handa 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: ri65fo4mmnahbtanucb9ndfg4ejqso8y X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 65F1EA001B X-HE-Tag: 1687358588-53676 X-HE-Meta: U2FsdGVkX1+4gBpUL/eY4z4eBeeQuOQMmVmX9mqOMUxlOyUnjNX3N+hF9djczl4+SK8HpWG4mzdsHem2zZJmkjIOs+JEmr4Xvdtokx1NOwnUYhrvVOjuqdqgI0D7Qa0VSMddlWqtZgdg4qzPDiU9/MHGUG7PsO+OSd08ReG/VjC/WEErIGnVktfZhFaNIV5qlBbS18kLMTlMhBP1prWffZj+NS3488jYj83Ai0xoC7XZ9HjE99usUJCc9vePPXfTF48vSa2OPSwHVxQ63CTwFPMUmPESRR4+fwJa0M2w7RHP9muhUXDx8z9VgvJeRGPw6XzOZDivyHGMM6um9Z8CfisUJLRQNz8xmfZof1nOIY5X76w13f5lrdlRk1IcprildtQOwesTW7lEqtyCTxaD0ui8yR1vhejNqlxSu+mb2vadSqGJOR2vbzzSnrmmIM/rD5RG0N8g4x0ACqKAgddmzIfW3ysu37mWX5eH+EbdHUamFQzAJbSMF7LMXh7OHwKtDhLh3HicZbnKI+vxbZHSuG1nZQCLYTwhITkj/mewO/3hUQ4TwY1m6qj02bBdQScjQGigbWaH/uTb2QsN8Ps155H8yWiiF6d0wkVsjMI2qTCg27hVJuCIfZHVQJUfVhbjRazpcadh9EPTSAOKluiMmXp9s0AQVKujC/w3X2U325Ie2IwxqihmPkc+J6u40PwWyDhm+ckvs1FG4f7O6KWRj+zPLBUEGrcpeMqpP6iPvjPBFrjUKQ46GyAAlT9HJvvNfH/WOWo4x5WKsaDfAIl8agtqZ9Ie/5SE9IAb8kYBZuHnmth+yhUFtzYOzx7XHntwI9HvwcE/yh1XR58SHbUyN7F/DQb5f85QTixZL5yZr/HrOVzhHcFLN1jFwyw/FvZ3BkX0+AV6wwJJSh8bZH3dZ4NzgfIWVuTe+3w8Qg3MkdV5Rkw2qjUkkc3STlcNxjraxQzHZauYuwpoJ/3nRu6 ofYMC9E+ zEbJBd205Y7LPfblLKoE2JT349PZse5Jxhl7MiiGB7ZqldFtYSmj9DqaDb9j0gkuxR7SO7Oqn4LtzUJT+LDh0wpHGjIoUVXtJqd6FdvTc0mqPKv0MkZ4H1vwag6xpx55YVCY7tUPntVg5N/Q1NL35s5llcY1UvzBXbG67RW5LVRmL0SqC5nivMDnrejWl1+dYg4iWeQOCKY9U8Bo303G5mU2ERzgCzcXkIeWJHkTOq/xHZGvrk+ILaFBONBdQXXmwaM5N/CmMIt8xm5ABV6sYC9IP2mK//8j8AL20707mjiHPDXy1rPAhquoO59NhToRCVF8vzwdVTGgE2tc5mEy07QRx+INXH1m1xGj1Cvhzd9S6xNtJOZYT8HNeFA== 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 Wed, Jun 21, 2023 at 4:07=E2=80=AFPM Tetsuo Handa wrote: > > 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? Perhaps you are right and I shouldn't have insisted on pushing this flag down to stackdepot. If other users (e.g. page_owner) can afford invoking kswapd, then we are good to go, and new compiler-based tools can use the same flags KASAN and KMSAN do. > > >> Allocation for order-2 might stall if GFP_NOFS or GFP_NOIO is suppli= ed > >> 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 &=3D ~__GFP_NOFAIL;" will not discard flags i= n > GFP_NOFS / GFP_NOIO ? But not for the other if-clause? Anyway, I actually confused GFP_NOIO (which is technically __GFP_RECLAIM) and GFP_NOFS with __GFP_IO/__GFP_FS, thinking that there's a separate pair of GFP flags opposite to __GFP_IO and __GFP_FS. Please disregard. > > > >> 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. > I agree, let's go for it. Sorry for the trouble. --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg