Hi Anshuman,
On Fri, Apr 05, 2019 at 10:10:22AM +0530, Anshuman Khandual wrote:
> On arm64 platform "struct dev_pagemap" is getting corrupted during ZONE_DEVICE
> unmapping path through device_destroy(). Its device memory range end address
> (pgmap->res.end) which is getting corrupted in this particular case. AFAICS
> pgmap which gets initialized by the driver and mapped with devm_memremap_pages()
> should retain it's values during the unmapping path as well. Is this assumption
> right ?
[...]
> The problem can be traced down here.
>
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> index e038e2b3b7ea..2a410c88c596 100644
> --- a/drivers/base/devres.c
> +++ b/drivers/base/devres.c
> @@ -33,7 +33,7 @@ struct devres {
> * Thus we use ARCH_KMALLOC_MINALIGN here and get exactly the same
> * buffer alignment as if it was allocated by plain kmalloc().
> */
> - u8 __aligned(ARCH_KMALLOC_MINALIGN) data[];
> + u8 __aligned(__alignof__(unsigned long long)) data[];
> };
[...]
> With the patch:
>
> [ 53.027865] XXX: zone_device_public_altmap_init pgmap ffff8005de634218 resource ffff8005de634250 res->start 680000000 res->end 6bfffffff size 40000000
> [ 53.029840] XXX: devm_memremap_pages_release pgmap ffff8005de634218 resource ffff8005de634250 res->start 680000000 res->end 6bfffffff size 40000000
>
> Without the patch:
>
> [ 34.326066] XXX: zone_device_public_altmap_init pgmap ffff8005de530a80 resource ffff8005de530ab8 res->start 680000000 res->end 6bfffffff size 40000000
> [ 34.328063] XXX: devm_memremap_pages_release pgmap ffff8005de530a80 resource ffff8005de530ab8 res->start 680000000 res->end 0 size fffffff980000001
OK, so without this patch pgmap->res.end becomes 0 while it should stay
at 0x6bfffffff. Is it easy to reproduce with mainline?
What's zone_device_public_altmap_init? I couldn't grep it in mainline.
How's the pgmap allocated?
I'd suggest you enable kasan and see if it spots anything.
--
Catalin
