* Re: [PATCH 3/6] binfmt_elf: remove the set_fs(KERNEL_DS) in elf_core_dump
From: Christoph Hellwig @ 2020-04-06 13:03 UTC (permalink / raw)
To: Al Viro
Cc: Arnd Bergmann, linux-kernel, Jeremy Kerr, linux-fsdevel,
Andrew Morton, linuxppc-dev, Christoph Hellwig
In-Reply-To: <20200406130238.GT23230@ZenIV.linux.org.uk>
On Mon, Apr 06, 2020 at 02:02:38PM +0100, Al Viro wrote:
> On Mon, Apr 06, 2020 at 02:03:09PM +0200, Christoph Hellwig wrote:
> > There is no logic in elf_core_dump itself that uses uaccess routines
> > on kernel pointers, the file writes are nicely encapsulated in dump_emit
> > which does its own set_fs.
>
> ... assuming you've checked the asm/elf.h to see that nobody is playing
> silly buggers in these forests of macros and the stuff called from those.
> Which is a feat that ought to be mentioned in commit message...
None of the calls should go into asm/elf.h headers, but some go to
various out of line arch callouts. And I did look through those - spufs
was the only funky one.
^ permalink raw reply
* Re: [PATCH 2/6] binfmt_elf: open code copy_siginfo_to_user to kernelspace buffer
From: Christoph Hellwig @ 2020-04-06 13:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel@vger.kernel.org, Jeremy Kerr,
Linux FS-devel Mailing List, Andrew Morton, linuxppc-dev,
Christoph Hellwig, Alexander Viro
In-Reply-To: <CAK8P3a02LQNOehukgaCj81wg1D2XhW1=_mQZ72cT6nQdO=mhOw@mail.gmail.com>
On Mon, Apr 06, 2020 at 03:01:24PM +0200, Arnd Bergmann wrote:
> > static void fill_siginfo_note(struct memelfnote *note, user_siginfo_t *csigdata,
> > const kernel_siginfo_t *siginfo)
> > {
> > - mm_segment_t old_fs = get_fs();
> > - set_fs(KERNEL_DS);
> > - copy_siginfo_to_user((user_siginfo_t __user *) csigdata, siginfo);
> > - set_fs(old_fs);
> > + memcpy(csigdata, siginfo, sizeof(struct kernel_siginfo));
> > + memset((char *)csigdata + sizeof(struct kernel_siginfo), 0,
> > + SI_EXPANSION_SIZE);
> > fill_note(note, "CORE", NT_SIGINFO, sizeof(*csigdata), csigdata);
> > }
>
> I think this breaks compat binfmt-elf mode, which relies on this trick:
>
> fs/compat_binfmt_elf.c:#define copy_siginfo_to_user copy_siginfo_to_user32
> fs/compat_binfmt_elf.c#include "binfmt_elf.c"
>
> At least we seem to only have one remaining implementation of
> __copy_siginfo_to_user32(), so fixing this won't require touching all
> architectures, but I don't see an obvious way to do it right. Maybe
> compat-binfmt-elf.c should just override fill_siginfo_note() itself
> rather than overriding copy_siginfo_to_user().
Ooops. Yes, this will need some manual handling.
^ permalink raw reply
* Re: [PATCH v2] powerpc/time: Replace <linux/clk-provider.h> by <linux/of_clk.h>
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Geert Uytterhoeven, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-clk, Geert Uytterhoeven, linux-kernel
In-Reply-To: <20200213083804.24315-1-geert+renesas@glider.be>
On Thu, 2020-02-13 at 08:38:04 UTC, Geert Uytterhoeven wrote:
> The PowerPC time code is not a clock provider, and just needs to call
> of_clk_init().
>
> Hence it can include <linux/of_clk.h> instead of <linux/clk-provider.h>.
>
> Remove the #ifdef protecting the of_clk_init() call, as a stub is
> available for the !CONFIG_COMMON_CLK case.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/60083063b755e29685902609e024ecd0c4a1a7d9
cheers
^ permalink raw reply
* Re: [PATCH v4 1/2] powerpc/perf: Implement a global lock to avoid races between trace, core and thread imc events.
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Anju T Sudhakar; +Cc: linuxppc-dev, harihare, maddy, anju
In-Reply-To: <20200313055238.8656-1-anju@linux.vnet.ibm.com>
On Fri, 2020-03-13 at 05:52:37 UTC, Anju T Sudhakar wrote:
> IMC(In-memory Collection Counters) does performance monitoring in
> two different modes, i.e accumulation mode(core-imc and thread-imc events),
> and trace mode(trace-imc events). A cpu thread can either be in
> accumulation-mode or trace-mode at a time and this is done via the LDBAR
> register in POWER architecture. The current design does not address the
> races between thread-imc and trace-imc events.
>
> Patch implements a global id and lock to avoid the races between
> core, trace and thread imc events. With this global id-lock
> implementation, the system can either run core, thread or trace imc
> events at a time. i.e. to run any core-imc events, thread/trace imc events
> should not be enabled/monitored.
>
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a36e8ba60b991d563677227f172db69e030797e6
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries: Fix MCE handling on pseries
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Ganesh Goudar, linuxppc-dev; +Cc: mahesh, npiggin
In-Reply-To: <20200320110119.10207-1-ganeshgr@linux.ibm.com>
On Fri, 2020-03-20 at 11:01:19 UTC, Ganesh Goudar wrote:
> MCE handling on pSeries platform fails as recent rework to use common
> code for pSeries and PowerNV in machine check error handling tries to
> access per-cpu variables in realmode. The per-cpu variables may be
> outside the RMO region on pSeries platform and needs translation to be
> enabled for access. Just moving these per-cpu variable into RMO region
> did'nt help because we queue some work to workqueues in real mode, which
> again tries to touch per-cpu variables. Also fwnmi_release_errinfo()
> cannot be called when translation is not enabled.
>
> This patch fixes this by enabling translation in the exception handler
> when all required real mode handling is done. This change only affects
> the pSeries platform.
>
> Without this fix below kernel crash is seen on injecting
> SLB multihit:
>
> BUG: Unable to handle kernel data access on read at 0xc00000027b205950
> Faulting instruction address: 0xc00000000003b7e0
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: mcetest_slb(OE+) af_packet(E) xt_tcpudp(E) ip6t_rpfilter(E) ip6t_REJECT(E) ipt_REJECT(E) xt_conntrack(E) ip_set(E) nfnetlink(E) ebtable_nat(E) ebtable_broute(E) ip6table_nat(E) ip6table_mangle(E) ip6table_raw(E) ip6table_security(E) iptable_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) ip_tables(E) x_tables(E) xfs(E) ibmveth(E) vmx_crypto(E) gf128mul(E) uio_pdrv_genirq(E) uio(E) crct10dif_vpmsum(E) rtc_generic(E) btrfs(E) libcrc32c(E) xor(E) zstd_decompress(E) zstd_compress(E) raid6_pq(E) sr_mod(E) sd_mod(E) cdrom(E) ibmvscsi(E) scsi_transport_srp(E) crc32c_vpmsum(E) dm_mod(E) sg(E) scsi_mod(E)
> CPU: 34 PID: 8154 Comm: insmod Kdump: loaded Tainted: G OE 5.5.0-mahesh #1
> NIP: c00000000003b7e0 LR: c0000000000f2218 CTR: 0000000000000000
> REGS: c000000007dcb960 TRAP: 0300 Tainted: G OE (5.5.0-mahesh)
> MSR: 8000000000001003 <SF,ME,RI,LE> CR: 28002428 XER: 20040000
> CFAR: c0000000000f2214 DAR: c00000027b205950 DSISR: 40000000 IRQMASK: 0
> GPR00: c0000000000f2218 c000000007dcbbf0 c000000001544800 c000000007dcbd70
> GPR04: 0000000000000001 c000000007dcbc98 c008000000d00258 c0080000011c0000
> GPR08: 0000000000000000 0000000300000003 c000000001035950 0000000003000048
> GPR12: 000000027a1d0000 c000000007f9c000 0000000000000558 0000000000000000
> GPR16: 0000000000000540 c008000001110000 c008000001110540 0000000000000000
> GPR20: c00000000022af10 c00000025480fd70 c008000001280000 c00000004bfbb300
> GPR24: c000000001442330 c00800000800000d c008000008000000 4009287a77000510
> GPR28: 0000000000000000 0000000000000002 c000000001033d30 0000000000000001
> NIP [c00000000003b7e0] save_mce_event+0x30/0x240
> LR [c0000000000f2218] pseries_machine_check_realmode+0x2c8/0x4f0
> Call Trace:
> Instruction dump:
> 3c4c0151 38429050 7c0802a6 60000000 fbc1fff0 fbe1fff8 f821ffd1 3d42ffaf
> 3fc2ffaf e98d0030 394a1150 3bdef530 <7d6a62aa> 1d2b0048 2f8b0063 380b0001
> ---[ end trace 46fd63f36bbdd940 ]---
>
> Fixes: 9ca766f9891d ("powerpc/64s/pseries: machine check convert to use common event code")
> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a95a0a1654f16366360399574e10efd87e867b39
cheers
^ permalink raw reply
* Re: [PATCH v12 1/8] powerpc: Add back __ARCH_WANT_SYS_LLSEEK macro
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Michal Suchanek, linuxppc-dev
Cc: Mark Rutland, , Gustavo Luiz Duarte, Peter Zijlstra,
Jordan Niethe, Sebastian Andrzej Siewior, Claudio Carvalho,
Paul Mackerras, Jiri Olsa, Rob Herring, Michael Neuling,
Mauro Carvalho Chehab, Masahiro Yamada, Nayna Jain, el.com,
Alexander Shishkin, Ingo Molnar, Hari Bathini, Michal Suchanek,
Valentin Schneider, Arnd Bergmann, Andy Shevchenko,
Arnaldo Carvalho de Melo, Alexander Viro, Jonathan Cameron,
Namhyung Kim, Thomas Gleixner, Allison Randal, Greg Kroah-Hartman,
Nicholas Piggin, linux-kernel, Eric Richter, Eric W. Biederman,
linux-fsdevel, David S. Miller, Thiago Jung Bauermann
In-Reply-To: <dd4575c51e31766e87f7e7fa121d099ab78d3290.1584699455.git.msuchanek@suse.de>
On Fri, 2020-03-20 at 10:20:12 UTC, Michal Suchanek wrote:
> This partially reverts commit caf6f9c8a326 ("asm-generic: Remove
> unneeded __ARCH_WANT_SYS_LLSEEK macro")
>
> When CONFIG_COMPAT is disabled on ppc64 the kernel does not build.
>
> There is resistance to both removing the llseek syscall from the 64bit
> syscall tables and building the llseek interface unconditionally.
>
> Link: https://lore.kernel.org/lkml/20190828151552.GA16855@infradead.org/
> Link: https://lore.kernel.org/lkml/20190829214319.498c7de2@naga/
>
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Patches 1-7 applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9e62ccec3ba0a17c8050ea78500dfdd0e4c5c0cc
cheers
^ permalink raw reply
* Re: [PATCH 1/9] powerpc/ps3: Remove duplicate error messages
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Geoff Levand
Cc: Geert Uytterhoeven, linuxppc-dev, Markus Elfring, Dan Carpenter,
Emmanuel Nicolet
In-Reply-To: <1bc5a16a22c487c478a204ebb7b80a22d2ad9cd0.1585340156.git.geoff@infradead.org>
On Fri, 2020-03-27 at 20:26:23 UTC, Geoff Levand wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
>
> Remove duplicate memory allocation failure error messages.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7ee417497a29028502cf952f419ab2635f563d51
cheers
^ permalink raw reply
* Re: [PATCH 4/9] powerpc/ps3: remove an unneeded NULL check
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Geoff Levand
Cc: Geert Uytterhoeven, linuxppc-dev, Markus Elfring, Dan Carpenter,
Emmanuel Nicolet
In-Reply-To: <ddc3513dc54d15456692c80df49287fe3babe40a.1585340156.git.geoff@infradead.org>
On Fri, 2020-03-27 at 20:26:23 UTC, Geoff Levand wrote:
> From: Dan Carpenter <dan.carpenter@oracle.com>
>
> Static checkers don't like the inconsistent NULL checking on "ops".
> This function is only called once and "ops" isn't NULL so the check can
> be removed.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/96efbab92cccbe3434501e5a77cbaa01c5bc2767
cheers
^ permalink raw reply
* Re: [PATCH] selftests/eeh: Skip ahci adapters
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: oohall
In-Reply-To: <20200326061144.2006522-1-mpe@ellerman.id.au>
On Thu, 2020-03-26 at 06:11:44 UTC, Michael Ellerman wrote:
> The ahci driver doesn't support error recovery, and if your root
> filesystem is attached to it the eeh-basic.sh test will likely kill
> your machine.
>
> So skip any device we see using the ahci driver.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/bbe9064f30f06e7791d04f9f61a842226a6a44fe
cheers
^ permalink raw reply
* Re: [PATCH 6/9] powerpc/ps3: Set CONFIG_UEVENT_HELPER=y in ps3_defconfig
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Geoff Levand
Cc: Geert Uytterhoeven, linuxppc-dev, Markus Elfring, Dan Carpenter,
Emmanuel Nicolet
In-Reply-To: <410cda9aa1a6e04434dfe1f9aa2103d0694f706c.1585340156.git.geoff@infradead.org>
On Fri, 2020-03-27 at 20:26:23 UTC, Geoff Levand wrote:
> Set CONFIG_UEVENT_HELPER=y in ps3_defconfig.
>
> commit 1be01d4a57142ded23bdb9e0c8d9369e693b26cc (driver: base: Disable
> CONFIG_UEVENT_HELPER by default) disabled the CONFIG_UEVENT_HELPER option
> that is needed for hotplug and module loading by most older 32bit powerpc
> distributions that users typically install on the PS3.
>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d3883fa0784832bb65df019ae6a291a87d146fb1
cheers
^ permalink raw reply
* Re: [PATCH kernel] powerpc/pseries/ddw: Extend upper limit for huge DMA window for persistent memory
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Brian J King, Alexey Kardashevskiy, Aneesh Kumar K . V,
Oliver O'Halloran, David Gibson, Wen Xiong
In-Reply-To: <20200331012338.23773-1-aik@ozlabs.ru>
On Tue, 2020-03-31 at 01:23:38 UTC, Alexey Kardashevskiy wrote:
> Unlike normal memory ("memory" compatible type in the FDT),
> the persistent memory ("ibm,pmemory" in the FDT) can be mapped anywhere
> in the guest physical space and it can be used for DMA.
>
> In order to maintain 1:1 mapping via the huge DMA window, we need to
> know the maximum physical address at the time of the window setup.
> So far we've been looking at "memory" nodes but "ibm,pmemory" does not
> have fixed addresses and the persistent memory may be mapped afterwards.
>
> Since the persistent memory is still backed with page structs,
> use MAX_PHYSMEM_BITS as the upper limit.
>
> This effectively disables huge DMA window in LPAR under pHyp if
> persistent memory is present but this is the best we can do.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/54fc3c681ded9437e4548e2501dc1136b23cfa9a
cheers
^ permalink raw reply
* Re: [PATCH] Revert "powerpc/64: irq_work avoid interrupt when called with hardware irqs enabled"
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20200402120401.1115883-1-npiggin@gmail.com>
On Thu, 2020-04-02 at 12:04:01 UTC, Nicholas Piggin wrote:
> This reverts commit ebb37cf3ffd39fdb6ec5b07111f8bb2f11d92c5f.
>
> That commit does not play well with soft-masked irq state manipulations
> in idle, interrupt replay, and possibly others due to tracing code
> sometimes using irq_work_queue (e.g., in trace_hardirqs_on()). That
> can cause PACA_IRQ_DEC to become set when it is not expected, and be
> ignored or cleared or cause warnings.
>
> The net result seems to be missing an irq_work until the next timer
> interrupt in the worst case which is usually not going to be noticed,
> however it could be a long time if the tick is disabled, which is
> agains the spirit of irq_work and might cause real problems.
>
> The idea is still solid, but it would need more work. It's not really
> clear if it would be worth added complexity, so revert this for now
> (not a straight revert, but replace with a comment explaining why we
> might see interrupts happening, and gives git blame something to find).
>
> Fixes: ebb37cf3ffd3 ("powerpc/64: irq_work avoid interrupt when called with hardware irqs enabled")
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/abc3fce76adbdfa8f87272c784b388cd20b46049
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Fix doorbell wakeup msgclr optimisation
From: Michael Ellerman @ 2020-04-06 13:05 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20200402121212.1118218-1-npiggin@gmail.com>
On Thu, 2020-04-02 at 12:12:12 UTC, Nicholas Piggin wrote:
> Commit 3282a3da25bd ("powerpc/64: Implement soft interrupt replay in C")
> broke the doorbell wakeup optimisation introduced by commit a9af97aa0a12
> ("powerpc/64s: msgclr when handling doorbell exceptions from system
> reset").
>
> This patch restores it, in C code. It's moved explicitly to the system
> reset wakeup path, rather than the doorbell replay path, because it is
> always the right thing to do in the wakeup case, but it could be rare to
> have a pending message in other cases in which case it's wasted work --
> we would have to be done to see if that was a worthwhile optimisation,
> and I suspect it would not be.
>
> The results are similar to those in the original commit, test on POWER8
> of context_switch selftests benchmark with polling idle disabled (e.g.,
> always nap, giving cross-CPU IPIs) gives the following results:
>
> broken patched
> Different threads, same core: 317k/s 375k/s +18.7%
> Different cores: 280k/s 282k/s +1.0%
>
> Fixes: 3282a3da25bd ("powerpc/64: Implement soft interrupt replay in C")
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0c89649a70bed679fd408c1eb82fa99dbe1354a0
cheers
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Always build the tm-poison test 64-bit
From: Michael Ellerman @ 2020-04-06 13:06 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: gromero
In-Reply-To: <20200403095656.3772005-1-mpe@ellerman.id.au>
On Fri, 2020-04-03 at 09:56:56 UTC, Michael Ellerman wrote:
> The tm-poison test includes inline asm which is 64-bit only, so the
> test must be built 64-bit in order to work.
>
> Otherwise it fails, eg:
> # file tm-poison
> tm-poison: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV) ...
> # ./tm-poison
> test: tm_poison_test
> Unknown value 0x1fff71150 leaked into f31!
> Unknown value 0x1fff710c0 leaked into vr31!
> failure: tm_poison_test
>
> Fixes: a003365cab64 ("powerpc/tm: Add tm-poison test")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/6ba4a2d3591039aea1cb45c7c42262d26351a2fa
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: improve ppc_save_regs
From: Michael Ellerman @ 2020-04-06 13:06 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20200403131006.123243-1-npiggin@gmail.com>
On Fri, 2020-04-03 at 13:10:05 UTC, Nicholas Piggin wrote:
> Make ppc_save_regs a bit more useful:
> - Set NIP to our caller rather rather than the caller's caller (which is
> what we save to LR in the stack frame).
> - Set SOFTE to the current irq soft-mask state rather than
> uninitialised.
> - Zero CFAR rather than leave it uninitialised.
>
> In qemu, injecting a nmi to an idle CPU gives a nicer stack trace (note
> NIP, IRQMASK, CFAR).
>
> Oops: System Reset, sig: 6 [#1]
> LE PAGE_SIZE=64K MMU=Hash PREEMPT SMP NR_CPUS=2048 NUMA PowerNV
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc2-00429-ga76e38fd80bf #1277
> NIP: c0000000000b6e5c LR: c0000000000b6e5c CTR: c000000000b06270
> REGS: c00000000173fb08 TRAP: 0100 Not tainted
> MSR: 9000000000001033 <SF,HV,ME,IR,DR,RI,LE> CR: 28000224 XER: 00000000
> CFAR: c0000000016a2128 IRQMASK: c00000000173fc80
> GPR00: c0000000000b6e5c c00000000173fc80 c000000001743400 c00000000173fb08
> GPR04: 0000000000000000 0000000000000000 0000000000000008 0000000000000001
> GPR08: 00000001fea80000 0000000000000000 0000000000000000 ffffffffffffffff
> GPR12: c000000000b06270 c000000001930000 00000000300026c0 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000003 c0000000016a2128
> GPR20: c0000001ffc97148 0000000000000001 c000000000f289a8 0000000000080000
> GPR24: c0000000016e1480 000000011dc870ba 0000000000000000 0000000000000003
> GPR28: c0000000016a2128 c0000001ffc97148 c0000000016a2260 0000000000000003
> NIP [c0000000000b6e5c] power9_idle_type+0x5c/0x70
> LR [c0000000000b6e5c] power9_idle_type+0x5c/0x70
> Call Trace:
> [c00000000173fc80] [c0000000000b6e5c] power9_idle_type+0x5c/0x70 (unreliable)
> [c00000000173fcb0] [c000000000b062b0] stop_loop+0x40/0x60
> [c00000000173fce0] [c000000000b022d8] cpuidle_enter_state+0xa8/0x660
> [c00000000173fd60] [c000000000b0292c] cpuidle_enter+0x4c/0x70
> [c00000000173fda0] [c00000000017624c] call_cpuidle+0x4c/0x90
> [c00000000173fdc0] [c000000000176768] do_idle+0x338/0x460
> [c00000000173fe60] [c000000000176b3c] cpu_startup_entry+0x3c/0x40
> [c00000000173fe90] [c0000000000126b4] rest_init+0x124/0x140
> [c00000000173fed0] [c0000000010948d4] start_kernel+0x938/0x988
> [c00000000173ff90] [c00000000000cdcc] start_here_common+0x1c/0x20
>
> Oops: System Reset, sig: 6 [#1]
> LE PAGE_SIZE=64K MMU=Hash PREEMPT SMP NR_CPUS=2048 NUMA PowerNV
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc2-00430-gddce91b8712f #1278
> NIP: c00000000001d150 LR: c0000000000b6e5c CTR: c000000000b06270
> REGS: c00000000173fb08 TRAP: 0100 Not tainted
> MSR: 9000000000001033 <SF,HV,ME,IR,DR,RI,LE> CR: 28000224 XER: 00000000
> CFAR: 0000000000000000 IRQMASK: 1
> GPR00: c0000000000b6e5c c00000000173fc80 c000000001743400 c00000000173fb08
> GPR04: 0000000000000000 0000000000000000 0000000000000008 0000000000000001
> GPR08: 00000001fea80000 0000000000000000 0000000000000000 ffffffffffffffff
> GPR12: c000000000b06270 c000000001930000 00000000300026c0 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000003 c0000000016a2128
> GPR20: c0000001ffc97148 0000000000000001 c000000000f289a8 0000000000080000
> GPR24: c0000000016e1480 00000000b68db8ce 0000000000000000 0000000000000003
> GPR28: c0000000016a2128 c0000001ffc97148 c0000000016a2260 0000000000000003
> NIP [c00000000001d150] replay_system_reset+0x30/0xa0
> LR [c0000000000b6e5c] power9_idle_type+0x5c/0x70
> Call Trace:
> [c00000000173fc80] [c0000000000b6e5c] power9_idle_type+0x5c/0x70 (unreliable)
> [c00000000173fcb0] [c000000000b062b0] stop_loop+0x40/0x60
> [c00000000173fce0] [c000000000b022d8] cpuidle_enter_state+0xa8/0x660
> [c00000000173fd60] [c000000000b0292c] cpuidle_enter+0x4c/0x70
> [c00000000173fda0] [c00000000017624c] call_cpuidle+0x4c/0x90
> [c00000000173fdc0] [c000000000176768] do_idle+0x338/0x460
> [c00000000173fe60] [c000000000176b38] cpu_startup_entry+0x38/0x40
> [c00000000173fe90] [c0000000000126b4] rest_init+0x124/0x140
> [c00000000173fed0] [c0000000010948d4] start_kernel+0x938/0x988
> [c00000000173ff90] [c00000000000cdcc] start_here_common+0x1c/0x20
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d16a58f8854b194c964a4bbe8156ec624ebfdbd2
cheers
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/spufs: simplify spufs core dumping
From: Arnd Bergmann @ 2020-04-06 13:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-kernel@vger.kernel.org, Alexander Viro,
Linux FS-devel Mailing List, Andrew Morton, linuxppc-dev,
Jeremy Kerr
In-Reply-To: <20200406120312.1150405-2-hch@lst.de>
On Mon, Apr 6, 2020 at 2:03 PM Christoph Hellwig <hch@lst.de> wrote:
>
> Replace the coredump ->read method with a ->dump method that must call
> dump_emit itself. That way we avoid a buffer allocation an messing with
> set_fs() to call into code that is intended to deal with user buffers.
> For the ->get case we can now use a small on-stack buffer and avoid
> memory allocations as well.
I had no memory of this code at all, but your change looks fine to me.
Amazingly you even managed to even make it smaller and more readable
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device
From: Alexey Kardashevskiy @ 2020-04-06 13:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Aneesh Kumar K.V, Joerg Roedel, Robin Murphy, linux-kernel, iommu,
Greg Kroah-Hartman, linuxppc-dev, Lu Baolu
In-Reply-To: <20200406115016.GA10941@lst.de>
On 06/04/2020 21:50, Christoph Hellwig wrote:
> On Fri, Apr 03, 2020 at 07:38:11PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 26/03/2020 12:26, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 25/03/2020 19:37, Christoph Hellwig wrote:
>>>> On Wed, Mar 25, 2020 at 03:51:36PM +1100, Alexey Kardashevskiy wrote:
>>>>>>> This is for persistent memory which you can DMA to/from but yet it does
>>>>>>> not appear in the system as a normal memory and therefore requires
>>>>>>> special handling anyway (O_DIRECT or DAX, I do not know the exact
>>>>>>> mechanics). All other devices in the system should just run as usual,
>>>>>>> i.e. use 1:1 mapping if possible.
>>>>>>
>>>>>> On other systems (x86 and arm) pmem as long as it is page backed does
>>>>>> not require any special handling. This must be some weird way powerpc
>>>>>> fucked up again, and I suspect you'll have to suffer from it.
>>>>>
>>>>>
>>>>> It does not matter if it is backed by pages or not, the problem may also
>>>>> appear if we wanted for example p2p PCI via IOMMU (between PHBs) and
>>>>> MMIO might be mapped way too high in the system address space and make
>>>>> 1:1 impossible.
>>>>
>>>> How can it be mapped too high for a direct mapping with a 64-bit DMA
>>>> mask?
>>>
>>> The window size is limited and often it is not even sparse. It requires
>>> an 8 byte entry per an IOMMU page (which is most commonly is 64k max) so
>>> 1TB limit (a guest RAM size) is a quite real thing. MMIO is mapped to
>>> guest physical address space outside of this 1TB (on PPC).
>>>
>>>
>>
>> I am trying now this approach on top of yours "dma-bypass.3" (it is
>> "wip", needs an upper boundary check):
>>
>> https://github.com/aik/linux/commit/49d73c7771e3f6054804f6cfa80b4e320111662d
>>
>> Do you see any serious problem with this approach? Thanks!
>
> Do you have a link to the whole branch? The github UI is unfortunately
> unusable for that (or I'm missing something).
The UI shows the branch but since I rebased and forcepushed it, it does
not. Here is the current one with:
https://github.com/aik/linux/commits/dma-bypass.3
Thanks,
--
Alexey
^ permalink raw reply
* Re: [PATCH v5 1/2] powerpc/powernv: Remove two unnecessary variable initialisations in opal_add_one_export()
From: Markus Elfring @ 2020-04-06 13:40 UTC (permalink / raw)
To: Qiujun Huang, linuxppc-dev
Cc: linux-kernel, Oliver O'Halloran, Paul Mackerras,
Thomas Gleixner
In-Reply-To: <20200406125242.4973-2-hqjagain@gmail.com>
> And we can remove the redundant assignments to attr and name.
How do you think about a wording like the following?
Two local variables will eventually be set to appropriate pointers
a bit later. Thus omit their explicit initialisation at the beginning.
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v5 2/2] powerpc/powernv: Add NULL check after kzalloc in opal_add_one_export
From: Markus Elfring @ 2020-04-06 14:00 UTC (permalink / raw)
To: Qiujun Huang, linuxppc-dev
Cc: linux-kernel, Oliver O'Halloran, Paul Mackerras,
Thomas Gleixner
In-Reply-To: <20200406125242.4973-3-hqjagain@gmail.com>
> Here needs a NULL check, as kzalloc may fail returning NULL.
>
> Issue was found by coccinelle.
* Do you really try to ignore (my) specific patch review comments
(for a moment)?
https://lore.kernel.org/linuxppc-dev/b7d64d4a-74dd-ee21-db7b-018070f1295f@web.de/
https://lore.kernel.org/patchwork/comment/1414845/
https://lkml.org/lkml/2020/4/6/279
* Would you like to integrate further adjustments with a varying delay?
(Are you waiting on nicer feedback by any software maintainers?)
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v8 1/7] perf expr: Add expr_ prefix for parse_ctx and parse_id
From: Arnaldo Carvalho de Melo @ 2020-04-06 14:13 UTC (permalink / raw)
To: Kajol Jain
Cc: mark.rutland, maddy, peterz, yao.jin, mingo, kan.liang, ak,
alexander.shishkin, anju, mamatha4, sukadev, ravi.bangoria,
jmario, namhyung, tglx, mpetlan, gregkh, linux-kernel,
linux-perf-users, jolsa, linuxppc-dev
In-Reply-To: <20200401203340.31402-2-kjain@linux.ibm.com>
Em Thu, Apr 02, 2020 at 02:03:34AM +0530, Kajol Jain escreveu:
> From: Jiri Olsa <jolsa@kernel.org>
>
> Adding expr_ prefix for parse_ctx and parse_id,
> to straighten out the expr* namespace.
>
> There's no functional change.
Next time please add your Signed-off-by: as well when pushing 3rd party
patches.
Applied.
- Arnaldo
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> tools/perf/tests/expr.c | 4 ++--
> tools/perf/util/expr.c | 10 +++++-----
> tools/perf/util/expr.h | 12 ++++++------
> tools/perf/util/expr.y | 6 +++---
> tools/perf/util/stat-shadow.c | 2 +-
> 5 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
> index 28313e59d6f6..ea10fc4412c4 100644
> --- a/tools/perf/tests/expr.c
> +++ b/tools/perf/tests/expr.c
> @@ -6,7 +6,7 @@
> #include <string.h>
> #include <linux/zalloc.h>
>
> -static int test(struct parse_ctx *ctx, const char *e, double val2)
> +static int test(struct expr_parse_ctx *ctx, const char *e, double val2)
> {
> double val;
>
> @@ -22,7 +22,7 @@ int test__expr(struct test *t __maybe_unused, int subtest __maybe_unused)
> const char **other;
> double val;
> int i, ret;
> - struct parse_ctx ctx;
> + struct expr_parse_ctx ctx;
> int num_other;
>
> expr__ctx_init(&ctx);
> diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
> index fd192ddf93c1..c8ccc548a585 100644
> --- a/tools/perf/util/expr.c
> +++ b/tools/perf/util/expr.c
> @@ -11,7 +11,7 @@ extern int expr_debug;
> #endif
>
> /* Caller must make sure id is allocated */
> -void expr__add_id(struct parse_ctx *ctx, const char *name, double val)
> +void expr__add_id(struct expr_parse_ctx *ctx, const char *name, double val)
> {
> int idx;
>
> @@ -21,13 +21,13 @@ void expr__add_id(struct parse_ctx *ctx, const char *name, double val)
> ctx->ids[idx].val = val;
> }
>
> -void expr__ctx_init(struct parse_ctx *ctx)
> +void expr__ctx_init(struct expr_parse_ctx *ctx)
> {
> ctx->num_ids = 0;
> }
>
> static int
> -__expr__parse(double *val, struct parse_ctx *ctx, const char *expr,
> +__expr__parse(double *val, struct expr_parse_ctx *ctx, const char *expr,
> int start)
> {
> YY_BUFFER_STATE buffer;
> @@ -52,7 +52,7 @@ __expr__parse(double *val, struct parse_ctx *ctx, const char *expr,
> return ret;
> }
>
> -int expr__parse(double *final_val, struct parse_ctx *ctx, const char *expr)
> +int expr__parse(double *final_val, struct expr_parse_ctx *ctx, const char *expr)
> {
> return __expr__parse(final_val, ctx, expr, EXPR_PARSE) ? -1 : 0;
> }
> @@ -75,7 +75,7 @@ int expr__find_other(const char *expr, const char *one, const char ***other,
> int *num_other)
> {
> int err, i = 0, j = 0;
> - struct parse_ctx ctx;
> + struct expr_parse_ctx ctx;
>
> expr__ctx_init(&ctx);
> err = __expr__parse(NULL, &ctx, expr, EXPR_OTHER);
> diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
> index 9377538f4097..b9e53f2b5844 100644
> --- a/tools/perf/util/expr.h
> +++ b/tools/perf/util/expr.h
> @@ -5,19 +5,19 @@
> #define EXPR_MAX_OTHER 20
> #define MAX_PARSE_ID EXPR_MAX_OTHER
>
> -struct parse_id {
> +struct expr_parse_id {
> const char *name;
> double val;
> };
>
> -struct parse_ctx {
> +struct expr_parse_ctx {
> int num_ids;
> - struct parse_id ids[MAX_PARSE_ID];
> + struct expr_parse_id ids[MAX_PARSE_ID];
> };
>
> -void expr__ctx_init(struct parse_ctx *ctx);
> -void expr__add_id(struct parse_ctx *ctx, const char *id, double val);
> -int expr__parse(double *final_val, struct parse_ctx *ctx, const char *expr);
> +void expr__ctx_init(struct expr_parse_ctx *ctx);
> +void expr__add_id(struct expr_parse_ctx *ctx, const char *id, double val);
> +int expr__parse(double *final_val, struct expr_parse_ctx *ctx, const char *expr);
> int expr__find_other(const char *expr, const char *one, const char ***other,
> int *num_other);
>
> diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
> index 4720cbe79357..cd17486c1c5d 100644
> --- a/tools/perf/util/expr.y
> +++ b/tools/perf/util/expr.y
> @@ -15,7 +15,7 @@
> %define api.pure full
>
> %parse-param { double *final_val }
> -%parse-param { struct parse_ctx *ctx }
> +%parse-param { struct expr_parse_ctx *ctx }
> %parse-param {void *scanner}
> %lex-param {void* scanner}
>
> @@ -39,14 +39,14 @@
>
> %{
> static void expr_error(double *final_val __maybe_unused,
> - struct parse_ctx *ctx __maybe_unused,
> + struct expr_parse_ctx *ctx __maybe_unused,
> void *scanner,
> const char *s)
> {
> pr_debug("%s\n", s);
> }
>
> -static int lookup_id(struct parse_ctx *ctx, char *id, double *val)
> +static int lookup_id(struct expr_parse_ctx *ctx, char *id, double *val)
> {
> int i;
>
> diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
> index 0fd713d3674f..402af3e8d287 100644
> --- a/tools/perf/util/stat-shadow.c
> +++ b/tools/perf/util/stat-shadow.c
> @@ -729,7 +729,7 @@ static void generic_metric(struct perf_stat_config *config,
> struct runtime_stat *st)
> {
> print_metric_t print_metric = out->print_metric;
> - struct parse_ctx pctx;
> + struct expr_parse_ctx pctx;
> double ratio, scale;
> int i;
> void *ctxp = out->ctx;
> --
> 2.21.0
>
--
- Arnaldo
^ permalink raw reply
* Re: [PATCH v5 1/2] powerpc/powernv: Return directly after a failed of_property_read_u64_array() in opal_add_one_export()
From: Markus Elfring @ 2020-04-06 14:56 UTC (permalink / raw)
To: Qiujun Huang, linuxppc-dev
Cc: linux-kernel, Oliver O'Halloran, Paul Mackerras,
Thomas Gleixner
In-Reply-To: <20200406125242.4973-2-hqjagain@gmail.com>
> We don't need to go to the labal of out …
Please avoid a typo for this change description.
> fails, as there is nothing to do. Just return.
I suggest to reconsider also this wording.
Return directly after a call of the function “of_property_read_u64_array”
failed at the beginning.
> And we can …
Do such words indicate that even this patch approach should be split
into further update steps?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v3 1/1] powerpc/kernel: Enables memory hot-remove after reboot on pseries guests
From: Leonardo Bras @ 2020-04-06 15:41 UTC (permalink / raw)
To: bharata
Cc: Greg Kroah-Hartman, Claudio Carvalho, linux-kernel,
Paul Mackerras, Allison Randal, Nathan Fontenot, Thomas Gleixner,
linuxppc-dev, Hari Bathini
In-Reply-To: <20200403143831.GA12662@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
Hello Bharata,
On Fri, 2020-04-03 at 20:08 +0530, Bharata B Rao wrote:
> The patch would be more complete with the following change that ensures
> that DRCONF_MEM_HOTREMOVABLE flag is set for non-boot-time hotplugged
> memory too. This will ensure that ibm,dynamic-memory-vN property
> reflects the right flags value for memory that gets hotplugged
> post boot.
>
You just sent that on a separated patchset, so I think it's dealt with.
Do you have any other comments on the present patch?
Best regards,
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2] powerpc/vio: drop bus_type from parent device
From: Thadeu Lima de Souza Cascardo @ 2020-04-06 15:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cascardo
Commit df44b479654f62b478c18ee4d8bc4e9f897a9844 ("kobject: return error
code if writing /sys/.../uevent fails") started returning failure when
writing to /sys/devices/vio/uevent.
This causes an early udevadm trigger to fail. On some installer versions of
Ubuntu, this will cause init to exit, thus panicing the system very early
during boot.
Removing the bus_type from the parent device will remove some of the extra
empty files from /sys/devices/vio/, but will keep the rest of the layout
for vio devices, keeping them under /sys/devices/vio/.
It has been tested that uevents for vio devices don't change after this
fix, they still contain MODALIAS.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Fixes: df44b479654f ("kobject: return error code if writing /sys/.../uevent fails")
---
arch/powerpc/platforms/pseries/vio.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
index 37f1f25ba804..a94dab3972a0 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -36,7 +36,6 @@ static struct vio_dev vio_bus_device = { /* fake "parent" device */
.name = "vio",
.type = "",
.dev.init_name = "vio",
- .dev.bus = &vio_bus_type,
};
#ifdef CONFIG_PPC_SMLPAR
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device
From: Christoph Hellwig @ 2020-04-06 17:17 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Greg Kroah-Hartman, Joerg Roedel, Robin Murphy, linux-kernel,
iommu, Aneesh Kumar K.V, linuxppc-dev, Christoph Hellwig,
Lu Baolu
In-Reply-To: <348046e7-7a38-62d6-4df0-e4a537b98926@ozlabs.ru>
On Mon, Apr 06, 2020 at 11:25:09PM +1000, Alexey Kardashevskiy wrote:
> >> Do you see any serious problem with this approach? Thanks!
> >
> > Do you have a link to the whole branch? The github UI is unfortunately
> > unusable for that (or I'm missing something).
>
> The UI shows the branch but since I rebased and forcepushed it, it does
> not. Here is the current one with:
>
> https://github.com/aik/linux/commits/dma-bypass.3
Ok, so we use the core bypass without persistent memory, and then
have another bypass mode on top. Not great, but I can't think
of anything better. Note that your checks for the map_sg case
aren't very efficient - for one it would make sense to calculate
the limit only once, but also it would make sense to reuse the
calculted diecect mapping addresses instead of doing another pass
later on in the dma-direct code.
^ permalink raw reply
* Re: [PATCH] powerpc/mce: Add MCE notification chain
From: Mahesh J Salgaonkar @ 2020-04-06 17:17 UTC (permalink / raw)
To: Nicholas Piggin
Cc: santosh, linuxppc-dev, mahesh, Ganesh, aneesh.kumar, arbab
In-Reply-To: <1586139348.0tunz2vuxz.astroid@bobo.none>
On 2020-04-06 12:17:22 Mon, Nicholas Piggin wrote:
> Ganesh's on April 4, 2020 11:05 pm:
> > On 4/3/20 7:38 AM, Nicholas Piggin wrote:
> >
> >> Ganesh Goudar's on March 30, 2020 5:12 pm:
> >>> From: Santosh S <santosh@fossix.org>
> >>>
> >>> Introduce notification chain which lets know about uncorrected memory
> >>> errors(UE). This would help prospective users in pmem or nvdimm subsystem
> >>> to track bad blocks for better handling of persistent memory allocations.
> >>>
> >>> Signed-off-by: Santosh S <santosh@fossix.org>
> >>> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
> >> Do you have any such users yet? It would be good to refer to an example
> >> user and give a brief description of what it does in its notifier.
> >
> > Santosh has sent a patch which uses this notification.
> > https://patchwork.ozlabs.org/patch/1265062/
>
> Okay. So these things are asynchronous after the machine check. I guess
> that's the design of it and memory offlining does something similar by
> the looks, but how do you prevent the memory being allocated for
> something else before the notifiers run?
We can't. This race even exists today when we call memory_failure(). If
the same memory is allocated again then we may hit another mce on same
address when touched until the subsystem that has resistered for
notification has completed handling the notified address.
Thanks,
-Mahesh.
>
> >>> @@ -263,6 +277,7 @@ static void machine_process_ue_event(struct work_struct *work)
> >>> while (__this_cpu_read(mce_ue_count) > 0) {
> >>> index = __this_cpu_read(mce_ue_count) - 1;
> >>> evt = this_cpu_ptr(&mce_ue_event_queue[index]);
> >>> + blocking_notifier_call_chain(&mce_notifier_list, 0, evt);
> >> Can we really use a blocking notifier here? I'm not sure that we can.
> >
> > I think we can, do you see any problem?
>
> No it looks okay after better look, sorry for the noise.
>
> Thanks,
> Nick
--
Mahesh J Salgaonkar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox