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 5466FCDD0DD for ; Tue, 22 Oct 2024 19:53:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E51656B00A0; Tue, 22 Oct 2024 15:52:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E00636B00A1; Tue, 22 Oct 2024 15:52:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA1BD6B00AA; Tue, 22 Oct 2024 15:52:59 -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 A76BF6B00A0 for ; Tue, 22 Oct 2024 15:52:59 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 00C2880478 for ; Tue, 22 Oct 2024 19:52:44 +0000 (UTC) X-FDA: 82702285890.06.A0EEBEC Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) by imf07.hostedemail.com (Postfix) with ESMTP id 08A984001A for ; Tue, 22 Oct 2024 19:52:34 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=poDjp2Ue; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of 3mAIYZwYKCD0rdZmibfnnfkd.bnlkhmtw-lljuZbj.nqf@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3mAIYZwYKCD0rdZmibfnnfkd.bnlkhmtw-lljuZbj.nqf@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729626739; a=rsa-sha256; cv=none; b=jxiQWXYs3NqX7aKxJxRqhezu6d/ZsT6XJZA+6TBzL6vijtRlJbwOt4GfYOQ5qpHgV9YOom saC8X/Ed0FKOyxVIIKXrKX7gSyKcsXio2dfF6y+BDBDPgLIejSTRdG5J8Ejs/LW50NkRfg J8s94561V4Req5JMAx0oKKRUAwfVNhM= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=poDjp2Ue; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of 3mAIYZwYKCD0rdZmibfnnfkd.bnlkhmtw-lljuZbj.nqf@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3mAIYZwYKCD0rdZmibfnnfkd.bnlkhmtw-lljuZbj.nqf@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729626739; 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=P+SI51bEi1jKFAwZYIZIZnZEYLQDC0ghYZ/VkhDOKRw=; b=WkmVODarhuAFbLESWsvIaqrD+G7iIbj4QxOfhKkDRuJu3IKuVE7e5jTgxUUXx1JFSDuHZ+ UhZkobTPJ2yFlR2hXeQyghNQFrHnj8p0xDzQlYxD39hfJt/ob3Ml6vWAU5GTffq+sVSl2g lvJDQSzsJ3uIKEOnXBX+9oh8XnpibuE= Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-e292dbfd834so9132531276.3 for ; Tue, 22 Oct 2024 12:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729626776; x=1730231576; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=P+SI51bEi1jKFAwZYIZIZnZEYLQDC0ghYZ/VkhDOKRw=; b=poDjp2Ue6KEyo11F9XSL5Jbpt+fML3/nTPfTt98fG85P7c/L74CXAkuDoE/fTsU2B+ A4WIM5ZeromunNXRnp6f8iiQ0bIWnxY3zp7yYNfL53roMItNfTNCNYLbr3KQaFzg0lDQ rQ0V4OjI603r2ei84Bk/ShSjnB26U5zVBW2+mYU+VzIhGCYCVZBsDF+iWURosLBOlwdh H5hJh2ttw9OWu/sndoro79V2TUvBDwEEQQbLgzzde7IxR6TOWAVY69G8J+Xu/XVnzl9X os3Qwp/arn0B7GEQs+AuxcQNaaL0n7ceKLTomjarwCDLQiDGY/RGt5LEAT1dq32FAaZK SZig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729626776; x=1730231576; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=P+SI51bEi1jKFAwZYIZIZnZEYLQDC0ghYZ/VkhDOKRw=; b=HcnXDFLVKWyGWLwRvsC9qSWvnyHAnieahp3DcmMpg7Q5rkUTS/uuQE5ROKSjw2HEMf S2i0SsG9B72kLGvayfuefbZdrEsKpTq4q3hvld0xtP8Jk62kINlFMR5o+4nT8DWEW69M 0xfvejOM9kvnHXoRkCm9v7E44MQyQxqFpnXbOmmoQO+hY5i9FCtnsitCO4KuXMuvsxAw Mj/yqdrdzyEeWkg8H6d/1rkuBpajcaf7OXKMNXmY1p+LLmnrXUkzZsHn7pWoYMUVT/mW qJ6VTSzne8i7qD6UJMCNf7f1u7HPenEg3KUVAEU8Nwk67nCjXliZLJUfUoYCLeQL1Z86 ltzg== X-Forwarded-Encrypted: i=1; AJvYcCWd08LrNB0VrTgQwLTC2FTgh1MmbUe4jYHGMQtSHi8bxkZLh5jp6RNCByfnnKdzbNYwExMyaf8z/g==@kvack.org X-Gm-Message-State: AOJu0YykZI8uC6xQxpGkMtdbSE55TkfjF7fCr446bU0wEhH0dB9jGET6 uZJOKiqVTEJeKccmE1zfvuyBvdj79h6vjJK3zi5Q5cAaxVqu29s2ZVNJpZ85fKjv/8wGcQntjZB nWw== X-Google-Smtp-Source: AGHT+IEwPnDeQbkgHiRpbdb78i0IZVB0bvSwR5nuQygXUzqVgLEvYnoLPehcPVfIe+hCt8gRKA6p7HNV+TE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a05:6902:1818:b0:e2e:3131:337f with SMTP id 3f1490d57ef6-e2e3a624ed7mr37276.4.1729626776174; Tue, 22 Oct 2024 12:52:56 -0700 (PDT) Date: Tue, 22 Oct 2024 12:52:54 -0700 In-Reply-To: Mime-Version: 1.0 References: <20241021173455.2691973-1-roman.gushchin@linux.dev> Message-ID: Subject: Re: [PATCH v2] mm: page_alloc: move mlocked flag clearance into free_pages_prepare() From: Sean Christopherson To: Matthew Wilcox Cc: Yosry Ahmed , Roman Gushchin , Andrew Morton , linux-mm@kvack.org, Vlastimil Babka , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Hugh Dickins , kvm@vger.kernel.org, Paolo Bonzini Content-Type: text/plain; charset="us-ascii" X-Rspam-User: X-Stat-Signature: mcdgjxkj7bnc1zy91mrjzeir7uj9krap X-Rspamd-Queue-Id: 08A984001A X-Rspamd-Server: rspam02 X-HE-Tag: 1729626754-763888 X-HE-Meta: U2FsdGVkX18nrPkJYQlPLVL8HpG5Fh85uFBr2TJS2ANQr83U7qJB95cyfrmulIvafjhkPvc1l10L8Hn3/1p890a0AuiVW5n/dENYlSpuQqpgjJlYhAe6dQjS+gV+H6/Otib9kDSe3rZpLzJlr829uGAC0tM80cMYVSqze/xhUJrdJZMO67gPiAPxkbnahe2SPtkVh4bvq0CaeG+Uc2YntMLSKmaMl+p3AMeiIf7x1kjcqrrpQTrXrl62037I0jdvxukcjbNy3RXxi673pi9PKVw++knXuHgOpOaGegMy4c+PpT6KhVuPpm4IJNnoeDvySmzauwImfOImIx52+W05+F27kMgNezL0yKl6G5m3ZXnrSiKICswFrB7ueJ6AOnrecw58E7LkkzTU2J0hz1/dYOpJt9uAtXohNkY9M1IEmGUL0NpWOoEKTaMMS5so+2STEoxvzGvoxUaRsuCXBrBBO3Aacf0aIHIQnjz6KUjCxvp1tfsugp8k+bQ79GxJiJcM5Ko23Z2ZtNFWJmMDZGd0aUdgt8l4klEWyS6uCKaILEPKsnE+6NPKWmGdkInddXCl3P2wKWLYYRCbjji6FfS3QReB4hYAXR8aLQabQhizL5R46oH5l5ZOlN7u9GAwpMxUCIM1M1kUEoPizU01k78T1vuJsNJQ8bXYVKQvJQcnvQzisIjKMUsDBgQrw+1QHBQD/aB7r9IoCY3Q7/bjMjMG8MQfwTrspO/q16OjEzKtzvjbbYmRT7dUDLaviV+e+VKkPRpomRe61PUffOpzEldY9Gj6sZ0ia07mKvrQ+wGdM4uSWePGj0d4xdy/hhaGFIgAiqihVGXkPkoKEMlNwzQeDqONFK5Hg8PB2aXC07iFbQnddpP1aq9R9tO9ZkZ7KcSa/iRJwk7Z/7izJZzrAnlVLtR3VUl/UDbWmwYi2X8tXC/DGtqMsspPUc9jBHIs2yoH7zO8EwMm+A0wje1S02L 2sf9ZKgH Dsnj97kj3PzHH9yRfUJrXD2zr6N8dFvuhOsP/dS4QIBDD9JfEQBzAc1mD1EZ/bE4whCrGFjtg895gyjkWXbgqwjYFeMTPzPrfySasRT6mUfaZYtw1nRPd4EKLKTezwxN2UIPVe23fmXxzhFSnLeJMvG1p3fnLNuy+UhZ8wI/iYtt2YW2J9ziqr66UQJeO1Btnhb1MKBRQqrqQ5+aFdWWqRdcV1FxiNO6WBghb1QxmpvN9ilksB7AkVo52Rb0qU0P87Qyk2c4UA4hjThrmwTlfpdiRRFHDDMLk6Fke5hoN9/jXUA6OweQUoxYpqQIy124J913B2Zd5ICYmhK9BdUgu/rXlLxurFpMj3rSK/q9AoN+Zy8BYC3VPOd5c4rLRk8TKbSl3HkkgLv/TwJRAUKuNsgIa/4sNjr6N3sDBUKDrB+XtDeGqmn1G3tjtJSmOuS9N1dX8a9FCv+ICihzcLczRO+579eNeCxVb5/ApQwhatQGR9hzdDZ8bHtzO2X2QLyCwAsIn33uGWazk90TV4HWd5jPiXjsuwoIN3MFGDTOXhfLreqpuo8NfNyrTnHlDd4P9ebOqOqxCnZShfXbduz26vh4rGJR4aoV6GHWjmO+whc9i5XKKovlFapwssHIiYYSQTEzZ 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 Tue, Oct 22, 2024, Matthew Wilcox wrote: > On Tue, Oct 22, 2024 at 08:39:34AM -0700, Sean Christopherson wrote: > > > Trying to or maybe set VM_SPECIAL in kvm_vcpu_mmap()? I am not > > > sure tbh, but this doesn't seem right. > > > > Agreed. VM_DONTEXPAND is the only VM_SPECIAL flag that is remotely appropriate, > > but setting VM_DONTEXPAND could theoretically break userspace, and other than > > preventing mlock(), there is no reason why the VMA can't be expanded. I doubt > > any userspace VMM is actually remapping and expanding a vCPU mapping, but trying > > to fudge around this outside of core mm/ feels kludgy and has the potential to > > turn into a game of whack-a-mole. > > Actually, VM_PFNMAP is probably ideal. We're not really mapping pages > here (I mean, they are pages, but they're not filesystem pages or > anonymous pages ... there's no rmap to them). We're mapping blobs of > memory whose refcount is controlled by the vma that maps them. We don't > particularly want to be able to splice() this memory, or do RDMA to it. > We probably do want gdb to be able to read it (... yes?) More than likely, yes. And we probably want the pages to show up in core dumps, and be gup()-able. I think that's the underlying problem with KVM's pages. In many cases, we want them to show up as vm_normal_page() pages. But for a few things, e.g. mlock(), it's nonsensical because they aren't entirely normal, just mostly normal. > which might be a complication with a PFNMAP VMA. > > We've given a lot of flexibility to device drivers about how they > implement mmap() and I think that's now getting in the way of some > important improvements. I want to see a simpler way of providing the > same functionality, and I'm not quite there yet.