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 5162AC0218A for ; Mon, 27 Jan 2025 13:51:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C4F62280150; Mon, 27 Jan 2025 08:51:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BD9AA280148; Mon, 27 Jan 2025 08:51:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7B90280150; Mon, 27 Jan 2025 08:51:40 -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 87584280148 for ; Mon, 27 Jan 2025 08:51:40 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1BF1C160169 for ; Mon, 27 Jan 2025 13:51:40 +0000 (UTC) X-FDA: 83053369560.17.36B64D9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf25.hostedemail.com (Postfix) with ESMTP id 8DF8FA0004 for ; Mon, 27 Jan 2025 13:51:37 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FgDinq27; dmarc=none; spf=none (imf25.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=1737985898; a=rsa-sha256; cv=none; b=hwNPCZBOfxOh7niQhu39rfxeyeblp6NsSmhFgVQxg81RR6mJATujq2chw0Zu98pI/WMUjj i7jiayfb0U3VI6WVl9p3fNQaGSNjiXY/m3hEcVwWzld6GjPSnLvQys5REaDU7Gb8wJvB/6 EA4xOGcuCciBfYZVxS/98ANacRnRyhk= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FgDinq27; dmarc=none; spf=none (imf25.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=1737985898; 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=WwZ8/HRnFmeLDeBnLMF9ALpoQ2i6k+zaF6tYugZOpgM=; b=DB7i8NSWE5cW055dpCerdJzaX5hjxEVKM1algbP+tZDrQvjFbM3WzPL+cwRNmPSVYh7Kr/ c9qcDAzfUqLmJJHko0av/QeADKbqBo7fbfJZOj/5BL0AT8zlG3htXtnfJazNpiSRqpHffy hWd7aob5ZAyMdHi0U+EKx4pB8vUhkiE= 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=WwZ8/HRnFmeLDeBnLMF9ALpoQ2i6k+zaF6tYugZOpgM=; b=FgDinq27ZXj0o5Jh/xG1WqpFSl YEDlGFTOfszJKXSclDHZACtlBRejU+4hdb8TIyPUav4w6BDiO4R6gHW28RKopJv6lc3FsUrFnxhb8 IsggbqaHwqkyss12753HCV1UBZlRcrQCDdkTu7T31YpYFm/58vkXiuW8xp+HEJbRMmftFHSbtbLtt TzfB40gcvvxW+B7MNeG1m5OcmNvjn2bGSv/D4DVvX435W4/HDQZm0eTNIm5nooz2Yma0oiMiQBQbv qJSNxDJSnf3W2/4DmlqjWBfMJjoxbT5IqOSZLPhasLxs/FrzCfv1m7Db172F/BHhc/7p51biE2OFm RWGm8YVQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tcPWY-00000009ToN-17YQ; Mon, 27 Jan 2025 13:51:34 +0000 Date: Mon, 27 Jan 2025 13:51:34 +0000 From: Matthew Wilcox To: Alexandre Ghiti Cc: Catalin Marinas , Will Deacon , Ryan Roberts , Mark Rutland , Paul Walmsley , Palmer Dabbelt , Albert Ou , Andrew Morton , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH v4 2/9] riscv: Restore the pfn in a NAPOT pte when manipulated by core mm code Message-ID: References: <20250127093530.19548-1-alexghiti@rivosinc.com> <20250127093530.19548-3-alexghiti@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250127093530.19548-3-alexghiti@rivosinc.com> X-Rspam-User: X-Rspamd-Queue-Id: 8DF8FA0004 X-Rspamd-Server: rspam10 X-Stat-Signature: sn3rkmogkxpgbkdz6e13h6wdw6wdbknr X-HE-Tag: 1737985897-303096 X-HE-Meta: U2FsdGVkX1+N1iCA3cEw+GVd8WxXXocgyYS48nn7Gy8gVvaMVIuroAxLgEMFyXdNrxycsqIetU6n6UvlfeIc3ZaU1JCRm5PBDAeOCcoiNQB7Wotk/L9RYZWDifimD8fYC4yEYR9jcqHFKf0mxR95bKFd0994qT4Im9BtdhoK1xhCJFkDnvbTpi+euhfLUBSo1O2jpC2OrYkYPd8reuxzyMiegicET3JKsbWzM5mBSbDDStRlvjx36cc0oRJ+3XzT/g4qMxixXXGUvi8vF90NQx8Ayk3a6laCuN9j9gKwcqssIl4LrbAqSvb8eZKt41bb8aCd0lYjo00+8yCV39YZYuMfWq2L8MKsLyIj/TiD150xp4mGOsnMadv56EAt4rp9F7oPXO51IqIza+VqpacJA2laPX2ClM0QlKdmTMs1CfPfm5RUuDZNdafhpG0tes8dDTGGx/NY+pb6dxPSBNbG3nsX782ZBYuMUwD75Xz3RYBM+2emCepjzy6VhlPL1wKUIqCbmSUiS7j9f3q5d3e3x19LIkh7ljF/CpjMTSgsso98Vg8X0qPREg2JlQ1ECt8uZezHRGnrfTz3tuU72EYRjdIgFbYIj6798n/InxUrG1hmaawY2DHLPYo0266cc/fZ6rxQRf2sRMPDvu/TnbV/FyoIZhUDqeURpEhuSq3FRXLCxyp5GzDaSZ0a9XiuEUxtNrRb+SmFWBdZHUuqFjfwB03OROnppBQoeSjubDZ8dQ201RWhze+kv3z0Cnb0Hbl9mauJyXgX7IGzxY5KKjSllkbullKVMaI4UBmy1FEBvzw3m+5L58N0FLKiBhx8WljF0zivNcRYwNyaK2wCgeYdVyTaxxtbBNpMNlFrdI41fk7EAMK6aFbGlyFRu/VuccmIdvzpgGx5rX8JNVjNIjF3io9Hrbf/d1e4sv9l2vZyB5yjB5Vn2KFKEdgAehjyeXZZnbjG/NcgsS0+C5K0Yeg /Z9TNhIQ ERmLvwr+edxjG9/+VluoIDnaoFdHVMO/8p8odZD5NXlGF/JJ651MlhJhuhddrRdcNlpWqqX6JNvm1Wn7TtjL/t+IUNoOwYlvboXHWBuhA20JIP7mBDSzAMtSCqGjyJKk5mRlbsQ1zsBy04w6tUtLYtZPLjCtQ1b4rRH6vDqAwTtKNtSBYmiI9DRjBaa+0yzzAtZvwPNSZjARX9T0cTKE3SYtywwgXstcNrWzh5Zl6ePG3gP4= 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: List-Subscribe: List-Unsubscribe: On Mon, Jan 27, 2025 at 10:35:23AM +0100, Alexandre Ghiti wrote: > +#ifdef CONFIG_RISCV_ISA_SVNAPOT > +static inline void set_ptes(struct mm_struct *mm, unsigned long addr, > + pte_t *ptep, pte_t pteval, unsigned int nr) > +{ > + if (unlikely(pte_valid_napot(pteval))) { > + unsigned int order = ilog2(nr); > + > + if (!is_napot_order(order)) { > + /* > + * Something's weird, we are given a NAPOT pte but the No, nothing is weird. This can happen under a lot of different circumstances. For example, one might mmap() part of a file and the folio containing the data is only partially mapped. The filesystem / page cache might choose to use a folio order that isn't one of your magic hardware orders. > + * size of the mapping is not a known NAPOT mapping > + * size, so clear the NAPOT bit and map this without > + * NAPOT support: core mm only manipulates pte with the > + * real pfn so we know the pte is valid without the N > + * bit. > + */ > + pr_err("Incorrect NAPOT mapping, resetting.\n"); > + pteval = pte_clear_napot(pteval); > + } else { > + /* > + * NAPOT ptes that arrive here only have the N bit set > + * and their pfn does not contain the mapping size, so > + * set that here. > + */ > + pteval = pte_mknapot(pteval, order); You're assuming that pteval is aligned to the order that you've calculated, and again that's not true. For example, the user may have called mmap() on range 0x21000-0x40000 of a file which is covered by a 128kB folio. You'll be called with a pteval pointing to 0x21000 and calculate that you can put a 64kB entry there ... no. I'd suggest you do some testing with fstests and xfs as your underlying filesystem. It should catch these kinds of mistakes.