Re: [PATCH v8 1/3] devres: provide devm_krealloc()

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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@linux.intel.com> 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