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 5A29EC433FE for ; Tue, 18 Jan 2022 19:04:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D80836B0071; Tue, 18 Jan 2022 14:04:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D08416B0073; Tue, 18 Jan 2022 14:04:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA9CD6B0074; Tue, 18 Jan 2022 14:04:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay038.a.hostedemail.com [64.99.140.38]) by kanga.kvack.org (Postfix) with ESMTP id A4DDF6B0071 for ; Tue, 18 Jan 2022 14:04:14 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 6E20660754 for ; Tue, 18 Jan 2022 19:04:14 +0000 (UTC) X-FDA: 79044333228.01.9390CB7 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf21.hostedemail.com (Postfix) with ESMTP id 727F61C0011 for ; Tue, 18 Jan 2022 19:04:13 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id x83so80226pgx.4 for ; Tue, 18 Jan 2022 11:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ldKTp6E7VqjIz5n60IX5o6ZyBvDvKwMzZelWXwdNFeI=; b=N/nW52q4LecIp5YWIHrgbN0fbb/ldDzctJkkZl6ph1ZkurwfhgqZqx1xcdANF7PLRn zP10Hp1rnkr5wQC/gwyfRW0tB7aM9dNVQxhf/pxqGVA+GTBJ0OHrdGAyVEPwUAfTPzUF eTVLwrH4B66+L/tjheeSFolyav4/REBZg72ua8DJbpgwvG0yb06x+VjXpJKfIAtGhfy0 tdY+BauAfjcjb+jR/FI0C1+wb6tRWpQ7gf4IMSJCX38h9twCne+Pi37nqx26CeqLKYyI M3M+Wvu+nojDG1kTc/4oYl49N+QcvKetm0akKONQINjQA72xTXzDhTVCC+xae2pqp2PD Yybg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ldKTp6E7VqjIz5n60IX5o6ZyBvDvKwMzZelWXwdNFeI=; b=3YguIBHNBZrJEyM5OzVg3PjAy0VPrDU3tsdZ+PwrpL20EJP0xQ0IgH3JoujttWUl+K Z4ufePk4C30pk9ZYGYUD+qlSU4pITvF/9Kcvxc9iZoCrnEOTKrtnwTn/bRHruIZmN/Vq +Ftl4K1PYnkIDG/d1AdMdIfLy0nCSczyayCj41/mMWNJNAfGYoeRpZRXZZgdH162MsLz 2avIACZq0VSAt6bIXWoZq5k7gYgV3VmCvyNIca6K7+n0yo4VnY4M5weSb/op4geW6lHW VqN7B/oHdwkYZoCoJooOfCEbhNOAHVL88dop8RZ+tjqX4EPqsoew7wZYULPNQk/P2CnQ A0eA== X-Gm-Message-State: AOAM533u4Rmf8xhBUqeMpWwlVS4Pp3e/KYZw2Fhag90ullLY4Ziuo/Ue ec0os45x7ZjLCzehbLFQiSmkjfMPKfhJB1Kvev4= X-Google-Smtp-Source: ABdhPJzPCqeBtqW5igPrkRPR21PzuJBtjjHfsxQaR00EvYTpch8FyH9WexAGfKE3RNJqnnFdstLatcpr61qA8x3GYaQ= X-Received: by 2002:a63:b34c:: with SMTP id x12mr24242780pgt.541.1642532652374; Tue, 18 Jan 2022 11:04:12 -0800 (PST) MIME-Version: 1.0 References: <20220118185354.464517-1-yury.norov@gmail.com> In-Reply-To: From: Yury Norov Date: Tue, 18 Jan 2022 11:04:00 -0800 Message-ID: Subject: Re: [RFC PATCH] arm64: don't vmap() invalid page To: Matthew Wilcox Cc: Catalin Marinas , Will Deacon , Andrew Morton , Nicholas Piggin , Ding Tianhong , Anshuman Khandual , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 727F61C0011 X-Stat-Signature: b8ues3uf6g5m93myi4y5igqpk1rgkd3m Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="N/nW52q4"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of yury.norov@gmail.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=yury.norov@gmail.com X-Rspamd-Server: rspam03 X-HE-Tag: 1642532653-155838 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 Tue, Jan 18, 2022 at 10:56 AM Matthew Wilcox wrote: > > On Tue, Jan 18, 2022 at 10:53:54AM -0800, Yury Norov wrote: > > vmap() takes struct page *pages as one of arguments, and user may provide > > an invalid pointer, which would lead to DABT at address translation later. > > Currently, kernel checks the pages against NULL. In my case, however, the > > address was not NULL, and was big enough so that the hardware generated > > Address Size Abort. > > > > Interestingly, this abort happens even if copy_from_kernel_nofault() is used, > > which is quite inconvenient for debugging purposes. > > > > This patch adds an arch_vmap_page_valid() helper into vmap() path, so that > > architectures may add arch-specific checks of the pointer passed into vmap. > > > > For arm64, if the page passed to vmap() corresponds to a physical address > > greater than maximum possible value as described in TCR_EL1.IPS register, the > > following table walk would generate Address Size Abort. Instead of creating > > the invalid mapping, kernel will return ERANGE in such situation. > > This seems like a very elaborate way of spelling: > > pfn_valid(page_to_pfn(page)); > > which doesn't require any architecture hook. No? Looks like yes. I'll resend later today if there are no other comments. Thank you for the hint.