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;
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' ...
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.
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?
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.
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/0x140Obviously 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;
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/0x140Obviously 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 :)
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/0x140Obviously 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?
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.
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)
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... 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
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... 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.
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... 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
linux-stable-mirror@lists.linaro.org
-
Andrew Morton -
Andrey Ryabinin -
David Hildenbrand -
kbuild test robot -
Matthew Wilcox