* Re: dvb usb issues since kernel 4.9
From: Linus Torvalds @ 2018-01-09 17:55 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Peter Zijlstra, Alan Stern, Ingo Molnar, Josef Griebichler,
Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel,
Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer,
linux-kernel, netdev, Jonathan Corbet, LMML, David Miller
In-Reply-To: <20180109154235.2a42f0a0@vento.lan>
On Tue, Jan 9, 2018 at 9:42 AM, Mauro Carvalho Chehab
<mchehab@s-opensource.com> wrote:
>
> On my preliminar tests, writing to a file on an ext4 partition at a
> USB stick loses data up to the point to make it useless (1/4 of the data
> is lost!). However, writing to a class 10 microSD card is doable.
Note that most USB sticks are horrible crap. They can have write
latencies counted in _seconds_.
You can cause VM issues and various other non-hardware stalls with
them, simply because something gets stuck waiting for a page writeout
that should take a few ms on any reasonable hardware, but ends up
talking half a second or more.
For example, even really well-written software that tries to do things
like threaded write-behind to smooth out the IO will be _totally_
screwed by the USB stick behavior (where you might write a few MB at
high speeds, and then the next write - however small - takes a second
because the stupid USB stick does a synchronous garbage collection.
Suddenly all that clever software that tried to keep things moving
along smoothly without any hiccups, and tried hard to make the USB bus
have a nice constant loadm can't do anything at all about the crap
hardware.
So when testing writes to USB sticks, I'm not convinced you're
actually testing any USB bus limitations or even really any other
hardware limitations than the USB stick itself.
Linus
^ permalink raw reply
* Re: Re: dvb usb issues since kernel 4.9
From: Eric Dumazet @ 2018-01-09 17:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra,
Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, USB list,
Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel,
netdev, Jonathan Corbet, LMML, David Miller
In-Reply-To: <CA+55aFzcoNEpnRp0R3fLYQKdfzS5mLj3z_v=1A1NfyrybQ__4A@mail.gmail.com>
On Tue, Jan 9, 2018 at 9:48 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet <edumazet@google.com> wrote:
>>
>> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has
>> shown up multiple times in various 'regressions'
>> simply because it could surface the problem more often.
>> But even if you revert it, you can still make the faulty
>> driver/subsystem misbehave by adding more stress to the cpu handling
>> the IRQ.
>
> ..but that's always true. People sometimes live on the edge - often by
> design (ie hardware has been designed/selected to be the crappiest
> possible that still work).
>
> That doesn't change anything. A patch that takes "bad things can
> happen" to "bad things DO happen" is a bad patch.
I was expecting that people could get a chance to fix the root cause,
instead of trying to keep status quo.
Strangely, it took 18 months for someone to complain enough and
'bisect to this commit'
Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate
handling', but TCP Small queues heavily use TASKLET,
so as far as I am concerned a revert would have the same effect.
^ permalink raw reply
* tipc: memory leak in tipc_nl_node_get_link
From: Dmitry Vyukov @ 2018-01-09 18:01 UTC (permalink / raw)
To: Jon Maloy, Ying Xue, David Miller, netdev, tipc-discussion, LKML,
syzkaller
Hello,
syzkaller has hit the following memory leak on 4.15-rc7.
It seems that tipc_nl_node_get_link() fails to free the skb when
tipc_node_find_by_name() fails.
5:58:28 KMEMLEAK READ1 1071
[ 386.810943] kmemleak: 2 new suspected memory leaks, 0 unleaked (see
/sys/kernel/debug/kmemleak)
2018/01/09 15:58:31 KMEMLEAK READ2 2225
2018/01/09 15:58:31 BUG: memory leak
eferenced object 0xffff88002a782280 (size 232):
comm "syz-executor2", pid 6844, jiffies 4295044059 (age 10.220s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000c914c2d7>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000c914c2d7>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000c914c2d7>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000c914c2d7>] kmem_cache_alloc_node+0x12d/0x2a0 mm/slub.c:2761
[<000000007ed8c8b5>] __alloc_skb+0x103/0x7c0 net/core/skbuff.c:193
[<0000000023449dd8>] nlmsg_new include/linux/skbuff.h:983 [inline]
[<0000000023449dd8>] tipc_nl_node_get_link+0x1d4/0x6b0 net/tipc/node.c:1877
[<0000000019b652e1>] genl_family_rcv_msg+0x881/0x1110
net/netlink/genetlink.c:599
[<000000009c0a85f1>] genl_rcv_msg+0xc6/0x170 net/netlink/genetlink.c:624
[<00000000052c4d51>] netlink_rcv_skb+0x275/0x550
net/netlink/af_netlink.c:2408
[<00000000d5ae339c>] genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
[<000000004cb4e55b>] netlink_unicast_kernel
net/netlink/af_netlink.c:1275 [inline]
[<000000004cb4e55b>] netlink_unicast+0x567/0x710
net/netlink/af_netlink.c:1301
[<00000000bc52e4f5>] netlink_sendmsg+0x9c4/0xf60
net/netlink/af_netlink.c:1864
[<00000000cc6816f5>] sock_sendmsg_nosec net/socket.c:636 [inline]
[<00000000cc6816f5>] sock_sendmsg+0xd2/0x120 net/socket.c:646
[<00000000db8490cd>] ___sys_sendmsg+0x7f6/0x930 net/socket.c:2026
[<0000000097919974>] __sys_sendmsg+0xe6/0x220 net/socket.c:2060
[<000000000334a861>] SYSC_sendmsg net/socket.c:2071 [inline]
[<000000000334a861>] SyS_sendmsg+0x36/0x60 net/socket.c:2067
[<0000000008a3e08e>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<0000000094cce38d>] 0xffffffffffffffff
2018/01/09 15:58:31 BUG: memory leak
unreferenced object 0xffff880017894200 (size 8192):
comm "syz-executor2", pid 6844, jiffies 4295044059 (age 10.233s)
hex dump (first 32 bytes):
00 21 89 17 00 88 ff ff 00 00 00 00 00 00 00 00 .!..............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000b0c26949>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000b0c26949>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000b0c26949>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000b0c26949>] __kmalloc_node_track_caller+0x19f/0x360 mm/slub.c:4320
[<0000000061c65883>] __kmalloc_reserve.isra.39+0x3a/0xe0
net/core/skbuff.c:137
[<00000000dba6a120>] __alloc_skb+0x144/0x7c0 net/core/skbuff.c:205
[<0000000023449dd8>] nlmsg_new include/linux/skbuff.h:983 [inline]
[<0000000023449dd8>] tipc_nl_node_get_link+0x1d4/0x6b0 net/tipc/node.c:1877
[<0000000019b652e1>] genl_family_rcv_msg+0x881/0x1110
net/netlink/genetlink.c:599
[<000000009c0a85f1>] genl_rcv_msg+0xc6/0x170 net/netlink/genetlink.c:624
[<00000000052c4d51>] netlink_rcv_skb+0x275/0x550
net/netlink/af_netlink.c:2408
[<00000000d5ae339c>] genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
[<000000004cb4e55b>] netlink_unicast_kernel
net/netlink/af_netlink.c:1275 [inline]
[<000000004cb4e55b>] netlink_unicast+0x567/0x710
net/netlink/af_netlink.c:1301
[<00000000bc52e4f5>] netlink_sendmsg+0x9c4/0xf60
net/netlink/af_netlink.c:1864
[<00000000cc6816f5>] sock_sendmsg_nosec net/socket.c:636 [inline]
[<00000000cc6816f5>] sock_sendmsg+0xd2/0x120 net/socket.c:646
[<00000000db8490cd>] ___sys_sendmsg+0x7f6/0x930 net/socket.c:2026
[<0000000097919974>] __sys_sendmsg+0xe6/0x220 net/socket.c:2060
[<000000000334a861>] SYSC_sendmsg net/socket.c:2071 [inline]
[<000000000334a861>] SyS_sendmsg+0x36/0x60 net/socket.c:2067
[<0000000008a3e08e>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<0000000094cce38d>] 0xffffffffffffffff
^ permalink raw reply
* Re: [PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution
From: Dan Williams @ 2018-01-09 18:01 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linux Kernel Mailing List, linux-arch, Peter Zijlstra, Netdev,
Greg KH, Thomas Gleixner, Linus Torvalds, David S. Miller,
Elena Reshetova, Alan Cox
In-Reply-To: <87373fj9bv.fsf@xmission.com>
On Tue, Jan 9, 2018 at 8:17 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Dan Williams <dan.j.williams@intel.com> writes:
[..]
> The user controlled value condition of your patchset implies that you
> assume indirect branch predictor poisoning is handled in other ways.
>
> Which means that we can assume speculation will take some variation of
> the static call chain.
>
> Further you are worrying about array accesses. Which means you
> are worried about attacks that are the equivalent of meltdown that
> can give you reading of all memory available to the kernel.
>
>
> The mpls code in question reads a pointer from memory.
>
>
> The only thing the code does with that pointer is verify it is not NULL
> and dereference it.
>
> That does not make it possible to extricate the pointer bits via a cache
> side-channel as a pointer is 64bits wide.
>
> There might maybe be a timing attack where it is timed how long the
> packet takes to deliver. If you can find the base address of the array,
> at best such a timeing attack will tell you is if some arbitrary cache
> line is already cached in the kernel. Which is not the class of attack
> your patchset is worried about. Further there are more direct ways
> to probe the cache from a local process.
>
> So I submit to you that the mpls code is not vulnerable to the class of
> attack you are addressing.
>
> Further I would argue that anything that reads a pointer from memory is
> a very strong clue that it falls outside the class of code that you are
> addressing.
>
> Show me where I am wrong and I will consider patches.
No, the concern is a second dependent read (or write) within the
speculation window after this first bounds-checked dependent read.
I.e. this mpls code path appears to have the setup condition:
if (x < max)
val = array1[x];
...but it's not clear that there is an exploit condition later on in
the instruction stream:
array2[val] = y;
/* or */
y = array2[val];
My personal paranoia says submit the patch and not worry about finding
that later exploit condition, if DaveM wants to drop the patch that's
his prerogative. In general, with the performance conscious version of
nospec_array_ptr() being the default, why worry about what is / is not
in the speculation window?
^ permalink raw reply
* [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config
From: Alexei Starovoitov @ 2018-01-09 18:04 UTC (permalink / raw)
To: davem; +Cc: daniel, netdev, linux-kernel, kernel-team
The BPF interpreter has been used as part of the spectre 2 attack CVE-2017-5715.
A quote from goolge project zero blog:
"At this point, it would normally be necessary to locate gadgets in
the host kernel code that can be used to actually leak data by reading
from an attacker-controlled location, shifting and masking the result
appropriately and then using the result of that as offset to an
attacker-controlled address for a load. But piecing gadgets together
and figuring out which ones work in a speculation context seems annoying.
So instead, we decided to use the eBPF interpreter, which is built into
the host kernel - while there is no legitimate way to invoke it from inside
a VM, the presence of the code in the host kernel's text section is sufficient
to make it usable for the attack, just like with ordinary ROP gadgets."
To make attacker job harder introduce BPF_JIT_ALWAYS_ON config
option that removes interpreter from the kernel in favor of JIT-only mode.
So far eBPF JIT is supported by:
x64, arm64, arm32, sparc64, s390, powerpc64, mips64
The start of JITed program is randomized and code page is marked as read-only.
In addition "constant blinding" can be turned on with net.core.bpf_jit_harden
v2->v3:
- move __bpf_prog_ret0 under ifdef (Daniel)
v1->v2:
- fix init order, test_bpf and cBPF (Daniel's feedback)
- fix offloaded bpf (Jakub's feedback)
- add 'return 0' dummy in case something can invoke prog->bpf_func
- retarget bpf tree. For bpf-next the patch would need one extra hunk.
It will be sent when the trees are merged back to net-next
Considered doing:
int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT;
but it seems better to land the patch as-is and in bpf-next remove
bpf_jit_enable global variable from all JITs, consolidate in one place
and remove this jit_init() function.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
init/Kconfig | 7 +++++++
kernel/bpf/core.c | 19 +++++++++++++++++++
lib/test_bpf.c | 11 +++++++----
net/core/filter.c | 6 ++----
net/core/sysctl_net_core.c | 6 ++++++
net/socket.c | 9 +++++++++
6 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 2934249fba46..5e2a4a391ba9 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1392,6 +1392,13 @@ config BPF_SYSCALL
Enable the bpf() system call that allows to manipulate eBPF
programs and maps via file descriptors.
+config BPF_JIT_ALWAYS_ON
+ bool "Permanently enable BPF JIT and remove BPF interpreter"
+ depends on BPF_SYSCALL && HAVE_EBPF_JIT && BPF_JIT
+ help
+ Enables BPF JIT and removes BPF interpreter to avoid
+ speculative execution of BPF instructions by the interpreter
+
config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 86b50aa26ee8..51ec2dda7f08 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -767,6 +767,7 @@ noinline u64 __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
}
EXPORT_SYMBOL_GPL(__bpf_call_base);
+#ifndef CONFIG_BPF_JIT_ALWAYS_ON
/**
* __bpf_prog_run - run eBPF program on a given context
* @ctx: is the data we are operating on
@@ -1317,6 +1318,14 @@ EVAL6(PROG_NAME_LIST, 224, 256, 288, 320, 352, 384)
EVAL4(PROG_NAME_LIST, 416, 448, 480, 512)
};
+#else
+static unsigned int __bpf_prog_ret0(const void *ctx,
+ const struct bpf_insn *insn)
+{
+ return 0;
+}
+#endif
+
bool bpf_prog_array_compatible(struct bpf_array *array,
const struct bpf_prog *fp)
{
@@ -1364,9 +1373,13 @@ static int bpf_check_tail_call(const struct bpf_prog *fp)
*/
struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)
{
+#ifndef CONFIG_BPF_JIT_ALWAYS_ON
u32 stack_depth = max_t(u32, fp->aux->stack_depth, 1);
fp->bpf_func = interpreters[(round_up(stack_depth, 32) / 32) - 1];
+#else
+ fp->bpf_func = __bpf_prog_ret0;
+#endif
/* eBPF JITs can rewrite the program in case constant
* blinding is active. However, in case of error during
@@ -1376,6 +1389,12 @@ struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)
*/
if (!bpf_prog_is_dev_bound(fp->aux)) {
fp = bpf_int_jit_compile(fp);
+#ifdef CONFIG_BPF_JIT_ALWAYS_ON
+ if (!fp->jited) {
+ *err = -ENOTSUPP;
+ return fp;
+ }
+#endif
} else {
*err = bpf_prog_offload_compile(fp);
if (*err)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index 9e9748089270..f369889e521d 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -6250,9 +6250,8 @@ static struct bpf_prog *generate_filter(int which, int *err)
return NULL;
}
}
- /* We don't expect to fail. */
if (*err) {
- pr_cont("FAIL to attach err=%d len=%d\n",
+ pr_cont("FAIL to prog_create err=%d len=%d\n",
*err, fprog.len);
return NULL;
}
@@ -6276,6 +6275,10 @@ static struct bpf_prog *generate_filter(int which, int *err)
* checks.
*/
fp = bpf_prog_select_runtime(fp, err);
+ if (*err) {
+ pr_cont("FAIL to select_runtime err=%d\n", *err);
+ return NULL;
+ }
break;
}
@@ -6461,8 +6464,8 @@ static __init int test_bpf(void)
pass_cnt++;
continue;
}
-
- return err;
+ err_cnt++;
+ continue;
}
pr_cont("jited:%u ", fp->jited);
diff --git a/net/core/filter.c b/net/core/filter.c
index 6a85e67fafce..d339ef170df6 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1054,11 +1054,9 @@ static struct bpf_prog *bpf_migrate_filter(struct bpf_prog *fp)
*/
goto out_err_free;
- /* We are guaranteed to never error here with cBPF to eBPF
- * transitions, since there's no issue with type compatibility
- * checks on program arrays.
- */
fp = bpf_prog_select_runtime(fp, &err);
+ if (err)
+ goto out_err_free;
kfree(old_prog);
return fp;
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index cbc3dde4cfcc..a47ad6cd41c0 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -325,7 +325,13 @@ static struct ctl_table net_core_table[] = {
.data = &bpf_jit_enable,
.maxlen = sizeof(int),
.mode = 0644,
+#ifndef CONFIG_BPF_JIT_ALWAYS_ON
.proc_handler = proc_dointvec
+#else
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &one,
+ .extra2 = &one,
+#endif
},
# ifdef CONFIG_HAVE_EBPF_JIT
{
diff --git a/net/socket.c b/net/socket.c
index 05f361faec45..78acd6ce74c7 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2619,6 +2619,15 @@ static int __init sock_init(void)
core_initcall(sock_init); /* early initcall */
+static int __init jit_init(void)
+{
+#ifdef CONFIG_BPF_JIT_ALWAYS_ON
+ bpf_jit_enable = 1;
+#endif
+ return 0;
+}
+pure_initcall(jit_init);
+
#ifdef CONFIG_PROC_FS
void socket_seq_show(struct seq_file *seq)
{
--
2.9.5
^ permalink raw reply related
* Re: [PATCH bpf] bpf: avoid false sharing of map refcount with max_entries
From: Alexei Starovoitov @ 2018-01-09 18:17 UTC (permalink / raw)
To: Edward Cree; +Cc: Daniel Borkmann, ast, netdev
In-Reply-To: <51893658-b798-c8da-fc9f-3e65f771eaec@solarflare.com>
On Tue, Jan 09, 2018 at 04:23:08PM +0000, Edward Cree wrote:
> >
> > Quoting from Goolge's Project Zero blog [1]:
> typo "Goolge".
Applied with typo fixed, thanks Daniel!
^ permalink raw reply
* tun: memory leak in tun_set_iff
From: Dmitry Vyukov @ 2018-01-09 18:20 UTC (permalink / raw)
To: David Miller, Jason Wang, Eric Dumazet, Willem de Bruijn,
Michael S. Tsirkin, netdev, LKML, syzkaller
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
Hello,
syzkaller has hit the following memory leak on 4.15-rc7.
Reproducer is attached.
unreeferenced object 0xffff88002c9ac400 (size 4096):
comm "syz-executor0", pid 12349, jiffies 4295751114 (age 10.067s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000ad172f4e>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000ad172f4e>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000ad172f4e>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000ad172f4e>] slab_alloc mm/slub.c:2733 [inline]
[<00000000ad172f4e>] __kmalloc+0x1a9/0x340 mm/slub.c:3758
[<00000000d66b86d6>] kmalloc_array include/linux/slab.h:618 [inline]
[<00000000d66b86d6>] kcalloc include/linux/slab.h:629 [inline]
[<00000000d66b86d6>] __ptr_ring_init_queue_alloc
include/linux/ptr_ring.h:450 [inline]
[<00000000d66b86d6>] ptr_ring_init include/linux/ptr_ring.h:468 [inline]
[<00000000d66b86d6>] skb_array_init include/linux/skb_array.h:176 [inline]
[<00000000d66b86d6>] tun_attach+0x940/0x10b0 drivers/net/tun.c:754
[<000000007a69e5cb>] tun_set_iff drivers/net/tun.c:2315 [inline]
[<000000007a69e5cb>] __tun_chr_ioctl+0x2435/0x4210 drivers/net/tun.c:2524
[<000000005c75f6a6>] tun_chr_ioctl+0x2a/0x40 drivers/net/tun.c:2773
[<00000000ece2f188>] vfs_ioctl fs/ioctl.c:46 [inline]
[<00000000ece2f188>] file_ioctl fs/ioctl.c:500 [inline]
[<00000000ece2f188>] do_vfs_ioctl+0x1cf/0x16b0 fs/ioctl.c:684
[<0000000021f4fda7>] SYSC_ioctl fs/ioctl.c:701 [inline]
[<0000000021f4fda7>] SyS_ioctl+0xb6/0xe0 fs/ioctl.c:692
[<0000000001148918>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<000000008d0cf26e>] 0xffffffffffffffff
[-- Attachment #2: tun.c --]
[-- Type: text/x-csrc, Size: 942 bytes --]
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <endian.h>
#include <fcntl.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <unistd.h>
int main()
{
syscall(__NR_mmap, 0x20000000, 0xfff000, 3, 0x32, -1, 0);
int fd = syscall(__NR_open, "/dev/net/tun", 0);
*(uint32_t*)0x2021b000 = 9;
syscall(__NR_ioctl, fd, 0x400454da, 0x2021b000);
memcpy((void*)0x20533000,
"\x02\x00\x00\x00\x04\x00\x00\x00\x00\x04\x00\x80\x00\xe9\xbc\x22", 16);
*(uint32_t*)0x20533010 = 0x10001;
*(uint32_t*)0x20533014 = 0;
*(uint64_t*)0x20533018 = 0x20012fe8;
*(uint32_t*)0x20012fe8 = 0;
*(uint32_t*)0x20012fec = 0;
*(uint32_t*)0x20012ff0 = 0;
*(uint32_t*)0x20012ff4 = 0;
*(uint32_t*)0x20012ff8 = 0;
*(uint16_t*)0x20012ffc = 0;
*(uint16_t*)0x20012ffe = 0;
syscall(__NR_ioctl, fd, 0x400454ca, 0x20533000);
return 0;
}
^ permalink raw reply
* [PATCH net] ipv6: Fix cleanup ordering on inet6_init() error path
From: Ben Hutchings @ 2018-01-09 18:21 UTC (permalink / raw)
To: netdev; +Cc: WANG Cong, Andrey Konovalov
Commit 15e668070a64 reordered the initialisation in inet6_init() to
fix a crash on an error path further down the call stack. It also
reordered cleanup on the error path in inet6_init(), but the result
is not the reverse of the initialisation order. This presumably
can result in a resource leak or crash in some error cases. Reorder
cleanup again to fix this.
Fixes: 15e668070a64 ("ipv6: reorder icmpv6_init() and ip6_mr_init()")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
This fix is untested and based only on my review of the earlier commit.
Ben.
net/ipv6/af_inet6.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index c9441ca45399..fbaa70d95d7f 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -1074,11 +1074,11 @@ static int __init inet6_init(void)
igmp_fail:
ndisc_cleanup();
ndisc_fail:
- ip6_mr_cleanup();
+ icmpv6_cleanup();
icmp_fail:
- unregister_pernet_subsys(&inet6_net_ops);
+ ip6_mr_cleanup();
ipmr_fail:
- icmpv6_cleanup();
+ unregister_pernet_subsys(&inet6_net_ops);
register_pernet_fail:
sock_unregister(PF_INET6);
rtnl_unregister_all(PF_INET6);
--
2.15.0.rc0
^ permalink raw reply related
* Re: [PATCH net-next v3 06/10] net/mlx5e: Change Mellanox references in DIM code
From: Tal Gilboa @ 2018-01-09 18:22 UTC (permalink / raw)
To: Andy Gospodarek, Saeed Mahameed; +Cc: netdev, mchan, Talat Batheesh
In-Reply-To: <20180109160646.GA2262@C02RW35GFVH8.dhcp.broadcom.net>
On 1/9/2018 6:06 PM, Andy Gospodarek wrote:
> On Mon, Jan 08, 2018 at 11:06:28PM -0800, Saeed Mahameed wrote:
>>
>>
>> On 01/08/2018 10:13 PM, Andy Gospodarek wrote:
>>> From: Andy Gospodarek <gospo@broadcom.com>
>>>
>>> Change all appropriate mlx5_am* and MLX5_AM* references to net_dim and
>>> NET_DIM, respectively, in code that handles dynamic interrupt
>>> moderation. Also change all references from 'am' to 'dim' when used as
>>> local variables and add generic profile references.
>>>
>>> Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
>>> Acked-by: Tal Gilboa <talgi@mellanox.com>
>>> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>>> ---
>>> drivers/net/ethernet/mellanox/mlx5/core/en.h | 9 +-
>>> drivers/net/ethernet/mellanox/mlx5/core/en_dim.c | 14 +-
>>> .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 6 +-
>>> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 40 ++-
>>> drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 8 +-
>>> drivers/net/ethernet/mellanox/mlx5/core/net_dim.c | 286 ++++++++++-----------
>>> drivers/net/ethernet/mellanox/mlx5/core/net_dim.h | 63 ++---
>>> 7 files changed, 225 insertions(+), 201 deletions(-)
>>>
>>
>> [...]
>>
>>> #define IS_SIGNIFICANT_DIFF(val, ref) \
>>> (((100 * abs((val) - (ref))) / (ref)) > 10) /* more than 10% difference */
>>> -static int mlx5e_am_stats_compare(struct mlx5e_rx_am_stats *curr,
>>> - struct mlx5e_rx_am_stats *prev)
>>> +static int net_dim_stats_compare(struct net_dim_stats *curr,
>>> + struct net_dim_stats *prev)
>>> {
>>> if (!prev->bpms)
>>> - return curr->bpms ? MLX5E_AM_STATS_BETTER :
>>> - MLX5E_AM_STATS_SAME;
>>> + return curr->bpms ? NET_DIM_STATS_BETTER :
>>> + NET_DIM_STATS_SAME;
>>> if (IS_SIGNIFICANT_DIFF(curr->bpms, prev->bpms))
>>> - return (curr->bpms > prev->bpms) ? MLX5E_AM_STATS_BETTER :
>>> - MLX5E_AM_STATS_WORSE;
>>> + return (curr->bpms > prev->bpms) ? NET_DIM_STATS_BETTER :
>>> + NET_DIM_STATS_WORSE;
>>
>> Hey Andy,
>>
>> I am currently reviewing a patch internally that fixes a bug in this area,
>> prev->ppms can be 0 and could cause IS_SIGNIFICANT_DIFF ouch !
>> same goes for prev->eppm, for some reason we had a broken assumption that if
>> ppms is 0 for some reason then the bpms is 0 and the above condition will
>> cover us.
>>
>> Anyway the patch will go to net, which means when this series gets accepted
>> then net-next will fail to merge with net and we need to manually push the
>> fix to the new DIM library.
>>
>> But for now I don't think anything is required for this series other than
>> bringing this division by 0 issue and the future merge conflict to your
>> attention.
>>
>
> Thanks for bringing that to everyone's attention. I agree there is
> probably not much that should be done at this point -- hopefully the
> merge should go pretty smoothly, since net_dim.h is seen as a rename
> from en_rx_am.c.
I talked with Talat, who is submitting the fix. He will apply it over
these patches after they are accepted.
>
>
>>> if (IS_SIGNIFICANT_DIFF(curr->ppms, prev->ppms))
>>> - return (curr->ppms > prev->ppms) ? MLX5E_AM_STATS_BETTER :
>>> - MLX5E_AM_STATS_WORSE;
>>> + return (curr->ppms > prev->ppms) ? NET_DIM_STATS_BETTER :
>>> + NET_DIM_STATS_WORSE;
>>> if (IS_SIGNIFICANT_DIFF(curr->epms, prev->epms))
>>> - return (curr->epms < prev->epms) ? MLX5E_AM_STATS_BETTER :
>>> - MLX5E_AM_STATS_WORSE;
>>> + return (curr->epms < prev->epms) ? NET_DIM_STATS_BETTER :
>>> + NET_DIM_STATS_WORSE;
>>> - return MLX5E_AM_STATS_SAME;
>>> + return NET_DIM_STATS_SAME;
>>> }
^ permalink raw reply
* Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout
From: Geert Uytterhoeven @ 2018-01-09 18:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Andrew Lunn, Geert Uytterhoeven, David S . Miller,
Florian Fainelli, netdev, Linux-Renesas,
Linux Kernel Mailing List
In-Reply-To: <20180109142248.GG17719@n2100.armlinux.org.uk>
Hi Russell,
On Tue, Jan 9, 2018 at 3:22 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Tue, Jan 09, 2018 at 03:10:08PM +0100, Andrew Lunn wrote:
>> On Tue, Jan 09, 2018 at 12:11:21PM +0100, Geert Uytterhoeven wrote:
>> > In case of success, the return values of (__)phy_write() and
>> > (__)phy_modify() are not compatible: (__)phy_write() returns 0, while
>> > (__)phy_modify() returns the old PHY register value.
>> >
>> > Apparently this change was catered for in drivers/net/phy/marvell.c, but
>> > not in other source files.
>> >
>> > Hence genphy_restart_aneg() now returns 4416 instead zero, which is
>> > considered an error:
>> >
>> > ravb e6800000.ethernet eth0: failed to connect PHY
>> > IP-Config: Failed to open eth0
>> > IP-Config: No network devices available
>> >
>> > Fix this by converting positive values to zero in all callers of
>> > phy_modify().
>> >
>> > Fixes: fea23fb591cce995 ("net: phy: convert read-modify-write to phy_modify()")
>> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> > ---
>> > Alternatively, __phy_modify() could be changed to follow __phy_write()
>> > semantics?
>>
>> Hi Geert, Russell
>>
>> I took a quick look at the uses of phy_modify(). I don't see any uses
>> of the return code other than as an error indicator. So having it
>> return 0 on success seems like a better fix.
>
> I'd like to avoid that, because I don't want to have yet another
> accessor that needs to be used for advertisment modification (where
> we need to know if we changed any bits.)
>
> That's why this accessor returns the old value.
But this is documented nowhere!
I believe there are no current users of (__)phy_modify() that rely on this
behavior. Except perhaps phy_restore_page(), which I don't understand at all.
BTW, I think phy_restore_page() may return a strict positive value as well,
thus breaking m88e1318_set_wol(), which is not supposed to return strict
positive values.
So changing __phy_modify() to return zero on success seems like the way
forward...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout
From: Russell King - ARM Linux @ 2018-01-09 18:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Andrew Lunn, Geert Uytterhoeven, David S . Miller,
Florian Fainelli, netdev, Linux-Renesas,
Linux Kernel Mailing List
In-Reply-To: <CAMuHMdXBasJu-u54LxT3x3fXcnW4Bm9N1nNyt-S=R5+=3oZaDA@mail.gmail.com>
On Tue, Jan 09, 2018 at 07:25:40PM +0100, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Tue, Jan 9, 2018 at 3:22 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Tue, Jan 09, 2018 at 03:10:08PM +0100, Andrew Lunn wrote:
> >> On Tue, Jan 09, 2018 at 12:11:21PM +0100, Geert Uytterhoeven wrote:
> >> > In case of success, the return values of (__)phy_write() and
> >> > (__)phy_modify() are not compatible: (__)phy_write() returns 0, while
> >> > (__)phy_modify() returns the old PHY register value.
> >> >
> >> > Apparently this change was catered for in drivers/net/phy/marvell.c, but
> >> > not in other source files.
> >> >
> >> > Hence genphy_restart_aneg() now returns 4416 instead zero, which is
> >> > considered an error:
> >> >
> >> > ravb e6800000.ethernet eth0: failed to connect PHY
> >> > IP-Config: Failed to open eth0
> >> > IP-Config: No network devices available
> >> >
> >> > Fix this by converting positive values to zero in all callers of
> >> > phy_modify().
> >> >
> >> > Fixes: fea23fb591cce995 ("net: phy: convert read-modify-write to phy_modify()")
> >> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> > ---
> >> > Alternatively, __phy_modify() could be changed to follow __phy_write()
> >> > semantics?
> >>
> >> Hi Geert, Russell
> >>
> >> I took a quick look at the uses of phy_modify(). I don't see any uses
> >> of the return code other than as an error indicator. So having it
> >> return 0 on success seems like a better fix.
> >
> > I'd like to avoid that, because I don't want to have yet another
> > accessor that needs to be used for advertisment modification (where
> > we need to know if we changed any bits.)
> >
> > That's why this accessor returns the old value.
>
> But this is documented nowhere!
>
> I believe there are no current users of (__)phy_modify() that rely on this
> behavior. Except perhaps phy_restore_page(), which I don't understand at all.
>
> BTW, I think phy_restore_page() may return a strict positive value as well,
> thus breaking m88e1318_set_wol(), which is not supposed to return strict
> positive values.
Correct, and it has to for temperature reading in marvell.c to work.
> So changing __phy_modify() to return zero on success seems like the way
> forward...
So what do we call an accessor that returns the original value?
__phy_modify_return_old_value()
bit long-winded isn't it?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout
From: Geert Uytterhoeven @ 2018-01-09 18:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Andrew Lunn, Geert Uytterhoeven, David S . Miller,
Florian Fainelli, netdev, Linux-Renesas,
Linux Kernel Mailing List
In-Reply-To: <20180109183116.GN17719@n2100.armlinux.org.uk>
Hi Russell,
On Tue, Jan 9, 2018 at 7:31 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Tue, Jan 09, 2018 at 07:25:40PM +0100, Geert Uytterhoeven wrote:
>> On Tue, Jan 9, 2018 at 3:22 PM, Russell King - ARM Linux
>> <linux@armlinux.org.uk> wrote:
>> > On Tue, Jan 09, 2018 at 03:10:08PM +0100, Andrew Lunn wrote:
>> >> On Tue, Jan 09, 2018 at 12:11:21PM +0100, Geert Uytterhoeven wrote:
>> >> > In case of success, the return values of (__)phy_write() and
>> >> > (__)phy_modify() are not compatible: (__)phy_write() returns 0, while
>> >> > (__)phy_modify() returns the old PHY register value.
>> >> >
>> >> > Apparently this change was catered for in drivers/net/phy/marvell.c, but
>> >> > not in other source files.
>> >> >
>> >> > Hence genphy_restart_aneg() now returns 4416 instead zero, which is
>> >> > considered an error:
>> >> >
>> >> > ravb e6800000.ethernet eth0: failed to connect PHY
>> >> > IP-Config: Failed to open eth0
>> >> > IP-Config: No network devices available
>> >> >
>> >> > Fix this by converting positive values to zero in all callers of
>> >> > phy_modify().
>> >> >
>> >> > Fixes: fea23fb591cce995 ("net: phy: convert read-modify-write to phy_modify()")
>> >> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> >> > ---
>> >> > Alternatively, __phy_modify() could be changed to follow __phy_write()
>> >> > semantics?
>> >>
>> >> Hi Geert, Russell
>> >>
>> >> I took a quick look at the uses of phy_modify(). I don't see any uses
>> >> of the return code other than as an error indicator. So having it
>> >> return 0 on success seems like a better fix.
>> >
>> > I'd like to avoid that, because I don't want to have yet another
>> > accessor that needs to be used for advertisment modification (where
>> > we need to know if we changed any bits.)
>> >
>> > That's why this accessor returns the old value.
>>
>> But this is documented nowhere!
>>
>> I believe there are no current users of (__)phy_modify() that rely on this
>> behavior. Except perhaps phy_restore_page(), which I don't understand at all.
>>
>> BTW, I think phy_restore_page() may return a strict positive value as well,
>> thus breaking m88e1318_set_wol(), which is not supposed to return strict
>> positive values.
>
> Correct, and it has to for temperature reading in marvell.c to work.
For phy_restore_page()?
Not for breaking m88e1318_set_wol(), I guess?
>> So changing __phy_modify() to return zero on success seems like the way
>> forward...
>
> So what do we call an accessor that returns the original value?
>
> __phy_modify_return_old_value()
__phy_modify_ret()?
Or __phy_modify(...., u16 *oldval) (where oldval can be NULL)?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* net: memory leak in socket
From: Dmitry Vyukov @ 2018-01-09 18:39 UTC (permalink / raw)
To: David Miller, netdev, LKML, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Eric Dumazet, Willem de Bruijn, syzkaller
Hello,
syzkaller has hit the following memory leak on 4.15-rc7:
unreferenced object 0xffff88002713fb20 (size 16):
comm "syz-executor3", pid 6576, jiffies 4295029354 (age 10.166s)
hex dump (first 16 bytes):
69 6e 73 6d 6f 64 5f 74 00 00 d9 1c 00 88 ff ff insmod_t........
backtrace:
[<00000000da8d6b27>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000da8d6b27>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000da8d6b27>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000da8d6b27>] slab_alloc mm/slub.c:2733 [inline]
[<00000000da8d6b27>] __kmalloc_track_caller+0x183/0x310 mm/slub.c:4290
[<000000001aa62b7a>] kstrdup+0x39/0x70 mm/util.c:56
[<00000000fa6a957e>] security_netlbl_sid_to_secattr+0xbc/0x1a0
security/selinux/ss/services.c:3522
[<0000000054674134>] selinux_netlbl_sock_genattr+0xef/0x410
security/selinux/netlabel.c:94
[<000000002338a05c>] selinux_netlbl_socket_post_create+0x79/0x160
security/selinux/netlabel.c:341
[<0000000059825908>] selinux_socket_post_create+0x37f/0xa60
security/selinux/hooks.c:4399
[<00000000fff6c966>] security_socket_post_create+0x8b/0xd0
security/security.c:1344
[<000000005786c830>] __sock_create+0x758/0x920 net/socket.c:1281
[<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
[<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
[<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
[<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<00000000921bbbd9>] 0xffffffffffffffff
unreferenced object 0xffff88007c3bba80 (size 992):
comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
hex dump (first 32 bytes):
01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
40 2e 5a 2c 00 88 ff ff 00 00 00 00 00 00 00 00 @.Z,............
backtrace:
[<00000000ff3d837a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000ff3d837a>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000ff3d837a>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000ff3d837a>] slab_alloc mm/slub.c:2733 [inline]
[<00000000ff3d837a>] kmem_cache_alloc+0x110/0x280 mm/slub.c:2738
[<00000000d243ce94>] sock_alloc_inode+0x70/0x300 net/socket.c:250
[<000000005a0b3852>] alloc_inode+0x65/0x190 fs/inode.c:208
[<000000004af29540>] new_inode_pseudo+0x69/0x1a0 fs/inode.c:890
[<0000000074cb6753>] sock_alloc+0x41/0x280 net/socket.c:569
[<00000000cc5c2e64>] __sock_create+0x161/0x920 net/socket.c:1229
[<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
[<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
[<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
[<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<00000000921bbbd9>] 0xffffffffffffffff
unreferenced object 0xffff88002c5a2e40 (size 128):
comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
hex dump (first 32 bytes):
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
ff ff ff ff ff ff ff ff c0 da db 88 ff ff ff ff ................
backtrace:
[<00000000696a590c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000696a590c>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000696a590c>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000696a590c>] slab_alloc mm/slub.c:2733 [inline]
[<00000000696a590c>] kmem_cache_alloc_trace+0x126/0x290 mm/slub.c:2750
[<00000000551c8f10>] kmalloc include/linux/slab.h:499 [inline]
[<00000000551c8f10>] sock_alloc_inode+0xb4/0x300 net/socket.c:253
[<000000005a0b3852>] alloc_inode+0x65/0x190 fs/inode.c:208
[<000000004af29540>] new_inode_pseudo+0x69/0x1a0 fs/inode.c:890
[<0000000074cb6753>] sock_alloc+0x41/0x280 net/socket.c:569
[<00000000cc5c2e64>] __sock_create+0x161/0x920 net/socket.c:1229
[<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
[<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
[<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
[<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<00000000921bbbd9>] 0xffffffffffffffff
unreferenced object 0xffff88007310f680 (size 96):
comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
hex dump (first 32 bytes):
b0 ba 3b 7c 00 88 ff ff 88 f6 10 73 00 88 ff ff ..;|.......s....
88 f6 10 73 00 88 ff ff dd 00 00 00 dd 00 00 00 ...s............
backtrace:
[<00000000ff3d837a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000ff3d837a>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000ff3d837a>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000ff3d837a>] slab_alloc mm/slub.c:2733 [inline]
[<00000000ff3d837a>] kmem_cache_alloc+0x110/0x280 mm/slub.c:2738
[<00000000094ffa79>] kmem_cache_zalloc include/linux/slab.h:678 [inline]
[<00000000094ffa79>] inode_alloc_security
security/selinux/hooks.c:234 [inline]
[<00000000094ffa79>] selinux_inode_alloc_security+0xf9/0x390
security/selinux/hooks.c:2885
[<0000000082b97b6d>] security_inode_alloc+0x92/0xe0 security/security.c:437
[<000000009683bb60>] inode_init_always+0x64f/0xca0 fs/inode.c:167
[<00000000a71f5b21>] alloc_inode+0x82/0x190 fs/inode.c:215
[<000000004af29540>] new_inode_pseudo+0x69/0x1a0 fs/inode.c:890
[<0000000074cb6753>] sock_alloc+0x41/0x280 net/socket.c:569
[<00000000cc5c2e64>] __sock_create+0x161/0x920 net/socket.c:1229
[<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
[<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
[<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
[<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<00000000921bbbd9>] 0xffffffffffffffff
unreferenced object 0xffff88007127bf00 (size 2528):
comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<00000000ff3d837a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000ff3d837a>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<00000000ff3d837a>] slab_alloc_node mm/slub.c:2725 [inline]
[<00000000ff3d837a>] slab_alloc mm/slub.c:2733 [inline]
[<00000000ff3d837a>] kmem_cache_alloc+0x110/0x280 mm/slub.c:2738
[<0000000021d2cae7>] sk_prot_alloc+0x69/0x2f0 net/core/sock.c:1463
[<0000000088be91b8>] sk_alloc+0x109/0x1740 net/core/sock.c:1523
[<00000000bbd7f0e5>] inet_create+0x4f8/0x10a0 net/ipv4/af_inet.c:319
[<00000000c0aa842f>] __sock_create+0x521/0x920 net/socket.c:1265
[<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
[<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
[<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
[<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
[<00000000921bbbd9>] 0xffffffffffffffff
Reproducer:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <sys/time.h>
#include <sys/resource.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
int main()
{
struct rlimit rlim;
rlim.rlim_cur = 0;
rlim.rlim_max = 0;
setrlimit(RLIMIT_NOFILE, &rlim);
socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
return 0;
}
^ permalink raw reply
* Re: [PATCH v2 2/3] net: Add BUG_ON() to get_net()
From: Eric Dumazet @ 2018-01-09 18:52 UTC (permalink / raw)
To: Kirill Tkhai, netdev, davem; +Cc: ebiederm
In-Reply-To: <151551003602.4318.8752010178458260165.stgit@localhost.localdomain>
On Tue, 2018-01-09 at 18:00 +0300, Kirill Tkhai wrote:
> Since people may mistakenly obtain destroying net
> from net_namespace_list and from net::netns_ids
> without checking for its net::counter, let's protect
> against such situations and insert BUG_ON() to stop
> move on after this.
>
> Panic is better, than memory corruption and undefined
> behavior.
>
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
> ---
> include/net/net_namespace.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index 10f99dafd5ac..ff0e47471d5b 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -195,7 +195,7 @@ void __put_net(struct net *net);
>
> static inline struct net *get_net(struct net *net)
> {
> - atomic_inc(&net->count);
> + BUG_ON(atomic_inc_return(&net->count) <= 1);
> return net;
> }
Why not simply use refcount_t instead of duplicating its logic ?
^ permalink raw reply
* net/8021q: memory leak in register_vlan_dev
From: Dmitry Vyukov @ 2018-01-09 18:53 UTC (permalink / raw)
To: David Miller, vfedorenko, gfree.wind, David Ahern, Cong Wang,
netdev, LKML, Eric Dumazet, Willem de Bruijn, syzkaller
Hello,
syzkaller has hit the following memory leak on 4.15-rc7:
unreferenced object 0xffff88007b704140 (size 256):
comm "syz-executor6", pid 5661, jiffies 4294856803 (age 9.848s)
hex dump (first 32 bytes):
00 40 b7 2c 00 88 ff ff 00 00 00 00 00 00 00 00 .@.,............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000050f8eb54>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<0000000050f8eb54>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<0000000050f8eb54>] slab_alloc_node mm/slub.c:2725 [inline]
[<0000000050f8eb54>] slab_alloc mm/slub.c:2733 [inline]
[<0000000050f8eb54>] kmem_cache_alloc_trace+0x126/0x290 mm/slub.c:2750
[<000000004d4e9ef7>] kmalloc include/linux/slab.h:499 [inline]
[<000000004d4e9ef7>] kzalloc include/linux/slab.h:688 [inline]
[<000000004d4e9ef7>] vlan_info_alloc net/8021q/vlan_core.c:152 [inline]
[<000000004d4e9ef7>] vlan_vid_add+0x710/0xb20 net/8021q/vlan_core.c:244
[<000000000e87916f>] register_vlan_dev+0xbf/0x600 net/8021q/vlan.c:150
[<00000000b2f0a3d2>] register_vlan_device net/8021q/vlan.c:273 [inline]
[<00000000b2f0a3d2>] vlan_ioctl_handler+0xbac/0x140d net/8021q/vlan.c:593
[<00000000c951ea6d>] sock_ioctl+0x2f8/0x460 net/socket.c:1039
[<00000000e2a8e27a>] vfs_ioctl fs/ioctl.c:46 [inline]
[<00000000e2a8e27a>] file_ioctl fs/ioctl.c:500 [inline]
[<00000000e2a8e27a>] do_vfs_ioctl+0x1cf/0x16b0 fs/ioctl.c:684
[<00000000ec28ff91>] SYSC_ioctl fs/ioctl.c:701 [inline]
[<00000000ec28ff91>] SyS_ioctl+0xb6/0xe0 fs/ioctl.c:692
unreferenced object 0xffff88007c49aea0 (size 32):
comm "syz-executor6", pid 5661, jiffies 4294856803 (age 9.862s)
hex dump (first 32 bytes):
e0 41 70 7b 00 88 ff ff e0 41 70 7b 00 88 ff ff .Ap{.....Ap{....
81 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000050f8eb54>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<0000000050f8eb54>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<0000000050f8eb54>] slab_alloc_node mm/slub.c:2725 [inline]
[<0000000050f8eb54>] slab_alloc mm/slub.c:2733 [inline]
[<0000000050f8eb54>] kmem_cache_alloc_trace+0x126/0x290 mm/slub.c:2750
[<000000003d983c2c>] kmalloc include/linux/slab.h:499 [inline]
[<000000003d983c2c>] kzalloc include/linux/slab.h:688 [inline]
[<000000003d983c2c>] vlan_vid_info_alloc net/8021q/vlan_core.c:196 [inline]
[<000000003d983c2c>] __vlan_vid_add net/8021q/vlan_core.c:213 [inline]
[<000000003d983c2c>] vlan_vid_add+0x45a/0xb20 net/8021q/vlan_core.c:251
[<000000000e87916f>] register_vlan_dev+0xbf/0x600 net/8021q/vlan.c:150
[<00000000b2f0a3d2>] register_vlan_device net/8021q/vlan.c:273 [inline]
[<00000000b2f0a3d2>] vlan_ioctl_handler+0xbac/0x140d net/8021q/vlan.c:593
[<00000000c951ea6d>] sock_ioctl+0x2f8/0x460 net/socket.c:1039
[<00000000e2a8e27a>] vfs_ioctl fs/ioctl.c:46 [inline]
[<00000000e2a8e27a>] file_ioctl fs/ioctl.c:500 [inline]
[<00000000e2a8e27a>] do_vfs_ioctl+0x1cf/0x16b0 fs/ioctl.c:684
[<00000000ec28ff91>] SYSC_ioctl fs/ioctl.c:701 [inline]
[<00000000ec28ff91>] SyS_ioctl+0xb6/0xe0 fs/ioctl.c:692
unreferenced object 0xffff88007d87a200 (size 4096):
comm "syz-executor6", pid 5661, jiffies 4294856803 (age 9.863s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000050f8eb54>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<0000000050f8eb54>] slab_post_alloc_hook mm/slab.h:440 [inline]
[<0000000050f8eb54>] slab_alloc_node mm/slub.c:2725 [inline]
[<0000000050f8eb54>] slab_alloc mm/slub.c:2733 [inline]
[<0000000050f8eb54>] kmem_cache_alloc_trace+0x126/0x290 mm/slub.c:2750
[<00000000b52b3185>] kmalloc include/linux/slab.h:499 [inline]
[<00000000b52b3185>] kzalloc include/linux/slab.h:688 [inline]
[<00000000b52b3185>] vlan_group_prealloc_vid net/8021q/vlan.c:70 [inline]
[<00000000b52b3185>] register_vlan_dev+0x4ac/0x600 net/8021q/vlan.c:168
[<00000000b2f0a3d2>] register_vlan_device net/8021q/vlan.c:273 [inline]
[<00000000b2f0a3d2>] vlan_ioctl_handler+0xbac/0x140d net/8021q/vlan.c:593
[<00000000c951ea6d>] sock_ioctl+0x2f8/0x460 net/socket.c:1039
[<00000000e2a8e27a>] vfs_ioctl fs/ioctl.c:46 [inline]
[<00000000e2a8e27a>] file_ioctl fs/ioctl.c:500 [inline]
[<00000000e2a8e27a>] do_vfs_ioctl+0x1cf/0x16b0 fs/ioctl.c:684
[<00000000ec28ff91>] SYSC_ioctl fs/ioctl.c:701 [inline]
[<00000000ec28ff91>] SyS_ioctl+0xb6/0xe0 fs/ioctl.c:692
Reproducer:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <fcntl.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <unistd.h>
int main()
{
long r[2];
syscall(__NR_mmap, 0x20000000, 0xfff000, 3, 0x32, -1, 0);
r[0] = syscall(__NR_open, "/dev/net/tun", 0);
*(uint8_t*)0x20927fd8 = 0x73;
*(uint8_t*)0x20927fd9 = 0x79;
*(uint8_t*)0x20927fda = 0x7a;
*(uint8_t*)0x20927fdb = 0x30;
*(uint8_t*)0x20927fdc = 0;
*(uint32_t*)0x20927fe8 = 5;
*(uint32_t*)0x20927fec = 0;
*(uint64_t*)0x20927ff0 = 0x20c15000;
*(uint32_t*)0x20c15000 = 0;
*(uint32_t*)0x20c15004 = 0;
*(uint16_t*)0x20c15008 = 0;
syscall(__NR_ioctl, r[0], 0x400454ca, 0x20927fd8);
r[1] = syscall(__NR_socket, 2, 2, 0);
memcpy((void*)0x20006000,
"\x1b\x52\x03\x10\xb5\x64\xc4\x23\x54\xe2\xd0\xb8\xa1\x4e\x1a\xd7", 16);
*(uint32_t*)0x20006010 = 0;
*(uint32_t*)0x20006014 = 0;
*(uint64_t*)0x20006018 = 0x20006000;
*(uint32_t*)0x20006000 = 0;
*(uint8_t*)0x20006004 = 0x73;
*(uint8_t*)0x20006005 = 0x79;
*(uint8_t*)0x20006006 = 0x7a;
*(uint8_t*)0x20006007 = 0x30;
*(uint8_t*)0x20006008 = 0;
syscall(__NR_ioctl, r[1], 0x8983, 0x20006000);
return 0;
}
^ permalink raw reply
* Re: net: memory leak in socket
From: Al Viro @ 2018-01-09 18:53 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Miller, netdev, LKML, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Eric Dumazet, Willem de Bruijn, syzkaller
In-Reply-To: <CACT4Y+afcR2=wsmG_DObzG04JvVX-8X-4_zK4WYp1EAMhbbGEg@mail.gmail.com>
On Tue, Jan 09, 2018 at 07:39:50PM +0100, Dmitry Vyukov wrote:
> Hello,
>
> syzkaller has hit the following memory leak on 4.15-rc7:
>
> unreferenced object 0xffff88002713fb20 (size 16):
> comm "syz-executor3", pid 6576, jiffies 4295029354 (age 10.166s)
> hex dump (first 16 bytes):
> 69 6e 73 6d 6f 64 5f 74 00 00 d9 1c 00 88 ff ff insmod_t........
> backtrace:
> [<00000000da8d6b27>] kmemleak_alloc_recursive
> include/linux/kmemleak.h:55 [inline]
> [<00000000da8d6b27>] slab_post_alloc_hook mm/slab.h:440 [inline]
> [<00000000da8d6b27>] slab_alloc_node mm/slub.c:2725 [inline]
> [<00000000da8d6b27>] slab_alloc mm/slub.c:2733 [inline]
> [<00000000da8d6b27>] __kmalloc_track_caller+0x183/0x310 mm/slub.c:4290
> [<000000001aa62b7a>] kstrdup+0x39/0x70 mm/util.c:56
> [<00000000fa6a957e>] security_netlbl_sid_to_secattr+0xbc/0x1a0
> security/selinux/ss/services.c:3522
> [<0000000054674134>] selinux_netlbl_sock_genattr+0xef/0x410
> security/selinux/netlabel.c:94
> [<000000002338a05c>] selinux_netlbl_socket_post_create+0x79/0x160
> security/selinux/netlabel.c:341
> [<0000000059825908>] selinux_socket_post_create+0x37f/0xa60
> security/selinux/hooks.c:4399
> [<00000000fff6c966>] security_socket_post_create+0x8b/0xd0
> security/security.c:1344
> [<000000005786c830>] __sock_create+0x758/0x920 net/socket.c:1281
> [<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
> [<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
> [<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
> [<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
> [<00000000921bbbd9>] 0xffffffffffffffff
>
> unreferenced object 0xffff88007c3bba80 (size 992):
> comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
> hex dump (first 32 bytes):
> 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
> 40 2e 5a 2c 00 88 ff ff 00 00 00 00 00 00 00 00 @.Z,............
> backtrace:
> [<00000000ff3d837a>] kmemleak_alloc_recursive
> include/linux/kmemleak.h:55 [inline]
> [<00000000ff3d837a>] slab_post_alloc_hook mm/slab.h:440 [inline]
> [<00000000ff3d837a>] slab_alloc_node mm/slub.c:2725 [inline]
> [<00000000ff3d837a>] slab_alloc mm/slub.c:2733 [inline]
> [<00000000ff3d837a>] kmem_cache_alloc+0x110/0x280 mm/slub.c:2738
> [<00000000d243ce94>] sock_alloc_inode+0x70/0x300 net/socket.c:250
> [<000000005a0b3852>] alloc_inode+0x65/0x190 fs/inode.c:208
> [<000000004af29540>] new_inode_pseudo+0x69/0x1a0 fs/inode.c:890
> [<0000000074cb6753>] sock_alloc+0x41/0x280 net/socket.c:569
> [<00000000cc5c2e64>] __sock_create+0x161/0x920 net/socket.c:1229
> [<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
> [<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
> [<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
> [<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
> [<00000000921bbbd9>] 0xffffffffffffffff
>
> unreferenced object 0xffff88002c5a2e40 (size 128):
> comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
> hex dump (first 32 bytes):
> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
> ff ff ff ff ff ff ff ff c0 da db 88 ff ff ff ff ................
> backtrace:
> [<00000000696a590c>] kmemleak_alloc_recursive
> include/linux/kmemleak.h:55 [inline]
> [<00000000696a590c>] slab_post_alloc_hook mm/slab.h:440 [inline]
> [<00000000696a590c>] slab_alloc_node mm/slub.c:2725 [inline]
> [<00000000696a590c>] slab_alloc mm/slub.c:2733 [inline]
> [<00000000696a590c>] kmem_cache_alloc_trace+0x126/0x290 mm/slub.c:2750
> [<00000000551c8f10>] kmalloc include/linux/slab.h:499 [inline]
> [<00000000551c8f10>] sock_alloc_inode+0xb4/0x300 net/socket.c:253
> [<000000005a0b3852>] alloc_inode+0x65/0x190 fs/inode.c:208
> [<000000004af29540>] new_inode_pseudo+0x69/0x1a0 fs/inode.c:890
> [<0000000074cb6753>] sock_alloc+0x41/0x280 net/socket.c:569
> [<00000000cc5c2e64>] __sock_create+0x161/0x920 net/socket.c:1229
> [<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
> [<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
> [<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
> [<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
> [<00000000921bbbd9>] 0xffffffffffffffff
>
> unreferenced object 0xffff88007310f680 (size 96):
> comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
> hex dump (first 32 bytes):
> b0 ba 3b 7c 00 88 ff ff 88 f6 10 73 00 88 ff ff ..;|.......s....
> 88 f6 10 73 00 88 ff ff dd 00 00 00 dd 00 00 00 ...s............
> backtrace:
> [<00000000ff3d837a>] kmemleak_alloc_recursive
> include/linux/kmemleak.h:55 [inline]
> [<00000000ff3d837a>] slab_post_alloc_hook mm/slab.h:440 [inline]
> [<00000000ff3d837a>] slab_alloc_node mm/slub.c:2725 [inline]
> [<00000000ff3d837a>] slab_alloc mm/slub.c:2733 [inline]
> [<00000000ff3d837a>] kmem_cache_alloc+0x110/0x280 mm/slub.c:2738
> [<00000000094ffa79>] kmem_cache_zalloc include/linux/slab.h:678 [inline]
> [<00000000094ffa79>] inode_alloc_security
> security/selinux/hooks.c:234 [inline]
> [<00000000094ffa79>] selinux_inode_alloc_security+0xf9/0x390
> security/selinux/hooks.c:2885
> [<0000000082b97b6d>] security_inode_alloc+0x92/0xe0 security/security.c:437
> [<000000009683bb60>] inode_init_always+0x64f/0xca0 fs/inode.c:167
> [<00000000a71f5b21>] alloc_inode+0x82/0x190 fs/inode.c:215
> [<000000004af29540>] new_inode_pseudo+0x69/0x1a0 fs/inode.c:890
> [<0000000074cb6753>] sock_alloc+0x41/0x280 net/socket.c:569
> [<00000000cc5c2e64>] __sock_create+0x161/0x920 net/socket.c:1229
> [<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
> [<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
> [<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
> [<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
> [<00000000921bbbd9>] 0xffffffffffffffff
>
> unreferenced object 0xffff88007127bf00 (size 2528):
> comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
> backtrace:
> [<00000000ff3d837a>] kmemleak_alloc_recursive
> include/linux/kmemleak.h:55 [inline]
> [<00000000ff3d837a>] slab_post_alloc_hook mm/slab.h:440 [inline]
> [<00000000ff3d837a>] slab_alloc_node mm/slub.c:2725 [inline]
> [<00000000ff3d837a>] slab_alloc mm/slub.c:2733 [inline]
> [<00000000ff3d837a>] kmem_cache_alloc+0x110/0x280 mm/slub.c:2738
> [<0000000021d2cae7>] sk_prot_alloc+0x69/0x2f0 net/core/sock.c:1463
> [<0000000088be91b8>] sk_alloc+0x109/0x1740 net/core/sock.c:1523
> [<00000000bbd7f0e5>] inet_create+0x4f8/0x10a0 net/ipv4/af_inet.c:319
> [<00000000c0aa842f>] __sock_create+0x521/0x920 net/socket.c:1265
> [<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
> [<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
> [<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
> [<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
> [<00000000921bbbd9>] 0xffffffffffffffff
>
>
>
> Reproducer:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <sys/time.h>
> #include <sys/resource.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <arpa/inet.h>
>
> int main()
> {
> struct rlimit rlim;
> rlim.rlim_cur = 0;
> rlim.rlim_max = 0;
> setrlimit(RLIMIT_NOFILE, &rlim);
> socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
> return 0;
> }
Argh... Got broken by "make sock_alloc_file() do sock_release() on failures" -
cleanup after sock_map_fd() failure got pulled all the way into sock_alloc_file(),
but it used to serve the case when sock_map_fd() failed *before* getting to
sock_alloc_file().
Fixes: commit 8e1611e23579 (make sock_alloc_file() do sock_release() on failures)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/net/socket.c b/net/socket.c
index bbd2e9ceb692..1536515b6437 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -430,8 +430,10 @@ static int sock_map_fd(struct socket *sock, int flags)
{
struct file *newfile;
int fd = get_unused_fd_flags(flags);
- if (unlikely(fd < 0))
+ if (unlikely(fd < 0)) {
+ sock_release(sock);
return fd;
+ }
newfile = sock_alloc_file(sock, flags, NULL);
if (likely(!IS_ERR(newfile))) {
^ permalink raw reply related
* Re: net: memory leak in socket
From: Dmitry Vyukov @ 2018-01-09 18:58 UTC (permalink / raw)
To: Al Viro
Cc: David Miller, netdev, LKML, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Eric Dumazet, Willem de Bruijn, syzkaller
In-Reply-To: <20180109185351.GE13338@ZenIV.linux.org.uk>
On Tue, Jan 9, 2018 at 7:53 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, Jan 09, 2018 at 07:39:50PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> syzkaller has hit the following memory leak on 4.15-rc7:
>>
>> unreferenced object 0xffff88002713fb20 (size 16):
>> comm "syz-executor3", pid 6576, jiffies 4295029354 (age 10.166s)
>> hex dump (first 16 bytes):
>> 69 6e 73 6d 6f 64 5f 74 00 00 d9 1c 00 88 ff ff insmod_t........
>> backtrace:
>> [<00000000da8d6b27>] kmemleak_alloc_recursive
>> include/linux/kmemleak.h:55 [inline]
>> [<00000000da8d6b27>] slab_post_alloc_hook mm/slab.h:440 [inline]
>> [<00000000da8d6b27>] slab_alloc_node mm/slub.c:2725 [inline]
>> [<00000000da8d6b27>] slab_alloc mm/slub.c:2733 [inline]
>> [<00000000da8d6b27>] __kmalloc_track_caller+0x183/0x310 mm/slub.c:4290
>> [<000000001aa62b7a>] kstrdup+0x39/0x70 mm/util.c:56
>> [<00000000fa6a957e>] security_netlbl_sid_to_secattr+0xbc/0x1a0
>> security/selinux/ss/services.c:3522
>> [<0000000054674134>] selinux_netlbl_sock_genattr+0xef/0x410
>> security/selinux/netlabel.c:94
>> [<000000002338a05c>] selinux_netlbl_socket_post_create+0x79/0x160
>> security/selinux/netlabel.c:341
>> [<0000000059825908>] selinux_socket_post_create+0x37f/0xa60
>> security/selinux/hooks.c:4399
>> [<00000000fff6c966>] security_socket_post_create+0x8b/0xd0
>> security/security.c:1344
>> [<000000005786c830>] __sock_create+0x758/0x920 net/socket.c:1281
>> [<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
>> [<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
>> [<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
>> [<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
>> [<00000000921bbbd9>] 0xffffffffffffffff
>>
>> unreferenced object 0xffff88007c3bba80 (size 992):
>> comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
>> hex dump (first 32 bytes):
>> 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
>> 40 2e 5a 2c 00 88 ff ff 00 00 00 00 00 00 00 00 @.Z,............
>> backtrace:
>> [<00000000ff3d837a>] kmemleak_alloc_recursive
>> include/linux/kmemleak.h:55 [inline]
>> [<00000000ff3d837a>] slab_post_alloc_hook mm/slab.h:440 [inline]
>> [<00000000ff3d837a>] slab_alloc_node mm/slub.c:2725 [inline]
>> [<00000000ff3d837a>] slab_alloc mm/slub.c:2733 [inline]
>> [<00000000ff3d837a>] kmem_cache_alloc+0x110/0x280 mm/slub.c:2738
>> [<00000000d243ce94>] sock_alloc_inode+0x70/0x300 net/socket.c:250
>> [<000000005a0b3852>] alloc_inode+0x65/0x190 fs/inode.c:208
>> [<000000004af29540>] new_inode_pseudo+0x69/0x1a0 fs/inode.c:890
>> [<0000000074cb6753>] sock_alloc+0x41/0x280 net/socket.c:569
>> [<00000000cc5c2e64>] __sock_create+0x161/0x920 net/socket.c:1229
>> [<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
>> [<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
>> [<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
>> [<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
>> [<00000000921bbbd9>] 0xffffffffffffffff
>>
>> unreferenced object 0xffff88002c5a2e40 (size 128):
>> comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
>> hex dump (first 32 bytes):
>> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
>> ff ff ff ff ff ff ff ff c0 da db 88 ff ff ff ff ................
>> backtrace:
>> [<00000000696a590c>] kmemleak_alloc_recursive
>> include/linux/kmemleak.h:55 [inline]
>> [<00000000696a590c>] slab_post_alloc_hook mm/slab.h:440 [inline]
>> [<00000000696a590c>] slab_alloc_node mm/slub.c:2725 [inline]
>> [<00000000696a590c>] slab_alloc mm/slub.c:2733 [inline]
>> [<00000000696a590c>] kmem_cache_alloc_trace+0x126/0x290 mm/slub.c:2750
>> [<00000000551c8f10>] kmalloc include/linux/slab.h:499 [inline]
>> [<00000000551c8f10>] sock_alloc_inode+0xb4/0x300 net/socket.c:253
>> [<000000005a0b3852>] alloc_inode+0x65/0x190 fs/inode.c:208
>> [<000000004af29540>] new_inode_pseudo+0x69/0x1a0 fs/inode.c:890
>> [<0000000074cb6753>] sock_alloc+0x41/0x280 net/socket.c:569
>> [<00000000cc5c2e64>] __sock_create+0x161/0x920 net/socket.c:1229
>> [<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
>> [<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
>> [<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
>> [<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
>> [<00000000921bbbd9>] 0xffffffffffffffff
>>
>> unreferenced object 0xffff88007310f680 (size 96):
>> comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
>> hex dump (first 32 bytes):
>> b0 ba 3b 7c 00 88 ff ff 88 f6 10 73 00 88 ff ff ..;|.......s....
>> 88 f6 10 73 00 88 ff ff dd 00 00 00 dd 00 00 00 ...s............
>> backtrace:
>> [<00000000ff3d837a>] kmemleak_alloc_recursive
>> include/linux/kmemleak.h:55 [inline]
>> [<00000000ff3d837a>] slab_post_alloc_hook mm/slab.h:440 [inline]
>> [<00000000ff3d837a>] slab_alloc_node mm/slub.c:2725 [inline]
>> [<00000000ff3d837a>] slab_alloc mm/slub.c:2733 [inline]
>> [<00000000ff3d837a>] kmem_cache_alloc+0x110/0x280 mm/slub.c:2738
>> [<00000000094ffa79>] kmem_cache_zalloc include/linux/slab.h:678 [inline]
>> [<00000000094ffa79>] inode_alloc_security
>> security/selinux/hooks.c:234 [inline]
>> [<00000000094ffa79>] selinux_inode_alloc_security+0xf9/0x390
>> security/selinux/hooks.c:2885
>> [<0000000082b97b6d>] security_inode_alloc+0x92/0xe0 security/security.c:437
>> [<000000009683bb60>] inode_init_always+0x64f/0xca0 fs/inode.c:167
>> [<00000000a71f5b21>] alloc_inode+0x82/0x190 fs/inode.c:215
>> [<000000004af29540>] new_inode_pseudo+0x69/0x1a0 fs/inode.c:890
>> [<0000000074cb6753>] sock_alloc+0x41/0x280 net/socket.c:569
>> [<00000000cc5c2e64>] __sock_create+0x161/0x920 net/socket.c:1229
>> [<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
>> [<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
>> [<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
>> [<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
>> [<00000000921bbbd9>] 0xffffffffffffffff
>>
>> unreferenced object 0xffff88007127bf00 (size 2528):
>> comm "syz-executor3", pid 6576, jiffies 4295029368 (age 10.153s)
>> hex dump (first 32 bytes):
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
>> backtrace:
>> [<00000000ff3d837a>] kmemleak_alloc_recursive
>> include/linux/kmemleak.h:55 [inline]
>> [<00000000ff3d837a>] slab_post_alloc_hook mm/slab.h:440 [inline]
>> [<00000000ff3d837a>] slab_alloc_node mm/slub.c:2725 [inline]
>> [<00000000ff3d837a>] slab_alloc mm/slub.c:2733 [inline]
>> [<00000000ff3d837a>] kmem_cache_alloc+0x110/0x280 mm/slub.c:2738
>> [<0000000021d2cae7>] sk_prot_alloc+0x69/0x2f0 net/core/sock.c:1463
>> [<0000000088be91b8>] sk_alloc+0x109/0x1740 net/core/sock.c:1523
>> [<00000000bbd7f0e5>] inet_create+0x4f8/0x10a0 net/ipv4/af_inet.c:319
>> [<00000000c0aa842f>] __sock_create+0x521/0x920 net/socket.c:1265
>> [<00000000e7afba0a>] sock_create net/socket.c:1305 [inline]
>> [<00000000e7afba0a>] SYSC_socket net/socket.c:1335 [inline]
>> [<00000000e7afba0a>] SyS_socket+0x102/0x1f0 net/socket.c:1315
>> [<000000007df77eb7>] entry_SYSCALL_64_fastpath+0x23/0x9a
>> [<00000000921bbbd9>] 0xffffffffffffffff
>>
>>
>>
>> Reproducer:
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include <sys/time.h>
>> #include <sys/resource.h>
>> #include <sys/types.h>
>> #include <sys/socket.h>
>> #include <sys/socket.h>
>> #include <netinet/in.h>
>> #include <arpa/inet.h>
>>
>> int main()
>> {
>> struct rlimit rlim;
>> rlim.rlim_cur = 0;
>> rlim.rlim_max = 0;
>> setrlimit(RLIMIT_NOFILE, &rlim);
>> socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
>> return 0;
>> }
>
> Argh... Got broken by "make sock_alloc_file() do sock_release() on failures" -
> cleanup after sock_map_fd() failure got pulled all the way into sock_alloc_file(),
> but it used to serve the case when sock_map_fd() failed *before* getting to
> sock_alloc_file().
>
> Fixes: commit 8e1611e23579 (make sock_alloc_file() do sock_release() on failures)
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Please add:
Reported-by: Dmitry Vyukov <dvyukov@google.com>
> ---
> diff --git a/net/socket.c b/net/socket.c
> index bbd2e9ceb692..1536515b6437 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -430,8 +430,10 @@ static int sock_map_fd(struct socket *sock, int flags)
> {
> struct file *newfile;
> int fd = get_unused_fd_flags(flags);
> - if (unlikely(fd < 0))
> + if (unlikely(fd < 0)) {
> + sock_release(sock);
> return fd;
> + }
>
> newfile = sock_alloc_file(sock, flags, NULL);
> if (likely(!IS_ERR(newfile))) {
^ permalink raw reply
* Re: Re: dvb usb issues since kernel 4.9
From: Linus Torvalds @ 2018-01-09 18:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Josef Griebichler, Jesper Dangaard Brouer, Peter Zijlstra,
Mauro Carvalho Chehab, Alan Stern, Greg Kroah-Hartman, USB list,
Rik van Riel, Paolo Abeni, Hannes Frederic Sowa, linux-kernel,
netdev, Jonathan Corbet, LMML, David Miller
In-Reply-To: <CANn89iLo9WsFq-cvL63zD6hOXFRs97hDifksNsAHTegNQqXzZw@mail.gmail.com>
On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet <edumazet@google.com> wrote:
>
> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate
> handling', but TCP Small queues heavily use TASKLET,
> so as far as I am concerned a revert would have the same effect.
Does it actually?
TCP ends up dropping packets outside of the window etc, so flooding a
machine with TCP packets and causing some further processing up the
stack sounds very different from the basic packet flooding thing that
happens with NET_RX_SOFTIRQ.
Also, honestly, the kinds of people who really worry about flooding
tend to have packet filtering in the receive path etc.
So I really think "you can use up 90% of CPU time with a UDP packet
flood from the same network" is very very very different - and
honestly not at all as important - as "you want to be able to use a
USB DVB receiver and watch/record TV".
Because that whole "UDP packet flood from the same network" really is
something you _fundamentally_ have other mitigations for.
I bet that whole commit was introduced because of a benchmark test,
rather than real life. No?
In contrast, now people are complaining about real loads not working.
Linus
^ permalink raw reply
* Build failure in -next due to 'xdp: generic XDP handling of xdp_rxq_info'
From: Guenter Roeck @ 2018-01-09 19:01 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexei Starovoitov, David S. Miller, netdev, linux-kernel
Hi,
commit e817f85652c ("xdp: generic XDP handling of xdp_rxq_info") results in
the following error when building m68k:m5208evb_defconfig in -next.
net/core/dev.c: In function 'netif_get_rxqueue':
net/core/dev.c:3926:15: error: 'struct net_device' has no member named '_rx'
net/core/dev.c:3931:28: error:
'struct net_device' has no member named 'real_num_rx_queues'
net/core/dev.c: In function 'netif_alloc_rx_queues':
net/core/dev.c:7633:29: error:
'struct net_device' has no member named 'num_rx_queues'
[ and so on ]
Reverting the commit fixes the problem. Bisect log is attached.
Guenter
---
# bad: [06d41862286aa7bc634a1dd9e6e7e96f925ef30a] Add linux-next specific files for 20180109
# good: [b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d] Linux 4.15-rc7
git bisect start 'HEAD' 'v4.15-rc7'
# bad: [9da4bdd3a63316ea34855132136f33c5b028a345] Merge remote-tracking branch 'crypto/master'
git bisect bad 9da4bdd3a63316ea34855132136f33c5b028a345
# good: [4367c00fe4237e51bbd365d89afca092de188906] Merge remote-tracking branch 'i2c/i2c/for-next'
git bisect good 4367c00fe4237e51bbd365d89afca092de188906
# bad: [f998b6b10144cd9809da6af02758615f789e8aa1] netfilter: ipset: Missing nfnl_lock()/nfnl_unlock() is added to ip_set_net_exit()
git bisect bad f998b6b10144cd9809da6af02758615f789e8aa1
# good: [918341e063028080bcd73d33540f77d9c1d20602] cxgb4: Report tid start range correctly for T6
git bisect good 918341e063028080bcd73d33540f77d9c1d20602
# good: [4f83435ad777358d9cdc138868feebbe2a23f577] nfp: bpf: allocate vNIC priv for keeping track of the offloaded program
git bisect good 4f83435ad777358d9cdc138868feebbe2a23f577
# good: [8a4816cad00bf14642f0ed6043b32d29a05006ce] tg3: Add Macronix NVRAM support
git bisect good 8a4816cad00bf14642f0ed6043b32d29a05006ce
# bad: [7f0b800048b562d716372466ea8d9de648c422dd] Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
git bisect bad 7f0b800048b562d716372466ea8d9de648c422dd
# good: [c90ecbfaf50d2d7db25c531d9169be7e47435f3f] rds: Use atomic flag to track connections being destroyed
git bisect good c90ecbfaf50d2d7db25c531d9169be7e47435f3f
# good: [0ddf543226acacfb9f521dafc6c817d5b04c7b1f] xdp/mlx5: setup xdp_rxq_info
git bisect good 0ddf543226acacfb9f521dafc6c817d5b04c7b1f
# bad: [e817f85652c14d78f170b18797e4c477c78949e0] xdp: generic XDP handling of xdp_rxq_info
git bisect bad e817f85652c14d78f170b18797e4c477c78949e0
# good: [96a8604f95fa216b9ddfd15c687eed42a2f56901] bnxt_en: setup xdp_rxq_info
git bisect good 96a8604f95fa216b9ddfd15c687eed42a2f56901
# good: [27e95e3648910c81a0840aa10dde77323795519e] thunderx: setup xdp_rxq_info
git bisect good 27e95e3648910c81a0840aa10dde77323795519e
# good: [754b8a21a96d5f11712245aef907149606b323ae] virtio_net: setup xdp_rxq_info
git bisect good 754b8a21a96d5f11712245aef907149606b323ae
# first bad commit: [e817f85652c14d78f170b18797e4c477c78949e0] xdp: generic XDP handling of xdp_rxq_info
^ permalink raw reply
* [net-next 00/13][pull request] 10GbE Intel Wired LAN Driver Updates 2018-01-09
From: Jeff Kirsher @ 2018-01-09 19:02 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates to ixgbe and ixgbevf only.
Emil fixes an issue with "wake on LAN"(WoL) where we need to ensure we
enable the reception of multicast packets so that WoL works for IPv6
magic packets. Cleaned up code no longer needed with the update to
adaptive ITR.
Paul update the driver to advertise the highest capable link speed
when a module gets inserted. Also extended the displaying of firmware
version to include the iSCSI and OEM block in the EEPROM to better
identify firmware versions/images.
Tonghao Zhang cleans up a code comment that no longer applies since
InterruptThrottleRate has been removed from the driver.
Alex fixes SR-IOV and MACVLAN offload interaction, where the MACVLAN
offload was incorrectly configuring several filters with the wrong
pool value which resulted in MACLVAN interfaces not being able to
receive traffic that had to pass over the physical interface. Fixed
transmit hangs and dropped receive frames when the number of VFs
changed. Added support for RSS on MACVLAN pools for X550 devices.
Fixed up the MACVLAN limitations so we can now support 63 offloaded
devices. Cleaned up MACVLAN code that is no longer needed with the
recent changes and fixes.
The following are changes since commit f4803f1b73f877a571be4c8e531dfcf190acc691:
net: tipc: remove unused hardirq.h
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 10GbE
Alexander Duyck (7):
ixgbe: Fix interaction between SR-IOV and macvlan offload
ixgbe: Perform reinit any time number of VFs change
ixgbe: Add support for macvlan offload RSS on X550 and clean-up pool
handling
ixgbe: There is no need to update num_rx_pools in L2 fwd offload
ixgbe: Fix limitations on macvlan so we can support up to 63 offloaded
devices
ixgbe: Use ring values to test for Tx pending
ixgbe: Drop l2_accel_priv data pointer from ring struct
Emil Tantilov (3):
ixgbe: enable multicast on shutdown for WOL
ixgbe: remove unused enum latency_range
ixgbevf: remove redundant setting of xcast_mode
Paul Greenwalt (2):
ixgbe: advertise highest capable link speed
ixgbe: extend firmware version support
Tonghao Zhang (1):
ixgbe: Remove an obsolete comment about ITR
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 10 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 112 +++++++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 6 +
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 7 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 7 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 11 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 233 +++++++++++-----------
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 46 ++---
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 39 ++++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 4 -
10 files changed, 298 insertions(+), 177 deletions(-)
--
2.15.1
^ permalink raw reply
* [net-next 02/13] ixgbe: remove unused enum latency_range
From: Jeff Kirsher @ 2018-01-09 19:02 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180109190233.15206-1-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
This enum is no longer needed after
commit: b4ded8327fe ("ixgbe: Update adaptive ITR algorithm")
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index b3a1a12712ac..43ca5b0d5999 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -2517,13 +2517,6 @@ static void ixgbe_configure_msix(struct ixgbe_adapter *adapter)
IXGBE_WRITE_REG(&adapter->hw, IXGBE_EIAC, mask);
}
-enum latency_range {
- lowest_latency = 0,
- low_latency = 1,
- bulk_latency = 2,
- latency_invalid = 255
-};
-
/**
* ixgbe_update_itr - update the dynamic ITR value based on statistics
* @q_vector: structure containing interrupt and ring information
--
2.15.1
^ permalink raw reply related
* [net-next 12/13] ixgbe: Use ring values to test for Tx pending
From: Jeff Kirsher @ 2018-01-09 19:02 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20180109190233.15206-1-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch simplifies the check for Tx pending traffic and makes it more
holistic as there being any difference between next_to_use and
next_to_clean is much more informative than if head and tail are equal, as
it is possible for us to either not update tail, or not be notified of
completed work in which case next_to_clean would not be equal to head.
In addition the simplification makes it so that we don't have to read
hardware which allows us to drop a number of variables that were previously
being used in the call.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 20 ++++----------------
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 144674c6c293..6b61edba8c73 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1064,24 +1064,12 @@ static u64 ixgbe_get_tx_completed(struct ixgbe_ring *ring)
static u64 ixgbe_get_tx_pending(struct ixgbe_ring *ring)
{
- struct ixgbe_adapter *adapter;
- struct ixgbe_hw *hw;
- u32 head, tail;
+ unsigned int head, tail;
- if (ring->l2_accel_priv)
- adapter = ring->l2_accel_priv->real_adapter;
- else
- adapter = netdev_priv(ring->netdev);
+ head = ring->next_to_clean;
+ tail = ring->next_to_use;
- hw = &adapter->hw;
- head = IXGBE_READ_REG(hw, IXGBE_TDH(ring->reg_idx));
- tail = IXGBE_READ_REG(hw, IXGBE_TDT(ring->reg_idx));
-
- if (head != tail)
- return (head < tail) ?
- tail - head : (tail + ring->count - head);
-
- return 0;
+ return ((head <= tail) ? tail : tail + ring->count) - head;
}
static inline bool ixgbe_check_tx_hang(struct ixgbe_ring *tx_ring)
--
2.15.1
^ permalink raw reply related
* [net-next 04/13] ixgbe: extend firmware version support
From: Jeff Kirsher @ 2018-01-09 19:02 UTC (permalink / raw)
To: davem; +Cc: Paul Greenwalt, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180109190233.15206-1-jeffrey.t.kirsher@intel.com>
From: Paul Greenwalt <paul.greenwalt@intel.com>
Extend FW version reporting by displaying information from the iSCSI
or OEM block in the EEPROM.
This will allow us to more accurately identify the FW.
Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 112 +++++++++++++++++++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 6 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 7 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 7 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 38 +++++++-
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 39 ++++++++
7 files changed, 198 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 8611763d6129..08fb589399d2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -723,8 +723,7 @@ struct ixgbe_adapter {
u16 bridge_mode;
- u16 eeprom_verh;
- u16 eeprom_verl;
+ char eeprom_id[NVM_VER_SIZE];
u16 eeprom_cap;
u32 interrupt_event;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 9bef255f6a18..1948e4208fb4 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -4028,6 +4028,118 @@ s32 ixgbe_init_thermal_sensor_thresh_generic(struct ixgbe_hw *hw)
return 0;
}
+/**
+ * ixgbe_get_orom_version - Return option ROM from EEPROM
+ *
+ * @hw: pointer to hardware structure
+ * @nvm_ver: pointer to output structure
+ *
+ * if valid option ROM version, nvm_ver->or_valid set to true
+ * else nvm_ver->or_valid is false.
+ **/
+void ixgbe_get_orom_version(struct ixgbe_hw *hw,
+ struct ixgbe_nvm_version *nvm_ver)
+{
+ u16 offset, eeprom_cfg_blkh, eeprom_cfg_blkl;
+
+ nvm_ver->or_valid = false;
+ /* Option Rom may or may not be present. Start with pointer */
+ hw->eeprom.ops.read(hw, NVM_OROM_OFFSET, &offset);
+
+ /* make sure offset is valid */
+ if (offset == 0x0 || offset == NVM_INVALID_PTR)
+ return;
+
+ hw->eeprom.ops.read(hw, offset + NVM_OROM_BLK_HI, &eeprom_cfg_blkh);
+ hw->eeprom.ops.read(hw, offset + NVM_OROM_BLK_LOW, &eeprom_cfg_blkl);
+
+ /* option rom exists and is valid */
+ if ((eeprom_cfg_blkl | eeprom_cfg_blkh) == 0x0 ||
+ eeprom_cfg_blkl == NVM_VER_INVALID ||
+ eeprom_cfg_blkh == NVM_VER_INVALID)
+ return;
+
+ nvm_ver->or_valid = true;
+ nvm_ver->or_major = eeprom_cfg_blkl >> NVM_OROM_SHIFT;
+ nvm_ver->or_build = (eeprom_cfg_blkl << NVM_OROM_SHIFT) |
+ (eeprom_cfg_blkh >> NVM_OROM_SHIFT);
+ nvm_ver->or_patch = eeprom_cfg_blkh & NVM_OROM_PATCH_MASK;
+}
+
+/**
+ * ixgbe_get_oem_prod_version Etrack ID from EEPROM
+ *
+ * @hw: pointer to hardware structure
+ * @nvm_ver: pointer to output structure
+ *
+ * if valid OEM product version, nvm_ver->oem_valid set to true
+ * else nvm_ver->oem_valid is false.
+ **/
+void ixgbe_get_oem_prod_version(struct ixgbe_hw *hw,
+ struct ixgbe_nvm_version *nvm_ver)
+{
+ u16 rel_num, prod_ver, mod_len, cap, offset;
+
+ nvm_ver->oem_valid = false;
+ hw->eeprom.ops.read(hw, NVM_OEM_PROD_VER_PTR, &offset);
+
+ /* Return is offset to OEM Product Version block is invalid */
+ if (offset == 0x0 && offset == NVM_INVALID_PTR)
+ return;
+
+ /* Read product version block */
+ hw->eeprom.ops.read(hw, offset, &mod_len);
+ hw->eeprom.ops.read(hw, offset + NVM_OEM_PROD_VER_CAP_OFF, &cap);
+
+ /* Return if OEM product version block is invalid */
+ if (mod_len != NVM_OEM_PROD_VER_MOD_LEN ||
+ (cap & NVM_OEM_PROD_VER_CAP_MASK) != 0x0)
+ return;
+
+ hw->eeprom.ops.read(hw, offset + NVM_OEM_PROD_VER_OFF_L, &prod_ver);
+ hw->eeprom.ops.read(hw, offset + NVM_OEM_PROD_VER_OFF_H, &rel_num);
+
+ /* Return if version is invalid */
+ if ((rel_num | prod_ver) == 0x0 ||
+ rel_num == NVM_VER_INVALID || prod_ver == NVM_VER_INVALID)
+ return;
+
+ nvm_ver->oem_major = prod_ver >> NVM_VER_SHIFT;
+ nvm_ver->oem_minor = prod_ver & NVM_VER_MASK;
+ nvm_ver->oem_release = rel_num;
+ nvm_ver->oem_valid = true;
+}
+
+/**
+ * ixgbe_get_etk_id - Return Etrack ID from EEPROM
+ *
+ * @hw: pointer to hardware structure
+ * @nvm_ver: pointer to output structure
+ *
+ * word read errors will return 0xFFFF
+ **/
+void ixgbe_get_etk_id(struct ixgbe_hw *hw,
+ struct ixgbe_nvm_version *nvm_ver)
+{
+ u16 etk_id_l, etk_id_h;
+
+ if (hw->eeprom.ops.read(hw, NVM_ETK_OFF_LOW, &etk_id_l))
+ etk_id_l = NVM_VER_INVALID;
+ if (hw->eeprom.ops.read(hw, NVM_ETK_OFF_HI, &etk_id_h))
+ etk_id_h = NVM_VER_INVALID;
+
+ /* The word order for the version format is determined by high order
+ * word bit 15.
+ */
+ if ((etk_id_h & NVM_ETK_VALID) == 0) {
+ nvm_ver->etk_id = etk_id_h;
+ nvm_ver->etk_id |= (etk_id_l << NVM_ETK_SHIFT);
+ } else {
+ nvm_ver->etk_id = etk_id_l;
+ nvm_ver->etk_id |= (etk_id_h << NVM_ETK_SHIFT);
+ }
+}
+
void ixgbe_disable_rx_generic(struct ixgbe_hw *hw)
{
u32 rxctrl;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
index a01409e2e06c..4d4c02366cb3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
@@ -139,6 +139,12 @@ extern const u32 ixgbe_mvals_8259X[IXGBE_MVALS_IDX_LIMIT];
s32 ixgbe_get_thermal_sensor_data_generic(struct ixgbe_hw *hw);
s32 ixgbe_init_thermal_sensor_thresh_generic(struct ixgbe_hw *hw);
+void ixgbe_get_etk_id(struct ixgbe_hw *hw,
+ struct ixgbe_nvm_version *nvm_ver);
+void ixgbe_get_oem_prod_version(struct ixgbe_hw *hw,
+ struct ixgbe_nvm_version *nvm_ver);
+void ixgbe_get_orom_version(struct ixgbe_hw *hw,
+ struct ixgbe_nvm_version *nvm_ver);
void ixgbe_disable_rx_generic(struct ixgbe_hw *hw);
void ixgbe_enable_rx_generic(struct ixgbe_hw *hw);
s32 ixgbe_setup_mac_link_multispeed_fiber(struct ixgbe_hw *hw,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 0aaf70b3cfcd..3bcf58b27d8b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -1014,16 +1014,13 @@ static void ixgbe_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
- u32 nvm_track_id;
strlcpy(drvinfo->driver, ixgbe_driver_name, sizeof(drvinfo->driver));
strlcpy(drvinfo->version, ixgbe_driver_version,
sizeof(drvinfo->version));
- nvm_track_id = (adapter->eeprom_verh << 16) |
- adapter->eeprom_verl;
- snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version), "0x%08x",
- nvm_track_id);
+ strlcpy(drvinfo->fw_version, adapter->eeprom_id,
+ sizeof(drvinfo->fw_version));
strlcpy(drvinfo->bus_info, pci_name(adapter->pdev),
sizeof(drvinfo->bus_info));
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
index a23c2b5411a0..6e6b3c175267 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
@@ -1034,11 +1034,8 @@ int ixgbe_fcoe_get_hbainfo(struct net_device *netdev,
ixgbe_driver_name,
ixgbe_driver_version);
/* Firmware Version */
- snprintf(info->firmware_version,
- sizeof(info->firmware_version),
- "0x%08x",
- (adapter->eeprom_verh << 16) |
- adapter->eeprom_verl);
+ strlcpy(info->firmware_version, adapter->eeprom_id,
+ sizeof(info->firmware_version));
/* Model */
if (hw->mac.type == ixgbe_mac_82599EB) {
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 07d929bf4b50..cfe02893c875 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -10234,6 +10234,41 @@ bool ixgbe_wol_supported(struct ixgbe_adapter *adapter, u16 device_id,
return false;
}
+/**
+ * ixgbe_set_fw_version - Set FW version
+ * @adapter: the adapter private structure
+ *
+ * This function is used by probe and ethtool to determine the FW version to
+ * format to display. The FW version is taken from the EEPROM/NVM.
+ */
+static void ixgbe_set_fw_version(struct ixgbe_adapter *adapter)
+{
+ struct ixgbe_hw *hw = &adapter->hw;
+ struct ixgbe_nvm_version nvm_ver;
+
+ ixgbe_get_oem_prod_version(hw, &nvm_ver);
+ if (nvm_ver.oem_valid) {
+ snprintf(adapter->eeprom_id, sizeof(adapter->eeprom_id),
+ "%x.%x.%x", nvm_ver.oem_major, nvm_ver.oem_minor,
+ nvm_ver.oem_release);
+ return;
+ }
+
+ ixgbe_get_etk_id(hw, &nvm_ver);
+ ixgbe_get_orom_version(hw, &nvm_ver);
+
+ if (nvm_ver.or_valid) {
+ snprintf(adapter->eeprom_id, sizeof(adapter->eeprom_id),
+ "0x%08x, %d.%d.%d", nvm_ver.etk_id, nvm_ver.or_major,
+ nvm_ver.or_build, nvm_ver.or_patch);
+ return;
+ }
+
+ /* Set ETrack ID format */
+ snprintf(adapter->eeprom_id, sizeof(adapter->eeprom_id),
+ "0x%08x", nvm_ver.etk_id);
+}
+
/**
* ixgbe_probe - Device Initialization Routine
* @pdev: PCI device information struct
@@ -10570,8 +10605,7 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
/* save off EEPROM version number */
- hw->eeprom.ops.read(hw, 0x2e, &adapter->eeprom_verh);
- hw->eeprom.ops.read(hw, 0x2d, &adapter->eeprom_verl);
+ ixgbe_set_fw_version(adapter);
/* pick up the PCI bus settings for reporting later */
if (ixgbe_pcie_from_parent(hw))
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index ffa0ee5cd0f5..21eb79ae3c30 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -235,6 +235,45 @@ struct ixgbe_thermal_sensor_data {
struct ixgbe_thermal_diode_data sensor[IXGBE_MAX_SENSORS];
};
+#define NVM_OROM_OFFSET 0x17
+#define NVM_OROM_BLK_LOW 0x83
+#define NVM_OROM_BLK_HI 0x84
+#define NVM_OROM_PATCH_MASK 0xFF
+#define NVM_OROM_SHIFT 8
+
+#define NVM_VER_MASK 0x00FF /* version mask */
+#define NVM_VER_SHIFT 8 /* version bit shift */
+#define NVM_OEM_PROD_VER_PTR 0x1B /* OEM Product version block pointer */
+#define NVM_OEM_PROD_VER_CAP_OFF 0x1 /* OEM Product version format offset */
+#define NVM_OEM_PROD_VER_OFF_L 0x2 /* OEM Product version offset low */
+#define NVM_OEM_PROD_VER_OFF_H 0x3 /* OEM Product version offset high */
+#define NVM_OEM_PROD_VER_CAP_MASK 0xF /* OEM Product version cap mask */
+#define NVM_OEM_PROD_VER_MOD_LEN 0x3 /* OEM Product version module length */
+#define NVM_ETK_OFF_LOW 0x2D /* version low order word */
+#define NVM_ETK_OFF_HI 0x2E /* version high order word */
+#define NVM_ETK_SHIFT 16 /* high version word shift */
+#define NVM_VER_INVALID 0xFFFF
+#define NVM_ETK_VALID 0x8000
+#define NVM_INVALID_PTR 0xFFFF
+#define NVM_VER_SIZE 32 /* version sting size */
+
+struct ixgbe_nvm_version {
+ u32 etk_id;
+ u8 nvm_major;
+ u16 nvm_minor;
+ u8 nvm_id;
+
+ bool oem_valid;
+ u8 oem_major;
+ u8 oem_minor;
+ u16 oem_release;
+
+ bool or_valid;
+ u8 or_major;
+ u16 or_build;
+ u8 or_patch;
+};
+
/* Interrupt Registers */
#define IXGBE_EICR 0x00800
#define IXGBE_EICS 0x00808
--
2.15.1
^ permalink raw reply related
* [net-next 03/13] ixgbe: advertise highest capable link speed
From: Jeff Kirsher @ 2018-01-09 19:02 UTC (permalink / raw)
To: davem; +Cc: Paul Greenwalt, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180109190233.15206-1-jeffrey.t.kirsher@intel.com>
From: Paul Greenwalt <paul.greenwalt@intel.com>
On module insert advertise highest capable link speed. If module is
capable of 10G, then advertise 10G, else advertise modules capable
link speeds.
Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 43ca5b0d5999..07d929bf4b50 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7656,6 +7656,7 @@ static void ixgbe_sfp_detection_subtask(struct ixgbe_adapter *adapter)
static void ixgbe_sfp_link_config_subtask(struct ixgbe_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
+ u32 cap_speed;
u32 speed;
bool autoneg = false;
@@ -7668,16 +7669,14 @@ static void ixgbe_sfp_link_config_subtask(struct ixgbe_adapter *adapter)
adapter->flags &= ~IXGBE_FLAG_NEED_LINK_CONFIG;
- speed = hw->phy.autoneg_advertised;
- if ((!speed) && (hw->mac.ops.get_link_capabilities)) {
- hw->mac.ops.get_link_capabilities(hw, &speed, &autoneg);
+ hw->mac.ops.get_link_capabilities(hw, &cap_speed, &autoneg);
- /* setup the highest link when no autoneg */
- if (!autoneg) {
- if (speed & IXGBE_LINK_SPEED_10GB_FULL)
- speed = IXGBE_LINK_SPEED_10GB_FULL;
- }
- }
+ /* advertise highest capable link speed */
+ if (!autoneg && (cap_speed & IXGBE_LINK_SPEED_10GB_FULL))
+ speed = IXGBE_LINK_SPEED_10GB_FULL;
+ else
+ speed = cap_speed & (IXGBE_LINK_SPEED_10GB_FULL |
+ IXGBE_LINK_SPEED_1GB_FULL);
if (hw->mac.ops.setup_link)
hw->mac.ops.setup_link(hw, speed, true);
--
2.15.1
^ permalink raw reply related
* [net-next 01/13] ixgbe: enable multicast on shutdown for WOL
From: Jeff Kirsher @ 2018-01-09 19:02 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180109190233.15206-1-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Previously we only enabled the reception of multicast packets when
wake on multicast is set, but we also need this to allow waking with
IPv6 magic packets.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 95aba975b391..b3a1a12712ac 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6791,7 +6791,7 @@ static int __ixgbe_shutdown(struct pci_dev *pdev, bool *enable_wake)
struct ixgbe_adapter *adapter = pci_get_drvdata(pdev);
struct net_device *netdev = adapter->netdev;
struct ixgbe_hw *hw = &adapter->hw;
- u32 ctrl, fctrl;
+ u32 ctrl;
u32 wufc = adapter->wol;
#ifdef CONFIG_PM
int retval = 0;
@@ -6816,18 +6816,18 @@ static int __ixgbe_shutdown(struct pci_dev *pdev, bool *enable_wake)
hw->mac.ops.stop_link_on_d3(hw);
if (wufc) {
+ u32 fctrl;
+
ixgbe_set_rx_mode(netdev);
/* enable the optics for 82599 SFP+ fiber as we can WoL */
if (hw->mac.ops.enable_tx_laser)
hw->mac.ops.enable_tx_laser(hw);
- /* turn on all-multi mode if wake on multicast is enabled */
- if (wufc & IXGBE_WUFC_MC) {
- fctrl = IXGBE_READ_REG(hw, IXGBE_FCTRL);
- fctrl |= IXGBE_FCTRL_MPE;
- IXGBE_WRITE_REG(hw, IXGBE_FCTRL, fctrl);
- }
+ /* enable the reception of multicast packets */
+ fctrl = IXGBE_READ_REG(hw, IXGBE_FCTRL);
+ fctrl |= IXGBE_FCTRL_MPE;
+ IXGBE_WRITE_REG(hw, IXGBE_FCTRL, fctrl);
ctrl = IXGBE_READ_REG(hw, IXGBE_CTRL);
ctrl |= IXGBE_CTRL_GIO_DIS;
--
2.15.1
^ permalink raw reply related
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