Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220812130645.14710-1-sbinding@opensource.cirrus.com> <20220825072505.316002-1-ardb@kernel.org>
In-Reply-To: <20220825072505.316002-1-ardb@kernel.org>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Thu, 25 Aug 2022 09:40:58 +0200
Message-ID: <CAJZ5v0iyRAzx=HjWko=QJ7iXv_Ftwsx+yjnA2MuN4KVZo9wWew@mail.gmail.com>
Subject: Re: [PATCH v1] ACPI: Property: Fix type detection of unified integer
 reading functions
To:     Ard Biesheuvel <ardb@kernel.org>,
        Sakari Ailus <sakari.ailus@linux.intel.com>
Cc:     Stefan Binding <sbinding@opensource.cirrus.com>,
        "Shevchenko, Andriy" <andriy.shevchenko@intel.com>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        patches@opensource.cirrus.com,
        "Rafael J. Wysocki" <rafael@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Aug 25, 2022 at 9:25 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > The current code expects the type of the value to be an integer type,
> > instead the value passed to the macro is a pointer.
> > Ensure the size comparison uses the correct pointer type to choose the
> > max value, instead of using the integer type.
> >
> > Fixes: 923044133367 ("ACPI: property: Unify integer value reading functions")
> >
> > Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
>
> Acked-by: Ard Biesheuvel <ardb@kernel.org>
>
> Can we get this queued up and sent out please? This is breaking some ACPI arm64
> systems, which use device properties for their MAC addresses.

It is in my queue for -rc3.

> Some grumbling about the original patch below.
>
> > ---
> >  drivers/acpi/property.c | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
> > index 7b3ad8ed2f4e..b1d4a8db89df 100644
> > --- a/drivers/acpi/property.c
> > +++ b/drivers/acpi/property.c
> > @@ -1043,10 +1043,10 @@ static int acpi_data_prop_read_single(const struct acpi_device_data *data,
> >                               break;                                  \
> >                       }                                               \
> >                       if (__items[i].integer.value > _Generic(__val,  \
> > -                                                             u8: U8_MAX, \
> > -                                                             u16: U16_MAX, \
> > -                                                             u32: U32_MAX, \
> > -                                                             u64: U64_MAX, \
> > +                                                             u8 *: U8_MAX, \
> > +                                                             u16 *: U16_MAX, \
> > +                                                             u32 *: U32_MAX, \
> > +                                                             u64 *: U64_MAX, \
> >                                                               default: 0U)) { \
>
> Why is there a default here? Having one is what hides the fact that the patch was completely broken.

Sakari?

> >                               ret = -EOVERFLOW;                       \
> >                               break;                                  \
> >
>
> Also, I must ask: given how broken the original patch is, I suppose no testing whatsoever was done?