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 2D5F2C05027 for ; Thu, 26 Jan 2023 14:38:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A17F8E0003; Thu, 26 Jan 2023 09:38:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 951C78E0001; Thu, 26 Jan 2023 09:38:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 819C58E0003; Thu, 26 Jan 2023 09:38:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7441A8E0001 for ; Thu, 26 Jan 2023 09:38:02 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 18F39C06FE for ; Thu, 26 Jan 2023 14:38:02 +0000 (UTC) X-FDA: 80397204804.30.64D2B25 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf03.hostedemail.com (Postfix) with ESMTP id 29B7320014 for ; Thu, 26 Jan 2023 14:37:58 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=IhoqLpHc; dmarc=none; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674743880; 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=v5lRST3UhBT0bHTWLRn+IKxRT3Fm30qCFhm6PJyxMIA=; b=GUZC0QPgyFnABIHmwacNiBgHe/yryEN/6znQu729kW56HIUjyp1SvGbtSvIOLwVGwQSrfB 77YGBJanZeFnZTiLAJ/Emf/934vhhGVCplodRFyxoOH6Q92gJZuQff2IWytrhhyICIiZek Ni348UkJnqpVCLq6VT/egwAgbz/WGYk= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=IhoqLpHc; dmarc=none; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674743880; a=rsa-sha256; cv=none; b=JDuk6fexCSYDatY7kdbbIVCiT8QzyQSCS+Obq5lZmo3AXG0xzQW1DGMRO5itoNG6na7yqm sJiVEsbJh5ov9erqV3lTWw/oNX7RR31vHwwtW5KtNo4EB2TUJYnuq7oEY5rVZPot2gxe0O DFzc2phlyY4dhiwEPo7YLu9FoA9GW3E= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=v5lRST3UhBT0bHTWLRn+IKxRT3Fm30qCFhm6PJyxMIA=; b=IhoqLpHc6jxkTvFzdHxeJ+ZYim 1I7vODMn698IB/zXrwXRkm7oe3KykWcJltyUDuClBppjzwKhcKo6mIH8LWoeiZSgTZkh0g8PuPAF7 SKBjuWJBTQXLU3Nk1yUPafBTBLWwXUXNBoY0VmzPviNIdHxXME070k779dIeTza7UKSsqvSJGUB+O RJQ/rF0/HqknHKnfsMJMBwKPysHHE5vMeYZUxmu2n00HzT5xE8UnnHPpOYmdHtS4x2Mpql3O/Pg8q I46BNMEwEK19kWHE9UfWLluLiY+PX+a7mCRvFnuwm1My70xy4B2urvXQoH0De/GEAGI5U0eqGvJlK CywF3kGg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pL3Nv-006oVa-FN; Thu, 26 Jan 2023 14:37:51 +0000 Date: Thu, 26 Jan 2023 14:37:51 +0000 From: Matthew Wilcox To: "Lad, Prabhakar" Cc: Linux-MM , linux-riscv , device-tree , Linux-Renesas , Palmer Dabbelt , Arnd Bergmann , Rob Herring , Krzysztof Kozlowski , Jessica Clarke , Geert Uytterhoeven , Fabrizio Castro , Biju Das , Chris Paterson Subject: Re: [QUERY]: Block region to mmap Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 29B7320014 X-Stat-Signature: zzs185hgjxy1tto9ujo9iu9abawydrr7 X-HE-Tag: 1674743878-840575 X-HE-Meta: U2FsdGVkX1+xEsI/gVORm5nr4/bBEFrLEnSGl/ki0m6Qk5CtuGmPkV2vVDKFitMpNgvPCbQXBFbm0ZBujbpepmQYuq5rvW79kBkYUtLmitvDLAXT4UKs/p1LYpFU9W5HU6AeXQ2Ys1g/RTBD/q6cGArD1PXSL/DwdLJo7YWbJ12+8xqADuXqDVknRuk2HqTz+qnsdpzIta/0G6SuLOaqKVctbzqGa0vSHgHCRpAOA93dPaxd7KhsK/r9KgYIU3GSx3l5cKBo4/GTsCDL4DN4/JYFLgHWV4Rb6BTQzLAkxLPuDCc7/uoBKoox5MzTTe+2i+f2Wf++V2CtWZe2y0jLuzKLYOq5ds3CUSuLuJSph9AsQ9MmSNSUmRdjt9m9n4rivvXKmP+nhJ7JwsKLvUYHJH1Idc0Zci2MFlJvXBPE9724qmDSJcvuZon0Y8Adah7RTreQ7JfgyQEQJS30b1SBUkx7oEBwJgyRuxDM88FkBHGvqVO4Ny8tiB/nrU94EI1GPGbWs9qtXyqf1RkdUu+Poj0jQuWRDBc0owktBryrFcHNzvnLRVveel2u30sCbK+VdQ+fHytPmbHJYwWHpYmzDL3xVxqxGOYx69pKBaxHwxsN18fP9nc3su1/cda81VkrRqcW9gLpCtkQp0kpnO4J2pW1/ijxEfchoaTt5G1k1WWhUn7XvxxYter2lihsaUIxBNYaRTjhrV01qyaFyODgyDQeJygxQEqzxCRttrHp5zVeiqOsAErC3cB+raDqtCpOGS8S0GyNyVDXWxJzAvdNgd1AdJMf8e35SMhoXorZpVFEg8lXdexnBu5WI8aU95da6JF8of9CE5oExJfY2oplnM/QUuygGafaWM4lMnPi3Nd29VPo2mGEQW0TaNua317stW3kNYHi1SpayFVPpoh509Zalo8Z1J00ROWaF5DQLN+3am4NCdZLCIs8y3nsEu9pKiCkEsVMqK5iAOZNCRR Y8l0XD5G bCeoHk4jtV4YLEzm/qNKw7m2HcCFP8bDakOsCnbM4S0MwEHmQPMh+RJ3go5OJsIT3TzCuQJ9r0W0eDZqjR982pDv7lGTzCDl2xZShY3LwKnJI2f/Y9W2wUHbhv/WhEgvjRo67ZmDDLOUhom1ZL6U93QoTQjYkJ8tWJ0dJFqXijpAXP1WnNc3eBaHIw3PVAc9aBzLf 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 Wed, Jan 25, 2023 at 12:30:13PM +0000, Lad, Prabhakar wrote: > Renesas RZ/Five RISC-V SoC has Instruction local memory and Data local > memory (ILM & DLM) mapped between region 0x30000 - 0x4FFFF. When a > virtual address falls within this range, the MMU doesn't trigger a > page fault; it assumes the virtual address is a physical address which > can cause undesired behaviours. Wow. I've never come across such broken behaviour before. > To avoid this the ILM/DLM memory regions are now added to the root > domain region of the PMPU with permissions set to 0x0 for S/U modes so > that any access to these regions gets blocked and for M-mode we grant > full access (R/W/X). This prevents any users from accessing these > regions by triggering an unhandled signal 11 in S/U modes. I have no idea what any of this means. > This works as expected but for applications say for example when doing > mmap to this region would still succeed and later down the path when > doing a read/write to this location would cause unhandled signal 11. > To handle this case gracefully we might want mmap() itself to fail if > the addr/offset falls in this local memory region. No, that's not what you want. You want mmap to avoid allocating address space in that virtual address range. I don't know if we have a good way to do that at the moment; like I said I've never seen such broken hardware before. I'd say the right way to solve this is to add a new special kind of VMA to the address space that covers this range. We'd want to make sure it doesn't appear in /proc/*/maps and also that it can't be overridden with MAP_FIXED.