* [tipc-discussion][net 1/2] tipc: improve function tipc_wait_for_cond()
From: Tung Nguyen @ 2019-02-19 4:20 UTC (permalink / raw)
To: davem, netdev; +Cc: tipc-discussion
In-Reply-To: <20190219042048.23243-1-tung.q.nguyen@dektech.com.au>
Commit 844cf763fba6 ("tipc: make macro tipc_wait_for_cond() smp safe")
replaced finish_wait() with remove_wait_queue() but still used
prepare_to_wait(). This causes unnecessary conditional
checking before adding to wait queue in prepare_to_wait().
This commit replaces prepare_to_wait() with add_wait_queue()
as the pair function with remove_wait_queue().
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
---
net/tipc/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 1217c90a363b..81b87916a0eb 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -388,7 +388,7 @@ static int tipc_sk_sock_err(struct socket *sock, long *timeout)
rc_ = tipc_sk_sock_err((sock_), timeo_); \
if (rc_) \
break; \
- prepare_to_wait(sk_sleep(sk_), &wait_, TASK_INTERRUPTIBLE); \
+ add_wait_queue(sk_sleep(sk_), &wait_); \
release_sock(sk_); \
*(timeo_) = wait_woken(&wait_, TASK_INTERRUPTIBLE, *(timeo_)); \
sched_annotate_sleep(); \
--
2.17.1
^ permalink raw reply related
* [tipc-discussion][net 2/2] tipc: improve function tipc_wait_for_rcvmsg()
From: Tung Nguyen @ 2019-02-19 4:20 UTC (permalink / raw)
To: davem, netdev; +Cc: tipc-discussion
In-Reply-To: <20190219042048.23243-1-tung.q.nguyen@dektech.com.au>
This commit replaces schedule_timeout() with wait_woken()
in function tipc_wait_for_rcvmsg(). wait_woken() uses
memory barriers in its implementation to avoid potential
race condition when putting a process into sleeping state
and then waking it up.
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
---
net/tipc/socket.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 81b87916a0eb..684f2125fc6b 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1677,7 +1677,7 @@ static void tipc_sk_send_ack(struct tipc_sock *tsk)
static int tipc_wait_for_rcvmsg(struct socket *sock, long *timeop)
{
struct sock *sk = sock->sk;
- DEFINE_WAIT(wait);
+ DEFINE_WAIT_FUNC(wait, woken_wake_function);
long timeo = *timeop;
int err = sock_error(sk);
@@ -1685,15 +1685,17 @@ static int tipc_wait_for_rcvmsg(struct socket *sock, long *timeop)
return err;
for (;;) {
- prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
if (timeo && skb_queue_empty(&sk->sk_receive_queue)) {
if (sk->sk_shutdown & RCV_SHUTDOWN) {
err = -ENOTCONN;
break;
}
+ add_wait_queue(sk_sleep(sk), &wait);
release_sock(sk);
- timeo = schedule_timeout(timeo);
+ timeo = wait_woken(&wait, TASK_INTERRUPTIBLE, timeo);
+ sched_annotate_sleep();
lock_sock(sk);
+ remove_wait_queue(sk_sleep(sk), &wait);
}
err = 0;
if (!skb_queue_empty(&sk->sk_receive_queue))
@@ -1709,7 +1711,6 @@ static int tipc_wait_for_rcvmsg(struct socket *sock, long *timeop)
if (err)
break;
}
- finish_wait(sk_sleep(sk), &wait);
*timeop = timeo;
return err;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel
From: Masahiro Yamada @ 2019-02-19 4:14 UTC (permalink / raw)
To: Alexei Starovoitov, Joel Fernandes (Google)
Cc: Networking, Linux Kernel Mailing List, Andrew Morton,
Alexei Starovoitov, atish patra, Daniel Colascione, Dan Williams,
Greg Kroah-Hartman, Jonathan Corbet, Karim Yaghmour, Kees Cook,
kernel-team, open list:DOCUMENTATION,
open list:KERNEL SELFTEST FRAMEWORK, Manoj Rao, Paul McKenney,
Peter Zijlstra (Intel), Randy Dunlap, Steven Rostedt, Shuah Khan,
Thomas Gleixner, Yonghong Song
In-Reply-To: <20190215031926.ljzluy2cfxp64u6o@ast-mbp>
On Fri, Feb 15, 2019 at 11:48 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Mon, Feb 11, 2019 at 09:35:59AM -0500, Joel Fernandes (Google) wrote:
> > Introduce in-kernel headers and other artifacts which are made available
> > as an archive through proc (/proc/kheaders.txz file).
The extension '.txz' is not used in kernel code.
'.tar.xz' is used for 'tarxz-pkg', 'perf-tarxz-src-pkg' etc.
$ git grep '\.txz'
$ git grep '\.tar\.xz'
Documentation/admin-guide/README.rst: xz -cd linux-4.X.tar.xz | tar xvf -
arch/x86/crypto/camellia-aesni-avx-asm_64.S: *
http://koti.mbnet.fi/axh/crypto/camellia-BSD-1.2.0-aesni1.tar.xz
crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
crypto/testmgr.h: * https://bench.cr.yp.to/supercop/supercop-20170228.tar.xz
scripts/package/Makefile: @echo ' perf-tarxz-src-pkg - Build
$(perf-tar).tar.xz source tarball'
tools/testing/selftests/gen_kselftest_tar.sh:
ext=".tar.xz"
I prefer '.tar.xz' for consistency.
BTW, have you ever looked at scripts/extract-ikconfig?
You added IKHD_ST and IKHD_ED
just to mimic kernel/configs.c
It is currently pointless without the extracting tool,
but you might think it is useful to extract headers
from vmlinux or the module without mounting procfs.
> > This archive makes
> > it possible to build kernel modules, run eBPF programs, and other
> > tracing programs that need to extend the kernel for tracing purposes
> > without any dependency on the file system having headers and build
> > artifacts.
> >
> > On Android and embedded systems, it is common to switch kernels but not
> > have kernel headers available on the file system. Raw kernel headers
> > also cannot be copied into the filesystem like they can be on other
> > distros, due to licensing and other issues. There's no linux-headers
> > package on Android. Further once a different kernel is booted, any
> > headers stored on the file system will no longer be useful. By storing
> > the headers as a compressed archive within the kernel, we can avoid these
> > issues that have been a hindrance for a long time.
>
> The set looks good to me and since the main use case is building bpf progs
> I can route it via bpf-next tree if there are no objections.
> Masahiro, could you please ack it?
Honestly, I was not tracking this thread
since I did not know I was responsible for this.
I just started to take a closer look, then immediately got scared.
This version is not mature enough for the merge.
First of all, this patch cannot be compiled out-of-tree (O= option).
I do not know why 0-day bot did not catch this apparent breakage.
$ make -j8 O=hoge
make[1]: Entering directory '/home/masahiro/workspace/bsp/linux/hoge'
GEN Makefile
Using .. as source for kernel
DESCEND objtool
CALL ../scripts/checksyscalls.sh
CHK include/generated/compile.h
make[2]: *** No rule to make target 'Module.symvers', needed by
'kernel/kheaders_data.txz'. Stop.
make[2]: *** Waiting for unfinished jobs....
/home/masahiro/workspace/bsp/linux/Makefile:1043: recipe for target
'kernel' failed
make[1]: *** [kernel] Error 2
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/masahiro/workspace/bsp/linux/hoge'
Makefile:152: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
I was able to compile it in-tree
but it makes the incremental build extremely slow.
(Here, the incremental build means
"make" without changing any code after the full build.)
Before this patch, "make -j8" took 11 sec on my machine.
real 0m11.777s
user 0m16.608s
sys 0m5.164s
After this patch, x86_64_defconfig + CONFIG_IKHEADERS_PROC=y
takes 53 sec for me since kernel/kheaders_data.txz is regenerated
every time even when you did not touch any source file.
$ time make -j8
DESCEND objtool
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
GEN kernel/kheaders_data.txz
UPD kernel/kheaders_data.h
CC kernel/kheaders.o
AR kernel/built-in.a
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
AR init/built-in.a
AR built-in.a
LD vmlinux.o
MODPOST vmlinux.o
KSYM .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.o
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
Building modules, stage 2.
CC arch/x86/boot/version.o
MODPOST 17 modules
VOFFSET arch/x86/boot/compressed/../voffset.h
OBJCOPY arch/x86/boot/compressed/vmlinux.bin
RELOCS arch/x86/boot/compressed/vmlinux.relocs
CC arch/x86/boot/compressed/kaslr.o
GZIP arch/x86/boot/compressed/vmlinux.bin.gz
CC arch/x86/boot/compressed/misc.o
MKPIGGY arch/x86/boot/compressed/piggy.S
AS arch/x86/boot/compressed/piggy.o
LD arch/x86/boot/compressed/vmlinux
ZOFFSET arch/x86/boot/zoffset.h
OBJCOPY arch/x86/boot/vmlinux.bin
AS arch/x86/boot/header.o
LD arch/x86/boot/setup.elf
OBJCOPY arch/x86/boot/setup.bin
BUILD arch/x86/boot/bzImage
Setup is 15612 bytes (padded to 15872 bytes).
System is 12673 kB
CRC 697aaf88
Kernel: arch/x86/boot/bzImage is ready (#6)
real 0m53.024s
user 0m32.076s
sys 0m9.296s
Also, I notice $(ARCH) must be fixed to $(SRCARCH),
but that is one of minor issues.
We should take time for careful review and test.
Please give me more time for thorough review.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Kalle Valo @ 2019-02-19 4:06 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
X86 ML, linux-wireless, Christoph Hellwig, David S. Miller,
Networking, Linux Kernel Mailing List, Lorenzo Bianconi,
moderated list:ARM/Mediatek SoC support, linux-arm-kernel,
Felix Fietkau, Matthias Brugger
In-Reply-To: <CAK7LNAQMgFXw=rtpdPNZ=xpLw-SiwKGAgM__Owvqd1EhTCUntQ@mail.gmail.com>
Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> On Tue, Feb 19, 2019 at 4:38 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Kalle Valo <kvalo@codeaurora.org> writes:
>>
>> > Kalle Valo <kvalo@codeaurora.org> writes:
>> >
>> >> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
>> >>
>> >>> __sw_hweight8() is just internal implementation.
>> >>>
>> >>> Drivers should use the common API, hweight8().
>> >>>
>> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >>
>> >> Acked-by: Kalle Valo <kvalo@codeaurora.org>
>> >>
>> >>> This patch should go to x86 tree along with 2/2.
>> >>>
>> >>> Otherwise, all{yes,mod}config of x86 would be broken.
>> >>>
>> >>> This patch is trivial enough.
>> >>> I want ACK from the net/wireless maintainer
>> >>> so that this can go in via x86 tree.
>> >>
>> >> Sounds good to me, feel free to push via the x86 tree.
>> >
>> > Actually, can you wait a bit? Felix just reminded me that we have a
>> > similar patch pending from Ben Hutchings:
>> >
>> > https://patchwork.kernel.org/patch/10808203/
>> >
>> > And it seems there are two instances of __sw_hweight8, at least in my
>> > wireless-drivers-next tree:
>> >
>> > drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
>> > __sw_hweight8(dev->antenna_mask);
>> > drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
>> > __sw_hweight8(dev->antenna_mask);
>> >
>> > So we need to think what to do.
>>
>> I think the best would be that Felix applies Ben's patch to the wireless
>> tree and I'll push it to Linus during the next merge window (via
>> net-next). Simpler and less conflicts that way.
>>
>> So Masahiro, could you hold your x86 patch for a while until the mt76
>> patch will be in Linus' tree? That should not take more than two weeks,
>> I think.
>
> Sure.
> I will resend 2/2 later.
Great, thanks!
--
Kalle Valo
^ permalink raw reply
* Re: WARNING in xfrm_policy_fini
From: syzbot @ 2019-02-19 3:05 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
In-Reply-To: <000000000000c5745b0573d62311@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: a3b22b9f11d9 Linux 5.0-rc7
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17e3d4d0c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=7132344728e7ec3f
dashboard link: https://syzkaller.appspot.com/bug?extid=9bce6db6c82f06b85d8b
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177317a8c00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9bce6db6c82f06b85d8b@syzkaller.appspotmail.com
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
cgroup: fork rejected by pids controller in /syz3
cgroup: fork rejected by pids controller in /syz2
WARNING: CPU: 1 PID: 31 at net/xfrm/xfrm_policy.c:3871
xfrm_policy_fini+0x30c/0x3a0 net/xfrm/xfrm_policy.c:3871
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 31 Comm: kworker/u4:2 Not tainted 5.0.0-rc7 #77
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
panic+0x2cb/0x65c kernel/panic.c:214
__warn.cold+0x20/0x45 kernel/panic.c:571
report_bug+0x263/0x2b0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
fixup_bug arch/x86/kernel/traps.c:173 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
kobject: 'loop1' (00000000fd200829): kobject_uevent_env
RIP: 0010:xfrm_policy_fini+0x30c/0x3a0 net/xfrm/xfrm_policy.c:3871
Code: c3 e8 b8 e9 72 fb 0f 0b e9 49 fe ff ff e8 ac e9 72 fb 0f 0b e9 cd fd
ff ff e8 a0 e9 72 fb 0f 0b e9 00 ff ff ff e8 94 e9 72 fb <0f> 0b e9 62 fd
ff ff e8 98 e8 a9 fb e9 7d fe ff ff 4c 89 ff e8 ab
kobject: 'loop1' (00000000fd200829): fill_kobj_path: path
= '/devices/virtual/block/loop1'
RSP: 0018:ffff8880a9a8fbb0 EFLAGS: 00010293
RAX: ffff8880a9a82100 RBX: ffff88808e30dbf0 RCX: 1ffff1101535053e
RDX: 0000000000000000 RSI: ffffffff85fcf7ec RDI: ffff8880a9a8297c
RBP: ffff8880a9a8fbf0 R08: ffff8880a9a82100 R09: ffff8880a9a829f0
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88808e30c080
R13: ffff8880a9a8fcc8 R14: ffffffff893d5eb8 R15: dffffc0000000000
xfrm_net_exit+0x1d/0x70 net/xfrm/xfrm_policy.c:3931
ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
cleanup_net+0x3fb/0x960 net/core/net_namespace.c:551
kobject: 'loop1' (00000000fd200829): kobject_uevent_env
kobject: 'loop1' (00000000fd200829): fill_kobj_path: path
= '/devices/virtual/block/loop1'
cgroup: fork rejected by pids controller in /syz1
process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
worker_thread+0x98/0xe40 kernel/workqueue.c:2319
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [PATCH] can: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-02-19 2:57 UTC (permalink / raw)
To: Nicolas.Ferre, wg, mkl, davem, alexandre.belloni,
Ludovic.Desroches
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel, Kees Cook
In-Reply-To: <daae008e-35fd-7553-fcb2-7932fe53b959@embeddedor.com>
Hi,
Friendly ping:
Dave, I wonder if you can take this.
Thanks
--
Gustavo
On 2/14/19 3:37 PM, Gustavo A. R. Silva wrote:
>
>
> On 1/30/19 2:11 AM, Nicolas.Ferre@microchip.com wrote:
>> On 29/01/2019 at 19:06, Gustavo A. R. Silva wrote:
>>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>>> where we are expecting to fall through.
>>>
>>> This patch fixes the following warnings:
>>>
>>> drivers/net/can/peak_canfd/peak_pciefd_main.c:668:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> drivers/net/can/spi/mcp251x.c:875:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> drivers/net/can/usb/peak_usb/pcan_usb.c:422:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> drivers/net/can/at91_can.c:895:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> drivers/net/can/at91_can.c:953:15: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> drivers/net/can/usb/peak_usb/pcan_usb.c: In function ‘pcan_usb_decode_error’:
>>> drivers/net/can/usb/peak_usb/pcan_usb.c:422:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>> if (n & PCAN_USB_ERROR_BUS_LIGHT) {
>>> ^
>>> drivers/net/can/usb/peak_usb/pcan_usb.c:428:2: note: here
>>> case CAN_STATE_ERROR_WARNING:
>>> ^~~~
>>>
>>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>>
>>> This patch is part of the ongoing efforts to enabling
>>> -Wimplicit-fallthrough.
>>>
>>> Notice that in some cases spelling mistakes were fixed.
>>> In other cases, the /* fall through */ comment is placed
>>> at the bottom of the case statement, which is what GCC
>>> is expecting to find.
>>>
>>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>>> ---
>>> drivers/net/can/at91_can.c | 6 ++++--
>>
>> For this one:
>> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
>>
>
> Thanks, Nicolas.
>
> Dave:
>
> I wonder if you can take this patch.
>
> Thanks
> --
> Gustavo
>
>>> drivers/net/can/peak_canfd/peak_pciefd_main.c | 2 +-
>>> drivers/net/can/spi/mcp251x.c | 3 ++-
>>> drivers/net/can/usb/peak_usb/pcan_usb.c | 2 +-
>>> 4 files changed, 8 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
>>> index d98c69045b17..1718c20f9c99 100644
>>> --- a/drivers/net/can/at91_can.c
>>> +++ b/drivers/net/can/at91_can.c
>>> @@ -902,7 +902,8 @@ static void at91_irq_err_state(struct net_device *dev,
>>> CAN_ERR_CRTL_TX_WARNING :
>>> CAN_ERR_CRTL_RX_WARNING;
>>> }
>>> - case CAN_STATE_ERROR_WARNING: /* fallthrough */
>>> + /* fall through */
>>> + case CAN_STATE_ERROR_WARNING:
>>> /*
>>> * from: ERROR_ACTIVE, ERROR_WARNING
>>> * to : ERROR_PASSIVE, BUS_OFF
>>> @@ -951,7 +952,8 @@ static void at91_irq_err_state(struct net_device *dev,
>>> netdev_dbg(dev, "Error Active\n");
>>> cf->can_id |= CAN_ERR_PROT;
>>> cf->data[2] = CAN_ERR_PROT_ACTIVE;
>>> - case CAN_STATE_ERROR_WARNING: /* fallthrough */
>>> + /* fall through */
>>> + case CAN_STATE_ERROR_WARNING:
>>> reg_idr = AT91_IRQ_ERRA | AT91_IRQ_WARN | AT91_IRQ_BOFF;
>>> reg_ier = AT91_IRQ_ERRP;
>>> break;
>>> diff --git a/drivers/net/can/peak_canfd/peak_pciefd_main.c b/drivers/net/can/peak_canfd/peak_pciefd_main.c
>>> index c458d5fdc8d3..e4f4d65a76b4 100644
>>> --- a/drivers/net/can/peak_canfd/peak_pciefd_main.c
>>> +++ b/drivers/net/can/peak_canfd/peak_pciefd_main.c
>>> @@ -668,7 +668,7 @@ static int pciefd_can_probe(struct pciefd_board *pciefd)
>>> pciefd_can_writereg(priv, CANFD_CLK_SEL_80MHZ,
>>> PCIEFD_REG_CAN_CLK_SEL);
>>>
>>> - /* fallthough */
>>> + /* fall through */
>>> case CANFD_CLK_SEL_80MHZ:
>>> priv->ucan.can.clock.freq = 80 * 1000 * 1000;
>>> break;
>>> diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
>>> index e90817608645..17257c73c302 100644
>>> --- a/drivers/net/can/spi/mcp251x.c
>>> +++ b/drivers/net/can/spi/mcp251x.c
>>> @@ -875,7 +875,8 @@ static irqreturn_t mcp251x_can_ist(int irq, void *dev_id)
>>> if (new_state >= CAN_STATE_ERROR_WARNING &&
>>> new_state <= CAN_STATE_BUS_OFF)
>>> priv->can.can_stats.error_warning++;
>>> - case CAN_STATE_ERROR_WARNING: /* fallthrough */
>>> + /* fall through */
>>> + case CAN_STATE_ERROR_WARNING:
>>> if (new_state >= CAN_STATE_ERROR_PASSIVE &&
>>> new_state <= CAN_STATE_BUS_OFF)
>>> priv->can.can_stats.error_passive++;
>>> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb.c b/drivers/net/can/usb/peak_usb/pcan_usb.c
>>> index 13238a72a338..eca785532b6b 100644
>>> --- a/drivers/net/can/usb/peak_usb/pcan_usb.c
>>> +++ b/drivers/net/can/usb/peak_usb/pcan_usb.c
>>> @@ -423,7 +423,7 @@ static int pcan_usb_decode_error(struct pcan_usb_msg_context *mc, u8 n,
>>> new_state = CAN_STATE_ERROR_WARNING;
>>> break;
>>> }
>>> - /* else: fall through */
>>> + /* fall through */
>>>
>>> case CAN_STATE_ERROR_WARNING:
>>> if (n & PCAN_USB_ERROR_BUS_HEAVY) {
>>>
>>
>>
^ permalink raw reply
* Re: [PATCH net-next] yellowfin: fix remove set but not used variable warning
From: YueHaibing @ 2019-02-19 2:34 UTC (permalink / raw)
To: David Miller; +Cc: yang.wei9, netdev, kernel-janitors
In-Reply-To: <20190218.121337.147896114474592034.davem@davemloft.net>
On 2019/2/19 4:13, David Miller wrote:
> From: YueHaibing <yuehaibing@huawei.com>
> Date: Mon, 18 Feb 2019 08:15:46 +0000
>
>> @@ -1050,8 +1050,11 @@ static int yellowfin_rx(struct net_device *dev)
>> struct sk_buff *rx_skb = yp->rx_skbuff[entry];
>> s16 frame_status;
>> u16 desc_status;
>> - int data_size, yf_size;
>> + int data_size;
>> u8 *buf_addr;
>> +#ifdef YF_PROTOTYPE
>> + int yf_size = sizeof(struct yellowfin_desc);
>> +#endif
>
> This is just silly.
>
> Please move this variable declaration and initialization into the
> YF_PROTOTYPE basic block in the code below it, like this:
>
> #ifdef YF_PROTOTYPE /* Support for prototype hardware errata. */
> } else if ((yp->flags & HasMACAddrBug) &&
> int yf_size = sizeof(struct yellowfin_desc);
There's just in if condition, define the 'yf_size' seems incorrect
maybe we can remove 'yf_size' and use sizeof directly?
>
> !ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
> entry * yf_size),
> dev->dev_addr) &&
> !ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
> entry * yf_size),
> "\377\377\377\377\377\377")) {
> if (bogus_rx++ == 0)
> netdev_warn(dev, "Bad frame to %pM\n",
> buf_addr);
> #endif
>
> Thanks.
>
> .
>
^ permalink raw reply
* [PATCH][net-next] bridge: remove redundant check on err in br_multicast_ipv4_rcv
From: Li RongQing @ 2019-02-19 2:17 UTC (permalink / raw)
To: netdev
br_ip4_multicast_mrd_rcv only return 0 and -ENOMSG,
no other negative value
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/bridge/br_multicast.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 4a048fd1cbea..fe9f2d8ca2c1 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1615,12 +1615,7 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
if (ip_hdr(skb)->protocol == IPPROTO_PIM)
br_multicast_pim(br, port, skb);
} else if (ipv4_is_all_snoopers(ip_hdr(skb)->daddr)) {
- err = br_ip4_multicast_mrd_rcv(br, port, skb);
-
- if (err < 0 && err != -ENOMSG) {
- br_multicast_err_count(br, port, skb->protocol);
- return err;
- }
+ br_ip4_multicast_mrd_rcv(br, port, skb);
}
return 0;
--
2.16.2
^ permalink raw reply related
* [PATCH] net: remove unneeded switch fall-through
From: Li RongQing @ 2019-02-19 2:15 UTC (permalink / raw)
To: netdev
This case block has been terminated by a return, so not need
a switch fall-through
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/ipv4/igmp.c | 1 -
net/ipv6/mcast_snoop.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index b448cf32296c..6c2febc39dca 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1541,7 +1541,6 @@ static int ip_mc_check_igmp_msg(struct sk_buff *skb)
case IGMP_HOST_LEAVE_MESSAGE:
case IGMP_HOST_MEMBERSHIP_REPORT:
case IGMPV2_HOST_MEMBERSHIP_REPORT:
- /* fall through */
return 0;
case IGMPV3_HOST_MEMBERSHIP_REPORT:
return ip_mc_check_igmp_reportv3(skb);
diff --git a/net/ipv6/mcast_snoop.c b/net/ipv6/mcast_snoop.c
index 55e2ac179f28..dddd75d1be0e 100644
--- a/net/ipv6/mcast_snoop.c
+++ b/net/ipv6/mcast_snoop.c
@@ -128,7 +128,6 @@ static int ipv6_mc_check_mld_msg(struct sk_buff *skb)
switch (mld->mld_type) {
case ICMPV6_MGM_REDUCTION:
case ICMPV6_MGM_REPORT:
- /* fall through */
return 0;
case ICMPV6_MLD2_REPORT:
return ipv6_mc_check_mld_reportv2(skb);
--
2.16.2
^ permalink raw reply related
* Re: [PATCH 0/2] Netfilter/IPVS fixes for net
From: David Miller @ 2019-02-19 1:56 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190218230823.8114-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Tue, 19 Feb 2019 00:08:21 +0100
> The following patchset contains Netfilter/IPVS fixes for net:
>
> 1) Follow up patch to fix a compilation warning in a recent IPVS fix:
> 098e13f5b21d ("ipvs: fix dependency on nf_defrag_ipv6").
>
> 2) Bogus ENOENT error on flush after rule deletion in the same batch,
> reported by Phil Sutter.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net v4.15..v4.19] net: dsa: Fix NPD checking for br_vlan_enabled()
From: David Miller @ 2019-02-19 1:54 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, frank-w, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20190218223011.4824-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 18 Feb 2019 14:30:11 -0800
> It is possible for the DSA slave network device not to be part of a
> bridge, yet have an upper device like a VLAN device be part of a bridge.
> When that VLAN device is enslaved, since it does not define any
> switchdev_ops, we will recurse down to the lower/physical port device,
> call switchdev_port_obj_add() with a VLAN, and here we will check
> br_vlan_enabled() on a NULL dp->bridge_dev, thus causing a NULL pointer
> de-reference.
>
> This is no longer a problem upstream after commit d17d9f5e5143
> ("switchdev: Replace port obj add/del SDO with a notification").
>
> Fixes: 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is disabled")
> Reported-by: Frank Wunderlich <frank-w@public-files.de>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> David,
>
> This affects v4.15..v4.19, but not v5.0-rc1 can you still queue this up
> for -stable? Thanks!
Queued up.
^ permalink raw reply
* Re: [PATCH v2] bonding: fix PACKET_ORIGDEV regression
From: David Ahern @ 2019-02-19 1:51 UTC (permalink / raw)
To: Michal Soltys, David Miller
Cc: Maciej Żenczykowski, Jay Vosburgh, Vincent Bernat,
Mahesh Bandewar, Chonggang Li, Linux NetDev
In-Reply-To: <20190218165528.15575-1-soltys@ziu.info>
On 2/18/19 9:55 AM, Michal Soltys wrote:
> This patch fixes a subtle PACKET_ORIGDEV regression which was a side
> effect of fixes introduced by:
>
> 6a9e461f6fe4 bonding: pass link-local packets to bonding master also.
>
> ... to:
>
> b89f04c61efe bonding: deliver link-local packets with skb->dev set to link that packets arrived on
>
> While 6a9e461f6fe4 restored pre-b89f04c61efe presence of link-local
> packets on bonding masters (which is required e.g. by linux bridges
> participating in spanning tree or needed for lab-like setups created
> with group_fwd_mask) it also caused the originating device
> information to be lost due to cloning.
>
> Maciej Żenczykowski proposed another solution that doesn't require
> packet cloning and retains original device information - instead of
> returning RX_HANDLER_PASS for all link-local packets it's now limited
> only to packets from inactive slaves.
>
> At the same time, packets passed to bonding masters retain correct
> information about the originating device and PACKET_ORIGDEV can be used
> to determine it.
>
> This elegantly solves all issues so far:
>
> - link-local packets that were removed from bonding masters
> - LLDP daemons being forced to explicitly bind to slave interfaces
> - PACKET_ORIGDEV having no effect on bond interfaces
>
> Fixes: 6a9e461f6fe4 (bonding: pass link-local packets to bonding master also.)
> Reported-by: Vincent Bernat <vincent@bernat.ch>
> Signed-off-by: Michal Soltys <soltys@ziu.info>
> ---
> drivers/net/bonding/bond_main.c | 35 +++++++++++++--------------------
> 1 file changed, 14 insertions(+), 21 deletions(-)
>
Hi Michal:
Can you add test cases that shows the expectations of this API? Given
the back and forth on the last set of patches -- and the impacts to
lldpd users for example -- we really need test cases added to selftests.
^ permalink raw reply
* Re: [PATCH] net: netcp: Fix ethss driver probe issue
From: David Miller @ 2019-02-19 1:50 UTC (permalink / raw)
To: m-karicheri2; +Cc: w-kwok2, netdev, linux-kernel
In-Reply-To: <20190218201051.19623-1-m-karicheri2@ti.com>
From: Murali Karicheri <m-karicheri2@ti.com>
Date: Mon, 18 Feb 2019 15:10:51 -0500
> Recent commit below has introduced a bug in netcp driver that causes
> the ethss driver probe failure and thus break the networking function
> on K2 SoCs such as K2HK, K2L, K2E etc. This patch fixes the issue to
> restore networking on the above SoCs.
>
> Fixes: 21c328dcecfc ("net: ethernet: Convert to using %pOFn instead of device_node.name")
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] net: hns: Fixes the missing put_device in positive leg for roce reset
From: David Miller @ 2019-02-19 1:45 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linux-rdma, linuxarm
In-Reply-To: <20190218174032.22972-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Mon, 18 Feb 2019 17:40:32 +0000
> This patch fixes the missing device reference release-after-use in
> the positive leg of the roce reset API of the HNS DSAF.
>
> Fixes: c969c6e7ab8c ("net: hns: Fix object reference leaks in hns_dsaf_roce_reset()")
> Reported-by: John Garry <john.garry@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Applied, thanks Salil.
^ permalink raw reply
* Re: pull-request: wireless-drivers 2019-02-18
From: David Miller @ 2019-02-19 1:41 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87zhqtt98h.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 18 Feb 2019 17:19:26 +0200
> here's one more pull request to net tree for 5.0. Please let me know if
> you have any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH net] net: stmmac: Fix a race in EEE enable callback
From: David Miller @ 2019-02-19 1:40 UTC (permalink / raw)
To: jose.abreu
Cc: netdev, linux-kernel, joao.pinto, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <fb866bb5dd8a11326fab8e6d393f2a37eed5073f.1550496861.git.joabreu@synopsys.com>
From: Jose Abreu <jose.abreu@synopsys.com>
Date: Mon, 18 Feb 2019 14:35:03 +0100
> We are saving the status of EEE even before we try to enable it. This
> leads to a race with XMIT function that tries to arm EEE timer before we
> set it up.
>
> Fix this by only saving the EEE parameters after all operations are
> performed with success.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Fixes: d765955d2ae0 ("stmmac: add the Energy Efficient Ethernet support")
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH][unix] missing barriers in some of unix_sock ->addr and ->path accesses
From: Sasha Levin @ 2019-02-19 1:30 UTC (permalink / raw)
To: Al Viro; +Cc: netdev, David Miller, stable, stable
In-Reply-To: <20190218213246.GV2217@ZenIV.linux.org.uk>
On Mon, Feb 18, 2019 at 09:32:46PM +0000, Al Viro wrote:
>On Mon, Feb 18, 2019 at 09:14:33PM +0000, Sasha Levin wrote:
>> Hi,
>>
>> [This is an automated email]
>>
>> This commit has been processed because it contains a -stable tag.
>
>Ugh... Should've removed Cc; stable from netdev posting; my apologies.
>
>> How should we proceed with this patch?
>
>Wait for it to get into davem's tree, for starters?
It won't go in stable until it's upstream, the only reason for this
early mail is that it's easier to get responses from people while the
patch is still fresh in their brains (as you might have noticed ;) )
rather than in a few weeks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] NETWORKING: avoid use IPCB in cipso_v4_error
From: David Miller @ 2019-02-19 1:25 UTC (permalink / raw)
To: s-nazarov; +Cc: paul, netdev, linux-security-module, kuznet, yoshfuji
In-Reply-To: <1122331550497151@iva7-d29a8296bc3c.qloud-c.yandex.net>
From: Nazarov Sergey <s-nazarov@yandex.ru>
Date: Mon, 18 Feb 2019 16:39:11 +0300
> I think, it would not be a good solution, if I will analyze all
> subsystems using icmp_send, because I do not have enough knowledge
> for this. I propose to add a new function, for example,
> ismp_send_safe, something like that:
Please don't do this.
Solve the problem properly by auditing each case, there aren't a lot and
it is not too difficult to see the upcall sites.
^ permalink raw reply
* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Masahiro Yamada @ 2019-02-19 1:13 UTC (permalink / raw)
To: Kalle Valo
Cc: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
X86 ML, linux-wireless, Christoph Hellwig, David S. Miller,
Networking, Linux Kernel Mailing List, Lorenzo Bianconi,
moderated list:ARM/Mediatek SoC support, linux-arm-kernel,
Felix Fietkau, Matthias Brugger
In-Reply-To: <87pnrosy29.fsf@kamboji.qca.qualcomm.com>
On Tue, Feb 19, 2019 at 4:38 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Kalle Valo <kvalo@codeaurora.org> writes:
>
> > Kalle Valo <kvalo@codeaurora.org> writes:
> >
> >> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> >>
> >>> __sw_hweight8() is just internal implementation.
> >>>
> >>> Drivers should use the common API, hweight8().
> >>>
> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >>
> >> Acked-by: Kalle Valo <kvalo@codeaurora.org>
> >>
> >>> This patch should go to x86 tree along with 2/2.
> >>>
> >>> Otherwise, all{yes,mod}config of x86 would be broken.
> >>>
> >>> This patch is trivial enough.
> >>> I want ACK from the net/wireless maintainer
> >>> so that this can go in via x86 tree.
> >>
> >> Sounds good to me, feel free to push via the x86 tree.
> >
> > Actually, can you wait a bit? Felix just reminded me that we have a
> > similar patch pending from Ben Hutchings:
> >
> > https://patchwork.kernel.org/patch/10808203/
> >
> > And it seems there are two instances of __sw_hweight8, at least in my
> > wireless-drivers-next tree:
> >
> > drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
> > __sw_hweight8(dev->antenna_mask);
> > drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
> > __sw_hweight8(dev->antenna_mask);
> >
> > So we need to think what to do.
>
> I think the best would be that Felix applies Ben's patch to the wireless
> tree and I'll push it to Linus during the next merge window (via
> net-next). Simpler and less conflicts that way.
>
> So Masahiro, could you hold your x86 patch for a while until the mt76
> patch will be in Linus' tree? That should not take more than two weeks,
> I think.
Sure.
I will resend 2/2 later.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH net 0/2] qed: iWARP - fix some syn related issues.
From: David Miller @ 2019-02-19 0:52 UTC (permalink / raw)
To: michal.kalderon; +Cc: ariel.elior, netdev, linux-rdma
In-Reply-To: <20190218132403.12487-1-michal.kalderon@marvell.com>
From: Michal Kalderon <michal.kalderon@marvell.com>
Date: Mon, 18 Feb 2019 15:24:01 +0200
> This series fixes two bugs related to iWARP syn processing flow.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Remove set but not used variable 'mfw_vn'
From: David Miller @ 2019-02-19 0:48 UTC (permalink / raw)
To: yuehaibing; +Cc: aelior, skalluru, GR-everest-linux-l2, netdev, kernel-janitors
In-Reply-To: <20190218121954.78928-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 18 Feb 2019 12:19:54 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function 'bnx2x_get_hwinfo':
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:11940:10: warning:
> variable 'mfw_vn' set but not used [-Wunused-but-set-variable]
>
> It's never used since introduction.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net: phy: add helpers for handling C45 10GBT AN register values
From: David Miller @ 2019-02-19 0:44 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <c6be00e5-d4e5-69a1-cb9c-31cd446556be@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 16 Feb 2019 17:24:58 +0100
> Similar to the existing helpers for the Clause 22 registers add helpers
> to deal with converting Clause 45 advertisement registers to / from
> link mode bitmaps.
>
> Note that these helpers are defined in linux/mdio.h, not like the
> Clause 22 helpers in linux/mii.h. Reason is that the Clause 45 register
> constants are defined in uapi/linux/mdio.h. And uapi/linux/mdio.h
> includes linux/mii.h before defining the C45 register constants.
>
> v2:
> - Remove few helpers which aren't used by this series. They will
> follow together with the users.
Series applied with fuzz on patch #1 :-)))))
^ permalink raw reply
* Re: [PATCH net-next] liquidio: using NULL instead of plain integer
From: David Miller @ 2019-02-19 0:42 UTC (permalink / raw)
To: yuehaibing; +Cc: dchickles, sburla, fmanlunas, linux-kernel, netdev
In-Reply-To: <20190216095310.22544-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Sat, 16 Feb 2019 17:53:10 +0800
> Fix following warning:
>
> drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c:1453:35: warning: Using plain integer as NULL pointer
> drivers/net/ethernet/cavium/liquidio/lio_main.c:2910:23: warning: Using plain integer as NULL pointer
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: remove unneeded mmiowb barriers
From: David Miller @ 2019-02-19 0:39 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <10883db9-493c-7434-2379-de79712cee85@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 16 Feb 2019 10:20:15 +0100
> writex() has implicit barriers, that's what makes it different from
> writex_relaxed(). Therefore these calls to mmiowb() can be removed.
>
> This patch was recently reverted due to a dependency with another
> problematic patch. But because it didn't contribute to the problem
> it was rebased and can be resubmitted.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] r8152: Add support for MAC address pass through on RTL8153-BD
From: David Miller @ 2019-02-19 0:38 UTC (permalink / raw)
To: david0813
Cc: linux-usb, netdev, linux-kernel, hayeswang, mario.limonciello,
bigeasy, edumazet, jslaby, f.fainelli, david.chen7, kai.heng.feng,
zhongjiang
In-Reply-To: <20190216091642.21388-1-david0813@gmail.com>
From: David Chen <david0813@gmail.com>
Date: Sat, 16 Feb 2019 17:16:42 +0800
> From: David Chen <david.chen7@dell.com>
>
> RTL8153-BD is used in Dell DA300 type-C dongle.
> It should be added to the whitelist of devices to activate MAC address
> pass through.
>
> Per confirming with Realtek all devices containing RTL8153-BD should
> activate MAC pass through and there won't use pass through bit on efuse
> like in RTL8153-AD.
>
> Signed-off-by: David Chen <david.chen7@dell.com>
Applied, thanks.
^ 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