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 D62FBC54FB3 for ; Mon, 2 Jun 2025 14:56:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7670F6B02C3; Mon, 2 Jun 2025 10:56:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 717BA6B02C6; Mon, 2 Jun 2025 10:56:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60FA86B02C3; Mon, 2 Jun 2025 10:56:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3F5466B02C3 for ; Mon, 2 Jun 2025 10:56:27 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DED801209C5 for ; Mon, 2 Jun 2025 14:56:26 +0000 (UTC) X-FDA: 83510761572.19.67BC3B7 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf03.hostedemail.com (Postfix) with ESMTP id E015320014 for ; Mon, 2 Jun 2025 14:56:24 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=tUVv9iFk; spf=pass (imf03.hostedemail.com: domain of jannh@google.com designates 209.85.208.53 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=1748876185; 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=pNF511MgaFtsD48A90MDbHZtD9Ll5lctEsJk06IOH/4=; b=102c2StnAze5MEM6DPf6gkLd4ud4BxrBgBNz36DB1iJy2wMe6KoATIdEW46eLoA64qWAQC KacaGvWjIxrImm+yk9lUnwZIIg5XesW88yKXLNXHc34VZ3U3zS5Ze+UFVPwvTB5Yt+ih4l SZ5M31eWpoF8WmznulCuVjb6o4YctqI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748876185; a=rsa-sha256; cv=none; b=R9scwLFLRYfh1FoXU0q7LGT5Ds/F3zuLnq/qw+QZESdFEw7hdogzyYes6wLrliESlqPoVn jQI8l40UNtfl54rr5TL831Pn8XdGNtTv7OupwGn116XPfWJaPBpNhY8CPJcR/N0vd3mRK0 KgRN3BBvuXWjC56e6WwFNF0BmNDUGV8= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=tUVv9iFk; spf=pass (imf03.hostedemail.com: domain of jannh@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-6024087086dso14547a12.0 for ; Mon, 02 Jun 2025 07:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1748876183; x=1749480983; 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=pNF511MgaFtsD48A90MDbHZtD9Ll5lctEsJk06IOH/4=; b=tUVv9iFk11sZtC8iS7YjtDPQG4g6CRARMqC4E4BR4DKD7wVVJf8p6nKq13hyovaOEq RDk1h8CNkudbJYNN6C/1BkitWwyqs79VAkBHSbf+fmzKaBPE2Op4CCjY+h8B8VjRyR44 aZYPdgAcJpLz1sfJSkvZJZ0NrzOlR7heVCp/85uC2Z4MdLO8ewmbCSKFuPYxYHabYaqM xqT+fP/tLZdvhHkh3NVuEAQ4xa3awJZQBJa5yettL+p8FK8yGiFn70UglhFdgKpBe56U oXyiU4vnzh93ewhGAKXbt0PYUt2AJZgiKxjInhmn7gqtKwyK1qNmA+4+af6B3KcTSvKI JliA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748876183; x=1749480983; 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=pNF511MgaFtsD48A90MDbHZtD9Ll5lctEsJk06IOH/4=; b=SO1G/ltxiWxF8g9pl0aI3ZeLNCdvMAhk09rN/cuk+GrBVYBpkSPzfQtNQrsiPAY0pl LVt41E01MQBz3uDOGrNpPrybCn2DqPT3rZpR7txl58Gn6pcnrTqzb5vEsG2PXh9x6/yn ZaQNKDqrD3i/qPGyA1/05SZpz/DhdQNAi7Ei+KEAc/kpfhnhJtavTkMoNNN+j8cduaxI Jb4+rmqy8kCagMT9MqQfa8anRtDX74/ixdha27KxHUMrQEGN3ZzjMH0BoVRJKLo8XEOA Jjb8FKynNbEnr1M9CTQqx3avbOYbO6rvu9+0P+T3vmjAZgrGnVgyImOO6K3uomDsNEJE IpPw== X-Forwarded-Encrypted: i=1; AJvYcCWaR18ydijkwbtPrHvkoMt/IB+gwOvDMhUZWNEehoGjmdtKbDCuabOEqW8jwCRek9TBeFDhAT5AYg==@kvack.org X-Gm-Message-State: AOJu0YwA9rvOo3n/ImGacIaqdG83C/Uy1BUk4udwCPqdNQI+ukmvlkGF sStTG+HxpOIduM15haSIMCW9CHrt+nApRlyXT36g97y9oU4oszeyq4AB2tNibSs/V7jmwHp/U3I MUCgmFYmfkDNMh8E87Z+MKIW868fp9cLTzY8Ygpw6 X-Gm-Gg: ASbGncuDpW1CcWXnCRWuwJeBTe72wNcxZHAcXh+yb9aseHmYC7brJzolkDmutqTqZ+n nfcwVGVFSguDlVuDTgVzESUppgAxbtwUZe0foLTkCQpdjGGPJbfXXkcyg8V83+OqJrDQOiEWGXB yT7VIVVL+/QsaeNPBNzsbTi+wyCstPRG4MTjpeMsqro+siMCO4zCJzdazXuUOfRx/Z5M5KdRZrJ Rl7/+L1O/w= X-Google-Smtp-Source: AGHT+IGQtc3WBIVJZRLnX8hZQzlRbDDYAStKVAzE1RREAckOOqW5UwtvA2umiVPi5uY6NCwFxiD63Zy+fl33mDpdslk= X-Received: by 2002:a50:baa3:0:b0:602:3bf:ce71 with SMTP id 4fb4d7f45d1cf-605b3d6f8e3mr115449a12.3.1748876182849; Mon, 02 Jun 2025 07:56:22 -0700 (PDT) MIME-Version: 1.0 References: <20250530104439.64841-1-21cnbao@gmail.com> In-Reply-To: From: Jann Horn Date: Mon, 2 Jun 2025 16:55:46 +0200 X-Gm-Features: AX0GCFs5qpWJTcbQ9fFL1U98ltPX_aaeb9EoUWAY5hf-6w2pnymfyPDVvrasKGg Message-ID: Subject: Re: [PATCH RFC v2] mm: use per_vma lock for MADV_DONTNEED To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , "Liam R. Howlett" , Lorenzo Stoakes , David Hildenbrand , Vlastimil Babka , Suren Baghdasaryan , Lokesh Gidra , Tangquan Zheng Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E015320014 X-Stat-Signature: kzw6bxusyfeur38pub5ziuw4r6ixkhn6 X-Rspam-User: X-HE-Tag: 1748876184-797694 X-HE-Meta: U2FsdGVkX1+KkqPMK4szABGBFi9jBKXdy1Y4uQf+Jg0DNfewphUB2xt9F+Bv7RqWFpJDHM7VqZO2YqKVEKAIMqJyEF1rg7RTNOprfEZwtJUB2yDnDKowQBOJqkeCdRWSrFOHCAnlu7Vxtdb4V7oKDeh92k4NBSvLYqKeoSC2JGPTaLhLpyluxCBfIfQQTTvpQV97Gb6Raa4DPQJ6b6WoP9dbsp1zi7IS7hKd0PoVKQR3/vMcg61RX5bZvy4ULJQ0FzlxBfge/xTx+jgcOLsD7bc3uXcyCNnQykZybobcaozTt1Wru6HAJNQwKyOfOkzZiy2OyUS68TowOthD1jMB1EfOUve564MYVxQhOOOQE99opibrOtnFqKnYFDbASRDAooWHHc/xna4Jy17aZt9Kyrz+9qth6h550ReEn2dAZSI+JPuBjz0RXlkuovCwvjfoexqnQSVWj8pPb2YAPRg3SNG/wuhJmUrYSAc1dZW3kZTRlL1+PiCe1iTy6nQjrasJ91myPrKw7vBacxTRVcjbDPniZ7I2gzXhdYMCpqf+olkX5K77XuqLbRImrHIM7VScPg2HFKkYU7Lx+Yj+FIWAGhEmexCUw7MvRAS8eci/e/Azkc0m2obc4wEZtv1Wj+Rs3s+nLWO9dYqKtD3Ypnj7HiCKMsY8NKIB/3uPrOu3XGdTR29QEfn+yz88FoBvQdcCSZ9cpWA9BrRGr3sjYK0b9/4u7LdC2cLmm9+V4vug+bORY9QNZEC0fOIIzgWtVlfSlF6LWDRtYr7PsGDiWXttYxOulXJGgMCmj2C1lFY4wnm4q5HtxQsb7yB8Ar3FNrNMHeR5Upb8j3HvNRKybdxLwyJYIwGONKvEt0YMfVYs7s5QWP6tSU4jTjc52id99wqaN/s2p1H0cWGMEUiXq4FbFp3dtFNhlOorvgl+tofa1P96sr6BV+Oc5FClU4ZcFXTftdRXzcQLGcHtvyOGVf4 oFu0su5P 6q4sPGv0BB/5V5aVZFf8DsMCtHvbljUeSN2DUbBZdsZSIfHHhZgzq1aq+T9YLSMIdqEI83/MT55sAlp5niGzs9aP1yWolx3ohJIMuI0dsmcx2ZEOicIyvPd4fBD4TOCdBeV7dVmjjF1ljFolggakJJSeMzwatLykBeB/wX343WDWtrc82lmsQM9yRbid7Ugq4kJV/UxHubJ+XGWwD2YMimBKEo3+eC3wTNjy/N+8EN/sp8PgQNUW3g9Vc7e43c9lYwFg2bE6MugoQxxcGOOLJz3Jv265zGjazjQRf 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: List-Subscribe: List-Unsubscribe: On Sat, May 31, 2025 at 12:00=E2=80=AFAM Barry Song <21cnbao@gmail.com> wro= te: > On Fri, May 30, 2025 at 10:07=E2=80=AFPM Jann Horn wro= te: > > On Fri, May 30, 2025 at 12:44=E2=80=AFPM Barry Song <21cnbao@gmail.com>= wrote: > > > @@ -1714,19 +1770,24 @@ static int madvise_do_behavior(struct mm_stru= ct *mm, > > > unsigned long start, size_t len_in, > > > struct madvise_behavior *madv_behavior) > > > { > > > + struct vm_area_struct *vma =3D madv_behavior->vma; > > > int behavior =3D madv_behavior->behavior; > > > + > > > struct blk_plug plug; > > > unsigned long end; > > > int error; > > > > > > if (is_memory_failure(behavior)) > > > return madvise_inject_error(behavior, start, start + = len_in); > > > - start =3D untagged_addr_remote(mm, start); > > > + start =3D untagged_addr(start); > > > > Why is this okay? I see that X86's untagged_addr_remote() asserts that > > the mmap lock is held, which is no longer the case here with your > > patch, but untagged_addr() seems wrong here, since we can be operating > > on another process. I think especially on X86 with 5-level paging and > > LAM, there can probably be cases where address bits are used for part > > of the virtual address in one task while they need to be masked off in > > another task? > > > > I wonder if you'll have to refactor X86 and Risc-V first to make this > > work... ideally by making sure that their address tagging state > > updates are atomic and untagged_area_remote() works locklessly. > > If possible, can we try to avoid this at least for this stage? We all > agree that > a per-VMA lock for DONTNEED is long overdue. The main goal of the patch > is to drop the mmap_lock for high-frequency madvise operations like > MADV_DONTNEED and potentially MADV_FREE. For these two cases, it's highly > unlikely that one process would be managing the memory of another. In v2, > we're modifying common code, which is why we ended up here. > > We could consider doing: > > if (current->mm =3D=3D mm) > untagged_addr(start); > else > untagged_addr_remote(mm, start); Ah, in other words, basically make it so that for now we don't use VMA locking on remote processes, and then we can have two different paths here for "local operation" and "MM-locked operation"? That's not very pretty but from a correctness perspective I'm fine with that.