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 D42D0C433FE for ; Mon, 28 Nov 2022 17:34:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24A676B0073; Mon, 28 Nov 2022 12:34:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FA6C6B0074; Mon, 28 Nov 2022 12:34:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C2B76B0078; Mon, 28 Nov 2022 12:34:48 -0500 (EST) 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 F00ED6B0073 for ; Mon, 28 Nov 2022 12:34:47 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B68BE1C6669 for ; Mon, 28 Nov 2022 17:34:47 +0000 (UTC) X-FDA: 80183551014.02.885295A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf16.hostedemail.com (Postfix) with ESMTP id D981618001A for ; Mon, 28 Nov 2022 17:34:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669656884; h=from:from: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; bh=HOnSzZsHYJMsU4U1iQE6DAPLRF/mhbFHpR28YkQY5sY=; b=gLNy6L8IAHjtXbtNqfto4k3k9nYGJrkwDjsgG93vG7SQIeswJZSDlzzSjQMLqQK3nKMoEU s+yryntqVkWntlmEqpsLVxsYh8RRogAJJz6LRfutJZ74jp0B57hQlwdGmkFXjKPScYTu7y CBJmqnkNpPtWXYkA4U24wvhhlYxBTtA= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-297-KZLabN26PMONWy78gFiuvQ-1; Mon, 28 Nov 2022 12:34:43 -0500 X-MC-Unique: KZLabN26PMONWy78gFiuvQ-1 Received: by mail-wm1-f72.google.com with SMTP id v188-20020a1cacc5000000b003cf76c4ae66so8870198wme.7 for ; Mon, 28 Nov 2022 09:34:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HOnSzZsHYJMsU4U1iQE6DAPLRF/mhbFHpR28YkQY5sY=; b=kf9X/uRUDNT4RA9J15zr5eXOKN/Ta67dA/Pw3q7scU068gMXanr5Hek4TjCH4gSyqG 8o/j+5w8/PsoAejfpK+lDyODVmzL/LILqfpRyV/ERWomva26++CfQ7efZM2g4UYPrlb/ Y9b0uBnPMA87HF3/gI+6pW1ODF3GYG//kP4Y/WVsO8ybdMvrozNt1EPtahXcea1D+tXi /IC/iekhBclIe70Hn3RQiGK1W0+KX1cbnP8bJnEITbWYQObMn2d+WwN+pdNm5fs5drS7 K8b1ubLiUgpzJqwc+3O1Tz5eFvJPpnvPYva0MU+rKPzMD/6URWnxd5zsqZLksOhRpuzs A+1w== X-Gm-Message-State: ANoB5plUdl9M4y2y/U0EgEYVaJhKfy1jb2wTt3529UKmFGBhwZRXBB7w AnJTvxumtRv9CqQgn4v3xx30v7Zo33qovUfklYl8oVzD+a8WqSXvmwzdYzuWQdyB/n7qoZCSClh p0IwMjIH+8Vo= X-Received: by 2002:a7b:c4cc:0:b0:3cf:89c5:c241 with SMTP id g12-20020a7bc4cc000000b003cf89c5c241mr37100207wmk.204.1669656882284; Mon, 28 Nov 2022 09:34:42 -0800 (PST) X-Google-Smtp-Source: AA0mqf7Vg7Jm1kR4dA6EHQua9xX4cybNBFmpBAFyMBAC9EygowzOSbC7XNsISkS4AJ/A0EcLcu5sGA== X-Received: by 2002:a7b:c4cc:0:b0:3cf:89c5:c241 with SMTP id g12-20020a7bc4cc000000b003cf89c5c241mr37100175wmk.204.1669656881884; Mon, 28 Nov 2022 09:34:41 -0800 (PST) Received: from ?IPV6:2003:cb:c702:9000:3d6:e434:f8b4:80cf? (p200300cbc702900003d6e434f8b480cf.dip0.t-ipconnect.de. [2003:cb:c702:9000:3d6:e434:f8b4:80cf]) by smtp.gmail.com with ESMTPSA id u26-20020a7bcb1a000000b003cfd42821dasm15515518wmj.3.2022.11.28.09.34.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Nov 2022 09:34:41 -0800 (PST) Message-ID: Date: Mon, 28 Nov 2022 18:34:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH v3 1/3] mm/khugepaged: Take the right locks for page table retraction To: Jann Horn Cc: security@kernel.org, Andrew Morton , Yang Shi , Peter Xu , John Hubbard , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20221125213714.4115729-1-jannh@google.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gLNy6L8I; spf=pass (imf16.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669656887; a=rsa-sha256; cv=none; b=Mre0Fex8gUJrKFt1JpS1ul5P+nPBVO3aa6IbskbyxQTy5OgtZnbfNXFACJXs/+fqkZDnfH xxzMzL1mrZEGFrib+7aOAwZfiH7wYW4TYglRSdV7TroUotqIuqYkVrMxsuNKHTdXNAXw3J 6oEfJF5ly6wKqZB+PYsUeV2Cyott9J4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669656887; 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=HOnSzZsHYJMsU4U1iQE6DAPLRF/mhbFHpR28YkQY5sY=; b=qISFD32J59Fl/OWwuaX7O+0aAqGdP8se+3q4XIA8guPF6bO/oS/MLN0oVTFN0VPTVU30Uh ILqxR60E84SXz/gYgt7cmd+9wIVCWCeejPtyoJ05T/fxvuH3ixxsceeKFAOgXEg2g9coZM C4fwlJZ0jR61kWSzTXr8MOwtU61wO+c= Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gLNy6L8I; spf=pass (imf16.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam01 X-Stat-Signature: stuy8upm7rbjxioxxzwh7bmh9ubem8oz X-Rspamd-Queue-Id: D981618001A X-Rspam-User: X-HE-Tag: 1669656886-113291 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 28.11.22 18:28, Jann Horn wrote: > On Mon, Nov 28, 2022 at 2:53 PM David Hildenbrand wrote: >> On 25.11.22 22:37, Jann Horn wrote: >>> pagetable walks on address ranges mapped by VMAs can be done under the mmap >>> lock, the lock of an anon_vma attached to the VMA, or the lock of the VMA's >>> address_space. Only one of these needs to be held, and it does not need to >>> be held in exclusive mode. >>> >>> Under those circumstances, the rules for concurrent access to page table >>> entries are: >>> >>> - Terminal page table entries (entries that don't point to another page >>> table) can be arbitrarily changed under the page table lock, with the >>> exception that they always need to be consistent for >>> hardware page table walks and lockless_pages_from_mm(). >>> This includes that they can be changed into non-terminal entries. >>> - Non-terminal page table entries (which point to another page table) >>> can not be modified; readers are allowed to READ_ONCE() an entry, verify >>> that it is non-terminal, and then assume that its value will stay as-is. >>> >>> Retracting a page table involves modifying a non-terminal entry, so >>> page-table-level locks are insufficient to protect against concurrent >>> page table traversal; it requires taking all the higher-level locks under >>> which it is possible to start a page walk in the relevant range in >>> exclusive mode. >>> >>> The collapse_huge_page() path for anonymous THP already follows this rule, >>> but the shmem/file THP path was getting it wrong, making it possible for >>> concurrent rmap-based operations to cause corruption. >> >> This sounds sane and correct to me. No expert on file-THP, though. >> >> For anon-THP it's the mmap lock and the rmap locks. I assume the only >> difference for file-THP is that the rmap lock is actually the mapping >> lock. Looking at rmap_walk_file(), that seems to be the case. > > Yeah. You can also have private file VMAs that are associated with > both a mapping and a set of anon_vmas, and in that case you would need > to lock the mmap, the mapping, and the anon_vma root; but the file THP > code in khugepaged instead just bails on file VMAs with an anon_vma. Right, that's my understanding as well. > >> I wish at least PTE table removal could be done easier ... I already >> experimented some time ago with some ideas (e.g., lock in PMD table >> memmap) but it's all far from trivial and space in the memmap is rare. > > Because you want it to be faster? Is that for the THP usecase or something else? Page table reclaim and page table migration, where you might only have limited context and wouldn't want to take all these expensive locks in write mode (IOW, you wouldn't want to care about them at all). Feel free to add my Acked-by: David Hildenbrand -- Thanks, David / dhildenb