* [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node
@ 2020-09-03 5:49 kernel test robot
2020-09-03 12:31 ` Joao Martins
0 siblings, 1 reply; 5+ messages in thread
From: kernel test robot @ 2020-09-03 5:49 UTC (permalink / raw)
To: Dan Williams
Cc: kbuild-all, clang-built-linux, Joao Martins, Andrew Morton,
Linux Memory Management List
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 4442749a203151a319a5bb8d0b983b84253a6931
commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range
config: x86_64-randconfig-a002-20200902 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> ld.lld: error: undefined symbol: phys_to_target_node
>>> referenced by device.c:84 (drivers/dax/hmem/device.c:84)
>>> dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29623 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node 2020-09-03 5:49 [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node kernel test robot @ 2020-09-03 12:31 ` Joao Martins 2020-09-05 21:24 ` Randy Dunlap 0 siblings, 1 reply; 5+ messages in thread From: Joao Martins @ 2020-09-03 12:31 UTC (permalink / raw) To: Andrew Morton, Vishal Verma Cc: kernel test robot, Dan Williams, kbuild-all, clang-built-linux, Linux Memory Management List On 9/3/20 6:49 AM, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > head: 4442749a203151a319a5bb8d0b983b84253a6931 > commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range > config: x86_64-randconfig-a002-20200902 (attached as .config) > compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f) > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # install x86_64 cross compiling tool for clang build > # apt-get install binutils-x86-64-linux-gnu > git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot <lkp@intel.com> > > All errors (new ones prefixed by >>): > >>> ld.lld: error: undefined symbol: phys_to_target_node > >>> referenced by device.c:84 (drivers/dax/hmem/device.c:84) > >>> dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a > This would require the proposed fix below the scissors mark. I had reported this failure before, but it needed an adjustment so I'm re-sending it. --------------------------->8---------------------------- From 622c1297b7d76a319b07a29192fe9bfe5c2b6b7c Mon Sep 17 00:00:00 2001 From: Joao Martins <joao.m.martins@oracle.com> Date: Tue, 1 Sep 2020 08:06:35 -0400 Subject: [PATCH] device-dax: Require NUMA_KEEP_MEMINFO for phys_to_target_node() phys_to_target_node() and memory_add_physaddr_to_nid() are only defined with both CONFIG_NUMA=y and CONFIG_MEMORY_HOTPLUG=y. Oherwise we see: drivers/dax/hmem/device.o: in function `hmem_register_one': drivers/dax/hmem/device.c:85: undefined reference to `phys_to_target_node' lkp also reports such build failures: ld.lld: error: undefined symbol: phys_to_target_node X86 is a special case in which both can be defined without depending on MEMORY_HOTPLUG=y. The other case is powerpc (for memory_add_physaddr_to_nid) but like ARM64 dependencies, the arch-specific override requires CONFIG_NUMA and CONFIG_MEMORY_HOTPLUG. In all cases this ends up depending on CONFIG_NUMA_KEEP_MEMINFO to signal the presence of phys_to_target_node() which is what CONFIG_DEV_DAX_HMEM_DEVICES should depend on. Additionally, the X86 arch-override is not selected unless X86_PMEM_LEGACY=y. So on CONFIG_DEV_DAX_HMEM we select CONFIG_NUMA_KEEP_INFO ourselves if both NUMA and X86 are set. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> --- drivers/dax/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig index a66dff78f298..567428e10b7b 100644 --- a/drivers/dax/Kconfig +++ b/drivers/dax/Kconfig @@ -35,6 +35,7 @@ config DEV_DAX_PMEM config DEV_DAX_HMEM tristate "HMEM DAX: direct access to 'specific purpose' memory" depends on EFI_SOFT_RESERVE + select NUMA_KEEP_MEMINFO if (NUMA && X86) default DEV_DAX help EFI 2.8 platforms, and others, may advertise 'specific purpose' @@ -49,6 +50,7 @@ config DEV_DAX_HMEM Say M if unsure. config DEV_DAX_HMEM_DEVICES + depends on NUMA_KEEP_MEMINFO # for phys_to_target_node() depends on DEV_DAX_HMEM && DAX=y def_bool y -- 2.17.1 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node 2020-09-03 12:31 ` Joao Martins @ 2020-09-05 21:24 ` Randy Dunlap 2020-09-05 21:58 ` Randy Dunlap 0 siblings, 1 reply; 5+ messages in thread From: Randy Dunlap @ 2020-09-05 21:24 UTC (permalink / raw) To: Joao Martins, Andrew Morton, Vishal Verma Cc: kernel test robot, Dan Williams, kbuild-all, clang-built-linux, Linux Memory Management List, Matt Fleming On 9/3/20 5:31 AM, Joao Martins wrote: > On 9/3/20 6:49 AM, kernel test robot wrote: >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master >> head: 4442749a203151a319a5bb8d0b983b84253a6931 >> commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range >> config: x86_64-randconfig-a002-20200902 (attached as .config) >> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f) >> reproduce (this is a W=1 build): >> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross >> chmod +x ~/bin/make.cross >> # install x86_64 cross compiling tool for clang build >> # apt-get install binutils-x86-64-linux-gnu >> git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f >> # save the attached .config to linux build tree >> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 >> >> If you fix the issue, kindly add following tag as appropriate >> Reported-by: kernel test robot <lkp@intel.com> >> >> All errors (new ones prefixed by >>): >> >>>> ld.lld: error: undefined symbol: phys_to_target_node >> >>> referenced by device.c:84 (drivers/dax/hmem/device.c:84) >> >>> dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a >> > This would require the proposed fix below the scissors mark. > > I had reported this failure before, but it needed an adjustment so I'm re-sending it. > > --------------------------->8---------------------------- > > From 622c1297b7d76a319b07a29192fe9bfe5c2b6b7c Mon Sep 17 00:00:00 2001 > From: Joao Martins <joao.m.martins@oracle.com> > Date: Tue, 1 Sep 2020 08:06:35 -0400 > Subject: [PATCH] device-dax: Require NUMA_KEEP_MEMINFO for > phys_to_target_node() > > phys_to_target_node() and memory_add_physaddr_to_nid() are only defined > with both CONFIG_NUMA=y and CONFIG_MEMORY_HOTPLUG=y. Oherwise we see: > > drivers/dax/hmem/device.o: in function `hmem_register_one': > drivers/dax/hmem/device.c:85: undefined reference to `phys_to_target_node' > > lkp also reports such build failures: > > ld.lld: error: undefined symbol: phys_to_target_node > > X86 is a special case in which both can be defined without depending on > MEMORY_HOTPLUG=y. The other case is powerpc (for > memory_add_physaddr_to_nid) but like ARM64 dependencies, the > arch-specific override requires CONFIG_NUMA and CONFIG_MEMORY_HOTPLUG. > > In all cases this ends up depending on CONFIG_NUMA_KEEP_MEMINFO to > signal the presence of phys_to_target_node() which is what > CONFIG_DEV_DAX_HMEM_DEVICES should depend on. Additionally, the X86 > arch-override is not selected unless X86_PMEM_LEGACY=y. So on > CONFIG_DEV_DAX_HMEM we select CONFIG_NUMA_KEEP_INFO ourselves if both > NUMA and X86 are set. > > Reported-by: kernel test robot <lkp@intel.com> > Signed-off-by: Joao Martins <joao.m.martins@oracle.com> > --- > drivers/dax/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig > index a66dff78f298..567428e10b7b 100644 > --- a/drivers/dax/Kconfig > +++ b/drivers/dax/Kconfig > @@ -35,6 +35,7 @@ config DEV_DAX_PMEM > config DEV_DAX_HMEM > tristate "HMEM DAX: direct access to 'specific purpose' memory" > depends on EFI_SOFT_RESERVE > + select NUMA_KEEP_MEMINFO if (NUMA && X86) > default DEV_DAX > help > EFI 2.8 platforms, and others, may advertise 'specific purpose' > @@ -49,6 +50,7 @@ config DEV_DAX_HMEM > Say M if unsure. > > config DEV_DAX_HMEM_DEVICES > + depends on NUMA_KEEP_MEMINFO # for phys_to_target_node() > depends on DEV_DAX_HMEM && DAX=y > def_bool y > Hi, There is also this patch from Matt Fleming from last year that I have successfully tested (built) on ppc64 and arch/sh/, where build errors were reported. https://lore.kernel.org/lkml/20191223164220.GA14394@codeblueprint.co.uk/ but Matt doesn't seem to be replying to any emails about this patch... -- ~Randy ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node 2020-09-05 21:24 ` Randy Dunlap @ 2020-09-05 21:58 ` Randy Dunlap 2020-09-06 2:58 ` Randy Dunlap 0 siblings, 1 reply; 5+ messages in thread From: Randy Dunlap @ 2020-09-05 21:58 UTC (permalink / raw) To: Joao Martins, Andrew Morton, Vishal Verma Cc: kernel test robot, Dan Williams, kbuild-all, clang-built-linux, Linux Memory Management List, Matt Fleming On 9/5/20 2:24 PM, Randy Dunlap wrote: > On 9/3/20 5:31 AM, Joao Martins wrote: >> On 9/3/20 6:49 AM, kernel test robot wrote: >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master >>> head: 4442749a203151a319a5bb8d0b983b84253a6931 >>> commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range >>> config: x86_64-randconfig-a002-20200902 (attached as .config) >>> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f) >>> reproduce (this is a W=1 build): >>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross >>> chmod +x ~/bin/make.cross >>> # install x86_64 cross compiling tool for clang build >>> # apt-get install binutils-x86-64-linux-gnu >>> git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f >>> # save the attached .config to linux build tree >>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 >>> >>> If you fix the issue, kindly add following tag as appropriate >>> Reported-by: kernel test robot <lkp@intel.com> >>> >>> All errors (new ones prefixed by >>): >>> >>>>> ld.lld: error: undefined symbol: phys_to_target_node >>> >>> referenced by device.c:84 (drivers/dax/hmem/device.c:84) >>> >>> dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a >>> >> This would require the proposed fix below the scissors mark. >> >> I had reported this failure before, but it needed an adjustment so I'm re-sending it. >> >> --------------------------->8---------------------------- >> >> From 622c1297b7d76a319b07a29192fe9bfe5c2b6b7c Mon Sep 17 00:00:00 2001 >> From: Joao Martins <joao.m.martins@oracle.com> >> Date: Tue, 1 Sep 2020 08:06:35 -0400 >> Subject: [PATCH] device-dax: Require NUMA_KEEP_MEMINFO for >> phys_to_target_node() >> >> phys_to_target_node() and memory_add_physaddr_to_nid() are only defined >> with both CONFIG_NUMA=y and CONFIG_MEMORY_HOTPLUG=y. Oherwise we see: >> >> drivers/dax/hmem/device.o: in function `hmem_register_one': >> drivers/dax/hmem/device.c:85: undefined reference to `phys_to_target_node' >> >> lkp also reports such build failures: >> >> ld.lld: error: undefined symbol: phys_to_target_node >> >> X86 is a special case in which both can be defined without depending on >> MEMORY_HOTPLUG=y. The other case is powerpc (for >> memory_add_physaddr_to_nid) but like ARM64 dependencies, the >> arch-specific override requires CONFIG_NUMA and CONFIG_MEMORY_HOTPLUG. >> >> In all cases this ends up depending on CONFIG_NUMA_KEEP_MEMINFO to >> signal the presence of phys_to_target_node() which is what >> CONFIG_DEV_DAX_HMEM_DEVICES should depend on. Additionally, the X86 >> arch-override is not selected unless X86_PMEM_LEGACY=y. So on >> CONFIG_DEV_DAX_HMEM we select CONFIG_NUMA_KEEP_INFO ourselves if both >> NUMA and X86 are set. >> >> Reported-by: kernel test robot <lkp@intel.com> >> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> >> --- >> drivers/dax/Kconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig >> index a66dff78f298..567428e10b7b 100644 >> --- a/drivers/dax/Kconfig >> +++ b/drivers/dax/Kconfig >> @@ -35,6 +35,7 @@ config DEV_DAX_PMEM >> config DEV_DAX_HMEM >> tristate "HMEM DAX: direct access to 'specific purpose' memory" >> depends on EFI_SOFT_RESERVE >> + select NUMA_KEEP_MEMINFO if (NUMA && X86) >> default DEV_DAX >> help >> EFI 2.8 platforms, and others, may advertise 'specific purpose' >> @@ -49,6 +50,7 @@ config DEV_DAX_HMEM >> Say M if unsure. >> >> config DEV_DAX_HMEM_DEVICES >> + depends on NUMA_KEEP_MEMINFO # for phys_to_target_node() >> depends on DEV_DAX_HMEM && DAX=y >> def_bool y >> > > Hi, > > There is also this patch from Matt Fleming from last year that I have > successfully tested (built) on ppc64 and arch/sh/, where build errors were reported. > > https://lore.kernel.org/lkml/20191223164220.GA14394@codeblueprint.co.uk/ > > but Matt doesn't seem to be replying to any emails about this patch... > OK, Matt's patch doesn't fix this x86_64 dax + hmem build error, so apparently Joao's patch is needed. -- ~Randy ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node 2020-09-05 21:58 ` Randy Dunlap @ 2020-09-06 2:58 ` Randy Dunlap 0 siblings, 0 replies; 5+ messages in thread From: Randy Dunlap @ 2020-09-06 2:58 UTC (permalink / raw) To: Joao Martins, Andrew Morton, Vishal Verma Cc: kernel test robot, Dan Williams, kbuild-all, clang-built-linux, Linux Memory Management List, Matt Fleming On 9/5/20 2:58 PM, Randy Dunlap wrote: > On 9/5/20 2:24 PM, Randy Dunlap wrote: >> On 9/3/20 5:31 AM, Joao Martins wrote: >>> On 9/3/20 6:49 AM, kernel test robot wrote: >>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master >>>> head: 4442749a203151a319a5bb8d0b983b84253a6931 >>>> commit: bd295a352cfa24e5110a53f978edb48b7c21ff8f [2890/4758] ACPI: HMAT: attach a device for each soft-reserved range >>>> config: x86_64-randconfig-a002-20200902 (attached as .config) >>>> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 224d8153b53b16cf535ea1a55afdfe1ec5b1374f) >>>> reproduce (this is a W=1 build): >>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross >>>> chmod +x ~/bin/make.cross >>>> # install x86_64 cross compiling tool for clang build >>>> # apt-get install binutils-x86-64-linux-gnu >>>> git checkout bd295a352cfa24e5110a53f978edb48b7c21ff8f >>>> # save the attached .config to linux build tree >>>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 >>>> >>>> If you fix the issue, kindly add following tag as appropriate >>>> Reported-by: kernel test robot <lkp@intel.com> >>>> >>>> All errors (new ones prefixed by >>): >>>> >>>>>> ld.lld: error: undefined symbol: phys_to_target_node >>>> >>> referenced by device.c:84 (drivers/dax/hmem/device.c:84) >>>> >>> dax/hmem/device.o:(hmem_register_one) in archive drivers/built-in.a >>>> >>> This would require the proposed fix below the scissors mark. >>> >>> I had reported this failure before, but it needed an adjustment so I'm re-sending it. >>> >>> --------------------------->8---------------------------- >>> >>> From 622c1297b7d76a319b07a29192fe9bfe5c2b6b7c Mon Sep 17 00:00:00 2001 >>> From: Joao Martins <joao.m.martins@oracle.com> >>> Date: Tue, 1 Sep 2020 08:06:35 -0400 >>> Subject: [PATCH] device-dax: Require NUMA_KEEP_MEMINFO for >>> phys_to_target_node() >>> >>> phys_to_target_node() and memory_add_physaddr_to_nid() are only defined >>> with both CONFIG_NUMA=y and CONFIG_MEMORY_HOTPLUG=y. Oherwise we see: >>> >>> drivers/dax/hmem/device.o: in function `hmem_register_one': >>> drivers/dax/hmem/device.c:85: undefined reference to `phys_to_target_node' >>> >>> lkp also reports such build failures: >>> >>> ld.lld: error: undefined symbol: phys_to_target_node >>> >>> X86 is a special case in which both can be defined without depending on >>> MEMORY_HOTPLUG=y. The other case is powerpc (for >>> memory_add_physaddr_to_nid) but like ARM64 dependencies, the >>> arch-specific override requires CONFIG_NUMA and CONFIG_MEMORY_HOTPLUG. >>> >>> In all cases this ends up depending on CONFIG_NUMA_KEEP_MEMINFO to >>> signal the presence of phys_to_target_node() which is what >>> CONFIG_DEV_DAX_HMEM_DEVICES should depend on. Additionally, the X86 >>> arch-override is not selected unless X86_PMEM_LEGACY=y. So on >>> CONFIG_DEV_DAX_HMEM we select CONFIG_NUMA_KEEP_INFO ourselves if both >>> NUMA and X86 are set. >>> >>> Reported-by: kernel test robot <lkp@intel.com> >>> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> >>> --- >>> drivers/dax/Kconfig | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig >>> index a66dff78f298..567428e10b7b 100644 >>> --- a/drivers/dax/Kconfig >>> +++ b/drivers/dax/Kconfig >>> @@ -35,6 +35,7 @@ config DEV_DAX_PMEM >>> config DEV_DAX_HMEM >>> tristate "HMEM DAX: direct access to 'specific purpose' memory" >>> depends on EFI_SOFT_RESERVE >>> + select NUMA_KEEP_MEMINFO if (NUMA && X86) >>> default DEV_DAX >>> help >>> EFI 2.8 platforms, and others, may advertise 'specific purpose' >>> @@ -49,6 +50,7 @@ config DEV_DAX_HMEM >>> Say M if unsure. >>> >>> config DEV_DAX_HMEM_DEVICES >>> + depends on NUMA_KEEP_MEMINFO # for phys_to_target_node() >>> depends on DEV_DAX_HMEM && DAX=y >>> def_bool y >>> >> >> Hi, >> >> There is also this patch from Matt Fleming from last year that I have >> successfully tested (built) on ppc64 and arch/sh/, where build errors were reported. >> >> https://lore.kernel.org/lkml/20191223164220.GA14394@codeblueprint.co.uk/ >> >> but Matt doesn't seem to be replying to any emails about this patch... >> > > OK, Matt's patch doesn't fix this x86_64 dax + hmem build error, so > apparently Joao's patch is needed. > OTOH, Joao's patch doesn't fix the ppc64 and arch/sh/ build errors. I'd prefer to see one patch to fix all of these build errors... -- ~Randy ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-09-06 2:58 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-03 5:49 [linux-next:master 2890/4758] ld.lld: error: undefined symbol: phys_to_target_node kernel test robot 2020-09-03 12:31 ` Joao Martins 2020-09-05 21:24 ` Randy Dunlap 2020-09-05 21:58 ` Randy Dunlap 2020-09-06 2:58 ` Randy Dunlap
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox