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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44E59C433E0 for ; Mon, 28 Dec 2020 18:48:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 07B34229EF for ; Mon, 28 Dec 2020 18:48:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727266AbgL1Ssj (ORCPT ); Mon, 28 Dec 2020 13:48:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46310 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726832AbgL1Ssi (ORCPT ); Mon, 28 Dec 2020 13:48:38 -0500 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 224A4C0613D6 for ; Mon, 28 Dec 2020 10:47:58 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id 23so25828587lfg.10 for ; Mon, 28 Dec 2020 10:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ul9Q7F+zVW3PAg2S28tHJ0IR0KNP8kk2DEXpGYeIlWk=; b=KMz20JUoK22L486IVp7caAQRxpZ8S38J8Jj8SYjxbV/2agAn1XdkiISquPYQRJW1NZ BzhkpKZWGzoh12IDv+006ZR9bm3NnfFzCFwKPl2CY7Fp4pA9o8KEXdrfYpWns0a6uB5G 3IE7VhWsbuQlLRJgfgKehWJwyFvcqT3jWXckU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ul9Q7F+zVW3PAg2S28tHJ0IR0KNP8kk2DEXpGYeIlWk=; b=JC+ES7ZdYH+7xQ221ejRfmASA99mC4meh6wU4xHAMxZ0gcRw7AoRKjTylZO1fBogAb v4fzRn9iZhmZhviahPxgCV5vUbJJ7K9hFEXPQISlBw2+e9HtThdCpXAXbRbZrRuInHC2 Gt4j6tu+KOG1/KHb7o8+sT1/unmrMSwtotKZD3FH0nW6xBGOQdjm9BwfGY7Mri0OqpxU GrVaOZo34fU73UkSh5eqdmbpknFz5lEa31R1/hO8Mtg7Q84LuRIn+VHhQtsNKueZX9EW VgJQQuMKYKBNDa7Cy3wxIDdt5HXb/Q4GjhYjOLjyv4jcDQG4SkN7jsvtTf3BBHAkW5kq k/Ow== X-Gm-Message-State: AOAM532khV7slUA/iPQFwC2XzsaYJMJNNjbsqeWcwQu4G5223bvjI/ME h8nkn0ezsJzMlWwq1biUo4QzPOJO7LmC7A== X-Google-Smtp-Source: ABdhPJyZ63HMe9z62x0RFSUtIJlJFdIBiaYbW7kwVeqLKjkhbYAp8HzfR6O2B+Rtwi1l7sCWWjkJJQ== X-Received: by 2002:a19:4148:: with SMTP id o69mr18203076lfa.610.1609181276136; Mon, 28 Dec 2020 10:47:56 -0800 (PST) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com. [209.85.167.41]) by smtp.gmail.com with ESMTPSA id c7sm5410475lfm.262.2020.12.28.10.47.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Dec 2020 10:47:54 -0800 (PST) Received: by mail-lf1-f41.google.com with SMTP id x20so25819622lfe.12 for ; Mon, 28 Dec 2020 10:47:53 -0800 (PST) X-Received: by 2002:a2e:9d89:: with SMTP id c9mr23613429ljj.220.1609181273408; Mon, 28 Dec 2020 10:47:53 -0800 (PST) MIME-Version: 1.0 References: <20201226204335.dikqkrkezqet6oqf@box> <20201226224016.dxjmordcfj75xgte@box> <20201227234853.5mjyxcybucts3kbq@box> <20201228125352.phnj2x2ci3kwfld5@box> In-Reply-To: <20201228125352.phnj2x2ci3kwfld5@box> From: Linus Torvalds Date: Mon, 28 Dec 2020 10:47:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting To: "Kirill A. Shutemov" Cc: Hugh Dickins , Matthew Wilcox , "Kirill A. Shutemov" , Will Deacon , Linux Kernel Mailing List , Linux-MM , Linux ARM , Catalin Marinas , Jan Kara , Minchan Kim , Andrew Morton , Vinayak Menon , Android Kernel Team Content-Type: multipart/mixed; boundary="0000000000002e6e5605b78ab6d7" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --0000000000002e6e5605b78ab6d7 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 28, 2020 at 4:53 AM Kirill A. Shutemov wrote: > > So far I only found one more pin leak and always-true check. I don't see > how can it lead to crash or corruption. Keep looking. Well, I noticed that the nommu.c version of filemap_map_pages() needs fixing, but that's obviously not the case Hugh sees. No,m I think the problem is the pte_unmap_unlock(vmf->pte, vmf->ptl); at the end of filemap_map_pages(). Why? Because we've been updating vmf->pte as we go along: vmf->pte += xas.xa_index - last_pgoff; and I think that by the time we get to that "pte_unmap_unlock()", vmf->pte potentially points to past the edge of the page directory. I think that is the bug that Hugh sees - simply because we get entirely confused about the page table locking. And it would match the latest change, which was all about moving that unlock from the caller to filemap_map_pages(), and now it's missing the pte fixup.. I personally think it's wrong to update vmf->pte at all. We should just have a local 'ptep' pointer that we update as we walk along. But that requires another change to the calling convention, namely to "do_set_pte()". Also, considering how complicated this patch is getting, I think it might be good to try to split it up a bit. In particular, I think the calling convention change for "filemap_map_pages()" could be done first and independently. And then as a second step, move the VM_FAULT_NOPAGE and "pte_unmap_lock()" from the callers to filemap_map_pages(). And then only as the final step, do that nice re-organization with first_map_page/next_map_page() and moving the locking from alloc_set_pte() into filemap_map_pages().. How does that sound? Anyway, Hugh, if it's about overshooting the pte pointer, maybe this absolutely horrendous and disgusting patch fixes it without the above kinds of more extensive cleanups. Worth testing, perhaps, even if it's too ugly for words? Linus --0000000000002e6e5605b78ab6d7 Content-Type: application/octet-stream; name=patch Content-Disposition: attachment; filename=patch Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kj8wyykk0 IG1tL2ZpbGVtYXAuYyB8IDE0ICsrKysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgMTQgaW5z ZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL21tL2ZpbGVtYXAuYyBiL21tL2ZpbGVtYXAuYwppbmRl eCA0MmQ3YTU4ZTNhMTQuLjc0Mzg0ZjlmMTc3NiAxMDA2NDQKLS0tIGEvbW0vZmlsZW1hcC5jCisr KyBiL21tL2ZpbGVtYXAuYwpAQCAtMzAyMiw2ICszMDIyLDggQEAgdm1fZmF1bHRfdCBmaWxlbWFw X21hcF9wYWdlcyhzdHJ1Y3Qgdm1fZmF1bHQgKnZtZiwgdW5zaWduZWQgbG9uZyBhZGRyZXNzLAog CXN0cnVjdCBwYWdlICpoZWFkLCAqcGFnZTsKIAl1bnNpZ25lZCBpbnQgbW1hcF9taXNzID0gUkVB RF9PTkNFKGZpbGUtPmZfcmEubW1hcF9taXNzKTsKIAl2bV9mYXVsdF90IHJldCA9IDA7CisJcHRl X3QgKm9yaWdfcHRlOworCXVuc2lnbmVkIGxvbmcgb3JpZ19hZGRyZXNzOwogCiAJcmN1X3JlYWRf bG9jaygpOwogCWhlYWQgPSBmaXJzdF9tYXBfcGFnZSh2bWYsICZ4YXMsIGVuZF9wZ29mZik7CkBA IC0zMDM3LDYgKzMwMzksMTQgQEAgdm1fZmF1bHRfdCBmaWxlbWFwX21hcF9wYWdlcyhzdHJ1Y3Qg dm1fZmF1bHQgKnZtZiwgdW5zaWduZWQgbG9uZyBhZGRyZXNzLAogCiAJdm1mLT5wdGUgPSBwdGVf b2Zmc2V0X21hcF9sb2NrKHZtYS0+dm1fbW0sIHZtZi0+cG1kLAogCQkJCSAgICAgICB2bWYtPmFk ZHJlc3MsICZ2bWYtPnB0bCk7CisKKwkvKgorCSAqIERpc2d1c3RpbmcgLSB3ZSBzaG91bGQgbm90 IHVwZGF0ZSB2bWYtPnB0ZSBhbmQgLT5hZGRyZXNzLAorCSAqIGJ1dCBkb19zZXRfcHRlKCkgbmVl ZHMgaXQKKwkgKi8KKwlvcmlnX3B0ZSA9IHZtZi0+cHRlOworCW9yaWdfYWRkcmVzcyA9IHZtZi0+ YWRkcmVzczsKKwogCWRvIHsKIAkJcGFnZSA9IGZpbmRfc3VicGFnZShoZWFkLCB4YXMueGFfaW5k ZXgpOwogCQlpZiAoUGFnZUhXUG9pc29uKHBhZ2UpKQpAQCAtMzA2Niw2ICszMDc2LDEwIEBAIHZt X2ZhdWx0X3QgZmlsZW1hcF9tYXBfcGFnZXMoc3RydWN0IHZtX2ZhdWx0ICp2bWYsIHVuc2lnbmVk IGxvbmcgYWRkcmVzcywKIAkJdW5sb2NrX3BhZ2UoaGVhZCk7CiAJCXB1dF9wYWdlKGhlYWQpOwog CX0gd2hpbGUgKChoZWFkID0gbmV4dF9tYXBfcGFnZSh2bWYsICZ4YXMsIGVuZF9wZ29mZikpICE9 IE5VTEwpOworCisJLyogSGFja2V0eSBoYWNrIC0gcmVzZXQgdGhlIHZtZiBzdGF0ZSBiYWNrICov CisJdm1mLT5wdGUgPSBvcmlnX3B0ZTsKKwl2bWYtPmFkZHJlc3MgPSBvcmlnX2FkZHJlc3M7CiAJ cHRlX3VubWFwX3VubG9jayh2bWYtPnB0ZSwgdm1mLT5wdGwpOwogCXJjdV9yZWFkX3VubG9jaygp OwogCVdSSVRFX09OQ0UoZmlsZS0+Zl9yYS5tbWFwX21pc3MsIG1tYXBfbWlzcyk7Cg== --0000000000002e6e5605b78ab6d7-- 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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18D7FC433E0 for ; Mon, 28 Dec 2020 18:48:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 80BB12084D for ; Mon, 28 Dec 2020 18:48:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 80BB12084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8E4728D0017; Mon, 28 Dec 2020 13:47:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 894368D0010; Mon, 28 Dec 2020 13:47:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7AAC38D0017; Mon, 28 Dec 2020 13:47:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id 64B268D0010 for ; Mon, 28 Dec 2020 13:47:59 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 27FCB3629 for ; Mon, 28 Dec 2020 18:47:59 +0000 (UTC) X-FDA: 77643575478.30.robin57_4f1152727496 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 0C2C9180B3C85 for ; Mon, 28 Dec 2020 18:47:59 +0000 (UTC) X-HE-Tag: robin57_4f1152727496 X-Filterd-Recvd-Size: 8385 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Mon, 28 Dec 2020 18:47:58 +0000 (UTC) Received: by mail-lf1-f49.google.com with SMTP id o13so25908081lfr.3 for ; Mon, 28 Dec 2020 10:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ul9Q7F+zVW3PAg2S28tHJ0IR0KNP8kk2DEXpGYeIlWk=; b=KMz20JUoK22L486IVp7caAQRxpZ8S38J8Jj8SYjxbV/2agAn1XdkiISquPYQRJW1NZ BzhkpKZWGzoh12IDv+006ZR9bm3NnfFzCFwKPl2CY7Fp4pA9o8KEXdrfYpWns0a6uB5G 3IE7VhWsbuQlLRJgfgKehWJwyFvcqT3jWXckU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ul9Q7F+zVW3PAg2S28tHJ0IR0KNP8kk2DEXpGYeIlWk=; b=NGh4fqVDUb6IK+notzW52guOKuGI5ied5HTf/yChQkhfwHikv0P/rgGrzStr4aQJ+e Zmk2/WzFOhb2nhwEgbVZyJnj3tRbU+deTbuK0IoCkmChfqI8IeF9EwHYu0yARN2qHW6T 9SVhlFHz8E6vGzdqB+eOWG37TwRc0BKVMXBb/vvAd8N6ojKDr++Nnn7BS448wgiDt6QU M+MkfZr5ANZhH93dW4XM+nk2el4OcNjB3eJAjm4+ZdllZH+6nBx8G5utFI6sBfgsKaSJ LqVJtjME1JtiNX5LtZm6oGLUe4K43A6mkJs+e+Apd/CC3WOlN7WosF8rW714HjdOJgSu IS0w== X-Gm-Message-State: AOAM531gYdp9wksVWFf/yeWatUr8z5jJg3m151FicilA/nRZCjnH+y6K cKBABGCcVIsaBY/UdbtWjwjbrdIdbFHKBQ== X-Google-Smtp-Source: ABdhPJx77cFhTfbOsaX4B593k6B75cdmvG9iIQ6XJtpdv9KsOh7Vs6DPVrSJnO9OxQ8iCKn6poG9lQ== X-Received: by 2002:ac2:47e7:: with SMTP id b7mr18526290lfp.117.1609181276651; Mon, 28 Dec 2020 10:47:56 -0800 (PST) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id b205sm5414163lfg.218.2020.12.28.10.47.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Dec 2020 10:47:54 -0800 (PST) Received: by mail-lf1-f44.google.com with SMTP id y19so25748590lfa.13 for ; Mon, 28 Dec 2020 10:47:53 -0800 (PST) X-Received: by 2002:a2e:9d89:: with SMTP id c9mr23613429ljj.220.1609181273408; Mon, 28 Dec 2020 10:47:53 -0800 (PST) MIME-Version: 1.0 References: <20201226204335.dikqkrkezqet6oqf@box> <20201226224016.dxjmordcfj75xgte@box> <20201227234853.5mjyxcybucts3kbq@box> <20201228125352.phnj2x2ci3kwfld5@box> In-Reply-To: <20201228125352.phnj2x2ci3kwfld5@box> From: Linus Torvalds Date: Mon, 28 Dec 2020 10:47:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting To: "Kirill A. Shutemov" Cc: Hugh Dickins , Matthew Wilcox , "Kirill A. Shutemov" , Will Deacon , Linux Kernel Mailing List , Linux-MM , Linux ARM , Catalin Marinas , Jan Kara , Minchan Kim , Andrew Morton , Vinayak Menon , Android Kernel Team Content-Type: multipart/mixed; boundary="0000000000002e6e5605b78ab6d7" 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: --0000000000002e6e5605b78ab6d7 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 28, 2020 at 4:53 AM Kirill A. Shutemov wrote: > > So far I only found one more pin leak and always-true check. I don't see > how can it lead to crash or corruption. Keep looking. Well, I noticed that the nommu.c version of filemap_map_pages() needs fixing, but that's obviously not the case Hugh sees. No,m I think the problem is the pte_unmap_unlock(vmf->pte, vmf->ptl); at the end of filemap_map_pages(). Why? Because we've been updating vmf->pte as we go along: vmf->pte += xas.xa_index - last_pgoff; and I think that by the time we get to that "pte_unmap_unlock()", vmf->pte potentially points to past the edge of the page directory. I think that is the bug that Hugh sees - simply because we get entirely confused about the page table locking. And it would match the latest change, which was all about moving that unlock from the caller to filemap_map_pages(), and now it's missing the pte fixup.. I personally think it's wrong to update vmf->pte at all. We should just have a local 'ptep' pointer that we update as we walk along. But that requires another change to the calling convention, namely to "do_set_pte()". Also, considering how complicated this patch is getting, I think it might be good to try to split it up a bit. In particular, I think the calling convention change for "filemap_map_pages()" could be done first and independently. And then as a second step, move the VM_FAULT_NOPAGE and "pte_unmap_lock()" from the callers to filemap_map_pages(). And then only as the final step, do that nice re-organization with first_map_page/next_map_page() and moving the locking from alloc_set_pte() into filemap_map_pages().. How does that sound? Anyway, Hugh, if it's about overshooting the pte pointer, maybe this absolutely horrendous and disgusting patch fixes it without the above kinds of more extensive cleanups. Worth testing, perhaps, even if it's too ugly for words? Linus --0000000000002e6e5605b78ab6d7 Content-Type: application/octet-stream; name=patch Content-Disposition: attachment; filename=patch Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kj8wyykk0 IG1tL2ZpbGVtYXAuYyB8IDE0ICsrKysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgMTQgaW5z ZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL21tL2ZpbGVtYXAuYyBiL21tL2ZpbGVtYXAuYwppbmRl eCA0MmQ3YTU4ZTNhMTQuLjc0Mzg0ZjlmMTc3NiAxMDA2NDQKLS0tIGEvbW0vZmlsZW1hcC5jCisr KyBiL21tL2ZpbGVtYXAuYwpAQCAtMzAyMiw2ICszMDIyLDggQEAgdm1fZmF1bHRfdCBmaWxlbWFw X21hcF9wYWdlcyhzdHJ1Y3Qgdm1fZmF1bHQgKnZtZiwgdW5zaWduZWQgbG9uZyBhZGRyZXNzLAog CXN0cnVjdCBwYWdlICpoZWFkLCAqcGFnZTsKIAl1bnNpZ25lZCBpbnQgbW1hcF9taXNzID0gUkVB RF9PTkNFKGZpbGUtPmZfcmEubW1hcF9taXNzKTsKIAl2bV9mYXVsdF90IHJldCA9IDA7CisJcHRl X3QgKm9yaWdfcHRlOworCXVuc2lnbmVkIGxvbmcgb3JpZ19hZGRyZXNzOwogCiAJcmN1X3JlYWRf bG9jaygpOwogCWhlYWQgPSBmaXJzdF9tYXBfcGFnZSh2bWYsICZ4YXMsIGVuZF9wZ29mZik7CkBA IC0zMDM3LDYgKzMwMzksMTQgQEAgdm1fZmF1bHRfdCBmaWxlbWFwX21hcF9wYWdlcyhzdHJ1Y3Qg dm1fZmF1bHQgKnZtZiwgdW5zaWduZWQgbG9uZyBhZGRyZXNzLAogCiAJdm1mLT5wdGUgPSBwdGVf b2Zmc2V0X21hcF9sb2NrKHZtYS0+dm1fbW0sIHZtZi0+cG1kLAogCQkJCSAgICAgICB2bWYtPmFk ZHJlc3MsICZ2bWYtPnB0bCk7CisKKwkvKgorCSAqIERpc2d1c3RpbmcgLSB3ZSBzaG91bGQgbm90 IHVwZGF0ZSB2bWYtPnB0ZSBhbmQgLT5hZGRyZXNzLAorCSAqIGJ1dCBkb19zZXRfcHRlKCkgbmVl ZHMgaXQKKwkgKi8KKwlvcmlnX3B0ZSA9IHZtZi0+cHRlOworCW9yaWdfYWRkcmVzcyA9IHZtZi0+ YWRkcmVzczsKKwogCWRvIHsKIAkJcGFnZSA9IGZpbmRfc3VicGFnZShoZWFkLCB4YXMueGFfaW5k ZXgpOwogCQlpZiAoUGFnZUhXUG9pc29uKHBhZ2UpKQpAQCAtMzA2Niw2ICszMDc2LDEwIEBAIHZt X2ZhdWx0X3QgZmlsZW1hcF9tYXBfcGFnZXMoc3RydWN0IHZtX2ZhdWx0ICp2bWYsIHVuc2lnbmVk IGxvbmcgYWRkcmVzcywKIAkJdW5sb2NrX3BhZ2UoaGVhZCk7CiAJCXB1dF9wYWdlKGhlYWQpOwog CX0gd2hpbGUgKChoZWFkID0gbmV4dF9tYXBfcGFnZSh2bWYsICZ4YXMsIGVuZF9wZ29mZikpICE9 IE5VTEwpOworCisJLyogSGFja2V0eSBoYWNrIC0gcmVzZXQgdGhlIHZtZiBzdGF0ZSBiYWNrICov CisJdm1mLT5wdGUgPSBvcmlnX3B0ZTsKKwl2bWYtPmFkZHJlc3MgPSBvcmlnX2FkZHJlc3M7CiAJ cHRlX3VubWFwX3VubG9jayh2bWYtPnB0ZSwgdm1mLT5wdGwpOwogCXJjdV9yZWFkX3VubG9jaygp OwogCVdSSVRFX09OQ0UoZmlsZS0+Zl9yYS5tbWFwX21pc3MsIG1tYXBfbWlzcyk7Cg== --0000000000002e6e5605b78ab6d7-- 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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF250C433E0 for ; Mon, 28 Dec 2020 18:49:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 57C5F229EF for ; Mon, 28 Dec 2020 18:49:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57C5F229EF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:To: Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=1POtQG/2GyrHvGGHhl7PDwsuU4qia3nDZZu14+89kUg=; b=WFv1IrD6w4axAV9mAvU3vHT+6 YSgKKsETuXPrUXnlBUlVgjWxNq6ppQPAFToNcCfZ3jUKvmQ0OwRLcQasObiryAin3zpq1U90L6eW/ mDvWfxZpIbcuR6jAIkRVbfLb4gqg/HSEPN1DvKmS7B5ymKaZOSUTsHY73GY/ugyGUBJr1tcMM7Tks 48vIwgY2MPeE0XcftclJdqGOHb05XEyPe1yIqSx50OKxonHMZe0fDlSMUPF93cKeaj7mK+MglM8sg k16NRdcXfwQxfHRADcQa6ZknvJaqHtr8t32IWCLa6vnaH6IQjkOZdrxahfVGnBPvZxQhFjUDFrJbc LdsE2vCCA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ktxYo-0006bA-6h; Mon, 28 Dec 2020 18:48:02 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ktxYl-0006aI-BM for linux-arm-kernel@lists.infradead.org; Mon, 28 Dec 2020 18:48:00 +0000 Received: by mail-lf1-x133.google.com with SMTP id a12so25896702lfl.6 for ; Mon, 28 Dec 2020 10:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ul9Q7F+zVW3PAg2S28tHJ0IR0KNP8kk2DEXpGYeIlWk=; b=KMz20JUoK22L486IVp7caAQRxpZ8S38J8Jj8SYjxbV/2agAn1XdkiISquPYQRJW1NZ BzhkpKZWGzoh12IDv+006ZR9bm3NnfFzCFwKPl2CY7Fp4pA9o8KEXdrfYpWns0a6uB5G 3IE7VhWsbuQlLRJgfgKehWJwyFvcqT3jWXckU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ul9Q7F+zVW3PAg2S28tHJ0IR0KNP8kk2DEXpGYeIlWk=; b=FEqUCPDfh2R7KaduF4oqrCk+XRKSy2sGOgViTdFLOuQlHxW6AUn+fHU2akFRj4ai2t 9fdLOA+I8EnEElsFpg0874dLnSISNBs5LD2QpB6kcqejE5ZQKJN789NXwCBMjCUDiTGV PHSv27k5Pra41vp4qhH6DoGmzTL3TaLMt8s1/L49KDCKsuY7zu3AuNCyHQSZQuhHq6g4 h3TC8rkgS4YjoqB0+ai1dw9E2M14wrWzu7iZe4H5hBRO3XwBEWuGn4Kc4yUld9gi84zv Qnsxei4FU+6QVMa2sBh1gJfhVRAHkSK+GqhogtC8i7MRNlOCQTccqB9RAOSatH8Gckw9 OTsQ== X-Gm-Message-State: AOAM533d9k/Mnu8RdzSp1DlsQ1nFZLUOsI5jW/sKjYCwdzmRSZjutSbO MwiE1XQFq59PwRvMOZvTgVqhhb+1H0c8Kw== X-Google-Smtp-Source: ABdhPJyx2xkNqkr9b3k7EPR0aGArGNPfTu4ATmU4tgFRV3DtXoPQr4S307y6CTPzLfwPdzu4AsyZwA== X-Received: by 2002:a19:8053:: with SMTP id b80mr21075780lfd.74.1609181277236; Mon, 28 Dec 2020 10:47:57 -0800 (PST) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com. [209.85.167.42]) by smtp.gmail.com with ESMTPSA id m21sm6422064ljb.108.2020.12.28.10.47.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Dec 2020 10:47:54 -0800 (PST) Received: by mail-lf1-f42.google.com with SMTP id o13so25907764lfr.3 for ; Mon, 28 Dec 2020 10:47:53 -0800 (PST) X-Received: by 2002:a2e:9d89:: with SMTP id c9mr23613429ljj.220.1609181273408; Mon, 28 Dec 2020 10:47:53 -0800 (PST) MIME-Version: 1.0 References: <20201226204335.dikqkrkezqet6oqf@box> <20201226224016.dxjmordcfj75xgte@box> <20201227234853.5mjyxcybucts3kbq@box> <20201228125352.phnj2x2ci3kwfld5@box> In-Reply-To: <20201228125352.phnj2x2ci3kwfld5@box> From: Linus Torvalds Date: Mon, 28 Dec 2020 10:47:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting To: "Kirill A. Shutemov" Content-Type: multipart/mixed; boundary="0000000000002e6e5605b78ab6d7" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201228_134759_520838_F15C8D64 X-CRM114-Status: GOOD ( 23.41 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Android Kernel Team , Jan Kara , Minchan Kim , Catalin Marinas , Hugh Dickins , Linux Kernel Mailing List , Matthew Wilcox , Linux-MM , Vinayak Menon , Linux ARM , Andrew Morton , Will Deacon , "Kirill A. Shutemov" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --0000000000002e6e5605b78ab6d7 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 28, 2020 at 4:53 AM Kirill A. Shutemov wrote: > > So far I only found one more pin leak and always-true check. I don't see > how can it lead to crash or corruption. Keep looking. Well, I noticed that the nommu.c version of filemap_map_pages() needs fixing, but that's obviously not the case Hugh sees. No,m I think the problem is the pte_unmap_unlock(vmf->pte, vmf->ptl); at the end of filemap_map_pages(). Why? Because we've been updating vmf->pte as we go along: vmf->pte += xas.xa_index - last_pgoff; and I think that by the time we get to that "pte_unmap_unlock()", vmf->pte potentially points to past the edge of the page directory. I think that is the bug that Hugh sees - simply because we get entirely confused about the page table locking. And it would match the latest change, which was all about moving that unlock from the caller to filemap_map_pages(), and now it's missing the pte fixup.. I personally think it's wrong to update vmf->pte at all. We should just have a local 'ptep' pointer that we update as we walk along. But that requires another change to the calling convention, namely to "do_set_pte()". Also, considering how complicated this patch is getting, I think it might be good to try to split it up a bit. In particular, I think the calling convention change for "filemap_map_pages()" could be done first and independently. And then as a second step, move the VM_FAULT_NOPAGE and "pte_unmap_lock()" from the callers to filemap_map_pages(). And then only as the final step, do that nice re-organization with first_map_page/next_map_page() and moving the locking from alloc_set_pte() into filemap_map_pages().. How does that sound? Anyway, Hugh, if it's about overshooting the pte pointer, maybe this absolutely horrendous and disgusting patch fixes it without the above kinds of more extensive cleanups. Worth testing, perhaps, even if it's too ugly for words? Linus --0000000000002e6e5605b78ab6d7 Content-Type: application/octet-stream; name=patch Content-Disposition: attachment; filename=patch Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kj8wyykk0 IG1tL2ZpbGVtYXAuYyB8IDE0ICsrKysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgMTQgaW5z ZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL21tL2ZpbGVtYXAuYyBiL21tL2ZpbGVtYXAuYwppbmRl eCA0MmQ3YTU4ZTNhMTQuLjc0Mzg0ZjlmMTc3NiAxMDA2NDQKLS0tIGEvbW0vZmlsZW1hcC5jCisr KyBiL21tL2ZpbGVtYXAuYwpAQCAtMzAyMiw2ICszMDIyLDggQEAgdm1fZmF1bHRfdCBmaWxlbWFw X21hcF9wYWdlcyhzdHJ1Y3Qgdm1fZmF1bHQgKnZtZiwgdW5zaWduZWQgbG9uZyBhZGRyZXNzLAog CXN0cnVjdCBwYWdlICpoZWFkLCAqcGFnZTsKIAl1bnNpZ25lZCBpbnQgbW1hcF9taXNzID0gUkVB RF9PTkNFKGZpbGUtPmZfcmEubW1hcF9taXNzKTsKIAl2bV9mYXVsdF90IHJldCA9IDA7CisJcHRl X3QgKm9yaWdfcHRlOworCXVuc2lnbmVkIGxvbmcgb3JpZ19hZGRyZXNzOwogCiAJcmN1X3JlYWRf bG9jaygpOwogCWhlYWQgPSBmaXJzdF9tYXBfcGFnZSh2bWYsICZ4YXMsIGVuZF9wZ29mZik7CkBA IC0zMDM3LDYgKzMwMzksMTQgQEAgdm1fZmF1bHRfdCBmaWxlbWFwX21hcF9wYWdlcyhzdHJ1Y3Qg dm1fZmF1bHQgKnZtZiwgdW5zaWduZWQgbG9uZyBhZGRyZXNzLAogCiAJdm1mLT5wdGUgPSBwdGVf b2Zmc2V0X21hcF9sb2NrKHZtYS0+dm1fbW0sIHZtZi0+cG1kLAogCQkJCSAgICAgICB2bWYtPmFk ZHJlc3MsICZ2bWYtPnB0bCk7CisKKwkvKgorCSAqIERpc2d1c3RpbmcgLSB3ZSBzaG91bGQgbm90 IHVwZGF0ZSB2bWYtPnB0ZSBhbmQgLT5hZGRyZXNzLAorCSAqIGJ1dCBkb19zZXRfcHRlKCkgbmVl ZHMgaXQKKwkgKi8KKwlvcmlnX3B0ZSA9IHZtZi0+cHRlOworCW9yaWdfYWRkcmVzcyA9IHZtZi0+ YWRkcmVzczsKKwogCWRvIHsKIAkJcGFnZSA9IGZpbmRfc3VicGFnZShoZWFkLCB4YXMueGFfaW5k ZXgpOwogCQlpZiAoUGFnZUhXUG9pc29uKHBhZ2UpKQpAQCAtMzA2Niw2ICszMDc2LDEwIEBAIHZt X2ZhdWx0X3QgZmlsZW1hcF9tYXBfcGFnZXMoc3RydWN0IHZtX2ZhdWx0ICp2bWYsIHVuc2lnbmVk IGxvbmcgYWRkcmVzcywKIAkJdW5sb2NrX3BhZ2UoaGVhZCk7CiAJCXB1dF9wYWdlKGhlYWQpOwog CX0gd2hpbGUgKChoZWFkID0gbmV4dF9tYXBfcGFnZSh2bWYsICZ4YXMsIGVuZF9wZ29mZikpICE9 IE5VTEwpOworCisJLyogSGFja2V0eSBoYWNrIC0gcmVzZXQgdGhlIHZtZiBzdGF0ZSBiYWNrICov CisJdm1mLT5wdGUgPSBvcmlnX3B0ZTsKKwl2bWYtPmFkZHJlc3MgPSBvcmlnX2FkZHJlc3M7CiAJ cHRlX3VubWFwX3VubG9jayh2bWYtPnB0ZSwgdm1mLT5wdGwpOwogCXJjdV9yZWFkX3VubG9jaygp OwogCVdSSVRFX09OQ0UoZmlsZS0+Zl9yYS5tbWFwX21pc3MsIG1tYXBfbWlzcyk7Cg== --0000000000002e6e5605b78ab6d7 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --0000000000002e6e5605b78ab6d7--