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 B98F7C61DA4 for ; Mon, 30 Jan 2023 10:53:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 15D2B6B0072; Mon, 30 Jan 2023 05:53:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E7A86B0073; Mon, 30 Jan 2023 05:53:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC8316B0074; Mon, 30 Jan 2023 05:53:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D941C6B0072 for ; Mon, 30 Jan 2023 05:53:56 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A8A49A0615 for ; Mon, 30 Jan 2023 10:53:56 +0000 (UTC) X-FDA: 80411155272.06.96CD00E Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf24.hostedemail.com (Postfix) with ESMTP id EA22718000A for ; Mon, 30 Jan 2023 10:53:54 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ht9m9YFx; spf=pass (imf24.hostedemail.com: domain of prabhakar.csengg@gmail.com designates 209.85.128.170 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=1675076034; 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=FUC6K+TUdMSstlrzdppRdz/QrMCOXm0EOP7+90i1xZY=; b=W6Uu8NfnkqoPmJnvCgdV3gFPqsI6XUuob/FyWsWbOKCyGx4ci4NmEh0Ey5rbbUv1N747ZB k8z2q7xUc5BAKFpdYrMdPBHnc+0R0nR4iKA8zccEzTjMqwPUcQfVAKxcAZA99a7P7gJDf+ BWiFIWYx0/TMJ9pxou5D6FY9QVpveLI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ht9m9YFx; spf=pass (imf24.hostedemail.com: domain of prabhakar.csengg@gmail.com designates 209.85.128.170 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=1675076035; a=rsa-sha256; cv=none; b=MJhgpXHtiW8HEetOzrN9MBlNI065LvxdeeAiNfROMqZnd97A3SR7os/yksUSFg2LCCazHS s5UDQ8zydjMjfLLyfRrsjLbgR1RQkTw6+BajKf5aGd0tr4Gm265Z+ucZy+hlJlXGD91AYw 0rr779dObQ5m244JjkmHbaAPTZEV//M= Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-50660e2d2ffso154349847b3.1 for ; Mon, 30 Jan 2023 02:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FUC6K+TUdMSstlrzdppRdz/QrMCOXm0EOP7+90i1xZY=; b=ht9m9YFxQLFVsUimHeqoJwFOz8qFoSRwZxDiiTuUCr6V9x5I9kzETu5HZ7Rmjy4sEi fZhXb5qv67wtF+fT5O3UuWa+FO1COtdg5e+h2L1kz6syB0Vh/fbc7sY2LvOPYqFgz4JM wPEP8L+Z48T6Y/f7lzkOWKTluCOkEGZ9SxMMaXB4rb+AePPqGO3IckIkQOTgfEGw7zP/ c2Mqi7wWoSXJaPWKSLOS5iLCgUz5XOrtLj7Rjb5HwZyghhU6UVRiQXKGEnbEWzxGOPKo HBisRg6xWKEI08xXgJdaZdfAf2SfbJwAkt9DNzkXrMyp6I1MoYB9R0TN1VDZhpMoLg+F TWfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FUC6K+TUdMSstlrzdppRdz/QrMCOXm0EOP7+90i1xZY=; b=ZfvjHwUjCp2ecjAES08BQskFChjo3mMZ7JQrY/Hh7jxsXXgd5kfC38DDHBHUBbvEWA Os+3IRUwqLHkGbylIjb3ylePY1H/PcbPylrmpjmMAqKJMOlQD7YUcm96hyOiGa9WlK7O AgIxX/f88K4yTSpYS9pEzlFKlDZ4+xVM1iJS3cEauCuH3DBA0Nhgg3OKS4hEbXGGnGFh 3/EytSiwHyIhAfZWmkF4nkvKvBj8s74bKKrx9jeVsaJ4BNA2tufIHEn+nh7uZX7dW9eQ 1fHxRbn2CufEGEgA26f1KWvGb/V3KlEj75EQfXHgnTLldWgF5s0lyNjcCX5wiHQXZHSo uLNw== X-Gm-Message-State: AO0yUKW5yGMgn7Tc1bl2yf5JTjLuphdX8aiK4dSsoQBagJFcnYwDb1+Q g0gzvU3FCPB9H9DSYeLAy93UidvpCfcOV+3qDKo= X-Google-Smtp-Source: AK7set8tcLkYYaI01/h2mGKxIOWC8zR7J8jV7aBtEhF+UBiWCM2HORVPRdg6Bslygx9SHUJanm0vt4LR3QDgRmsbg4g= X-Received: by 2002:a81:b246:0:b0:506:55d9:3a78 with SMTP id q67-20020a81b246000000b0050655d93a78mr1975529ywh.339.1675076034014; Mon, 30 Jan 2023 02:53:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Lad, Prabhakar" Date: Mon, 30 Jan 2023 10:53:28 +0000 Message-ID: Subject: Re: [QUERY]: Block region to mmap To: Matthew Wilcox Cc: Linux-MM , linux-riscv , Linux-Renesas , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , 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" X-Stat-Signature: boq3fjhiu5zweuq5r9i5cw6q8qjqwuk8 X-Rspam-User: X-Rspamd-Queue-Id: EA22718000A X-Rspamd-Server: rspam06 X-HE-Tag: 1675076034-750198 X-HE-Meta: U2FsdGVkX19nw98gtAVLHw+Wh8ng95T0cIjc+0ZOVJ4twkNfyXsOMhNXneIgy662R/1ajXBIMeQTsr9D0RXziW6T7ljntEyePwKec71F5A88wKW1zqIaoG6zuU0HnlpJ7VDNo6ic2XWiqOyACBTaWz9uJXC26ZnRobZITgpRgKQxCL3up/A2LmElte9T33B+QIZSyMQ6M+AanwczeFUaQEgW4z2811NR7wJilTE/vVSQB/x/5g29ttxWgo/80V5p1xMTnw0mCoIoe3KnpGkvEzcDdKPE+KUXp5niKS13U0hbmMj4xXVSBYVUVVjGLQhyO6+T8OrzgK/JBDgo1o6lub1oOkknRrBGaxL15FXYkKUI8+FIEHzfxlYbTnRUc8ukgLCKbB6oLxSjDooaPoKxxN95wvFwqbC7GBbauWKxdsVanvPuPLEx4kYD5F+t2PmrB2pxoNy4EZjlgG7Ygvbix3t0B436Rm9rOp1kC3n+GzFljCg5lZr3IikWlNcAsRlhtXTB3KPMts4EbYzUPiT7qEeHByas/Sw5hyEouadQL1r4TCnS4J9HYM86KlyCWl99XFNOOAXF+GzNlaOE3iu7dwoCeUTKoOcegRAowJODAJW3Z4OFrSgxv2NVvSLGFE7j62Pu3+drjMsV17T1FxS7K90YPAaeWkaoPeemlbdvEwLcMESMgGsIsbMGP30fvn3N3XbmzkW2moPGjtYLsDT4B7zpd9N8VTBMgJ79D9heqD+AnNY+CbPw19oCvoro8COODeVaM3W0O7/w2v5EFcT73FDW5xAas1AkDz+CcURIe8oToSfmNqD1TibiZ47mQoHqrWzozx2Uuon0l98K0ZkAEjsCOFX+dVjgsYIThTcPTR+gfk0QIsT5l1JrA6ptfDx4LY7T/oT8D06bAZ7VnsPeqtmLkt/tsrI0Jc34q0P/YM6U3skZHE+0uSOyYIdmG8DDdpeMi95NxCth4rL79TE IdS1vbYC yoGbKcZ13x0IXdGytqBXzmdGMNsbIBdBUyJvM5aeifEY0HRLp0fsT+534+pJHMLN5FXXJz9GdImgBNcPPnsD3oYLfhgflryvgF/73lGrEiFrGrLGcob0UgCAM059vltedxXrk2ka1cvxIDQInB8Cgu9wgo38ouaFS5e8EVhzWC1cUpRnRxV2PsHY5SHJ8zb5Z/xKk++e+KNUmonbuC3i0OsXz4rWDl9Qziz9fuX7xF7DlXNvJ10bqeiejuoXKEfnnYWOnJrQDNMFr9Agh9Gds4tddpLByeCTGbjhgtXk2J1uNofy2CdWHFxhjehIooxQpmq3JT50rQJ6cyzDg+8FS93KuX7nmp/dSoORnycw+YJP3ZM+WCwt92ArUYYRzqQmRRre7iju3qIzeKbHr+UOyZ0q6CySkPVrx0pgWo7KhsYA7G3Lf3cymFUGGRcM6ay3df+7ZahGWElP6DRzxY/K8iWAAxheJLiWg1vD5J23GRWqat+IJmXpddgdoXQ== 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 Matthew, Thank you for the feedback. On Thu, Jan 26, 2023 at 2:37 PM Matthew Wilcox wrote: > > 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. > Basically we are making use of the memory protection unit (MPU) so that only M-mode is allowed to access this region and S/U modes are blocked. > > 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. Do you have any pointers where I can look further into this? > We'd want to make sure it doesn't appear in /proc/*/maps and also that > it can't be overridden with MAP_FIXED. Agreed. Cheers, Prabhakar