From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>, robin.murphy-5wv7dgnIgG8@public.gmane.org, will.deacon-5wv7dgnIgG8@public.gmane.org, joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org, lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org, hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, sudeep.holla-5wv7dgnIgG8@public.gmane.org, rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org, lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, catalin.marinas-5wv7dgnIgG8@public.gmane.org, arnd-r2nGTMty4D4@public.gmane.org, linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org Subject: Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask Date: Thu, 6 Apr 2017 12:34:09 -0700 [thread overview] Message-ID: <58E69831.6010306@gmail.com> (raw) In-Reply-To: <b77e3405-f060-bcd5-99f6-7d76f9edf08a-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> On 04/06/17 04:01, Sricharan R wrote: > Hi Frank, > > On 4/6/2017 12:31 PM, Frank Rowand wrote: >> On 04/04/17 03:18, Sricharan R wrote: >>> Size of the dma-range is calculated as coherent_dma_mask + 1 >>> and passed to arch_setup_dma_ops further. It overflows when >>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF, >>> resulting in size getting passed as 0 wrongly. Fix this by >>> passsing in max(mask, mask + 1). Note that in this case >>> when the mask is set to full 64bits, we will be passing the mask >>> itself to arch_setup_dma_ops instead of the size. The real fix >>> for this should be to make arch_setup_dma_ops receive the >>> mask and handle it, to be done in the future. >>> >>> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> >>> --- >>> drivers/of/device.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/of/device.c b/drivers/of/device.c >>> index c17c19d..c2ae6bb 100644 >>> --- a/drivers/of/device.c >>> +++ b/drivers/of/device.c >>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np) >>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size); >>> if (ret < 0) { >>> dma_addr = offset = 0; >>> - size = dev->coherent_dma_mask + 1; >>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1); >>> } else { >>> offset = PFN_DOWN(paddr - dma_addr); >>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset); >>> >> >> NACK. >> >> Passing an invalid size to arch_setup_dma_ops() is only part of the problem. >> size is also used in of_dma_configure() before calling arch_setup_dma_ops(): >> >> dev->coherent_dma_mask = min(dev->coherent_dma_mask, >> DMA_BIT_MASK(ilog2(dma_addr + size))); >> *dev->dma_mask = min((*dev->dma_mask), >> DMA_BIT_MASK(ilog2(dma_addr + size))); >> >> which would be incorrect for size == 0xffffffffffffffffULL when >> dma_addr != 0. So the proposed fix really is not papering over >> the base problem very well. >> > > Ok, but with your fix for of_dma_get_range and the above fix, > dma_addr will be '0' when size = 0xffffffffffffffffULL, > but DMA_BIT_MASK(ilog2(dma_addr + size)) would be wrong though, > making coherent_dma_mask to be smaller 0x7fffffffffffffffULL. Yes, that was my point. Setting size to 0x7fffffffffffffffULL affects several places. Another potential location (based only on the function header comment, not from reading the code) is iommu_dma_init_domain(). The header comment says: * @base and @size should be exact multiples of IOMMU page granularity to * avoid rounding surprises. I have not read enough context to really understand of_dma_configure(), but it seems there is yet another issue in how the error return case from of_dma_get_range() is handled (with the existing code, as well as if my patch gets accepted). An error return value can mean _either_ there is no dma-ranges property _or_ "an other problem occurred". Should the "an other problem occurred" case be handled by defaulting size to a value based on dev->coherent_dma_mask (the current case) or should the attempt to set up the DMA configuration just fail? > > Regards, > Sricharan > >> I agree that the proper solution involves passing a mask instead >> of a size to arch_setup_dma_ops(). >> >
WARNING: multiple messages have this Message-ID (diff)
From: Frank Rowand <frowand.list@gmail.com> To: Sricharan R <sricharan@codeaurora.org>, robin.murphy@arm.com, will.deacon@arm.com, joro@8bytes.org, lorenzo.pieralisi@arm.com, iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, m.szyprowski@samsung.com, bhelgaas@google.com, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, tn@semihalf.com, hanjun.guo@linaro.org, okaya@codeaurora.org, robh+dt@kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, sudeep.holla@arm.com, rjw@rjwysocki.net, lenb@kernel.org, catalin.marinas@arm.com, arnd@arndb.de, linux-arch@vger.kernel.org, gregkh@linuxfoundation.org Subject: Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask Date: Thu, 6 Apr 2017 12:34:09 -0700 [thread overview] Message-ID: <58E69831.6010306@gmail.com> (raw) Message-ID: <20170406193409.3pdnP7vh5NNkjlUUhS8BCjyvdF3c1VVzr4GABDohSAE@z> (raw) In-Reply-To: <b77e3405-f060-bcd5-99f6-7d76f9edf08a@codeaurora.org> On 04/06/17 04:01, Sricharan R wrote: > Hi Frank, > > On 4/6/2017 12:31 PM, Frank Rowand wrote: >> On 04/04/17 03:18, Sricharan R wrote: >>> Size of the dma-range is calculated as coherent_dma_mask + 1 >>> and passed to arch_setup_dma_ops further. It overflows when >>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF, >>> resulting in size getting passed as 0 wrongly. Fix this by >>> passsing in max(mask, mask + 1). Note that in this case >>> when the mask is set to full 64bits, we will be passing the mask >>> itself to arch_setup_dma_ops instead of the size. The real fix >>> for this should be to make arch_setup_dma_ops receive the >>> mask and handle it, to be done in the future. >>> >>> Signed-off-by: Sricharan R <sricharan@codeaurora.org> >>> --- >>> drivers/of/device.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/of/device.c b/drivers/of/device.c >>> index c17c19d..c2ae6bb 100644 >>> --- a/drivers/of/device.c >>> +++ b/drivers/of/device.c >>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np) >>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size); >>> if (ret < 0) { >>> dma_addr = offset = 0; >>> - size = dev->coherent_dma_mask + 1; >>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1); >>> } else { >>> offset = PFN_DOWN(paddr - dma_addr); >>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset); >>> >> >> NACK. >> >> Passing an invalid size to arch_setup_dma_ops() is only part of the problem. >> size is also used in of_dma_configure() before calling arch_setup_dma_ops(): >> >> dev->coherent_dma_mask = min(dev->coherent_dma_mask, >> DMA_BIT_MASK(ilog2(dma_addr + size))); >> *dev->dma_mask = min((*dev->dma_mask), >> DMA_BIT_MASK(ilog2(dma_addr + size))); >> >> which would be incorrect for size == 0xffffffffffffffffULL when >> dma_addr != 0. So the proposed fix really is not papering over >> the base problem very well. >> > > Ok, but with your fix for of_dma_get_range and the above fix, > dma_addr will be '0' when size = 0xffffffffffffffffULL, > but DMA_BIT_MASK(ilog2(dma_addr + size)) would be wrong though, > making coherent_dma_mask to be smaller 0x7fffffffffffffffULL. Yes, that was my point. Setting size to 0x7fffffffffffffffULL affects several places. Another potential location (based only on the function header comment, not from reading the code) is iommu_dma_init_domain(). The header comment says: * @base and @size should be exact multiples of IOMMU page granularity to * avoid rounding surprises. I have not read enough context to really understand of_dma_configure(), but it seems there is yet another issue in how the error return case from of_dma_get_range() is handled (with the existing code, as well as if my patch gets accepted). An error return value can mean _either_ there is no dma-ranges property _or_ "an other problem occurred". Should the "an other problem occurred" case be handled by defaulting size to a value based on dev->coherent_dma_mask (the current case) or should the attempt to set up the DMA configuration just fail? > > Regards, > Sricharan > >> I agree that the proper solution involves passing a mask instead >> of a size to arch_setup_dma_ops(). >> >
next prev parent reply other threads:[~2017-04-06 19:34 UTC|newest] Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <1489086061-9356-1-git-send-email-sricharan@codeaurora.org> [not found] ` <1489086061-9356-1-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2017-04-04 10:18 ` [PATCH V10 00/12] IOMMU probe deferral support Sricharan R 2017-04-04 10:18 ` Sricharan R [not found] ` <1491301105-5274-1-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2017-04-04 10:18 ` [PATCH V10 01/12] iommu/of: Refactor of_iommu_configure() for error handling Sricharan R 2017-04-04 10:18 ` Sricharan R 2017-04-04 10:18 ` [PATCH V10 02/12] iommu/of: Prepare for deferred IOMMU configuration Sricharan R 2017-04-04 10:18 ` Sricharan R 2017-04-04 10:18 ` [PATCH V10 03/12] of: dma: Move range size workaround to of_dma_get_range() Sricharan R 2017-04-04 10:18 ` Sricharan R [not found] ` <1491301105-5274-4-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2017-04-04 10:46 ` Robin Murphy 2017-04-04 10:46 ` Robin Murphy 2017-04-06 6:24 ` Frank Rowand 2017-04-06 6:24 ` Frank Rowand [not found] ` <58E5DF13.2020700-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-04-06 9:35 ` Sricharan R 2017-04-06 9:35 ` Sricharan R 2017-04-06 10:03 ` Robin Murphy 2017-04-06 10:03 ` Robin Murphy 2017-04-04 10:18 ` [PATCH V10 04/12] of: dma: Make of_dma_deconfigure() public Sricharan R 2017-04-04 10:18 ` Sricharan R [not found] ` <1491301105-5274-5-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2017-04-04 10:47 ` Robin Murphy 2017-04-04 10:47 ` Robin Murphy 2017-04-04 10:18 ` [PATCH V10 05/12] ACPI/IORT: Add function to check SMMUs drivers presence Sricharan R 2017-04-04 10:18 ` Sricharan R [not found] ` <1491301105-5274-6-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2017-04-04 11:04 ` Robin Murphy 2017-04-04 11:04 ` Robin Murphy 2017-04-04 10:18 ` [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask Sricharan R 2017-04-04 10:18 ` Sricharan R [not found] ` <1491301105-5274-7-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2017-04-04 11:10 ` Robin Murphy 2017-04-04 11:10 ` Robin Murphy 2017-04-06 7:01 ` Frank Rowand 2017-04-06 7:01 ` Frank Rowand [not found] ` <58E5E7B7.1050400-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-04-06 10:24 ` Robin Murphy 2017-04-06 10:24 ` Robin Murphy [not found] ` <b081f333-084d-ffa5-635f-f7f1c0232ac3-5wv7dgnIgG8@public.gmane.org> 2017-04-06 13:56 ` Rob Herring 2017-04-06 13:56 ` Rob Herring [not found] ` <CAL_JsqLsE378hfs=xNvSdPV2r+7H81cAFzOwtda2W+mFVoohuA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-04-06 14:45 ` Robin Murphy 2017-04-06 14:45 ` Robin Murphy 2017-04-06 19:24 ` Frank Rowand 2017-04-06 19:24 ` Frank Rowand 2017-04-06 11:01 ` Sricharan R 2017-04-06 11:01 ` Sricharan R [not found] ` <b77e3405-f060-bcd5-99f6-7d76f9edf08a-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2017-04-06 19:34 ` Frank Rowand [this message] 2017-04-06 19:34 ` Frank Rowand 2017-04-07 4:12 ` Sricharan R 2017-04-07 14:46 ` Robin Murphy 2017-04-07 14:46 ` Robin Murphy 2017-04-07 23:13 ` Frank Rowand 2017-04-07 23:13 ` Frank Rowand [not found] ` <58E81D01.8030606-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-04-10 13:25 ` Robin Murphy 2017-04-10 13:25 ` Robin Murphy 2017-04-07 23:10 ` Frank Rowand 2017-04-07 23:10 ` Frank Rowand 2017-04-04 10:18 ` [PATCH V10 07/12] of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices Sricharan R 2017-04-04 10:18 ` Sricharan R [not found] ` <1491301105-5274-8-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2017-04-04 12:17 ` Robin Murphy 2017-04-04 12:17 ` Robin Murphy 2017-04-04 12:30 ` Sricharan R 2017-04-04 12:30 ` Sricharan R 2017-04-04 10:18 ` [PATCH V10 08/12] iommu: of: Handle IOMMU lookup failure with deferred probing or error Sricharan R 2017-04-04 10:18 ` Sricharan R 2017-04-04 11:24 ` Robin Murphy 2017-04-04 11:24 ` Robin Murphy 2017-04-04 10:18 ` [PATCH V10 09/12] drivers: acpi: " Sricharan R 2017-04-04 10:18 ` Sricharan R 2017-04-04 11:31 ` Robin Murphy 2017-04-04 11:31 ` Robin Murphy 2017-04-04 10:18 ` [PATCH V10 10/12] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops Sricharan R 2017-04-04 10:18 ` Sricharan R 2017-04-04 10:18 ` [PATCH V10 11/12] iommu/arm-smmu: Clean up early-probing workarounds Sricharan R 2017-04-04 10:18 ` Sricharan R 2017-04-04 10:18 ` [PATCH V10 12/12] ACPI/IORT: Remove linker section for IORT entries probing Sricharan R 2017-04-04 10:18 ` Sricharan R 2017-04-04 11:33 ` Robin Murphy 2017-04-04 11:33 ` Robin Murphy 2017-04-04 12:49 ` [PATCH V10 00/12] IOMMU probe deferral support Robin Murphy 2017-04-04 12:49 ` Robin Murphy [not found] ` <b0f3a1ec-ea13-7465-1d44-9191e3e803ef-5wv7dgnIgG8@public.gmane.org> 2017-04-05 10:04 ` Lorenzo Pieralisi 2017-04-05 10:04 ` Lorenzo Pieralisi 2017-04-05 1:23 ` Rob Herring 2017-04-05 1:23 ` Rob Herring 2017-04-06 18:46 ` Frank Rowand 2017-04-06 18:46 ` Frank Rowand
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=58E69831.6010306@gmail.com \ --to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \ --cc=arnd-r2nGTMty4D4@public.gmane.org \ --cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \ --cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \ --cc=hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \ --cc=lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org \ --cc=m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \ --cc=okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \ --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \ --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \ --cc=sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \ --cc=sudeep.holla-5wv7dgnIgG8@public.gmane.org \ --cc=tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org \ --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).