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 B9BA3C54EAA for ; Wed, 25 Jan 2023 12:30:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 11AB16B0073; Wed, 25 Jan 2023 07:30:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A4196B0075; Wed, 25 Jan 2023 07:30:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E600D6B0078; Wed, 25 Jan 2023 07:30:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D176E6B0073 for ; Wed, 25 Jan 2023 07:30:41 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B3B131A0D65 for ; Wed, 25 Jan 2023 12:30:41 +0000 (UTC) X-FDA: 80393255082.25.ECA7D77 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf27.hostedemail.com (Postfix) with ESMTP id 1010440021 for ; Wed, 25 Jan 2023 12:30:39 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=AsBm6dEO; spf=pass (imf27.hostedemail.com: domain of prabhakar.csengg@gmail.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=prabhakar.csengg@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674649840; 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: references:dkim-signature; bh=gTVJ5IeBy0z9R5c5aNjfyFKovOA3r97gzXqNSx0yexE=; b=2Lsf4+8o0LgzKrX5pAYuGLh7CaxGHyV2X559BtioBzq8OUqwvcilToTHQSZHxRnwpQVknV qLAl7pe6tfSCQknX1rzbb/ljuIbgfz7FlfmIRp4cF7fz4gkJO65tt7u+w71sj/dGOIcFPL wsgufn0A80TeF2vDIKvERfCd7lIpwjQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=AsBm6dEO; spf=pass (imf27.hostedemail.com: domain of prabhakar.csengg@gmail.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=prabhakar.csengg@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674649840; a=rsa-sha256; cv=none; b=gepdl3HGgRB+fl/HgLvmf2wSgRRgdf5BCqmYXOSZ5ZBnTzqwSLo++BMXp6lVnz6fQlC47k RPvjx70HhYVPbazLXTmZWoGPsEzkX7TIiUqU4vycdprx8R34jJYJpk/Ns0Ez2sxCctV/bG hmHw9/sw5Vh39UkXfsMaPgydAKJIy14= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-4c24993965eso260730817b3.12 for ; Wed, 25 Jan 2023 04:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gTVJ5IeBy0z9R5c5aNjfyFKovOA3r97gzXqNSx0yexE=; b=AsBm6dEOEuSBgIj7OsJAOnftvKkT6rBN6P2wzlFIKn3kR8YGtxFPJooMQn/sYVLvky /b6Mdw4nrVBYlg69L+8bWvqct9IlyOhzunrixHPlUe0D3rOnVXoYtZM467trNOF6yMsi sLhMRcodynBeNI6DYVMAzDREo9c+1o2DEgiWlm6ozysyiUPMgJcQvkAlVaaEajtVRNJP oj1odxsyYvR8YpHvqjVcRQf7Xwyx55GeAv+ar4IB0Ni0eZPxlmKq6yrPje/Ruwi3fxWM 59h7/YZdMZ/Ldy6HGbmcKXQTgfKJa4W4GrnBjr7DVX2ajeCoip5khf6Qg/+E4anSMz9Y t+rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gTVJ5IeBy0z9R5c5aNjfyFKovOA3r97gzXqNSx0yexE=; b=Oy6GUrywwNOp5SYqtRqOcDM6QUmjKfXJm6Wl0zVQycL7QbVAFOQrzUhfKC0aLLn7at DN9g8Hm9PQNLCAheZ8C8au5BJfCdnzrUnyQWiW+jLuLUd118IQsBf/c7PapbpGN31WG1 f8E0ovpqJrrqAl4klhpBQWSqQ6+OaGYZjoVWuyjDt1bd1x2AE7nHFQiB1weJY9wlz0QE qW2YGyoHnd5Olz2QjklO5fncitP/V5U97RLpSxHoGxhPEAgBynJtR1+aDWH8fhrPH/kg OD0Q7cUn6TA4Siv2WRrLoQe7cpbquTe2uyupkSdQv+G6vWT4cb4Izm3+e4aa111gyqCX mRQw== X-Gm-Message-State: AFqh2kr6OD2AIp7Mm08liMcV6bUCYvH4/6XesXGpg1BjE3QYNe4O7Mvc XszrtbAvG3LJKEvFmTtsetcL83sPlyw06OWsAy4nf0wCsHeVUcKG X-Google-Smtp-Source: AMrXdXut2HOW6nQLQPB79z8MmIxPOz8DnDv0LgpXrdDm5LiUzPvokqudwvptpL2xy0l3DxSJcVaiA90Cebe+1eBbFzs= X-Received: by 2002:a0d:c9c4:0:b0:461:bf16:bb9f with SMTP id l187-20020a0dc9c4000000b00461bf16bb9fmr3701514ywd.105.1674649839044; Wed, 25 Jan 2023 04:30:39 -0800 (PST) MIME-Version: 1.0 From: "Lad, Prabhakar" Date: Wed, 25 Jan 2023 12:30:13 +0000 Message-ID: Subject: [QUERY]: Block region to mmap To: Linux-MM , linux-riscv , device-tree , Linux-Renesas Cc: Palmer Dabbelt , Arnd Bergmann , Rob Herring , Krzysztof Kozlowski , Jessica Clarke , Geert Uytterhoeven , Fabrizio Castro , Biju Das , Chris Paterson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1010440021 X-Stat-Signature: xaoudtts53jemu6cbpwj8hsyd9isnz7q X-HE-Tag: 1674649839-532744 X-HE-Meta: U2FsdGVkX19fRhgePMmeuqPTaSGILcqt33hL14nlP1f+F+BeTHcj80BVonUaEY12sn04pTIVnTsDq1QI0/+JqCANxD/0XC5SvBs4cErs2LXSom6W690bc1BCFNkBKvgUYW2mvIxARQEBvSU9p1L9+3aIpudklEuo0fVXVWnHoO5kQJTjUuxGF/fEjA6zC5KuOaPMG6Ws0dOamBia042P1qHb6wkVG37wrMNw68AxMvgyc2rgtCPjqZMPm1jJcmGBZ01o9p/Cl3Uns+S9z5NzBdh6FQHQyFQbgdeI7FUIXGjFPiL6M3JB2G1yk8Czaa9DbSagEETZmgR4FXvbNmO0wH32C9OATf2uQBj9CPzjFm/cyXjGsqKgS15SA9Mgp8FLl9vIwWxwHPE+Sqvd01/NawQTT84hcJm8q/HZ4ECJjD5jP6jnIbnNoVxq1M0s7iVK1D21ZvMkL6cwIo1iXTPh9EXKglDxzCdwbErSwlEmkzJlqmGblBnjN3GjL+zwV1zCw5+c0ik/Ko7GfqYuIWEfWXvHHiiWd5xv/8/W07KZ0nGSxS8+RxzXoao5gGGj4Zl0OMfwxcd4CiXGqHFAmzuG/7SN1QbzX2/0uKUZNHHr7clxPBcP9gN7isOdttLA069PTYoHgUtuW0o3A1uxJtvkrcwIx3YAPYb0SJ30dW1eC5MuVxiyaHtHkh0/KQFQYFZTl3Z17a8eD2tZWzE/rQjSq3um8Memgf8THUGsIXktt0nWb/+S1nK3W07yhxlMg/PLrKqkAJdP/OV8ibEIQc7oGj0cFDqcKabbu6cJXTMcbSl5Ux/wXswo8Nf5inmMQbRBmyPWJ2QnZPWu8ZX95rLnUKmjnchpxypp5ilMzsUQdeZMF30IEewvx5BZ6EHgf5pFywNsn4bML0wzpjBRSEelQKIDGjDLcVySHNjhF59NDyV9uabwWcsB5cgv+vunI/9RuLEMOc6Y+9bfYoLRwkd VkwEAmqf zp8Vs5cHUOJsuoocnu5kwTFhaeVFzBBXHJdsOgNPAKBKHta/vGhDAECXVMdlhs3rv5zywMznBLx7nKMMz7CbnOUlB0CS+x1Qw4M3fAwYaeCGu24RWlb5U3FSDVSozjkCsAujwOA1xKAQuZmmScuLMGS2c/oj9uBgH/JJVgvqvknykec58yqvAH95EnO+XIN5Q9m+1D2UD966Mpmuksoh34JQouhCIhaW3lg3QXzaRzqtt0onIB7HnNPsKsjh+ez0B0nx+/m7+yAWhBFVcPHhRfwErVGa3GhCzDxxuWuAdhk7Mw+JcWOotrMs2sqTiiY2VCPgFb1FfFnrD11YYLZCwKoAWlp36/B5uzdQxHr/FYNpDsMunZ7B+URWBZDK5hvtppp6Ei2Jlq7DBtPFtSX1aQTPZXUxeV4j1qSNr4+F8/GOpxkWFZrOpMOrmvFKAbOChYJ7EUAGWwJ+1AejOVYlL3Hbj8uJ1J43n8zrb 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: Hi All, 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. 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. 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. Tracing through the mmap call we have arch_mmap_check() if implemented by architectures this callback gets called and it can be used as a validator to make sure mmap() to the local memory region fails. (Note maybe this callback can be implemented using ALTERNATIVX() macro so that other RISC-V SoCs do nop() to this callback). This approach seems reasonable but isn't a generic approach. For other platforms with similar issues will have to go through similar implementation. Instead if we define the memory regions in the device tree that aren't to be allowed to be mmaped with this approach the implementation can be generic and can be used on other archs/platforms. Looking at the kernel code SPARC architecture (UltraSPARC T1) also has a hole in the virtual memory address space (relevant commit-id to fix this issue 8bcd17411643beb9a601e032d0cf1016909a81d3). As this VA hole =E2=80=9Csupport=E2=80=9D has been added a long time ago no= w, and maybe simply replicating their approach is not acceptable anymore hence the proposed approach. Is there any better approach which I am missing, any pointers comments welc= ome. Cheers, Prabhakar