[PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[Andrey Ryabinin]

KASAN uses different routines to map shadow for hot added memory and memory
obtained in boot process. Attempt to offline memory onlined by normal boot
process leads to this:

    Trying to vfree() nonexistent vm area (000000005d3b34b9)
    WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190

    Call Trace:
     kasan_mem_notifier+0xad/0xb9
     notifier_call_chain+0x166/0x260
     __blocking_notifier_call_chain+0xdb/0x140
     __offline_pages+0x96a/0xb10
     memory_subsys_offline+0x76/0xc0
     device_offline+0xb8/0x120
     store_mem_state+0xfa/0x120
     kernfs_fop_write+0x1d5/0x320
     __vfs_write+0xd4/0x530
     vfs_write+0x105/0x340
     SyS_write+0xb0/0x140

Obviously we can't call vfree() to free memory that wasn't allocated via
vmalloc(). Use find_vm_area() to see if we can call vfree().

Unfortunately it's a bit tricky to properly unmap and free shadow allocated
during boot, so we'll have to keep it. If memory will come online again
that shadow will be reused.

Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
Reported-by: Paul Menzel <pmenzel+linux-kasan-dev@molgen.mpg.de>
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: <stable@vger.kernel.org>
---
 mm/kasan/kasan.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 55 insertions(+), 2 deletions(-)

diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index e13d911251e7..0d9d9d268f32 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -791,6 +791,41 @@ DEFINE_ASAN_SET_SHADOW(f5);
 DEFINE_ASAN_SET_SHADOW(f8);
 
 #ifdef CONFIG_MEMORY_HOTPLUG
+static bool shadow_mapped(unsigned long addr)
+{
+	pgd_t *pgd = pgd_offset_k(addr);
+	p4d_t *p4d;
+	pud_t *pud;
+	pmd_t *pmd;
+	pte_t *pte;
+
+	if (pgd_none(*pgd))
+		return false;
+	p4d = p4d_offset(pgd, addr);
+	if (p4d_none(*p4d))
+		return false;
+	pud = pud_offset(p4d, addr);
+	if (pud_none(*pud))
+		return false;
+
+	/*
+	 * We can't use pud_large() or pud_huge(), the first one
+	 * is arch-specific, the last one depend on HUGETLB_PAGE.
+	 * So let's abuse pud_bad(), if bud is bad it's has to
+	 * because it's huge.
+	 */
+	if (pud_bad(*pud))
+		return true;
+	pmd = pmd_offset(pud, addr);
+	if (pmd_none(*pmd))
+		return false;
+
+	if (pmd_bad(*pmd))
+		return true;
+	pte = pte_offset_kernel(pmd, addr);
+	return !pte_none(*pte);
+}
+
 static int __meminit kasan_mem_notifier(struct notifier_block *nb,
 			unsigned long action, void *data)
 {
@@ -812,6 +847,14 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
 	case MEM_GOING_ONLINE: {
 		void *ret;
 
+		/*
+		 * If shadow is mapped already than it must have been mapped
+		 * during the boot. This could happen if we onlining previously
+		 * offlined memory.
+		 */
+		if (shadow_mapped(shadow_start))
+			return NOTIFY_OK;
+
 		ret = __vmalloc_node_range(shadow_size, PAGE_SIZE, shadow_start,
 					shadow_end, GFP_KERNEL,
 					PAGE_KERNEL, VM_NO_GUARD,
@@ -823,8 +866,18 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
 		kmemleak_ignore(ret);
 		return NOTIFY_OK;
 	}
-	case MEM_OFFLINE:
-		vfree((void *)shadow_start);
+	case MEM_OFFLINE: {
+		struct vm_struct *vm;
+
+		/*
+		 * Only hot-added memory have vm_area. Freeing shadow
+		 * mapped during boot would be tricky, so we'll just
+		 * have to keep it.
+		 */
+		vm = find_vm_area((void *)shadow_start);
+		if (vm)
+			vfree((void *)shadow_start);
+	}
 	}
 
 	return NOTIFY_OK;
-- 
2.13.6

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[Matthew Wilcox]

On Thu, Feb 01, 2018 at 07:33:49PM +0300, Andrey Ryabinin wrote:
> +	case MEM_OFFLINE: {
> +		struct vm_struct *vm;
> +
> +		/*
> +		 * Only hot-added memory have vm_area. Freeing shadow
> +		 * mapped during boot would be tricky, so we'll just
> +		 * have to keep it.
> +		 */
> +		vm = find_vm_area((void *)shadow_start);
> +		if (vm)
> +			vfree((void *)shadow_start);
> +	}

This looks like a complicated way to spell 'is_vmalloc_addr' ...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[Andrey Ryabinin]

On 02/01/2018 10:57 PM, Matthew Wilcox wrote:
> On Thu, Feb 01, 2018 at 07:33:49PM +0300, Andrey Ryabinin wrote:
>> +	case MEM_OFFLINE: {
>> +		struct vm_struct *vm;
>> +
>> +		/*
>> +		 * Only hot-added memory have vm_area. Freeing shadow
>> +		 * mapped during boot would be tricky, so we'll just
>> +		 * have to keep it.
>> +		 */
>> +		vm = find_vm_area((void *)shadow_start);
>> +		if (vm)
>> +			vfree((void *)shadow_start);
>> +	}
> 
> This looks like a complicated way to spell 'is_vmalloc_addr' ...
> 

It's not. shadow_start is never vmalloc address.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[Matthew Wilcox]

On Thu, Feb 01, 2018 at 11:22:55PM +0300, Andrey Ryabinin wrote:
> >> +		vm = find_vm_area((void *)shadow_start);
> >> +		if (vm)
> >> +			vfree((void *)shadow_start);
> >> +	}
> > 
> > This looks like a complicated way to spell 'is_vmalloc_addr' ...
> > 
> 
> It's not. shadow_start is never vmalloc address.

I'm confused.  How can you call vfree() on something that isn't a vmalloc
address?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[Andrey Ryabinin]

On 02/02/2018 08:20 PM, Matthew Wilcox wrote:
> On Thu, Feb 01, 2018 at 11:22:55PM +0300, Andrey Ryabinin wrote:
>>>> +		vm = find_vm_area((void *)shadow_start);
>>>> +		if (vm)
>>>> +			vfree((void *)shadow_start);
>>>> +	}
>>>
>>> This looks like a complicated way to spell 'is_vmalloc_addr' ...
>>>
>>
>> It's not. shadow_start is never vmalloc address.
> 
> I'm confused.  How can you call vfree() on something that isn't a vmalloc
> address?
> 

​vfree() is able to free any address returned by __vmalloc_node_range().
And __vmalloc_node_range() gives you any address you ask.
It doesn't have to be an address in [VMALLOC_START, VMALLOC_END] range.

That's also how the module_alloc()/module_memfree() works on architectures that
have designated area for modules.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[David Hildenbrand]

On 01.02.2018 17:33, Andrey Ryabinin wrote:
> KASAN uses different routines to map shadow for hot added memory and memory
> obtained in boot process. Attempt to offline memory onlined by normal boot
> process leads to this:
> 
>     Trying to vfree() nonexistent vm area (000000005d3b34b9)
>     WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
> 
>     Call Trace:
>      kasan_mem_notifier+0xad/0xb9
>      notifier_call_chain+0x166/0x260
>      __blocking_notifier_call_chain+0xdb/0x140
>      __offline_pages+0x96a/0xb10
>      memory_subsys_offline+0x76/0xc0
>      device_offline+0xb8/0x120
>      store_mem_state+0xfa/0x120
>      kernfs_fop_write+0x1d5/0x320
>      __vfs_write+0xd4/0x530
>      vfs_write+0x105/0x340
>      SyS_write+0xb0/0x140
> 
> Obviously we can't call vfree() to free memory that wasn't allocated via
> vmalloc(). Use find_vm_area() to see if we can call vfree().
> 
> Unfortunately it's a bit tricky to properly unmap and free shadow allocated
> during boot, so we'll have to keep it. If memory will come online again
> that shadow will be reused.
> 

While debugging kasan memory hotplug problems I am having, stumbled over
this patch.

Couldn't we handle that via VM_KASAN like in kasan_module_alloc/free
instead?

> Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
> Reported-by: Paul Menzel <pmenzel+linux-kasan-dev@molgen.mpg.de>
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: <stable@vger.kernel.org>
> ---
>  mm/kasan/kasan.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 55 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index e13d911251e7..0d9d9d268f32 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -791,6 +791,41 @@ DEFINE_ASAN_SET_SHADOW(f5);
>  DEFINE_ASAN_SET_SHADOW(f8);
>  
>  #ifdef CONFIG_MEMORY_HOTPLUG
> +static bool shadow_mapped(unsigned long addr)
> +{
> +	pgd_t *pgd = pgd_offset_k(addr);
> +	p4d_t *p4d;
> +	pud_t *pud;
> +	pmd_t *pmd;
> +	pte_t *pte;
> +
> +	if (pgd_none(*pgd))
> +		return false;
> +	p4d = p4d_offset(pgd, addr);
> +	if (p4d_none(*p4d))
> +		return false;
> +	pud = pud_offset(p4d, addr);
> +	if (pud_none(*pud))
> +		return false;
> +
> +	/*
> +	 * We can't use pud_large() or pud_huge(), the first one
> +	 * is arch-specific, the last one depend on HUGETLB_PAGE.
> +	 * So let's abuse pud_bad(), if bud is bad it's has to
> +	 * because it's huge.
> +	 */
> +	if (pud_bad(*pud))
> +		return true;
> +	pmd = pmd_offset(pud, addr);
> +	if (pmd_none(*pmd))
> +		return false;
> +
> +	if (pmd_bad(*pmd))
> +		return true;
> +	pte = pte_offset_kernel(pmd, addr);
> +	return !pte_none(*pte);
> +}
> +
>  static int __meminit kasan_mem_notifier(struct notifier_block *nb,
>  			unsigned long action, void *data)
>  {
> @@ -812,6 +847,14 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
>  	case MEM_GOING_ONLINE: {
>  		void *ret;
>  
> +		/*
> +		 * If shadow is mapped already than it must have been mapped
> +		 * during the boot. This could happen if we onlining previously
> +		 * offlined memory.
> +		 */
> +		if (shadow_mapped(shadow_start))
> +			return NOTIFY_OK;
> +
>  		ret = __vmalloc_node_range(shadow_size, PAGE_SIZE, shadow_start,
>  					shadow_end, GFP_KERNEL,
>  					PAGE_KERNEL, VM_NO_GUARD,
> @@ -823,8 +866,18 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
>  		kmemleak_ignore(ret);
>  		return NOTIFY_OK;
>  	}
> -	case MEM_OFFLINE:
> -		vfree((void *)shadow_start);
> +	case MEM_OFFLINE: {
> +		struct vm_struct *vm;
> +
> +		/*
> +		 * Only hot-added memory have vm_area. Freeing shadow
> +		 * mapped during boot would be tricky, so we'll just
> +		 * have to keep it.
> +		 */
> +		vm = find_vm_area((void *)shadow_start);
> +		if (vm)
> +			vfree((void *)shadow_start);
> +	}
>  	}
>  
>  	return NOTIFY_OK;
> 


-- 

Thanks,

David / dhildenb

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[David Hildenbrand]

On 18.05.2018 17:57, David Hildenbrand wrote:
> On 01.02.2018 17:33, Andrey Ryabinin wrote:
>> KASAN uses different routines to map shadow for hot added memory and memory
>> obtained in boot process. Attempt to offline memory onlined by normal boot
>> process leads to this:
>>
>>     Trying to vfree() nonexistent vm area (000000005d3b34b9)
>>     WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
>>
>>     Call Trace:
>>      kasan_mem_notifier+0xad/0xb9
>>      notifier_call_chain+0x166/0x260
>>      __blocking_notifier_call_chain+0xdb/0x140
>>      __offline_pages+0x96a/0xb10
>>      memory_subsys_offline+0x76/0xc0
>>      device_offline+0xb8/0x120
>>      store_mem_state+0xfa/0x120
>>      kernfs_fop_write+0x1d5/0x320
>>      __vfs_write+0xd4/0x530
>>      vfs_write+0x105/0x340
>>      SyS_write+0xb0/0x140
>>
>> Obviously we can't call vfree() to free memory that wasn't allocated via
>> vmalloc(). Use find_vm_area() to see if we can call vfree().
>>
>> Unfortunately it's a bit tricky to properly unmap and free shadow allocated
>> during boot, so we'll have to keep it. If memory will come online again
>> that shadow will be reused.
>>
> 
> While debugging kasan memory hotplug problems I am having, stumbled over
> this patch.
> 
> Couldn't we handle that via VM_KASAN like in kasan_module_alloc/free
> instead?
> 

Just realized that this will most probably not work. So please ignore my
comment for now :)

-- 

Thanks,

David / dhildenb

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[Andrey Ryabinin]

On 02/01/2018 07:33 PM, Andrey Ryabinin wrote:
> KASAN uses different routines to map shadow for hot added memory and memory
> obtained in boot process. Attempt to offline memory onlined by normal boot
> process leads to this:
> 
>     Trying to vfree() nonexistent vm area (000000005d3b34b9)
>     WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
> 
>     Call Trace:
>      kasan_mem_notifier+0xad/0xb9
>      notifier_call_chain+0x166/0x260
>      __blocking_notifier_call_chain+0xdb/0x140
>      __offline_pages+0x96a/0xb10
>      memory_subsys_offline+0x76/0xc0
>      device_offline+0xb8/0x120
>      store_mem_state+0xfa/0x120
>      kernfs_fop_write+0x1d5/0x320
>      __vfs_write+0xd4/0x530
>      vfs_write+0x105/0x340
>      SyS_write+0xb0/0x140
> 
> Obviously we can't call vfree() to free memory that wasn't allocated via
> vmalloc(). Use find_vm_area() to see if we can call vfree().
> 
> Unfortunately it's a bit tricky to properly unmap and free shadow allocated
> during boot, so we'll have to keep it. If memory will come online again
> that shadow will be reused.
> 
> Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
> Reported-by: Paul Menzel <pmenzel+linux-kasan-dev@molgen.mpg.de>
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: <stable@vger.kernel.org>
> ---

This seems stuck in -mm. Andrew, can we proceed?

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[Andrew Morton]

On Tue, 22 May 2018 19:44:06 +0300 Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:

> > Obviously we can't call vfree() to free memory that wasn't allocated via
> > vmalloc(). Use find_vm_area() to see if we can call vfree().
> > 
> > Unfortunately it's a bit tricky to properly unmap and free shadow allocated
> > during boot, so we'll have to keep it. If memory will come online again
> > that shadow will be reused.
> > 
> > Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
> > Reported-by: Paul Menzel <pmenzel+linux-kasan-dev@molgen.mpg.de>
> > Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Cc: <stable@vger.kernel.org>
> > ---
> 
> This seems stuck in -mm. Andrew, can we proceed?

OK.

Should there be a code comment explaining the situation that Matthew
asked about?  It's rather obscure.

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

[Andrey Ryabinin]

On 05/23/2018 12:03 AM, Andrew Morton wrote:
> On Tue, 22 May 2018 19:44:06 +0300 Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:
> 
>>> Obviously we can't call vfree() to free memory that wasn't allocated via
>>> vmalloc(). Use find_vm_area() to see if we can call vfree().
>>>
>>> Unfortunately it's a bit tricky to properly unmap and free shadow allocated
>>> during boot, so we'll have to keep it. If memory will come online again
>>> that shadow will be reused.
>>>
>>> Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
>>> Reported-by: Paul Menzel <pmenzel+linux-kasan-dev@molgen.mpg.de>
>>> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>>> Cc: <stable@vger.kernel.org>
>>> ---
>>
>> This seems stuck in -mm. Andrew, can we proceed?
> 
> OK.
> 
> Should there be a code comment explaining the situation that Matthew
> asked about?  It's rather obscure.
> 

Ok. Here is my attempt to improve the situation. If something is still not clear,
I'm open to suggestions.



From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Subject: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix

Improve comments.

Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
---
 mm/kasan/kasan.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 135ce2838c89..ea44dd0bc4e7 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -812,7 +812,7 @@ static bool shadow_mapped(unsigned long addr)
 	/*
 	 * We can't use pud_large() or pud_huge(), the first one
 	 * is arch-specific, the last one depend on HUGETLB_PAGE.
-	 * So let's abuse pud_bad(), if bud is bad it's has to
+	 * So let's abuse pud_bad(), if pud is bad than it's bad
 	 * because it's huge.
 	 */
 	if (pud_bad(*pud))
@@ -871,9 +871,16 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
 		struct vm_struct *vm;
 
 		/*
-		 * Only hot-added memory have vm_area. Freeing shadow
-		 * mapped during boot would be tricky, so we'll just
-		 * have to keep it.
+		 * shadow_start was either mapped during boot by kasan_init()
+		 * or during memory online by __vmalloc_node_range().
+		 * In the latter case we can use vfree() to free shadow.
+		 * Non-NULL result of the find_vm_area() will tell us if
+		 * that was the second case.
+		 *
+		 * Currently it's not possible to free shadow mapped
+		 * during boot by kasan_init(). It's because the code
+		 * to do that hasn't been written yet. So we'll just
+		 * leak the memory.
 		 */
 		vm = find_vm_area((void *)shadow_start);
 		if (vm)
-- 
2.16.1

Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 5120 bytes --]

Hi Andrey,

I love your patch! Yet something to improve:

[auto build test ERROR on mmotm/master]
[cannot apply to v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasan-dont-vfree-nonexistent-vm_area-fix/20180526-093255
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=sparc 

All errors (new ones prefixed by >>):

   fs/autofs/inode.o: In function `autofs_new_ino':
   inode.c:(.text+0x220): multiple definition of `autofs_new_ino'
   fs/autofs/inode.o:inode.c:(.text+0x220): first defined here
   fs/autofs/inode.o: In function `autofs_clean_ino':
   inode.c:(.text+0x280): multiple definition of `autofs_clean_ino'
   fs/autofs/inode.o:inode.c:(.text+0x280): first defined here
   fs/autofs/inode.o: In function `autofs_free_ino':
   inode.c:(.text+0x2c0): multiple definition of `autofs_free_ino'
   fs/autofs/inode.o:inode.c:(.text+0x2c0): first defined here
   fs/autofs/inode.o: In function `autofs_kill_sb':
   inode.c:(.text+0x2e0): multiple definition of `autofs_kill_sb'
   fs/autofs/inode.o:inode.c:(.text+0x2e0): first defined here
   fs/autofs/inode.o: In function `autofs_get_inode':
   inode.c:(.text+0x360): multiple definition of `autofs_get_inode'
   fs/autofs/inode.o:inode.c:(.text+0x360): first defined here
   fs/autofs/inode.o: In function `autofs_fill_super':
   inode.c:(.text+0x440): multiple definition of `autofs_fill_super'
   fs/autofs/inode.o:inode.c:(.text+0x440): first defined here
   fs/autofs/root.o: In function `is_autofs_dentry':
   root.c:(.text+0x1860): multiple definition of `is_autofs_dentry'
   fs/autofs/root.o:root.c:(.text+0x1860): first defined here
   fs/autofs/root.o:(.rodata+0x100): multiple definition of `autofs_dentry_operations'
   fs/autofs/root.o:(.rodata+0x100): first defined here
   fs/autofs/root.o:(.rodata+0x180): multiple definition of `autofs_dir_inode_operations'
   fs/autofs/root.o:(.rodata+0x180): first defined here
   fs/autofs/root.o:(.rodata+0x240): multiple definition of `autofs_dir_operations'
   fs/autofs/root.o:(.rodata+0x240): first defined here
   fs/autofs/root.o:(.rodata+0x338): multiple definition of `autofs_root_operations'
   fs/autofs/root.o:(.rodata+0x338): first defined here
   fs/autofs/symlink.o:(.rodata+0x0): multiple definition of `autofs_symlink_inode_operations'
   fs/autofs/symlink.o:(.rodata+0x0): first defined here
   fs/autofs/waitq.o: In function `autofs_catatonic_mode':
>> waitq.c:(.text+0x80): multiple definition of `autofs_catatonic_mode'
   fs/autofs/waitq.o:waitq.c:(.text+0x80): first defined here
   fs/autofs/waitq.o: In function `autofs_wait_release':
>> waitq.c:(.text+0x180): multiple definition of `autofs_wait_release'
   fs/autofs/waitq.o:waitq.c:(.text+0x180): first defined here
   fs/autofs/waitq.o: In function `autofs_wait':
>> waitq.c:(.text+0x520): multiple definition of `autofs_wait'
   fs/autofs/waitq.o:waitq.c:(.text+0x520): first defined here
   fs/autofs/expire.o: In function `autofs_expire_direct':
   expire.c:(.text+0x7a0): multiple definition of `autofs_expire_direct'
   fs/autofs/expire.o:expire.c:(.text+0x7a0): first defined here
   fs/autofs/expire.o: In function `autofs_expire_indirect':
   expire.c:(.text+0x8e0): multiple definition of `autofs_expire_indirect'
   fs/autofs/expire.o:expire.c:(.text+0x8e0): first defined here
   fs/autofs/expire.o: In function `autofs_expire_wait':
   expire.c:(.text+0xba0): multiple definition of `autofs_expire_wait'
   fs/autofs/expire.o:expire.c:(.text+0xba0): first defined here
   fs/autofs/expire.o: In function `autofs_expire_run':
   expire.c:(.text+0xce0): multiple definition of `autofs_expire_run'
   fs/autofs/expire.o:expire.c:(.text+0xce0): first defined here
   fs/autofs/expire.o: In function `autofs_do_expire_multi':
   expire.c:(.text+0xde0): multiple definition of `autofs_do_expire_multi'
   fs/autofs/expire.o:expire.c:(.text+0xde0): first defined here
   fs/autofs/expire.o: In function `autofs_expire_multi':
   expire.c:(.text+0xea0): multiple definition of `autofs_expire_multi'
   fs/autofs/expire.o:expire.c:(.text+0xea0): first defined here
   fs/autofs/dev-ioctl.o: In function `autofs_dev_ioctl_init':
   dev-ioctl.c:(.init.text+0x0): multiple definition of `autofs_dev_ioctl_init'
   fs/autofs/dev-ioctl.o:dev-ioctl.c:(.init.text+0x0): first defined here
   fs/autofs/dev-ioctl.o: In function `autofs_dev_ioctl_exit':
   dev-ioctl.c:(.text+0xbc0): multiple definition of `autofs_dev_ioctl_exit'
   fs/autofs/dev-ioctl.o:dev-ioctl.c:(.text+0xbc0): first defined here

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 54228 bytes --]

Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix

[Andrew Morton]

On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot <lkp@intel.com> wrote:

> Hi Andrey,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on mmotm/master]
> [cannot apply to v4.17-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasan-dont-vfree-nonexistent-vm_area-fix/20180526-093255
> base:   git://git.cmpxchg.org/linux-mmotm.git master
> config: sparc-allyesconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         make.cross ARCH=sparc 
> 
> All errors (new ones prefixed by >>):
> 
>    fs/autofs/inode.o: In function `autofs_new_ino':
>    inode.c:(.text+0x220): multiple definition of `autofs_new_ino'
>    fs/autofs/inode.o:inode.c:(.text+0x220): first defined here
>    fs/autofs/inode.o: In function `autofs_clean_ino':
>    inode.c:(.text+0x280): multiple definition of `autofs_clean_ino'
>    fs/autofs/inode.o:inode.c:(.text+0x280): first defined here

There's bot breakage here - clearly that patch didn't cause this error.

Ian, this autofs glitch may still not be fixed.

Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 4962 bytes --]

Hi Andrey,

I love your patch! Yet something to improve:

[auto build test ERROR on mmotm/master]
[cannot apply to v4.17-rc7 next-20180529]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasan-dont-vfree-nonexistent-vm_area-fix/20180526-093255
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

   fs/autofs/inode.o: In function `autofs_new_ino':
>> inode.c:(.text+0x170): multiple definition of `autofs_new_ino'
   fs/autofs/inode.o:inode.c:(.text+0x170): first defined here
   fs/autofs/inode.o: In function `autofs_clean_ino':
>> inode.c:(.text+0x1c0): multiple definition of `autofs_clean_ino'
   fs/autofs/inode.o:inode.c:(.text+0x1c0): first defined here
   fs/autofs/inode.o: In function `autofs_free_ino':
>> inode.c:(.text+0x1f0): multiple definition of `autofs_free_ino'
   fs/autofs/inode.o:inode.c:(.text+0x1f0): first defined here
   fs/autofs/inode.o: In function `autofs_kill_sb':
>> inode.c:(.text+0x200): multiple definition of `autofs_kill_sb'
   fs/autofs/inode.o:inode.c:(.text+0x200): first defined here
   fs/autofs/inode.o: In function `autofs_get_inode':
>> inode.c:(.text+0x250): multiple definition of `autofs_get_inode'
   fs/autofs/inode.o:inode.c:(.text+0x250): first defined here
   fs/autofs/inode.o: In function `autofs_fill_super':
>> inode.c:(.text+0x300): multiple definition of `autofs_fill_super'
   fs/autofs/inode.o:inode.c:(.text+0x300): first defined here
   fs/autofs/root.o: In function `is_autofs_dentry':
>> root.c:(.text+0x1170): multiple definition of `is_autofs_dentry'
   fs/autofs/root.o:root.c:(.text+0x1170): first defined here
>> fs/autofs/root.o:(.rodata+0x0): multiple definition of `autofs_dentry_operations'
   fs/autofs/root.o:(.rodata+0x0): first defined here
>> fs/autofs/root.o:(.rodata+0x40): multiple definition of `autofs_dir_inode_operations'
   fs/autofs/root.o:(.rodata+0x40): first defined here
>> fs/autofs/root.o:(.rodata+0xc0): multiple definition of `autofs_dir_operations'
   fs/autofs/root.o:(.rodata+0xc0): first defined here
>> fs/autofs/root.o:(.rodata+0x140): multiple definition of `autofs_root_operations'
   fs/autofs/root.o:(.rodata+0x140): first defined here
>> fs/autofs/symlink.o:(.rodata+0x0): multiple definition of `autofs_symlink_inode_operations'
   fs/autofs/symlink.o:(.rodata+0x0): first defined here
   fs/autofs/waitq.o: In function `autofs_catatonic_mode':
>> waitq.c:(.text+0x60): multiple definition of `autofs_catatonic_mode'
   fs/autofs/waitq.o:waitq.c:(.text+0x60): first defined here
   fs/autofs/waitq.o: In function `autofs_wait_release':
>> waitq.c:(.text+0x110): multiple definition of `autofs_wait_release'
   fs/autofs/waitq.o:waitq.c:(.text+0x110): first defined here
   fs/autofs/waitq.o: In function `autofs_wait':
>> waitq.c:(.text+0x520): multiple definition of `autofs_wait'
   fs/autofs/waitq.o:waitq.c:(.text+0x520): first defined here
   fs/autofs/expire.o: In function `autofs_expire_direct':
   expire.c:(.text+0x4d0): multiple definition of `autofs_expire_direct'
   fs/autofs/expire.o:expire.c:(.text+0x4d0): first defined here
   fs/autofs/expire.o: In function `autofs_expire_indirect':
   expire.c:(.text+0x5c0): multiple definition of `autofs_expire_indirect'
   fs/autofs/expire.o:expire.c:(.text+0x5c0): first defined here
   fs/autofs/expire.o: In function `autofs_expire_wait':
   expire.c:(.text+0x840): multiple definition of `autofs_expire_wait'
   fs/autofs/expire.o:expire.c:(.text+0x840): first defined here
   fs/autofs/expire.o: In function `autofs_expire_run':
   expire.c:(.text+0x910): multiple definition of `autofs_expire_run'
   fs/autofs/expire.o:expire.c:(.text+0x910): first defined here
   fs/autofs/expire.o: In function `autofs_do_expire_multi':
   expire.c:(.text+0xa30): multiple definition of `autofs_do_expire_multi'
   fs/autofs/expire.o:expire.c:(.text+0xa30): first defined here
   fs/autofs/expire.o: In function `autofs_expire_multi':
   expire.c:(.text+0xb00): multiple definition of `autofs_expire_multi'
   fs/autofs/expire.o:expire.c:(.text+0xb00): first defined here
   fs/autofs/dev-ioctl.o: In function `autofs_dev_ioctl_init':
   dev-ioctl.c:(.init.text+0x0): multiple definition of `autofs_dev_ioctl_init'
   fs/autofs/dev-ioctl.o:dev-ioctl.c:(.init.text+0x0): first defined here
   fs/autofs/dev-ioctl.o: In function `autofs_dev_ioctl_exit':
   dev-ioctl.c:(.text+0xac0): multiple definition of `autofs_dev_ioctl_exit'
   fs/autofs/dev-ioctl.o:dev-ioctl.c:(.text+0xac0): first defined here

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 63107 bytes --]