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 61A2AD637C9 for ; Wed, 13 Nov 2024 21:24:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F12546B0085; Wed, 13 Nov 2024 16:24:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E9BA26B0089; Wed, 13 Nov 2024 16:24:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D15396B008C; Wed, 13 Nov 2024 16:24:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id ACF286B0085 for ; Wed, 13 Nov 2024 16:24:31 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2CF8EC0647 for ; Wed, 13 Nov 2024 21:24:31 +0000 (UTC) X-FDA: 82782348516.07.4EC06B5 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf04.hostedemail.com (Postfix) with ESMTP id 572124001B for ; Wed, 13 Nov 2024 21:23:34 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0g6rB7x0; spf=pass (imf04.hostedemail.com: domain of jannh@google.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731532875; 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=WALPwj00gB0ma8t1qi9YCWEzgMiAXx66M8d65obtXCQ=; b=fVlWjJwL4n3y7Ta5CQko51+xJ/lgR6yx44Nx5TLvibTSqb4GZ5JcQfp+AWXEAjtnqxL+2g uU4j6XzT/5GRJtq/H1hTstgqp5muuuj6TVWSHPVwMACFR9pTDNv7h0+udERKGNLGR9kENf Pk2Q8kF8qSp2NSKVuIa2hryz+BPF4oI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0g6rB7x0; spf=pass (imf04.hostedemail.com: domain of jannh@google.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731532875; a=rsa-sha256; cv=none; b=AboBsgDDBILpX/rT+TfesYYY3S26gRGm3V4lcADPacOp1ryznPdLitZNrm94mRE+6+9oyZ U4O7LXOwYyrSXLDkfhyepIb6E8n+kYVPQOFPRGUZYEw1EnkQfXyPNWDCtDugvH1YKy7xFL Yzt8UlIlFjPGHKMkYrTfnRdH6MeAo4I= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5c93e9e701fso2950a12.1 for ; Wed, 13 Nov 2024 13:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731533068; x=1732137868; darn=kvack.org; 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=WALPwj00gB0ma8t1qi9YCWEzgMiAXx66M8d65obtXCQ=; b=0g6rB7x0H7yTBUdoOEkh0xVWpp15tMW/0hAR+55R9h+wSKRrE/GXaA9nM9gAiciiup oqv216nsTSbk/3wcIQ+BhciDd1OTcxNVuczsEs5ZSwKr8S7w9OybqicMPNXWYyM22ovX llGnUodH32JF2uN1o+mKR7rmWSIf7hxODQq/R0iDYXNtzTkrKbcmB96wd08D7PDRTfmr FbHVp+qJf7KZpJ2eQgtD6TdH4Ry3MuM9ESHSLjcGu0g7ZwiKCwJ2xiEyTpnWpCn3LTZc qoLuGtEpfikGK8qNuBUd4Tx+/8V32oqWJf8LkZdoZoEjnpxasoy+ylJh/hF3P88lmEcB wqDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731533068; x=1732137868; 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=WALPwj00gB0ma8t1qi9YCWEzgMiAXx66M8d65obtXCQ=; b=O/NdvNv5m2q3HqaAJ+za3gyOV3izK8wgyswvLMOriY7U9HtTR9W5heAidzPVLhCxEh d3XXWExvoWNCLKkNJWUAuLcOYkut1xQhAhtdrsz9MmmYWSBxLYGSM2E6vPWfMDDn6Lxp KI1KIUkxm8aUlTdq1TGzt0cKD36LrPMpDRq1tkzZA3wQrYUJtTKTXtlWABfzbz4oTe4S N8XnADfr0K7dnU4pCm1RokYEhaTCNqgnkM8PHfv+5AZZsDpEN3Gy18tc+Zd+MUJuuDiP 4Y2VvK5M2RL7bQQ04aOAN6pbUBdkpOt7XCesZP93Xkf1oSdzb4NCt7EPjwoPozwhWRSm TzxQ== X-Forwarded-Encrypted: i=1; AJvYcCW6K93I3GuPAHepRrGCzOMuIZO1qqDGxpgOF7v2h8TdrrpenqTYzixfnvaN8BVAOLGwVG+INXIt4A==@kvack.org X-Gm-Message-State: AOJu0YzddvqYfT5PO5EORm81JFfM6bRyZ9DolZzW41mI1UpJ0IW+BoP1 jOOaeg+rO4F+3yN2aeogu2ZQcOqn98jHgIItrkzzXH/Y3+brdQk0vDw8b/Skto0Lb2rhY3SVCsT aeHMS6TDvigxrf4YDASZgnRU/aqm6E6sGYQs5 X-Gm-Gg: ASbGncsTAkKWRU06a/+tH7tQfhBBWggaSY9F/C3zYSvz0YardzaTbBkCQP10gMXrlhb z8YGhQ/8/KvsmjwmCawVWPsGGnoy+ajh4ctYOTDN4KW560ZGxffGauneeF44R X-Google-Smtp-Source: AGHT+IFfLNMBVXixSLINqFDfIpRoTPK96jE6ghQ+OIDXRzVy5SViDkAaMVqzB27iNuyze13HZhhc94KsZh47a2fZZoU= X-Received: by 2002:a05:6402:543:b0:5ce:c7a2:fe71 with SMTP id 4fb4d7f45d1cf-5cf759092edmr106413a12.0.1731533067298; Wed, 13 Nov 2024 13:24:27 -0800 (PST) MIME-Version: 1.0 References: <20241112194635.444146-1-surenb@google.com> <20241112194635.444146-5-surenb@google.com> <54b8d0b9-a1c7-4c1b-a588-2e5308a977fb@suse.cz> In-Reply-To: From: Jann Horn Date: Wed, 13 Nov 2024 22:23:50 +0100 Message-ID: Subject: Re: [PATCH v2 4/5] mm: make vma cache SLAB_TYPESAFE_BY_RCU To: Matthew Wilcox Cc: "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, mhocko@suse.com, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, minchan@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 572124001B X-Stat-Signature: ecd66wh7ths4ttuhyedhthxcieunhipt X-Rspam-User: X-HE-Tag: 1731533014-336263 X-HE-Meta: U2FsdGVkX1+LKcG372bTMrNG9T5HL1MTYtZ6CbUSLEXEYF/FNT8xwWPQ0sGslpb2QzWTzFepgimHBmdZqennnDX/N30uL4j7ZijdyGgSguV7AQCMSPgBNV0xRCBnkEUrGf0uBYMmle35dACilX29aBYuFUKTMfpPMglAkqaeCGe7BKV3SglqxR9sa9jhyj7CMP8PeYTBHV2Rxl70mCbgaoNqTASKDI+w5eDRRmPoqRP9vtZjrg9QblafYCXQkYG32lLJmZpTS8J7D5ZRtN840kVFXYoAGesCjOgNiAdE1jtFW9hogsWnSCbiZpnqIXEilYuxhPRZ1f32PE2dfHCiN7EgGBXh7Rjd3DV0ejwy38QbJsMUB+s55x3GBc/+jKAIGLZY2qttrjX6Y56UWvlrrD2iONAcrNngSjWdZ82dljbZBkP0dZBiPqBFyhyusC5PiKzKS6Q2XA9D8/WdP4lCMnpBWpyfTzQXgrvLTiihUHWw5oVGCGnzNwehsXRO+Qg2uWHk5tjPdD9d+uGRHG2HbQhyjEsUuVBQZVXN5RxfagE60ZoDWsfnyo+0gqirNuUncaFxW/UsN69EevJkHNm5p7/8Fo6Ex+d9YJzwIf4ZMPTouZm9u5qaPHRlctIwOpIOHfKch6mR8kpg8zzIuGMzy4WPxuydQSwuHpBk5Q2sAw+GApF7rVg0AGsh8Xyw2UwqIxw0N2JwMnZvIcEHEnEFyMWEFTlXp93SbZmLuaJH+RbmTWzX6gzlNnwyH1vAy5efsFhQM1X8ies7AcdUlgbTAxMmqDjW+QmokLp51+F9S6QmlCgG0HjMIFQt2SgSoFvmVRFg4bGffSKKV2OGbWVyEm2F+edfFjvPUe3atGgr2IX5NYsQzM8ktc4QlZnuqOr8yGCpp3eTm4JqPn5DyMapDdn2LNsBlVpLRC3cUy/UI++fMw/2uGTbztVlq9Y2cc83IBUogijCCJbLNd/dE7n aoLSlgEL B1fK1mPgtYJpc2wa1i1RgCnGYoxfulXnTl1iHAT7eK0B55c7EbQPAYiCLjgFgDuiK/zsjKuSiG+hWpVtSejC0ujATQvYm//Q4Q90rcPSZocysKOoqCDNwnOdi1HLVAHLyzBxPabkCHlErmfkwpx/4Ju4EyXynU13trN4R++nkj6TE1Ol/XcaTaWQ0xYdBTl2hUKUTejUqW0yP5UVkgEl4Qw1PBJwi6A1D3jfRbfhSTVRzgGlzmi+wLR4HOXSapr3af/4DtqbU5fVO3kIKS4wPyQpwhu+/pY+j2DGTdKUISg7EsFjSJgIvu/jZViG6vLgdowGBkksBB8ds7us= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Nov 13, 2024 at 9:59=E2=80=AFPM Matthew Wilcox wrote: > On Wed, Nov 13, 2024 at 05:44:00PM +0100, Jann Horn wrote: > > Something like NULL or (void*)1 is fine with me but please don't do > > pointer-to-itself - we shouldn't unnecessarily store a pointer to an > > object of one type in a pointer field of an incompatible type, that > > increases the risk of creating type confusion issues (both in the > > memory corruption sense and in the Spectre sense). I know MM already > > has several places where similar stuff can happen (in particular > > page->mapping), but here it seems like unnecessary risk to me. > > Hm? I don't think page->mapping can ever point at page. As far as I > know, we have four cases, discriminated by the bottom two bits: > > 0 - NULL or address_space > 1 - anon_vma > 2 - movable_ops > 3 - ksm_stable_node Oh, I didn't even know about cases 2 and 3. Ah, yes, I didn't mean it can point at itself, I meant the pattern of having a pointer declared as "points to type A" ("struct address_space *mapping") while it actually points at other types sometimes. > In fact, we're almost done eliminating page->mapping. Just a few > filesystems and device drivers left to go. Ah, you mean by replacing it with folio->mapping as in https://lore.kernel.org/all/20241025190822.1319162-4-willy@infradead.org/ ? > Would it be halpful if we did: > > - struct address_space *mapping; > + union { > + struct address_space *mapping; > + unsigned long raw_mapping; > + }; > > and had non-filesystems use raw_mapping and do the masking? While I think that would look a tiny bit tidier, I don't think it would make a significant difference for page->mapping or folio->mapping. In the context of the VMA field, the question is about whether we make it possible for the same memory location to contain values of different types, which I think increases the risk of programmer mistakes or speculative confusions; while in the context of the page->mapping field, the same memory location can contain values of different types either way. So while aesthetically I think having a union for the mapping field would look a little nicer, I don't actually see much benefit in making such a change.