On 04/05/2019 07:12 PM, Catalin Marinas wrote:
> 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?
Yeah but with some ZONE_DEVICE series patches.
>
> What's zone_device_public_altmap_init? I couldn't grep it in mainline.
Test module inti function (should have mentioned it clearly).
> How's the pgmap allocated?
devm_kzalloc() but the problem seems to be gone with kzalloc().
>
> I'd suggest you enable kasan and see if it spots anything.
>
Sure.
