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 A0908C433EF for ; Wed, 25 May 2022 17:41:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F85C8D0003; Wed, 25 May 2022 13:41:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A6458D0002; Wed, 25 May 2022 13:41:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 091B18D0003; Wed, 25 May 2022 13:41:21 -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 F03488D0002 for ; Wed, 25 May 2022 13:41:20 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1772621127 for ; Wed, 25 May 2022 17:41:20 +0000 (UTC) X-FDA: 79504981920.06.FBF4CBF Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) by imf17.hostedemail.com (Postfix) with ESMTP id 714A140034 for ; Wed, 25 May 2022 17:40:49 +0000 (UTC) Received: by mail-il1-f180.google.com with SMTP id o16so14332952ilq.8 for ; Wed, 25 May 2022 10:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SHh+F5QjRRXvKKbUW3PJK5nDgnCrKXzAfsKecyJT+o4=; b=pemBLclirhwOK3RceXO5cnwknIfCOBX5vQBaJIWMYH5/G/phTTJWpWmE8k+J+uwvuS NHzaIhE3eKdzwhEH76ESN5IPai/icdvOQT7ywxfjp8kCclxcT2llThK2sgJ1CLqO1zMz AxvMGiS62aqJ5ZBkUCCe2y5/PfRpi1/5tzKJixHb8HaYlSwqvO4ptnrQ/qcLH9nmTx1O E5L4WJypr1/JD9W45VnZdlLNL+j4tQQDdjaeetx6K8jo+F6njg4dX+iWN27/wrmObQ3Y V/uuSF3Fa9S+EMUJHIj+gv02/OoKe/DTEqnqNYYEL79Az3iI5hVMdX5ythNH3AhX3hJM JNJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SHh+F5QjRRXvKKbUW3PJK5nDgnCrKXzAfsKecyJT+o4=; b=PKUgZRA/600KdQQvMi9QJBuHHzxIq9owXZuL36fs5C8dSrlx2k9ezs5FM3iRzjzaHM qxthEHv7Rb9JkshZ50pA2R0js/HorBJoH7QHTV7vsmULEK6ru2KsHhVQaqR3nDjH93XW EhuGaaplb9GHsmgnOh1ztGxhO6o1TrjWx/SNK+IdI7yvOx+1ELAMt99w1/lc/xOvk+gG fPzL7wqkqiYS8yKnREIBva8xrwtim/SUp/5Mnt3uTTUAlqfXiJU+sztg+a1kNRd9MGZa Dk+9chsrRSq49YV7czUbfj3Ss4cTXq8B965e/9rp+BZ0McGc3+3RuLiSTKlews9Jw3wx 40dg== X-Gm-Message-State: AOAM532NixSlHzRd54qR0vhjhrsL/RQpDZeL9ZDkYMwD50jy+ET1mWKT EXLXQTtd6K8teW5fBPnhUnXqQpXarHFZykSwe0s= X-Google-Smtp-Source: ABdhPJz4tJusgewGhFkdLC90PBkVQkJovEKoNwcJbBEY80P3wt+me7BMYEj+6LljIf2ccj6+LwdHrcEVmtAcXXAWZKQ= X-Received: by 2002:a05:6e02:1be2:b0:2d1:5818:a454 with SMTP id y2-20020a056e021be200b002d15818a454mr18031573ilv.248.1653500478886; Wed, 25 May 2022 10:41:18 -0700 (PDT) MIME-Version: 1.0 References: <20220517180945.756303-1-catalin.marinas@arm.com> In-Reply-To: From: Andrey Konovalov Date: Wed, 25 May 2022 19:41:08 +0200 Message-ID: Subject: Re: [PATCH 0/3] kasan: Fix ordering between MTE tag colouring and page->flags To: Catalin Marinas Cc: Andrey Ryabinin , Will Deacon , Vincenzo Frascino , Peter Collingbourne , kasan-dev , Linux Memory Management List , Linux ARM Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: by4peprctmeqh6ppi19eerbd6bqjcqzy X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=pemBLcli; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.166.180 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 714A140034 X-HE-Tag: 1653500449-739934 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, May 25, 2022 at 5:45 PM Catalin Marinas wrote: > > > Does this have to be GFP_USER? Can we add new flags to > > GFP_HIGHUSER_MOVABLE instead? > > > > For instance, Peter added __GFP_SKIP_KASAN_POISON to > > GFP_HIGHUSER_MOVABLE in c275c5c6d50a0. > > The above commit was a performance improvement. Here we need to address > the correctness. However, looking through the GFP_USER cases, I don't > think any of them is at risk of ending up in user space with PROT_MTE. > There are places where GFP_USER is passed to kmalloc() for in-kernel > objects that would never be mapped to user, though the new gfp flag > won't be taken into account. Yeah, those kmalloc()'s look suspicious. > I'm ok to move the new flag to the GFP_HIGHUSER_MOVABLE but probably > still keep a page_kasan_tag_reset() on the set_pte_at() path together > with a WARN_ON_ONCE() if we miss anything. GFP_HIGHUSER_MOVABLE is used in fewer places than GFP_USER, so if it works - great! However, see below. > > Adding __GFP_SKIP_KASAN_UNPOISON makes sense, but we still need to > > reset the tag in page->flags. > > My thought was to reset the tag in page->flags based on 'unpoison' > alone without any extra flags. We use this flag for vmalloc() pages but > it seems we don't reset the page tags (as we do via > kasan_poison_slab()). I just realized that we already have __GFP_ZEROTAGS that initializes both in-memory and page->flags tags. Currently only used for user pages allocated via alloc_zeroed_user_highpage_movable(). Perhaps we can add this flag to GFP_HIGHUSER_MOVABLE? We'll also need to change the behavior of __GFP_ZEROTAGS to work even when GFP_ZERO is not set, but this doesn't seem to be a problem. And, at this point, we can probably combine __GFP_ZEROTAGS with __GFP_SKIP_KASAN_POISON, as they both would target user pages. Does this make sense?