* [PATCH net] ipvlan: fix crash
From: Mahesh Bandewar @ 2016-12-18 2:16 UTC (permalink / raw)
To: netdev, Eric Dumazet, David Miller; +Cc: Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
------------[ cut here ]------------
kernel BUG at include/linux/skbuff.h:1737!
Call Trace:
[<ffffffff921fbbc2>] dev_forward_skb+0x92/0xd0
[<ffffffffc031ac65>] ipvlan_process_multicast+0x395/0x4c0 [ipvlan]
[<ffffffffc031a9a7>] ? ipvlan_process_multicast+0xd7/0x4c0 [ipvlan]
[<ffffffff91cdfea7>] ? process_one_work+0x147/0x660
[<ffffffff91cdff09>] process_one_work+0x1a9/0x660
[<ffffffff91cdfea7>] ? process_one_work+0x147/0x660
[<ffffffff91ce086d>] worker_thread+0x11d/0x360
[<ffffffff91ce0750>] ? rescuer_thread+0x350/0x350
[<ffffffff91ce960b>] kthread+0xdb/0xe0
[<ffffffff91c05c70>] ? _raw_spin_unlock_irq+0x30/0x50
[<ffffffff91ce9530>] ? flush_kthread_worker+0xc0/0xc0
[<ffffffff92348b7a>] ret_from_fork+0x9a/0xd0
[<ffffffff91ce9530>] ? flush_kthread_worker+0xc0/0xc0
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/ipvlan/ipvlan_core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
index b4e990743e1d..4294fc1f5564 100644
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -660,6 +660,9 @@ rx_handler_result_t ipvlan_handle_frame(struct sk_buff **pskb)
if (!port)
return RX_HANDLER_PASS;
+ if (unlikely(!pskb_may_pull(skb, sizeof(struct ethhdr))))
+ goto out;
+
switch (port->mode) {
case IPVLAN_MODE_L2:
return ipvlan_handle_mode_l2(pskb, port);
@@ -672,6 +675,8 @@ rx_handler_result_t ipvlan_handle_frame(struct sk_buff **pskb)
/* Should not reach here */
WARN_ONCE(true, "ipvlan_handle_frame() called for mode = [%hx]\n",
port->mode);
+
+out:
kfree_skb(skb);
return RX_HANDLER_CONSUMED;
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH net v2 3/3] bpf: fix mark_reg_unknown_value for spilled regs on map value marking
From: Daniel Borkmann @ 2016-12-18 0:52 UTC (permalink / raw)
To: davem; +Cc: ast, kafai, netdev, Daniel Borkmann
In-Reply-To: <cover.1482019225.git.daniel@iogearbox.net>
Martin reported a verifier issue that hit the BUG_ON() for his
test case in the mark_reg_unknown_value() function:
[ 202.861380] kernel BUG at kernel/bpf/verifier.c:467!
[...]
[ 203.291109] Call Trace:
[ 203.296501] [<ffffffff811364d5>] mark_map_reg+0x45/0x50
[ 203.308225] [<ffffffff81136558>] mark_map_regs+0x78/0x90
[ 203.320140] [<ffffffff8113938d>] do_check+0x226d/0x2c90
[ 203.331865] [<ffffffff8113a6ab>] bpf_check+0x48b/0x780
[ 203.343403] [<ffffffff81134c8e>] bpf_prog_load+0x27e/0x440
[ 203.355705] [<ffffffff8118a38f>] ? handle_mm_fault+0x11af/0x1230
[ 203.369158] [<ffffffff812d8188>] ? security_capable+0x48/0x60
[ 203.382035] [<ffffffff811351a4>] SyS_bpf+0x124/0x960
[ 203.393185] [<ffffffff810515f6>] ? __do_page_fault+0x276/0x490
[ 203.406258] [<ffffffff816db320>] entry_SYSCALL_64_fastpath+0x13/0x94
This issue got uncovered after the fix in a08dd0da5307 ("bpf: fix
regression on verifier pruning wrt map lookups"). The reason why it
wasn't noticed before was, because as mentioned in a08dd0da5307,
mark_map_regs() was doing the id matching incorrectly based on the
uncached regs[regno].id. So, in the first loop, we walked all regs
and as soon as we found regno == i, then this reg's id was cleared
when calling mark_reg_unknown_value() thus that every subsequent
register was probed against id of 0 (which, in combination with the
PTR_TO_MAP_VALUE_OR_NULL type is an invalid condition that no other
register state can hold), and therefore wasn't type transitioned such
as in the spilled register case for the second loop.
Now since that got fixed, it turned out that 57a09bf0a416 ("bpf:
Detect identical PTR_TO_MAP_VALUE_OR_NULL registers") used
mark_reg_unknown_value() incorrectly for the spilled regs, and thus
hitting the BUG_ON() in some cases due to regno >= MAX_BPF_REG.
Although spilled regs have the same type as the non-spilled regs
for the verifier state, that is, struct bpf_reg_state, they are
semantically different from the non-spilled regs. In other words,
there can be up to 64 (MAX_BPF_STACK / BPF_REG_SIZE) spilled regs
in the stack, for example, register R<x> could have been spilled by
the program to stack location X, Y, Z, and in mark_map_regs() we
need to scan these stack slots of type STACK_SPILL for potential
registers that we have to transition from PTR_TO_MAP_VALUE_OR_NULL.
Therefore, depending on the location, the spilled_regs regno can
be a lot higher than just MAX_BPF_REG's value since we operate on
stack instead. The reset in mark_reg_unknown_value() itself is
just fine, only that the BUG_ON() was inappropriate for this. Fix
it by making a __mark_reg_unknown_value() version that can be
called from mark_map_reg() generically; we know for the non-spilled
case that the regno is always < MAX_BPF_REG anyway.
Fixes: 57a09bf0a416 ("bpf: Detect identical PTR_TO_MAP_VALUE_OR_NULL registers")
Reported-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/verifier.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 64b7b1a..83ed2f8 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -462,14 +462,19 @@ static void init_reg_state(struct bpf_reg_state *regs)
regs[BPF_REG_1].type = PTR_TO_CTX;
}
-static void mark_reg_unknown_value(struct bpf_reg_state *regs, u32 regno)
+static void __mark_reg_unknown_value(struct bpf_reg_state *regs, u32 regno)
{
- BUG_ON(regno >= MAX_BPF_REG);
regs[regno].type = UNKNOWN_VALUE;
regs[regno].id = 0;
regs[regno].imm = 0;
}
+static void mark_reg_unknown_value(struct bpf_reg_state *regs, u32 regno)
+{
+ BUG_ON(regno >= MAX_BPF_REG);
+ __mark_reg_unknown_value(regs, regno);
+}
+
static void reset_reg_range_values(struct bpf_reg_state *regs, u32 regno)
{
regs[regno].min_value = BPF_REGISTER_MIN_RANGE;
@@ -1976,7 +1981,7 @@ static void mark_map_reg(struct bpf_reg_state *regs, u32 regno, u32 id,
*/
reg->id = 0;
if (type == UNKNOWN_VALUE)
- mark_reg_unknown_value(regs, regno);
+ __mark_reg_unknown_value(regs, regno);
}
}
--
1.9.3
^ permalink raw reply related
* [PATCH net v2 2/3] bpf: fix overflow in prog accounting
From: Daniel Borkmann @ 2016-12-18 0:52 UTC (permalink / raw)
To: davem; +Cc: ast, kafai, netdev, Daniel Borkmann
In-Reply-To: <cover.1482019225.git.daniel@iogearbox.net>
Commit aaac3ba95e4c ("bpf: charge user for creation of BPF maps and
programs") made a wrong assumption of charging against prog->pages.
Unlike map->pages, prog->pages are still subject to change when we
need to expand the program through bpf_prog_realloc().
This can for example happen during verification stage when we need to
expand and rewrite parts of the program. Should the required space
cross a page boundary, then prog->pages is not the same anymore as
its original value that we used to bpf_prog_charge_memlock() on. Thus,
we'll hit a wrap-around during bpf_prog_uncharge_memlock() when prog
is freed eventually. I noticed this that despite having unlimited
memlock, programs suddenly refused to load with EPERM error due to
insufficient memlock.
There are two ways to fix this issue. One would be to add a cached
variable to struct bpf_prog that takes a snapshot of prog->pages at the
time of charging. The other approach is to also account for resizes. I
chose to go with the latter for a couple of reasons: i) We want accounting
rather to be more accurate instead of further fooling limits, ii) adding
yet another page counter on struct bpf_prog would also be a waste just
for this purpose. We also do want to charge as early as possible to
avoid going into the verifier just to find out later on that we crossed
limits. The only place that needs to be fixed is bpf_prog_realloc(),
since only here we expand the program, so we try to account for the
needed delta and should we fail, call-sites check for outcome anyway.
On cBPF to eBPF migrations, we don't grab a reference to the user as
they are charged differently. With that in place, my test case worked
fine.
Fixes: aaac3ba95e4c ("bpf: charge user for creation of BPF maps and programs")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
include/linux/bpf.h | 11 +++++++++++
kernel/bpf/core.c | 16 +++++++++++++---
kernel/bpf/syscall.c | 36 ++++++++++++++++++++++++++++--------
3 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 201eb48..f74ae68 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -238,6 +238,8 @@ u64 bpf_event_output(struct bpf_map *map, u64 flags, void *meta, u64 meta_size,
void bpf_prog_sub(struct bpf_prog *prog, int i);
struct bpf_prog * __must_check bpf_prog_inc(struct bpf_prog *prog);
void bpf_prog_put(struct bpf_prog *prog);
+int __bpf_prog_charge(struct user_struct *user, u32 pages);
+void __bpf_prog_uncharge(struct user_struct *user, u32 pages);
struct bpf_map *bpf_map_get_with_uref(u32 ufd);
struct bpf_map *__bpf_map_get(struct fd f);
@@ -318,6 +320,15 @@ static inline struct bpf_prog * __must_check bpf_prog_inc(struct bpf_prog *prog)
{
return ERR_PTR(-EOPNOTSUPP);
}
+
+static inline int __bpf_prog_charge(struct user_struct *user, u32 pages)
+{
+ return 0;
+}
+
+static inline void __bpf_prog_uncharge(struct user_struct *user, u32 pages)
+{
+}
#endif /* CONFIG_BPF_SYSCALL */
/* verifier prototypes for helper functions called from eBPF programs */
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 75c08b8..1eb4f13 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -105,19 +105,29 @@ struct bpf_prog *bpf_prog_realloc(struct bpf_prog *fp_old, unsigned int size,
gfp_t gfp_flags = GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO |
gfp_extra_flags;
struct bpf_prog *fp;
+ u32 pages, delta;
+ int ret;
BUG_ON(fp_old == NULL);
size = round_up(size, PAGE_SIZE);
- if (size <= fp_old->pages * PAGE_SIZE)
+ pages = size / PAGE_SIZE;
+ if (pages <= fp_old->pages)
return fp_old;
+ delta = pages - fp_old->pages;
+ ret = __bpf_prog_charge(fp_old->aux->user, delta);
+ if (ret)
+ return NULL;
+
fp = __vmalloc(size, gfp_flags, PAGE_KERNEL);
- if (fp != NULL) {
+ if (fp == NULL) {
+ __bpf_prog_uncharge(fp_old->aux->user, delta);
+ } else {
kmemcheck_annotate_bitfield(fp, meta);
memcpy(fp, fp_old, fp_old->pages * PAGE_SIZE);
- fp->pages = size / PAGE_SIZE;
+ fp->pages = pages;
fp->aux->prog = fp;
/* We keep fp->aux from fp_old around in the new
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 35d674c..e89acea 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -615,19 +615,39 @@ static void free_used_maps(struct bpf_prog_aux *aux)
kfree(aux->used_maps);
}
+int __bpf_prog_charge(struct user_struct *user, u32 pages)
+{
+ unsigned long memlock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+ unsigned long user_bufs;
+
+ if (user) {
+ user_bufs = atomic_long_add_return(pages, &user->locked_vm);
+ if (user_bufs > memlock_limit) {
+ atomic_long_sub(pages, &user->locked_vm);
+ return -EPERM;
+ }
+ }
+
+ return 0;
+}
+
+void __bpf_prog_uncharge(struct user_struct *user, u32 pages)
+{
+ if (user)
+ atomic_long_sub(pages, &user->locked_vm);
+}
+
static int bpf_prog_charge_memlock(struct bpf_prog *prog)
{
struct user_struct *user = get_current_user();
- unsigned long memlock_limit;
-
- memlock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+ int ret;
- atomic_long_add(prog->pages, &user->locked_vm);
- if (atomic_long_read(&user->locked_vm) > memlock_limit) {
- atomic_long_sub(prog->pages, &user->locked_vm);
+ ret = __bpf_prog_charge(user, prog->pages);
+ if (ret) {
free_uid(user);
- return -EPERM;
+ return ret;
}
+
prog->aux->user = user;
return 0;
}
@@ -636,7 +656,7 @@ static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)
{
struct user_struct *user = prog->aux->user;
- atomic_long_sub(prog->pages, &user->locked_vm);
+ __bpf_prog_uncharge(user, prog->pages);
free_uid(user);
}
--
1.9.3
^ permalink raw reply related
* [PATCH net v2 1/3] bpf: dynamically allocate digest scratch buffer
From: Daniel Borkmann @ 2016-12-18 0:52 UTC (permalink / raw)
To: davem; +Cc: ast, kafai, netdev, Daniel Borkmann
In-Reply-To: <cover.1482019225.git.daniel@iogearbox.net>
Geert rightfully complained that 7bd509e311f4 ("bpf: add prog_digest
and expose it via fdinfo/netlink") added a too large allocation of
variable 'raw' from bss section, and should instead be done dynamically:
# ./scripts/bloat-o-meter kernel/bpf/core.o.1 kernel/bpf/core.o.2
add/remove: 3/0 grow/shrink: 0/0 up/down: 33291/0 (33291)
function old new delta
raw - 32832 +32832
[...]
Since this is only relevant during program creation path, which can be
considered slow-path anyway, lets allocate that dynamically and be not
implicitly dependent on verifier mutex. Move bpf_prog_calc_digest() at
the beginning of replace_map_fd_with_map_ptr() and also error handling
stays straight forward.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
include/linux/bpf.h | 2 +-
include/linux/filter.h | 14 +++++++++++---
kernel/bpf/core.c | 27 ++++++++++++++++-----------
kernel/bpf/syscall.c | 2 +-
kernel/bpf/verifier.c | 6 ++++--
5 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 8796ff0..201eb48 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -216,7 +216,7 @@ struct bpf_event_entry {
u64 bpf_get_stackid(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5);
bool bpf_prog_array_compatible(struct bpf_array *array, const struct bpf_prog *fp);
-void bpf_prog_calc_digest(struct bpf_prog *fp);
+int bpf_prog_calc_digest(struct bpf_prog *fp);
const struct bpf_func_proto *bpf_get_trace_printk_proto(void);
diff --git a/include/linux/filter.h b/include/linux/filter.h
index af8a180..7023142 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -57,9 +57,6 @@
/* BPF program can access up to 512 bytes of stack space. */
#define MAX_BPF_STACK 512
-/* Maximum BPF program size in bytes. */
-#define MAX_BPF_SIZE (BPF_MAXINSNS * sizeof(struct bpf_insn))
-
/* Helper macros for filter block array initializers. */
/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
@@ -517,6 +514,17 @@ static __always_inline u32 bpf_prog_run_xdp(const struct bpf_prog *prog,
return BPF_PROG_RUN(prog, xdp);
}
+static inline u32 bpf_prog_insn_size(const struct bpf_prog *prog)
+{
+ return prog->len * sizeof(struct bpf_insn);
+}
+
+static inline u32 bpf_prog_digest_scratch_size(const struct bpf_prog *prog)
+{
+ return round_up(bpf_prog_insn_size(prog) +
+ sizeof(__be64) + 1, SHA_MESSAGE_BYTES);
+}
+
static inline unsigned int bpf_prog_size(unsigned int proglen)
{
return max(sizeof(struct bpf_prog),
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 83e0d15..75c08b8 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -136,28 +136,29 @@ void __bpf_prog_free(struct bpf_prog *fp)
vfree(fp);
}
-#define SHA_BPF_RAW_SIZE \
- round_up(MAX_BPF_SIZE + sizeof(__be64) + 1, SHA_MESSAGE_BYTES)
-
-/* Called under verifier mutex. */
-void bpf_prog_calc_digest(struct bpf_prog *fp)
+int bpf_prog_calc_digest(struct bpf_prog *fp)
{
const u32 bits_offset = SHA_MESSAGE_BYTES - sizeof(__be64);
- static u32 ws[SHA_WORKSPACE_WORDS];
- static u8 raw[SHA_BPF_RAW_SIZE];
- struct bpf_insn *dst = (void *)raw;
+ u32 raw_size = bpf_prog_digest_scratch_size(fp);
+ u32 ws[SHA_WORKSPACE_WORDS];
u32 i, bsize, psize, blocks;
+ struct bpf_insn *dst;
bool was_ld_map;
- u8 *todo = raw;
+ u8 *raw, *todo;
__be32 *result;
__be64 *bits;
+ raw = vmalloc(raw_size);
+ if (!raw)
+ return -ENOMEM;
+
sha_init(fp->digest);
memset(ws, 0, sizeof(ws));
/* We need to take out the map fd for the digest calculation
* since they are unstable from user space side.
*/
+ dst = (void *)raw;
for (i = 0, was_ld_map = false; i < fp->len; i++) {
dst[i] = fp->insnsi[i];
if (!was_ld_map &&
@@ -177,12 +178,13 @@ void bpf_prog_calc_digest(struct bpf_prog *fp)
}
}
- psize = fp->len * sizeof(struct bpf_insn);
- memset(&raw[psize], 0, sizeof(raw) - psize);
+ psize = bpf_prog_insn_size(fp);
+ memset(&raw[psize], 0, raw_size - psize);
raw[psize++] = 0x80;
bsize = round_up(psize, SHA_MESSAGE_BYTES);
blocks = bsize / SHA_MESSAGE_BYTES;
+ todo = raw;
if (bsize - psize >= sizeof(__be64)) {
bits = (__be64 *)(todo + bsize - sizeof(__be64));
} else {
@@ -199,6 +201,9 @@ void bpf_prog_calc_digest(struct bpf_prog *fp)
result = (__force __be32 *)fp->digest;
for (i = 0; i < SHA_DIGEST_WORDS; i++)
result[i] = cpu_to_be32(fp->digest[i]);
+
+ vfree(raw);
+ return 0;
}
static bool bpf_is_jmp_and_has_target(const struct bpf_insn *insn)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 4819ec9..35d674c 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -811,7 +811,7 @@ static int bpf_prog_load(union bpf_attr *attr)
err = -EFAULT;
if (copy_from_user(prog->insns, u64_to_user_ptr(attr->insns),
- prog->len * sizeof(struct bpf_insn)) != 0)
+ bpf_prog_insn_size(prog)) != 0)
goto free_prog;
prog->orig_prog = NULL;
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 81e267b..64b7b1a 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2931,6 +2931,10 @@ static int replace_map_fd_with_map_ptr(struct bpf_verifier_env *env)
int insn_cnt = env->prog->len;
int i, j, err;
+ err = bpf_prog_calc_digest(env->prog);
+ if (err)
+ return err;
+
for (i = 0; i < insn_cnt; i++, insn++) {
if (BPF_CLASS(insn->code) == BPF_LDX &&
(BPF_MODE(insn->code) != BPF_MEM || insn->imm != 0)) {
@@ -3178,8 +3182,6 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr)
log_level = 0;
}
- bpf_prog_calc_digest(env->prog);
-
ret = replace_map_fd_with_map_ptr(env);
if (ret < 0)
goto skip_full_check;
--
1.9.3
^ permalink raw reply related
* [PATCH net v2 0/3] Couple of BPF fixes
From: Daniel Borkmann @ 2016-12-18 0:52 UTC (permalink / raw)
To: davem; +Cc: ast, kafai, netdev, Daniel Borkmann
This set contains three BPF fixes for net, one that addresses the
complaint from Geert wrt static allocations, and the other is a fix
wrt mem accounting that I found recently during testing and there's
still one more fix on the map value marking.
Thanks!
v1 -> v2:
- Patch 1 as is.
- Fixed kbuild bot issue by letting charging helpers stay in the
syscall.c, since there locked_vm is valid and only export the
ones needed by bpf_prog_realloc(). Add empty stubs in case the
bpf syscall is not enabled.
- Added patch 3 that addresses one more issue in map val marking.
Daniel Borkmann (3):
bpf: dynamically allocate digest scratch buffer
bpf: fix overflow in prog accounting
bpf: fix mark_reg_unknown_value for spilled regs on map value marking
include/linux/bpf.h | 13 ++++++++++++-
include/linux/filter.h | 14 +++++++++++---
kernel/bpf/core.c | 43 +++++++++++++++++++++++++++++--------------
kernel/bpf/syscall.c | 38 +++++++++++++++++++++++++++++---------
kernel/bpf/verifier.c | 17 ++++++++++++-----
5 files changed, 93 insertions(+), 32 deletions(-)
--
1.9.3
^ permalink raw reply
* Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock
From: Francois Romieu @ 2016-12-18 0:15 UTC (permalink / raw)
To: Pavel Machek
Cc: Lino Sanfilippo, bh74.an, ks.giri, vipul.pandya, peppe.cavallaro,
alexandre.torgue, davem, linux-kernel, netdev
In-Reply-To: <20161217173150.GA20231@amd>
Pavel Machek <pavel@ucw.cz> :
[...]
> Won't this up/down the interface, in a way userspace can observe?
It won't up/down the interface as it doesn't exactly mimic what the
network code does (there's more than rtnl_lock).
For the same reason it's broken if it races with the transmit path: it
can release driver resources while the transmit path uses these.
Btw the points below may not matter/hurt much for a proof a concept
but they would need to be addressed as well:
1) unchecked (and avoidable) extra error paths due to stmmac_release()
2) racy cancel_work_sync. Low probability as it is, an irq + error could
take place right after cancel_work_sync
Lino, have you considered via-rhine.c since its "move work from irq to
workqueue context" changes that started in
7ab87ff4c770eed71e3777936299292739fcd0fe [*] ?
It's a shameless plug - originated in r8169.c - but it should be rather
close to what the sxgbe and friends require. Thought / opinion ?
[*] Including fixes/changes in:
- 3a5a883a8a663b930908cae4abe5ec913b9b2fd2
- e1efa87241272104d6a12c8b9fcdc4f62634d447
- 810f19bcb862f8889b27e0c9d9eceac9593925dd
- e45af497950a89459a0c4b13ffd91e1729fffef4
- a926592f5e4e900f3fa903298c4619a131e60963
- 559bcac35facfed49ab4f408e162971612dcfdf3
--
Ueimor
^ permalink raw reply
* Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function
From: Christian Kujau @ 2016-12-18 0:06 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Tom Herbert, Netdev, kernel-hardening, LKML,
Linux Crypto Mailing List, Jean-Philippe Aumasson,
Daniel J . Bernstein, Linus Torvalds, Eric Biggers, David Laight
In-Reply-To: <CAHmME9qNcsXtdWO_rmngSXXeBsTbA9B_33oLJ_pWOWcO7P2JZg@mail.gmail.com>
On Thu, 15 Dec 2016, Jason A. Donenfeld wrote:
> > I'd still drop the "24" unless you really think we're going to have
> > multiple variants coming into the kernel.
>
> Okay. I don't have a problem with this, unless anybody has some reason
> to the contrary.
What if the 2/4-round version falls and we need more rounds to withstand
future cryptoanalysis? We'd then have siphash_ and siphash48_ functions,
no? My amateurish bike-shedding argument would be "let's keep the 24 then" :-)
C.
--
BOFH excuse #354:
Chewing gum on /dev/sd3c
^ permalink raw reply
* [PATCH] net: wireless: marvell: libertas: constify cfg80211_ops structures
From: Bhumika Goyal @ 2016-12-17 22:57 UTC (permalink / raw)
To: julia.lawall, kvalo, libertas-dev, linux-wireless, netdev,
linux-kernel
Cc: Bhumika Goyal
cfg80211_ops structures are only passed as an argument to the function
wiphy_new. This argument is of type const, so cfg80211_ops strutures
having this property can be declared as const.
Done using Coccinelle
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct cfg80211_ops i@p = {...};
@ok1@
identifier r1.i;
position p;
@@
wiphy_new(&i@p,...)
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct cfg80211_ops i;
File size before:
text data bss dec hex filename
21225 1954 16 23195 5a9b wireless/marvell/libertas/cfg.o
File size after:
text data bss dec hex filename
22041 1154 16 23211 5aab wireless/marvell/libertas/cfg.o
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/wireless/marvell/libertas/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas/cfg.c b/drivers/net/wireless/marvell/libertas/cfg.c
index 7ff2efa..3f97acb 100644
--- a/drivers/net/wireless/marvell/libertas/cfg.c
+++ b/drivers/net/wireless/marvell/libertas/cfg.c
@@ -2086,7 +2086,7 @@ static int lbs_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
* Initialization
*/
-static struct cfg80211_ops lbs_cfg80211_ops = {
+static const struct cfg80211_ops lbs_cfg80211_ops = {
.set_monitor_channel = lbs_cfg_set_monitor_channel,
.libertas_set_mesh_channel = lbs_cfg_set_mesh_channel,
.scan = lbs_cfg_scan,
--
1.9.1
^ permalink raw reply related
* [PATCH] net: wireless: ath: wil6210: constify cfg80211_ops structures
From: Bhumika Goyal @ 2016-12-17 22:44 UTC (permalink / raw)
To: julia.lawall, qca_merez, kvalo, linux-wireless, wil6210, netdev,
linux-kernel
Cc: Bhumika Goyal
cfg80211_ops structures are only passed as an argument to the function
wiphy_new. This argument is of type const, so cfg80211_ops strutures
having this property can be declared as const.
Done using Coccinelle
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct cfg80211_ops i@p = {...};
@ok1@
identifier r1.i;
position p;
@@
wiphy_new(&i@p,...)
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct cfg80211_ops i;
File size before:
text data bss dec hex filename
18133 6632 0 24765 60bd wireless/ath/wil6210/cfg80211.o
File size after:
text data bss dec hex filename
18933 5832 0 24765 60bd wireless/ath/wil6210/cfg80211.o
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/wireless/ath/wil6210/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 6aa3ff4..54dd116 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -1499,7 +1499,7 @@ static int wil_cfg80211_set_power_mgmt(struct wiphy *wiphy,
return rc;
}
-static struct cfg80211_ops wil_cfg80211_ops = {
+static const struct cfg80211_ops wil_cfg80211_ops = {
.add_virtual_intf = wil_cfg80211_add_iface,
.del_virtual_intf = wil_cfg80211_del_iface,
.scan = wil_cfg80211_scan,
--
1.9.1
^ permalink raw reply related
* Re: [PATCHv2 2/5] sh_eth: enable wake-on-lan for Gen2 devices
From: Sergei Shtylyov @ 2016-12-17 21:52 UTC (permalink / raw)
To: Niklas Söderlund, Simon Horman, netdev, linux-renesas-soc
Cc: Geert Uytterhoeven
In-Reply-To: <eeff27f9-25eb-a981-33a9-15aa98ce9db1@cogentembedded.com>
On 12/14/2016 04:37 PM, Sergei Shtylyov wrote:
>> Tested on Gen2 r8a7791/Koelsch.
>>
>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>> ---
>> drivers/net/ethernet/renesas/sh_eth.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c
>> b/drivers/net/ethernet/renesas/sh_eth.c
>> index 87640b9..348ed22 100644
>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>> @@ -624,8 +624,9 @@ static struct sh_eth_cpu_data r8a779x_data = {
>>
>> .register_type = SH_ETH_REG_FAST_RCAR,
>>
>> - .ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD,
>> - .ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP,
>> + .ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD | ECSR_MPD,
>> + .ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP |
>> + ECSIPR_MPDIP,
>
> These expressions seem to have been sorted by the bit # before your patch,
> now they aren't... care to fix? :-)
After looking at the SH7743/64 code, nevermind this request. Sorry. :-)
MBR, Sergei
^ permalink raw reply
* Re: [PATCHv2 1/5] sh_eth: add generic wake-on-lan support via magic packet
From: Sergei Shtylyov @ 2016-12-17 21:50 UTC (permalink / raw)
To: Niklas Söderlund, Simon Horman, netdev, linux-renesas-soc
Cc: Geert Uytterhoeven
In-Reply-To: <20161212160931.6478-2-niklas.soderlund+renesas@ragnatech.se>
Hello!
On 12/12/2016 07:09 PM, Niklas Söderlund wrote:
Not the complete review yet, just some superficial comments.
> Add generic functionality to support Wake-on-Lan using MagicPacket which
LAN.
> are supported by at least a few versions of sh_eth. Only add
> functionality for WoL, no specific sh_eth version are marked to support
> WoL yet.
[...]
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index 05b0dc5..87640b9 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
[...]
> @@ -3150,15 +3187,67 @@ static int sh_eth_drv_remove(struct platform_device *pdev)
[...]
> +static int sh_eth_wol_restore(struct net_device *ndev)
> +{
> + struct sh_eth_private *mdp = netdev_priv(ndev);
> + int ret;
> +
> + napi_enable(&mdp->napi);
> +
> + /* Disable MagicPacket */
> + sh_eth_modify(ndev, ECMR, ECMR_PMDE, 0);
> +
> + /* The device need to be reset to restore MagicPacket logic
Needs.
[...]
> index d050f37..4ceed00 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.h
> +++ b/drivers/net/ethernet/renesas/sh_eth.h
> @@ -493,6 +493,7 @@ struct sh_eth_cpu_data {
> unsigned shift_rd0:1; /* shift Rx descriptor word 0 right by 16 */
> unsigned rmiimode:1; /* EtherC has RMIIMODE register */
> unsigned rtrate:1; /* EtherC has RTRATE register */
> + unsigned magic:1; /* EtherC has ECMR.PMDE and ECSR.MPD */
After looking at the SH7734/63 manuals it became obvious that PMDE was a
result of typo, the bit is called MPDE actually, the current name doesn't make
sense anyway. Care to fix?
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: use designated initializers
From: Kees Cook @ 2016-12-17 21:33 UTC (permalink / raw)
To: David Miller; +Cc: LKML, linux-decnet-user, Network Development
In-Reply-To: <20161217.115745.140164763267728629.davem@davemloft.net>
On Sat, Dec 17, 2016 at 8:57 AM, David Miller <davem@davemloft.net> wrote:
> From: Kees Cook <keescook@chromium.org>
> Date: Fri, 16 Dec 2016 16:58:58 -0800
>
>> Prepare to mark sensitive kernel structures for randomization by making
>> sure they're using designated initializers. These were identified during
>> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
>> extracted from grsecurity.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>
> Applied, although "decnet: " would have been a much better
> subsystem prefix.
Thanks! Yeah, I had corrected that in my tree already in case there
was a v2 needed. I was working off an auto-splitting script that I
taught to guess at prefixes by looking at commit logs. It didn't work
very well. ;) We need another field in MAINTAINERS. :)
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* Re: [TSN RFC v2 0/9] TSN driver for the kernel
From: Richard Cochran @ 2016-12-17 20:09 UTC (permalink / raw)
To: Henrik Austad
Cc: linux-kernel, Henrik Austad, linux-media, alsa-devel, netdev
In-Reply-To: <20161217090554.GA19737@icarus.home.austad.us>
On Sat, Dec 17, 2016 at 10:05:54AM +0100, Henrik Austad wrote:
> I'm sending out a new set now because, what I have works _fairly_ well for
> testing and a way to see what you can do with AVB. Using spotify to play
> music on random machines is quite entertaining.
You have missed the point about TSN entirely. Unless your demo has
synchronized playback (in the low microsecond range), then it really
is pointless. We can already play music over the LAN using gstreamer,
without a single kernel change. Heck, gstreamer even has its own
rudimentary synchronization, so your series is a step backwards.
> And therein lies the problem. It cannot yet be written, so we have to start
> in *some* end. And as I repeatedly stated in June, I'm at an RFC here,
> trying to spark some interest and lure other developers in :)
The best way to attract interest is to provide the critical
infrastructure missing in the kernel. Coding a media player in kernel
space is not very interesting in my view.
> Yes, and this requires a lot of change to ALSA (and probably something in
> V4L2 as well?), so before we get to that, perhaps have a set of patches
> that does this best effort and *then* work on getting time-triggered
> playback into the kernel?
No, we don't need a best effort implementation. That is gstreamer and Co.
> So, the next issue I plan to tackle, is how I do buffers, the current
> approach where tsn_core allocates memory is on its way out and I'll let the
> shim (which means alsa/v4l2) will provide a buffer. Then I'll start looking
> at qdisc.
More than once you wrote something like, "I know that's needed, but it
is just too hard ATM." Please start with qdisc and tc. That
shouldn't be too hard. If we had the AVB shaping rules with one or
two drivers supporting them, that would be one piece already done.
Thanks,
Richard
^ permalink raw reply
* Re: Potential issues (security and otherwise) with the current cgroup-bpf API
From: Andy Lutomirski @ 2016-12-17 20:02 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Andy Lutomirski, Daniel Mack, Alexei Starovoitov, Kees Cook,
Jann Horn, Tejun Heo, David Ahern, David S. Miller, Thomas Graf,
Michael Kerrisk, Peter Zijlstra, Linux API,
linux-kernel@vger.kernel.org, Network Development, John Stultz,
Eric W. Biederman
In-Reply-To: <58559171.30402@digikod.net>
On Sat, Dec 17, 2016 at 11:26 AM, Mickaël Salaün <mic@digikod.net> wrote:
>
> On 17/12/2016 19:18, Andy Lutomirski wrote:
>> Hi all-
>>
>> I apologize for being rather late with this. I didn't realize that
>> cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see
>> it on the linux-api list, so I missed the discussion.
>>
>> I think that the inet ingress, egress etc filters are a neat feature,
>> but I think the API has some issues that will bite us down the road
>> if it becomes stable in its current form.
>>
>> Most of the problems I see are summarized in this transcript:
>>
>> # mkdir cg2
>> # mount -t cgroup2 none cg2
>> # mkdir cg2/nosockets
>> # strace cgrp_socket_rule cg2/nosockets/ 0
>> ...
>> open("cg2/nosockets/", O_RDONLY|O_DIRECTORY) = 3
>>
>> ^^^^ You can modify a cgroup after opening it O_RDONLY?
>
> I sent a patch to check the cgroup.procs permission before attaching a
> BPF program to it [1], but it was not merged because not part of the
> current security model (which may not be crystal clear). The thing is
> that the current socket/BPF/cgroup feature is only available to a
> process with the *global CAP_NET_ADMIN* and such a process can already
> modify the network for every processes, so it doesn't make much sense to
> check if it can modify the network for a subset of this processes.
>
> [1] https://lkml.org/lkml/2016/9/19/854
I don't think that's quite the right approach. First, checking
permissions on an fd that's not the fd passed to the syscall is weird
and IMO shouldn't be done without a good reason. Second,
cgroups.procs seems like the wrong file.
Why not create "net.socket_create_filter" and require a writable fd to
*that* to be passed to the syscall.
>
> However, needing a process to open a cgroup *directory* in write mode
> may not make sense because the process does not modify the content of
> the cgroup but only use it as a *reference* in the network stack.
> Forcing an open with write mode may forbid to use this kind of
> network-filtering feature in a read-only file-system but not necessarily
> read-only *network configuration*.
It does modify the cgroup. Logically it changes the cgroup behavior.
As an implementation matter, it modifies the struct cgroup.
>
> Another point of view is that the CAP_NET_ADMIN may be an unneeded
> privilege if the cgroup migration is using a no_new_privs-like feature
> as I proposed with Landlock [2] (with an extra ptrace_may_access() check).
> The new capability proposition for cgroup may be interesting too.
>
> [2] https://lkml.org/lkml/2016/9/14/82
>
>>
>> bpf(BPF_PROG_LOAD, {prog_type=0x9 /* BPF_PROG_TYPE_??? */, insn_cnt=2,
>> insns=0x7fffe3568c10, license="GPL", log_level=1, log_size=262144,
>> log_buf=0x6020c0, kern_version=0}, 48) = 4
>>
>> ^^^^ This is fine. The bpf() syscall manipulates bpf objects.
>>
>> bpf(0x8 /* BPF_??? */, 0x7fffe3568bf0, 48) = 0
>>
>> ^^^^ This is not so good:
>> ^^^^
>> ^^^^ a) The bpf() syscall is supposed to manipulate bpf objects. This
>> ^^^^ is manipulating a cgroup. There's no reason that a socket creation
>> ^^^^ filter couldn't be written in a different language (new iptables
>> ^^^^ table? Simple list of address families?), but if that happened,
>> ^^^^ then using bpf() to install it would be entirely nonsensical.
>
> Another point of view is to say that the BPF program (called by the
> network stack) is using a reference to a set of processes thanks to a
> cgroup.
I strongly disagree with this point of view. From a user's
perspective, nothing about the bpf program changed -- the cgroup
changes. Even in the code, the bpf program doesn't have a reference
to anything. The cgroup references the bpf program.
>>
>> # echo $$ >cg2/nosockets/cgroup.procs
>> # ping 127.0.0.1
>> ping: socket: Operation not permitted
>> # ls cg2/nosockets/
>> cgroup.controllers cgroup.events cgroup.procs cgroup.subtree_control
>> # cat cg2/nosockets/cgroup.controllers
>>
>> ^^^^ Something in cgroupfs should give an indication that this cgroup
>> ^^^^ filters socket creation, but there's nothing there. You should also
>> ^^^^ be able to turn the filter off from cgroupfs.
>
> Right. Everybody was OK at LPC to add such an information but it is not
> there yet.
Then let's do it before CONFIG_CGROUP_BPF=y becomes possible in a
released kernel.
> Right. Because this feature doesn't handle namespaces (only global
> CAP_NET_ADMIN), nested containers should not be allowed to use it at all.
> If we want this kind of feature to be usable by something other than a
> process with a global capability, then we need an inheritance mechanism
> similar to what I designed for Landlock. I think it could be added later.
I think it's okay to have a new kernel feature that doesn't support
namespacing yet. I don't think it's okay to have a new kernel feature
that will become problematic when namespacing is added, and I think
cgroup-bpf is in the latter class.
Anyway, here's a half-baked proposal to clean this all up:
Make these new fiters actually be cgroup controllers. Fix whatever
needs to be fixed to make that work. This will mean that they can't
be the "subtree-control" type of controllers. (Maybe the same set of
fixes will help with the cpu controllers, too.) Make them stack
properly. Make them configurable using cgroupfs.
Add a "dangerous" flag on cgroups. Cgroups are "dangerous" if they
have dangerous controllers enabled. Controllers like "inet ingress"
are dangerous. You can only configure dangerous controllers if all
tasks in the cgroup have no_new_privs set and you have appropriate
permission over the tasks or if the cgroup is empty. If trying to bind
an inet ingress filter would make a cgroup dangerous and you don't
have the relevent privilege, then the operation fails. You cannot move
any task into a dangerous cgroup unless that task has no_new_privs set
*and* you have privilege over that task or if the task is in a
namespace that you have CAP_SYS_ADMIN on. (This is kind of like your
proposal, and maybe they should be merged. I do think that
*something* is needed and needs fleshing out.
Keep in mind, though, that strictly requiring no_new_privs is
excessive for namespaced applications. It might be okay to require
that a cgroup only ever contain tasks in a given namespace or perhaps
that a cgroup only contain tasks that are either no_new_privs *or* are
in a given namespace or its descendents. (In fact, unshare() can
*clear* no_new_privs because being in a fresh userns has more or less
the same effect.)
--Andy
^ permalink raw reply
* probably serious conntrack/netfilter panic, 4.8.14, timers and intel turbo
From: Denys Fedoryshchenko @ 2016-12-17 19:48 UTC (permalink / raw)
To: Linux Kernel Network Developers, linux-kernel, Pablo Neira Ayuso
Hi,
I posted recently several netfilter related crashes, didn't got any
answers, one of them started to happen quite often on loaded NAT
(17Gbps),
so after trying endless ways to make it stable, i found out that in
backtrace i can often see timers, and this bug probably appearing on
older releases,
i've seen such backtrace with timer fired for conntrack on them.
I disabled Intel turbo for cpus on this loaded NAT, and voila, panic
disappeared for 2nd day!
* by wrmsr -a 0x1a0 0x4000850089
I am not sure timers is the reason, but probably turbo creating some
condition for bug.
Here is examples of backtrace of last reboots (kernel 4.8.14), and same
kernel worked perfectly without turbo.
Last one also one crash on 4.8.0 that looks painfully similar, on
totally different workload, but with conntrack enabled. It happens there
much less often,
so harder to crash and test by disabling turbo.
[28904.162607] BUG: unable to handle kernel
NULL pointer dereference
at 0000000000000008
[28904.163210] IP:
[<ffffffffa00ab07d>] nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
[28904.163745] PGD 0
[28904.164058] Oops: 0002 [#1] SMP
[28904.164323] Modules linked in:
nf_nat_pptp
nf_nat_proto_gre
xt_TCPMSS
xt_connmark
ipt_MASQUERADE
nf_nat_masquerade_ipv4
xt_nat
xt_rateest
xt_RATEEST
nf_conntrack_pptp
nf_conntrack_proto_gre
xt_CT
xt_set
xt_hl
xt_tcpudp
ip_set_hash_net
ip_set
nfnetlink
iptable_raw
iptable_mangle
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
iptable_filter
ip_tables
x_tables
netconsole
configfs
8021q
garp
mrp
stp
llc
bonding
ixgbe
dca
[28904.168132] CPU: 27 PID: 0 Comm: swapper/27 Not tainted
4.8.14-build-0124 #2
[28904.168398] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS
SE5C610.86B.01.01.1008.031920151331 03/19/2015
[28904.168853] task: ffff885fa42e8c40 task.stack: ffff885fa42f0000
[28904.169114] RIP: 0010:[<ffffffffa00ab07d>]
[<ffffffffa00ab07d>] nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
[28904.169643] RSP: 0018:ffff885fbccc3dd8 EFLAGS: 00010246
[28904.169901] RAX: 0000000000000000 RBX: ffff885fbccc0000 RCX:
ffff885fbccc0010
[28904.170169] RDX: ffff885f87a1c150 RSI: 0000000000000142 RDI:
ffff885fbccc0000
[28904.170437] RBP: ffff885fbccc3de8 R08: 00000000cbdee177 R09:
0000000000000100
[28904.170704] R10: ffff885fbccc3dd0 R11: ffffffff820050c0 R12:
ffff885f87a1c140
[28904.170971] R13: 000000000005d948 R14: 00000000000ea942 R15:
ffff885f87a1c160
[28904.171237] FS: 0000000000000000(0000) GS:ffff885fbccc0000(0000)
knlGS:0000000000000000
[28904.171688] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[28904.171964] CR2: 0000000000000008 CR3: 000000607f006000 CR4:
00000000001406e0
[28904.172231] Stack:
[28904.172482] ffff885f87a1c140
ffffffff820a1405
ffff885fbccc3e28
ffffffffa00abb30
[28904.173182] 00000002820a1405
ffff885f87a1c140
ffff885f99a28201
0000000000000000
[28904.173884] 0000000000000000
ffffffff820050c8
ffff885fbccc3e58
ffffffffa00abc62
[28904.174585] Call Trace:
[28904.174835] <IRQ>
[28904.174912] [<ffffffffa00abb30>] nf_ct_delete_from_lists+0xc9/0xf2
[nf_conntrack]
[28904.175613] [<ffffffffa00abc62>] nf_ct_delete+0x109/0x12c
[nf_conntrack]
[28904.175894] [<ffffffffa00abc85>] ? nf_ct_delete+0x12c/0x12c
[nf_conntrack]
[28904.176169] [<ffffffffa00abc92>] death_by_timeout+0xd/0xf
[nf_conntrack]
[28904.176443] [<ffffffff81109922>] call_timer_fn.isra.5+0x17/0x6b
[28904.176714] [<ffffffff811099e5>] expire_timers+0x6f/0x7e
[28904.176975] [<ffffffff81109add>] run_timer_softirq+0x69/0x8b
[28904.177238] [<ffffffff811141bb>] ?
clockevents_program_event+0xd0/0xe8
[28904.177504] [<ffffffff810d000c>] __do_softirq+0xbd/0x1aa
[28904.177765] [<ffffffff810d0240>] irq_exit+0x37/0x7c
[28904.178026] [<ffffffff8102c519>]
smp_trace_apic_timer_interrupt+0x7b/0x88
[28904.178300] [<ffffffff8102c52f>] smp_apic_timer_interrupt+0x9/0xb
[28904.178565] [<ffffffff818f4f1c>] apic_timer_interrupt+0x7c/0x90
[28904.178835] <EOI>
[28904.178907] [<ffffffff8101b929>] ? mwait_idle+0x64/0x7a
[28904.179436] [<ffffffff810e3d8f>] ?
atomic_notifier_call_chain+0x13/0x15
[28904.179712] [<ffffffff8101bd04>] arch_cpu_idle+0xa/0xc
[28904.179976] [<ffffffff810f7c3d>] default_idle_call+0x27/0x29
[28904.180244] [<ffffffff810f7d5c>] cpu_startup_entry+0x11d/0x1c7
[28904.180508] [<ffffffff8102af13>] start_secondary+0xe8/0xeb
[28904.180767] Code:
80
2f
0b
82
48
89
df
e8
da
90
84
e1
48
8b
43
10
49
8d
54
24
10
48
8d
4b
10
49
89
4c
24
18
a8
01
49
89
44
24
10
48
89
53
10
75
04
89
50
08
c6
03
00
5b
41
5c
5d
c3
48
8b
05
10
be
00
00
89
f6
[28904.185546] RIP
[<ffffffffa00ab07d>] nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
[28904.186065] RSP <ffff885fbccc3dd8>
[28904.186319] CR2: 0000000000000008
[28904.186593] ---[ end trace 35cbc6c885a5c2d8 ]---
[28904.186860] Kernel panic - not syncing: Fatal exception in interrupt
[28904.187155] Kernel Offset: disabled
[28904.187419] Rebooting in 5 seconds..
[28909.193662] ACPI MEMORY or I/O RESET_REG.
[14125.227611] BUG: unable to handle kernel
NULL pointer dereference
at (null)
[14125.228215] IP:
[<ffffffffa00cbd89>] nf_nat_setup_info+0x6d8/0x755 [nf_nat]
[14125.228564] PGD 0
[14125.228882] Oops: 0000 [#1] SMP
[14125.229146] Modules linked in:
nf_nat_pptp
nf_nat_proto_gre
xt_TCPMSS
xt_connmark
ipt_MASQUERADE
nf_nat_masquerade_ipv4
xt_nat
xt_rateest
xt_RATEEST
nf_conntrack_pptp
nf_conntrack_proto_gre
xt_CT
xt_set
xt_hl
xt_tcpudp
ip_set_hash_net
ip_set
nfnetlink
iptable_raw
iptable_mangle
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
iptable_filter
ip_tables
x_tables
netconsole
configfs
8021q
garp
mrp
stp
llc
bonding
ixgbe
dca
[14125.232998] CPU: 30 PID: 0 Comm: swapper/30 Not tainted
4.8.14-build-0124 #2
[14125.233274] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS
SE5C610.86B.01.01.1008.031920151331 03/19/2015
[14125.233736] task: ffff885fa5edb100 task.stack: ffff885fa5ef0000
[14125.234009] RIP: 0010:[<ffffffffa00cbd89>]
[<ffffffffa00cbd89>] nf_nat_setup_info+0x6d8/0x755 [nf_nat]
[14125.234540] RSP: 0018:ffff885fbe783920 EFLAGS: 00010202
[14125.234806] RAX: 00000000001461e5 RBX: ffffc90037f28794 RCX:
000000000000000e
[14125.235075] RDX: 0000000000000000 RSI: ffff881405040218 RDI:
ffffc90037f28794
[14125.235345] RBP: ffff885fbe7839f8 R08: 000000008b605951 R09:
0000000000000001
[14125.235615] R10: ffff885f93ecab4e R11: ffff882fa5eb0c20 R12:
0000000000000000
[14125.235885] R13: ffff885f9f1bedd8 R14: ffff885f9f1bed00 R15:
ffffc90036f1c000
[14125.236154] FS: 0000000000000000(0000) GS:ffff885fbe780000(0000)
knlGS:0000000000000000
[14125.236604] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[14125.236870] CR2: 0000000000000000 CR3: 0000000002006000 CR4:
00000000001406e0
[14125.237139] Stack:
[14125.237391] ffff885fbe7839a0
ffffffffa00cb0cd
ffffffffa00ccb90
ffffffff001461e5
[14125.238098] 0000000000000000
ffffffffa00cb01d
000000000a19000a
0000000000000000
[14125.238808] a6c3fbcd0002ad8e
0000000000000000
0011350000000000
00000000015459b9
[14125.239520] Call Trace:
[14125.239776] <IRQ>
[14125.239851] [<ffffffffa00cb0cd>] ? nf_nat_bysource_hash+0xb0/0xb0
[nf_nat]
[14125.240373] [<ffffffffa00cb01d>] ? __nf_nat_l4proto_find+0x1d/0x1d
[nf_nat]
[14125.240651] [<ffffffffa012d092>] xt_snat_target_v0+0x65/0x67 [xt_nat]
[14125.240931] [<ffffffffa009f3d3>] ipt_do_table+0x28e/0x5a2 [ip_tables]
[14125.241199] [<ffffffffa009f6cb>] ? ipt_do_table+0x586/0x5a2
[ip_tables]
[14125.241474] [<ffffffffa0042800>] ? bond_dev_queue_xmit+0x52/0x57
[bonding]
[14125.241752] [<ffffffffa00e4040>] ? iptable_nat_ipv4_fn+0x12/0x12
[iptable_nat]
[14125.242210] [<ffffffffa00e405a>] iptable_nat_do_chain+0x1a/0x1c
[iptable_nat]
[14125.242661] [<ffffffffa00d34e3>] nf_nat_ipv4_fn+0xeb/0x17c
[nf_nat_ipv4]
[14125.242930] [<ffffffffa00d3618>] nf_nat_ipv4_out+0x35/0x37
[nf_nat_ipv4]
[14125.243198] [<ffffffffa00e407e>] iptable_nat_ipv4_out+0x10/0x12
[iptable_nat]
[14125.243655] [<ffffffff818a1985>] nf_iterate+0x41/0x66
[14125.243925] [<ffffffff818a19d5>] nf_hook_slow+0x2b/0x94
[14125.244199] [<ffffffff818ab740>] ip_output+0xa0/0xbd
[14125.244471] [<ffffffff818aad25>] ? ip_fragment.constprop.5+0x77/0x77
[14125.244739] [<ffffffff818a867c>] ip_forward_finish+0x53/0x58
[14125.245007] [<ffffffff818a89b4>] ip_forward+0x333/0x340
[14125.245279] [<ffffffff818a8629>] ? ip_frag_mem+0x3e/0x3e
[14125.245542] [<ffffffff818a7007>] ip_rcv_finish+0x32f/0x33a
[14125.245809] [<ffffffff818a74f2>] ip_rcv+0x320/0x32d
[14125.246078] [<ffffffff818a6cd8>] ?
ip_local_deliver_finish+0x109/0x109
[14125.246349] [<ffffffff818764bf>] __netif_receive_skb_core+0x623/0x80a
[14125.246629] [<ffffffffa000a201>] ? ixgbe_poll+0x5cf/0x679 [ixgbe]
[14125.246905] [<ffffffff81876f14>] __netif_receive_skb+0x13/0x55
[14125.247178] [<ffffffff81877e6d>] process_backlog+0x8e/0x110
[14125.247443] [<ffffffff81877c69>] net_rx_action+0x107/0x27d
[14125.247709] [<ffffffff810d000c>] __do_softirq+0xbd/0x1aa
[14125.247982] [<ffffffff810d0240>] irq_exit+0x37/0x7c
[14125.248248] [<ffffffff8102a7ac>]
smp_trace_call_function_single_interrupt+0x2e/0x30
[14125.248710] [<ffffffff8102a7b7>]
smp_call_function_single_interrupt+0x9/0xb
[14125.248990] [<ffffffff818f527c>]
call_function_single_interrupt+0x7c/0x90
[14125.249259] <EOI>
[14125.249333] [<ffffffff8101b929>] ? mwait_idle+0x64/0x7a
[14125.249850] [<ffffffff810e3d8f>] ?
atomic_notifier_call_chain+0x13/0x15
[14125.250127] [<ffffffff8101bd04>] arch_cpu_idle+0xa/0xc
[14125.250394] [<ffffffff810f7c3d>] default_idle_call+0x27/0x29
[14125.250667] [<ffffffff810f7d5c>] cpu_startup_entry+0x11d/0x1c7
[14125.250939] [<ffffffff8102af13>] start_secondary+0xe8/0xeb
[14125.251202] Code:
ff
ff
00
39
c2
0f
84
1a
fe
ff
ff
e9
ae
fd
ff
ff
49
8b
74
c7
40
8b
0d
17
16
00
00
48
89
f2
f6
c2
01
75
0d
ff
c9
0f
84
21
ff
ff
ff
8b
12
eb
ee
49
89
b6
d8
00
00
00
49
8d
44
c7
40
4c
89
28
f0
[14125.256035] RIP
[<ffffffffa00cbd89>] nf_nat_setup_info+0x6d8/0x755 [nf_nat]
[14125.256368] RSP <ffff885fbe783920>
[14125.256623] CR2: 0000000000000000
[14125.256902] ---[ end trace dbad9b5a1e1b7632 ]---
[14125.257173] Kernel panic - not syncing: Fatal exception in interrupt
[14125.257461] Kernel Offset: disabled
[14125.257726] Rebooting in 5 seconds..
[14130.264058] ACPI MEMORY or I/O RESET_REG.
[10916.690366] BUG: unable to handle kernel
NULL pointer dereference
at 0000000000000008
[10916.690939] IP:
[<ffffffffa00ab07d>] nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
[10916.691461] PGD 5fa11a6067
PUD 5fa11a0067
PMD 0
[10916.691900] Oops: 0002 [#1] SMP
[10916.692156] Modules linked in:
nf_nat_pptp
nf_nat_proto_gre
xt_TCPMSS
xt_connmark
ipt_MASQUERADE
nf_nat_masquerade_ipv4
xt_nat
xt_rateest
xt_RATEEST
nf_conntrack_pptp
nf_conntrack_proto_gre
xt_CT
xt_set
xt_hl
xt_tcpudp
ip_set_hash_net
ip_set
nfnetlink
iptable_raw
iptable_mangle
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
iptable_filter
ip_tables
x_tables
netconsole
configfs
8021q
garp
mrp
stp
llc
bonding
ixgbe
dca
[10916.695863] CPU: 6 PID: 0 Comm: swapper/6 Not tainted
4.8.14-build-0124 #2
[10916.696129] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS
SE5C610.86B.01.01.1008.031920151331 03/19/2015
[10916.696576] task: ffff882fa5ea3d40 task.stack: ffff882fa5ec4000
[10916.696834] RIP: 0010:[<ffffffffa00ab07d>]
[<ffffffffa00ab07d>] nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
[10916.697351] RSP: 0018:ffff882fbed83de8 EFLAGS: 00010246
[10916.697604] RAX: 0000000000000000 RBX: ffff882fbed80000 RCX:
ffff882fbed80010
[10916.697863] RDX: ffff882f8b836450 RSI: 000000000000019b RDI:
ffff882fbed80000
[10916.698124] RBP: ffff882fbed83df8 R08: 00000000c236df5a R09:
0000000000000100
[10916.698382] R10: ffff882fbed83de0 R11: ffffffff820050c0 R12:
ffff882f8b836440
[10916.698642] R13: 0000000000004d8a R14: 000000000007099b R15:
ffff882f8b836460
[10916.698904] FS: 0000000000000000(0000) GS:ffff882fbed80000(0000)
knlGS:0000000000000000
[10916.699343] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[10916.699601] CR2: 0000000000000008 CR3: 0000005fa3e68000 CR4:
00000000001406e0
[10916.699862] Stack:
[10916.700105] ffff882f8b836440
ffffffff820a1405
ffff882fbed83e38
ffffffffa00abb30
[10916.700793] 00000002820a1405
ffff882f8b836440
ffff882f92f48401
0000000000000000
[10916.701479] 0000000000000000
ffffffff820050c8
ffff882fbed83e68
ffffffffa00abc62
[10916.702161] Call Trace:
[10916.702406] <IRQ>
[10916.702478] [<ffffffffa00abb30>] nf_ct_delete_from_lists+0xc9/0xf2
[nf_conntrack]
[10916.703151] [<ffffffffa00abc62>] nf_ct_delete+0x109/0x12c
[nf_conntrack]
[10916.703416] [<ffffffffa00abc85>] ? nf_ct_delete+0x12c/0x12c
[nf_conntrack]
[10916.703680] [<ffffffffa00abc92>] death_by_timeout+0xd/0xf
[nf_conntrack]
[10916.703945] [<ffffffff81109922>] call_timer_fn.isra.5+0x17/0x6b
[10916.704206] [<ffffffff811099e5>] expire_timers+0x6f/0x7e
[10916.704457] [<ffffffff81109add>] run_timer_softirq+0x69/0x8b
[10916.704709] [<ffffffff810d000c>] __do_softirq+0xbd/0x1aa
[10916.704959] [<ffffffff810d0240>] irq_exit+0x37/0x7c
[10916.705208] [<ffffffff8102a7ac>]
smp_trace_call_function_single_interrupt+0x2e/0x30
[10916.705637] [<ffffffff8102a7b7>]
smp_call_function_single_interrupt+0x9/0xb
[10916.705893] [<ffffffff818f527c>]
call_function_single_interrupt+0x7c/0x90
[10916.706148] <EOI>
[10916.706217] [<ffffffff8101b929>] ? mwait_idle+0x64/0x7a
[10916.706702] [<ffffffff810e3d8f>] ?
atomic_notifier_call_chain+0x13/0x15
[10916.706958] [<ffffffff8101bd04>] arch_cpu_idle+0xa/0xc
[10916.707210] [<ffffffff810f7c3d>] default_idle_call+0x27/0x29
[10916.707463] [<ffffffff810f7d5c>] cpu_startup_entry+0x11d/0x1c7
[10916.707715] [<ffffffff8102af13>] start_secondary+0xe8/0xeb
[10916.707965] Code:
80
2f
0b
82
48
89
df
e8
da
90
84
e1
48
8b
43
10
49
8d
54
24
10
48
8d
4b
10
49
89
4c
24
18
a8
01
49
89
44
24
10
48
89
53
10
75
04
89
50
08
c6
03
00
5b
41
5c
5d
c3
48
8b
05
10
be
00
00
89
f6
[10916.712535] RIP
[<ffffffffa00ab07d>] nf_ct_add_to_dying_list+0x55/0x61 [nf_conntrack]
[10916.713038] RSP <ffff882fbed83de8>
[10916.713282] CR2: 0000000000000008
[10916.713544] ---[ end trace cdc0d7fd100b7f79 ]---
[10916.713800] Kernel panic - not syncing: Fatal exception in interrupt
[10916.714070] Kernel Offset: disabled
[10916.714326] Rebooting in 5 seconds..
[10921.718433] ACPI MEMORY or I/O RESET_REG.
------- This one for old kernel, 4.8.0 !!!
[744605.128307] BUG: unable to handle kernel
paging request
at ffff88a005040218
[744605.128550] IP:
[<ffffffffa00a1d89>] nf_nat_setup_info+0x6d8/0x755 [nf_nat]
[744605.128788] PGD 0
[744605.129004] Oops: 0000 [#1] SMP
[744605.129223] Modules linked in:
sch_sfq
cls_fw
act_police
cls_u32
sch_ingress
sch_htb
pppoe
pppox
ppp_generic
slhc
xt_nat
ts_bm
xt_string
xt_connmark
xt_TCPMSS
xt_tcpudp
xt_mark
iptable_filter
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
iptable_mangle
ip_tables
x_tables
netconsole
configfs
8021q
garp
mrp
stp
llc
ixgbe
dca
[744605.130523] CPU: 4 PID: 10559 Comm: accel-pppd Not tainted
4.8.0-build-0117 #1
[744605.130959] Hardware name: Intel Corporation S2600GZ/S2600GZ, BIOS
SE5C600.86B.02.04.0003.102320141138 10/23/2014
[744605.131401] task: ffff8817d06cd240 task.stack: ffff8817c9610000
[744605.131630] RIP: 0010:[<ffffffffa00a1d89>]
[<ffffffffa00a1d89>] nf_nat_setup_info+0x6d8/0x755 [nf_nat]
[744605.132104] RSP: 0018:ffff8817c96139c0 EFLAGS: 00010216
[744605.132397] RAX: 00000000000014ce RBX: ffffc9001953c338 RCX:
000000000000000f
[744605.132831] RDX: ffff88a005040218 RSI: ffff88a005040218 RDI:
ffffc9001953c338
[744605.133262] RBP: ffff8817c9613a98 R08: 0000000063bf9e56 R09:
0000000000000001
[744605.133692] R10: 0000000000000000 R11: ffff88177b8a7010 R12:
0000000000000000
[744605.134124] R13: ffff88177fd32518 R14: ffff88177fd32440 R15:
ffffc90034b30000
[744605.134553] FS: 00007f7d6ee4c700(0000) GS:ffff8817df700000(0000)
knlGS:0000000000000000
[744605.135000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[744605.135231] CR2: ffff88a005040218 CR3: 0000002fcc4d1000 CR4:
00000000001406e0
[744605.135664] Stack:
[744605.135881] ffff8817ca0323e8
ffff8817c9613ad8
ffffffffa00a31d0
ffffffff000014ce
[744605.136331] 0000000000000000
ffffffffa00a101d
0000000015fd000a
0000000000000000
[744605.136784] 12fd000a0002a895
0000000000000000
0011150700000000
0000000015fd000a
[744605.137241] Call Trace:
[744605.137459] [<ffffffffa00a101d>] ? __nf_nat_l4proto_find+0x1d/0x1d
[nf_nat]
[744605.137691] [<ffffffffa00b4040>] ? iptable_nat_ipv4_fn+0x12/0x12
[iptable_nat]
[744605.138127] [<ffffffffa00a1e5b>]
__nf_nat_alloc_null_binding+0x55/0x5d [nf_nat]
[744605.138569] [<ffffffffa00a1e7e>] nf_nat_alloc_null_binding+0x1b/0x1d
[nf_nat]
[744605.138998] [<ffffffffa009752d>] nf_nat_ipv4_fn+0x135/0x17c
[nf_nat_ipv4]
[744605.139230] [<ffffffffa0097618>] nf_nat_ipv4_out+0x35/0x37
[nf_nat_ipv4]
[744605.139459] [<ffffffffa00b407e>] iptable_nat_ipv4_out+0x10/0x12
[iptable_nat]
[744605.139892] [<ffffffff8189ebd2>] nf_iterate+0x41/0x66
[744605.140117] [<ffffffff8189ec22>] nf_hook_slow+0x2b/0x94
[744605.140343] [<ffffffff818a88d9>] ip_output+0xa0/0xbd
[744605.140570] [<ffffffff818a7ebd>] ? ip_fragment.constprop.5+0x77/0x77
[744605.140795] [<ffffffff818a8185>] ip_local_out+0x30/0x37
[744605.141022] [<ffffffff818a90df>] ip_send_skb+0x14/0x38
[744605.141257] [<ffffffff818c904c>] udp_send_skb+0x183/0x1e0
[744605.141480] [<ffffffff818ca9f1>] udp_sendmsg+0x543/0x71f
[744605.141705] [<ffffffff818a74a0>] ? ip_reply_glue_bits+0x4a/0x4a
[744605.141933] [<ffffffff818a18ce>] ?
__ip_route_output_key_hash+0x4f7/0x602
[744605.142165] [<ffffffff818d25f1>] inet_sendmsg+0x54/0x89
[744605.142392] [<ffffffff8185e5de>] sock_sendmsg+0x12/0x1d
[744605.142620] [<ffffffff8185e65e>] sock_write_iter+0x75/0x8d
[744605.142844] [<ffffffff811880d7>] __vfs_write+0xd0/0xf9
[744605.143066] [<ffffffff81188b82>] vfs_write+0xcd/0x177
[744605.143289] [<ffffffff81189c0d>] SyS_write+0x49/0x83
[744605.143514] [<ffffffff818f13df>] entry_SYSCALL_64_fastpath+0x17/0x93
[744605.143741] Code:
ff
ff
00
39
c2
0f
84
1a
fe
ff
ff
e9
ae
fd
ff
ff
49
8b
74
c7
40
8b
0d
d7
27
00
00
48
89
f2
f6
c2
01
75
0d
ff
c9
0f
84
21
ff
ff
ff
8b
12
eb
ee
49
89
b6
d8
00
00
00
49
8d
44
c7
40
4c
89
28
f0
[744605.146860] RIP
[<ffffffffa00a1d89>] nf_nat_setup_info+0x6d8/0x755 [nf_nat]
[744605.147206] RSP <ffff8817c96139c0>
[744605.147477] CR2: ffff88a005040218
[744605.148299] ---[ end trace 99c51f3aaa6204f3 ]---
[744605.152407] Kernel panic - not syncing: Fatal exception in interrupt
[744605.152770] Kernel Offset: disabled
[744605.156643] Rebooting in 5 seconds..
^ permalink raw reply
* Re: Potential issues (security and otherwise) with the current cgroup-bpf API
From: Mickaël Salaün @ 2016-12-17 19:26 UTC (permalink / raw)
To: Andy Lutomirski, Daniel Mack, Alexei Starovoitov, Kees Cook,
Jann Horn, Tejun Heo, David Ahern, David S. Miller, Thomas Graf,
Michael Kerrisk, Peter Zijlstra
Cc: Linux API, linux-kernel@vger.kernel.org, Network Development,
John Stultz
In-Reply-To: <CALCETrV81oFwq2AgeRsN54HA1jR=b5cOZfAgve8H8zhx83DTyA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 7074 bytes --]
On 17/12/2016 19:18, Andy Lutomirski wrote:
> Hi all-
>
> I apologize for being rather late with this. I didn't realize that
> cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see
> it on the linux-api list, so I missed the discussion.
>
> I think that the inet ingress, egress etc filters are a neat feature,
> but I think the API has some issues that will bite us down the road
> if it becomes stable in its current form.
>
> Most of the problems I see are summarized in this transcript:
>
> # mkdir cg2
> # mount -t cgroup2 none cg2
> # mkdir cg2/nosockets
> # strace cgrp_socket_rule cg2/nosockets/ 0
> ...
> open("cg2/nosockets/", O_RDONLY|O_DIRECTORY) = 3
>
> ^^^^ You can modify a cgroup after opening it O_RDONLY?
I sent a patch to check the cgroup.procs permission before attaching a
BPF program to it [1], but it was not merged because not part of the
current security model (which may not be crystal clear). The thing is
that the current socket/BPF/cgroup feature is only available to a
process with the *global CAP_NET_ADMIN* and such a process can already
modify the network for every processes, so it doesn't make much sense to
check if it can modify the network for a subset of this processes.
[1] https://lkml.org/lkml/2016/9/19/854
However, needing a process to open a cgroup *directory* in write mode
may not make sense because the process does not modify the content of
the cgroup but only use it as a *reference* in the network stack.
Forcing an open with write mode may forbid to use this kind of
network-filtering feature in a read-only file-system but not necessarily
read-only *network configuration*.
Another point of view is that the CAP_NET_ADMIN may be an unneeded
privilege if the cgroup migration is using a no_new_privs-like feature
as I proposed with Landlock [2] (with an extra ptrace_may_access() check).
The new capability proposition for cgroup may be interesting too.
[2] https://lkml.org/lkml/2016/9/14/82
>
> bpf(BPF_PROG_LOAD, {prog_type=0x9 /* BPF_PROG_TYPE_??? */, insn_cnt=2,
> insns=0x7fffe3568c10, license="GPL", log_level=1, log_size=262144,
> log_buf=0x6020c0, kern_version=0}, 48) = 4
>
> ^^^^ This is fine. The bpf() syscall manipulates bpf objects.
>
> bpf(0x8 /* BPF_??? */, 0x7fffe3568bf0, 48) = 0
>
> ^^^^ This is not so good:
> ^^^^
> ^^^^ a) The bpf() syscall is supposed to manipulate bpf objects. This
> ^^^^ is manipulating a cgroup. There's no reason that a socket creation
> ^^^^ filter couldn't be written in a different language (new iptables
> ^^^^ table? Simple list of address families?), but if that happened,
> ^^^^ then using bpf() to install it would be entirely nonsensical.
Another point of view is to say that the BPF program (called by the
network stack) is using a reference to a set of processes thanks to a
cgroup.
> ^^^^
> ^^^^ b) This is starting to be an excessively ugly multiplexer. Among
> ^^^^ other things, it's very unfriendly to seccomp.
FWIW, Landlock will have the capability to filter this kind of action.
>
> # echo $$ >cg2/nosockets/cgroup.procs
> # ping 127.0.0.1
> ping: socket: Operation not permitted
> # ls cg2/nosockets/
> cgroup.controllers cgroup.events cgroup.procs cgroup.subtree_control
> # cat cg2/nosockets/cgroup.controllers
>
> ^^^^ Something in cgroupfs should give an indication that this cgroup
> ^^^^ filters socket creation, but there's nothing there. You should also
> ^^^^ be able to turn the filter off from cgroupfs.
Right. Everybody was OK at LPC to add such an information but it is not
there yet.
>
> # mkdir cg2/nosockets/sockets
> # /home/luto/apps/linux/samples/bpf/cgrp_socket_rule cg2/nosockets/sockets/ 1
>
> ^^^^ This succeeded, which means that, if this feature is enabled in 4.10,
> ^^^^ then we're stuck with its semantics. If it returned -EINVAL instead,
> ^^^^ there would be a chance to refine it.
This is indeed unfortunate.
>
> # echo $$ >cg2/nosockets/sockets/cgroup.procs
> # ping 127.0.0.1
> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.029 ms
> ^C
> --- 127.0.0.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.029/0.029/0.029/0.000 ms
>
> ^^^^ Bash was inside a cgroup that disallowed socket creation, but socket
> ^^^^ creation wasn't disallowed. This means that the obvious use of socket
> ^^^^ creation filters in nestable constainers fails insecurely.
>
>
> There's also a subtle but nasty potential security problem here.
> In 4.9 and before, cgroups has only one real effect in the kernel:
> resource control. A process in a malicious cgroup could be DoSed,
> but that was about the extent of the damage that a malicious cgroup
> could do.
>
> In 4.10 with With CONFIG_CGROUP_BPF=y, a cgroup can have bpf
> programs attached that can do things if various events occur. (Right
> now, this means socket operations, but there are plans in the works
> to do this for LSM hooks too.) These bpf programs can say yes or no,
> but they can also read out various data (including socket payloads!)
> and save them away where an attacker can find them. This sounds a
> lot like seccomp with a narrower scope but a much stronger ability to
> exfiltrate private information.
>
> Unfortunately, while seccomp is very, very careful to prevent
> injection of a privileged victim into a malicious sandbox, the
> CGROUP_BPF mechanism appears to have no real security model. There
> is nothing to prevent a program that's in a malicious cgroup from
> running a setuid binary, and there is nothing to prevent a program
> that has the ability to move itself or another program into a
> malicious cgroup from doing so and then, if needed for exploitation,
> exec a setuid binary.
>
> This isn't much of a problem yet because you currently need
> CAP_NET_ADMIN to create a malicious sandbox in the first place. I'm
> sure that, in the near future, someone will want to make this stuff
> work in containers with delegated cgroup hierarchies, and then there
> may be a real problem here.
>
>
> I've included a few security people on this thread. The current API
> looks abusable, and it would be nice to find all the holes before
> 4.10 comes out.
>
>
> (The cgrp_socket_rule source is attached. You can build it by sticking it
> in samples/bpf and doing:
>
> $ make headers_install
> $ cd samples/bpf
> $ gcc -o cgrp_socket_rule cgrp_socket_rule.c libbpf.c -I../../usr/include
> )
>
> --Andy
>
Right. Because this feature doesn't handle namespaces (only global
CAP_NET_ADMIN), nested containers should not be allowed to use it at all.
If we want this kind of feature to be usable by something other than a
process with a global capability, then we need an inheritance mechanism
similar to what I designed for Landlock. I think it could be added later.
Regards,
Mickaël
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] rtlwifi: rtl8192ee: New firmware from Realtek
From: Larry Finger @ 2016-12-17 18:50 UTC (permalink / raw)
To: linux-firmware; +Cc: linux-wireless, Troy Tan, netdev, Larry Finger
From: Troy Tan <troy_tan@realsil.com.cn>
Recent testing by Realtek found bugs in both the driver and firmware for
the RTL8192EE chips.
Signed-off-by: Troy Tan <troy_tan@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
WHENCE | 5 ++++-
rtlwifi/rtl8192eefw.bin | Bin 32754 -> 31818 bytes
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/WHENCE b/WHENCE
index df2dffa..c6f650e 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2115,7 +2115,10 @@ Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
Driver: rtl8192ee - Realtek 802.11n WLAN driver for RTL8192EE
-Info: Taken from Realtek version rtl_92ce_92se_92de_8723ae_88ee_8723be_92ee_linux_mac80211_0017.1224.2013
+Info: Initial version taken from Realtek version
+ rtl_92ce_92se_92de_8723ae_88ee_8723be_92ee_linux_mac80211_0017.1224.2013
+ Updated Jan. 14, 2015 with file added by Realtek to
+ http://github.com/lwfinger/rtlwifi_new.git.
File: rtlwifi/rtl8192eefw.bin
Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
diff --git a/rtlwifi/rtl8192eefw.bin b/rtlwifi/rtl8192eefw.bin
index bede1ad79f9c5243484f31c790ef794d579c9b4b..4a034d3ae8910df49682876dfe44fe8690798825 100644
GIT binary patch
literal 31818
zcmb`w3w#q*+CQF|OfGHH+q6K-wS-nhMS^%+*Oekw@dhn~izpJX-epPGbOp6!0CB~&
z%P2+PT@}P6s3=r->#D4Bv9d4kzPr+jyX#(r0h5A2nyE_=Y?J)H&zYGd1=jWddH;oE
z&Ybg{`*WV>InVQ)lLOBdnMzD1lX+Zm_4$vPOz#!pCF_sB;TC>gJS)Ov;ypj;|L#4n
z-}~t={Jaw^iobWV_FQx%UriMvoUhV19@%e2+FOy97H1G9?ZuSO3NQgAg;0??f!=fN
zX0u7ivC+5PYUc56F>@v%Ki6h4*&Vqy!DP?NwIZCCYcbO|VC<!$LogMUiaGeMbPg3w
z6_w612Yr`X>AO(C_sCp)j~WTcicupd>>NSyBS#Db<hZdFr6$+7v1LX0z7Tm`<IXRo
z@AFDc_^xE%!|9vnc?&OCY&M%cm*WMiEjKTpHw!j<UVfnk(b-RqH&ePJzd(aPpvZtJ
zOhXqI3IY|FljA5T5(SIZmX}{#Vmx#3=O`#HF`j}wCzs$#N(DOwic3ld8fhhIs1m{h
z?XU8j^AQ*^vg%wmwWH2CkKRqEKP#%v9X*<*WI_aUKFggB3CKzxJ3fS7W%yL$<HCnf
z!h?^D&klS($LA`1>hW2O&&&9zCKFeU4`4V2?=Rz%701s8`c{}s)@qZ<)`7I$fI}Sw
z%j4aA7}dY^{~`T9)K6vQc+OrA)t~pC$yD;B$u!7|A*?<-Ty}dX4}JbqyLC9;1PsSm
zI!q!)veM+j7<x<(nueP$#>mxT)LuqOsuAKY<Ye>XmQsx9(<YU>mpjhSHdkOwPJcfw
zKR;V|D+6ObZ24!-$9eA+zMP5E$}t~4vn+}OngiF0$|_vdwZMP;nax013&-(1J?Y(I
zv0CvT3m_-gcpB+en*m|ZG17ALG9ixsutb3RcH>E@cC4MulS<a#bMhPxEkzG$X%uIK
z%B=!#Dl5$&P%xlyV9}uBGO?_rZ0LXjEnGfy@X#ScOC6>81*KZLILI+n3zrNkD=9A<
zT#i}%zx{pGDkU!#ul23$$ZPDdZ&E&bI`UNIJ@Ka^PhYYm{`99$AFKS?$*vE0-j`}$
zyR5C+RQ<^k^I~aWm))E9QEQj$fVrmZ#HX$HzeSJyyu%rBq()UPJ6UMAZ#N5m)8b`a
zuJG5Uh@*XdZH2|*d!ov5vMaH1nZ0X^V;dFur;~>ldK7!t4n;Z<aqL}ReQv}-_36op
zvaUa!j4WH|v34jY%A`0FpV)n3fJ53FaZo*eftsM0iw-*cCf5O*>r26JcOQ2@_WMs;
z-O@ES=i(<eF7xpoYs&u9)c#(-IlNdpVLxHt|Lx*sKXu7BEc9_}b|_(dCavNcpYk+5
zz2wuUKW%mLvAr#Pwb`F?`j(9yd$Ow{avT-axX{rpj&5{jWP$IAi%xc(vUioSek7vz
zd2(_Nm6v~$lOz3W;6Ul`-RO*9S!P*A0VhG*yH0h#<KSOkR%W$!u?*$qhjMbhDVP2=
zT>4wA@`;mO!pYcJ0nJ)-!X6vD=7itmOgAJ({q1tGhPa<bLn4lMY`MNC(7O0C{@M>~
zFY^5i;q5f47`9WC(%aSd)q@`UYnDSNhLualUo&sCjG$~^qF@G{D0_k{B*=}N{Rx4R
z_&1kDktILpHA~kw(s7E~w`$oL4WVI=SX>JKY53EF7;KFGL9UR$_Jh@GIF+QykxqW}
zy6c;KzrD+oH|B)LReO<SbM;uGCp=Y4dAmz3LJ>uWMisaYI*?tEMD||dJ~jn?Lx22s
zd#q*!hJ7ZR%c&`6?1EJHmC5K2634FSbH;8<b<asgZ%rJVjhCBJ-8UwqHzbZt?sFbp
zA6Jj8yGH%$rEAo~FJ7xUmA-(I2q?*bl5&RE^kK>qK7LKoXI_(XDklTVsetlrK<P!=
zNu-@Z+P6sSbq1@J$CpRcOIO5KIF()objo>D4IEJeU#ZTH6&=e@hSzvS<niVQ0xWZU
z`I9Tc521v6J+VL_AnoU`yCu9P0JuQ4`GmxMZQp-f8ci{7Tcu-n`}mLDg*6qsS5ynf
zXG+|4C-#S>Jg{qfQAM>R-%uM~%B}Hy5J<TvxFR|35lLk9a0PqZJE|1VYt`@J^;;?n
zpWVBb@BYKC6@O6Eq5WU&J0xx6Z?KythW6pJA0GvuL--uV=PT31jfJM0uc*C!_HBEM
zTDkTe9sbn~&R9hkKT(xUPb={s`<ok_vgsE}d{L~j&m&fLd-;hQDhGJ@i3eMM{LGPw
z2Yn?~KaMXCU-Dvnh0+^Nr0TwHR4tJo%g;Yoyh<r4ahrSd!~G*aE<rSRX7p*GYmgrW
z7N!eqsf+7HuSL?wtPDSwPNqorh~9jPu%iL1Oj!l62#yM1AwC^4r$fT&;FfffH65}M
zP`)%l4&I>mRu0|>#6hic@Misai$YzYm?=nNT|iJztW|o4p-*g_U5YiFzzFZ_=y<l(
z$%>A71)nMnjJ0us@3>SDYvTpqNy!>(Gdp~JV`!lH_==;dQ=hKY%Ntji6nUdn^%pHQ
ziC6y&K_$hC^QXk=TXisT*4GW6HSBKKEpsN{1T~<z6RK>PuGCbha^QDLie_X4S|i&Q
z`#3e$UgA<Nmjiu@$1aDGh><K|1Q;yF-R4qkcu%R472iHyMVffub6RFOuvPK!VO47b
z4{WO85`Mm6A3n~QJBe_1+oMLqHF$S}Gm<|qUhJQNK*7AY=%0x|;k<Z>e-;8o^WvqO
zi~a6~eVavq?Au&|^nII4k+^UAGcl)snO?^-)F)BhQUcF?;#;-i)sw}y=8A8R_H*KO
zE9Kx2v^%AR6hZA-F8;)!<)~&k8qZ6KwKK%G*0CaMgan@Z#J4XGr}*m&<UpxXQ-t9d
zsU-Ys8urP7GQ}gx+*rkR$l@!aapA`LWYuq{CKM&`+~?<dzV*xWj^U8;Ub@u8U;Q(E
zEaZ)ROx19rYcj35SUu;RAa69Q_$Ub^D~)QAybL%USx#s`6bZP6l|=x8s<gKhRqs6u
zR>_Hbm6V+DC~~M&ja4Z8&MrBmDBd#vMOfK^lc;tK1y02<jSA)(a7z6E?}Kt;fs%4{
z4L$CjAS3}ui+Mu(IyqFL?roV+JuIwB<wkTe=ALkokzxjhA*`g_E|9iltV*d;rpTdU
z6@zsV1`A0ayVVq`RNRGA6Q~|>rApgK2dh$)O@5*C7>gPu__@wQEO@Tq=k=h=5$;W3
z8lRnH0M=jPt)<K^<qA1)P)W6yR45ZrCA!o5NN7oM!heZ4dp|{(RV5{^|3nsE3ad&D
zddnSB+(}g`7Vmo)krbvVN<o_vZI{~Qz{m6&ZM$rgoS2VcELN#1IV3WW6e5(wqa3Oc
zSsm!f<!15ayIHHNOSNX%<p7N>t)qZ~{P$9kPEj807gqno&x_YTFK=j3uKkJX49D~1
z1@XehB58BJzZS?{;IG4Xp??~_i~Q5)?~^%KSPig$GIxa@N)RlF31IOJSbQ_sOMIy`
z@KtGGte~b8tss131>t+v{Cz#cdTtQk$`Ri>Z)b1M3-X3v#?+pl%3M7mg)mB~kyQTj
zlm6pC&WcDrd-}PGu*J_i{br~5TMt8bcZ{KXIMwqlEfaT4b^19XO%DIpl(Wm>x6mrU
z!n8E(b2e2p)X0HiEJmle@vwv;Rby(HdM9%^3Pg%Syq`m)vdD9FyBzvjX?ao(^(ZYR
z)pnWNL95V-_i&@iiT1zHngR{n%iu0%aHi^aW$yPtjJKSPhi#3ot#pRv;9pdHlzL9B
zyj|u#R(-VrRlNGq?VMR0_l+DFq<FBx2V>O)%26#}9Q>$NeCs47zkBDWt>O(2iPwH8
zeJBSC6hOEXi<08s-J+zLI7w*Y{6cz37eqlKN|YoRp4$vLX<~V|#`{>9sz@#ZJ1viS
z`H@R2llXqGGU>UYvJatuf!p#EbGq9K_`25!)QhE1_c?{ytbE;477z;LjRi`|BlLtM
zv-rwY6j^VleBuYC6LbDuwgOw-@a>#lZoPxx>xP5iP@rLvmanZJP^L<UmbYOMt4r|S
zA-;bp(W;r^)@rGawd(ui%<7FWMBF-G8pyIb3JGVxjv(zQX7K}#Vr6bC#<3jF-)US$
z4t$6SEs+E5Bn5yQmC4+DM0S59zPg_J0n~VpR@)dFex0|mIG)k0a%FFeK=|{X&#p@J
z46A<5DRb`w4I$=I8)U0cp*WP9YPAUi-(Zpo>rTp+a}~EAZ4rGA6{61ktprK5MyTtP
zh9e8X(>l@e5IkN8UeMt;=Eqd=$Ct?)^A(Q;MKo;HK^csbif?lGxiktnVrr>pK&hv^
zlJ^ddx;fxv324+*RdQfxq97<38Sv26;!Vz&D?Co#=uk>Mwo=b9WEjPOxsS(>AMcis
zb1;ery?s&wO)Cd6UM1e7Ngnbm%~%cIacsdR)TRsliyF2z?Ap$iQVG<b0vZGANCDOx
z#)$~$dji723&hE*l+;pFIMF!`9g;0hFp>@b6-62mPF`)YXZjP`98&{W6&s!d%aVm*
zif1A+fR?_kHl5ScO^B4&`Mw++s#GY0r2%qaCuW!}9)}Ta7T>!M@K|o=Hf(+S3#s7k
zFZv}h+!&OVGmmO;FG@9?*RWL<M))c)*G$-uLl)wBHkx!!T(pYv=%`nLGzFqplTFHD
zL5sC1-;deq`I^YUO*iP}Lk5*?i$MawS0poy3d@%-2ev7dW(@hC#CabRx{^diGLx0b
zOjd#n>|oeiL5QqLS~kL2lC*5pEYP2jRY{2Vy#SuEhn1Xa<H1NeFm_T-tj$8qqyq(g
zs4s&-Myu^oJq7D6UQbhjG@C)V3th?uTC?4@3I)WWTuFr!#UC1(a-^|(rVE-1CEyO|
z;K(zeax()`L|8)IK>rykYhA*8aTJphSO1ObYcG+le<D60TlX+_Acr<9sWgV?5xTsH
z&I&`7Mc(TPOX~}~rSir+#rp$>z*uosq3)z~4okBFt&!###?rP^nz8DTt}V2Nt=a^q
zk+UhiqC&5Bs{suO3H>h8(C<yPskEmX_%5zpDu*_8t9^h;$f4JjROesi(3`-v0S#NF
zvnTh%Db|(H7Nxg|6W4-OwWiBLr+qn0g71Uq=ANL&Jkxxm(-GigS;>rS5c0c0-Y_Vi
zL8fV`s4Zc_RLXaOkqz86^WyX4EmI<fJiEkdaM<_aYz!TqVu%Nh;tw?nWDlnrI<Q<n
z#Ht%j^NwXWQha{592fuz%~OyC%WEZg`QrDTG0(L+;rJ0F97(n50)HV;0yE;?j&)DP
z8Z-oS)N0TWYZeUw1$NTH3d<W!#PlsE6>nic@#f)U!^cd7IYR~p?3FiiN{boLN{gwQ
zmrDGcG(?L$%p%RzxlAy?GB-K>7welMlP)1h>%zU?lI(c>wwUKQ$y}c9k6K+y9^^h?
zZ2eww$=**}KWe3vl<R;M`y}xfi!w0>E$&`*TsRZaWkFYq-}$sv`gIsWU~q}G_#fD`
zmC2!fO1<F8^H=vYP#Cll3wxjHY%=?c4df5~7MLhbUbh8Q{D9)Emjhoa3C6GbqU|LK
zdL;}vr3GkV$$>By)UgU>K(s<B{;EO&sUaY3(LqF(M#_oVm`7pU0;x#mI9hSz7Ek~P
zhOy%Pf=>K?tE4ttQTtjsbO3D#C*?$KOs#i$eh3QP-TqSTaF($47qrC`t*@kf(=MX@
zXCl5LrWQzFbho!yYsY6I!-zbJNZXki>#{Tc6Ac8RGj_1yl>EvnB`Lr1q>^~YDlA14
zmzui4#K%M%)xu!q*Qb0NE>*vMloPl7!q3G#0|^rQowi&aoiWA0MiHY62BEF!35^Ik
z3sG!HF=YM^W9oKpC`Do@u;Iltgw%j9SEWtFy{NAaFbYU(flS%gidJxfF4Y-p6Tl}~
zF0i?w7<RWU)u<N8!O_I>k_g7+;CU35LmNS#L*1-M_tFfp*}#Yml9c!l14{fV@v@iX
z&<0XN#h3qL1++sxi_!A1(Q<)WKB{>CYH!5brZ>D-t+Aik@c#k;wHjHqR!3APqJ$#W
z>|R1>+F<lxdx!SBlqNYiT=8DrG|;~YssZQ(jBcST;>_!^-sIr9)GzE&^wBccy^G8=
zZBz#6!&n1a8xjWYQp#yiP?V9&7?6qE8~)51ft?xlian`r!ELKjra}{uqJok%xbN76
zZg-DbCqqIXuIkNWDG4_0BdAGG?i57jU<HNy+~&kFV7{%l8yihI^k=n|7k@g>Xc-{i
zo@2ad%{-s72`X#l^w*8FL^#ckLVsbr0UHoG^f}R7zM9`KLk|6w&9@vJi2@o`bBt9_
zv-tE1%>Lg1{TIbE4k3jq>Xw6}0I_4mj^$KL$MTL9$V7RdOnJ>}m-zPapZ86b#<L7m
zIx>B)Jjds0wV|GLHfqyZs)ELonnxne=jijY6*^C3Lzi@$Q{6Ol34<1G%!#V8QV+lL
zr?S<ofXc}mbCi$AyNNSjqqx^kO`)KhMf(z18n7X&)kA*MQaf$S&zh2xl~P3IrNVs)
z%)dDmUX1<P^@|13K8KaH5ar}%pdF^upmVbU^9?`;+HxA;;0$0{cFRzr(PmTUmvZPz
z)_#h;nuP?DbQg8J26E|{oiY8}Zc<8CH#5~Z&RPx3XFpZgMED<HYB$C{bR(k^;^mv=
zkXy7bq!vuB6YW>h>*R&v<a2fiJ1je_J8W7Cb%jNDm^=6muEQiw1}e>FIcFoMyy<-w
zzL6=s#Vdl^)RRPK7Jv8d{93|%my*--H@4L3WT(8*21Ssehe+X7Nyest3qol4t$(i^
zyb0_Us!n3M1DP@%3L22nC|lvTFXbj~m$`Xi)hTsIuYi6H;`S@;>r)yXz=j^A_CW$_
zstBii!(gLGMvvc-JmI@yEU^?WzM@-oUc5uup%NnR=xFRP?J(`&cJMpQM$g5YPDV;y
zhs@&CPdaQJ)(%UDVD!GDgH~9F+M)c1BHo@DDR&*<pSc;2FyDCr9uc$n_N#by@jV|!
zhG1jfIUbJ#W^sKvo(Hk3{ym;w0_saV!)Ec<4m=}#=R!QX@cP5ZP!!quIv!#EnNB<+
zeDRlfbny+xzN4k#c)f2~RXugT1@d6ZZI0g+a|>9L6XJLKnzfWykOB?C+(<o>3glp1
zjnunspiaTKQpr)~wE&TW-#}Uoo`8f2Rm*EOyJTq}|H=4IK0lR;&87U%9Y*TqWgL;9
zibIf^^a!3J<lsrQ;!uvv?IeBh#JPA^TwPaWx6XYMG?NtpR9mHh9$Qe}^Uu)>T5Og>
z>oCWy^>qu;*1J5{4!Emd?!Ig9N@YdFP}rIIeWhBTH=sk%r%6*IcZ1K|g2BidCU<Wt
zayKayr+)te*HMAgI%z;_z36|+QXi>rZ;@(wuFJW3eyb<F3SVHf|CAhhK}oXlPIS9%
z;PXW>edy%S%j#EdzZ_bx9`#<}<CqkV2_U4Uu}_os<MRk3K}lYw9leAN>w01)<<$kS
z<qfH|%fcQXbP*Oj!|HdGGgU9<1uzI`f7$#&3ZZsTk#fzoYm&6PKRK16Xw!hU_j(-x
zFr{-z<sd$MfB<`|l*(raTPDR<gkkpL)(|CbRE4ARH4`z3;^Zab<Z?!nse}Z;MFM}0
z7ACeratJ##G$9HNG{9qO)N7Hs-IVY$aUu*@x`8yiMcwi;3n7QQ52@>vsY!yN614bk
z$T;HCghrNZBbZjjHdKLr!vn#hR`HCMgJeZ1^%RwQ211olE(>EwnE;uV0@y~|SfBs`
zO0X8o;TyCi7{{Q>A#*8|zQHB&o_&6SpVt5ZGZ;szuvCfP1)g~KU3YmFVX^qkfEBR+
zh}<o>3*+}-K}PO@eJEIIqOMEv6_Mo(Bbll_<vXdNXOP5SLZLQ$2NU>D^z740xVx>;
z9FE^D3;xL6Y=Qa(ubH26Oq|!?q()3*icL8<olrrlz24_$#193AX~=+NOhf>H>rjDG
zxr|z|h7u*H#CrBn#!5FuA_pWfdWRyQ)$d??9E`(s7Dt6w^E=Pa6b}-z6VeyzWfNef
ziNWMkjW!A=qiEf9r4O^tNXoPNtOMkjye!uMM>sDFyiv`Sn+YQshCoS+A~Y-@sK|2a
z92+`RmD{a>HmW>{PGMpkh0tL9Z>Ci_tZ3gFHYUHK7O*r78+0H`LEX@MV@T4y-*AOf
zeDkoM$0(CJ)}<5$C=EdfnncV$6SsEL##U2EyeK$3v6&jCl**Qe)FvJlg%(MnO>7$n
z1ti!bL}%Lb*7F`S|NJ^})+}hdF7Z{X5D|R?z_xAy&vIq)EXw4?Hi7Cc)*iOb-P<|K
zf!oDdKBsJ%r06<qW4|K@@===rYj++2Lb-@-3@?U$!xjS=rUmUsOJ?bNYpiSww1;wF
zIO~^7fmTd}Zi@6o7PWIX42CQZ^gSLZZHCa+hp}BbFalIyqd4bX+VfX{mDRqFO+9wg
z*x>UXsP@?I-a$H3uNCS5vGzms_A=jM?2e$eTb$}_!4R1{TV!jlQUje-zzMoynXPIA
zhIT-`4>^&QUO<{}z7|?>n8rvk$cDtiH2Kaf?1q9gJrdZ+rM%XFQlI0=jg_)}Aoc)k
zK(MdV7!sEJr8_toTg0s0;A>o86W0M&=PwkkcTyrYgnkpYgtSAX4dE(nTlL)%#oG@@
zMiQ%^Hv`Xu{J4wo0H>d~6;H?o^FD|;Nelh!S$HB|4n#%~cpE(t-*yR}2Xi{#m2InO
z)baKu-=jn-T?Z_FL7Z|7AqWh2&%qPLy>lg=kQm-sj^`nMoasA+13B<H5K0(VCYi-w
z`Q%^@-uTY1oJ}IL>O$wp(7cZ{c+x_KFQu~eSq05w8XD+`zfr~7pmSUq6_p|_LK0?O
zcVYWFC{3UqrOgdqA&eiO%~&CA#xQB0lL5?q0F(NKf?Dw0H}1L4%fLza>06alKr!|U
zs~>D$7<mwQG|_+I(i}*x;S?moH4r-^58~Oz*&&C<Y6J<?2G0s3m0%13mF2u57+F})
zLr8hr@6roOCXAvMdZE*#4Ba)hWVFU>BuKN2Xe**UMs#*lo+k-7(1#`Pyhm$Gh29o{
z+QO3YeOg=kHILe(%g%<35c~(W>Ch0Q+#GD8A7ZqoB-NOkPj$N!*dZY$=@t?(ckeAw
z{(h)-yNfWwu_<~=1yc4KDb+~XuBEsog#A+}hio#Fu7wr9<MiUS#H<>2WYu6KrYoUD
zqY^DKUC$2GBd~fZ(2bpndq3+&HM+5#HhL^E>6Xx5Kecx!isI15B-(2vrn^arJQ5RG
ziABg6GjiII_{|g;UP-vEQ0xq!pn;&8+hIK^=&vA_X^=^w0b})s$7PEfX0}gY;D(<3
zPe4eh%}JL%P&RSs0W|Gs5zj)~RcW#o3m$lWtr%;EqA;+nmTBj6W2AZyZ1bJ3!)L>6
z?+3G;U@|&KXg9Zk`j{V=1HY$cK>7}B*CTc#yp1*Oe^@Lv@(-|$Tn)Jbo(|%}e+1?J
z7OafAq)h@dXjCXaB=lj1>fD&2zdIM5W`d_nfu5g?0#Y7(S{my(3BpBP6W>}l?gh%q
z1_5d<LrH9dA&D2Kn`Dd0Hxv{cR%**^l7|AjpxolfZUCAgky?v|Av(az#LB`TvbnJ~
z8-}L?3MsUBmkO$q)n*V7W`(gdPUE2k2mb5LL<DQtH1Xm3rV4*GEK1q=v|UR-3(4kb
zetz5wB$@&N^tMhyE8BsDRP`Q&$ufcpVMc(NBFf}G7{!=9Axf?*esd3Wbfm5Z>jn01
z*QmX*NJ-g=j>FXj*lK;(mxJ#%-xDbKG*=f$fS`C4$|cO><svrJWTok2RvLJTu`EP9
z<xqmGJQzSTlQH|oJ%`bT&5b#?7<M$H0gPUckb?!_^pM5dxDsUQSpb_IMe&4>onJA2
zpUzPPC|<fz4kEx8_bh<B$SU#WXYdYS>1K+rH^cN1Ea|xmwskEn2bf37l-`8+{73@D
zq|#Gq69yC0V5yICkhQgB3`(#-S2zX-Fy+8zTX#z47KPQ-m$q6~U#9KT#j6e=4ya(T
zYPcT(vDvg>vuFLIOSu$c=_L&NXfZlsi1ebNW|FE|_XjZq%`+1066HfG>$bD=GBWy`
zRp)ne=v!`@{>=98;FA}JQ{kj8GroXr9+;OVYnZl~MJ9!k=9#2WpQK8K{bESyw#VQm
zc3Nz~wxZ32+oe~-^5!p96c6b&mX=<-0SxI?E!bu`<ZEGq;L9YU`$}0Dd)IXMrK~Wv
zpom|_V6fXqSj!8iIfONtm$m;TRbES8D|-5RmR`d0K_&+5vn-4~CvY3aptQhFjmikm
z)Hh2^ejcoIm2Zgt(!$!VC9FkQaVvTX+sC{A)$grOe`Ao)3uyT?$UWI_km$10{Q4VM
zD{7$mpoUQ0Y<GY?2Mu^P#Q%E9!*fr`!VNxE4WRwBT7~ggDFNVd!1(WM_+7)!;?X@X
z)LquFr|yUxya8}btb~&Y_Lo@c`kNE-V4%r_O<7<`iD=&>2L>|wH>?z6697Sm087;n
zO`M`s3Uc5=7R_jp31)X9pW?JWIKJo<bENMJU`-5uUTtQJ@6UwZ)yVu?ATDX{Q9W04
z9t-v_vF8yqh1Z+1m6}2(F+a#qt^!qxM*KkQK2WL6<vL&#fPQJIoz#GV<4k-xPVxzy
zQy|JvqaY`pFDE2rsR`oXQW%5!uuIb353u)y_Ac|is&pe+(}&3kFYQ1S@}dd!VH>Qy
zAHX|oyeJe@r9w_DJ`ISy6ObH8P$u{*Vc3}1DXu%er(O>H1y~BhAP4(2EqKhdEUbnC
z5W;se`+gFmE^olpvQCa+oeVA+%G)>nyzZ%KtEPjCfJCIW7lKq_>z`D`d4GGOZqu~a
zDFq3g1=4?O?>bLMbkbdj-6T}yWD7vM7~=;8M4Vw1aQ96$;)g<<Da85(d<DbCFVjhe
znqG?^LGer;VpT&~^tNDBZ6Ps9i++^LM3a=pG%u8vZWdXCs9BUsY(sAt8H{2o87Wew
z3%ylxa2Nqu0pu=Zu5dH}g;P~nKVWhp9cj-WovYo=Gq#w0Bih%x;YAkQ->tqeBb<2q
zdGObmTKSnY!#9DF2I@&o6|HU~@k!|l-@JZ_)tST&X^78Hi7q3jCzJSiB7BL^harp1
zkPTx8(Y#}{V|TX4UW(6bZ?V@_hU2pUbTrFm5!|0;=ZMTyrRyR9Evn6FoW(_ER-Tjw
z(R&%a^LU2>r*W1Ufx|RL|F)o*+Byp((KJY$)lIE(Yg4bVCgO$7AB-6ZX3Xd%OiE&y
z<q&K^Lgze|MVvcFdrp6Svm5@Kw>KDEH}okqSy&}wkG63(rIL?71aF|wr%Giq{*YlJ
zFr``_>ikRgn^ci`Bj{9iGK(N92Qw@zY$|)q1Q*6GZFAo*I?L#E1sh&DbU74|*kXxS
z|3D61LyI0}3f&HH&FOXkN})Q=v;$nna$bRgc39-lb!?0C9E-aguE7@ZM?YY#0p-cn
zDbJUTT6TgmLQ&-#%UDc+*bQ_v<uMQ{l7}zC=RCHSIXzne%T_=VnL&`@80CyH?TXAz
zfJ;`wZ)WO#(wk)K`sL6$M^zZSL+2>T$`bJCONjmTL2Ie>9(%xZlN>t#s2b>2w^+JK
z*9)eoB$?V*4qXVf-Fc`-4qXO5!5lBo6Yqhp4|+Dr4~647O1jLL>Rj#7c#y`CxL!yI
z5s$`(l=ytNpE<01G-j!sl7kWOEa8Zu7@ZsOoURQ;aVQ|8{f^&xr2UuG{Ky%;(kc)2
z1tP%_hy>{uCBC4&#Zg@qSpenlh~IHTBMT~zCt5w?s^yy(;PIrg$#&$f1s>t4`6G87
z5uogfD5)sUjPN6OMVSnZMPf&ty0AhM#8hi>vdu?9XU@?3ch6XnjLld+#be!Md1}7&
zP`<Q@O1<A(o7Jw!d}7bk7sln8ngGIFWPZgV+mRY6K41Fbe;A6^`A{sPu~~)2)J?XS
z8=0Z_jogU|5*OSDFl=66)u^N4(X1Lfd#LU@eH;yepWoR7eLn*uvj{UhFepu8fl&P=
zYqOD$Ss#L7HBy%)43T8Jx5d=mVyZ=XkvfQQ!AkCwubDX#{CsA7)~eb4GsJI$X83mB
z8m(rCT0o=V=a3eNQ1hbgjno!Zv`J%A5%uaM@e11;V^iIist8-N!geDp2melaktNj*
zf~~AiB1TyY+4!F-HnUo;#G7iBk~%g%85@)6zN$|v7BLZZJj$h7Ssi=EBw|<fy)jcZ
zQSrT-)GhpC7?7ELXH4qY)pBqj)fK7R+rrgOj@$+ld*t?#RQu8ON7ljAz~o8E^~TIi
zvtFN_E+caLmfIGaKWQ)dqy$!?$4pHY(PrLDS*oEwTU(4lF2dw6VGS0dzp8G3e40LC
zBvm3#ft0F^7g<=^TP)BzgODrez_j(%`KzZPn*x=C8k?d<rpXhdYf?BY!lsrEi?pwg
zOslrY6R*Y2VB#;=#OKO^q~d9cOsg;PSR&Kf@+@-DB#pwm$li1D&PgSBFJ|vKc;}Hf
zkW%7zMD8G!`gxH%T85BQP-Je^9jWm6<lb1zknVa33UN#0+#ym$<c_Mj@wrl2dwA^~
z$TWBF+B>T4k-2!8OWW(Yk-3ekHCP!q<*U9_ZJeHpyH|k^{uPFnU#>~P3i>x?J<x)T
zp#09TEW94MU2Sj4job!AgWmr&s3DDECaeI?XyZLL0kr8$&&=NF`eW;=g(kS-vuWV<
zX-K?jHDJc1y01!VWdVowu8*kefXYXA?qX<b*k+XYtw7s3dn32E97ZF|@M#SmgkUO_
zQB*m#ON$~~6AT0g)o^^CRw^{{k$J)R@|Efey`{l}N+R}}1-3&2E8dvC$^H6_mGg85
zpu}S);7F`$PJB-HrMJd!wakmmYqPwiLCGc(lmLQSfB?WQW`;D1BIJt9Ss%G|U9|(x
z_#A}dx1v$;TM?$UYxF5{s~U*RQMcTxTd06JhKZ_OoLr58|6iY|VG)@=`=L}4B-7k2
z4bDchR5o-wrVq-^-~r|VEcjZakp>PEN@4-|TB-{&I9jSodFeOWR0)~p%<b1~W(3JD
z%X?01UGXhIxoPN}VSC#P%iG#H;WcY-t+q9Bt#zU_F`Q_v>r7bcB6Wnp{K&r;d+w-b
zL1ya-N`%^JBT6=+%o`cmGH+zf$-I$8h2Fk<o0zscxwqFyWWUkvP~F;2J+o<5+$tn1
z9YQninIViD+f1cT-vfjBVXqUvhYX$bBli&Fn^VvYhwDqQRoAw%G}gU7(b&o!RkPwN
zuj<Wgj**hyG($orKOgm`WG1d#joh>M#cKZPd%$eS7h&@~;(~>(_kibT3NbdrI{ybN
z?a%+^;339Rzy{eiRSq68-WjEXNN^MpER){v_yS}ii6lL<VH_Cb*7Wuh7LKR^bRZ)J
zbZ5UP@jI!Ey}yLNV(=))=^-^fKMFl~ksLf6RU`9Vhmddx5=uZR1<D>)a6o_(kKi~E
zWqhfYpO}k9-K9qEq_Ms=awmp*I_>(VMDDCSj-xukuT)4Gb-#XN!R9;h9KL!!cq@}o
z7;hC)+a0;Yr5AupPb|w$a~;$Z!o3sAs5<OGB51`C;)@X_(Z0U=0sYt*Fd|DdG4w4;
z?<1zzSp}0h$=GdEJR_Rtqv;@+)H9UXg_9QLto+D)tYU20BIvf%Oi`LBu>jMni4t<~
zSbxOm#lSLTg3d+h^^Dcuh%I@XTg-1-GZ+Jl6%KP{-r+(&F)OpTC_AsYPpZsH?Ddpn
zrFyMYvSe<xI9mnhn>OE?3k^9o<>r~6TQyUgVnXIcJ%ixVSQ4!_dkUiP3(bkb=p{tk
zavf2F_FXHLMPW}tij7k2qba4Bio6!0ICy6%D<55iU#}KsYNh#~N!P<)(tBUjQ-(T9
zsg6RbBbVy1MC)_C=VmH7qo_<R(#@IhS-}{IzE-OGUSQcJpq=S9(-fV`v|mYll@@T1
zogv=>iN5;xNaW2m#zd;gh{<Oy<?J#tLq)G6(;Db6R+E$ijaAyWg*ePKng*g;$-ONX
zS6@hS&@_F+5O?cuOhE0UT|e0^u8X)KKu?z*?cUomyn1X@oc!wJJ*LM`aF6%!kDo9<
z-XlDI!t!{p_3>Vt$+YsiM)x4;mPU7xG`Z1jmnLObxwj=(%fE7*Y2{_y%5nV4%gigs
z2`ewNto)&M<q!4zrBZ&Q+acK--2#a+?v?K8vJi^ECm^(r9I!S|Z=D9(=zCV{4Drr)
zrWb)@vA#jkh_wjKKqeVkvr<WAnE`F%hZs$StPEe;tVE0<GXap9EM8Z+##j{Y7onik
zm?`#pn#)YKt$++nQ##0P=DWdQYWhB472gjG2C_3sgELkIvzXG%VxysNJrc4IBr%)#
zG^|f#bIO)JU|%YX)U`>uT9W*{sCIjV*1BgNH8{E)I>B6@(j}%Uzp3S=+rsgCkwh*T
zc4Gxp-HTykTfAhfQMCmtXVNfMGoKVA3Fp|mZzt*-JtJ4QYPmOZZ=3zKaH8=(YvjH*
z>o9DKPrzuEt|7gLbQj_rXaBUS`;6M<&^JJ!Z{XY7crT8pz`5++Eax&x>5bjy$&1{F
zl7m(ECZw_fsJI>S@TZacJb44|i`<8oYW~2Ka9<oR|M!NB#c2KKhV)5=+6a7RL9O*R
z@8i@(uzriSY@@{Cb-na4V(z+L8dL9&-%s1u2O{_HeW}_OdEl1#{Zd}!{`MDZEs+Oq
zj^ED;sw}1Xz^aMdua}gj7g%o?GE{~&cRyB~Hnwnl(j+&gd&%%0Xt1$(81o{*De1Xf
zXEEdk=Q+Ro5fhYJU7943B?>|9-A@dXCTA7mEzB;1mxgAgB|Ss361@f46);|g+TfJ^
zANbiVQJPh2bT9TC4utKXP@q$_jAtFEp{dd6e+%PT=vkWnGZV?g=4ide<BZnld21x>
z&^T{>R*7I-c4AyP8sqvm<q;S97pqERTw3^yY6(m$L1SG15iFZ=p|NOqx)W)}MU(S?
zV_bTf|GzLUHl$9{QTtPxt~}`;0pCSQQ>uW-G9`xf6(~wc0nyD4W|P`LBUMSaCaB24
zFOa6^Vj2i2sO^245jVJ>d;qkwgdjR;774!v$Z%i46oNGOj($noDQQ2h16cOUsK*ZB
z26By1q-AE(IJDhTLDoC008!j=p~YxqSD`Zg317f|CHGBHp%|<plTxN7|02+Tu$H)u
z6s?f`l(G+nVE@oB%bqD}IN8nAXgG~QJ6I61GmL^!xb(LPpNmiI0c-o54r&Dd3gyn^
zSDVeIW(U_ifNvgF)Ld2Ee396ES!wfxiss29o9jk3-&)zcpsM+S>gLBLHa~Pt^GZ+i
zFXlHtzo7Z$JDXpxZ~paN&0FtoZojAbkM}nJ`M&0T4>TWouvuN$eCo$0(=T{d(OQ1P
zEk@v%T3{#42WZ0D18?gI5AD+vL_OkFC@Khoe>JHGHWg}t127)2lz;)U3F-}snSY6%
zvU0l~cz3uSxF1GnmT69p9+<byh`C%3Y+9oQ4q$)HVAtg7foE3ffoESal0Mc0o8o%l
zO$h!h*PD}!01j>Aa5wDlq<rB%f)_e`4&+y!#!((y=U&*Do=)4Q)7B*TspKQwp)CQ3
z!lR_&h82fgMG(VW^x!pslQE&+z_;q|&lov2>;W5kuoc;$Dj6>{?<9H$%Gl)%FJnKg
zBw&Vsi|7X9R8p(unO_meX%1+xd%-c0PLaWG#_C|cqW|#6mvZ7IA8hBWgsA~iUk8``
z!+%1Lh5qIr*b07O#2@b;zt4#OSO56^M*P?P;}y1a$ZHGtkid5jdQ#HQX<NB2A1*Km
z9*4RJTQKJNjNK|gkW9}Ap2xIuyO??%uC$m0*h1N4z?cZ?p?TmWAn^&6O1uu~RdqNL
ztfx@;2Re<R@b%<j7Nx^JE@dcgIKip6<D|gDO45%kF!SdXK^*BHK=#_uD00CF4T@1a
zLQ4kl_w18Hx063d=zbp@5<_>yR64bcvp0hSATw~Vuz3|Pt}*ekt4rpQ!v;A@&Lfvd
z4|E~;C;dRXzF{8Bns>rI%!6k=p7Zg%3(p03-i_y-c;16&J?fbUqJnCWoi*fkYDnNq
z&B;`N=MzjLcw>apr4+&233+G3XOB+7PC3L9NuY#F9~{6mU_;@30bHyYG#sPg$Z50~
zvjUIKgd8}`Zu!7X7jP(~(|^pdRjZR7^t+u(hrbZRB<p<m3!x=Y)WCNJQGq30{G7}6
z1~3;M0t_rUELE{c^2jnEBRp0(YS0P`EICy7N=9;pi#Q4Na_DJe+C$Cy)XJe>AVell
zIkXxfGNj5OS+faIE$|Rv!}fHO&F{h;8LJy24Q<>AN`mW7jYN}!vm}`#dE%Vy(v^VW
z2g@N;y!PkSPfc8PP2(hs)^_pImC_I-3-H-xMW9u5&rYh2hG|{{TW@mc0bd>laS20|
zg)!B0u{Pg7#%RySye`6%=G}`Y&3gl$H19vblji*)TnZwGejFtwj$z)?`tbm!-yj*G
zkJ!1rFcB-bz@Eph0NF)H4$;3bnYGD5;Vk_Fj_*=%>JYX{6rr8pI|Oy3cI=Sl)cdiG
zY6#(*0R^qb1O%}H*e*m4l5YdXnHCF!oBa<tw38Y!jE&G)8^O=n4j{M+*>o7%wqXvS
zHS$@>lac6<zQog_0@yj?*jz*Zug^89RGIphG|ZSHP&AAXN{H8K`QvV_q4617-Z*R-
zgeCD=TD~~!5@ZdJ-x{d{S8W+&Y8k<`oXfY2HMd+Yv`nzHTyHg*TJC`NS>yE4(zT7#
ztc}ypmwp82v&QM;q)XZJVrdMEA1_rsYI?-9#6AC~uqZ^_P$$p8XC^+g@R_YT8F)$q
z+B~gwIzM}VdO9ER4Zt8i$>`2wI^B5$^iP|M4eONDqxL55ZJg}RNuTV-jY}GR4HY48
zJ~QSLEe+)>bnTcp6GzDNAyg+S^GROqgYXEX_vMc<-sq&ZrVV9jeD<3g4ppH-@FglD
zS$V#m2X?7Y5wzbIkiw0ML=hJnVVJT(YD3mERi~rw71~kvJUV(Yi(R$AKl8jC%EQ@q
zIKFI^=#3p^N6uH#TIy$dSi0FVkV8?Z5)yqq&pl?^44=5DA`4Y$NH=aw@r`7g7`=0?
z7GFjB-MvH2O2r#eGu<Uu*H8?yT$R$>UBg4Yn@)qmwAd&GUO&Fk#tXSOZxLE8Y*x~Z
zv@<0<yH;Yj)>((zbQwB}%T79%$RP*1dO7PV-YnXs5Lb{JBI~w3!#JoD#^HUM;ash}
zkeyBA8|ZL;R6TY|Nx?1Sd}FLJ?&&$em2m0C{2eny!#-YX$rozVXx5TJ@`jh*UM`3J
zkw%}t<3=JvkuT7^^Qn3N79^{kbaw?@G8oIw(e5}QM_Sw%0au2m%h(BD;vilJyGjD)
zz3CmeK>;ys9Imv$?Gl|^rGf07$9elU4$9_1%p<UK4EgggURI&xQHfp)^VW3Ai6R^l
zr2A2RNA9N;$_VNq&gN{u*`7zs;GFWLyiw36fiBu$kc?rCjp+rR!`ujoJ=w^e2p)h`
z8nGd~f<OB5afd+;#gbzyI2M#?6CaY{#EMPg73AYyanLFYUlKlBpM?W}9Qc&9$btWX
za>M*MWWY}$zTs&2#M$s$*oA}+fl5Pu!Fy?T{-OQz@5T~4GcPL8GFv_T$oJ*IUJYt2
z85dzRHN&n&RgZ-kHrXC)naGTdFuDQ|TVsfu%v%|aKsQF-HW5O^$HpBakHAZu7)yFU
z3h3%8cxsJ=z|cXU->WjH%1_Hig@7~eA~}f-5eDK@tkV4x^HDH4d5F_@QRxC4X~lWF
zzh_0YxmvGkX+GH05oXsEr7#M#hF(N@+F04VQwg+9fPmLQUZUwfUzqMQH4?`V&TOP0
z6;dnVdzx+~yt--ra=f=uQ7)i41E3f1S0_!X>)_}#F2I3y5PGWs%3~pGD7ox1WWYUD
zJo<a~G;%10Uu!Xsd|=G*#)Wq^h4^&H%r6tPIDuqMmTEDJ?z=!Tu^#o&G^U&!hN*Uj
zp14{@Qw`^6E5W5)m7aJE>^8!yPvE?Z1=`ofVWPI-PK3apl=gK};juOWW3rt<5V2kk
zd<LX3E`7OBTPaNIJbw?;AR*$WkX&|C2!tZZ@~FQl1vzwWjr4HZaolY<Tqhtg(WxDM
zwYiilX;>k%5OQJ`X#oLuEHolO>s=5H$X8r|ulO#KtO6e>9taS~f<*{09Bpc{>UYEl
zHaJz%RRdJKE*uZZYN6l6w(yeRPc8L}&yAr0VOJuOZ+M21{u-2yW-!(Njvh1JqlAJ}
z<SfrT6QygYf5vrNEHa;60=0uVg}Ib`@)FYsO`(MIJcx(GewKSW?JRx`mq-u4!9ia6
zZd}{dAP4?iTlHjKo`n6MIf$9~ALNa#OI4Z^;qiSmJITE-9jlj4`lSD=ws)_WL+>yr
z@^?Vu5C(~-h1LOFpj-3)pug_|(qfb`!kL9C0lhKTX?Sg_(H6MFlXH3-E4Pg#6y}jl
zGY{u%oED(e->}r*F!|*-bSYzC4}&z&C7(Lzy@nBViJd`Udj-ge?b>aSm`~hdCJoV?
zR3XwjNDTh9(q;xy;#`^yPM;de020@npfsULfYzH0ocEHZJpUr;0xdp~B8;ZIC?BUC
zv=xwt6`<Yk_53=m7Of*%7cIJ@KOGIhxe!bmXbi?@4?U#3tc!#g!-f}|OLs^6kh!C6
zgVfKQec{{M2ZvdBz%qx~gK&`56j)GFQH3~sqdJd)tK{oGu?NW~wnX=d9jg1pQe;fm
zZDH0a+f)@!uE984gD&O4thF<O(1OjJ&YE^%>@mNfzL;Z-BTj9jkZtTzC_0W|%nmK0
zCX0U&4p|u^a@OGjeWin87V*9tB);=yhW<L5mdHU1uuEwx%>gYALyX53k{!asQY~V2
zVfGf$tw}CrlpMH#$dY9NsElR4l87!goKVod$=%HF2`BmVMOz|sKU7>{hxke`eR@(3
zeXHN8gKPPEl@<vR3Ujr|lezyQ!c6-SKSxJ1Ljyq^wPRv9;*K+GeK8M+$v(7-w&#I;
zs($v1P8mhrMTu}<bPAz!U_YUAU_WdA=WLHvEZ$UuB@60~-3hQBrI8DAXrPkt@=|4#
zBpEu!HUd8DAj^nu<Bb@P>WsFTL9QsBn3aB_p+Xt1UDG%S`@R7<zDEty4tfm0e6Ih*
z8S@U6gK*w9!w4@8*#_oNfjgh2bGqR^eX(>trF~3^B-CJukJtuc$#|qxx(#=BA((?Z
zySACx4XgQ>oE)N4ZfFFqjd@1|m;j_LZ*UCUs!A;&a*A`OQUxnrBSy5uPlI4C*to#K
zp1#0gEs$)ZU4dmw-mn(k<a5%xnGL_vw{+0QY<K}-vSLyAMTBWvM`0X7VB0ea!<NCe
zb`)N(IyGgRwyR6UXJC)Vv^l!XD?U@=SI=BI!yR$&T|2XOe8!!dOTqciO<NT>|3PHV
zyeO@1uTXb^#MceBxTW8V4?hx_;Vq*hrd|;gz7A}Xoo0ll0E!alYWN+Ku|{*m=shh0
zObFrt^R?IM7tRgw(@in&l%~agzHSR0XvOz#`1;TLLgr>+op4uyxv=_5&#X^^n+`h}
ztG7b;;CJ%(ETQAWD2ns*>}0Thp+*10!8nIZ+zAJEq5KB59Ry+-b1A?_+;YZyMmK;7
zrB@ja)DEMa<RWjL`0$5ySZc%J0wHtcCE=t7LV?N8|A>{sp1@5IZ&0vvWa}GP5W_(x
zHz@*&!O?`27xfNPk}1g?6R@a<V?V;yJ`S{EVX;%Xcvc|RIM$mr95_b|trqsBbV`_N
zsZ7992`PjQI$Okd_dt2NwJEFdNMenD$7Z3%Zz4!K+lR%b9SGJpMmhpn&Q;=WV2^gt
z5iZ2vb&j$CmIv(&p?;1seY%iRVCcp1MLne&=MJ~ug357&6>8^~MRB}~U-sul_ehQD
z*u}elJ_#mv2l`$JeO^;_s%{H4*3jOWC%MHK<B15BQi`@t@g`|+Y*T{QYTWM#^#Tqu
zVOIUz+rMGO=;W9Vcss?rcgH+*pt%eebCou_xl9iDXYd=gq~89`2Ca6qa>JvO+~fMU
z(%MvwD}GOJAD?cYU=)b<>lH(KVAys)_%tu!1p2w8f1}7YzP#r>G-*3FfOPpExV)KG
zN$rQyj|d?Fqe|nmT1i=~KyVyYXZh{MV(6Ku7l6Ft!!PvPg<~}2jkzi=Hr@FF?i0GE
z)bn5|!uQbEno9I~=Lbl~=0NC-=|NuTOzJ_i(4zwovhVz$vnLJSGb#<<Q<4F<YC#5k
zI0Jkmgk7qJvxrlVNDr_u3cp<PP|!O^oEn#A=nd(ai-UIzSm^va?)Ii2ZxI(Azy(bN
zJf`z=X*7#P2|vL_pE_(iqy+{m^!!Y+Gf=*BCmW5<!%ZVJ(HG+n(nY7;u!<2qQaiz|
zoqnTePIdN-qG<vckg^!BB~q-%DjhXM0R{uw)bCw?F{W38p^GWmUAjFu({I*pAYk*~
zG>X`!mezy|_edzuWW_GLsp>4vMV(ERXNi}E!OC%unN$G+2!*ZQ=ErQ|RcjPoY06Hb
z8mLEI$6}}JOM`V->r+)+6~<09L0JKdg72Sn-5Qu9f}erbWlmZ9LG4uid@Q!g%;1pH
z91)2!xm6hU7~gVpFa|OrotT0H+1jxhg21sFT}v7mh!Ck6UCJFe8EL~lNst4hYXx|2
zTts3zJMj8drS(+!%5RA_`OKBLtqQaNM5Qnly$Ifqupdqpt+<OrJI_m{AzdqJ1P&2{
z_v0dOBbjuZbP5=!a`g=CG!bdMp!7J6=4pI3>u~q)vdEs1n5KM`Xiz>aQ9tXAl5x_S
z5d+-jh=Z+A;y~faHVAoAK{!5*1>t#HCz)}q7z)rjc7}_3G;V$Ra#x@%q#-VI^)4Il
zLYdn}6SNOH>2aSBNJ@OAmY&!PP%I8PlTip`qK$fD+<wSe;NWaKN!(@#=DITJ$rHTi
zf@gsDN&}-_aK!gPfQCUH#5Zn;1veqp2zUoBh}4P#D?JC(g7bGeBFKSvG1W=1OgBff
z%+%6>_W^&lBYK2^bmY!+NdP=yY<e4mGr?q#8g6K)z=qGNkYY$FhYl&;lK!XkLWf9L
zV-rkR6JG6(PmfQ7?i+{rCf6Nv@9Z<~uxfR0nZ9}2n{|uJaZ8zTdllW?6;OHmLds02
z!A{e$^Y~UAU^``8D_{o}euE?R!5mC|*0lmU8c@8kKFlZt!fGEYL_i_E>`*^VOw#Q_
zIeVy_T$ED{=1Eq1-Hrf*i8hKsoUhRgIYE+Ep(I{vdW>tTCI|4vX$NtfM%K0pL8w;G
z4lqCm$j<_RrcsZjdo2dxOfm*AfPc`2VbX0-k3)9H9;<-G8j-M^>7*e&*mAI3@3b5o
ztj_`DvMZp`$7m8wfaG%!qRdn}xR23=G)2cYaVEi~+~5z;32yhv8cTwL`}{An_d;k2
zVPrR>ZP-xI#-MF;2~?z)7U-A7%Ur~Vwn!%Zrg+?%!Y+~5XdLM@v|4*ntIp45+g(ac
z8MWUG<ijrEF2#KauiPI&q2$m>2>T~#1GDpTGA8%C6$M7=j6E9LCJxthfoI4e_|2Yi
z?1!%V+F6QC!YPz^N;w4*SBs-;hoKx5f~l|IpAS_fj;;7Qpi1{~SHlzmi+2x_bpv-~
z`DjS#<aq`%rsu;U6Uw5VB}))C@%~v(L0XkoP<LRmfYWlnTd}mBvWC;~0Co)`#(>p?
zy{j8U7>&uYrF;2hUxyK=F8i8!1VB<pp*50hddg^?%yp1qUgp}fwC}%X2&Umv==Y@8
zrVBR}&lqf0|3_&#EQfZJf)-m<xEV-LYU8r$&~D=z`CN9RlC(>|C_1gv{{&Re|J+i(
z^NN^fw#-3aE^`Bw$MADlr2maoa;Y#*2ZcIu))POufEyS>oiO3@Eo?g-LT*sU0xZHx
zp7h5(9Hm#5VVo$b=XRNY4hw<F57+=-SZSjDQZM|GRL8NlvTmP=8H^Bt^4$|K`I&bg
zZ-l`URi8QiMuw)m%p1Ed{|`{8F`MF7N)k!{6W1+T5BN-DPoXwkw2C|TcwD&?`d>84
zu)OlPWsvVM!}2PJ{s8k*KTs65_A83J^5@lY7;3ewT36$fw46NUJc3$r6Ba$!vR^JC
zg2eDDOh0Qvhr-*66p;HK?XW@0**HK9#|JhJvNe|d1iyO_82}63Kzs(_gXPpXte|l?
zH)*)NafG?CV!@;eY0?M*KZ+2+4k$7lpAq<gmdG3&F+ilb{|?g&?uS6XxnC);MftVK
zmbqUlH9HXbf=?n4N~_7sq(Y;y12+s+Lmfnv=`&EKVhO(Xo@;Tw>(5HdlZc~VB>;oO
z`h>!Y`)^-DmCi-9fmOzj6A<{t4BS-xJNDxQU$zlARM|~DeviO+QuVzBIv5;+LxA|5
zsWNh5qu+fB16}FL`T!YW@+JJF2%3T`8i_#CKQue+E1|RW2wkGg7!WTHC^H7e;Tthy
zP<#l!%i=?k5-G>148~^&K10#eN@Ye>{2a=4l`>;kd?X-;$FVD%F(N(+-xcvnq(nvn
z+KJC7d@9xH&w#OWd*CG!2f-q94qg~xjf`SJ7>aRqRt1h6y%s+#P8|l$0x19oLP2Sz
zq`slW*>jQ|24`)>LA*lX{O>{)Lzh<>fafs4iY!1~te`uuXs>F6z>6D?XrtUl7uTa$
z?1hkq3yt)&hOeMKi9z_ZG;v{xXVR*P)GV&9VwwGVix4LD3x2#sLKDto7aqxhF-q^7
z5K~EUb}<A-91}9v;(f$XsKTR_i3<=^n_vf`O9k3rx)8+wLgc2q1|V6Y4e474kR!d@
z)^vyo%(J0{>phySgww7B)qb){4&2Coo~oUW=bd+SJ=Fm9voCku*aU7BtS#}4WlJ1q
zc0oLGTo>OB@6xlqrM~)J;OhyX6Ev2=I9UhEara#MkT1wIE{+_lqF0t`perEYaGo2h
zJb|vNVMvVh)N=ZA*JD)ZClde$GT%z0k$4mreb+q$#SO__#QG`}D9S5wVi+(eO{m2s
zROiKT*0B;Qi7{%gF|u{fU=Tu9hP(b1;JwUb%|csXY=v3<9V_Pq#kMOg^<=Yz&uKoR
z*x1lgGBVio)g^6XyKk3rHEmUwnqak|3lfTzCR3ZhH*wJ^-b!}Mi<!Usvu7UF_OtZs
zOAZ(-kb`bOBegdAkl9N^sloQrwD0AanS{NX#d~ho;9U5XnSWPZRi?V5tU3o(XNRU7
zIbc8`>|-~s%~Cv*(|Rai8M`Kl?o?ryt1;w8ZMf1KGmAIy<*Z>Y(C{7T$Sz|8APUe`
z0arq{gAp1IUx8BCRfqygMYJB$LO%8@r1)owc`RYlb>R*-wv6<0nArhlJAb;M11JbW
zdm$~lbU{=O796d>Y^5}s1KVFa#OpHVCB@qEG453-0xUsKhwI}IhYM8Sjzc!0OKC4<
zTQeNkm$f^nlP(4K$I(^WbjNfzwH_ByL$?iR0;MY`Zf{6ii^$|Ym>KtF4@eTYJA7m4
z2Vf3_!Q?@`8G9uv>rs8b1tpb9=BrS?@p-^FK4x)*mHz@(YL<H}8(|D~7<i!UtALKj
zm6i@bC@r>H*vfBE+EV#VWo%E4l~xNfYH`9_LHpI4p8+s~q5y`Woc%O_?uAYM5>PPV
zw<3bL@RIJX2*ug2Rg^QMDp}F-+hKYMC>;U<+sMGD_qb;$sP7G6;5_&!opDAXH%3$<
zJN&$-AtbY8O$g%Vp<P%G^%w%SRoCblRwmO?7SJ5odS=2gQQ{?2&k6t!#xKj5+w2A6
zR$)75?|BhoFL2NpY4PUu;#BR@!YwwYRT@ZT=^M}7Rw#~u-e6IrC9uA(@ri_chZoC@
z5oO6Ab#+Z4w1JfdG!%GCn^l%fm^xYx(DohbO&8?=!eFMK+X|Hyy<s}EWZq*DpI;|A
za95**RltfS@`Rx45CC=Ws|-V-not<rKge$})XJP5<Ygw*mB1;keCDyv+*oi8Pv#A%
zic~R^`YoJOGH)X&)tY%P0J^-2RV{49Cj@lB;SmS~`cWe)-o4|NL<R|>G(G7btHI@}
zw;?mENDz3Tpe8FJ<BIPQ&im=UdAd@0Hrzeo#YG*WT{28;%(SzIoF5@6RI4LFYw6c+
zOx3(}DcNf2mxZKz=*mZkE)0lcKoB+DW-S718|1NENrv0$_&CZDaD#2kb&!SegE@0)
zlwD!=3X>eBkW|?0W;cSaP|2<cixvZr$N+0yfc3{-i&gra9K0%^AAPCq5{rf2k)G*a
z;lWe`Y51S%WdIqfARFs%sB)0ZKcQ4;C8BZt^4ckH(-`>L$lT=^J`y<YZoyBsfcTPD
z3hYdTpmh;bYhkZwXsVc!PDBRWR8UU{8?Ohl=Ia;*T;Xejk$P7bOlRx|GQI~I;)>+&
zg@jZg3ia~yf16hG|CVOer3_0;2mMWSH)|VcECEu^dz?_Hm<8`}&18Ue3sqVL<e!*k
z1PG{-sj(jHkhJ$OIgnx(XT<7BKkeml?`^$j5_Od1R?25?<MMQbt5BrEbdXHnl}T{;
z5z5%JUoD#EUd3753*y&Bw4DD93oF!ESf0Vci2XE;g}#!0If!&;0TDv4GpzunE1D4H
KP@SgNTmK&fTs;*4
literal 32754
zcmc(I34Bvk+IQ~F&C)jAZi|$?gredo1i{f67lPIiUq@&qDk@9FqT-0AnvN)zT)=S~
zm0Kw)3L<8Cae<0fMI9+v9k)?YX69v9E|`=x%|!`<ZIbW*oO^GQ0*>>2@BDrrn&hm{
zdCvBnXFI1mA1^bNm`tXEQ_4qv6)>6R79o=NkH2&V?=8(sFqwF7xNqEdexLZU5#H-&
zN&L+>Xur4b>!)T2W<QldwrDYn7Aw<YWm+t$wXH==#SDN6MKTDLsS_w(Xg8ZpLV=CG
z?N&37Z;P2T3B`pri^=XNv<W7AQK1##qC$(AzEQ?rDLMpGS*2Kj?;7V|(NtaIta8wI
zrIo%*1$+-L#P^8dC|NyX7=@j~D1G>_lTdQ(nCeQCYwVb+GJKzox~{RORnqsVl_q@G
zu<xPt&GWp47c4fL&0fgyg4I@7RLq+No4u&G)Pm&vUye6ZzN5HAD}g|nQKmFoy0laf
z2w*{hqohm}ELK}lae0ODTY!I#lJW}USFjfpQn`vs!A^nliprCWyozk8iVAIX@m+KB
zY4{#CeB>#oQrd`<Po?;Azttm888wRK<U&;TG*&ws5>S;sc6`e4slulQ9~VB8@bTg!
z<Fgr`?f9IBPXj*l@p%p()nww__@E4@ApRUad1?GKlgV6dGFjawlWi;VK0-OPL1lTw
z&3n-NEB_byKhi$ID)64T9csU5qsdh9pvlzVhaq&IxLiIyREIu4hPPghH(`ZiEFC5h
zBUxi|VGO;dTTMevXJX{)Flx^Ml4^vw(>d9EpQREb`iM#8Zsrd0)6CTvlVjt@)aR!O
zujI;@_gMa3@P5(8(&ut%8XWVU<6%)6mO0j1Syi>mU5E9Le`Yh5tcBxvo_;BAu~@D6
z9~+>c(D*g-tu~{Cy}-yTEXsvA`iCuorEfQWDc6p@llvvedc2^>;m~sQkd{YjMyPt|
z;Ht8!%Hn<{{Yp<N>t9|aR#j9D?pLCP2MiuKc+lWVM`dwIrIs)DcMR6T75%F!22>3k
zfLZ*{{(G-YN}nlSeBW=j7By|Pzo@+TNbKR7o01R59vOdk@{z9|IZ*S!k*?qIyg$>q
zd{MjG<o^6_^L*)~F1xSjy|ymbPIGP5;jh~4e~It=?N(>Zkr`35=t!yE-eDF3rumDy
zT+we#F-Pa>x@wEVfB#6wk*-u^k-clZV-tb=?8u&ZUd7(ES&<IM9NSjAPl-9GJv}>B
z)%Dqt*rIt}>sIA(m6Sy0{U06f=a9C=9Mn!gAQTjH*)B)G<l1R-eJup+o<p8{fB#jR
zN4n7FoPU30k)QWkGxlF+cJu_y(fQJ0`(gWz@8>W2wM)Kqk)K<(S&8Cv(L-F*!``Mx
z?*8hLuiBh^Vp}WkHU~0J|DrKtj&xPW4xyo17dpD$(T&awFY(_$`bgJNdsh|fM=Czo
zTTrljz<}=x3Z!pOI!XF#H##F&7FiZiz)7X;T}QiLcknMPs<K+UScL%tb{7<UH$eJ!
zsPvaa&HYEZgd>SD0?=A^*q#`(>~O&3%p#JY{&u+-BA!QpNX+rNt<ZlzuuCrDFaE4<
zwEqEwJ7`ofY)2`lr>l4GtzP?D%kINN21tk2nj@BBRPAd3W~EbA_j9FGGQ!#K7buH=
zc~KlyiVN0Sy1tVRQPMvjT67#DH0&{pOX0tYezgmOjnUu5mGT$=VW}F;q-k=bBk#T7
z`mQ)&@A4L%aoFps8!g#f2d(kL-jNG=yGtzth_c-yN?f}fs4hq%i&uCKOh(_(pMc$-
zs9l0#zlzP}l#Da+lT7!|)A66B4xH2LOk9`gzBV1dCUsyMB9~>l|0^B8G<9H7uXF$E
zq`L3f3)Q`=E>!odyjXQAy+I`vRMJ5u<BTrr#gwP~{Iay)ye#8Xjs%sXLFN0P(u2Gs
z$UBO>?~&Kz42@izTpUx+T9RDiRC-vUqt5+maGx67t2(zX*}C{hbeT^?9ba)U$SNln
zKe!}%Cm`JHO$38MX$Sv{8PR1ylnc7ehb8VC`;J4>C`$3zY8)SRj(guzT3h|m61Q;Z
zDvA5W;T=(_2*<a*tlBNfmwKZMxn<tp1v8!ru2_L*SQ-_*T*()n%_9}>TK7gozb9Du
zeDuNMk3RWe$tP+yv}5l-cT1c2ORG#1BVXaO4WB>a^9DX|;<FK-x9~Y?`sJVM8m>Mx
z_OIK@+PKcmTca5{GE0@Y50!>>zOz+1a;v`--!uJ%YETgnnx%|M`@Lh5i=*Qs$tB%t
zX`;P!ugp#G3+e*yp2*!Z#cN*Py7lokrw%Z%v~gpix{JU5e%bVhB1itF1|DtPC`bOD
zP-W9&NcabU{#~i*_4cdj_VL%BUDMCYUq2rOmCS}kTA=1BYVPUe5~U}a$~4N9*`!+J
zCkB<TP%0`s=APo{vB~dOAcH$m#&N}~00n?c^8gQM{B5?8fyjQJ!3uDBMJU-btf$yW
zvda&djsb)u&H#ikpBFagg@xm*S@N>2d0`tBEtV$8;nR(=2%mxFOIU=*=)W$7x=1Nw
zk)?GkJXX&fr}PX#PuaA%6l*jUc(i2!n=l4C;S>C-bW)<76a0syl0-W%_>V}|M7!DH
z?>&R2fln^kuNt$vbaB%X6DIK+HBh$DBwp|Uf=Y&gQ)P?OpHcN?Ag;WsrLkpB%N&_A
z`6pm4c~U4aRjI93<xrcFq1hS+d}P~vKc^--D_qKXa;RJJ+U3YTq)3)10<0|N!sb$J
zi0@Y=E57|ame4*WgN-iEou@&NL+ceUA5|GD0Um3xmP-ZrmIW;ANh7Rd#<~zU@Yl+F
z8aKv@XC=!6S0Yd{D=7x9LZEb3vLbLb0%fz3mFvm_o|Xmc#K4vKt_WO(@5;c{Eeoc$
zB%FaoXph=hg!UwATS^6_mIdN#bHocKiLc!uwvP{R;xCrVp(8*(qlK`&#JY>bJHF7W
zxLK8^Q!`@S4Dq$s7|dFM!4%uw(F}jdP&tGy2bQ%gkV8)^UQy=8D6ZWWe;Ex6H^wik
z0XsEbmI~N`2zT(yfUFOMjCkcj6Mw-2`Y6Z|HKA&YqH7ZE&_o00n;=IHVrUO4DP&{E
zmC1{+#AAzT9S~u};$qwGAW&C2Tg%+rPOz-x)XhppPI(nMd_+xDEBwwHIr2xvR}~ly
zIuP22X3wC&eh`GnA2HP^r!@5Q-72SMD;ZbU;6t7XLK+2Wr%&j7Rt|rsZfl+39uifh
z0Y-8<;h8Yn$T4GqA*^IPE>PHXVx%%snJkA7s~D`&7%XJH?@=>oQt^~dNd?ZJv?EIU
za0hErTyRc6ICvUM8X;iVMzY{3HgRoLfY)O#N3<t}IlO0(QMO^c?^LSqQih@}^rPpV
z@ZE<~f$`$C0DstTR+WtS--{%(IPY5mm})=ECWkgEwVWDncUNjv?Q&?FzS=|ER2n*D
zJH`1g1%#z{1$gn2|CWOTl#B0DozY}*vLspBR3@z}4%A`wl?3YXT^hIo-(`WRix$Y7
zE2;+Be=>KD9!gPJY<iT%H_GChl^u`0Y7{;%TNq2cIYUbv-&o@KzIxGugV!B=Kzwbu
z_?mm?&%`%xWQ)v`V2do8SvnsZvl{?pu0R1}u$vEXi8=GV7j(*zgwpyTGL_Z}w_WBo
zE45{+6Y*%1%8B+r(}DyA*~ZG9$;z4BZ^_*6F{H0L1Bb-RaFE1Gv_OEXj#>h|GhlX>
zkCKB!5~?_*UFI5S{RktJT1n;4KGL+u*0lCF&Zr!I3k%{crGZmx8f5N$)n6A>#S0d6
zaAtArcXDWj;w_OwE3r&N&nUNh`SO?FYZKdxDf_L=S8d{@4~Q3kCcP_%S`?IUDHbKe
zzr9q+G;<QB@EIi&O=Y*ykvNFd6G|HAkH-uaY2u)6?I>blY9)QU52*<sKm5^}G`>Ho
zNqaA==|!Riryx~mFX0b%P*I-+OYF8)6l}Nh2OnVpp;V3>Q8HeO_-=o!rWfW?YJ;6>
ziXFF49Q1<~OKb;E@8ERM4GyYs@O12RR`cB%TFv%8rE;x0>{Qt-zB_|8C-}T#<TWA^
z)5Le5lBP1u{;jI{eG&$V@3u=PvC588IrJnQ1mJfRv)FMxBgJxfFOm1q28Ad`Kk>P%
z<xnRk5;&&<=7R&}P&+m=s&-;p{1#O*6PFTtolb0=63BR!rge+bxmpf=$N*_MqjH7j
zAqV8Ex~>p}VkDiIl4U`lITOu@PhTlbp~lgKOPL^t-c&q0RBRcc{3ESCo8*((KIT<V
zj~bOjzeg*b_`Kz};`<fFt8H_jg#+<+B(-aO*)ooGg$KLSg=u~c<otD`{{`a8IvVZE
zcIwT5|G>dUeKezww93)38Z&k6AjWTlLMJB9#PA*>{^32W1cnBqP_0zxCn?5KJ4wTP
zu^;wgV8VOYnF*}l)A&2;D;qhxhOKl;w)+@MZCI-nNBI^Bqze1SUcN;;=c!vj50NPA
zqPFPSr0pzY9W{ITHFszF_R}oh)}J+??G`&7-o>g^Nzghg@_SqWsMI_gaLm{{G_4;f
z5U(cUWHN^kdsj(!CZ5gIm{ZYly>jR^W!tI)4bl<6^pxAKtd_(3*wF052qLUxXz_Gn
zwMbQRXp<Iw3tTM50<&j*Tnm1nO2q^!TUy5!^YLTjO|!9=HA%zXXS^}oY=X4Gu2#;>
z4)S1HV~i=n!Vy4VD%glNa{-4`$VQx4Hn#jwz?h_A8dfydn57NIDl&_~wI`a80Jl?Q
zQzCfzEkDz?5sic~!EE24&;P&njSZOm@V;R^ax(laUeJX9m%Z~J*)PEIKf7D7e?W7d
zn&AYs%HSAXr3Mo!@fo)+<oKDxsW}&I<~Q{{S|xKEiQ7A0jNC(X9Ea*g+Tmx=38Zt>
zERAQZ(lg4oR)J35jefg|{mX5PssYX^b8msfLdYljD_aF@Z>83a&aK22koqg001G=n
zzfRF2%l#C=MrTzzE2<R`gOx~>hN3=IrUO_5K$TczIiP8kqCMXe>vYNIa`^3p>Q#xQ
z@$P%C&7~B1($FA?b0&xn4*9C>y*A3pxOQ3~ER^4sOW0)rr7izkE}_ff=}^n-ziN|S
zi$V$w-JPtz3!+Pv9QjIV5WGbJ_rXIH7Qi>*H!Hr#K|fY`@J{7*8yG!_5110ZizuFM
zQtfhZgg9x1lIlh{R8w=*A3RI_egW5JX?%~0faMLC+6#%j@j^HW-l>YObP>X}ye4(%
zECD3ykV63jTco63w+ai<%tBK)W^0nnwJE-ec#~Qhs%bL7kG(X&QQ2csU#4b2=!>Xb
zw90U$c0)ydT9d=?h?CaKk++l#hTFs?MC;B#+d{5>c*6U0mKpx7`{9WXT_~GMMC<c4
zeDWd;7<cz`;#t4Zvb7AETdxMe63X1CN`ut5iO45tBJjjQo`7B}bN$gf?j+@2D2p=(
zE=VV8xJ>kdv>f>?p>~7wF9%=$8AJ%am6o$iwZlg1ndrE*_$mZ~&y<=fs2(U!d^I5R
zPhcH01|Z8=y$7ZeyMcIAIr1JUbdrl7TcUW+0Au-q(z-{EysxyH-9?PCl(3$qen>KS
z%R<ImN*@F`2DRB7D9=KEF`)+0qxBX!1i553WGc3IdgGlHDLM2fw%Lwq0USS=oj>Dj
zI#8|ji&rb<d#e>35LAfrT#69jrQvdF8qRp3zE>)fIZp8;)cRfufZ=7!Owf3n$csv5
zofU0|<;b6aK{PF=>Jn;$%X@Axu6B2>svF8O!jF-djp@qxuNX}-cq+Lhp_WMh=<aN_
z){V<0Mv=H5iMHb_*5_CJI}pSGJLT{uG}~+q6xJ^w0#X=wkhttxw={xfVV*cNn-;AP
z8M7;{aOs60(>}=m60!}gxP&<A&FQC@rn|W5KjWugXr6wVFx^u&eMb588^!6jS5BW_
zJ$=#e=?{;X{&>ywXGTsBxu<tboWAbD>2F*#{Uh)6FR!2em)X;I-Y|V{!}M?FOz*jI
zhWVx$j+<vx&Ydyj7L#cPBrr4*=GV?N0uep%!o7N+W3dr<UJtzVq!HMn2kyN=53FBl
z1U}RQZCzSm=T1H0&ad>qE2ry$Wso5m7Ek_C4>Zrv18=>p2X6V57T7XX``xL-mumF_
zuiR+_{-~EUs@`+AmLT1wm$>)WTHyMHY)R8}MP8*<B1c{aas3mmCh!G=>K7m(p>}ZK
z9sWdX4eWz<ctB}Kr^n3;xh=y{M#;4EB@9Lw6Do(ctIkBb0Pd94GE_Qpgw_Nta)_RQ
ze=5P>Lh!+${#gNq27x;k{+GigV7G-@fOG-?S_^+sr6R2fR#E5Zd2An#Ez_hH%i&TY
zv7ola2{~LsVL9?F_V=o8hPh`Um))f+*#1YBk~|lC|2*-htK<mkYIFelR&f9Nwpy=^
z(gtmm1nR{I>cxiKDD|kd_TzdXJ&rQ^C;^7nhyP)tRK`XL{C$QA;|C9+yKmDt(RUcb
z@vh3oG)Y7kTSg8YMu=yj?=(EX1G2*PccF9+lM{|7&DXn%F*#}4sXUV!elLdw#dj$V
zQiu{zs!=+PCL7Fh8o<m#Q!^(%W9gGqOgWfOecsGp4gegD0tk?%eCHaawOL`sUCKyp
zUiyGFAQ<zrWw^NU9w$b)|3r`i9t=vMxb7RUzJj{p8>e)DjY^O>1xO1J>&!b(l_TFm
z>0>A}K=r>>(uv79I#uUpW%H8Fi#Km=+G^Tt*=%brg|r@5{oYJajSD2X;|SPl+iKam
zb?f4-OSUR!qJo;MV%p4Y<~N%+3#e?}Y(oXV8?_<q|8jY(61s@;C;e^)hY|tE3Q)pU
z^HzQ<x7DNrRRK0&VRR5A&H@tmqm6{MM%w=?Ho&!$Z+R0xQU1#X_=%at_E+%R#UBjE
z20;h#<r4htG>gCP#qTcszJTAaQR)DGqh|5-e)vVL;Ai;lLcBIMn94_%;Wx@}I3GVT
ze(a6->Ec`N^oReQ?nINb{oKgebab>rZI|(wlQ$$h4xCsMk`4YcEhmH=C?Wn3o6U~D
zOl-EtmWBn)sFiB7`niRswKltC=^Xd@xX-sA%_L?}4QK{qv*kq`Ewbv}yi}$q@N7L+
z?=FzJEhN-T{6oUkbxuAe9!1s5ny73FT75uzVh}}0)RQBvSZHmt>;DeCZtz~*?}k3L
zdoR8rlb4VHu;c6dS7`lv9{o!#;G`+Bh6c0ma&$azNIc(WVhtqyPx&_h4$uIuB7lUQ
z)UR!}c%N#S9h=?RD%J7B=Q`KTY@3lKT`k1+EZdK-$DtjHwCL(?IkH?$cx-ayNtVd;
zt85JA$Wv<E695bKgqjkUzKY6<Zybs%HH-AwpfwNHHS(mA_H%2kc8TvCx4rk!EZP=;
z_7pMdQX>E;na<V$?h;rM2i4hS;R~?(k_Eqz(tjM@6dha(*ik5d8FHZ9gdc&HYcF1w
z9ye~B=g1UFA~qkL>+v~)Amc^QlVrrZzNUgbBbAyK!u+D-k|>OC+_Frx7n3dQmoJ=%
zxfUlqBu*MNA6mdm)?qv_K&WsMRaj0oCNM)7IyxrG5>P>-LN^kgG7<=_Zdymkw9v}&
z^kV2*mC1SqO6$fUaPZIC`CuEy#2DLP#lv~W$l-B{ca$6^t4XD|tkQc@4euKu3uh1`
z5B`k;R#mdGKnW;lc%144Qy<=rSrry4$s2G2HO#re>yyKO@tYy&?}m64YY;r8$vN0~
zu{lhBFi~%$<dWE8ws@HOJmdeHwvxic&(ZQ}w{HbI9=`i8;{1skh=%r3b2Ql?3xQYz
zU~g9fg3ruPIZd2(h+%OSc;aNE|ED7xsR00rvK`eZFEZ0mxOSIfnX|lQlqZR8jR#-N
zD~?0J(im&Rx^=%Da4;^pFFeqMEw^KEV*qI-kVzwEV=-Skc6%n)hza8egU8u~(N1JF
z3j5S3%GGF63jy&_ZSFwT1Dsxi%ET5E)nQ|VRgx{(r1Ic1S3s*BC%dENGrdXyfz9}<
zw0^Fj!IZ;iDJgXI&w0Jib+wLP^Q05vT7bt$l3LfLln0Sb!AvJKX=d^E(c-(i<%oj)
zLUK1LvO+lg`)KJ5?NvrsOBw1b$lvYI0F%zJxSNQqOscz52}&2FAFJ0&7@`9dMv<MQ
zFpBJCxb#)uQLe&r70Qh$S%X(rnFKsMWEx{)wsdlWVF2AwPNQVSK`lrHtN?-zu?~97
zR}{p(7BCbNEM|nGff1>np^nf-$iieVC&nE6j4dt*`c84vGjeFPQYl;RRGWF6>P_El
zc~+-<aqn!*UP7B?vPEbys+)_^?##t#P32-Vu@r*|C%d{R?yq8}5@wpMb^{+zN3Epq
zd1|9u;|G8A^u9s$-wYO^U5X8-lXli#{O;m6Y{$>n{Mcdm!FfDuN6bm<;&m^6abDj&
zE;a&Z{lTa3gHwGEe!k`pDzO@<D*}Qz<urtFoZqwszo`EDA^hSve`6_rck^Q>`)|+=
zZnXR__z>|e*ETskT4^=O;WO~<?$7)g4lvzNobh1OHQf+5i>YHi#Zu-aGk--jv51i0
zp-`oD-QCAX@gNb@2Ow$k-irdKFDwwxUKh;(=tH7?9x_0^A8P09;-u>nwSt6AkKgKC
zK4|sz@{4bwEUSA?NRB+HH1OaAZVb3|VChsA+=Gg*Ul3KgYi;Rxt<T7iuBP@V*@|SZ
zk(`gtql6Anmm`mQHEgPNYy`rFW#jueZ1NB!e9j3mx^EoE;mzRN!Iow`9JDeUAkj=t
z;~eHQ-JaBx46*TPkB~}udM=0NW`o-8DT8$}F<H;4M$Qf+$Bmp0Eyp7v9GFZsWRsa>
zbq2ouSnyhAUJLDcEf|^EMkv#0M9a*!(~foo)=o9L@j46>tQ&50qXXU0GSeOj_y!2y
z*8xfZjy=HF$mEfkGBS;BYMCB8%6^Cbybil1(XeX8_GN!YIAj_@5{^I=*Nl=a9#YkZ
zwrG@th~7zt4D>2m(qy35RB4iy3V!6YIx*4NYK94;j@dH`6GYcSuli5Z%jcJQtxuWP
zs7%ffa6Xwqp#Hy44!sQ%bOm%nP}XY+zeD&{hT6L<m5|&7h1LZ)o?-qM!v~-}JAjjd
zdZP_4qvO@e81yZxK4ne_Qi)+g*@W#RLGKm@s4&b1&HPxbQQblW+nZ)0Ay0<TGfd-Y
z@(+e44N5S}G<KFiGl#te^)&$^0i1=QX@%2;m4(4}6eikjfY1q<7D&FOl2RatX70QR
zcMv}}fL3!BVWjCOcBta>e{QZ0xJ6Ra<m$7c>`cm;lfoUaj#FQl0mq_YeGvvuGkKAL
zDF0+AkV88dgXCaG1jV4F4VZC2YD^Z1dzCPwC?KhP1WL0f6wh~XaCjM~$)}`6@azP@
ztqRb<@0aW_8#_;5VOd=S>CA8d!)FAG*7~L&Rv>G;|9;ds#%Bb47r<64KVz;V<JfG`
ziOI}ikv)tCwlPhf9N9}|Gz^iM<|DF4ZyGCtRA1yJg5lCS5&15m0;R}zir27gky2a^
zEmxgmuca2*k()-Np3=@|-TazwSt3QTeRgKL!39F5An_NRg-gMDU9K!Nwe$Q!3`wif
zY-$(yW-dP2H-aI~OM?%3s7$+^>^u$})rk14F!|u9&JIgRR^Xt6liVRT{i6dR(p~f7
z3!my^kG6D{1m>XSpv_(zPJ5o6_AJUDT)-r9<iOSjX`$5XAR_{`L`;E!?}Q)3ccg~z
z&e7uAuP}rigs`2ARKQ+91db~oIh`23P%GGC67B!Bq`pt}-;QJW@?BF~I{f>z(-8^(
z;&cSaKH7rwHEn_K2ek#*wr>yz|0eeCn<N>P)iohWN!L^n?@AtKSeZ~oz1eOaq(B!^
z)~(4KIfm3PsS>iN7P61c1^YyRwOsND0~?a7tL0*=FQNia<TprOp1U(Dulrh+my4qP
zZgTErNKygdC%O5F>q*Wj?88KL%a7(UQHbR+QHbR+QHU8#lz#wI0YeOqs{R#uVJ&?n
zOV`4XY*B_|WuP!XxQd0@0KsvKhU_?&jFn(4SvT@l(10>HK{XqHmS7PZXz7-psKVIz
z2kDUkjMLLH1|qCLGr*cblCBT%e5;pb+5t~*UOuY<1%p;!%l{%TpQV6X&Cd_y<qu{p
zrt@$yWJ{Vr2%BuWhF8hLrG8Znq7OumgmEAsLC}Ms@xQb2j>h@rw>7R4-}z(X{f$qF
z>r3jf7*0oN#yrD#0pS!BO^;!lfo_5p_NbtqppPs)AT6|mBa=g2jQ{B(1}C%&VRl|I
zCmoon*)IkYM;^Hefs}#OGlSya527!JJ_dzD8Tb>S1ex3BQuTxi16T-dH~221sxVtI
z<=jz*MgZM`&X}e2Qc4gIgGO77C=j+l6$pQ)Le~s;2$<dsWMBf!(kR&d=#ZqNiE%<L
zfcGyLtroB+8q1+GT4mr(62zNOPBp0M4ub`ABd6nXmO-{hevP1H@Uv(i+Vc-r6U42+
zmbhUr9netoN)Gh)arC3vo%ynyD6wYXAxVi!h-#ckN?NQEW7fh>3L_tC4VD6Z6qq1Z
z#f>Gg31ZVJ$ZFNxbYA$BN*Q#Qh_iFUKN4P|%>!T)>W2z+3h7l~mE_lK&wymF+0HPc
zeuNn8v1<Id9$1^<@pmHJ`98SgXv(6M!v(wxBl^Drf##v7CyOjPKy;cPAin$g1{@(c
zXW+*Ke*?2dxTOooDF<a#X?#BBR7Vpcix>bq9V~QWh><&V5QsFc(+(obMTQF)tjyz~
zi%mr{{(f*&zdU`|?_x3>NBROMNseEZ(;3CG)A2(yk13Jxjc=aM3h@CmihhLSY~5j*
zyBb85I}aN%E6y@TL$($wo+CJSxu5#yV;LiVerCfrXve(a8_KM;VFchm3APM@GMuOV
z<j|7}7B+RfdRGbH2|S6%Pb#&r8_Qu16q`-4i_G0@MB$>kLh%U+tTw8J)ATekj3f6+
z!}<=GtBJq3-B%=r|M4YkEzc=fU|bhqVLOquW)W|DTY|oKEWu`c<1)srfPcD}AQ_Au
z+&j-zT+t!|qRZQIB&yptVFQgRtr8M&rr^|o6%>bh8g_V2Js3H7Yk*^lj-zPc46U~(
z%aNl%0=8tJ-h&XBrK9Ly4^FSp_b`Z)xPNdBbWHp+U2>=wHP4bm8LEN;DfH-M;_j+<
zmC?xf3J<Q4!zSc{kvDv2KqAA;YE`&j^<5=L3USUdPi`C%N-s2oO3#5`dC!+4CGe~7
zR@Yl_PD}w!ia5x>ATkiNhq;tH$|r*TnFR}e5!wcrEEJG4L#l&iJma$lm4*UuVWJW!
zI`WMAUQGiHR{5;W;JX|+y0bR-wOnsAw-t)*K&fcGfils>e9L~wq3IFih@1G&$Yej3
zPUOOb>cf<Mtat|o;b|;6WSb9+nr!nkpXG~)!GxF)xrhd~7Q_etNk1bmPfC+hH{iDx
zzYX}k7{7Dy`wRTuh~G=_dlP;qp`DAMq(n2Q&c?#cO(aVcQ&I^K-Y{c`>AZg#BsNr?
zMym?CswpE`rlu4^;T>9GL%H)42!^aQxo<F!F(%jS!K}e6Ob-2(+<WWc-wI`h49j0$
zo6NjDlc2kl0^kLQ3x4L?T5BW#YH8c~8CYyUPv=GLtmI!O-pvv<8mE=~AAaUkYQm`b
z7jedKVPKo$FTx1SVB=j6PmwdVVY>oYUytFLieDN&4}NL*uEZ}5-&Odf;k#Ou%H_xv
zaW%L<dqQcWIE9;NteeOJO&cIb7DD)Brn?A+MH5>iApK03mm`Z1B5_-eEY^TgCqPEo
ztSoG{1zhCk8~F_x_J&a&jzuWMG5PS~$r)nBnZrR^BfkL|9Vk=Vx;sYGMHX#z;D;d%
zVFd)ZdoVCSjhqs-xtMiGBdy`15M$+tjc7%<Cqa0G?>>sv5&qaOBI$o1I?CZs;o89Z
zFNZ(Gar`-wKEm%8TJeu*WAWHn;ok#8Is8X>EaJRI8Dl8I9~(mv{=^uH@TbO5g#Un$
zg$5=3nFjIq+(d@Rra*EbCyxJJ2M1@wO$uAQ;k!2l4(q8{a5z50o3&b-0*CshZ!yxp
z?VJ9dk^W8J^iCk(!Q?nxcmPcge~5%m{C=cfUr!u}94f`U*c!hACr}EdB_(N-4IK2z
z4sXf!5VEc|*<nD|d-y&=R@T=KRPuJXcbn<n9o)V9`Fp=JH=Bj#QcH7xtI5>trsI<M
z!cnROZ-7l0(;$=<(ku#d2#;0aE~|&nRHaLdGUHU~TsC-{uZJtnW*ojMda(t+2l4wJ
ze!tOr75Wyx?<0PQjwKB!(OQfEqGaR3QrOI2yMWCl^b~qeI}jpmjEBp3Z>Eyla8k?)
zvY%;a0a|kiAz(JcoknoJ9VQtxmW`LO_y^f|6^s8K@$hDNZeoeiy35KkTMi`PVt9ZW
z%b>M7z(O;IcmQ#L?DuF-?GB<Ya5u8Zw#KqPpe#sQaZS`>b1Uh~2h&8ICYu`oe{=%C
zA8UZ2+c*yJr^f;QjGW>Ckgb1o2gg0SgQJMBH|pym43#4hh>1CR8fmFdDE8=LkTx&+
zp3BmodCac?yA<cG9Pv?i>~)p?I~aF_D^^jKii35R9Jw6_mmv<lPu9_U)CSIX1!X{3
z)#Xi4zB@2t_5^MpkzAAZz$N2Og93JYaFl3}=t>e5kR$W;@+4FudN&H(qx5#-7Gwhz
zh5UI8>~0-40X`O(pMaqN1I8L}0tb&`jp~7Ra}o2grZzCxkw(@yh@=ns=zGl_BsQYg
z%)XgU;Nr<`${F~cr;Il}x)_Th({0!|eRNQ_+dq^ecj1Wfl=|#J@M1WO&nE0KE@OZl
zG#ju5HbTFvPDT@i?R>Q9$M4<vZ8C->2)UlBVf1<T$qD4N^LFAk<||Sm{oc*4pOBvd
zDj|yUCqNsXaBPx}6aC3xsU!RuBj8JCkaxmS)h{u5I5tCmLX$$d9;|jmnVnNf&h!Mn
z$D~s}3Czk-TAg|V6Km0RGl)LYgnfoJbzW=+)?%IkRkMr(2CIUj*PQh3>s$ft!cdsU
zXV9RpNiKl~CKpkXvpQQH?h&zBupAG0hZ`81RdXoSHly)^b+g)L)USNewr|cXuki59
ziI43QQou^d#Nmz2PkapG3odiff&|vbs6gPf2UoT@jL66N5_Dg=B%Qc&@no;{Ma#o8
zr8|qI7YXVuzPdcDVl$1-Gnt>M-&~3#HnV!SZC|aFoGG3ABLmSk6GRip<^fHpFWM3w
zREE_!=EWH!&fbn<{sC+clHWkud$xZ?Hs(F8`yNw|9R38CLH9#X!ZOIQf@J%2F5az5
zSLFfmmFB~MsxL1u?H!eu=^Olm4M1(#W<d`=3F1QQ%Qk=2=`?wyn8|qf&I-uMZpLn5
z{a+sMgvH1j-_~k&I}o<J#~@r-H!6<Bafqtbg1jut_y;f;=w|{8zz9dxMVH1KEM8~4
zp~zP&4T8(6uOSa&VZ6cawZt0=e5d>ic$D=mYfAcME___GISA6of2)`VA&V>!&vrsN
zn(Ks;+M8XB2aa2dJ@=UQo^T~zn@(Ie*;i=5lxlNJ`h-wUyq+~EjvO|y(80X{+g?@u
z_rZ$Eu?v-K;go@Zk-ibfoaVw{2GO;|^-bUFU%`rEkHU2!Ifw4uT<9Ob(&(i03duQA
zv7P`$o&wJUY_J^oL=TL?>ScLpFu63w=8#v&EwMSY(QnYJQyT(?GuvP%oW_5Vi$fXs
z6w704&i}a42&N#HUUObgblmqelLKh-pCQ_Ut%3$uy7@=uv{|sz$i;8n9C7yF+vYem
zYG_ma_Xkx*yNqg3wHX^;Cyz8reaIvBf>DIDh&aAKGvWrt{2U3al0LRcFk_#v^E>C2
z@;$s#diu~!hH^fs?FFe#dh-ZJcVB`D&gm0n+X{Cf_y(ZyiJF`lhqK0mrC`M4YHX%!
zH*!7!O%IY1ApEJ4)^o`{nyRj<L+Ju2fIn7a*VEiI#IDEG%%u6gCU$+zp-x<X{DTTA
zEH0n((yVpYBhdQV(wT5_U^JX9B}b;iQACt%7AP72VE<z>p?NZQ*!2R@9u%OaE9qFl
z$Po+qk&^0M?e@#UOIQeuR<b=rTtJSXleSm81A31MPE02t=WO|Vhdm0P-H#a{SW75)
zyBE%fXec%l$3+RjuT-V`C`lv0v#>5S0!&+Fi0Xe38pvcl+|=r6Eop9QTRx<Tsn-uQ
zL!{-me2Ct%VoYtVm(di;!$>TM)niQ>jw-}qZfiAlx0>ouGgc2Zd#Hvx>VK3u`v3OI
z<W&z{-M0c%Idb^jFUSoM?k21uQf8oE9ayR0g27<hUdpUjMVmAx6I0;^4?)8A(wI#5
zSt`QTys$kNhUkIHsFUhUtjcsR$EbH|;HVJR#=Ed%0@;d8XMA-`eHNZvtu3Ts828eZ
zFJAS+)v}4o^}L9BxC9kc=9@q7toXbF4tn>Rnk}NuylwyLeb2g~k7#XSTcJM7O~0dh
z0@@bCV6y!JX^@sR>)dK|uCvtw!`3HArhfiTS?#W%FoJ0A9R&tyH38lVIT?9k9Nt||
zX?2M{z$Ru*$P+J?Y?LogT(L|Je*iUvN}h%gG*PFa!Yd@&i{O0!4KACp6p>O2k@796
zO{q*dr4%6LkOZ^wK_xjoHl5i1(Xr{RgWT|S{eVh-pp2YOHwv~TT5(*F9?Sv*gH)sC
zz;4qST|PZIouZj-%cldi<<ps#hHye+lWGms1dsaNXQ@qBWRg=K@=yom+7-((@WR+k
zcgQ-(34>qL*-1h{E4K5yNT|D27S>{k8<Rn^j5VOm%9s?EL2up^Zi}xz@T^;C=GS~c
zsq{X@dSO1V&sfik)&rR9cm;d!LW78fv5ieTreVz*wjvGQPDxIK``I=6yhFy?(~Z;K
z(sZ3gD#tJkz}lu5TtcGB>$1?+t81@=7pJjEUb^DNsV{gSEvD`@VX-7eUX#40`>bin
zX-0==QJ=7mCR+YbHCp*UP>tl!AF4*f_XE|)vEqlS(H8iDYNWV1wwfl_v%Q5K(`P(r
z!^Eyx9h>&7+kxNYH3%iAK|7Y5hA>eOWB6m!)L`ryb^SE*XQZVH=F?!pAL<k*)nToy
z^*^2^Nnktkc1Icn(A+Hz%umbYm+oAhyf$_%-P#gj_0kyDv~e<O#EZiO$Ligcc_*zu
zlT>k?T7uy@d-~EbdJKB=`gDW|p~u0W>>JfqFG@#YG(g_~uZ1WuoH%hwecAGBqRW;~
zbHf0DGWSCfrS%eShU|Xsmd#8?2AkUH&#X@QGtc%i_=bc`&#r7+wQpstzODk0jpXj7
z4EeIWBv{V~`z_St69FSN!U=#O`B-2`(t&jnupVIcOa_>x{h3x1P;52zG8IVkHcTBt
zbzmr(Ns~k^V}{|R%5)p^BpZyi8T^Z;(D|GGY^jgc6FuU&)13aNm^?t_FTJhxO!p|9
zLJ6I=CZ}o<b|Pt)bNQVQ$EHGZxk760-qt$QeRdqmrKLYLEj^c8`cr=Cx#p!m6_%cB
zS?abfb=#I+Y&V&fKHD_4zci(3YMJz3O;hdC#Z6Pqk~^<iF!}DY7?@_$(q?XHGrzRi
zytG+Z+H6_6*t&GFZRrC#7>8tUnko=+nEIQkS4gEAc8rZmPEB4R3*p!mbYQ^4j+wHr
zP@P&4CP#uD@|t=1T1W+z?n@wBRMkz4w^tRBWt22sR_Q14_Wp$wwZKR!4T-m(#9~m1
z2~ues8SVW9zfIzy%Y=ShfQq~}-aZIUx6HJPIQ=iV;_U;=b7>l|L9F@!JJYpUBrE&X
zYf!zcWgzlTCjH7!=xjg+<14Q<$!j@zEibP%%WDOBtwmmImDk$jwe}WEK}$(tOaG#l
zYDdec;+8Y<d|}H4(d3PC<e%iAo)zs!-e|Bu=|q!i3)Ngjo5Rgqe2px;IMh9z7^k=)
zd}M2NtCkyMH@4f?!YV+J1GUmmw7@UvE)AtTf(I^Gpj9f<0xNNlvXsz5L0ov0!k7=8
z3nEQG^5$r&=_YIJrgrNPXe}r^i!d!q#<F=zHNbg!BX2S?<;V``Dt0LF-MkT-8V>(A
z<~jURPEX=G?|HGCP&+j8##HR)cFuvhFLGP`)n}xnpCf^%gh5ECLc%B{m}^+VP`?ui
zRsGO$h^BRGVmEn<`rQ<}iR4s%_|?(gBqINN%&*66{W#{m4D$mz=BM{c;~C~iV3;Fe
z1YtguB~<yHNDyht8tlI3Ex@zEhDQisVE8BL-Y^HmJjF@!z-Ff%bRcizKsXO1=aP=$
zme|~FtK7EOEte<fN=31`oh$1sv0HwboXY@d1p7Ixp}9JwtilEyJ>~_CL28-{sY#n$
zc%W#WAWW%*Bis|vHQQ;=uvE84(pY1e+|`)!H%;224k+a4Z4?mIY_g^{Af0@+78q8h
zFShqG0RXyN<Z<tl$3OYmQb!qj@OuP(-V93>@;saSWOY#1d$5o#dNuB~!$K;=+l4Z%
zGLz_Fp_EGU;;>rA@!FM^qHS4)V06GgzYpZz$>dlvlC+aKOunU}n;0e@BS!<WgL1Y2
z2n69iRlb<4M$_F)FNIrV#3^89LwTzC?ig}TTrKHt7q*vQhokTdD19{D5Xss-UPDvF
zMDc#>%`fAkOim~CZLLGPHm|&Im>yxpMLbECU)C;-&MVvF9g|ns=R6*^kjmAM!{C*R
zDV}dtsEXQzf2AgZ+{P3>Omf6iK|Q(newD<|S#fWF+zhRVH<-O8aR`qEQ2Ed#7CK10
z7m4OwELFuZv&gYgj-4r(%2`gnrU!$S)zdJQ_?EDA38|Il#=TW&qmtSvr8b~jDj?lb
zp{85X8aWOWwXe0J>6U(=#XK~bZs|vh<u?R8vpCaaAJuh2G<W|A-O|ecrEW>nda=>O
z!lav<paIGHJb$*8SxFTfiGFQ}3hFMe@Xbj~-b%NI41xB<#rS`(7#wx}9cb`rKCT#O
zWHqrwv^hz#*N^LzEWm9^W3S*?Oav*PiH07lG*;gZzeAQKKXH=U?X`d@du$u?uEKQ-
zmohlf&OvzWBH?jY&R?ATtj-BJHH$gDhX5H)I*7v@_x;&@onFi`u4JoP5>p#!N%eXX
zPm5ejx<XGf=aQ!CNkT5kqbFH%NmuGg)?Ct6dXg=dbT#-XI8*3mqiC=H)G_RqeHd4B
zyN}A;yUYcQFCd5KRGE69b4A@n2Yf=a1$R19V9=`TY;BhE`--J+@yb;hI(p!B?ytz9
z&O)r;0%kbzj9)r3M}5jD`L#pZ$N&qv14PhCE<*K>$>Hv9wHF!-h&=nr?8<DeNzm7C
z4rJ}k-!RFxaRw5>Jf~`kjlRGt?k{FqLmD{vkoiSM04WAHw!E0f43LLN>i`hxn$vU$
zWNb`AlKKhJW*U8fINb=NXV?gMOiZ_X3qurd6`Y!(uTWd2;Q6DmFC#=ZUU1t5VPTlR
z8a0B|)U~WpZZ}<!=)%>iRPVvR-)o{vX<dpej6~{gJQn32p2JuIk@Z(+<DSiGUM|H(
z<@)-ax?X6*<yAb7D2I(}wRw+6tu}0dat`fCh@stBD@Q^)+6XhW^~Vh4$ZCu*o0!P+
z#>7O{V1x>CO;1o0-YfEO!R7J1Y|Kf{b^Q{04+(~_>beS;G)K}%8*mb;GZ*m(5X<Ww
zrXklLTqCgm@VptG7BR+k>91J7&Z6l^-Udmm<tjR2hP3@keCL7s2Ohh1>AZFGUcR;M
zSF~#AzOz|;JA=Zp+we%w59a3&1-&pr&X#fn3lWhcimwz_!6JNY_?YqB3Emfrv*#iX
z&~p)m>~4KEJ%187Q-8tmfbLW!bzom4TBgwM08zqib*4V<MX*~Av%7HMrc!jn%LZ!@
z&#rvQk+o`@AZ|2KEmp}Wm|+D|a6i*>>W>0hSa%VFTU>VOea@CHGX`&^S>T~Uh|7^L
zbQH+97xx?J9vp43<l;v_q9R{nVScW7$09`BDB(wLzeMik$X12uJ1S8fn5VMWMW;x(
zREi1&ouT?~)HyUuYc0PT;dFwgbo8)Yfr6l}8N?QTwxh|ony7?#KuWfnncrO`sk}eV
z19XH770+tA!xC|6KGB>U8Lx)|riJ!{xBWm)L0(Ro40t58!z5<TMA_xi`GRP_mcg0_
zIEA^=4%0EE3-b#W8wDM3&pxK$z+Azqe9Q=<j<f0DEplWi!=F-}T2D;U9O`&2RP4uh
z)AWPgq@28N=9+Pwuo=N5zIiVj_rQG%?b)#(%?J%S8Ar|`Cu3kR>3Y%rbBa!C7AO5Q
zdxf6mP*+&8aaCTNbdel6kJUUcd!EXX(M(ZdT)4tHgL|DOkO5rQpksIpTytR=u2xQF
zS4qfI%%*uQvogrjZb}O9Byqym&N%Jx`e=oI`2^C7^$#wke-!s+7{wwWjsy~YX1dW~
z){iRViV)mtC;kREXviO6yymcIm4&Yr?_kYMQN|l$n1RsSSat~F31o?%cniFQ@M2)7
zlg<*VEBMa(7j;STeSBTGk7$*xUViw;coq(~BH(;%JXZ(AhW}<Fy0uZeUgc7naW{)O
zfoNr1N=XohIj-{!$Kx}dRFo9(Xb1=YxHJ^|X6PyD)w415>P}~(^-N9Y&E9G2Q}1;K
z2jle?1~u!R37vOj+r(jX%ZP_d)HDB}1_Zjpb2VN@`?uPvqrqiv=UP{7zIv^rV75A?
zpXPOLbhdLEGPo6TJTlM;5jK`QY;bFgCZND~9Rb6bXay(&LD5OG;@UNe-N~Vegj*f1
z>uiH>R3|R9(sO|58=FnM6v?AsC(hHZ0UD0&hF3e>BZKfj43ct+TGRdB^RwyF(=opA
zsD;5WZcV*`WyDa`3Idf5(sXJ65pEPDM__`#lTd{jj@<sT&B4vS12!7n*&dGj;q53v
zFM-{{HUM^w*`;6_-^Kf)=ppmIrO~C=K0;({=_EhM@OD}}uZmY=8PL@;;|V(U&Ki47
z1dic!904@*s;E{9bx(S}aV>g;+f$y>YGoiD;l4^aI1I!!B|iPwV@*qcZE#V{j~W+>
z;Jb{8qH9GE3wi0i#=Xuj;l&CMX@}QA_nP1%4hPj|x-fw+fHT{!Dk;xqADqxvQO~7&
z<F2mD2n=qO!uOOOF@U2#%O-WfsXA=V2mjJlL_!1Hh7PHkMW}0f%R=K?si<+U1dnM3
zmj(er*X}{YmVilEg|aUxcydOZiKk?rV2<82rTQovxB<0d9RxD@I&hHN6<61Ah9T$s
z54I~~1R)9YYt}Q*a`yWa4Lryf#tOKGp2H4)5x=XkC^J5IqOVrc8OekU9JHFVI_CX(
zgbnZZoR2)~1Xe7Se2O_u)uifpdf|{<&xIC~#J4<|=e~~ZxSIHTc!O{Fhxlt&j%ES_
zs(HmPoz0d*KRGyDeEQ*awwJAV3FDa=`g%yPTjBILcp0vsnEgX^&;N56x2$>o)3CEs
z0Y1wzcO4cW7BJ6z`k7BUP0`DsU!DNH3`EZvO@r?zJ%)$rveQ<h%lV`9sTeM<M(1hz
zy#@L@lUC8f^U*y8c8Bgu+;Zc;oamH=fyyDTna(F+km9j5*a8@Mc3i=yA3dZY!Hs?T
zDPY&^Ed1>Ys3O~ZBd~$U(;JWJxz(NX>Fxte$!;FkB|@*jy1COQ-H4_znXC-Q%B+Hn
zYt|Cri@ty=rK6o>&IK6Ao^unfT`Y`CD>G=aTu~Oq8-J6vX`y?#EU6maqSTTGO`=Et
ztg~_1l4X{&m-rA>O5u}~>5y2ec+8`J*f!{V_<J1E+8ywON5G!$O#o)-OV9}N2M>Lz
zW-oO^`InA+%2LtZ_+&3`SBAb~_jbQx<m6M_H4rcRD~<y!&aId=cIBKN<PLwYq<p+o
z6L05mI}oI97_Mqj!*~OkH&VQ+Gv02-uv0!wD|>~&gBv$P$-CPX>km3{)YX-{xfwpn
z9#n>|{808ep@ATBkwXf!3vzHEpg<l@K_QZEv&2Ws!J$xgl81LDJ_htl*L<=_H6rZN
zHsuUQgx#!OZ=tA@aAj{|X_e_Uv=kl8B1?uIg>(|69F<^*CNJ9XmTr9EjXL7(Guxi6
zJ4Y)?>RB%BFJsFeehhFQ$%f&&ICdH+71bCEZ`Lh1%_O+gmnlB1bu3^ZqrU`9FZYg}
zOY5JmV6n5oxfH$&x#v%M)V>KIkRTocd-X)4@$^`u!Cht5MmQg2cu8lwMMH)4>x4hL
zt}xP5%4k<q<MH^+*iUhF<@V8i7<*iZk|T#zdgXW%82k$=y|XJ3zLUP5t`VR#--LYJ
zf)<4O9u&b7^Noc@nptQpK^oD(iJR(EMzSC@{zNZ2#7IL?QEE>3?x~MSzb1$P*f<G3
z*A(Q0`oBqD7DTxVq$?@tn^ON5=`spY<Bij#3D64(_1)6hK*A#4zEc{_ik(`208Rs}
z7%JZ?Rk30pNM#IH3A>4a@%5do-}NyPI&Y_|UF7sH<GL%xyFMmf_BRTHx1t~DZnT0B
zYY@eS*v6meHL#Id5gj5W(4qbMDclMe^f<0IUlh}V#^o&rk-ZPBHNnzp|LIL?uRr8U
zqrnrQsWovN_Oeie&4rDV7!5^*zHL~9_7JUi7WoN)8cIiUVCyIyNOCZaaFTNMXW)=7
zu6%Y&N&X^Yusx;FwChqeb`1jyQ4MKvUA*@6PBGF4<6VPNO$uiMwdd<>mLc(K>BA_U
zZC~1MrFfvJ1=6sl@T9v6)HIS8aJgjK`Ro~^K4{T%bc7b=l3r3rj9#pR%8j~PInQ^x
z4mxb6qI5sNQ_3Efr(r0aqIwRh;8>cg!R>?(V6fhUVu@6C>&^aQaI)&pv}bTkf-_ud
zLo4&Vulb_{mno0|{{)oi2kjcmZ>~1-AH)q3mOraczT3#(if33^egOIOCm^)?UL*g$
zRCK%mkCgWmHvGCqp&R{z(j=}r$p?v?&_Uth6egX9w;Iao90+3(Cu)vlupc^Gs}Qdv
z<7=V@hXB@dqGk_`(EdEl1MZw`&1xPnKIC@mq_JR}fPTrZ4>O=G9t@hNRAY?^B<^Et
zQ`-xh7{#>P&RUpei5`KWbeb9?tS=HhM_(Fxj5KdXIrh{Y7OV!LjOCOj8qB`?os3*V
z`8Xa6dWz~&2FSr7pd1_ysi6Pw^emtmZ!`q`f6Utju=9ZxQS~={z}jnPhDXJE!80A;
zOvn$Nttk%&+Z7|@smbt9*Om?AU5phB{s3j!qV@17+6LZ~U7;1Q8G6_wAC#H)*l{EF
zJGv{|1_NF09S<!t`<Mu2Lh+6lOK^veISE%QXX6@wHKeMr_8>L>;6|||V&30l2RI$_
zFcIQTUw8{0^0cbpuEY*?w!44#CcPev9Bv~j!1t1S8^6!s_Z|EaA0~5~Fg$E;<Nbq^
zF{W||ernp4l+a7)cp4x*9QB!YnjBh(@}U<2lwNeCtlCpqkmds%kLo=uh{MMP_Kx_u
zta4$Pp<IA~)5e_j!HUpJ55*(}Lhc2#By+osxsoGq;PKtQSFIy&uukf9i|LNg<?JQw
z1D-9tS-l9-CtW{(0JJ~(I+4&W-ae1v2@XK-BXp)R_Xiq^$S#Q7yNDT@I084X`(9WK
z`tvU=f?>mxc{nuW2;LJo&R3qjyN7v-d<}?SD@Wm@TX!cFh5u0~vlqTjPzu1~(7zSD
zhM&6ts&%|`>_@i#tZ{7dC@9a#8vy%KuXl!4MLj{4Q?M`kR{5IvlO@z0a9nTpQ7e*)
zkb24xr{@CM+jJNMmIfi+W5&gEKL9AkJxd=?(rVDJ(o(`7hJXNo>a~(=dKki3Z~S!4
z9@7KUoa#8xUe)b4F_knDK#M&S498{`_wz;`cAM%qXJce}D9XjyU!TC$r67C9bEA@m
zBFMyb<HcmZY0S~+_#V9WjK?H-Tp5jgn0Hf;9*g9+n(4*l$nTXJzE4pA3-6`0pa0gK
zq<5BCRqegw<V9Ldo@#DKt9V9^e#7i<(9lly)8I$xZ|tzYtW>5roBD~-<Vj8aZB12o
z$eb(I4-RK1;nN?VDtO}zDQOzYT{P6*G|b#oJ^P|+34iM&HUybN@fn5>vD#cKttI?b
zrzl16rV4t>J*~hx5zrn+mN`5Rx*3Tu0Z|dkt1ZgqVkd9LT)FYuHOa<rKxxsqoVc`$
z;RyLA{aKIj8}w&Au-&n2%cv<F3FOcDhVcTk@z*`5_?fJ@$^8!d>mFa@4|jY>TAu(f
zhmL@GheT9Gm#OGao<(t$ncgc8lCV-L{gWYpr$RLq3Q&#uOXx)ggvKjZ_Dc>3Dp#JA
z#GTwL`zHtCyDB*tIWbg-4a8><K7)Z?jdJD4<jGX)JmtzE$>AtDH0i|mu;d7QS0`(b
z6B~}wPJBk-Q=?98*@5z3X!;5eGr019LA*}F6&t~VI{<jRAFuBw*CzLfQ?3I=gJK(!
zFCLVU(x7T2+>^Qh`jLToSJ#ixL>L93B}KvNyn-?@{d7Ye>I{hSHlJC0P=~IsXVorD
z)nVjqcmcP0vBg7A;A%N70tsS38kBqw6d2{&UknnWMB(uVgCr^kp%GGVC<>a3RbnU+
zXx8_#K@Tj!J2{9z=AzJgh%ER^60ci1Czir~rL}?nxB?{MVz!apXbRcjeD)bul}*%$
zaVPjZ97lLbLxIfrq=8`>!_YWa7#1KU+BN0^{hB|-j=GoWX?41oK8dcLr@Rx7Ba;M}
zyp^oL-h{~xrOC&>jFwxOdJt+P_Q-`(yi32ljuIMb>?!a6Vi%-!+;(F0AhScB#+_>e
zHyWVVvweYf7s}jDNQO4Nn?~wFHi3j`fctWS_B!ra^ja@*HFB7-9%&c$IOAR@+Rf%h
zz-FM*RFt0XSXBT6<q-Cak8G9Mv0!NO$xb*BjJ@KKy;zSRopzvyKbf;L8h|!Ow-5$o
zdfTX4`3?qLvWPGv#JuLJdrf(Ur@@T-lOuyb5$TY>0DfsFGZp_(!#HsAvBm+)Az;TF
z2To%(2LsS%T=qDP83~?XX?Q(nt3^EjXMKdmNI0R!u{qA%4@*60Di&lUtkeM07jP74
z#uF2$<qP7QzCLlfES<{^ACnzEw!aw7Hy5*(X@D_V;D-*<Gfg&nrU@D~N`}vX$A&)%
z&<#dZobe475B@aQO7_+=%gTu@3hw4*rIlV70}n7`AV~)@83Oro*a7oiXl8sUjE1@`
zP+SEuDgQZa;y-aN(t;45Htd7?LcmK5s|upYJCb+Od?#@~;|wrI*gRMQXLZKzY~32W
zqt#Y-8s3{x+A|ImiurM<hVfh}Nq!k9NtuDua%b#LA8)xsg8TXD(AxPc*_lJ;ckD6z
zNtrO7LWSTJ^LrAghz7_+jz1=+Z(u+Ko5Z*=c$FRU4hBIy9VaJAg>-`g0M3Zvm7Iji
z&m9Kwh-GVfZf+KB!d9&0tgemd4boZ^5Y#HRcgB9x!If$6NM*d{cDo=Asvm_SD-{+k
zuAkb$+3P3DTnr;+C^5v#&ljg`)+UyJK-Y?a+Kt4Y63}B%qV<>g`;}@<M+WwVv|>>V
z3#j^AIAU<XthX^uA6Q6w0){>KQrL#~PQYlQ7^%y+s}=90DE1h=Il{;VnXSkMl_ShR
z_IcpO$TZPjJo8T}?79oi0471Or$(G@^VZ)A*IF=#Dct2NX0BMw4}yb_L^cM<$Q85k
z+V53=c`i1La;>>|38w77fuaz>Cya@Q2aP|a`YW?VJex01<)%H3NrC@ES{4Q?xB1*O
z(&_e+ssxN)blwD@lGSua>~DNHyBn;&K?yijP$r1?v48OcM+GFHAo@-GzX}$NmBe|4
z$0<Uqv34kr9c19{*`G{$9tmscnFsCMVI~_={Gt%fDm<izOV||Ifge&`u?W+A0fJ^J
zA=nY!vP#5~y|EYc{{t`HQWSDpyV>IZ6UhQNlTIXG&=O_G>Tz!yVLlnU=on$T3gZ>-
z1pC$!Ap)Nff6dg-7!gW^K9JO8P!DKZBGuC6OyEy^IRyNDIKBJMxDR^Ib--#hDGfub
zp%s9poyG-vb!fE{-V0@oTlhI8(I{XGmufSC_m;?ZLYg|@#h&t6$^O<9UZu+(O<2!B
zn=u?`G7vb8n3@U{FjtpO{FPv!=%JrnU2H4-{VAC{8%vzHm!@x^XhP>#>g5<5s)!w6
zD7}^=Vpx#a8+nH6iT>`3Zco8r;W6Q-HMC&)M@X|mc%2v^vp||odLIWH9fI}qinl!B
zgDRQ^1_qAsb}SuDACLV>4-wHbjN4W0Sp3yW3gM%8FQIKmEGPjmw{t~0clEp?m1cu*
zh6vT9u`AaoxFxQcf9Ta8!%6@%0^z&|P{4vs*9Q{Uf%dRJ5cS;gc<jmIflA=6yr<}R
z=xwganwgGmhbED|u!%>A^N0vIxC^E8sTX;a<ayFR@DeUV@m9QC#IkbK1?C!}E_l#K
zqb|f8GA-mvtOhp4IgO&WjWFwwRx|8@E_wnCiU^{?aHgX*jE8`bf9F%#BE&A~MJkOV
QSXYengSk?jru9Sq59%k7NdN!<
--
2.1.2
^ permalink raw reply related
* [PATCH net-next v4 2/2] net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
From: Martin Blumenstingl @ 2016-12-17 18:21 UTC (permalink / raw)
To: davem, netdev, devicetree, linux-amlogic, robh+dt, mark.rutland,
carlo, khilman
Cc: peppe.cavallaro, alexandre.torgue, linux-arm-kernel,
Martin Blumenstingl
In-Reply-To: <20161217182119.4037-1-martin.blumenstingl@googlemail.com>
Prior to this patch we were using a hardcoded RGMII TX clock delay of
2ns (= 1/4 cycle of the 125MHz RGMII TX clock). This value works for
many boards, but unfortunately not for all (due to the way the actual
circuit is designed, sometimes because the TX delay is enabled in the
PHY, etc.). Making the TX delay on the MAC side configurable allows us
to support all possible hardware combinations.
This allows fixing a compatibility issue on some boards, where the
RTL8211F PHY is configured to generate the TX delay. We can now turn
off the TX delay in the MAC, because otherwise we would be applying the
delay twice (which results in non-working TX traffic).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index ffaed1f35efe..db970cd6600f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -35,10 +35,6 @@
#define PRG_ETH0_TXDLY_SHIFT 5
#define PRG_ETH0_TXDLY_MASK GENMASK(6, 5)
-#define PRG_ETH0_TXDLY_OFF (0x0 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_QUARTER (0x1 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_HALF (0x2 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_THREE_QUARTERS (0x3 << PRG_ETH0_TXDLY_SHIFT)
/* divider for the result of m250_sel */
#define PRG_ETH0_CLK_M250_DIV_SHIFT 7
@@ -69,6 +65,8 @@ struct meson8b_dwmac {
struct clk_divider m25_div;
struct clk *m25_div_clk;
+
+ u32 tx_delay_ns;
};
static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
@@ -179,6 +177,7 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
{
int ret;
unsigned long clk_rate;
+ u8 tx_dly_val;
switch (dwmac->phy_mode) {
case PHY_INTERFACE_MODE_RGMII:
@@ -196,9 +195,13 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
PRG_ETH0_INVERTED_RMII_CLK, 0);
- /* TX clock delay - all known boards use a 1/4 cycle delay */
+ /* TX clock delay in ns = "8ns / 4 * tx_dly_val" (where
+ * 8ns are exactly one cycle of the 125MHz RGMII TX clock):
+ * 0ns = 0x0, 2ns = 0x1, 4ns = 0x2, 6ns = 0x3
+ */
+ tx_dly_val = dwmac->tx_delay_ns >> 1;
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
- PRG_ETH0_TXDLY_QUARTER);
+ tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
break;
case PHY_INTERFACE_MODE_RMII:
@@ -282,6 +285,12 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "missing phy-mode property\n");
ret = -EINVAL;
goto err_remove_config_dt;
+ } else if (dwmac->phy_mode != PHY_INTERFACE_MODE_RMII) {
+ /* ignore errors as this is an optional property - by default
+ * we assume a TX delay of 0ns.
+ */
+ of_property_read_u32(pdev->dev.of_node, "amlogic,tx-delay-ns",
+ &dwmac->tx_delay_ns);
}
ret = meson8b_init_clk(dwmac);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v4 1/2] net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
From: Martin Blumenstingl @ 2016-12-17 18:21 UTC (permalink / raw)
To: davem, netdev, devicetree, linux-amlogic, robh+dt, mark.rutland,
carlo, khilman
Cc: peppe.cavallaro, alexandre.torgue, linux-arm-kernel,
Martin Blumenstingl
In-Reply-To: <20161217182119.4037-1-martin.blumenstingl@googlemail.com>
This allows configuring the RGMII TX clock delay. The RGMII clock is
generated by underlying hardware of the the Meson 8b / GXBB DWMAC glue.
The configuration depends on the actual hardware (no delay may be
needed due to the design of the actual circuit, the PHY might add this
delay, etc.).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
index 89e62ddc69ca..f8bc54094e3c 100644
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/meson-dwmac.txt
@@ -25,6 +25,20 @@ Required properties on Meson8b and newer:
- "clkin0" - first parent clock of the internal mux
- "clkin1" - second parent clock of the internal mux
+Optional properties on Meson8b and newer:
+- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
+ by this driver) in nanoseconds. Allowed values
+ are: 0ns, 2ns, 4ns, 6ns.
+ This must be configured when the phy-mode is
+ "rgmii" (typically a value of 2ns is used in
+ this case).
+ When phy-mode is set to "rgmii-id" or
+ "rgmii-txid" the TX clock delay is already
+ provided by the PHY. In that case this
+ property should be set to 0ns (which disables
+ the TX clock delay in the MAC to prevent the
+ clock from going off because both PHY and MAC
+ are adding a delay).
Example for Meson6:
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v4 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Martin Blumenstingl @ 2016-12-17 18:21 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
carlo-KA+7E9HrN00dnm+yROfE0A, khilman-rdvid1DuHRBWk0Htik3J/w
Cc: peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Martin Blumenstingl
In-Reply-To: <20161202233238.17561-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
cycle (= 2ns) TX clock delay. This seems to work fine for many boards
(for example Odroid-C2 or Amlogic's reference boards) but there are
some others where TX traffic is simply broken.
There are probably multiple reasons why it's working on some boards
while it's broken on others:
- some of Amlogic's reference boards are using a Micrel PHY
- hardware circuit design
- maybe more...
iperf3 results on my Mecool BB2 board (Meson GXM, RTL8211F PHY) with
TX clock delay disabled on the MAC (as it's enabled in the PHY driver).
TX throughput was virtually zero before:
$ iperf3 -c 192.168.1.100 -R
Connecting to host 192.168.1.100, port 5201
Reverse mode, remote host 192.168.1.100 is sending
[ 4] local 192.168.1.206 port 52828 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 108 MBytes 901 Mbits/sec
[ 4] 1.00-2.00 sec 94.2 MBytes 791 Mbits/sec
[ 4] 2.00-3.00 sec 96.5 MBytes 810 Mbits/sec
[ 4] 3.00-4.00 sec 96.2 MBytes 808 Mbits/sec
[ 4] 4.00-5.00 sec 96.6 MBytes 810 Mbits/sec
[ 4] 5.00-6.00 sec 96.5 MBytes 810 Mbits/sec
[ 4] 6.00-7.00 sec 96.6 MBytes 810 Mbits/sec
[ 4] 7.00-8.00 sec 96.5 MBytes 809 Mbits/sec
[ 4] 8.00-9.00 sec 105 MBytes 884 Mbits/sec
[ 4] 9.00-10.00 sec 111 MBytes 934 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1000 MBytes 839 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 998 MBytes 837 Mbits/sec receiver
iperf Done.
$ iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 4] local 192.168.1.206 port 52832 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.01 sec 99.5 MBytes 829 Mbits/sec 117 139 KBytes
[ 4] 1.01-2.00 sec 105 MBytes 884 Mbits/sec 129 70.7 KBytes
[ 4] 2.00-3.01 sec 107 MBytes 889 Mbits/sec 106 187 KBytes
[ 4] 3.01-4.01 sec 105 MBytes 878 Mbits/sec 92 143 KBytes
[ 4] 4.01-5.00 sec 105 MBytes 882 Mbits/sec 140 129 KBytes
[ 4] 5.00-6.01 sec 106 MBytes 883 Mbits/sec 115 195 KBytes
[ 4] 6.01-7.00 sec 102 MBytes 863 Mbits/sec 133 70.7 KBytes
[ 4] 7.00-8.01 sec 106 MBytes 884 Mbits/sec 143 97.6 KBytes
[ 4] 8.01-9.01 sec 104 MBytes 875 Mbits/sec 124 107 KBytes
[ 4] 9.01-10.01 sec 105 MBytes 876 Mbits/sec 90 139 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.01 sec 1.02 GBytes 874 Mbits/sec 1189 sender
[ 4] 0.00-10.01 sec 1.02 GBytes 873 Mbits/sec receiver
iperf Done.
I get similar TX throughput on my Meson GXBB "MXQ Pro+" board when I
disable the PHY's TX-delay and configure a 4ms TX-delay on the MAC.
So changes to at least the RTL8211F PHY driver are needed to get it
working properly in all situations.
Changes since v3:
- rebased to apply against current net-next branch (fixes a conflict
with d2ed0a7755fe14c7 "net: ethernet: stmmac: fix of-node and
fixed-link-phydev leaks")
-
Changes since v2:
- moved all .dts patches (3-7) to a separate series
- removed the default 2ns TX delay when phy-mode RGMII is specified
- (rebased against current net-next)
Changes since v1:
- renamed the devicetree property "amlogic,tx-delay" to
"amlogic,tx-delay-ns", which makes the .dts easier to read as we can
simply specify human-readable values instead of having "preprocessor
defines and calculation in human brain". Thanks to Andrew Lunn for
the suggestion!
- improved documentation to indicate when the MAC TX-delay should be
configured and how to use the PHY's TX-delay
- changed the default TX-delay in the dwmac-meson8b driver from 2ns
to 0ms when any of the rgmii-*id modes are used (the 2ns default
value still applies for phy-mode "rgmii")
- added patches to properly reset the PHY on Meson GXBB devices and to
use a similar configuration than the one we use on Meson GXL devices
(by passing a phy-handle to stmmac and defining the PHY in the mdio0
bus - patch 3-6)
- add the "amlogic,tx-delay-ns" property to all boards which are using
the RGMII PHY (patch 7)
Martin Blumenstingl (2):
net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
.../devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 21 +++++++++++++++------
2 files changed, 29 insertions(+), 6 deletions(-)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Potential issues (security and otherwise) with the current cgroup-bpf API
From: Andy Lutomirski @ 2016-12-17 18:18 UTC (permalink / raw)
To: Daniel Mack, Alexei Starovoitov, Mickaël Salaün,
Kees Cook, Jann Horn, Tejun Heo, David Ahern, David S. Miller,
Thomas Graf, Michael Kerrisk, Peter Zijlstra
Cc: Linux API, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development
[-- Attachment #1: Type: text/plain, Size: 4679 bytes --]
Hi all-
I apologize for being rather late with this. I didn't realize that
cgroup-bpf was going to be submitted for Linux 4.10, and I didn't see
it on the linux-api list, so I missed the discussion.
I think that the inet ingress, egress etc filters are a neat feature,
but I think the API has some issues that will bite us down the road
if it becomes stable in its current form.
Most of the problems I see are summarized in this transcript:
# mkdir cg2
# mount -t cgroup2 none cg2
# mkdir cg2/nosockets
# strace cgrp_socket_rule cg2/nosockets/ 0
...
open("cg2/nosockets/", O_RDONLY|O_DIRECTORY) = 3
^^^^ You can modify a cgroup after opening it O_RDONLY?
bpf(BPF_PROG_LOAD, {prog_type=0x9 /* BPF_PROG_TYPE_??? */, insn_cnt=2,
insns=0x7fffe3568c10, license="GPL", log_level=1, log_size=262144,
log_buf=0x6020c0, kern_version=0}, 48) = 4
^^^^ This is fine. The bpf() syscall manipulates bpf objects.
bpf(0x8 /* BPF_??? */, 0x7fffe3568bf0, 48) = 0
^^^^ This is not so good:
^^^^
^^^^ a) The bpf() syscall is supposed to manipulate bpf objects. This
^^^^ is manipulating a cgroup. There's no reason that a socket creation
^^^^ filter couldn't be written in a different language (new iptables
^^^^ table? Simple list of address families?), but if that happened,
^^^^ then using bpf() to install it would be entirely nonsensical.
^^^^
^^^^ b) This is starting to be an excessively ugly multiplexer. Among
^^^^ other things, it's very unfriendly to seccomp.
# echo $$ >cg2/nosockets/cgroup.procs
# ping 127.0.0.1
ping: socket: Operation not permitted
# ls cg2/nosockets/
cgroup.controllers cgroup.events cgroup.procs cgroup.subtree_control
# cat cg2/nosockets/cgroup.controllers
^^^^ Something in cgroupfs should give an indication that this cgroup
^^^^ filters socket creation, but there's nothing there. You should also
^^^^ be able to turn the filter off from cgroupfs.
# mkdir cg2/nosockets/sockets
# /home/luto/apps/linux/samples/bpf/cgrp_socket_rule cg2/nosockets/sockets/ 1
^^^^ This succeeded, which means that, if this feature is enabled in 4.10,
^^^^ then we're stuck with its semantics. If it returned -EINVAL instead,
^^^^ there would be a chance to refine it.
# echo $$ >cg2/nosockets/sockets/cgroup.procs
# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.029 ms
^C
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.029/0.029/0.029/0.000 ms
^^^^ Bash was inside a cgroup that disallowed socket creation, but socket
^^^^ creation wasn't disallowed. This means that the obvious use of socket
^^^^ creation filters in nestable constainers fails insecurely.
There's also a subtle but nasty potential security problem here.
In 4.9 and before, cgroups has only one real effect in the kernel:
resource control. A process in a malicious cgroup could be DoSed,
but that was about the extent of the damage that a malicious cgroup
could do.
In 4.10 with With CONFIG_CGROUP_BPF=y, a cgroup can have bpf
programs attached that can do things if various events occur. (Right
now, this means socket operations, but there are plans in the works
to do this for LSM hooks too.) These bpf programs can say yes or no,
but they can also read out various data (including socket payloads!)
and save them away where an attacker can find them. This sounds a
lot like seccomp with a narrower scope but a much stronger ability to
exfiltrate private information.
Unfortunately, while seccomp is very, very careful to prevent
injection of a privileged victim into a malicious sandbox, the
CGROUP_BPF mechanism appears to have no real security model. There
is nothing to prevent a program that's in a malicious cgroup from
running a setuid binary, and there is nothing to prevent a program
that has the ability to move itself or another program into a
malicious cgroup from doing so and then, if needed for exploitation,
exec a setuid binary.
This isn't much of a problem yet because you currently need
CAP_NET_ADMIN to create a malicious sandbox in the first place. I'm
sure that, in the near future, someone will want to make this stuff
work in containers with delegated cgroup hierarchies, and then there
may be a real problem here.
I've included a few security people on this thread. The current API
looks abusable, and it would be nice to find all the holes before
4.10 comes out.
(The cgrp_socket_rule source is attached. You can build it by sticking it
in samples/bpf and doing:
$ make headers_install
$ cd samples/bpf
$ gcc -o cgrp_socket_rule cgrp_socket_rule.c libbpf.c -I../../usr/include
)
--Andy
[-- Attachment #2: cgrp_socket_rule.c --]
[-- Type: text/x-csrc, Size: 1545 bytes --]
/* eBPF example program:
*
* - Loads eBPF program
*
* The eBPF program sets the sk_bound_dev_if index in new AF_INET{6}
* sockets opened by processes in the cgroup.
*
* - Attaches the new program to a cgroup using BPF_PROG_ATTACH
*/
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#include <unistd.h>
#include <assert.h>
#include <errno.h>
#include <fcntl.h>
#include <net/if.h>
#include <linux/bpf.h>
#include "libbpf.h"
static int prog_load(int value)
{
struct bpf_insn prog[] = {
BPF_MOV64_IMM(BPF_REG_0, value), /* r0 = verdict */
BPF_EXIT_INSN(),
};
return bpf_prog_load(BPF_PROG_TYPE_CGROUP_SOCK, prog, sizeof(prog),
"GPL", 0);
}
static int usage(const char *argv0)
{
printf("Usage: %s cg-path value\n", argv0);
return EXIT_FAILURE;
}
int main(int argc, char **argv)
{
int cg_fd, prog_fd, value, ret;
if (argc < 2)
return usage(argv[0]);
cg_fd = open(argv[1], O_DIRECTORY | O_RDONLY);
if (cg_fd < 0) {
printf("Failed to open cgroup path: '%s'\n", strerror(errno));
return EXIT_FAILURE;
}
value = atoi(argv[2]);
prog_fd = prog_load(value);
/* printf("Output from kernel verifier:\n%s\n-------\n", bpf_log_buf); */
if (prog_fd < 0) {
printf("Failed to load prog: '%s'\n", strerror(errno));
return EXIT_FAILURE;
}
ret = bpf_prog_attach(prog_fd, cg_fd, BPF_CGROUP_INET_SOCK_CREATE);
if (ret < 0) {
printf("Failed to attach prog to cgroup: '%s'\n",
strerror(errno));
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
^ permalink raw reply
* Re: Synopsys Ethernet QoS
From: Pavel Machek @ 2016-12-17 17:38 UTC (permalink / raw)
To: Joao Pinto
Cc: Niklas Cassel, Giuseppe CAVALLARO, Florian Fainelli,
Andy Shevchenko, David Miller, larper, rabinv, netdev,
CARLOS.PALMINHA, Jie.Deng1, Stephen Warren
In-Reply-To: <79642215-95ce-7f04-3db7-121c585e2f2a@synopsys.com>
[-- Attachment #1: Type: text/plain, Size: 3796 bytes --]
Hi!
> >> So if there is a long time before handling interrupts,
> >> I guess that it makes sense that one stream could
> >> get an advantage in the net scheduler.
> >>
> >> If I find the time, and if no one beats me to it, I will try to replace
> >> the normal timers with HR timers + a smaller default timeout.
> >>
> >
> > Can you try something like this? Highres timers will be needed, too,
> > but this fixes the logic problem.
> >
> > You'll need to apply it twice as code is copy&pasted.
> >
> > Best regards,
> > Pavel
> >
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> >
> > */
> > priv->tx_count_frames += nfrags + 1;
> > if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
> > - mod_timer(&priv->txtimer,
> > - STMMAC_COAL_TIMER(priv->tx_coal_timer));
> > + if (priv->tx_count_frames == nfrags + 1)
> > + mod_timer(&priv->txtimer,
> > + STMMAC_COAL_TIMER(priv->tx_coal_timer));
> > } else {
> > priv->tx_count_frames = 0;
> > priv->hw->desc->set_tx_ic(desc);
> >
> >
>
> I know that this is completely of topic, but I am facing a dificulty with
> stmmac. I have interrupts, mac well configured rx packets being received
> successfully, but TX is not working, resulting in Tx errors = Total TX packets.
> I have made a lot of debug and my conclusions is that by some reason when using
> stmmac after starting tx dma, the hw state machine enters a deadend state
> resulting in those errors. Anyone faced this trouble?
SMP or UP system? AFAICT the driver gets the memory barriers wrong. It
does not fail completely for me, but still fails rather quickly.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3e40578..641b03d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2121,11 +2205,11 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
if (mss_desc)
priv->hw->desc->set_tx_owner(mss_desc);
- /* The own bit must be the latest setting done when prepare the
+ /* The own bit must be the latest setting done when preparing the
* descriptor and then barrier is needed to make sure that
* all is coherent before granting the DMA engine.
*/
- smp_wmb();
+ wmb();
if (netif_msg_pktdata(priv)) {
pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
@@ -2336,9 +2401,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
/* The own bit must be the latest setting done when prepare the
* descriptor and then barrier is needed to make sure that
- * all is coherent before granting the DMA engine.
+ * all is coherent before granting access to the DMA engine.
*/
- smp_wmb();
+ wmb();
}
netdev_sent_queue(dev, skb->len);
Plus I'd suggest... at least (hand-edited). Driver should really be
modified to use readl() when accessing memory that changes.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3e40578..641b03d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1309,6 +1323,8 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
status = priv->hw->desc->tx_status(&priv->dev->stats,
&priv->xstats, p,
priv->ioaddr);
+ rmb();
+
/* Check if the descriptor is owned by the DMA */
if (unlikely(status & tx_dma_own))
break;
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock
From: Pavel Machek @ 2016-12-17 17:31 UTC (permalink / raw)
To: Lino Sanfilippo
Cc: Francois Romieu, bh74.an, ks.giri, vipul.pandya, peppe.cavallaro,
alexandre.torgue, davem, linux-kernel, netdev
In-Reply-To: <6f43eac8-754b-cfa2-371d-050701deb4cd@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
On Thu 2016-12-15 23:33:22, Lino Sanfilippo wrote:
> On 15.12.2016 22:32, Lino Sanfilippo wrote:
>
> > Ah ok. Then maybe priv->hw->dma->stop_tx() does not do the job correctly (stop the
> > tx path properly) and the HW is still active on the tx path while the tx buffers are
> > freed. OTOH stmmac_release() also stops the phy before the tx (and rx) paths are stopped.
> > Did you try to stop the phy fist in stmmac_tx_err_work(), too?
> >
> > Regards,
> > Lino
> >
>
> And this is the "sledgehammer" approach: Do a complete shutdown and restart
> of the hardware in case of tx error (against net-next and only
>compile tested).
Wow, thanks a lot. I'll try to get the driver back to the non-working
state, and try it.
I believe I have some idea what is wrong there. (Missing memory barriers).
> +static void stmmac_tx_err_work(struct work_struct *work)
> +{
> + struct stmmac_priv *priv = container_of(work, struct stmmac_priv,
> + tx_err_work);
> + /* restart netdev */
> + rtnl_lock();
> + stmmac_release(priv->dev);
> + stmmac_open(priv->dev);
> + rtnl_unlock();
> +}
Won't this up/down the interface, in a way userspace can observe?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] GTP tunneling fixes for net
From: David Miller @ 2016-12-17 17:01 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev, laforge
In-Reply-To: <1481837753-10317-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 15 Dec 2016 22:35:51 +0100
> The following patchset contains two GTP tunneling fixes for your net
> tree, they are:
>
> 1) Offset to IPv4 header in gtp_check_src_ms_ipv4() is incorrect, thus
> this function always succeeds and therefore this defeats this sanity
> check. This allows packets that have no PDP to go though, patch from
> Lionel Gauthier.
>
> 2) According to Note 0 of Figure 2 in Section 6 of 3GPP TS 29.060 v13.5.0
> Release 13, always set GTPv1 reserved bit to zero. This may cause
> interoperability problems, patch from Harald Welte.
>
> Please, apply, thanks a lot!
Series applied, thanks Pablo.
^ permalink raw reply
* Re: [PATCH] net/x25: use designated initializers
From: David Miller @ 2016-12-17 16:58 UTC (permalink / raw)
To: keescook; +Cc: linux-kernel, andrew.hendry, linux-x25, netdev
In-Reply-To: <20161217010339.GA140529@beast>
From: Kees Cook <keescook@chromium.org>
Date: Fri, 16 Dec 2016 17:03:39 -0800
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox