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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 26CE1C54E4A for ; Fri, 8 Mar 2024 16:13:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=+3oOn9p1nWd9wLYUzF5s4xKFxQy4D4dPDDLdENiGpSA=; b=GqldvK4+EtTgrd LJKLLjCG+TU5oEknTKQoMmf31ZS88jbQ0OmRetIyANv6ffFXaeBvl/SoHUUFj9MmmkqQ1Pmv7ubPe x+Wt8rVTMJIKud6TAqoryJDH1i8dM3QkvjDF3TzqgL4flRpjV6jDNwmPfOmIM51Y9G57zo9mvhTwn 80tiKl6ANpdHlE7f0tBMjI3x2nJAE8DForQUgWBdYHUk6s3FmK55NAuxW3EikFSDKU2TdeHFlU8ct pyN+Vy7MDNfsTZ4qhUZCcq+ymeWhMv+C1SkOFq/ywBQyWDaLyukNLQ3MuUaq8d2of407ZAR10S1M1 sFplWZ1P5SlJcpI1EW7g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ricqp-0000000A69W-02Yd; Fri, 08 Mar 2024 16:13:39 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ricqm-0000000A678-25qa for linux-arm-kernel@lists.infradead.org; Fri, 08 Mar 2024 16:13:38 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id E4FF4CE2750; Fri, 8 Mar 2024 16:13:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE693C433F1; Fri, 8 Mar 2024 16:13:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709914413; bh=HSmK8y4wZfMaF9zPGuPkWTfpEvKg9sCf44pQ9TfKLKI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=DQW+3eVHqqURvbqP0/pUlvw8/g5/RvwEORqnou2Y7p0rH5IW97csuPRMsZKHuO8wv JbYEgqXWP5gzgqGWLXQJsPVRu03W4kOTpFVHf/a+NrDqQ6kTt874PTcZM7MaMCX+Wr uwqk01eEt3KoUN/1g87iTSANfDlg7aknbs6mxCbl3CmXp5H2Zju1+EmAJPH+YHyGkV MF1oW8QdquOCla/Ntek6cp7x9wqjh3Pse9h8rT8YwxZ9UK1XleHhpluiUFiHintIx4 EyV28on5q+ldFpjpbqOPwYQJVTbkv3HuKdSRFJ6MUfmv1ou5GxPiC69kjgawJlxE5E EGp/9c1Tx8cfA== Date: Fri, 8 Mar 2024 10:13:31 -0600 From: Bjorn Helgaas To: Alexei Starovoitov Cc: Miguel Ojeda , Christoph Hellwig , Linus Torvalds , linux-mm , Andrew Morton , Catalin Marinas , Will Deacon , Linux ARM , Daniel Borkmann , bpf , Bjorn Helgaas , linux-pci@vger.kernel.org Subject: Re: vm_area at addr ffffffffc0800000 is not marked as VM_IOREMAP Message-ID: <20240308161331.GA682898@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240308_081336_969083_A05E4258 X-CRM114-Status: GOOD ( 22.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Mar 07, 2024 at 07:49:16PM -0800, Alexei Starovoitov wrote: > Ok. I think I figured it out. > Please try the attached patch. > PCI address range is managed independently from vmalloc range. This suggests that the PCI maintainers should be aware of something, but I don't know what this means. Can you elaborate on what PCI address range management this is, e.g., what functions allocate from it? Or how PCI should have been able to avoid this issue? The patch is in a generic area with no obvious connection to PCI and no obvious sign of independent management, which doesn't feel quite right. Maybe this is what Christoph is getting at. > Enforce flags and range in ioremap_page_range() only when > the start address is within vmalloc range allocated by get_vm_area(). > Fixes: 3e49a866c9dc ("mm: Enforce VM_IOREMAP flag and range in ioremap_page_range.") > Signed-off-by: Alexei Starovoitov > --- > mm/vmalloc.c | 23 +++++++++++++---------- > 1 file changed, 13 insertions(+), 10 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index e5b8c70950bc..17eb0f974e0f 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -311,16 +311,19 @@ int ioremap_page_range(unsigned long addr, unsigned long end, > int err; > > area = find_vm_area((void *)addr); > - if (!area || !(area->flags & VM_IOREMAP)) { > - WARN_ONCE(1, "vm_area at addr %lx is not marked as VM_IOREMAP\n", addr); > - return -EINVAL; > - } > - if (addr != (unsigned long)area->addr || > - (void *)end != area->addr + get_vm_area_size(area)) { > - WARN_ONCE(1, "ioremap request [%lx,%lx) doesn't match vm_area [%lx, %lx)\n", > - addr, end, (long)area->addr, > - (long)area->addr + get_vm_area_size(area)); > - return -ERANGE; > + if (area) { > + if (!(area->flags & VM_IOREMAP)) { > + WARN_ONCE(1, "vm_area at addr %lx is not marked as VM_IOREMAP\n", > + addr); > + return -EINVAL; > + } > + if (addr != (unsigned long)area->addr || > + (void *)end != area->addr + get_vm_area_size(area)) { > + WARN_ONCE(1, "ioremap request [%lx,%lx) doesn't match vm_area [%lx, %lx)\n", > + addr, end, (long)area->addr, > + (long)area->addr + get_vm_area_size(area)); > + return -ERANGE; > + } > } > err = vmap_range_noflush(addr, end, phys_addr, pgprot_nx(prot), > ioremap_max_page_shift); > -- > 2.43.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel