Re: [PATCH v8 1/3] devres: provide devm_krealloc()
From: Andy Shevchenko
Date: Fri Aug 21 2020 - 07:04:14 EST
On Fri, Aug 21, 2020 at 01:51:19PM +0300, Andy Shevchenko wrote:
> On Fri, Aug 21, 2020 at 10:59:19AM +0200, Bartosz Golaszewski wrote:
> > On Fri, Aug 21, 2020 at 10:35 AM Andy Shevchenko
> > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > On Thu, Aug 20, 2020 at 08:51:08PM +0200, Bartosz Golaszewski wrote:
...
> > > > +static struct devres *to_devres(void *data)
> > > > +{
> > > > + return data - ALIGN(sizeof(struct devres), ARCH_KMALLOC_MINALIGN);
> > > > +}
> > > > +
> > > > +static size_t devres_data_size(size_t total_size)
> > > > +{
> > > > + return total_size - ALIGN(sizeof(struct devres), ARCH_KMALLOC_MINALIGN);
> > > > +}
> > The data pointer in struct devres is defined as:
> >
> > u8 __aligned(ARCH_KMALLOC_MINALIGN) data[];
> >
> > And this value (assigned the value of ARCH_DMA_MINALIGN) varies from
> > one arch to another. I wasn't really sure if offsetof() would work for
> > every case so I went with something very explicit.
>
> I have checked with a small program simulating to_devres() with your variant,
> offsetof() and container_of().
>
> The result is this: if MINALIGN < sizeof(long) and since struct is unpacked the
> offsetof(), and thus container_of(), gives correct result, while ALIGN()
> approach mistakenly moves pointer too back.
...
> I think you need to change this to use container_of() and offsetof().
To be clear, there is probably no real problem, except unlikely possible
MINALIGN=4 on 64-bit arch, but for sake of the correctness.
--
With Best Regards,
Andy Shevchenko