From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D38321FF7D4 for ; Mon, 27 Jan 2025 13:51:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737985900; cv=none; b=R3wMQ0TPsVXkzo/UPw8tShJFt8ylFLov/vIOAvGLxkDwjt6pCenKZhvu8rhvcI9RSr5L0QnBxwn72SGsv+f62mamgfVNq9eLbylKI47lvJ9E4CwdmEuSsm0FyaKT9czSF0CXm9eegNO3jDQWvnfkLQFRzhVHItkf1Ajk3L/iz6U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737985900; c=relaxed/simple; bh=+etEEMv/VqVub1Gz5bje4HsyrE47OHlFzcFt7ARV8B8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gSvja8aL9EqdE/z40+jU+mkQ/bhl9ShUPgSjr3Fk7fkIsa+oMD/PVDwDaaz3khObedfXDrV0V4Pkr/ySVCOl7ejt+pXu+K6tEl4w1ug0A+ZR0Hf4MNj4iL+0AuhKvFi2QzejUz3a8K0E4Pi6Jj2YxUbMvuFcKho5N13AUkRBn6s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=FgDinq27; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="FgDinq27" 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250127093530.19548-3-alexghiti@rivosinc.com> 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.