Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210323131842.2773094-1-arnd@kernel.org> <CAKwvOdkBEQdVC73_datkwa+meitAGskDgTEr5LzX6AEnE4xd-w@mail.gmail.com>
 <87czvokgdk.wl-maz@kernel.org>
In-Reply-To: <87czvokgdk.wl-maz@kernel.org>
From:   Arnd Bergmann <arnd@kernel.org>
Date:   Wed, 24 Mar 2021 11:55:04 +0100
Message-ID: <CAK8P3a2kVagwETi0_t0C=eGJ6UU=AXegL94UykfQdh7H292XYQ@mail.gmail.com>
Subject: Re: [PATCH] irqchip/gic-v3: fix OF_BAD_ADDR error handling
To:     Marc Zyngier <maz@kernel.org>
Cc:     Nick Desaulniers <ndesaulniers@google.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Nathan Chancellor <nathan@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        clang-built-linux <clang-built-linux@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Mar 24, 2021 at 11:14 AM Marc Zyngier <maz@kernel.org> wrote:
>
> On Tue, 23 Mar 2021 22:06:22 +0000,
> Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > On Tue, Mar 23, 2021 at 6:18 AM Arnd Bergmann <arnd@kernel.org> wrote:
> > >
> > > From: Arnd Bergmann <arnd@arndb.de>
> > >
> > > When building with extra warnings enabled, clang points out a
> > > mistake in the error handling:
> > >
> > > drivers/irqchip/irq-gic-v3-mbi.c:306:21: error: result of comparison of constant 18446744073709551615 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> >
> > Looks like based on CONFIG_PHYS_ADDR_T_64BIT, phys_addr_t can be u64
> > or u32, but of_translate_address always returns a u64.  This is fine
> > for the current value of OF_BAD_ADDR, but I think there's a risk of
> > losing the top 32b of the return value of of_translate_address() here?
>
> If the DT describes a 64bit physical address, and that the (32bit)
> kernel isn't built to grok these addresses, then I'd say that the
> kernel cannot run on this HW, and that we don't need to worry much
> about this case.
>
> In general, CONFIG_PHYS_ADDR_T_64BIT must be selected by the arch code
> if anything above 32bit can be described in the PA space.

Right, this generally works fine, the OF_BAD_ADDR is just a little
hard to get right. Fortunately there are very few comparisons to
OF_BAD_ADDR in other drivers, so I don't think we have to do
anything about it. I looked through every other user of this and found
no problems there, either they use 64-bit temporaries, or they correctly
cast the results.

         Arnd