All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Russell King <linux@armlinux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	open list <linux-kernel@vger.kernel.org>,
	ssantosh@kernel.org, ardb@kernel.org, geert+renesas@glider.be
Subject: Re: [PATCH v3] ARM: Fix MAX_DMA_ADDRESS overflow
Date: Tue, 19 Jul 2022 09:34:12 -0700	[thread overview]
Message-ID: <58ca1f97-2bc2-7391-ffeb-514ee053bea9@gmail.com> (raw)
In-Reply-To: <CACRpkdYBwi9biXA7efSLonQM36RALeUqj3p+Rv0EFEfVDC=N5w@mail.gmail.com>



On 7/18/2022 5:53 AM, Linus Walleij wrote:
> On Thu, Jul 14, 2022 at 1:28 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 7/6/22 13:33, Florian Fainelli wrote:
>>> Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
>>> added a check to determine whether arm_dma_zone_size is exceeding the
>>> amount of kernel virtual address space available between the upper 4GB
>>> virtual address limit and PAGE_OFFSET in order to provide a suitable
>>> definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
>>> address space. The quantity used for comparison was off by a missing
>>> trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
>>> quantity.
>>>
>>> This was caught thanks to CONFIG_DEBUG_VIRTUAL on the bcm2711 platform
>>> where we define a dma_zone_size of 1GB and we have a PAGE_OFFSET value
>>> of 0xc000_0000 (CONFIG_VMSPLIT_3G) leading to MAX_DMA_ADDRESS being
>>> 0x1_0000_0000 which overflows the unsigned long type used throughout
>>> __pa() and then __virt_addr_valid(). Because the virtual address passed
>>> to __virt_addr_valid() would now be 0, the function would loudly warn
>>> and flood the kernel log, thus making the platform unable to boot
>>> properly.
>>>
>>> Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>
>> Shall I send this to RMK's patch system?
> 
> I think so!
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Thanks:

https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9216/1
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Russell King <linux@armlinux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	open list <linux-kernel@vger.kernel.org>,
	ssantosh@kernel.org, ardb@kernel.org, geert+renesas@glider.be
Subject: Re: [PATCH v3] ARM: Fix MAX_DMA_ADDRESS overflow
Date: Tue, 19 Jul 2022 09:34:12 -0700	[thread overview]
Message-ID: <58ca1f97-2bc2-7391-ffeb-514ee053bea9@gmail.com> (raw)
In-Reply-To: <CACRpkdYBwi9biXA7efSLonQM36RALeUqj3p+Rv0EFEfVDC=N5w@mail.gmail.com>



On 7/18/2022 5:53 AM, Linus Walleij wrote:
> On Thu, Jul 14, 2022 at 1:28 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 7/6/22 13:33, Florian Fainelli wrote:
>>> Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
>>> added a check to determine whether arm_dma_zone_size is exceeding the
>>> amount of kernel virtual address space available between the upper 4GB
>>> virtual address limit and PAGE_OFFSET in order to provide a suitable
>>> definition of MAX_DMA_ADDRESS that should fit within the 32-bit virtual
>>> address space. The quantity used for comparison was off by a missing
>>> trailing 0, leading to MAX_DMA_ADDRESS to be overflowing a 32-bit
>>> quantity.
>>>
>>> This was caught thanks to CONFIG_DEBUG_VIRTUAL on the bcm2711 platform
>>> where we define a dma_zone_size of 1GB and we have a PAGE_OFFSET value
>>> of 0xc000_0000 (CONFIG_VMSPLIT_3G) leading to MAX_DMA_ADDRESS being
>>> 0x1_0000_0000 which overflows the unsigned long type used throughout
>>> __pa() and then __virt_addr_valid(). Because the virtual address passed
>>> to __virt_addr_valid() would now be 0, the function would loudly warn
>>> and flood the kernel log, thus making the platform unable to boot
>>> properly.
>>>
>>> Fixes: 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis")
>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>
>> Shall I send this to RMK's patch system?
> 
> I think so!
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Thanks:

https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9216/1
-- 
Florian

  reply	other threads:[~2022-07-19 16:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-06 20:33 [PATCH v3] ARM: Fix MAX_DMA_ADDRESS overflow Florian Fainelli
2022-07-06 20:33 ` Florian Fainelli
2022-07-13 23:28 ` Florian Fainelli
2022-07-13 23:28   ` Florian Fainelli
2022-07-18 12:53   ` Linus Walleij
2022-07-18 12:53     ` Linus Walleij
2022-07-19 16:34     ` Florian Fainelli [this message]
2022-07-19 16:34       ` Florian Fainelli

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=58ca1f97-2bc2-7391-ffeb-514ee053bea9@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=grygorii.strashko@ti.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=ssantosh@kernel.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.