linux-kernel - Re: [PATCH v8 1/3] devres: provide devm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200821105119.GL1891694@smile.fi.intel.com>
Date:   Fri, 21 Aug 2020 13:51:19 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Bartosz Golaszewski <brgl@...ev.pl>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Michal Simek <michal.simek@...inx.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Guenter Roeck <linux@...ck-us.net>,
        linux-iio <linux-iio@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH v8 1/3] devres: provide devm_krealloc()

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@...ux.intel.com> wrote:
> > On Thu, Aug 20, 2020 at 08:51:08PM +0200, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bgolaszewski@...libre.com>

...

> > > +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);
> > > +}
> >
> > I'm fine with above, but here is a side note, perhaps
> >
> >         offsetof(struct devres, data)
> >
> > will be more practical (no duplication of alignment and hence slightly better
> > maintenance)? (Note, I didn't check if it provides the correct result)
> >
> 
> Hi Andy,
> 
> 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.

Test results
~~~~~~~~~~~~
sizeof(devres), ALIGN(data), resulting 3 pointers against NULL followed by
actual pointer of allocated struct and 3 pointers against it.

% for i in 1 2 4; do gcc -O2 -Wall -DSZ=$i -o test test.c && ./test | head -n1; done
szof: 24 a: 24 0xffffffffffffffe8 0xffffffffffffffef 0xffffffffffffffef, 0x55a3aa91e2a0: 0x55a3aa91e299 0x55a3aa91e2a0 0x55a3aa91e2a0
szof: 24 a: 24 0xffffffffffffffe8 0xffffffffffffffee 0xffffffffffffffee, 0x563d7b88b2a0: 0x563d7b88b29a 0x563d7b88b2a0 0x563d7b88b2a0
szof: 24 a: 24 0xffffffffffffffe8 0xffffffffffffffec 0xffffffffffffffec, 0x557d08cf82a0: 0x557d08cf829c 0x557d08cf82a0 0x557d08cf82a0

% for i in 1 2 4; do gcc -m32 -O2 -Wall -DSZ=$i -o test test.c && ./test | head -n1; done
szof: 12 a: 12 0xfffffff4 0xfffffff7 0xfffffff7, 0x584301a0: 0x5843019d 0x584301a0 0x584301a0
szof: 12 a: 12 0xfffffff4 0xfffffff6 0xfffffff6, 0x57bd61a0: 0x57bd619e 0x57bd61a0 0x57bd61a0
szof: 12 a: 12 0xfffffff4 0xfffffff4 0xfffffff4, 0x56b491a0: 0x56b491a0 0x56b491a0 0x56b491a0

I think you need to change this to use container_of() and offsetof().

> > Another side note: do we have existing users of these helpers?
> 
> Which ones? Because I assume you're not referring to the ones I'm
> adding in this patch. :)

Opposite, the ones you are introduced here. Meaning that we might convert
existing user(s) in the separate change(s) later on.

-- 
With Best Regards,
Andy Shevchenko