[{"id":3675824,"web_url":"http://patchwork.ozlabs.org/comment/3675824/","msgid":"<66eb23bf-1995-363f-78e6-f5a397a063a2@linux.intel.com>","list_archive_url":null,"date":"2026-04-10T11:14:55","subject":"Re: [PATCH 13/20] alpha/PCI: Clean up __pci_mmap_fits()","submitter":{"id":83553,"url":"http://patchwork.ozlabs.org/api/people/83553/","name":"Ilpo Järvinen","email":"ilpo.jarvinen@linux.intel.com"},"content":"On Fri, 10 Apr 2026, Krzysztof Wilczyński wrote:\n\n> Currently, __pci_mmap_fits() computes the BAR size using\n> pci_resource_len() - 1, which wraps to a large value when the\n> BAR length is zero, causing the bounds check to incorrectly\n> succeed.\n> \n> Thus, add an early return for empty resources.\n> \n> Also, remove the WARN() that fires when userspace attempts to\n> mmap beyond the BAR bounds.  The check still returns 0 to reject\n> the mapping, but the warning is excessive for normal operation.\n> \n> A similar warning was removed from the PCI core in the commit\n> 3b519e4ea618 (\"PCI: fix size checks for mmap() on /proc/bus/pci files\").\n\nThis looks like entirely separate two changes to me which just happen \nwithin the same context.\n\n> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>\n> ---\n>  arch/alpha/kernel/pci-sysfs.c | 14 ++++++--------\n>  1 file changed, 6 insertions(+), 8 deletions(-)\n> \n> diff --git a/arch/alpha/kernel/pci-sysfs.c b/arch/alpha/kernel/pci-sysfs.c\n> index 7aac5e76dcd6..867199b988de 100644\n> --- a/arch/alpha/kernel/pci-sysfs.c\n> +++ b/arch/alpha/kernel/pci-sysfs.c\n> @@ -37,20 +37,18 @@ static int hose_mmap_page_range(struct pci_controller *hose,\n>  static int __pci_mmap_fits(struct pci_dev *pdev, int num,\n>  \t\t\t   struct vm_area_struct *vma, int sparse)\n>  {\n> +\tresource_size_t len = pci_resource_len(pdev, num);\n>  \tunsigned long nr, start, size;\n>  \tint shift = sparse ? 5 : 0;\n>  \n> +\tif (!len)\n> +\t\treturn 0;\n> +\n>  \tnr = vma_pages(vma);\n>  \tstart = vma->vm_pgoff;\n> -\tsize = ((pci_resource_len(pdev, num) - 1) >> (PAGE_SHIFT - shift)) + 1;\n> +\tsize = ((len - 1) >> (PAGE_SHIFT - shift)) + 1;\n>  \n> -\tif (start < size && size - start >= nr)\n> -\t\treturn 1;\n> -\tWARN(1, \"process \\\"%s\\\" tried to map%s 0x%08lx-0x%08lx on %s BAR %d \"\n> -\t\t\"(size 0x%08lx)\\n\",\n> -\t\tcurrent->comm, sparse ? \" sparse\" : \"\", start, start + nr,\n> -\t\tpci_name(pdev), num, size);\n> -\treturn 0;\n> +\treturn start < size && size - start >= nr;\n>  }\n>  \n>  /**\n>","headers":{"Return-Path":"\n <linux-pci+bounces-52299-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=U3UsNCv4;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.232.135.74; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-52299-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"U3UsNCv4\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=192.198.163.8","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org [172.232.135.74])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsZ374cZ8z1yGS\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 21:15:15 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 32286302B974\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 11:15:11 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 319FB383C66;\n\tFri, 10 Apr 2026 11:15:09 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [192.198.163.8])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id A9A453BAD87;\n\tFri, 10 Apr 2026 11:15:07 +0000 (UTC)","from orviesa001.jf.intel.com ([10.64.159.141])\n  by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Apr 2026 04:15:07 -0700","from ijarvine-mobl1.ger.corp.intel.com (HELO localhost)\n ([10.245.244.118])\n  by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Apr 2026 04:14:58 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775819709; cv=none;\n b=QEH+z0CnfJBFz2I508XB1gwUqQtyP1NSHVRbjZRm0ZtS6ylBvPTehbzaApVeUjDSOaJ6AmzVCGsw24LuxWiIZqOvu0TZX3h948P4rEs288cps/8ikARbNmoQ4IYvCMls6B2q0gPOHdJ7W+zBQi6EtUMsPahbO1BJXzro+xWxdro=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775819709; c=relaxed/simple;\n\tbh=LQlh8I55FJSDZdIW0plgYRYVBRUjST2rjdHoYnP/X9g=;\n\th=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=AHClCPu1fWxe2msj7VdeZJZ8Tc53sai6/HuDFBhT2/eieouonhErDbtfd60W8dkZEMrDD5zcc57jP4LSOKJiYJru0rhI/cfVhVv8SvI1VcvsIUAjyk3auVDzSRb3Py8jaMSE2LELpUVHNpK7Sv+Z/MhowRlJnr5qYFFyKd3Nw7M=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=U3UsNCv4; arc=none smtp.client-ip=192.198.163.8","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n  t=1775819708; x=1807355708;\n  h=from:date:to:cc:subject:in-reply-to:message-id:\n   references:mime-version;\n  bh=LQlh8I55FJSDZdIW0plgYRYVBRUjST2rjdHoYnP/X9g=;\n  b=U3UsNCv41jhJAKcIXkshJVvck///8mho4EY4szMD2yyWPTht9x9RzceF\n   dMhuc7vJOAhoU8VsxnXK9J7795N4MVTss8x4qiY5bCPaoDJ3nPQ63Zq5b\n   BMhriVgUfmehFmvwFyc6lwwOVT9WM44HDIiRF2rpQqhyJLN76Iec3DNDn\n   Y3An7jomv+SbgSrahqXMIDbCfkMjeM7fXS1+hr++si2CV6cagO8FcjsxR\n   mFVUrNfeZpqA8qEsi3zjFl+J57McG1pGRXyZgJBw7cZbYbsT+HNdt76MY\n   9qgpyAMlVWogBa8hw2MX0M/XnKR+NYVAgsRtEfbyadHKWCYs/gMKFrA9W\n   A==;","X-CSE-ConnectionGUID":["ZBsjoM83TRaIVqR51r+ZHQ==","XwV8+G46Tz+BFYBFlBtq8g=="],"X-CSE-MsgGUID":["TnwaurmVQNWToZfW4OH7pQ==","z5AtohwQS8qN4xrUHCo/DA=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11754\"; a=\"94415842\"","E=Sophos;i=\"6.23,171,1770624000\";\n   d=\"scan'208\";a=\"94415842\"","E=Sophos;i=\"6.23,171,1770624000\";\n   d=\"scan'208\";a=\"267023344\""],"X-ExtLoop1":"1","From":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>","Date":"Fri, 10 Apr 2026 14:14:55 +0300 (EEST)","To":"=?iso-8859-2?q?Krzysztof_Wilczy=F1ski?= <kwilczynski@kernel.org>","cc":"Bjorn Helgaas <bhelgaas@google.com>, Bjorn Helgaas <helgaas@kernel.org>,\n  Manivannan Sadhasivam <mani@kernel.org>,\n  Lorenzo Pieralisi <lpieralisi@kernel.org>,\n  Magnus Lindholm <linmag7@gmail.com>, Matt Turner <mattst88@gmail.com>,\n  Richard Henderson <richard.henderson@linaro.org>,\n  Christophe Leroy <chleroy@kernel.org>,\n  Madhavan Srinivasan <maddy@linux.ibm.com>,\n  Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>,\n  Dexuan Cui <decui@microsoft.com>,\n =?iso-8859-2?q?Krzysztof_Ha=B3asa?= <khalasa@piap.pl>,\n  Lukas Wunner <lukas@wunner.de>, Oliver O'Halloran <oohall@gmail.com>,\n  Saurabh Singh Sengar <ssengar@microsoft.com>,\n  Shuan He <heshuan@bytedance.com>,\n  Srivatsa Bhat <srivatsabhat@microsoft.com>, linux-pci@vger.kernel.org,\n  linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH 13/20] alpha/PCI: Clean up __pci_mmap_fits()","In-Reply-To":"<20260410055040.39233-14-kwilczynski@kernel.org>","Message-ID":"<66eb23bf-1995-363f-78e6-f5a397a063a2@linux.intel.com>","References":"<20260410055040.39233-1-kwilczynski@kernel.org>\n <20260410055040.39233-14-kwilczynski@kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"multipart/mixed; boundary=\"8323328-133140870-1775819695=:1195\""}},{"id":3675830,"web_url":"http://patchwork.ozlabs.org/comment/3675830/","msgid":"<20260410112132.GA1756033@rocinante>","list_archive_url":null,"date":"2026-04-10T11:21:32","subject":"Re: [PATCH 13/20] alpha/PCI: Clean up __pci_mmap_fits()","submitter":{"id":86709,"url":"http://patchwork.ozlabs.org/api/people/86709/","name":"Krzysztof Wilczyński","email":"kwilczynski@kernel.org"},"content":"Hello,\n\n> > Currently, __pci_mmap_fits() computes the BAR size using\n> > pci_resource_len() - 1, which wraps to a large value when the\n> > BAR length is zero, causing the bounds check to incorrectly\n> > succeed.\n> > \n> > Thus, add an early return for empty resources.\n> > \n> > Also, remove the WARN() that fires when userspace attempts to\n> > mmap beyond the BAR bounds.  The check still returns 0 to reject\n> > the mapping, but the warning is excessive for normal operation.\n> > \n> > A similar warning was removed from the PCI core in the commit\n> > 3b519e4ea618 (\"PCI: fix size checks for mmap() on /proc/bus/pci files\").\n> \n> This looks like entirely separate two changes to me which just happen \n> within the same context.\n\nTrue.  I could split this into two separate patches.  However, the early\nreturn is so trivial, that I decided to keep it here, in lieu of that the\nlinked patch did, too.\n\nThoughts?\n\nThank you!\n\n\tKrzysztof","headers":{"Return-Path":"\n <linux-pci+bounces-52301-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=aNkWsMkv;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-52301-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"aNkWsMkv\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsZBW6PMcz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 21:21:39 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id C82DF3014538\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 11:21:37 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 235DE398918;\n\tFri, 10 Apr 2026 11:21:35 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 0005C3368AD;\n\tFri, 10 Apr 2026 11:21:34 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 2DC07C19421;\n\tFri, 10 Apr 2026 11:21:34 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775820095; cv=none;\n b=HjKXygDybq0KpnZQQqyjvL7bWPSN21IAtLT1ZNE7zbjyj5AJaIn7MD1BhycCEua9NZAB4bVwT3pESXwMuGz3umruqzCgzH1Kv64LIqRZ6LuTcvsoPAakKTxn+FA7Bq/gspiO4JalMgBZ2dkjaGFbBX5uDhe/9cYpb8vWqIxUQm4=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775820095; c=relaxed/simple;\n\tbh=xLa+rJ9E7aCqjS27Iq/hgGnSH2oHxIMaRffEJnqkauE=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=Sm1KW/uU1dJ3gVKwVaACrSkz1HBrH2hL+tUEzAhbuS8JK14ywbLgjAhInU8fPgP9nbsF/yik27sXRfsEKoV+iJTHO/TajJOwpVmZDrpUb2/rquMQJUew2p+HuUY920J3tgIcPGgso1A13DgiVhGpkVYx2jMgLMJzFUtUb3dHfNw=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=aNkWsMkv; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775820094;\n\tbh=xLa+rJ9E7aCqjS27Iq/hgGnSH2oHxIMaRffEJnqkauE=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=aNkWsMkvMG+Va6sAFKXUZym1llx13MYasPeV+K/sG2YsNB5fhSi1QGBWHW0lr8cEe\n\t Ev40On4E48kLxL4u5xdErZMqk8eBFmaEvlczXiYn844NLVvbOf+5VF6GQjp83Cd6RR\n\t URaOH6uyIvSnEz0s89g95P5FSEndyI6GSpvz+kofOapbCZ+SqnRpgUxmlcj+BjRr6d\n\t tUF3nGYNEh0ST+8xFRk7Kvo5dNDV1K+Mm4nyz7O3WrJ93GDtGkKwnZnfK/X17X7k2b\n\t f0faK0yZgmPX7lfc4nMqHmxbcB/3MooRWPwhpnkEtpGRlxGcqByVvM4/hDJUcHMRuX\n\t 9X5aOtHCv4PlQ==","Date":"Fri, 10 Apr 2026 20:21:32 +0900","From":"Krzysztof =?utf-8?q?Wilczy=C5=84ski?= <kwilczynski@kernel.org>","To":"Ilpo =?utf-8?b?SsOkcnZpbmVu?= <ilpo.jarvinen@linux.intel.com>","Cc":"Bjorn Helgaas <bhelgaas@google.com>, Bjorn Helgaas <helgaas@kernel.org>,\n Manivannan Sadhasivam <mani@kernel.org>,\n Lorenzo Pieralisi <lpieralisi@kernel.org>,\n Magnus Lindholm <linmag7@gmail.com>, Matt Turner <mattst88@gmail.com>,\n Richard Henderson <richard.henderson@linaro.org>,\n Christophe Leroy <chleroy@kernel.org>,\n Madhavan Srinivasan <maddy@linux.ibm.com>,\n Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>,\n Dexuan Cui <decui@microsoft.com>,\n Krzysztof =?utf-8?q?Ha=C5=82asa?= <khalasa@piap.pl>,\n Lukas Wunner <lukas@wunner.de>, Oliver O'Halloran <oohall@gmail.com>,\n Saurabh Singh Sengar <ssengar@microsoft.com>,\n Shuan He <heshuan@bytedance.com>, Srivatsa Bhat <srivatsabhat@microsoft.com>,\n linux-pci@vger.kernel.org, linux-alpha@vger.kernel.org,\n linuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH 13/20] alpha/PCI: Clean up __pci_mmap_fits()","Message-ID":"<20260410112132.GA1756033@rocinante>","References":"<20260410055040.39233-1-kwilczynski@kernel.org>\n <20260410055040.39233-14-kwilczynski@kernel.org>\n <66eb23bf-1995-363f-78e6-f5a397a063a2@linux.intel.com>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<66eb23bf-1995-363f-78e6-f5a397a063a2@linux.intel.com>"}},{"id":3675838,"web_url":"http://patchwork.ozlabs.org/comment/3675838/","msgid":"<f6c036e1-9145-e784-8a37-2486fc72978e@linux.intel.com>","list_archive_url":null,"date":"2026-04-10T11:32:43","subject":"Re: [PATCH 13/20] alpha/PCI: Clean up __pci_mmap_fits()","submitter":{"id":83553,"url":"http://patchwork.ozlabs.org/api/people/83553/","name":"Ilpo Järvinen","email":"ilpo.jarvinen@linux.intel.com"},"content":"On Fri, 10 Apr 2026, Krzysztof Wilczyński wrote:\n\n> Hello,\n> \n> > > Currently, __pci_mmap_fits() computes the BAR size using\n> > > pci_resource_len() - 1, which wraps to a large value when the\n> > > BAR length is zero, causing the bounds check to incorrectly\n> > > succeed.\n> > > \n> > > Thus, add an early return for empty resources.\n> > > \n> > > Also, remove the WARN() that fires when userspace attempts to\n> > > mmap beyond the BAR bounds.  The check still returns 0 to reject\n> > > the mapping, but the warning is excessive for normal operation.\n> > > \n> > > A similar warning was removed from the PCI core in the commit\n> > > 3b519e4ea618 (\"PCI: fix size checks for mmap() on /proc/bus/pci files\").\n> > \n> > This looks like entirely separate two changes to me which just happen \n> > within the same context.\n> \n> True.  I could split this into two separate patches.  However, the early\n> return is so trivial, that I decided to keep it here, in lieu of that the\n> linked patch did, too.\n> \n> Thoughts?\n\nIt's not just adding the early return that would go to the first patch but \nyou also need to rearrange the len for that. Effectively, the change is \nsplit in half, each becoming cleaner and more focused (both diff and the \nchangelog text).\n\nAs is I'm left on the borderline, while I can see it's \"correct\" after \nsplitting those changes inside my head, I also know it could have been \ndone better. I'd easily given rev-by for both if they'd have been done \nindividually, saved the time writing these emails about it, and \neffectively \"forgotten\" the patches (including upcoming versions of the \nseries).","headers":{"Return-Path":"\n <linux-pci+bounces-52303-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=hlMSkELI;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-52303-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"hlMSkELI\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=198.175.65.9","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsZRj5G5bz1yGS\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 21:33:05 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 709F8301484E\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 11:33:03 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 885AC394799;\n\tFri, 10 Apr 2026 11:33:02 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [198.175.65.9])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id E4DB428F935;\n\tFri, 10 Apr 2026 11:33:00 +0000 (UTC)","from orviesa010.jf.intel.com ([10.64.159.150])\n  by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Apr 2026 04:33:00 -0700","from ijarvine-mobl1.ger.corp.intel.com (HELO localhost)\n ([10.245.244.118])\n  by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Apr 2026 04:32:53 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775820782; cv=none;\n b=emdafTVOi0yxNYZMzE9VceSJ+lVO3vprnX2MGtyRArQsHDGqPUA0R+QrYMxrI8w57O9+2SXzvRkoZ8VYSDYJI0rdH6t8bIYiKpazgfFAESPaxFaTSTWFKyv1w5hPAVpbwXkiuYmhF17eWBUfqu4ahP90hgvYEp/PiplIsKXv3bw=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775820782; c=relaxed/simple;\n\tbh=e4U7N25hchQ0OTw8zCGZ+OMwYFRYHOMJzZ6QqDxdozE=;\n\th=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=XarF4OP0Euu+shD6cymXOz2TXEmfIARqf6uvknB/q8cIOxCPfqKgx/qhfqmVmXrm5bJh4pD6MJXODcpiX+Y+pw/hGjM4VuiHBgEp7JGJubstbl+6Cr+o48wYrLrjPHmJA6TIcw/mQ3X1jZ/E5frgzSk/xiqWXDUyoR/4XBPr9i8=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=hlMSkELI; arc=none smtp.client-ip=198.175.65.9","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n  t=1775820781; x=1807356781;\n  h=from:date:to:cc:subject:in-reply-to:message-id:\n   references:mime-version:content-id;\n  bh=e4U7N25hchQ0OTw8zCGZ+OMwYFRYHOMJzZ6QqDxdozE=;\n  b=hlMSkELIHmpLY7lpdl2+rvq651fZMZ/6tMmDQ/C0BPkJObskK6qCy+qz\n   qHg66XI6qRIZhsG5fAl0tQLfaE98L0HzpuAJa19kPCJ70thmmxrs8hcvS\n   kvD3M4nRLG7eIJ6AwqKc52rf/cNDSdL5m3FgyuPdXUOtbhkec2hHmqsSt\n   JDDnFt71Ip5Kx8aXIcPLgVIpCyMxywVPoj2A7M7VhbNX4m729CLRJi0bA\n   wSinhbwade1vecdC9eM4dficzK5ZTmpZHVcl8QwSjyXV3iX9JMNp9YR4/\n   osIUo/TWmqXck5mav3Ltt01XUs0wIOfYKIJiXSS3QfsEWwdCQ3jlrYPrF\n   g==;","X-CSE-ConnectionGUID":["+uDqoYznR+Gqe15ca2QZ5w==","pq0LdvgKRNOveewCKjRzXA=="],"X-CSE-MsgGUID":["bpwis0JDQ6mDMALJFqu0wg==","NCur4HzvQIiHzQCbo1QxPA=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11754\"; a=\"99472912\"","E=Sophos;i=\"6.23,171,1770624000\";\n   d=\"scan'208\";a=\"99472912\"","E=Sophos;i=\"6.23,171,1770624000\";\n   d=\"scan'208\";a=\"228225436\""],"X-ExtLoop1":"1","From":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>","Date":"Fri, 10 Apr 2026 14:32:43 +0300 (EEST)","To":"=?iso-8859-2?q?Krzysztof_Wilczy=F1ski?= <kwilczynski@kernel.org>","cc":"Bjorn Helgaas <bhelgaas@google.com>, Bjorn Helgaas <helgaas@kernel.org>,\n  Manivannan Sadhasivam <mani@kernel.org>,\n  Lorenzo Pieralisi <lpieralisi@kernel.org>,\n  Magnus Lindholm <linmag7@gmail.com>, Matt Turner <mattst88@gmail.com>,\n  Richard Henderson <richard.henderson@linaro.org>,\n  Christophe Leroy <chleroy@kernel.org>,\n  Madhavan Srinivasan <maddy@linux.ibm.com>,\n  Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>,\n  Dexuan Cui <decui@microsoft.com>,\n =?iso-8859-2?q?Krzysztof_Ha=B3asa?= <khalasa@piap.pl>,\n  Lukas Wunner <lukas@wunner.de>, Oliver O'Halloran <oohall@gmail.com>,\n  Saurabh Singh Sengar <ssengar@microsoft.com>,\n  Shuan He <heshuan@bytedance.com>,\n  Srivatsa Bhat <srivatsabhat@microsoft.com>, linux-pci@vger.kernel.org,\n  linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH 13/20] alpha/PCI: Clean up __pci_mmap_fits()","In-Reply-To":"<20260410112132.GA1756033@rocinante>","Message-ID":"<f6c036e1-9145-e784-8a37-2486fc72978e@linux.intel.com>","References":"<20260410055040.39233-1-kwilczynski@kernel.org>\n <20260410055040.39233-14-kwilczynski@kernel.org>\n <66eb23bf-1995-363f-78e6-f5a397a063a2@linux.intel.com>\n <20260410112132.GA1756033@rocinante>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"multipart/mixed; BOUNDARY=\"8323328-135863821-1775820198=:1195\"","Content-ID":"<35660afc-f9b7-2ff0-7765-d108aab98c34@linux.intel.com>"}},{"id":3675851,"web_url":"http://patchwork.ozlabs.org/comment/3675851/","msgid":"<20260410115541.GA1770099@rocinante>","list_archive_url":null,"date":"2026-04-10T11:55:41","subject":"Re: [PATCH 13/20] alpha/PCI: Clean up __pci_mmap_fits()","submitter":{"id":86709,"url":"http://patchwork.ozlabs.org/api/people/86709/","name":"Krzysztof Wilczyński","email":"kwilczynski@kernel.org"},"content":"Hello,\n\n> > > This looks like entirely separate two changes to me which just happen \n> > > within the same context.\n> > \n> > True.  I could split this into two separate patches.  However, the early\n> > return is so trivial, that I decided to keep it here, in lieu of that the\n> > linked patch did, too.\n> > \n> > Thoughts?\n> \n> It's not just adding the early return that would go to the first patch but \n> you also need to rearrange the len for that. Effectively, the change is \n> split in half, each becoming cleaner and more focused (both diff and the \n> changelog text).\n> \n> As is I'm left on the borderline, while I can see it's \"correct\" after \n> splitting those changes inside my head, I also know it could have been \n> done better. I'd easily given rev-by for both if they'd have been done \n> individually, saved the time writing these emails about it, and \n> effectively \"forgotten\" the patches (including upcoming versions of the \n> series).\n\nA simple \"yes, please split\" would suffice. :)  For future reference.\n\nThank you!\n\n\tKrzysztof","headers":{"Return-Path":"\n <linux-pci+bounces-52307-incoming=patchwork.ozlabs.org@vger.kernel.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=Lb/ZmOTV;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-52307-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"Lb/ZmOTV\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsZyG5nxmz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 21:56:06 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 803DE3019D9D\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 11:55:47 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id BC4EA3BE16B;\n\tFri, 10 Apr 2026 11:55:43 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 9952C3BE167;\n\tFri, 10 Apr 2026 11:55:43 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 08420C19421;\n\tFri, 10 Apr 2026 11:55:42 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775822143; cv=none;\n b=kEBfWFebAkDCa4qz/1j92a1w4M2pv/Y41BPn3judM2idXrZH6beshAQ/tqwEwsuJLvTtX2O2cpgPWV7yc5kGGFlMmZAh1BYGeYJhIcbyyqe6Lho+O5z+1vJI+63KLVNOEPTDbY4/Z3eDuRnsX2MMMRSTXijb8MQ+ShydEC9Ahaw=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775822143; c=relaxed/simple;\n\tbh=mdpaoKvaXfKLinXjUDc/IbjJOXSHqFvXpOvUOnu9NX8=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=T+jbEnR2ZNHT1wXbrtt9H2vm+n2WT+F66DJHEcXhjeINNnqDWTE67cXbw+UcsGEiaCkSfuQA6pGI5pRnHgEuxMS9g1y1iaijUJO4xguW2/O0fewXGpgdn+8X3VcV+xlYVlOVYsdhWs7mNWH7Mo98piHNcUBeMTePXGZ8KECHDgY=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=Lb/ZmOTV; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775822143;\n\tbh=mdpaoKvaXfKLinXjUDc/IbjJOXSHqFvXpOvUOnu9NX8=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=Lb/ZmOTV/EI6r89sYKM9ULJyJetsrcgzEuFMg/9jkdKVHDvnAJGfhz6XABBV42pDE\n\t tuDb+vDldQsgNNwYLOcZrBTikPs+k+KF+a7tGZuf4JesL90OlRBkKnyY9ttXH7PRhF\n\t KMyZZBGUe7CHTFHem+Axjaq2pR3+kzKnCTPcWTdbknpkbY9bpWLqpkgQ//cSi7z7dW\n\t JM9Z8kVYEjhEG/YrGw6zPJvyp3StfSjwyeG0Kz/ApB6/aG5lYpqf47YpvGvGF4AG1v\n\t aj/jBzvtsjynVD3A0L6z5orp4L3dsfkgbRa0IwgajGiEEx72Ab5cFsooy/inKLAk6Q\n\t sRx53daBp+a7Q==","Date":"Fri, 10 Apr 2026 20:55:41 +0900","From":"Krzysztof =?utf-8?q?Wilczy=C5=84ski?= <kwilczynski@kernel.org>","To":"Ilpo =?utf-8?b?SsOkcnZpbmVu?= <ilpo.jarvinen@linux.intel.com>","Cc":"Bjorn Helgaas <bhelgaas@google.com>, Bjorn Helgaas <helgaas@kernel.org>,\n Manivannan Sadhasivam <mani@kernel.org>,\n Lorenzo Pieralisi <lpieralisi@kernel.org>,\n Magnus Lindholm <linmag7@gmail.com>, Matt Turner <mattst88@gmail.com>,\n Richard Henderson <richard.henderson@linaro.org>,\n Christophe Leroy <chleroy@kernel.org>,\n Madhavan Srinivasan <maddy@linux.ibm.com>,\n Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>,\n Dexuan Cui <decui@microsoft.com>,\n Krzysztof =?utf-8?q?Ha=C5=82asa?= <khalasa@piap.pl>,\n Lukas Wunner <lukas@wunner.de>, Oliver O'Halloran <oohall@gmail.com>,\n Saurabh Singh Sengar <ssengar@microsoft.com>,\n Shuan He <heshuan@bytedance.com>, Srivatsa Bhat <srivatsabhat@microsoft.com>,\n linux-pci@vger.kernel.org, linux-alpha@vger.kernel.org,\n linuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH 13/20] alpha/PCI: Clean up __pci_mmap_fits()","Message-ID":"<20260410115541.GA1770099@rocinante>","References":"<20260410055040.39233-1-kwilczynski@kernel.org>\n <20260410055040.39233-14-kwilczynski@kernel.org>\n <66eb23bf-1995-363f-78e6-f5a397a063a2@linux.intel.com>\n <20260410112132.GA1756033@rocinante>\n <f6c036e1-9145-e784-8a37-2486fc72978e@linux.intel.com>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<f6c036e1-9145-e784-8a37-2486fc72978e@linux.intel.com>"}}]