From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Nicolas Pitre <nico@fluxnic.net>,
Catalin Marinas <catalin.marinas@arm.com>,
open list <linux-kernel@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH 2/2] ARM: Clamp MAX_DMA_ADDRESS to 32-bit
Date: Fri, 29 Apr 2022 16:07:52 +0100 [thread overview]
Message-ID: <Ymv/SIqErX3bm1bG@shell.armlinux.org.uk> (raw)
In-Reply-To: <CAMuHMdWyDLoOit-VYPzLXxLz6W300xpo_wrqj=Pr9sZSwk_OwQ@mail.gmail.com>
On Thu, Mar 24, 2022 at 09:31:56PM +0100, Geert Uytterhoeven wrote:
> Hi Florian,
>
> On Thu, Mar 24, 2022 at 6:54 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> > MAX_DMA_ADDRESS is a virtual address, therefore it needs to fit within a
> > 32-bit unsigned quantity. Platforms defining a DMA zone size in
> > their machine descriptor can easily overflow this quantity depending on
> > the DMA zone size and/or the PAGE_OFFSET setting.
> >
> > In most cases this is harmless, however in the case of a
> > CONFIG_DEBUG_VIRTUAL enabled, __virt_addr_valid() will be unable to
> > return that MAX_DMA_ADDRESS is valid because the value passed to that
> > function is an unsigned long which has already overflowed.
> >
> > Fixes: e377cd8221eb ("ARM: 8640/1: Add support for CONFIG_DEBUG_VIRTUAL")
> > Fixes: 2fb3ec5c9503 ("ARM: Replace platform definition of ISA_DMA_THRESHOLD/MAX_DMA_ADDRESS")
> > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> > --- a/arch/arm/include/asm/dma.h
> > +++ b/arch/arm/include/asm/dma.h
> > @@ -8,10 +8,12 @@
> > #ifndef CONFIG_ZONE_DMA
> > #define MAX_DMA_ADDRESS 0xffffffffUL
> > #else
> > +#include <linux/minmax.h>
> > #define MAX_DMA_ADDRESS ({ \
> > extern phys_addr_t arm_dma_zone_size; \
> > arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
>
> "arm_dma_zone_size < (0x10000000 - PAGE_OFFSET)" looks
> like an overflow-avoiding version of
> "PAGE_OFFSET + arm_dma_zone_size < 0x10000000".
> However, PAGE_OFFSET is always larger than 0x10000000,
> so "0x10000000 - PAGE_OFFSET" is a rather large number?
This, to me, looks like it should have been:
arm_dma_zone_size && arm_dma_zone_size < (0x100000000 - PAGE_OFFSET) ? \
since that is the only thing that would make sense - it's the virtual
space remaining between PAGE_OFFSET and the top of addressable space.
However, 0x100000000 isn't correct - since the vectors live at
0xffff0000, and we have the vmalloc space etc.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
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: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Nicolas Pitre <nico@fluxnic.net>,
Catalin Marinas <catalin.marinas@arm.com>,
open list <linux-kernel@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH 2/2] ARM: Clamp MAX_DMA_ADDRESS to 32-bit
Date: Fri, 29 Apr 2022 16:07:52 +0100 [thread overview]
Message-ID: <Ymv/SIqErX3bm1bG@shell.armlinux.org.uk> (raw)
In-Reply-To: <CAMuHMdWyDLoOit-VYPzLXxLz6W300xpo_wrqj=Pr9sZSwk_OwQ@mail.gmail.com>
On Thu, Mar 24, 2022 at 09:31:56PM +0100, Geert Uytterhoeven wrote:
> Hi Florian,
>
> On Thu, Mar 24, 2022 at 6:54 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> > MAX_DMA_ADDRESS is a virtual address, therefore it needs to fit within a
> > 32-bit unsigned quantity. Platforms defining a DMA zone size in
> > their machine descriptor can easily overflow this quantity depending on
> > the DMA zone size and/or the PAGE_OFFSET setting.
> >
> > In most cases this is harmless, however in the case of a
> > CONFIG_DEBUG_VIRTUAL enabled, __virt_addr_valid() will be unable to
> > return that MAX_DMA_ADDRESS is valid because the value passed to that
> > function is an unsigned long which has already overflowed.
> >
> > Fixes: e377cd8221eb ("ARM: 8640/1: Add support for CONFIG_DEBUG_VIRTUAL")
> > Fixes: 2fb3ec5c9503 ("ARM: Replace platform definition of ISA_DMA_THRESHOLD/MAX_DMA_ADDRESS")
> > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> > --- a/arch/arm/include/asm/dma.h
> > +++ b/arch/arm/include/asm/dma.h
> > @@ -8,10 +8,12 @@
> > #ifndef CONFIG_ZONE_DMA
> > #define MAX_DMA_ADDRESS 0xffffffffUL
> > #else
> > +#include <linux/minmax.h>
> > #define MAX_DMA_ADDRESS ({ \
> > extern phys_addr_t arm_dma_zone_size; \
> > arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
>
> "arm_dma_zone_size < (0x10000000 - PAGE_OFFSET)" looks
> like an overflow-avoiding version of
> "PAGE_OFFSET + arm_dma_zone_size < 0x10000000".
> However, PAGE_OFFSET is always larger than 0x10000000,
> so "0x10000000 - PAGE_OFFSET" is a rather large number?
This, to me, looks like it should have been:
arm_dma_zone_size && arm_dma_zone_size < (0x100000000 - PAGE_OFFSET) ? \
since that is the only thing that would make sense - it's the virtual
space remaining between PAGE_OFFSET and the top of addressable space.
However, 0x100000000 isn't correct - since the vectors live at
0xffff0000, and we have the vmalloc space etc.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2022-04-29 15:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 17:54 [PATCH 0/2] ARM: MAX_DMA_ADDRESS fixes Florian Fainelli
2022-03-24 17:54 ` Florian Fainelli
2022-03-24 17:54 ` [PATCH 1/2] ARM: Fix off by one in checking DMA zone size Florian Fainelli
2022-03-24 17:54 ` Florian Fainelli
2022-03-24 19:02 ` Linus Walleij
2022-03-24 19:02 ` Linus Walleij
2022-04-29 15:15 ` Russell King (Oracle)
2022-04-29 15:15 ` Russell King (Oracle)
2022-04-29 15:45 ` Arnd Bergmann
2022-04-29 15:45 ` Arnd Bergmann
2022-03-24 17:54 ` [PATCH 2/2] ARM: Clamp MAX_DMA_ADDRESS to 32-bit Florian Fainelli
2022-03-24 17:54 ` Florian Fainelli
2022-03-24 19:02 ` Linus Walleij
2022-03-24 19:02 ` Linus Walleij
2022-03-24 20:31 ` Geert Uytterhoeven
2022-03-24 20:31 ` Geert Uytterhoeven
2022-03-24 22:39 ` Florian Fainelli
2022-03-24 22:39 ` Florian Fainelli
2022-04-29 15:07 ` Russell King (Oracle) [this message]
2022-04-29 15:07 ` Russell King (Oracle)
2022-04-26 16:29 ` [PATCH 0/2] ARM: MAX_DMA_ADDRESS fixes Florian Fainelli
2022-04-26 16:29 ` 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=Ymv/SIqErX3bm1bG@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=f.fainelli@gmail.com \
--cc=geert@linux-m68k.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=robh+dt@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.