* Re: [PATCH v3 04/10] ASoC: tegra: add Tegra210 based I2S driver
From: Jon Hunter @ 2020-02-20 14:45 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-5-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Inter-IC Sound (I2S) controller implements full-duplex, bi-directional
> and single direction point to point serial interface. It can interface
> with I2S compatible devices. Tegra I2S controller can operate as both
> master and slave.
>
> This patch registers I2S controller with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes I2S interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The I2S devices can be enabled in the DT via
> "nvidia,tegra210-i2s" compatible binding.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 10 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra210_i2s.c | 938 +++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra210_i2s.h | 132 ++++++
> 4 files changed, 1082 insertions(+)
> create mode 100644 sound/soc/tegra/tegra210_i2s.c
> create mode 100644 sound/soc/tegra/tegra210_i2s.h
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [LTP] [PATCH] Add test for CVE 2017-10661
From: Martin Doucha @ 2020-02-20 14:45 UTC (permalink / raw)
To: ltp
Signed-off-by: Martin Doucha <mdoucha@suse.cz>
---
testcases/cve/Makefile | 3 +
testcases/cve/cve-2017-10661.c | 112 +++++++++++++++++++++++++++++++++
2 files changed, 115 insertions(+)
create mode 100644 testcases/cve/cve-2017-10661.c
diff --git a/testcases/cve/Makefile b/testcases/cve/Makefile
index da44fff60..1faee9fc5 100644
--- a/testcases/cve/Makefile
+++ b/testcases/cve/Makefile
@@ -36,6 +36,9 @@ endif
cve-2017-2671: CFLAGS += -pthread
cve-2017-2671: LDLIBS += -lrt
+cve-2017-10661: CFLAGS += -pthread
+cve-2017-10661: LDLIBS += -lrt
+
meltdown: CFLAGS += -I$(abs_srcdir)/../realtime/include
ifneq (,$(filter $(HOST_CPU),x86 x86_64))
diff --git a/testcases/cve/cve-2017-10661.c b/testcases/cve/cve-2017-10661.c
new file mode 100644
index 000000000..6fe6b63c7
--- /dev/null
+++ b/testcases/cve/cve-2017-10661.c
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 SUSE LLC <mdoucha@suse.cz>
+ *
+ * CVE-2017-10661
+ *
+ * Test for race condition vulnerability in timerfd_settime(). Multiple
+ * concurrent calls of timerfd_settime() clearing the CANCEL_ON_SET flag may
+ * cause memory corruption. Fixed in:
+ *
+ * commit 1e38da300e1e395a15048b0af1e5305bd91402f6
+ * Author: Thomas Gleixner <tglx@linutronix.de>
+ * Date: Tue Jan 31 15:24:03 2017 +0100
+ *
+ * timerfd: Protect the might cancel mechanism proper
+ */
+#include <unistd.h>
+#include <lapi/timerfd.h>
+#include "tst_test.h"
+#include "tst_fuzzy_sync.h"
+#include "tst_taint.h"
+
+#define TIMERFD_FLAGS "timerfd_settime(TFD_TIMER_ABSTIME | TFD_TIMER_CANCEL_ON_SET)"
+
+#ifndef TFD_TIMER_CANCEL_ON_SET
+#define TFD_TIMER_CANCEL_ON_SET (1<<1)
+#endif
+
+static int fd = -1;
+static struct itimerspec its;
+static struct tst_fzsync_pair fzsync_pair;
+
+static void setup(void)
+{
+ int tmp;
+
+ tst_taint_init(TST_TAINT_W | TST_TAINT_D);
+ fd = timerfd_create(CLOCK_REALTIME, 0);
+
+ if (fd < 0) {
+ tmp = (errno == ENOTSUP ? TCONF : TBROK) | TERRNO,
+ tst_brk(tmp, "Cannot create timer");
+ }
+
+ fzsync_pair.exec_loops = 1000000;
+ tst_fzsync_pair_init(&fzsync_pair);
+}
+
+static void cleanup(void)
+{
+ if (fd >= 0)
+ SAFE_CLOSE(fd);
+ tst_fzsync_pair_cleanup(&fzsync_pair);
+}
+
+static int punch_clock(int flags)
+{
+ return timerfd_settime(fd, flags, &its, NULL);
+}
+
+static void *thread_run(void *arg)
+{
+ while (tst_fzsync_run_b(&fzsync_pair)) {
+ tst_fzsync_start_race_b(&fzsync_pair);
+ // race to clear the CANCEL_ON_SET flag
+ punch_clock(0);
+ tst_fzsync_end_race_b(&fzsync_pair);
+ }
+
+ return arg;
+}
+
+static void run(void)
+{
+ tst_fzsync_pair_reset(&fzsync_pair, thread_run);
+
+ while (tst_fzsync_run_a(&fzsync_pair)) {
+ // set the CANCEL_ON_SET flag
+ TEST(punch_clock(TFD_TIMER_ABSTIME | TFD_TIMER_CANCEL_ON_SET));
+
+ if (TST_RET == -1)
+ tst_res(TBROK | TTERRNO, TIMERFD_FLAGS " failed");
+
+ if (TST_RET != 0)
+ tst_res(TBROK | TTERRNO, "Invalid " TIMERFD_FLAGS
+ " return value");
+
+ tst_fzsync_start_race_a(&fzsync_pair);
+ // race to clear the CANCEL_ON_SET flag
+ punch_clock(0);
+ tst_fzsync_end_race_a(&fzsync_pair);
+
+ if (tst_taint_check()) {
+ tst_res(TFAIL, "Kernel is vulnerable");
+ return;
+ }
+ }
+
+ tst_res(TPASS, "Nothing bad happened, probably");
+}
+
+static struct tst_test test = {
+ .test_all = run,
+ .setup = setup,
+ .cleanup = cleanup,
+ .min_kver = "2.6.25",
+ .tags = (const struct tst_tag[]) {
+ {"linux-git", "1e38da300e1e"},
+ {"CVE", "2017-10661"},
+ {}
+ }
+};
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v3 04/10] ASoC: tegra: add Tegra210 based I2S driver
From: Jon Hunter @ 2020-02-20 14:45 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-5-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Inter-IC Sound (I2S) controller implements full-duplex, bi-directional
> and single direction point to point serial interface. It can interface
> with I2S compatible devices. Tegra I2S controller can operate as both
> master and slave.
>
> This patch registers I2S controller with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes I2S interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The I2S devices can be enabled in the DT via
> "nvidia,tegra210-i2s" compatible binding.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 10 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra210_i2s.c | 938 +++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra210_i2s.h | 132 ++++++
> 4 files changed, 1082 insertions(+)
> create mode 100644 sound/soc/tegra/tegra210_i2s.c
> create mode 100644 sound/soc/tegra/tegra210_i2s.h
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 04/10] ASoC: tegra: add Tegra210 based I2S driver
From: Jon Hunter @ 2020-02-20 14:45 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-5-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Inter-IC Sound (I2S) controller implements full-duplex, bi-directional
> and single direction point to point serial interface. It can interface
> with I2S compatible devices. Tegra I2S controller can operate as both
> master and slave.
>
> This patch registers I2S controller with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes I2S interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The I2S devices can be enabled in the DT via
> "nvidia,tegra210-i2s" compatible binding.
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> sound/soc/tegra/Kconfig | 10 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra210_i2s.c | 938 +++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra210_i2s.h | 132 ++++++
> 4 files changed, 1082 insertions(+)
> create mode 100644 sound/soc/tegra/tegra210_i2s.c
> create mode 100644 sound/soc/tegra/tegra210_i2s.h
Thanks!
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
From: Arnd Bergmann @ 2020-02-20 14:44 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Florian Weimer, Helmut Grohne, GNU C Library, Viresh Kumar,
Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml, Joseph Myers
In-Reply-To: <20200220141451.3fa2fc3f@jawa>
On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de>
> > wrote:
> > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> > > > Are there any glibc issues that prevent it from working
> > > > correctly,
> > >
> > > I think that the glibc wrappers for most important syscalls are now
> > > converted.
> > >
> > > What is missing:
> > >
> > > - NTPL (threads)
> > > - stat
> >
> > Do you mean that code using these will fail to work correctly with
> > -D_TIME_BITS=64 at the moment, or that the interfaces are there
> > but they are not y2038 safe?
>
> For ARM32 (branch [2]):
>
> - Without -D_TIME_BITS=64 defined during compilation (as we do have
> now) the glibc is fully functional, but when you set date after
> 03:14:08 UTC on 19.01.2038 you will see the date reset (to 1901) in
> the user space programs (after calling e.g. 'date').
I'd actually consider intentionally breaking this for a Debian bootstrap,
at least initially, so that any application that accidentally gets built without
-D_TIME_BITS=64 runs into a build or link failure.
> - With -D_TIME_BITS=64 set during compilation - and using branch [2] -
> syscalls listed in [1] will provide correct date after Y2038 32 bit
> overflow. Other (i.e. not converted ones) will use overflow date (1901
> year). The glibc will also be fully functional up till Y2038 overflow.
Ok.
> > > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> > > some basic tests [4], but this may be not enough.
> >
> > This is probably something where debian-rebootstrap could help,
> > as building and testing more user space packages will excercise
> > additional code paths in glibc as well.
>
> Yes this _could_ help. Do you have any tutorial/howto similar to one
> from [4]?
Not sure, maybe Helmut has some references.
> > There is also some work
> > in Linaro to ensure that LTP tests the low-level syscall interfaces
> > in both the time32 and time64 variants.
>
> Interesting. Is this work now publicly available?
I think this is currently in the planning stage, but once patches
are available, they would be posted to the ltp mailing list. Viresh
should have more details on this.
Arnd
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply
* [PATCH] gwdpa: gswip: fix odd_ptr_err.cocci warnings
From: Julia Lawall @ 2020-02-20 14:43 UTC (permalink / raw)
To: Jack Ping CHNG
Cc: Jeff Kirsher, Amireddy Mallikarjuna reddy, intel-wired-lan,
netdev, linux-kernel, kbuild-all
From: kbuild test robot <lkp@intel.com>
PTR_ERR should typically access the value just tested by IS_ERR
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
Fixes: 69fab0a67a95 ("gwdpa: gswip: Introduce Gigabit Ethernet Switch (GSWIP) device driver")
CC: Jack Ping CHNG <jack.ping.chng@linux.intel.com>
Signed-off-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
---
Maybe the code is correct, but just unnecessarily obscure.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
head: 7a6fc7fc71cf6316739b60fcffdb86e0c43f99b5
commit: 69fab0a67a95208a25af95de20a0301298ee23f6 [43/47] gwdpa: gswip: Introduce Gigabit Ethernet Switch (GSWIP) device driver
:::::: branch date: 9 hours ago
:::::: commit date: 9 hours ago
gswip_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/gwdpa/gswip/gswip_dev.c
+++ b/drivers/net/ethernet/intel/gwdpa/gswip/gswip_dev.c
@@ -96,7 +96,7 @@ static int np_gswip_parse_dt(struct plat
pdata->sw_clk = devm_clk_get(dev, "switch");
if (IS_ERR(pdata->sw_clk))
- return PTR_ERR(priv->pdata.sw_clk);
+ return PTR_ERR(pdata->sw_clk);
for_each_node_by_name(node, GSWIP_MAC_DEV_NAME) {
priv->num_subdev_mac++;
^ permalink raw reply
* Re: [PATCH] lttng-modules: Check the pid_ns before using it because it may be NULL
From: Jonathan Rajotte-Julien @ 2020-02-20 14:37 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
In-Reply-To: <4688fc5ac550088b553d602ef1ecb110447a9100.camel@linuxfoundation.org>
I forwarded it to lttng-modules maintainer. I'll get back to you as soon as I get feedback.
----- Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2020-02-20 at 10:26 +0800, Li Zhou wrote:
> > Check the pid_ns before using it because it may be NULL to fix below
> > issue:
> > <1>[ 22.637196] Unable to handle kernel NULL pointer dereference at
> > virtual address 0000000000000080
> > <1>[ 22.645982] Mem abort info:
> > <1>[ 22.648769] ESR = 0x96000007
> > <1>[ 22.651817] Exception class = DABT (current EL), IL = 32 bits
> > <1>[ 22.657730] SET = 0, FnV = 0
> > <1>[ 22.660777] EA = 0, S1PTW = 0
> > <1>[ 22.663910] Data abort info:
> > <1>[ 22.666784] ISV = 0, ISS = 0x00000007
> > <1>[ 22.670611] CM = 0, WnR = 0
> > <1>[ 22.673574] user pgtable: 4k pages, 39-bit VAs, pgdp =
> > 0000000012378f78
> > <1>[ 22.680180] [0000000000000080] pgd=000000007f023003,
> > pud=000000007f023003, pmd=000000007f01f003, pte=0000000000000000
> > <0>[ 22.690794] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> > <4>[ 22.690797] Modules linked in: adkNetD ncp
> > lttng_ring_buffer_client_overwrite(C)
> > lttng_ring_buffer_metadata_client(C)
> > lttng_ring_buffer_client_discard(C)
> > lttng_ring_buffer_client_mmap_overwrite(C)
> > lttng_ring_buffer_client_mmap_discard(C)
> > lttng_ring_buffer_metadata_mmap_client(C) lttng_probe_signal(C)
> > lttng_probe_printk(C) lttng_probe_sched(C) lttng_probe_irq(C)
> > lttng_tracer(C) lttng_statedump(C) lttng_ftrace(C)
> > lttng_lib_ring_buffer(C) lttng_clock_plugin_arm_cntpct(C)
> > lttng_clock(C)
> > <0>[ 22.690823] Process lttng-sessiond (pid: 3093, stack limit =
> > 0x000000005d27910f)
> > <4>[ 22.690828] CPU: 1 PID: 3093 Comm: lttng-sessiond Tainted: G C
> > 4.18.37-rt820-custom #1
> > <4>[ 22.690830] Hardware name: DUS33 (CPM2-20) (DT)
> > <4>[ 22.690833] pstate: 60000005 (nZCv daif -PAN -UAO)
> > <4>[ 22.690845] pc : do_lttng_statedump+0xcc/0x8a8 [lttng_statedump]
> > <4>[ 22.690849] lr : do_lttng_statedump+0xc4/0x8a8 [lttng_statedump]
> > <4>[ 22.690851] sp : ffffffc07fe57ad0
> > <4>[ 22.690852] x29: ffffffc07fe57ad0 x28: ffffffc008ae2700
> > <4>[ 22.690856] x27: ffffff8000724000 x26: 0000000000000001
> > <4>[ 22.690859] x25: ffffff80089c9620 x24: 0000000000000000
> > <4>[ 22.690862] x23: ffffffc008ae2e10 x22: ffffff80089d3380
> > <4>[ 22.690865] x21: ffffffc07f450000 x20: ffffffc008ae2700
> > <4>[ 22.690869] x19: 0000000000000007 x18: 00000000fffffffe
> > <4>[ 22.690871] x17: 0000000000000000 x16: ffffff800824b980
> > <4>[ 22.690874] x15: 0000000000000000 x14: 736162203b656e6f
> > <4>[ 22.690877] x13: 6e203d20676e6964 x12: 0000000000000000
> > <4>[ 22.690880] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
> > <4>[ 22.690882] x9 : 3c1f647968721eff x8 : ffffffc0877504c8
> > <4>[ 22.690886] x7 : 09093a7c093a7c08 x6 : ffffff8010c4b317
> > <4>[ 22.690888] x5 : 0000000000000000 x4 : 00000040a7575000
> > <4>[ 22.690891] x3 : ffffffc008ae2e28 x2 : 0000000000000000
> > <4>[ 22.690894] x1 : 0000000000000000 x0 : 0000000000000000
> > <4>[ 22.690896] Call trace:
> > <4>[ 22.690902] do_lttng_statedump+0xcc/0x8a8 [lttng_statedump]
> > <4>[ 22.690905] lttng_statedump_start+0x20/0x30 [lttng_statedump]
> > <4>[ 22.690981] lttng_session_enable+0xf0/0x120 [lttng_tracer]
> > <4>[ 22.691018] lttng_session_ioctl+0x22c/0x328 [lttng_tracer]
> > <4>[ 22.691026] compat_sys_ioctl+0x110/0x778
> >
> > Signed-off-by: Li Zhou <li.zhou@windriver.com>
>
> Are upstream aware of this issue? I'd really like their opinion on this
> before we merge anything.
>
> Cheers,
>
> Richard
>
>
>
^ permalink raw reply
* [PATCH] gwdpa: gswip: fix odd_ptr_err.cocci warnings
From: Julia Lawall @ 2020-02-20 14:43 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]
From: kbuild test robot <lkp@intel.com>
PTR_ERR should typically access the value just tested by IS_ERR
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
Fixes: 69fab0a67a95 ("gwdpa: gswip: Introduce Gigabit Ethernet Switch (GSWIP) device driver")
CC: Jack Ping CHNG <jack.ping.chng@linux.intel.com>
Signed-off-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
---
Maybe the code is correct, but just unnecessarily obscure.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
head: 7a6fc7fc71cf6316739b60fcffdb86e0c43f99b5
commit: 69fab0a67a95208a25af95de20a0301298ee23f6 [43/47] gwdpa: gswip: Introduce Gigabit Ethernet Switch (GSWIP) device driver
:::::: branch date: 9 hours ago
:::::: commit date: 9 hours ago
gswip_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/gwdpa/gswip/gswip_dev.c
+++ b/drivers/net/ethernet/intel/gwdpa/gswip/gswip_dev.c
@@ -96,7 +96,7 @@ static int np_gswip_parse_dt(struct plat
pdata->sw_clk = devm_clk_get(dev, "switch");
if (IS_ERR(pdata->sw_clk))
- return PTR_ERR(priv->pdata.sw_clk);
+ return PTR_ERR(pdata->sw_clk);
for_each_node_by_name(node, GSWIP_MAC_DEV_NAME) {
priv->num_subdev_mac++;
^ permalink raw reply
* [Intel-wired-lan] [PATCH] gwdpa: gswip: fix odd_ptr_err.cocci warnings
From: Julia Lawall @ 2020-02-20 14:43 UTC (permalink / raw)
To: intel-wired-lan
From: kbuild test robot <lkp@intel.com>
PTR_ERR should typically access the value just tested by IS_ERR
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
Fixes: 69fab0a67a95 ("gwdpa: gswip: Introduce Gigabit Ethernet Switch (GSWIP) device driver")
CC: Jack Ping CHNG <jack.ping.chng@linux.intel.com>
Signed-off-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
---
Maybe the code is correct, but just unnecessarily obscure.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
head: 7a6fc7fc71cf6316739b60fcffdb86e0c43f99b5
commit: 69fab0a67a95208a25af95de20a0301298ee23f6 [43/47] gwdpa: gswip: Introduce Gigabit Ethernet Switch (GSWIP) device driver
:::::: branch date: 9 hours ago
:::::: commit date: 9 hours ago
gswip_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/gwdpa/gswip/gswip_dev.c
+++ b/drivers/net/ethernet/intel/gwdpa/gswip/gswip_dev.c
@@ -96,7 +96,7 @@ static int np_gswip_parse_dt(struct plat
pdata->sw_clk = devm_clk_get(dev, "switch");
if (IS_ERR(pdata->sw_clk))
- return PTR_ERR(priv->pdata.sw_clk);
+ return PTR_ERR(pdata->sw_clk);
for_each_node_by_name(node, GSWIP_MAC_DEV_NAME) {
priv->num_subdev_mac++;
^ permalink raw reply
* [dpdk-dev] [PATCH] net/mlx5: fix metadata split with encap action
From: Matan Azrad @ 2020-02-20 14:43 UTC (permalink / raw)
To: dev; +Cc: Viacheslav Ovsiienko, stable
In order to move the mbuf metadata from the WQE to the FDB steering
domain, the PMD add for each NIC TX flow a new action to copy the
metadata register REG_A to REG_C_0.
This copy action is considered as modify header action from HW
perspective.
The HW doesn't support to do modify header action after ant
encapsulation action.
The split metadata function wrongly added the copy action in the end of
the original actions list, hence, NIC egress flow with encapapsulation
action failed when the PMD worked with dv_xmeta_en mode.
Move the copy action to be before and back to back with the
encapsulation action for the aforementioned case.
Fixes: 71e254bc0294 ("net/mlx5: split Rx flows to provide metadata copy")
Cc: stable@dpdk.org
Signed-off-by: Matan Azrad <matan@mellanox.com>
---
drivers/net/mlx5/mlx5_flow.c | 66 ++++++++++++++++++++++++++++++++++----------
1 file changed, 51 insertions(+), 15 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index fa58546..60aab16 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -2744,7 +2744,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
}
/**
- * Get QUEUE/RSS action from the action list.
+ * Get metadata split action information.
*
* @param[in] actions
* Pointer to the list of actions.
@@ -2753,18 +2753,38 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
* @param[out] qrss_type
* Pointer to the action type to return. RTE_FLOW_ACTION_TYPE_END is returned
* if no QUEUE/RSS is found.
+ * @param[out] encap_idx
+ * Pointer to the index of the encap action if exists, otherwise the last
+ * action index.
*
* @return
* Total number of actions.
*/
static int
-flow_parse_qrss_action(const struct rte_flow_action actions[],
- const struct rte_flow_action **qrss)
+flow_parse_metadata_split_actions_info(const struct rte_flow_action actions[],
+ const struct rte_flow_action **qrss,
+ int *encap_idx)
{
+ const struct rte_flow_action_raw_encap *raw_encap;
int actions_n = 0;
+ int raw_decap_idx = -1;
+ *encap_idx = -1;
for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
switch (actions->type) {
+ case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
+ case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
+ *encap_idx = actions_n;
+ break;
+ case RTE_FLOW_ACTION_TYPE_RAW_DECAP:
+ raw_decap_idx = actions_n;
+ break;
+ case RTE_FLOW_ACTION_TYPE_RAW_ENCAP:
+ raw_encap = actions->conf;
+ if (raw_encap->size > MLX5_ENCAPSULATION_DECISION_SIZE)
+ *encap_idx = raw_decap_idx != -1 ?
+ raw_decap_idx : actions_n;
+ break;
case RTE_FLOW_ACTION_TYPE_QUEUE:
case RTE_FLOW_ACTION_TYPE_RSS:
*qrss = actions;
@@ -2774,6 +2794,8 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
}
actions_n++;
}
+ if (*encap_idx == -1)
+ *encap_idx = actions_n;
/* Count RTE_FLOW_ACTION_TYPE_END. */
return actions_n + 1;
}
@@ -3739,6 +3761,8 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
* Number of actions in the list.
* @param[out] error
* Perform verbose error reporting if not NULL.
+ * @param[in] encap_idx
+ * The encap action inndex.
*
* @return
* 0 on success, negative value otherwise
@@ -3747,7 +3771,8 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
flow_mreg_tx_copy_prep(struct rte_eth_dev *dev,
struct rte_flow_action *ext_actions,
const struct rte_flow_action *actions,
- int actions_n, struct rte_flow_error *error)
+ int actions_n, struct rte_flow_error *error,
+ int encap_idx)
{
struct mlx5_flow_action_copy_mreg *cp_mreg =
(struct mlx5_flow_action_copy_mreg *)
@@ -3762,15 +3787,24 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
if (ret < 0)
return ret;
cp_mreg->src = ret;
- memcpy(ext_actions, actions,
- sizeof(*ext_actions) * actions_n);
- ext_actions[actions_n - 1] = (struct rte_flow_action){
- .type = MLX5_RTE_FLOW_ACTION_TYPE_COPY_MREG,
- .conf = cp_mreg,
- };
- ext_actions[actions_n] = (struct rte_flow_action){
- .type = RTE_FLOW_ACTION_TYPE_END,
- };
+ if (encap_idx != 0)
+ memcpy(ext_actions, actions, sizeof(*ext_actions) * encap_idx);
+ if (encap_idx == actions_n - 1) {
+ ext_actions[actions_n - 1] = (struct rte_flow_action){
+ .type = MLX5_RTE_FLOW_ACTION_TYPE_COPY_MREG,
+ .conf = cp_mreg,
+ };
+ ext_actions[actions_n] = (struct rte_flow_action){
+ .type = RTE_FLOW_ACTION_TYPE_END,
+ };
+ } else {
+ ext_actions[encap_idx] = (struct rte_flow_action){
+ .type = MLX5_RTE_FLOW_ACTION_TYPE_COPY_MREG,
+ .conf = cp_mreg,
+ };
+ memcpy(ext_actions + encap_idx + 1, actions + encap_idx,
+ sizeof(*ext_actions) * (actions_n - encap_idx));
+ }
return 0;
}
@@ -3821,6 +3855,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
int mtr_sfx = 0;
size_t act_size;
int actions_n;
+ int encap_idx;
int ret;
/* Check whether extensive metadata feature is engaged. */
@@ -3830,7 +3865,8 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
return flow_create_split_inner(dev, flow, NULL, prefix_layers,
attr, items, actions, external,
error);
- actions_n = flow_parse_qrss_action(actions, &qrss);
+ actions_n = flow_parse_metadata_split_actions_info(actions, &qrss,
+ &encap_idx);
if (qrss) {
/* Exclude hairpin flows from splitting. */
if (qrss->type == RTE_FLOW_ACTION_TYPE_QUEUE) {
@@ -3905,7 +3941,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
"metadata flow");
/* Create the action list appended with copy register. */
ret = flow_mreg_tx_copy_prep(dev, ext_actions, actions,
- actions_n, error);
+ actions_n, error, encap_idx);
if (ret < 0)
goto exit;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] block: Prevent hung_check firing during long sync IO
From: Jesse Barnes @ 2020-02-20 14:43 UTC (permalink / raw)
To: Ming Lei; +Cc: Jens Axboe, linux-block, Salman Qazi, Bart Van Assche
In-Reply-To: <20200220120527.15082-1-ming.lei@redhat.com>
Yeah looks good.
Reviewed-by: Jesse Barnes <jsbarnes@google.com>
A further change (just for readability) might be to factor out these
"don't trigger hangcheck" waits from here and blk_execute_rq() into a
small helper with a descriptive name.
Thanks,
Jesse
On Thu, Feb 20, 2020 at 5:05 AM Ming Lei <ming.lei@redhat.com> wrote:
>
> submit_bio_wait() can be called from ioctl(BLKSECDISCARD), which
> may take long time to complete, as Salman mentioned, 4K BLKSECDISCARD
> takes up to 100 second on some devices. Also any block I/O operation
> that occurs after the BLKSECDISCARD is submitted will also potentially
> be affected by the hung task timeouts.
>
> So prevent hung_check from firing by taking same approach used
> in blk_execute_rq(), and the wake-up interval is set as half the
> hung_check timer period, which keeps overhead low enough.
>
> Cc: Salman Qazi <sqazi@google.com>
> Cc: Jesse Barnes <jsbarnes@google.com>
> Cc: Bart Van Assche <bvanassche@acm.org>
> Link: https://lkml.org/lkml/2020/2/12/1193
> Reported-by: Salman Qazi <sqazi@google.com>
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
> ---
> block/bio.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/block/bio.c b/block/bio.c
> index 94d697217887..c9ce19a86de7 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -17,6 +17,7 @@
> #include <linux/cgroup.h>
> #include <linux/blk-cgroup.h>
> #include <linux/highmem.h>
> +#include <linux/sched/sysctl.h>
>
> #include <trace/events/block.h>
> #include "blk.h"
> @@ -1019,12 +1020,19 @@ static void submit_bio_wait_endio(struct bio *bio)
> int submit_bio_wait(struct bio *bio)
> {
> DECLARE_COMPLETION_ONSTACK_MAP(done, bio->bi_disk->lockdep_map);
> + unsigned long hang_check;
>
> bio->bi_private = &done;
> bio->bi_end_io = submit_bio_wait_endio;
> bio->bi_opf |= REQ_SYNC;
> submit_bio(bio);
> - wait_for_completion_io(&done);
> +
> + /* Prevent hang_check timer from firing at us during very long I/O */
> + hang_check = sysctl_hung_task_timeout_secs;
> + if (hang_check)
> + while (!wait_for_completion_io_timeout(&done, hang_check * (HZ/2)));
> + else
> + wait_for_completion_io(&done);
>
> return blk_status_to_errno(bio->bi_status);
> }
> --
> 2.20.1
>
^ permalink raw reply
* [PATCH 1/2] riscv: roms: Add 32-bit OpenSBI firmware image for sifive_u
From: Bin Meng @ 2020-02-20 14:42 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Although the real world SiFive HiFive Unleashed board is a 64-bit
hardware configuration, with QEMU it is possible to test 32-bit
configuration with the same hardware features.
This updates the roms Makefile to add the build rules for creating
the 32-bit OpenSBI firmware image for sifive_u machine. A pre-built
OpenSBI image (built from commit 3e7d666) has been added as the
default bios for 32-bit sifive_u machine.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Makefile | 2 +-
pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin | Bin 0 -> 49472 bytes
roms/Makefile | 7 +++++++
3 files changed, 8 insertions(+), 1 deletion(-)
create mode 100644 pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
diff --git a/Makefile b/Makefile
index b5a7377..ee7aa6d 100644
--- a/Makefile
+++ b/Makefile
@@ -804,7 +804,7 @@ u-boot.e500 u-boot-sam460-20100605.bin \
qemu_vga.ndrv \
edk2-licenses.txt \
hppa-firmware.img \
-opensbi-riscv32-virt-fw_jump.bin \
+opensbi-riscv32-sifive_u-fw_jump.bin opensbi-riscv32-virt-fw_jump.bin \
opensbi-riscv64-sifive_u-fw_jump.bin opensbi-riscv64-virt-fw_jump.bin
diff --git a/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin b/pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
new file mode 100644
index 0000000000000000000000000000000000000000..93e2556baa261bfd796cdc484b345bf958c8afea
GIT binary patch
literal 49472
zcmce<3tUrIwm-g4PEJmO55TBst1S`%p{+&Z<EmH7D@5>7bwmfJ_Q5GSc5WXIb-Yf;
zTQE7qfCw5frPUeg1C*IsYpP7Wf8`k>S|7E7)v4ARk!l~&DpFA3_uc0Z3D#==_x}EW
z{e+X8v-e(Wuf6u#Yp=c5I(j8X9A=K_H7YVHRIkQ2PDvc1lIT?$(*9dPIfxO4a@rs@
zAzHOMUYz>$2;Awf?q^pJVq29O7sTQT>%OfkN+n(QVoh5Vr0aeRt7C~BWo)Lc(Wb2|
z(f9pL^kaV&On>ZW?~A)@NA`29{jcbae-&zfqZ0llD1&fU+xNA}g5kf2@SE4jgq`x8
zwg2wDGwS`WJFP+fDC_Uv*Zbt?F2V3NYQ0Vxiv?#jBYf^=T6eL#SfVScV%90vvF^jE
z9jn#~|El6-oZRCC=WmGcc{Q_emwbo4dndWL>&^`sP9E<qyQEk!yZ|`InHa$NBkEsd
zHt$;c*ix-Y*O%ym(}@g6rbo!tAelx{loo<DHB4?-c)F{vVfwz$M?dmcaVGmAOBm_D
zJL#)V#ag-k#V5P!KiN%7_Y;(sj#a7Ae_hYTQQG^HC^j>C*f71%h&rq)qW9y;QxU$S
z>d4X%J?}??%0NBd^>3ypc#eJ2$OT=*Z$<1^4oeO@Wxc+yf{1ZUoL<qFIQaii=oLRk
z+jtT{uR%PmS@Na52_t9;|I)E4huvr|%+m#5B)X6vi7yVVVY=a4dT^ER)3lMguwQ=q
zYM5?B&!;kESASjPMKAtO>Yl`R2_ws+x{<&jSfTKRp~tiBVTpOVkc$dmIy`1`$EM#1
zI!*i1bli@s&9eBsE|@2Qyn9AVhi@B9n4ax9Hv}c<&#~l;^ZGn3f6d>w^pz*?Q(7e`
z94dYK=NL82xgSpw)7Ds`U&|8h^L-ipfBis0`a1B-c782!bo@Z7`s(vATi*7NRDav&
zCdP5YO&soO#^L@PA2;)^O<0gl*j)<rw;H@1$hwo#JFKxXuWZ%mf`23NM8pp7JwZ+R
zr;EQfrgmgTUx`c)h>pT%jLZxCATKYZKM{RhnDbUInI{wnWu5>Zu)chd9-tVbXE4_#
z>W8b-1LjBF2%i<@eypV<J(P^m3>S+Sq9r~4W#Cr^xj-`L{n>#b6=79LH9?<X6f~Lu
zc6cJkMrb&_#;UMi!ibpT_Z{A#*KAWb%)?`}8t|VuJVp_}K0YLI6tgNLoy-boE@w!3
zKgAeb@EpaB5E5lOxrf+(98GLhqlsWq5QhRdFtIHWMe?_pmVq^<5QSpkVOr}(NWhqZ
zm9*Z#YK0TOQ2&pp-;W5Qg5dtBflft*s;X~ozeA6F`q;6M6JaMKPmOFC{l&Pm6Th5t
zzN(_O>Tu1m+LMPG4xjz>{IQECE}y)5>W79Ozqoa_?aPkydX6DCKnqX6iD%bG?}>?x
zO^y38PBC}=+>qow$+7cJ&P$#D<9yZBjZ?!C_a!DIH6$&Xc59mIxsA_-E!?*-;rWK=
z7rk)nh3we${C;EJ#a~6#y*QTAyQ5CVhQy?k;3%2i{sDwAF_|$;Y-TJIml?;zXU1nH
zFvd(HGc|K6lbD&vBxNQs(=w+q(=(?tGcso|Gc#v0&t^WGK8uW5m9a8;l{7x9GUWF3
z93k}kc#f>5*C71Xa-2dPBbVb0^3_|8kZ3y2BxUKAQ^h9_pU7%BcI@P*pwOZ7wHbp-
z&7SBN|7fb+z_7JuhIMUYOs<caEvnDf#`4K|7x^=Jk=FN*vxn>)>pab|)fUd=Ea6Ot
zTpU~5#Ide2&Q#mNg>bf@)x^=Xm{f84v;j=4ikqq*G=e#oo4D2%WMQ=SEaqt5>^$4N
zpJE&>JhLqCOx{OLq9LfB;_l4%1n-_F8d;Z&h2YoR&qOh){g?^iXXjM`i^C#qBTRHG
zX(2&pQOmD1*AsnWwkh0?6uLdp`C~E-VWNken7pi&NjNOxdvwLhv}PewqcqhHR<X4j
z73+#nnOqZ8zP&Tmo>s86E(PmqQkYyV3g2gi)vN3augmSe(RX&c^ev#`xx`laTahBB
zS$?{E^5pg;Ks+&l;!|wj5XTskL{YV&+H|Nt!yY<COwJ9&RHa0phBKz)HH59bMA+kI
zf_@Uyu`vvL>?UEWKPFq$A?huhqp^{3eDhmUrPBZYCs4DBKbq&bJdnBASHDQbr1rH9
zfE2oXp6C}HBj-Se-J$o=%f1~mRt$ZMQZ3LxspcVXJZg6ltiL6HcB{GXM44WZ?ta{N
zTo=WPUU5IlT?Or;GM2jsa#sb@|D1YO7dX-G)^e9+NYQ_G59KaN-vctHx`VpDlUc91
z1G!6{sHkyxeo-#Fdjy_eG`ZpxV$Qnb@@Sq&pcLM%qkXVhT(545d+7jscmpVE2G4E-
z?}A(W^sk&HRlK9g$jB6M{z3bQg$V*Rw4C8T^slrLPgL-W-rt_67hmuMzqqVa6kaIm
zS2@k`-rtE$6QH#DDO<I@c5^dDPjK)b7^f~{A|v{V8e40tzkB17PF;o{5g5O|HZGgU
zZHaGrqKX!r7qu#7t9&QzFQ8%yYkY(=CHQeBV<cxXOyoi^t0+HT<j&>F<w8-8%s(u4
z;j|L?&0}5tiK$iz?idcv8AE<v%ZXY=zhPZ-Q7#_kUPie$dz9Om>C^sfz(_5%0;AN(
ztYclUM6~hZvvMi%RkSyg&YFzT(%<n*_S$70`iop54J9(B`}WZA8tPBWG=!FSwXp=h
zlL|gb4<lnt2^$%cA&X&+#f-_g4-)0*U5WBRwW&4;@&me#E1WaA#&f>2PFUKkj0p^>
z39C}o61BaCt~{4!Zi+5!+7lgu)n<wqgVm-~OsA4OdUxMV(e(b5f*~>9XPL$+;;Ia}
zjid_NN~F~jO@^D|3mG=S3Y>N_ri4$JEy~Z<#PWtb+lDOW%o@R>gw)x<VYWiP)o|=F
zGi2R1;CTsnehfKxliR|Fs2xo%M*sUkOcfWa5~n)e*?}2IXJrpL*Ffc5kR<1>d<zNt
z7gKG2$RH(T&~V70G55$IJLG|du&xq}WEt_L#yZF#@IAQ(?mzH^$%R%9DOHdnXlabf
zR$w98jVi{`$T6SgY6n`F8EaX?K-M%>#hMIZESoTn4Ur^r6<3#=s+zGj@UUW|)B;-a
zwz38Dg=eZ%=OkHOp9h%;d|be%3HY@93?EN)(Lzsj@aq(>Hzp^E=Z3YHf!d&R`in7R
zM#t0fS+O+al&T@@WYUS5$L4%G@9=^{&)1ScruYJeohpJOwqq3bVgwwQluQ-x%(L~k
zFe{Dc)(Ee;0<=M4M4sj0<M!Lxojeg(O~3~g(&!w+=p4i795-V%+J=#mM~6KmjZR-j
zQxl_q?K~69R;k6Aj=vrxdf^6fd~--1pP<zYU8VGkgBa}>9T=n2jD9)KoXKlWscYJ2
z-Icv3Co;zq9lb<`UlP74jt$o+^nT4mbL3c7sW>ldfvB*TT7{XM@}&4Yl@BZYNdWVH
z#e+w9KFih`S=P0fHMy3vz9U>%Jx^R^H-#rEG7}4{7vTGzSs`<0itFbpQhrQKO*)wr
zJ8jQ2!%M3&np4hEI@eH+?xUv^w>znncj}0Gq$Sg+RT0IoB9RwzU8H|pAm84mwTF}a
z1*<DZcg>p7@%8iN`LklFsv+dmz2mdXI@-D~dty#xHsnAubc3kfZ&WUC%qz|LtjT6q
zGLwyED$?1$w(#OhL0foyzec|=4O&mXSJ3Y(g0gv=tEIEuG&E003+Ek$5sbF(W~Y9|
z1ngclN=NG$=9n4lio({?pNJWmM-Gc;v*u;Z5e3r|%oRPSX}sw;wSo~>ix(IJrNqza
zP;6Og++I#=ofqebDU-e~UzU8PoH;rqdEF5&eU6T$Qh{>fGU!h-ceWdat0lyblgD;(
zz?1@AFh^v5_13dvCuXxW@pJ{hKH1xbTtEE{FL(DW?NZXxEAK*N0z*EXS*to0b~xz}
z31E!{kTx>Uo8tFEqe;%Q*8)mbEjXXusUlbnl;_rzS|bZV@087-KA4m2;3Nw;sRW!<
z)`OF%tjIKARt8s0FEtOS464Jbr@6v-DQybZkeOnpYtwvMG7yyhF*-H=WPEJmo<t7(
zMez<hOfgS7G^d6H?6Q`ck2cEG;#;J7=%?u`Q^?i)P8{fYp{cLDU$NXA6enD1>K#_7
z3)Wyw+VG3|<W4I6Aq#m(uyDx2@%PBW)99ZI{cA%1T6**^(=`*bgK12EF+PehbmJb9
zM6s7wD`#M!;d(H|S+}d?YNR!yGH5^57X7|6g=Z_o<8#EXN4ev;JErg?j$*EhDETJ0
zI%qG|55(`5jdB~fHrhko-%BnJC{IpaQa(F51^ks*PRCqclS<9$Z^TDMOny)=Hy?j+
zFN2hzfD#l?f&xlkc|gZTUg;?J(lL=aX=d%5nt4?uAkAr8K9-c4GhMbfot^8HL68B^
zZO&oTpOMGL_$3`HEi44`Gx1*zzK{riXi-Z&4rw`yvQq@2@w*X0#;}JAp+i}rL+ykP
z^+^vMit0{OXA+2?%9QX3$3l}~sU~Bb*kjFpzdAFiL4>vxT{Ivp3p`lh37GZhFV_(L
z&g8kjX}dG52=a3rlSs!hNt8J;Bx$`go=oERU8{;bLrn=-J1~z}tQ{u0cKGa3K05Lc
zYGXa)v7UuvJsaO+J!1@ocV)&%Dto)61}Kkx)c*$Ne84mU=3>BH{(lMPC$0zg^8tFq
z-Cp|k@j?B27_0~A2=|4>1gefv`9cDc4$Z7BHIIZgdcu$Dq}N^(4UU4bjLq5Hc_o)g
z2onus9yGV!f0zV;&W8P|s|mVgOAkIRtWLrhL%+TD?D_lR!$|m~-HQ+N@BbToep%Z2
z;8PFzf_42yXuzTL(13~?;Q@!-?>2WlocCFmMakt%IP$RZvP0rnAaP0{amsp1ocoLy
zW5@*m-;0f`RjX>ls-T%m`!If^Ij(erIKI@fI{J$)P24fQ8Cu8s_=5#hg30}oONZMw
z#X%P-m>#2!x%b)Pb(`X*6!fmth4`$=pom=4l1HCThbBYoNqh@EvRf87E~^-?#X{O&
zs92}(3R8D?_W|uz$vR!2L=z~{0!nm06J1owQ~heBxCfj9E2|=Xw{Z-v>hvOGlvg_3
zd*9njsoZX3l=QsF*rf~8Hep$lb|NFOrhfLd+$ZCz)p0R(VFlC@G=%mWa`>0mO~&vr
zzMl`iH-hgMgYTE$hwtT8MUhA;D6f{=|2E9vxz<@It$3v+|2ejGcJdXUmF_|Eq161)
zH4gaPe~(AkxE?eF%^uYEhe3jMs@8&@!!iYnl<&&$u+?<Bq0lINSJuy7Of|Aad0KlY
z8D}37x6i)HVv67h8)1N5D}oWse82YjY@|p8b!)%Oc<~jXj|QhRg=CJ{u)z}*{qOFp
z!#f8TQEQ*CW+Ja;{bPO`<7m1}t{-ooFZ6Ed%`I9A+x|Y1p27FqQ{eu#vEzDKK+N12
z$KnR!M48?OVb!hPnMN+H{;ZzAMbb%Gzf!yV+tVG%WxiNdqO63IqScS$<YqNLIm9uH
zj1w6}amp?Ct+Blt81!vbX2x@`xO;1E>d}Lf6#r4~Z-;jl_GmqqV%w`#A(d5We)N{j
zc#@WlC=V*2nn&YGPcWG_sw|z5euK+ky?Bbj--^iZ52Tab{pt_Qfi>wuWb<BneQ`wn
zUPjU~=T%WHlj<}JDxhhaOS4Ccxns>!KRLv}9vbxDXt~$4*@Ji3f?63d<J=l;%3zGc
zaE9|MI70Q=#?vRod1!HWUsFUcQd%e)pnU|)8k*Mr^BP~@?l~fgX;fdNJJh5TbdO2~
z$$Ar?WR8opmTnkalqBwa#>UmOQ%l$dE&aB#-n$o}JF%bFH73xyv}EZ9S}P-9@b~mr
zlE~a`DcWDtDBo+Id~a)EC%yY*RYTGVx>w$3j?CGWJvtjy>%!0S%oov{;;{F;)kNCo
z>xz`*%L+kE<Ynx`r%<ggNCnENvNXlwyh6GYn6+GE6pi-xz}-1V(ganb!V9^3Z#hMz
zeOe$sHU4DQOzf#Z*WhS<u}JH`@fUYI*O6(wQWhrGjcT7?C+$F~ER)s%X}9DW*G;!`
zV`bauZsoEwzVb$11-PS|>waqx6G|;YuhWV?O<x!^hN15KxKnZL4vu^gvu9(hU08ld
zAuKsf-bvgvjWI0Dd#5h2NMn%Y{wb7qzjwJ~gYg}M+kUy@OquZ3X_8-gD(;;`&Ty)7
z(==NCvvT)fReR;#y|TT8?&-px7-!iK=ed@b@0H>*CwlpCUKQoUQuBeYWqK}-*c2zM
z<_89$k6PY1LLDbCT-UGg@ZNDkHrGE0Eo*s8X#cpCM&aet{fq6oBA$GfFf5_CAgln?
zpYe0uR^~oaV)w3)rP{2<apjC;xg5{fF|TZ5<8<3#3$@)|X(gU(AC^<BbVVh>^4!RI
zd}*CrE^S&2WcY^%r02UzhS;&+v1KO>O+MQ7JW0zDKlJ;*r4oNHc|_h3U43L>rEIrz
zJ`R0oO{7(b=Twwdx~(OHgf$Pd{LY6yVZ<uB7^~>=9{L2AMy0L<ZA(diQ+O}JZucXm
zP(R|_%cV7zvH0e>_Iee)>$&EsWJ7z=-<4+$%ucC0ket%Gm)@D3;<@&8McrOnihh5+
zTrTH1xKffK-Mb<ZU`j|<vk3+@YfMv{jLX!%E5HXPZA&;|lSH);z(<vuwOoc$+d7`?
zvU&nu?4w=qXM&YS&DNULLJ$|gy0)oJu8(`PplxYs(ay6F+dLk7=@$Malg@loz13W!
z)`_RoTg6Li+NLKULoE#9Mwm*hBt3t8e^ZGD*C1RIaSiXE9yTk$R6AE~a>lD!*UNzN
zCZKd%MYX@pBHCow5tFl+70b1J%j>#~8uiu;rAC*zO}#bqW3`yjn#U~`_%k6|p3gXw
zr#+36l?LF|z%#m4z{qq-y>(TMn)X*`I;94#?SrdrO}s+ea=Np-2dDkf16m$sX*pW&
z=lf~c)Pbi=i7LK6FO^@IXItLVBCvi+Q*k2clknL<;iU!@m*g0DmVA)y{K1Qhc6kf`
zHE0BE?$YR{Od~SuPj15fux`h%DVv|3eBjrV3s~w_ao^ksCojStPJ4Ykgx4<T1AuQ(
zII*?x!DsS71$BBp|Dvg+j*iaD7#$`(zvN}>0s7=F6j1cOV@poF(lxHbyT%n)X<Ub6
zT!SApuF_b(O-D{1H5(o0->Mib#@SXcj~*RKd9?duw3V8zncLLz2z`8agwVfW^vxsm
zPh@~|03GG-5pI4Dy$kkT=NJQB<p4AP%zwN4`Telnu_AfYfrU%A)XY5pd_(G~tlHwL
z!xeMBoOgD?7a8hO>&P{p;1i=tb8ZX|9usCwe<Es(#MLC~cbqdla`%`Ukws&KYNg_U
zQMhFPi+v-cOx9&iYaf1BU&1M7lKV4d$9N4+loMM!^{vC1T%((7Rctm2fvt*E?7KcZ
zx-U8`eq+2U@yC?Z1t%B8{%+6jLY{jGn941x0#_tQT4c$^DWA^@l5~vifjF~`Utl?$
z^?a86%%G5;IPoMZPR2BUme8O33tO9_#)+TWbSP2H9@2n^mtd|%VBSqov(6Rj5ZIga
ziw5HSjP4jHXV1<{<!l>8CNb~a+Pm%Fk=r-W_9wHog^&^{#B|6?SZ5-3^g9XKCG4S3
zaPG2#c-yR7TgAunpXK4?luK3P?2gRHv)e%_i^X5=UxL3ELg+0SLRw!>K)`smb}+R6
zGk~CBSZ5s|M8Fzz1rR1MCTHuffDqohYfO51A#m5a`k?j%T#Eu-6rhU&bWyNQjl$$w
zf>X~31$$_P0<=;5iaw~i`k?YcXuKjr2vuNwBH7wAfKUhsb%0<6ge!os6A)Sf;geqh
zp^3;4iisD3(=9{b?sx)r4@VzZ^npbmSo8rF!X>a2MzH7ui$1Uq?}PES3_*3<3t{^?
z8A4;TCm{bZ^Z^hG0ig~MtblL@5OxAWD<FLGD<G6K%Mcbddm)IYWe84>C*X}i=z|h{
zP@)gmhib5TF2O1qp+p~)=!5d%ec-Rj5NbVM2x*_m5Vl`|4%`oY0E9w7r~?EmAY1{2
zoq*5^2%r242#c@E5W=o{AsCLx5JWfTLvQo}=V60!`T`#jrv|&OCD?sM;OuM#&dero
z5ATEPk_;j1k{3d#Q-+Xs4)X!_;WL0x2ncn6U<HILfUpw~S^?pcUjZTfD;dJ&^IiyC
z*N(+-+7oc$ZS(;rV1rfY18fBvSfZD}A{~MAwG}G#LG|!HSkA~063%!bH2zcWL+EFo
zfQl9910WOvLLDGj0pSWD>;!~XK=|ZWKxq10hEV*u7lLz-41qi12`EZuYpLxvg@Igx
z)JSAZk_~qW1GxmLv4VMcAB@Lj2&!XV2;2W5LujmlM)N9LJD4}so&f|654i*g5j^X<
z0tgd$le6_#KqxsRLs)dk3qdTFAvh0016zzf0743nJ^(@@k3Imx5*~d3gcbb5`@mPr
z5NfNu5Ymcd2;2YZ35b4)b)Dha+B&p+1&~^KuTKf}jaZl`*G(w**4@5IuA2tzG8TG*
zul2o%T~RST>k9~8DVM&y#odQn|Nj1CS*ex<Sylr*2b{H}>)E?*e=dLQ{*zg$tB+ac
z;rTl0`R?WN^RV~ueC??HSPg@t=**E;E4Egn7ENM~^Eh}A>(zuF8t4>Da-G&<Btt6i
zYH{<a#&8AtVVzo+c?SAnt2(|?H$08eg&7##h-Buae|BR~NHK`Y7$jq$DscDZvX=bQ
zgjJHly&uHXEbLTo&lGhdZ?@@zH{8*MyxguE9^bADo7)b(ylYG^XS+4rs@JbQE}DQf
z+l94PTkLM*(tX<Sbd6eZp1^Y*uV4Er0~ERN`lqj7^Y55vIeB-b-)`#SN1Q2S#J_&+
znN{*$k~MNzB{?Fz*F@GG=Qt6xguMoL-I^BIP4!$$G_`b%j%SSC?{ZBO%48nTG>W{Q
zZ$=HCti0WQLQ1^{Xua;T1=X3x%*MexgtpV9yN)BPIeKM_w_c|49JQOla!9eT9*MMY
zyvS|!Z|R`Fo6&xEn_Lx(dz#~s8%r(2is<*jE|K4w*VG|$?m}0W&9@uA^@y#x*<Y|U
z6AmXY9BIGJbnS=bGPKXM#DL?Bk>eeFBXkv>w6`%v;jLzp**I#4(5H;F2eB@mxF2oq
z=#!@%9|XVC3(>84Ui?cf-qRL6?<AVTw7pUb#j32sy}79ePJ<6q%tgrK=1v)J_q#o@
z7X0@T;f=kD`;>g-R##hE{#GZ&b$>zHS(~c4vwZ;T8UQS}W;7A^yQh0V99l*DO(`Yx
zYf(gQoKST4_q$D?3g|Y-i5iSS9&x?cB#pgHAFkF*Asat{2#PYaFsjIu(9$Wa-beOZ
zw3Z;^9()T{j&5prM{{&MC$%ZJl==N;<B%#{k&003<&bLcIIK)=>>7QFL#9s+FHWd0
z*_D|(E}_5x-#rEVZQdCCHU9p=Yme}j8SM0yAkWhhB*nLc*OCmMmVgs~Dm4pQjUw~A
zOvB1~ush8<5$<bs(QfQdY}~ERb7cb(Y}_msaC>`Z1&mtS-hQq1u6?8oCx!5+Qf!Lz
zC&6lKj_58+J37=Ra<i5$(yCO!<2fb(R;bs!Sd`VjI|)yVj+PDnnx2vkUApDdtYgK8
z4<CZ>WlclX*^1}Sr+&HU>?>cq){qg99u9AycsnsAScu73g82py7iIk#uh+-9HM(GB
zn=S;O;rN8%GXkGTe4fN-q_T~Lhm-8-^d@Hf%Oq75%crbOUb}@~xEA;Y6jN`%Ss5w9
zbgnOxXwQYdotyh+5U$!jeU{nR;P;v}e+t4?+xyc$*|YIGJLye(4z4*lZw{E2l=XwC
z<&<skW?62-6|F^+0i|N8^_8qloJM(~@?VY2zAO%Qri{BNa?Uy8fhm0|=ZQ0>Xu(g<
z!=I`li(*hTjCx>X8faU|6F7~#|B~Bw5m3a?H)xv`{*l%o{MK^YU*9a%JuKR@@I0&d
zwIE!zs>`p_c7lh7iE_Q|uVb{BThWW+8{!k-lNy$^F-bM;$KRzsck;Q|g?kn<hEVLB
z<TgW7JtY5+Oc_p&qCWWcVLn)lap!Rs=kO++l9+1cbNCSW2UX!z^&<8}cm@rEhjtN;
zHGe$T`R-?8wU<-7&k`|%Z*xXHT)0=}O%!o*1T3t_sei0?tAeQ5EQJk`2zoJ<JXHr@
z;fHvLJ?t!NKD-Nz3~W!pZF!HA;BF6)ZrrE`tvr9>CtC}zg)1fMAPeZtFJ9osO@!yz
zepvg{L$6JerF44eg-Pei(?d^8a^i2rr0>hpLw8TA$KRq!t+<m9kCXJ!j7fF)`^Kc}
zxc}m$Gx$4eQYHRIPkI&iqb4QeZ}6m*xDzlb4S&g`8TcDDaVfn&F$I4ECdS||nYg5k
zF{IGhh}EMD!|zLojG^(jJ{aaVdoj#!q!{McQw;N+6vO<z6vO=O6vO-iiebJ;G0a~^
zG0ab+80IHa4D$^X!~C%n!~9T+Vg3M$VLnGO%pXfJ%nzj)<`1A4=5xRhyZ)w<-qh}$
zTJv+iF72AjovlXU8%wWUX4`<V#CBU`s3*R5K`7A&EoZF8aXEXe@WPm=)o_z+Nszp&
zZmH&oAB?p%ni)sIGUlmV$DflKDpeha_mlQyf!tPzMu*+P*v>>C0_Iw@O>F6OwAK+Z
z)6qDVNfIk3<CH_ZGWLF6LLt+sMSG4If%cU??bEhx^%115jCuvZYl!yCUDEqX<x5rP
zjxo~7gnTMNt--2eum@YHwAU7nhi|`%Xfm~LSs7gshdIolFW3BSW`5E>Sm}3J^@Eo%
zOD5@8>?Hb>C5(2tmHFBjCJL$+#caJFXEo}IA{bq8DQviH_nZ(ZVCSZ`nvW*oyhYut
z&>EXNZOem*)s<`X<GwE2W8qA;KLrtORuE}EyK=sMpo=WcUB~-z%gQLl7(=quADM&H
zG5(~;&sX2*UFlC|alUsx4BxAQh9owVZmq<@?~eX3yji+m=CgX1T2R~n>Fs=fVZdJU
zbct)ovMy}~^a6!+As=^`!s9!1!*Akh?sz(!3-~as`H{vB8V92byVSvk)^z+ap7!wn
zj~cf5%`vuyGNwI8&)1VudraWUoB~To?SMR@&gMCTen2BRSn%}r?FlkPyya=>_MB4t
z%AA<M0eJ-$&Ja?YjdNeQyw=d%i8_mV*7^SuhIceEPGgIF#z{0{l+>WDVsyNAZ;;Ou
z&Nw8dz4OEHM(Jr!ofAHa?C5yv@8%tG8?<ght)>22{sJew(W21uhECXS{Y9hD+(Z@*
zu#FFecbu#ZkB%3+^kTbon!>;HPTZ&?Yywu01gstgtRlwoDlL{V{h~6WwX2xfQuKhS
zcD@3#8g`(?um>$y_*&*4Agk}5mj~^HoYq9Fi!hd&ssEawZd5+(96SgRc|Z&Y#PK~K
z7FLJhRNq%aYW|lAt02l_XO4cj?)66d<+hG~HP%4=HZ?>nAK)AkV?Ay?`cBN?Bf1P1
z84@G%Ln=4Lv<GdfT$QmZqx+t;5=oliXmQvxUX6;%Rj)6ms=@0myT?2(JJPz#$|k6Y
zu<(R>#$mc=ab(?uey@UlFB~y4+PA`qpz5Wz;gE$v6v^ZweXq7?+j7{3dlALnCN5_|
z_SkQQ=U?PkK0-B>Byrs{?nnJP;EPO#);j#&ix&OpU4716=BZ~yCB2{4CM<|%PMX{M
z%QgCpZ~tk|d-U9J!F{|^DI8{6ayi8yv7AYwzthTa=f_ve$K`A;XQsVWzHDiTGpw3u
zk}8j#Klx?D*|T4$T<04uo<e-ii64$l$+opjCAyK@Zt0%<_?9m6=B?W7{npqV_@bHx
z&X4Rg3T#WjR)1(!Yhx}#;;}man{Bq1Bm!uCF5NEhm_p4hkTNavEN8P`%bGEHe{^L0
zoPu}b{St4bELza8AmMlWeiw!~9@WBIGZG<(gg;KuKxVbT_seLrw08>FNo&#W*1YdK
z4(7Twer*ER3)b~WQt!6$Clp)r+B=w}_MtDKe?y{eU$(~B`rN#&U9<Sk%&f~<Nn)|+
zdGW&d$lP5y^gF%hnf1oX_MulTLVhnrs8M*egt1w8R+rIE+?O`Ax-&NYgpoDZl{xr-
zFz3qpM{D^2r668bO5arOcQ4=4TE6eJsWPwwI|rQhTf{Q=SE?WMnu=)0_+ZANJQ2Nl
z4W)@#?(Mx+bwaW7(Sk`w4|LV#ymbeZ(deI(pJp}C2%uxf<mjJ^HJ7WdR=jpTW01+H
zB9YmG$dA~wW>@w;D>H+crq#?+XnW)6Zko+Jgb05N4`geHkQK)Sb(ogYBy)xkbPGOi
zPr^U{Ng~d$@lgsvb*ry1IE#__$oBnH#N8{a)5fdXwU9H+v%=TkDnzAr(9@`=B!7NK
zrPk-+Os(s=`^L8&XoVMg-Rf)Oqg4WTtGA8MR|yQgX7EBEdOw2`$gP1keijdCkANF^
zJjZ>)3CdgjZG45wwx&OJdAItqE+zJ9Q7Yk)78O0UdCk(6rB%h>Zh+UY&hKX1RzGE1
z$|(5MlXaTN&4Il#I|UWaDG|Y=%izhrSz&Wu5jW0NrQAwfgjleIY5S&yP2V_OHRH#H
zY2YEY7JIAjXAn_2p{&@#*7hcs%?H=ewvSHX`p{P08~E>5mRWl@m$Ahf^26%Xia)Ow
zjS)uMyjwA}-1nnoxD?;Ya#|*^*E-GYT8gLid|c#a`Yc&`X5#}?Q!0K~{pZ!0#u#H}
z!pd?ALs;eNs|77+Ioqm4LR%5UCO<9c71&EyD}Cd1!{@dMmL}z&fx{0yaKQR}J9m^R
z#M~CSnSHvZZKL(dUfKqrDHF@(U5V<SUX0$KB4gACdPjg##)h^aV?=QtJb|`lvkWJZ
zn=hL;S`V(Ft!_R*v6rbZ1yslc6*3c=rMpuqD0Z}8a!V1$h2_kQ%?IdRT5CzUZTVYd
zrp4(Bgl%In<FJg6vE5ouzHgfw7Z7K14u|A8g}q`;n@t5eXe>mVV<AFry@K)#8)m+3
z3ahy-tZG(Cypz?e>>de<u`L&V=;Lf_D8@gS-{0%4L1BC89buG94ktsW*w&1ZN=~5I
zchP|MzqOp!aF(C7Y?pS{VN(1`skzJ6IoxyYE0J|7NuU!PGm(BvYnPvKI{HjrmFVis
zKo3niM9;UqKEFYQbQP=%rmM|$7kelOHf3Jgx3O5UXzZQ-n;^!9Ro8(?4ti3{PMxnX
zO*JY^30QZH%N1H$=J$wtKpFjFo}rO_b=7;UrP&VUUcx06?hu~kl)}O`B?}n3j8Y={
zjdJ}j*LT+{yTdX!#%<f#MkA(tPbX!+sM74lvV~Hl2pObh&2$a86Hqg^W@MHYzBBK_
zlX%df=MKRR!01Nyhh_8Sj?gJ|9ir!j-SujudRRN|%&oC;=61R6y*1na-CJ|QQm-ef
zcXS&42Hl17+@a|e6bH|><5z8bJPFG>2s{{rF6?H<tN-q;;pE{_ah3Kc41UYQfX{@b
z)Ki-T(0<VR_rf<B4barBIo2jxi`E#KMSI8?3dVTvJjmZJ2<M2p;Voq6Lwud>(0(k?
zeoCPIl=aYl7{mQEF4@yLM%sP)SgWuX9UZUnv1G}X3RTOdSRn`AIYuF^k$hnk{!~IX
z#kmVl`&iH9ww|hFM>q*Q*<Ssp^0~y1j&#+(f%@WU#S}|`QD}6MSw>;yKE<Fo_u$hV
zw9Rj5n{V>0+@`v6YUP)){VN&cbCs*BN5|W-YuD{4`C+0c+xeEwm%qsnHAjP_UA^nO
zA#sp)&=s30Zg;JhL*Rusr1}fAL))b-P|H>E;clx{*0IBfQoqay*kfjAZd9;w4VXiS
zrg}C@!9H87V5b%<OvjXns=5sN4rf{C#|o44Cg?nd4e1-gZc*!B>tOVPn{j;e1rw`|
zRmJl9-ydT1ixx={N2%OJ?jo;Gqp@0N@=Vq7O4ISVIGKA{$=1E8G*u~;?D784z=kUk
z5vpX5#k1_Eb6Hc}%dBqX$M?68QOntr+hAS4d55juz?xjASkn<RYdXA*WslV06!Q|x
z9)1(2mmdS$o2+fX8Uj3d{SQtW2gOur^g=pQ<yWPa?M<O)99Qaq{ZC|ze~7>Kv1~@~
zeubo}Q@Kqs4$s>J{dxTb606d`HU%+ozb7=-SHHN0N!92VT}E`OE~Eyh1WKF|Y`ddh
za)szGA0xt=GP2J~$My;x+y4yL(6KG+K$HtkACx#X7!I5Hm>%aH>-d%Psc(c9o-MWp
zdeU)I-8vth8H%kL@QBESUrZ+aR?L?aI`NVM9ykg_KQ&k+PZ-IUA`2z6Y7{!lDaBUH
zCB^+LXtM2$-C<<hz0|ib)7!MX5^IS0_F-|RsCegnqc4WSci}i+=!xagc~dMx?|St*
z-u4A>{Q|hw!y{*&2u~r7(askoytig}eL8@-d7A=0F~Ayl0qgB$_ia;Aul%34X$n`i
z)gPFN^P6~BGIb%B+B_$o`Jnv(=7_ZKkgbJ=x}6g=PVfFhz9-fej#}B=^}Ob(39nx7
zx?eGQ)QZ-w`;~o0E$J#F)()PqvK;=iS6piQGHT~+9P6hVxp7GBF4)s<ga=<|3`44^
zEikI<o7G5d=BqNqu4_TpmAPwqp%T=Dn5anWelt8euf6@xq0S+Rxz%CP-er}&dkvxX
z1XvlnS{99)Dj37jGU^q1y?lji@vHIrDUP;ouH0oAhxolI;yyFHA)fg%+Un5-?<BAu
zA>w0wyzCY2AyJFIFPo9vTn1_WW!TxIFJ?B(Ih8?F=S!ijkF!q6_K=LXhZ(`+cZ65$
z1B3oVt+ojxvXy%_yc0dzuCTDWL}D6YCG3bgc)Ve6Xw+lFd=h%6`3_Fgp1gSntJodg
zi2m)caJTD5Ub^%CGe_qOT(cjv_&YXL%^fBI{XX&f%^zo_&OJFdHf2vr$O5`r(AL<n
zL_~0TPCT9O`;;-z=eS={Uhwn#w4N7!^H{+0Z&pxP5}b<i{FktQpm;if=U}6^B+mVS
zsS=pt^W>#FGbSIM?|!`b=8R-t2ox?m0$OLdwX3(Zm3!J~*NwP@Hk5Y`0J?i<^R*et
z%gR}U20njznZB*b{qS6Pyv_G6g^_8Xy?eZIMe_H11Ap*x@|xHav7U;zJLw3@CqH!D
zeMe4pK7;HrM`n++W`=4lr#f?u@Sg2xBH-Bzc16%~Y6C9mo2}fxVN*1<0ZV>F7am`e
zc6~+ifE_Fy$M8Cd>RmJ{9M8}(T4%%#A`Igv^$e66Ii?+>a^_yVy_^7@ilJlIvz0kw
zfsxkKg@GGJptVR!r<->?C-P3++tU4N7k1V5juNfuIq|cazt{`(L4xk>hmzL+^xpap
z>%;wf@cN;9+xcZ`&Jkf9?STpH$+I>0w(u}aa({uEAC}+SlIAWCorqln9(wkIR}xYV
zlC&^HnaPpLG}27pNPWc;VbRhzHjz-LDPe$$oyw_LV<_xiW8qQe8-Kzcnh*Wl2>pC9
ztV+x8tDiH5KGjs}QF%8Kyj0Vnu(SB9uA&l7wg;=LsH|k;5cf6{@uO2IMu;C}^+GjM
zrFMMtd#ubf5?xTLRczcKm1*h-6^&aNm$g5OHR9gXe^b%YZsJ>-je7@puSV$|DDltx
zln{EWiFb}ou_)g0rOjxIUe%!RJ}tGZsRs51O+>fhG|_G0iLRI@nFgHWzvrz*%hJ72
zQUy_G#xqB?8Uvyi;ah&;tB;dJ)2SNbxzM?nmJSmYiR-0va&K%FwZ-FX5;Y>NkN_9T
zKQhhVNlbI=AO$zC@mzR&52cpv<NhQ}j7>ZlFUPUQ1gdH&ObW3ZTIUB|XpetLp~<zp
z5GPc6YY}x)MR%>gm6}eQ3EQxZtd7n!=vB8Ax?&|Tem$4=;O$b{5?wvyQ(`(^)Ry=2
z6Ozf!y-sZ}+Vce>JuN_=x0z1Y5GGMfTGzC02mLP0gP+{#ON2eW4gEW8=QKh!WK|vu
z4Aw+D_!h;%0>!(fIqs{acNPHp-?q>l&GYxM$yukJE2AaeF0xL$UOv|Ofs^tYjYp=@
zy)s2hvA!Y(@50-g*!mg?rl4$8Quw8I;dYaPZ7`$HheZc}OEIMYJ<gyw&J;ynxA7(@
zQ2ws3&oEt$3-hi^=MZ$HzIrD)`DocwN4FpSWyoJ`pe^DY68)oa*F;aua#)%aN#el*
z&xyBNWm?n_6R0o3Q*&idrAfE(64BXj5~2MxaPeGtVg0>W=<G^z?k*lL<QtNm@SG=z
zp(#$qUI*8rt}EAdC0*Czkgn%lSFY<ya0M4*N0c5KeO*2Qpj@rOog1N1Q9;ms5C`*j
ztY`1u2o3J~9r_RaF7%lNC=L5<g4P?QpXDNY`z_-BLkT<=WGnlF_J1bC`K`+lR`CJ8
zE8M)33r;+LEcH{m(q+c4OtP<l9%kLSJ!lDV((HU8=r6eT{*My-TezR|_u?R2wY|RG
zZvQiWXGd=5inJ|3B=lSAP5hK+UCw82@bxwSwW6}pC_w9`s~y!{piSPv+4O~{kHT(x
z=j)ut&)M*rJDJexuS&W@6IMy{9oRlao9b5Q!Hw8GTWLvc3$IT33K1pOj<1$~2a(zT
z0&iYBZjpb7lf={TPP%qHi~e4hQ~5dd6ZVMPdr0l|3lzWmaa!thstw3<j7H4RSeZGW
z5@a#jWeq&mrGvf`Xz)~g_>Zo=VqZbQjii}{Ox`>(bu_DxoP{M-qvfKN`Xz|4xbWc`
zLCuXQTns<zC@mMoc`oGTm=X$=$QYtT#t@~+_=(c@^rDYb+hQRD5Kon!zZek+zg)61
zNBA2boIWeMt6l#rVG#Eih3vWTtSI<#kKG6-QG*w^<_T;05bR{&kHHx134|Qn*tDwl
z@9*>O!lsV&SyAwUkmCd4n~(m`e#qI8D8AI2O;7XuT=35rP-ik)m0C@H0KDH7f{h;{
zX*MU`?ilPW<9EX!nUAKuw(-Fs@P<d;v4|+P&WA=cmySliM2<)aXS9e!q2+0-;6X&K
z!Q&k^+<0L0GJG=L^oeiIOb`uc^7I?)p<5A!u;LaGRl=If{plU|A8vK%RTa@DXMaL1
zVA%Vi_877S*-2vg8PbW-%C*!cf?gB~y)}NOguyB{L4y@50xRvkxtr|p1F$f#b-)jx
z4C{1v)~db7X|8|+I5iS3l=PkKWRf1#66-n*db;4{*o2l^Wd6Vk`wh8>+$cfJNm0w!
zv}14B4*PNYOp)`WxuF8Dz_Qp5zHc{$#<wHB?ZWX~_p9&z)bm8z0FFf_uR+pypLpT2
z`w{MfmU~g@Iq|nfcYp4}*u4@5Mcw6(6OUhVE4cI5%j8nexRHse;eg|*C3Fn6n!*6j
ziO#RxEO%+>0VZMLfdlb<%4R38fW%wU<wIbH6$JV7zS<PG&IQR*AjjJFwC%`c!q07r
zE3Bqbw|Au)m2$}BMn8?^RCfEGhtue7(KrrP!;#s0tP^vDoLgjbRjv_NMRzS}_M9j`
z&3)~AZx#oc-VoT>eecF_64kogW@&l5eT@xi=Md$G9@=i+Z1J4<>hr;M>EUFQ6mg=&
zS<GT7eq&U6zA`F3fAAQbQTA;m!XO%BlR`jWCFn=yi6_N$WM0F)0Nm@3d-OV}5tNa2
z0-}ZmPx8SDJ&HO1k08ln6#i-dIJyI}llr`_eeRJV)mZcXA+PW9nd!YPaCMLoJLDGl
zL*5o>_LJtWRvK$*EB-s~*NP0sSpylcO&$$bwR}&kHpc<CZM0UHC~HLC^~RJ?k1PmI
zL_Rkn3qo@bp7+gPaDOdC%0&_nU6STdNT9h$&d7dP8?u;lYs4B@JUG~7ILu3G?cjW8
zl+fHv;5*Y&h85JyAG;7If~<we$01{$RtB2cgWzGM^^4p`Pg3lXm(}0*a*6uE6Btu*
zFId7_3GJ`0sOjT^i?TP?RR>mx3wZ^!W%})Do2jH1X+F)O1)H(8v$cz!X&+H)>vS!<
zL7(;M0n-pQ{J^|QEaU?V`2fpU&s-^m)l@!E{psiVWhmEoN0-r@8<cKrqA%U_OTv-8
z#nA-WSV-kAc#&v&n-T|erUVVVG$W8FV*=+J)z`&W+i6rEjp-YijXsz~qtv4(Tef7z
z%d{xnB0Lwx3H-ZCQ;8pOoVF7&2PfVSl!L#VT_{Xk2T3I=-R~5($ryxghWzO0wxf9S
zZFJ%Hp6A31x4W<!*7EN4GMSUeAokEe#MGz|M-v8n-8kf_le1va+*22kpH3HC)1eF5
z)<Gj&CuWVKp2K%wC+WaGxdVH5k<yyVLK=bOjXaX$kY=8z5lH*YrrIpEZGJt@U0r;!
z-F8cbyj>&LjLzPl&HkMyw%-|;!dlyM?%H^MR)CO2Pqxgr;dz&Jk@{vwUHE;eHRXy8
z`vdzT$iJ*bgRkf8v%eE(o8Jn*j&ZQfOvzbb=`J78E3}afH{aH#q!8_jI-X{(xkA8C
z53ox1urWeA+KLE09koPeUQ*MzrkUdXBAXu6<~+&I8g@F#&pN(c7c!h$P$k<7w3zFq
z*0eGS%OfqF`nSF%JO4Gdoc`AT;al>_=bZfg+a{9x)d0ENwA)g-+|z;OvUQt!Wo8|N
zP218ZJ2xJ2URGh?Mun}}#Rq{-@HteE+{lhl5qJS)O@ZCB+g2Ki(K0y)B8o}{nuH;G
zYMhjtkYi%u4VcR5fA1s()e~tC?qIwndkC<P#JI!S1JBJno{GFiLpk)v+xx{>Q8ygt
zbYZYZlKg?#>)tN4K!<EIg_+xiUe^9;EODzg-jcY?33%W#wpQk{f09__Fyok1WJ4?_
zG363Yv<z^foG57zz~~|(uW<fzTjIVaZ?=Jc=lYa;^Ip=Nmo)b!&3h@Id}j>OE(;>N
z%%iObvtzRbmK$jM!+7NXtGT^-u{90r67Oia4X>-QM96dv>9c643a71VZPqd(tad%d
zE$XAfb;tmEHM<`BWO1%kK5&tc<9bX(%OZ-lY>1T;EM>~Ui-c^~V}lprezxlolk*Yu
z&<{O`L=PtR=)o~@PS(6Ge%JuNd&&=|zz>%|%@0o`7Y##>P;q)Daz?=8iu%jm*7tgn
zIcyGt-@!?7RD{DaJO-Ld8yl{?v(K)}D8UK!(kA!1mpg^^y#v5IZMM_DljfK{sDx>-
z>lc>5qYWBVEpVy@POdJT?rKxE+mlFc!kIjcQLz1s1RD3-d(MM4%!9+22WK%4t|F3@
zo}AzB+&m5Z1Y6=yIIsPQbp}C_@aTOwpiWeWa5HkN__{nweeD3mW#rDxsuCwZ4QuwD
z(j4ent-!q1ZRRikGM;Dh=D<oU)6P@jIk3IlcKR*MeYchWCXi-UoqlDn?esJ<%xG(|
z_zQi%BW$R-EoeL;Q|wI&V{`if&GZ<QO5O_(-rL^$F73I!w6-{X>0XW0%Iv+ie?0*o
z$G6D)z5d!u9uM(=?>!mXM?bqKPJe%|cUDqA>8xY)?CJUQ83A5SoRU+OEhxGEloPdn
zHMec2pFqs9i$81M6sK8a<Hjj;BW|{BUhL&gK`a}To2IRQl(C7+6xwAX;snZ6TGgKv
z!W!2=Zjn|sP9cb{fuDe%#}dlVqZZL8;KNMUpa{yV3T?roM5B`GT3reuuj~=<?8dTz
z^gg}2F3}DemD-zD@t^BPY-<}(q^*B~47Cp9`f}bUi?0ugc`oMtL|8=OyAAIgrSf)h
zp<Yu6T^||DIb@kYzP8C>bUa0+v&mgh*kMX|6j9r~5VidTqP8dboB%z9<H&9GR&qqG
zWB#Sy%6tos>y}ww4{0j9bi;v5*r~Q2yp}NOF0WDg%DgrQyjB-+m)9_N%x!KH|IIIB
zcqVTiX4?X3o_Z>twjU^8mpH1-nmDYCjzv$Zm6TJewePjH9APkyzgY(=-E3<;Aamzt
zkI4W!7(j=FE;`WNP?tPImJ4JYlvjs)rNQyMVP$Aj;tjdYC40L^rhC*%$|(E;d#MiT
zjUJ$RXsAc4E(D+9_=MquRbUUz`f$y2po~|L^kP1W`p~2YsG?|IIoq2p{)qkge`LMX
zYdQP%t>*pnZmXxeTitI4ynVFIDrIFxw+-;ux9jh?+peX%T^ZYFKl-0y`{4(7TZKi*
zO9P6nzqBg=wvf5^qrxt8r1k!^g$3o>(>w0A3r`EV-7s;Y71p9+ifa-ye)%+t>Y?2>
zJGydHUu4}De750JjL!}g*(Z(`_W-L8x6pQPV9azG5r}Q4V<y3SzgySiFf0DwwfgMl
zyRGK?wtD=%|4pkN``uRI72S>N>l=Hv>dONUrt0zazeLri*Y%|8uWvIi_m|rA<n(Nl
z(p26j(|rR87;VL9Wn0Ia!V^j1k?uZ)B+=*~Itr!clhC)cVj>y!3@ueEhKXNy`j+fD
zRo-FBQ6+Hh7<)_!xTb;Z~(krTHVzhIp}I|nBJyteG;B3sdSStG4`V4u4$XPRNp
z?HJGd!KRv<kZH&?-U#QTOeq?ozjcNP0~-iCFM`CX_7qa<7;M+Kzl<IW`(TqI*(iuj
z$^k~`;|dCYW>*$Jiv35%FDrE0hBNox7k}aYXTNYCBL=HPX_k#Qkayx%$F6}-M`Mrp
zFm+X+s&|#I4a1JJJ>>B`fgCO?n~{A#nvw4qk8g_e<E9kg1iFXKqpSSUpOybqE}!XJ
zUb6gx3V)SP5RHci#c@aE@2<K*aitc<Alzw^pvrffT!Z4W`Th3Q)s%0jHDP6PcZ3;*
zt^2T~M!N3wUdw9aGfm2`)Y43!B9B1T>NuxwUeYdHp4lir=PTtN$iEhsZ;I0n9E*60
zmB~{!e%7O2Qq|0^+{pAa;+geb^$+x@|KD<b>LEO3<7}yZzr<Bi1~D&QI6+t|*EN2E
zy8qd%kbi~$b5mSywfwzlpD!LC(U^^&(cz=TqvO903S3-jkF?uyuC6O8{#d$}-r6Hy
z_wAvr!EUhUE@eQMAlyR^o;^e2<oGrBr#vDLqM0Fa)MH4t+))0JG2wTwjtk^yj6|?n
zKun=_S+l=fN{->PAu2JXMqdWo{OU47>Ao_^G5#kaVeo$OKOABc`2<mK!qP*^ZmudR
zeJAcEUR_P^yc3t15X1NH`Yt96>-xSa?jwGKH2yO7nF+DjwUS9I2c&r;M~xh;G6P`W
z84LSPD0bCVs`|Xo@?fROThARV5SnmuZ!{2OyCH1CGDOm)5#KVELBi!Sc<hgq^6q)<
zeN;C2tRm)-);(6_by_Y=<B%P|Ol`{8^?nRH>^73hA+jzvITw+2xk<=iB&^ar5TdTA
z)yJz(l5607cY&tkd&zF#^=Y4XSk*uVMP~0Z=O%_Gu1hLLp7a`OF%8aNATVQDAuyC>
zLu=ZF-*ETjr!qi}go({%rr|a1ZZ5ffB~Ejali}eZdCb$y()0{q<}o?HG|mAKi({JR
zge!VIF(oz<c3Lw*4EJL~0CM}lUQO-Rwjd32v6l(?(y8^@(X<>p%PJN1huWe^Uh8NY
zk1X0De1kn@t#H%Tn`%I^y?P944=1U76*nVqiz*RWKFU;mPuQ{=ei*t|=zUsQruy+|
zTUJ=0@aSnj;WXVzDd8X1AGt8bC{R-&*Gxp+<UAUED>PnJIs9hD2v-iP4{nfF>k9w+
z7^mRxr{r>JtkAk0Lbacgb;TnVZ!W_+-^4EMWyTkS$^`d~%Xc0GNw|Dfu{1d|UQoiX
z8EsNK4D^<i^>e#3fKe*X0974+^JCn%58s-XC6>RGd|mQmrE`Euh`B2}y7`Ibqou17
z#x<Mz>VvD0M<(V9^_88hpMBJX`DL0qfUr{y;MHZsWC#V{CWC*|2pcyRr_!lv*}lGo
zqduvzD*BEHN*$V`n_6RZA@s~aL@Nbo#fes$(aLtTg3(QA1oyLsy;3{WN`G%Fb$Rbp
zd|BbU`gm<!*Hffu=eyc)shLS!SH${2f^D@2B+wi>`d)hCj@;pRLqikAcLrwX7R=E^
zyw9T0#cAl93I<Ftw7(=p>~?E%GPlwUZ<JfT@g2y43M)G7ir~@$VoKUhOw;y)TgjUP
zDluMW_~91q{KfG)30TP3Gu}N7*^DWN)XrsW1FTGJFShngoQb@Qtng|0EMvC#U4$fY
zG$u3kkR>MzKFiy+;Y{9S<2t4A=N975(9nq2ir3dtXo=-E?wUgS{cfPsrW`=r>opyF
zkqP<0-5E{sS2fVyU{1p?YIM%NY)^2}??-)4?LJ(RP^VPV8E&TU#0b8or;$76b|De|
z#dW;WZ8LV#*<Xw`rE%=Mth3_MGq3}-yN&bP9hzhYJNKd`*G(=Bp|&xiTp)_>Fv)u8
zYpJCi>#pZJ+UM4n!7lQ?jVH?4%`9rUwJkqY;^e|t_ldMp9U1Ffg?~mVEQWMF>+?*v
zzC<M#UC*eW0zDx>Hir<wz)4yeJdUwet@o}ZK4qeG-ZFtcWhTILO!ga-&t_HU!_H=q
zQY)p>#O#APFFk`yYbhKl*g^daSB}Ro1E-pkMSrb>e=%qSPqB{<nOr`y*|`n89*cFL
zK5q-&9HAMv^fMFAU)_IeYoind1#)M!3g%wmm?s$O?E-&@l#_F*@0fgYI*iWnl+1Xy
z!mmRY9LZcSHyI6BZIa<rvJ9(DTGwh5BE1WMa)<C%3-PY;%O-l)YsSFTo|!+Sik`ws
zElfoVacE(x)B@g)5X8`TBrJwp<(bJ-g}?lCx0Os|eRqy@1LHzF@D8LqlJ2phdB^E!
zjmwtCYxm=gb1dEwi}4w;5IIM*w6>7|)iE1i(@|=kJvOw`I~TmOfbu@&`_C{((W~FL
zC_uT6kNC|w1=Z-meO6Ps>`+>kjN)W2kvN2_FJ}x+Y3=d8*MNF@kU^uf$7Su4Vzm<g
zZDA$O9C<&io0!)|%<F``k|gOKKg#{*;6E~U;$$b4$R=YVMj{34{tAr5lDi|(h4Cvb
zijVN-krjyRz-sK0*D&->TD^RGH`J&Vm5lIm3(<--lHBN?F?7BNS$>FascEMXsOU%8
zgXsRZquq30a-W@rtW!|R<2)@H8W`8O3*IEVA3t20g|pI*pn24`T>Jr*h&v|-Ix)jL
z))@uTqLfRE|M2X7!R1?a(cfv=$zvx}!rIpnXoPQp_3~ZqVv0ydfTb&naR6vKmate&
zAeDJKK4<bmxca=hJeomVE=liZ8oPhfRjWIu0_W=q?a9cX5KLY{%q`oj#0rqqo+5mz
zR8YCZA)hgmK)(s%ct%KXBk=qTj$T}9c0WG0owhxvYo8<Y;mQTgWlT~dDC(<gjkMZ9
z8N8q2uchWa*5(n2upq~<Un><EL<X<Z%bexSzTf>z_WtT#Gh`j7OT&Q<MfJCez{u=j
z-(%g!8U8he-a3X60$Wrz%{7H^c{nq9ho}_#AQKm!yK}~OI(ijGKM!dtN%q}e9gECy
zs0yOPuydRT|ASu2p<^Pm&zgmJ<W5=qL_5_G=G@1ti24-EEtDUQ%o$MW&=f?|Xt#Od
zu<_{AQCvsRc0MRSpY_?q$n3Q8q#S42s|yU!Z@WFRaHb>fGJAHvT@sl^DJ(}pdTk!}
zEBVznx#SE<dU#99a(2$CZYevnA@$QmhhI6AK_YWTQjH`B*|6R&&DJ#Hw76<H+q{5E
zMw}6MdDVJ-N={CXok8WJ<kdUP&kxaWM!chIy0-T<g+$R4-zf#QRCATCY1H#7xF{hq
zSBT+MLVT$jw!%B^7wqlr{b`nccn@^C-y7fAKEyr9-noB`yXLz)v|bIZckRQ@QgPT(
zoPFGJ@EeJ{Vfk%p8TITgFQw94?0s+pZ9|t~VMOJMGH|A{S#f=SX|}t6^UeAN)-tT4
zciiXfH*i*6Vkeu|9NwVIP?D$0t}hr`W{Rx2!`)q@WnE+5Vfe<-71}y38`;fX16MZ+
z3-LC|`8`iQ<qWX&#D*~*U4SfqN-CocVnq_zD+(d^rUGwC!kiFhA_Gg!HU(xgJR#%~
z?!YS@2eYr2ubeL+o6FMqZf#>*{d_~&_4!N7Wu5aXaZe3zZLlnr=7;2ermE>+64pI4
zxDi^vbQVcxw|hD#eV>s`e|hJUB;BR*G-o_FzR%aRjxZH_H)M^;OrTODV!U_uNbMxa
z?a<jTw<XUdugs>}3)NgkA}0Y|li?5k9OnPgpKHbjibuj(a4Gs94!Qn2j$A1(78&|3
zs^I7_$b$q9tF>o$UYjJ#+G(b!Bys!brRS)mb-!n9pMzLFjIeD<v!Sd1@@@=~LYC&v
z=J~=mO-g7{$mWtix74huqdoEUW~7pe*-?sCmyDq@$xX&~O87hm=*e<Veal~&yHfJo
zkfC^W^iuO^_#ILS?eUaaZGOmuGi#@U+W}2)_gA?NWkIy4q}KYuN2$&yOrO9YgD~F8
z0*Ssl2~kQfwR48RB41xSuP)t9TQW%1a97jX{rVM|BC@ts_;151*$8AuHfJVA77B|(
z8Lmjw2pz*22Ui$Pv3U9l$I<w&(hcr63p<=CbTqtg!J*?|LhXC+b;G8du4<U`sTV#p
z(%sK~?TZ0&+_s0-m73vSu=~TWC@xx1Au}<oP(WVk%%X#4;L{$?-o@vFjE}>zjR>!|
zD%=5v&M=(K(a}79OH)V3SJV{S51QRg;qC1`@TG6<@#5TA=1i%_yp-R!Lk4-dunSW}
z+kyjk=QU6*hk6+`P;R@H_hYH~DJR7e)LIhC6c!0qjq;$meX!8cjiaZYW;CKF?ZtNY
z8?7CPmR30D>w??h3wSR#Q+#MNH8Mv_&z)s%f4@6a|2R{Qh-c((fM$RvU;D@qN>i-w
z2D-k7>Lts;ZqE^!szLBi)2eDm(fJ2_n*xuTu!EnOHCs<1%bJIF>;OXHV#Z2iC*P%a
zytAA7qsls;w5|or8eVD%l;(i<Z6NY`-Zkd}0$#@~jOP?97mO-GCc@Y7YX(Q?DwHI?
ze|Ob(R~XyBzfo*SlXNvY+q*3h3uvU@o$rmp^|Id7ZxGoApVUQeyAx?0+IWBMO18iV
zS6bDyryp(-p6B3?OnZqPp3hsFq@F%uZfBCVC)pFR@>?SwrMsZBltKa5rm=JvG?iBh
z7fY3X+)U)1Ifj@6=!#_JBNKBl3cO!ia!Oj64L)X6x=Qt~J$r_$q%|kzB$so3?r6V`
zi8-&9%}9wUdnsja`9$mXayBBqJ-5q-6lsBe#IObq8u@r=mElY(N6%HMHcoe{TJ8<_
z<iU=VV8M<WS(&DmL6a&W7ge!p>cbww(f172tvy)48HCn-uqIIpnl}rU$>2h*)2P(~
zJ*<gb<WLL#ACATW%ohG!?zoNaZ=82bMqa@hf&jya(s&O_+;|0>5RO>7<v7V_jf=6D
zsmr4f^^J=GAq2J;<cr9a_742W0(cMZEs^q6n2gx-&#Z?Y%^@0Z0HW}k0lSfyW{yQP
zUZ?^(b>CDzmX+SgwwUfYnwTxvp`VuaAVE^3>wY`@nPXKd{aPmxesFQZciWZv)wR)6
z-Vqk>P_ozouyM&~aT!`pgGL$4>d_KygSHgJOe_%6I5wus3Y(iZQq*U;qJI>}6+psB
zr%SRuZ>f|~rYC2UfIZf6*7d4>D!h;Bnb}vQJ>4N{Z>xb#>6G-wN7JF3gst5MZT=F8
zRabEr`HP?j&m4s%YB2$AFdiYiUNa%4p9VXEwTJD8H);`YW~<M_yWcE~_H%sT`)T_k
zi_!k)PyUrAn!BxX6^%NKmGXPgUQ}_mTetk_d+N5p&k}xJXlYZ;sT%LP>H7vKua`L0
zTE|)UPEG{g@e20PTv)NZc)y7(uN3c>5efM)y#McF{pE?DW8HKA2zvu8sjLC>;LsRY
zLWVQ3psG9vLik-)2Vyvi3$&tDF)mxH$x=X`Z$J*T5xO0)Hr-<pjpZ+LXL9Rd5j~eX
zC#$$XFGesZzfPNMCAQ>jV*9O?(f&4@(FWl<PlLD2Wiz&UemDVc_NU`OX&)<Di>f&7
zpKkfnQAo@Sfu(DUYBqNBx^1v>ZK3&bYv2(Jj;Mvru(rQUT~HQ1fEGVofgW&GD*6t;
zWY{L@e4A6ag+C*`d2r!cid8Y?$JN^Tz-yircmN;da?z$}VD*XRwJTcvu}jkEuY@zY
z;s|)T%5d1)F*KG{QKh0;zhp^=h)ZN}0aqdNlHyxwf|s$1W{OG91I#>FeWkM=uY~3x
z&*hca`=&qHCYxHbsEYb#kIoqfA1=t*KBYNA64#flLtkB|Fbi%%Uk3N^h##fVqVPA~
z!Y>ddf9#^SA&r&54YUA`CMRgXUj+29LTUqvT(cmH?xB$t_;H6OG$#3|a0K4M4;a1k
z1vb@0jQjO>bw&HhM=JWBA!br(&Qo8r@Uyd>wi3L<j_qGf`)O+c_3WVH84bf0`w{9b
zPT&2xFmH>-HZL2}VLUUamX5V{9zHF%km<?~-i?0bGfL|}w^3UA>8~0Y-IfG~t`zr1
zX@pE)FXgB@mUFbsgk2{~#~eIhss#@?F|#o4bX+9*z&d@g_eIX}-KV5J*YRC%$b&j?
zq~p8q@b1aW1zhioS<nm%!o<pdFSWXda6dd~bT8Va@x|EEF}~mUZaR?)n-X>=%w?;m
zsPlrmUUT(*y1v|vr=+<Diy|gmF~ujsVv&M%W(9moVYyJkMzv-OU%%$u8pID=w<}@W
zP@n|Xf)!W;mQaZ;S+PP?3)fZ}@Scs)+}BQ=9^NFFfq}ZnRw7&5<P-3e<fC~1TDzn-
z-|L4Aof+2Cad=zd=JA7jXbkI<<aaE9J1%_nK5HDznBq0SaRP9R=)$ocSoY)a*1Zjf
zH;4)HUcYe6jCR}kY`g^=pU?duQLV_-j=4NPhuAtg{I&mu&qmDedT_?y=p3VSJ%`ag
zp2Jl2)u!L@xBc{!KjoR&zEl!R^Y3@P5dYnPs4YihGorRA7tz%UHnPi?8Su(mw;`1m
z5!=~pc@@=A*{@xY&74^q(#wJLW{y|pAy@e#M&hQTG2p1V%!V3WaXd4s%iiF9W1sg8
z7RVTsh?Arw$iJjehMhK+SvU6n6oOuIp*&AGwNpVY$5np+r@iZsi?T}h=bho5cOXS`
zLa-n1lna)h{KX`0ZW>TCfQ6Mfl5IufVMJPfC^MsIx*rq<giWYs5p*}R+O*ueZR>=X
zdkvugbvOI9h_&UGBdBePnILL1_xrqaMo`=Cr+Yu2d;ekd;d!6)KJWSc<2lcH&N-wb
zCav);crr`Rh3>CjWs%jIH9oenekJy8_DkHP%O<HC^C*<Vd(iTZ+WUPnCswB+%cx~h
zHLgP5i`mkqhAo%_!=4`dp(?J`eY0Wl2CRm=Q)0K4Ja*AgdOd6rG4t4z@s_!P)_rmZ
zNTh)th9o*#Vc%A<y#(cN8dn~ey<IJjc@Q>P>d;=HhPSX+{=1u-)v!zNz{!}+Y^WOg
zEcd9`n~!_2<H=J~f_|?g&@PHd?)s4WzB6Zrq1Op%u6p#H$;uexzn~{4nHDqjQQcU5
zEV;ND)=d;j$6c7y;;Z8g7t?(q-F@TAUl|a4lBcJYZ!ae~e_!eNsmQZ0`Sqcf>G*^4
z@=R!{yEgsgwSjp`?*^7YKohTO;VaZ$w*0j_|NTss^5PN9U#KknuToy%j0P$P<O5EC
z3XPLIx;sUV;Jyw2))MnY8cz&Yj3;Uzhw%iKn-_y)3e6r2?iP$?F%sD!V#nB~jOSlz
zpuE{%8VL29X<JLCf1`~q!7KrmigMScyMMcWK#fvMRb8KaXojTLrT+N>#eEiZ<Wytt
zem+8t_g42R%TV3o4KeP?I>h%3<y8L{R6dux1amI1YDjB_G&*5cQxR7&G%iqkuaxJ>
zYAq1z1E=_7vL2;+Q#W=*q5M>-z9`(CqRu7Z664;7@#u-6t_a`R*ZPY0mSB`4S?^7C
zZS`<yqT)S%oY6fm=(}M7zHhzZnwf0#dc#wH#Ys=UW|C#UI+uF?==5{w4JA)W3iSEs
z*dv&KBi)<sE~VKgJvEelx*i-FNDe5u7weZ<pG9BLF9ij3=&A;NQ`f1W{#?4GB?<16
zyk)=&*o5*s?;53^2oTh;1ycBg89I)>9~xQrRhx9t2{it!vcQ(>9|L>vptbj`LvueZ
zZJGVqBL~Umd%;Ifevr2xw@#?JUwl7g@cXPxd%vA&Q(d^J{1k3E8rt~%7S+!^s(I{m
zstqlH>cac)KsHs^zOL5y%kn2xIN$3AGviCojwpWbUW}%5FseEsQDkZk4{cJsCoVGY
zi4*K4o%h7&m`A^PArJQ-!QWF4`~mjBBeeSlNFW%E=Z7UKrYFB*bj$clcsdUo%?i!q
z8}c^rrkRmmB}L*rXTlS&IXuMl%il_-+&@US3^C=bm12I!mzNLqD)&n!WuC-y&W<>V
z^Q{jDLi+n`JfTf)%KzHX4vF#rMwJ>!6_DOMpN6T@o98@96fcE&ze<<tBl}KZ|JLVY
zjOQ+mnWzgmhjE@X=5|Q1t?wc~{*IkdXCV6?k$#k9H{l%1u7e)%{3>(w%u$<)qhTSb
zd-nozgq_OpjWYX-$G>~QcWCI>C(GB?&3t-%gJ>P7^^iQG<Rj<@E_m87eo_kPb`#7{
za5{!64>uMY4kB%kiVX+CFs6-!WK7Z)t^Ee1<GqzMJGlk()Q7OPPV&Gfv<9phbIWn|
z-e0=sUG$O^60~8&I^C)Fd&ZTg9H*Kv@nv<ELM7Z1DB*y-NGr4kT?G5Qa)eGjDfraH
zUC5(=v`tblR_FtB86j=A{8R%eMaJ5Kytj&CgW7>rEsCWT67tS~{PY9z@n^fK1z;=^
zc6^94*`K77{Z7&vSi;D%F;?DML)IcsUv8tK@+hTb$r3MtFQh^qEl;SPQ9WE(D@p1K
z1L;sFpjSW+eDT7+pq15a#lB0dy2O!A#xjcX<AK9dsF&<R-6-<3w);a@j{#*+I{m!!
zXvnqlD)S$cSEk{lLiv)sk8%pggKCKkkoft!NSs}Y)(Iax={?f68h6>vvahN8yTJUB
zW&k3UNtDX5%YSoEjr!EOOtmM{SFh$xvffiBhq!ec6+>+dn^7zDN=sKIN5LK^UYb!e
z#uzC*tN2Fs_VIgkIKN95vQeqfy}eEvz@ZSw`kp@io{V!AaSpX{8*F3f`-|znYvlLo
z;7X@f$LhAJIlMBx_MPB4-ELhV%#M8DY~A@2kZ5RUm|8lB?U*gCc@*n0FV+X}AGYK?
z-;BL5s-~+mXO*P}nlOZzbM2-zYK-ZA?P=B5HAW@672i@ibv~dANR!zYSw$L_<`!6%
z1TC<v5wyUvR?q^=A%YfImIW=atP`}rvLa}KWxb#UmO}+CupB06f#quiEwDU9&;rXt
z1ud`~E@*+}VS*Nz$)_m&9}Ao&30mMZji3ci(+XPPv=BiHoF)re;540}1x`~0EpVD%
z&;qB03R>W_FhL8Pc8#C~P8%X<fzyTxTHv&BK?|HVOwa<4og_0#|JX?p0!IrxMPReQ
zR)OsTy99O%TrKb`0@n%LEO48^9Rha?EK4GMfujYUBCuIttH5@FT>`rWt`_(ef$Icr
z7Pw8|4uQK>tcdiN39L+()p(T&ti%dhV8tY8ft5Q1EwD00&;l!Qf)-f8!S<BiGJ%z!
z30h#~PC*N-OcS)g%FhKYuyU861y-gDT3}^{paoX$7PP?BOH&_RoHSRjO)k}MUt>5h
zl?|;hJY2{oAO1GxiQ(=nL-EudJk)+8pZ)R(L+RMvJghm2r)&;4lq$RVkmiy6zRgh>
zFLv+|-MVL2yDQe7Txq4=mik(EmZub7hqp!Xk2dQ(^!2c|>v-d4jfcKwc;3Bvr24g?
zTl4MM_#Jc-)82YdY2+R*w?*L#!Z`I`*~5o+>&KP7UK$uXTDI3rp+3(1mIdn^UC%AE
zE`~n(!6&$`EsTFo{!e{_U(+@Me!sz$ZavQ7wE3>>ru|8M?j+xhJ?DMb>(Arcq6W;K
zu*zp1^3H2GEpk#U)-u5zAM3lmyB9Hvr5MQ#IMaF$*Eb{8h>^ZoM=|n^>h5t@lz)m{
z@oKzpt2by71KF<eJ^J!_<l7ruXAh$oAmm=k8(*>RB>a4X{QPE@h|9>H)4uEUrztL7
zXDKdvi~}oo;WR2WZ0oLa`m$8_6;7&B!%3|JU8$p+<W!$h0vv8~F{&;Jb#D6RX<a9U
zVR7@}dR<r11D!$N-F0gN?~fo9)z7yAF2y=>QT>>*OZB5dcUbr_O3%8Ah8-q9h9HKM
zcXbuLf1IfI8oG)ms!zD}6*Z|CH3>U<w3avc5PKNLE!Flnt`ap!XVB|*b6LKIKlo}0
zp7(IAe2qaL6TrHd-5lG^`b)WUeV~*(HWWbaeBsP8YtX*OppV;udoDvEMeM+x8s9mF
zCm|j0)vqn4GBEUFf84=B#zX8n{`kubZZ_0m$X9VFi{|r=;Zu=DD|Y;$yiuA49m+eR
zxfi}5&vCB&@Fcv)e)!=E@Zx%4`2G;^Sl~Lm9}D+t;HgB{yDh$v2haF^qd!yN-idOY
z_&M%tZ-DC!2T%Lf>rV$<{{+`n@M9{%i0-$gg_TGIECpdHk`#><hkh%dsY>_<2BrNZ
zfBL9qs&aawK^c23|J_j?)&gL)V}+i|1$~uW0|^kist<7|a4Gww3imI+A6N}34q8rG
zT$fo+k-d(b#9e2h@p41gR1J%sI_RBVkuLYioCF)$r_P?AXEirGW_8uut#%=W;Oj+O
zG+WC;lMFJ`&>4mac#6k;sAn&J|NWW?Fua*?Lrx>*aW7_9}?G3F^qcQol#p<jLp
z7K;5=s(f_&NTd<5vP#8f7h+~d%n~p0(Y>tmto%af@N$bmkMKj=StFhh{+Ui@&=+Ce
zR0c~_oVozxA#KYR>9DRzey{Qt+@SqorP;!B4h-i{w&Rw|B<Rtx?$f*!`fRNBs9bx&
z_hBVJsT;=srVGc3+wcW<OzgobRr6TP1m^2fD(POnm*mt+o0Turh4Ri8><z>k)t)k}
zl+?q|E$py9QAb>)GkZyHOir!joyT<Crc-!VONh3$6<qBI`7A;{%9<d>r@}h(7NoIw
zPb6jr3grE<8tpq%H3(yYqUA?AHJ->)I!_5QKCQUCB)<n4AFJ}rTi?UH%BgrmcbPv>
z^4iuU%oT95YI7F+SgP^ab$*|(r4Qw+t`*VB5#nDJTjN{U`kl?{>*)Nhu6~|%Z~bG|
zm9VJI6}1!f1Eo}r)v-FPqrF0QOt5;zj1qH<$Ev(aJ>$N5y?0G3<6XT}FTrVLu(QKg
z>KYY7Q!pbzX!wrjM#|v9iXX}q)_mZha#eX=($NZpwW`s=dpb1}*72<EsGX?iX4LcK
zOZ6OaCLdMb7PO+S&A7^jJa86mU|&2N{$={M@*A73wUF)al&R5;HzrtdBk^&D(-(1D
z0_G8<U&ai!v6!^_i3-j0kUmw*e~!J9<SCiSc*j_6O$<hx(#>-Wk+)sCM-r<y?2qqn
zcFUI8xaGkeVm}w1vg_4rEt{bgY@Fiy<i-ST(oC%HJfhxys!d*w+We$+X{L!)md0YF
zUrtol&M4%Rst+-<G^}$&bFW}V{ZN&sbRU~;@s{*3zOa+Q*3Wg8Jzw!`)3YI_(m4ra
z!MuKYO556yZ)(SETCZB6&Aeps6*#*#IL42Od9#l<${NqvDXhE;v*o_M)7?ots+&Or
zb;-76G4^}>`!CE>aE8YBd_fv3vKJt|Va!JX-6vV;Y%Py1=O4>BPb*+aKg%6@-zzia
znJ-S~!|W2j#)|U;%v#c&lBQ~wd$W7`bYFzs?^8mt&JX*aNYWnoK2Z9IM|zbjp|A|Z
zDS*&zLIV#yTFhk@;%3Mk#L2O5@5^-GGiUmIqeH*DIOmgw6Vp|jjS}CZa?h8-z6F*o
z$OYQ>ziKMKPi8chAxB1@Rr8VL7ux+oxj{B6WZ&aX!fr&IuPdkEW+!m-Uz}pRVyr~|
z#JEpP-|8kymw^03t4`!c@O!G4Bx{j{%LMF?>U!q=Mo(x2qZL!wb}U)XZrTKEINN$n
zV25<qGhLtB&keM)xka@l?OzF{U0UBC!t3zg96PQ&;s-1ROr1wzFS3upCc)kH%*6M}
z-~PHo{<`LMU!fD;Swb4&x62dDaRT2*ax?Paq6wB@=!G<-2gY5}&*bkJc&>~Y{#>o$
zbXm^{eQNMFajH2pKZyIa2las3>b8=d2&3wYh`pq><k#P+g|6V4KfS)Sbmp2*%V3uX
z4dZP0+Nu4TQ?g}Aye}AD2hN#kyHw8bwGZbWz8ld<rS@k9EA55dY$|NAqZ+T3eR<t#
z{SV~kz}66K2{HSqmhj!OW^2i9fs)^+K!ZW0-gPSD1C;yRpe@$~)dG}SM87=;wFUmJ
ztRwrW*8@IW<nJh&K&yaG?bJ{H7O;{USf?p1q-&-3cW?2Q+>x-A)_+6zl4{(rNAa%i
zBmPzQ23rAr@p_4?VSCxOHRFmWtl`h=uH)yL!xFN1Ug!1rR^q(p4$s_D>C2?Zu?#i7
zbxB-}Hc4UFD-S*GO;w}*YO3vE-t=zfjq1c{-RQjy9XQ`sFPW@+G@f;Osd2R@T`QSz
z`?=S>S(Av9gU>R)d<V1CdX#QI&%`-@Svw}paGUfy;!Wv$G>KY68u$yrU)rfbZ;$hM
z`BMi~e%!BPkCK)}a(<A_C`***tz8AFOX`%9ybrf(5bLjwg{!gty7yMkfi;(6o%PGO
znqrHBbEjZWuc@x;_?KrRVptZDVECtA@*E16+-5bF)}va}(xY0hu1!npd2};g3sQ=B
z9*LBAXM4;vcXgGi{irq&OYd3mhPP{>am5JBFSJW7H69&e*%3*x^tDTIYAj))bhs^~
zF^eDW2~p#Bq-V6Dy;QO#L(#&Dw`AFN)@WN%L&BLRvBngBGM--_K7^mxexqqhGc%ZB
z&xLf-`BAHjU>7@#f7^Z|zGpWlH`W_Kx0L!;M1F%5vlo-@R9&`}`U+c*pyc4PzRp|Q
z%S;Dwaurf*dc0F>szG_pZNvI6<pZVPWa!4azan{;bZWh2`?XED!JA*`VJ+(nx;~_S
zWF$Y`GjiGJmUYipnhtboJ&}skSnTbAU+(=HI(_}ID*n_KW~rf_W_)3!fiKxIV%bR0
z5#ds3)rV`%b>8$&=3Un!eO_t$7<J^IIMqGfr}b>q1!7R!ESb_faGJX!c^*bQN47{N
zhfnKu_n}UB7aAmfVF%k@YbZnhesypN@7*!vT;%pz?;6yb_G8*ay#Zf&dyi>N#V0k8
zdph*^!p^o=8}#_%M4KLzep%%9>Lw*2AGeGve!sWpDCB-cT3nT|+FRL)8fuUCmbPdN
z2azLX$22?FHLWw1?$PjXJK6Geo`X8cvW_2a)^K+-o8hK1Nyu6mc@DRWdHYT>Q$(}W
zv(D#i>oed^CwgmW*GUP<lXrRM>ZHb`m2Y{_E*g{SysOMI-o}+l$x>ZnnY&>|>G54V
z%Wi6jtxT<37GbGvduv%lOU=B$Y%hzYc3C!|l6%lHzfoIeVdwQ!=G#iSs}(j8RKkI_
zsZ0;FO%G(;oi*Myz482MJ@ZyaAfLOLDGJi%$$DloL|}CvIhBrbi_l96t2}ej-hQ=T
z<5jvfiQ%TKLyQ-mWr;Q1uE0i|o^Go0&TWM}sYRKambPk4avNGQ+Q-*h^d|R~c#}0k
zqV!TrGzD5>j%bPY-f^C}{VlOI_Nq8;(2q8ZMtt0I0>#VlcsN$3wUYNhv&P#EC~eWw
z&NRNXo#K><I6c`O6H#Tdwg&qOHAc;7v0g}yymt$0s^J~r`<9*t#&6sj-^sQ!Xonr5
z9Uks68a_tvCfecATQ}5b_oE$ZnZ~lwq<trWkJ5(lBik9zZe}KZbA0t$6Rr(3m371?
zV&*1V;{~+Fk5LZExmXuGHLR)Bw_N!KsYc1%R<E}A1-Q{e?M2t`@}{>)-gOJ0xAz`w
zmZ*k!4;|AOUZB<hI%62_^|HhM!Eg}ajKm4+5q5@Jjnet27Si}J)as{tSzN7W4ca9?
zIFc{!9eHkaT&+pp8}Cg&rfHHJSD6ZrX-vcXxE(<+A?KbtD#g`!P$zkI`v|`DsNq~>
zTuoDW<9zSQK4w^R+VAZRmpoR{4hs>JD!taE98EB-3D<hs5u-IbG)=WFHQvg%(H0bG
z-NuB4E2BJZ=r7J<jYIMJhe<uveKmZ3eHagigs*hRo2H<Tk?Z5j*P1pqOQyCgoT~mh
z^S0U9>LOEAlw@kh3NzJ1)GW39QAerlslI-`)^iA{M@^;L=2Z@9JR=cS=K+cL_OPaP
zyhDf5r6=@8?JXKljjZ-YEgF+@Qsb%C!3W;k!J4XhhYU`7TE8~e>vMMZkd>Pk`(U@%
zJim5Z+4=^<$7q{qhaSYGG3m9xh_?FYxZ+jGC%mtheYvZp(pr~Tv&>7UZ4Ukhb6_wB
z26JFA2L^LsFb4*6U@!*;b6_wB26JFA2L^LsFbBRb2U2FG%*nXt0qd+ej4hcoVaoVB
z<Hl#1>{B!2;$YRsSl9!L?0IR4DaL3=7|}+fF#|uKtA6C35qPUUh8c|$K^h;uic@vZ
z$XEftjE|CE87sn!EAWs0kQd}ce$nF!<E`{eZ*DWL0P1HojwRm_2>z;%j}qsjs=s&9
z7b+_Sgn#rkc{`B^kob{H(ANw^mp;#!xWYJrxQJLmpW<)8UHz**!(;Ko`~GJngEGln
zP>^3>jLtM>*`3bpyewmCN?L;P;rq?A!q|g3Hs^x;f?VS)TdqCmiP1PMn7^0aCnwCF
zW3<?9PFI25f%miLMrVpLxWtocD>M?HL-h!LWU6I!kE@`-p64_s+X|fhK~NYj^}Qv#
zAa|*)z-~;mIWCLCq{8T&!Z3E}eOmVN%ibeN_a%n0*{(ciHeyfJVy?Zwk)5AM!BF@U
zC<@lRU*_d6&0{GKrexfkFeicP&771}bH=^q`-xhZ<@Y}g7_rdre-pS9Fd8r$kdn8=
zmXn=nbmq)AF352?78(oei(Phy)975b$Zq^abdKvWO2k5>Ejn|WF@OW?*$eWG3tTxl
z^q#_=bAMt++Pqo!Q20UGl45z_N;)IeoJwvBmiqk!uPzDTcY%)pEN~-C?<#=_g1kX@
z!jAdb8O{RRq6|A#0LJJU5zNcXu@@K@*s^o%nJhae$DU=&F=ppEoCPlKq`bR=h2>^D
zkOx_L_Do|=zAf{I-aDN6D90;2uyb2Z&XtZx-y&O<eWHzXyTgI#xN@A|!{f>ec$R6j
z7dq_)d1_SgP~ckRq&$jt1oND#tnpSgsVMl{km&>8<#L<LVV{l~HR)$Lg~nVbiZw`4
z`CP_JFJpsm!AqGFB(L<>zK9238FL*@v=2v+CVw4^7%Q+{?tk<p4n%nXvlF~o0LNs&
zB*tvOHo_)AEC4oXwmSe*0q6}KaCgAn0e1)79dLJ$`<;NF0VYodOkz&><Ags>@H@fp
z1iusfPVf#)_rS==h`R(x%eG`Mu^TM~c6(-iuF*Q>4tVq<e$xdn`Nxcmed!PUPSvp@
za-!dx6Z)S6E{r`ho)v8b#M)WWBY*<%{8aEIb5>Lc&<J`r_@XjdQ4Zh^z#-7&&j-K+
z^i02d?Mt$`-8ctnF>+hpSf_Em9o1?PS_G=LGvA21n46zzbJ~r0_NB(W{7gHW$QQXB
z^d~+#ll;idb&aQ%PtTcX7xSqR;TI@*ly$a)FS*^Z#Dp>kKHq_|n8+9AJM4LEq9dPA
zbl3~BZ8`CiCr!ftNt32co;)RX(j@qineTFrUu1JG6yGk&$>x*T;pKk+XMh8M4*<u0
zB<utKyMVU=I{@1N{{h$x*aX-B_zj>Eum-RiumZ3IkOK&L%J1(3?gg9%Joh8vYw&jh
zz5sj*_&Z=fU=N@P@SlL~fHweJ0lx=q1k?g3PPgWv6TOYGJx?S3fP;W908wkvUjx4l
zIELr#m3R-(1B`$~KoOu4?~VXBRr&qj0q%On?=Jzg0OCLw0#Z{j7?_hVXoxNXjW^YN
zwcCTK4`S3&M;F03KG>(+ilKzvem`I~0DBm2f0!{E4m0M=PIxdQWft}H=Qkp3z|0r?
z{`ml+R|Dqac^aU0E-U)Kgkx8P_xjt&e?TFi0`MyUxebKXpce(YWtNkj=PJBCNTHr%
zq`)Zdpf<ttb5WPG(L@-_&J&%sV?1@_)Z!S8Pxf3FBoKQBcNAn4*lmHfbcOrUf@~)>
zxL{wEok=5Ywiub|%RE;u^`np#KKm4P0Fe9-)DeNnZ6MG)CTTQU{6fS}zT&6*Z+^=E
z@~8iQ{tc%B!cSU0n@KAq>4u>iMs866;~~^TExl!`+wH)=N5@?$+@u?{Ki}>5`!&P>
z-h+6q#rv;;$!YL6m;-}3Fqi}XlN>POBZ6B69=@9u5zu@oE%kwW&2ayr-`hh1yvYgo
z&-o!fdKVKO;KjV`-?E;+ffc=aBP&`29Au(?GT49axVPV(-s=TZrMcfd<v|DLd+LzL
ya#H%;@0n$pO+cR{C-u9VQ&Z*;ko&Cz+(Cw-iw&)SA5k;=`4{eFMQ~U9-v0tg0|1@?
literal 0
HcmV?d00001
diff --git a/roms/Makefile b/roms/Makefile
index 28e1e55..f9acf39 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -66,6 +66,7 @@ default help:
@echo " efi -- update UEFI (edk2) platform firmware"
@echo " opensbi32-virt -- update OpenSBI for 32-bit virt machine"
@echo " opensbi64-virt -- update OpenSBI for 64-bit virt machine"
+ @echo " opensbi32-sifive_u -- update OpenSBI for 32-bit sifive_u machine"
@echo " opensbi64-sifive_u -- update OpenSBI for 64-bit sifive_u machine"
@echo " bios-microvm -- update bios-microvm.bin (qboot)"
@echo " clean -- delete the files generated by the previous" \
@@ -181,6 +182,12 @@ opensbi64-virt:
PLATFORM="qemu/virt"
cp opensbi/build/platform/qemu/virt/firmware/fw_jump.bin ../pc-bios/opensbi-riscv64-virt-fw_jump.bin
+opensbi32-sifive_u:
+ $(MAKE) -C opensbi \
+ CROSS_COMPILE=$(riscv32_cross_prefix) \
+ PLATFORM="sifive/fu540"
+ cp opensbi/build/platform/sifive/fu540/firmware/fw_jump.bin ../pc-bios/opensbi-riscv32-sifive_u-fw_jump.bin
+
opensbi64-sifive_u:
$(MAKE) -C opensbi \
CROSS_COMPILE=$(riscv64_cross_prefix) \
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 4/6] NFS: Add READ_PLUS data segment support
From: Anna Schumaker @ 2020-02-20 14:42 UTC (permalink / raw)
To: Chuck Lever; +Cc: Trond.Myklebust, Linux NFS Mailing List
In-Reply-To: <AAF85957-285A-42BF-993D-7EB4843E2ED2@oracle.com>
On Fri, 2020-02-14 at 17:28 -0500, Chuck Lever wrote:
> > On Feb 14, 2020, at 4:12 PM, schumaker.anna@gmail.com wrote:
> >
> > From: Anna Schumaker <Anna.Schumaker@Netapp.com>
> >
> > This patch adds client support for decoding a single NFS4_CONTENT_DATA
> > segment returned by the server. This is the simplest implementation
> > possible, since it does not account for any hole segments in the reply.
> >
> > Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
> > ---
> > fs/nfs/nfs42xdr.c | 138 ++++++++++++++++++++++++++++++++++++++
> > fs/nfs/nfs4proc.c | 43 +++++++++++-
> > fs/nfs/nfs4xdr.c | 1 +
> > include/linux/nfs4.h | 2 +-
> > include/linux/nfs_fs_sb.h | 1 +
> > include/linux/nfs_xdr.h | 2 +-
> > 6 files changed, 182 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/nfs/nfs42xdr.c b/fs/nfs/nfs42xdr.c
> > index c03f3246d6c5..bf118ecabe2c 100644
> > --- a/fs/nfs/nfs42xdr.c
> > +++ b/fs/nfs/nfs42xdr.c
> > @@ -45,6 +45,15 @@
> > #define encode_deallocate_maxsz (op_encode_hdr_maxsz + \
> > encode_fallocate_maxsz)
> > #define decode_deallocate_maxsz (op_decode_hdr_maxsz)
> > +#define encode_read_plus_maxsz (op_encode_hdr_maxsz + \
> > + encode_stateid_maxsz + 3)
> > +#define NFS42_READ_PLUS_SEGMENT_SIZE (1 /* data_content4 */ + \
> > + 2 /* data_info4.di_offset */ + \
> > + 2 /* data_info4.di_length */)
> > +#define decode_read_plus_maxsz (op_decode_hdr_maxsz + \
> > + 1 /* rpr_eof */ + \
> > + 1 /* rpr_contents count */ + \
> > + NFS42_READ_PLUS_SEGMENT_SIZE)
> > #define encode_seek_maxsz (op_encode_hdr_maxsz + \
> > encode_stateid_maxsz + \
> > 2 /* offset */ + \
> > @@ -128,6 +137,14 @@
> > decode_putfh_maxsz + \
> > decode_deallocate_maxsz + \
> > decode_getattr_maxsz)
> > +#define NFS4_enc_read_plus_sz (compound_encode_hdr_maxsz + \
> > + encode_sequence_maxsz + \
> > + encode_putfh_maxsz + \
> > + encode_read_plus_maxsz)
> > +#define NFS4_dec_read_plus_sz (compound_decode_hdr_maxsz + \
> > + decode_sequence_maxsz + \
> > + decode_putfh_maxsz + \
> > + decode_read_plus_maxsz)
> > #define NFS4_enc_seek_sz (compound_encode_hdr_maxsz + \
> > encode_sequence_maxsz + \
> > encode_putfh_maxsz + \
> > @@ -252,6 +269,16 @@ static void encode_deallocate(struct xdr_stream *xdr,
> > encode_fallocate(xdr, args);
> > }
> >
> > +static void encode_read_plus(struct xdr_stream *xdr,
> > + const struct nfs_pgio_args *args,
> > + struct compound_hdr *hdr)
> > +{
> > + encode_op_hdr(xdr, OP_READ_PLUS, decode_read_plus_maxsz, hdr);
> > + encode_nfs4_stateid(xdr, &args->stateid);
> > + encode_uint64(xdr, args->offset);
> > + encode_uint32(xdr, args->count);
> > +}
> > +
> > static void encode_seek(struct xdr_stream *xdr,
> > const struct nfs42_seek_args *args,
> > struct compound_hdr *hdr)
> > @@ -446,6 +473,29 @@ static void nfs4_xdr_enc_deallocate(struct rpc_rqst
> > *req,
> > encode_nops(&hdr);
> > }
> >
> > +/*
> > + * Encode READ_PLUS request
> > + */
> > +static void nfs4_xdr_enc_read_plus(struct rpc_rqst *req,
> > + struct xdr_stream *xdr,
> > + const void *data)
> > +{
> > + const struct nfs_pgio_args *args = data;
> > + struct compound_hdr hdr = {
> > + .minorversion = nfs4_xdr_minorversion(&args->seq_args),
> > + };
> > +
> > + encode_compound_hdr(xdr, req, &hdr);
> > + encode_sequence(xdr, &args->seq_args, &hdr);
> > + encode_putfh(xdr, args->fh, &hdr);
> > + encode_read_plus(xdr, args, &hdr);
> > +
> > + rpc_prepare_reply_pages(req, args->pages, args->pgbase,
> > + args->count, hdr.replen);
> > + req->rq_rcv_buf.flags |= XDRBUF_READ;
>
> IMO this line is incorrect.
You're right, this line causes problems for RDMA with READ_PLUS. I added it to
match how the other xdr read encoders were set up
>
> RFC 8267 Section 6.1 does not list any part of the result of READ_PLUS
> as DDP-eligible. There's no way for a client to know how to set up
> Write chunks, unless it knows exactly where the file's holes are in
> advance. Even then... racy.
>
> Just curious, have you tried READ_PLUS with proto=rdma ?
I haven't done in-depth performance testing, but I have been able to run it.
Anna
>
>
> > + encode_nops(&hdr);
> > +}
> > +
> > /*
> > * Encode SEEK request
> > */
> > @@ -694,6 +744,67 @@ static int decode_deallocate(struct xdr_stream *xdr,
> > struct nfs42_falloc_res *re
> > return decode_op_hdr(xdr, OP_DEALLOCATE);
> > }
> >
> > +static uint32_t decode_read_plus_data(struct xdr_stream *xdr, struct
> > nfs_pgio_res *res,
> > + uint32_t *eof)
> > +{
> > + __be32 *p;
> > + uint32_t count, recvd;
> > + uint64_t offset;
> > +
> > + p = xdr_inline_decode(xdr, 8 + 4);
> > + if (unlikely(!p))
> > + return -EIO;
> > +
> > + p = xdr_decode_hyper(p, &offset);
> > + count = be32_to_cpup(p);
> > + if (count == 0)
> > + return 0;
> > +
> > + recvd = xdr_read_pages(xdr, count);
> > + if (count > recvd) {
> > + dprintk("NFS: server cheating in read reply: "
> > + "count %u > recvd %u\n", count, recvd);
> > + count = recvd;
> > + *eof = 0;
> > + }
> > +
> > + return count;
> > +}
> > +
> > +static int decode_read_plus(struct xdr_stream *xdr, struct nfs_pgio_res
> > *res)
> > +{
> > + __be32 *p;
> > + uint32_t count, eof, segments, type;
> > + int status;
> > +
> > + status = decode_op_hdr(xdr, OP_READ_PLUS);
> > + if (status)
> > + return status;
> > +
> > + p = xdr_inline_decode(xdr, 4 + 4);
> > + if (unlikely(!p))
> > + return -EIO;
> > +
> > + eof = be32_to_cpup(p++);
> > + segments = be32_to_cpup(p++);
> > + if (segments == 0)
> > + return 0;
> > +
> > + p = xdr_inline_decode(xdr, 4);
> > + if (unlikely(!p))
> > + return -EIO;
> > +
> > + type = be32_to_cpup(p++);
> > + if (type == NFS4_CONTENT_DATA)
> > + count = decode_read_plus_data(xdr, res, &eof);
> > + else
> > + return -EINVAL;
> > +
> > + res->eof = eof;
> > + res->count = count;
> > + return 0;
> > +}
> > +
> > static int decode_seek(struct xdr_stream *xdr, struct nfs42_seek_res *res)
> > {
> > int status;
> > @@ -870,6 +981,33 @@ static int nfs4_xdr_dec_deallocate(struct rpc_rqst
> > *rqstp,
> > return status;
> > }
> >
> > +/*
> > + * Decode READ_PLUS request
> > + */
> > +static int nfs4_xdr_dec_read_plus(struct rpc_rqst *rqstp,
> > + struct xdr_stream *xdr,
> > + void *data)
> > +{
> > + struct nfs_pgio_res *res = data;
> > + struct compound_hdr hdr;
> > + int status;
> > +
> > + status = decode_compound_hdr(xdr, &hdr);
> > + if (status)
> > + goto out;
> > + status = decode_sequence(xdr, &res->seq_res, rqstp);
> > + if (status)
> > + goto out;
> > + status = decode_putfh(xdr);
> > + if (status)
> > + goto out;
> > + status = decode_read_plus(xdr, res);
> > + if (!status)
> > + status = res->count;
> > +out:
> > + return status;
> > +}
> > +
> > /*
> > * Decode SEEK request
> > */
> > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> > index 95d07a3dc5d1..ed3ec8c36273 100644
> > --- a/fs/nfs/nfs4proc.c
> > +++ b/fs/nfs/nfs4proc.c
> > @@ -69,6 +69,10 @@
> >
> > #include "nfs4trace.h"
> >
> > +#ifdef CONFIG_NFS_V4_2
> > +#include "nfs42.h"
> > +#endif /* CONFIG_NFS_V4_2 */
> > +
> > #define NFSDBG_FACILITY NFSDBG_PROC
> >
> > #define NFS4_BITMASK_SZ 3
> > @@ -5199,28 +5203,60 @@ static bool nfs4_read_stateid_changed(struct
> > rpc_task *task,
> > return true;
> > }
> >
> > +static bool nfs4_read_plus_not_supported(struct rpc_task *task,
> > + struct nfs_pgio_header *hdr)
> > +{
> > + struct nfs_server *server = NFS_SERVER(hdr->inode);
> > + struct rpc_message *msg = &task->tk_msg;
> > +
> > + if (msg->rpc_proc == &nfs4_procedures[NFSPROC4_CLNT_READ_PLUS] &&
> > + server->caps & NFS_CAP_READ_PLUS && task->tk_status == -ENOTSUPP) {
> > + server->caps &= ~NFS_CAP_READ_PLUS;
> > + msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ];
> > + rpc_restart_call_prepare(task);
> > + return true;
> > + }
> > + return false;
> > +}
> > +
> > static int nfs4_read_done(struct rpc_task *task, struct nfs_pgio_header
> > *hdr)
> > {
> > -
> > dprintk("--> %s\n", __func__);
> >
> > if (!nfs4_sequence_done(task, &hdr->res.seq_res))
> > return -EAGAIN;
> > if (nfs4_read_stateid_changed(task, &hdr->args))
> > return -EAGAIN;
> > + if (nfs4_read_plus_not_supported(task, hdr))
> > + return -EAGAIN;
> > if (task->tk_status > 0)
> > nfs_invalidate_atime(hdr->inode);
> > return hdr->pgio_done_cb ? hdr->pgio_done_cb(task, hdr) :
> > nfs4_read_done_cb(task, hdr);
> > }
> >
> > +#ifdef CONFIG_NFS_V4_2
> > +static void nfs42_read_plus_support(struct nfs_server *server, struct
> > rpc_message *msg)
> > +{
> > + if (server->caps & NFS_CAP_READ_PLUS)
> > + msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ_PLUS];
> > + else
> > + msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ];
> > +}
> > +#else
> > +static void nfs42_read_plus_support(struct nfs_server *server, struct
> > rpc_message *msg)
> > +{
> > + msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ];
> > +}
> > +#endif /* CONFIG_NFS_V4_2 */
> > +
> > static void nfs4_proc_read_setup(struct nfs_pgio_header *hdr,
> > struct rpc_message *msg)
> > {
> > hdr->timestamp = jiffies;
> > if (!hdr->pgio_done_cb)
> > hdr->pgio_done_cb = nfs4_read_done_cb;
> > - msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ];
> > + nfs42_read_plus_support(NFS_SERVER(hdr->inode), msg);
> > nfs4_init_sequence(&hdr->args.seq_args, &hdr->res.seq_res, 0, 0);
> > }
> >
> > @@ -9970,7 +10006,8 @@ static const struct nfs4_minor_version_ops
> > nfs_v4_2_minor_ops = {
> > | NFS_CAP_SEEK
> > | NFS_CAP_LAYOUTSTATS
> > | NFS_CAP_CLONE
> > - | NFS_CAP_LAYOUTERROR,
> > + | NFS_CAP_LAYOUTERROR
> > + | NFS_CAP_READ_PLUS,
> > .init_client = nfs41_init_client,
> > .shutdown_client = nfs41_shutdown_client,
> > .match_stateid = nfs41_match_stateid,
> > diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
> > index 47817ef0aadb..68b2917d0537 100644
> > --- a/fs/nfs/nfs4xdr.c
> > +++ b/fs/nfs/nfs4xdr.c
> > @@ -7584,6 +7584,7 @@ const struct rpc_procinfo nfs4_procedures[] = {
> > PROC42(COPY_NOTIFY, enc_copy_notify, dec_copy_notify),
> > PROC(LOOKUPP, enc_lookupp, dec_lookupp),
> > PROC42(LAYOUTERROR, enc_layouterror, dec_layouterror),
> > + PROC42(READ_PLUS, enc_read_plus, dec_read_plus),
> > };
> >
> > static unsigned int nfs_version4_counts[ARRAY_SIZE(nfs4_procedures)];
> > diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h
> > index 82d8fb422092..c1eeef52545c 100644
> > --- a/include/linux/nfs4.h
> > +++ b/include/linux/nfs4.h
> > @@ -540,8 +540,8 @@ enum {
> >
> > NFSPROC4_CLNT_LOOKUPP,
> > NFSPROC4_CLNT_LAYOUTERROR,
> > -
> > NFSPROC4_CLNT_COPY_NOTIFY,
> > + NFSPROC4_CLNT_READ_PLUS,
> > };
> >
> > /* nfs41 types */
> > diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h
> > index 465fa98258a3..11248c5a7b24 100644
> > --- a/include/linux/nfs_fs_sb.h
> > +++ b/include/linux/nfs_fs_sb.h
> > @@ -281,5 +281,6 @@ struct nfs_server {
> > #define NFS_CAP_OFFLOAD_CANCEL (1U << 25)
> > #define NFS_CAP_LAYOUTERROR (1U << 26)
> > #define NFS_CAP_COPY_NOTIFY (1U << 27)
> > +#define NFS_CAP_READ_PLUS (1U << 28)
> >
> > #endif
> > diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h
> > index 94c77ed55ce1..8efbf3d8b263 100644
> > --- a/include/linux/nfs_xdr.h
> > +++ b/include/linux/nfs_xdr.h
> > @@ -655,7 +655,7 @@ struct nfs_pgio_args {
> > struct nfs_pgio_res {
> > struct nfs4_sequence_res seq_res;
> > struct nfs_fattr * fattr;
> > - __u32 count;
> > + __u64 count;
> > __u32 op_status;
> > union {
> > struct {
> > --
> > 2.25.0
> >
>
> --
> Chuck Lever
>
>
>
^ permalink raw reply
* Re: [PATCH] sched/fair: add !se->on_rq check before dequeue entity
From: chenqiwu @ 2020-02-20 14:42 UTC (permalink / raw)
To: Vincent Guittot
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel, chenqiwu
In-Reply-To: <CAKfTPtBS=HhBvp2ps1SZXc--WoXO_ZOY=+5o7RJ9vDgi9eLAqA@mail.gmail.com>
>
> Hmm i have been too quick in my reply. I wanted to say:
> AFAICT, there is no other way to dequeue a task from a cfs_rq for
> which the group entity is not enqueued
But we should notice the potential racy pathes called by deactivate_task().
For example:
One path is dequeue a task from its cfs_rq called by schedule():
__schedule
deactivate_task
dequeue_task
dequeue_task_fair
Another path is trying to migrate the same task to a CPU on the preferred node:
numa_migrate_preferred
task_numa_migrate
migrate_swap
stop_two_cpus
migrate_swap_stop
__migrate_swap_task
deactivate_task
dequeue_task_fair
There could be a racy if the task is dequeued form its cfs_rq in parallel.
^ permalink raw reply
* [PATCH 2/2] riscv: sifive_u: Update BIOS_FILENAME for 32-bit
From: Bin Meng @ 2020-02-20 14:42 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
In-Reply-To: <1582209758-2996-1-git-send-email-bmeng.cn@gmail.com>
Update BIOS_FILENAME to consider 32-bit bios image file name.
Tested booting Linux v5.5 32-bit image (built from rv32_defconfig
plus CONFIG_SOC_SIFIVE) with the default 32-bit bios image.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
hw/riscv/sifive_u.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index ca561d3..371133e 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -57,7 +57,11 @@
#include <libfdt.h>
-#define BIOS_FILENAME "opensbi-riscv64-sifive_u-fw_jump.bin"
+#if defined(TARGET_RISCV32)
+# define BIOS_FILENAME "opensbi-riscv32-sifive_u-fw_jump.bin"
+#else
+# define BIOS_FILENAME "opensbi-riscv64-sifive_u-fw_jump.bin"
+#endif
static const struct MemmapEntry {
hwaddr base;
--
2.7.4
^ permalink raw reply related
* Unexpected high latency on bbb
From: Laurentiu-Cristian Duca @ 2020-02-20 14:42 UTC (permalink / raw)
To: linux-rt-users
Hello,
I have made a rt-test on kernel preempt-rt 5.4.5
and got unexpected high latencies (5ms max).
Maybe I am doing something wrong ... please help
The same test got 120us max latency on EVL project
(on 3 hour test with one million samples)
and only the synchronization is different on preempt_rt
(referring to rt_gpio module described below).
scenario between beaglebone black computer and fpga board
====
fpga generates an interrupt and counts latency until ack
bbb receives and ack interrupt via rt_gpio module
fpga sends latency counter value via SPI to bbb
bbb prints on the screen
result: 5ms max latency.
rt_gpio.c module
====
...
static struct swait_queue_head head_swait;
static irqreturn_t rt_interrupt_handler(int irq, void *data)
{
n_interrupts++;
/* use swait.h model to signal interrupt arrived */
interrupt_done = 1;
smp_mb();
if (swait_active(&head_swait))
swake_up_one(&head_swait);
return IRQ_HANDLED;
}
static ssize_t rt_gpio_read(struct file *f, char __user *buf, size_t
len, loff_t *off)
{
int ret;
DECLARE_SWAITQUEUE(swait);
/* wait for interrupt using swait.h model */
for (;;) {
prepare_to_swait_exclusive(&head_swait, &swait, TASK_INTERRUPTIBLE);
/* smp_mb() from set_current_state() */
if (interrupt_done)
break;
schedule();
}
finish_swait(&head_swait, &swait);
interrupt_done = 0;
smp_mb();
gpiod_get_raw_value(gpiod_in)
copy_to_user(...);
}
static ssize_t rt_gpio_write(struct file *f, const char __user *buf,
size_t len, loff_t *off)
{
copy_from_user(...);
gpiod_set_raw_value(gpiod_out, user_value);
}
static int __init rt_gpio_init(void) /* Constructor */
{
...
request_irq(irq_line, rt_interrupt_handler,
IRQ_TYPE_EDGE_RISING | IRQF_NO_THREAD, "rt_gpio interrupt\n", (void *)1));
init_swait_queue_head(&head_swait);
}
static void __exit rt_gpio_exit(void)
{
free_irq(irq_line, (void*)1);
gpio_free(gpio_in_id);
gpio_free(gpio_out_id);
...
}
userspace
====
printf("Setup this thread as a real time thread\n");
if((ret = mlockall(MCL_FUTURE|MCL_CURRENT)) < 0) {
printf("mlockall failed: %s\n", strerror(ret));
return -1;
}
sp.sched_priority = 98;
if((ret = pthread_setschedparam(pthread_self(), SCHED_FIFO, &sp)) != 0) {
printf("Failed to set lat thread to real-time priority: %s\n",
strerror(ret));
return -1;
}
...
use rt_gpio module to receive interrupt and ack.
Thank you,
L-C
^ permalink raw reply
* [PATCH net] net: netlink: cap max groups which will be considered in netlink_bind()
From: Nikolay Aleksandrov @ 2020-02-20 14:42 UTC (permalink / raw)
To: netdev
Cc: davem, Nikolay Aleksandrov, Christophe Leroy, Richard Guy Briggs,
Erhard F .
Since nl_groups is a u32 we can't bind more groups via ->bind
(netlink_bind) call, but netlink has supported more groups via
setsockopt() for a long time and thus nlk->ngroups could be over 32.
Recently I added support for per-vlan notifications and increased the
groups to 33 for NETLINK_ROUTE which exposed an old bug in the
netlink_bind() code causing out-of-bounds access on archs where unsigned
long is 32 bits via test_bit() on a local variable. Fix this by capping the
maximum groups in netlink_bind() to BITS_PER_TYPE(u32), effectively
capping them at 32 which is the minimum of allocated groups and the
maximum groups which can be bound via netlink_bind().
CC: Christophe Leroy <christophe.leroy@c-s.fr>
CC: Richard Guy Briggs <rgb@redhat.com>
Fixes: 4f520900522f ("netlink: have netlink per-protocol bind function return an error code.")
Reported-by: Erhard F. <erhard_f@mailbox.org>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
Dave it is not necessary to queue this fix for stable releases since
NETLINK_ROUTE is the first to reach more groups after I added the vlan
notification changes and I don't think we'll ever backport new groups. :)
Up to you of course.
In fact looking at netlink_kernel_create nlk->groups can't be less than 32
so we can add a NETLINK_MIN_GROUPS == NETLINK_MAX_LEGACY_BIND_GRPS == 32
in net-next to replace the raw value.
net/netlink/af_netlink.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 4e31721e7293..edf3e285e242 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1014,7 +1014,8 @@ static int netlink_bind(struct socket *sock, struct sockaddr *addr,
if (nlk->netlink_bind && groups) {
int group;
- for (group = 0; group < nlk->ngroups; group++) {
+ /* nl_groups is a u32, so cap the maximum groups we can bind */
+ for (group = 0; group < BITS_PER_TYPE(u32); group++) {
if (!test_bit(group, &groups))
continue;
err = nlk->netlink_bind(net, group + 1);
@@ -1033,7 +1034,7 @@ static int netlink_bind(struct socket *sock, struct sockaddr *addr,
netlink_insert(sk, nladdr->nl_pid) :
netlink_autobind(sock);
if (err) {
- netlink_undo_bind(nlk->ngroups, groups, sk);
+ netlink_undo_bind(BITS_PER_TYPE(u32), groups, sk);
goto unlock;
}
}
--
2.24.1
^ permalink raw reply related
* [dpdk-dev] [PATCH] net/mlx5: fix running without rxq
From: Shiri Kuzin @ 2020-02-20 14:42 UTC (permalink / raw)
To: dev@dpdk.org
Cc: Matan Azrad, Raslan Darawsheh, Slava Ovsiienko, stable@dpdk.org
When running mlx5_dev_start in mlx5_ethdev the function calls
mlx5_dev_configure_rss_reta in order to configure the rxq's.
Before mlx5_dev_configure_rss_reta there isn't a check whether
there are rxq's and if rxq's are 0 the function fails.
For example, this command:
/build/app/test-pmd/testpmd -n 4 -w 0000:08:00.0,rx_vec_en=0
-- --burst=64 --mbcache=512 -i --nb-cores=27 --txd=2048 --rxd=2048
--vxlan-gpe-port=6081 --mp-alloc=xbuf --rxq 0 --forward-mode=txonly
would fail.
In order to fix this issue, we should call mlx5_dev_configure_rss_reta
only if we have rxq's.
Fixes: 63bd16292c3a ("net/mlx5: support RSS on hairpin")
Cc: stable@dpdk.org
Signed-off-by: Shiri Kuzin <shirik@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
---
drivers/net/mlx5/mlx5_trigger.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_trigger.c b/drivers/net/mlx5/mlx5_trigger.c
index be47df5..571b7a0 100644
--- a/drivers/net/mlx5/mlx5_trigger.c
+++ b/drivers/net/mlx5/mlx5_trigger.c
@@ -280,11 +280,13 @@
rte_net_mlx5_dynf_inline_mask = 1UL << fine_inline;
else
rte_net_mlx5_dynf_inline_mask = 0;
- ret = mlx5_dev_configure_rss_reta(dev);
- if (ret) {
- DRV_LOG(ERR, "port %u reta config failed: %s",
- dev->data->port_id, strerror(rte_errno));
- return -rte_errno;
+ if (dev->data->nb_rx_queues > 0) {
+ ret = mlx5_dev_configure_rss_reta(dev);
+ if (ret) {
+ DRV_LOG(ERR, "port %u reta config failed: %s",
+ dev->data->port_id, strerror(rte_errno));
+ return -rte_errno;
+ }
}
ret = mlx5_txq_start(dev);
if (ret) {
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v1 0/2] perf report: Support annotation of code without symbols
From: Jin, Yao @ 2020-02-20 14:42 UTC (permalink / raw)
To: Jiri Olsa
Cc: acme, jolsa, peterz, mingo, alexander.shishkin, Linux-kernel, ak,
kan.liang, yao.jin
In-Reply-To: <20200220120655.GA586895@krava>
On 2/20/2020 8:06 PM, Jiri Olsa wrote:
> On Thu, Feb 20, 2020 at 08:03:18PM +0800, Jin, Yao wrote:
>>
>>
>> On 2/20/2020 7:56 PM, Jiri Olsa wrote:
>>> On Thu, Feb 20, 2020 at 08:59:00AM +0800, Jin Yao wrote:
>>>> For perf report on stripped binaries it is currently impossible to do
>>>> annotation. The annotation state is all tied to symbols, but there are
>>>> either no symbols, or symbols are not covering all the code.
>>>>
>>>> We should support the annotation functionality even without symbols.
>>>>
>>>> The first patch uses al_addr to print because it's easy to dump
>>>> the instructions from this address in binary for branch mode.
>>>>
>>>> The second patch supports the annotation on stripped binary.
>>>>
>>>> Jin Yao (2):
>>>> perf util: Print al_addr when symbol is not found
>>>> perf annotate: Support interactive annotation of code without symbols
>>>
>>> looks good, but I'm getting crash when annotating unresolved kernel address:
>>>
>>> jirka
>>>
>>>
>>
>> Thanks for reporting the issue.
>>
>> I guess you are trying the "0xffffffff81c00ae7", let me try to reproduce
>> this issue.
>
> yes, I also checked and it did not happen before
>
> jirka
>
Hi Jiri,
Can you try this fix?
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index ff5711899234..5144528b2931 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -2497,7 +2497,7 @@ add_annotate_opt(struct hist_browser *browser,
struct map_symbol *ms,
u64 addr)
{
- if (ms->map->dso->annotate_warned)
+ if (!ms->map || !ms->map->dso || ms->map->dso->annotate_warned)
return 0;
if (!ms->sym) {
It's tested OK at my side.
Thanks
Jin Yao
^ permalink raw reply related
* Re: [PATCH] mm: memcontrol: asynchronous reclaim for memory.high
From: Johannes Weiner @ 2020-02-20 14:41 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Tejun Heo, Roman Gushchin, linux-mm, cgroups,
linux-kernel, kernel-team
In-Reply-To: <20200220094639.GD20509@dhcp22.suse.cz>
On Thu, Feb 20, 2020 at 10:46:39AM +0100, Michal Hocko wrote:
> On Wed 19-02-20 16:17:35, Johannes Weiner wrote:
> > On Wed, Feb 19, 2020 at 08:53:32PM +0100, Michal Hocko wrote:
> > > On Wed 19-02-20 14:16:18, Johannes Weiner wrote:
> [...]
> > > > [ This is generally work in process: for example, if you isolate
> > > > workloads with memory.low, kswapd cpu time isn't accounted to the
> > > > cgroup that causes it. Swap IO issued by kswapd isn't accounted to
> > > > the group that is getting swapped.
> > >
> > > Well, kswapd is a system activity and as such it is acceptable that it
> > > is accounted to the system. But in this case we are talking about a
> > > memcg configuration which influences all other workloads by stealing CPU
> > > cycles from them
> >
> > From a user perspective this isn't a meaningful distinction.
> >
> > If I partition my memory among containers and one cgroup is acting
> > out, I would want the culprit to be charged for the cpu cycles the
> > reclaim is causing. Whether I divide my machine up using memory.low or
> > using memory.max doesn't really matter: I'm choosing between the two
> > based on a *memory policy* I want to implement - work-conserving vs
> > non-conserving. I shouldn't have to worry about the kernel tracking
> > CPU cycles properly in the respective implementations of these knobs.
> >
> > So kswapd is very much a cgroup-attributable activity, *especially* if
> > I'm using memory.low to delineate different memory domains.
>
> While I understand what you are saying I do not think this is easily
> achievable with the current implementation. The biggest problem I can
> see is that you do not have a clear information who to charge for
> the memory shortage on a particular NUMA node with a pure low limit
> based balancing because the limit is not NUMA aware. Besides that the
> origin of the memory pressure might be outside of any memcg. You can
> punish/account all memcgs in excess in some manner, e.g. proportionally
> to their size/excess but I am not really sure how fair that will
> be. Sounds like an interesting project but also sounds like tangent to
> this patch.
>
> High/Max limits are quite different because they are dealing with
> the internal memory pressure and you can attribute it to the
> cgroup/hierarchy which is in excess. There is a clear domain to reclaim
> from. This is an easier model to reason about IMHO.
They're not different. memory.low is just a usage limit that happens
to be enforcecd lazily rather than immediately.
If I'm setting memory.high or memory.max and I allocate beyond it, my
memory will be reclaimed with the limit as the target.
If I'm setting memory.low and I allocate beyond it, my memory will
eventually be reclaimed with the limit as the target.
In either case, the cgroup who allocated the memory that is being
reclaimed is the one obviously responsible for the reclaim work. Why
would the time of limit enforcement change that?
If on the other hand an allocation reclaims you below your limit, such
as can happen with a NUMA-bound allocation, whether it's high, max, or
low, then that's their cost to pay. But it's not really that important
what we do in that case - the memcg settings aren't NUMA aware so that
whole scenario is out of the purview of the controller anyway.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index d6085115c7f2..24fe6e9e64b1 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2651,6 +2651,7 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
memcg = mem_cgroup_iter(target_memcg, NULL, NULL);
do {
struct lruvec *lruvec = mem_cgroup_lruvec(memcg, pgdat);
+ bool account_cpu = current_is_kswapd() || current_work();
unsigned long reclaimed;
unsigned long scanned;
@@ -2673,6 +2674,7 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
continue;
}
memcg_memory_event(memcg, MEMCG_LOW);
+ account_cpu = false;
break;
case MEMCG_PROT_NONE:
/*
@@ -2688,11 +2690,17 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
reclaimed = sc->nr_reclaimed;
scanned = sc->nr_scanned;
+ if (account_cpu)
+ use_cpu_of_cgroup(memcg->css.cgroup);
+
shrink_lruvec(lruvec, sc);
shrink_slab(sc->gfp_mask, pgdat->node_id, memcg,
sc->priority);
+ if (account_cpu)
+ unuse_cpu_of_cgroup();
+
/* Record the group's reclaim efficiency */
vmpressure(sc->gfp_mask, memcg, false,
sc->nr_scanned - scanned,
> > > without much throttling on the consumer side - especially when the
> > > memory is reclaimable without a lot of sleeping or contention on
> > > locks etc.
> >
> > The limiting factor on the consumer side is IO. Reading a page is way
> > more costly than reclaiming it, which is why we built our isolation
> > stack starting with memory and IO control and are only now getting to
> > working on proper CPU isolation.
> >
> > > I am absolutely aware that we will never achieve a perfect isolation due
> > > to all sorts of shared data structures, lock contention and what not but
> > > this patch alone just allows spill over to unaccounted work way too
> > > easily IMHO.
> >
> > I understand your concern about CPU cycles escaping, and I share
> > it. My point is that this patch isn't adding a problem that isn't
> > already there, nor is it that much of a practical concern at the time
> > of this writing given the state of CPU isolation in general.
>
> I beg to differ here. Ppu controller should be able to isolate user
> contexts performing high limit reclaim now. Your patch is changing that
> functionality to become unaccounted for a large part and that might be
> seen as a regression for those workloads which partition the system by
> using high limit and also rely on cpu controller because workloads are
> CPU sensitive.
>
> Without the CPU controller support this patch is not complete and I do
> not see an absolute must to marge it ASAP because it is not a regression
> fix or something we cannot live without.
I think you're still thinking in a cgroup1 reality, where you would
set a memory limit in isolation and then eat a ton of CPU pushing up
against it.
In comprehensive isolation setups implemented in cgroup2, "heavily"
reclaimed containers are primarily IO bound on page faults, refaults,
writeback. The reclaim cost is a small part of it, and as I said, in a
magnitude range for which the CPU controller is currently too heavy.
We can carry this patch out of tree until the CPU controller is fixed,
but I think the reasoning to keep it out is not actually based on the
practical reality of a cgroup2 world.
^ permalink raw reply related
* Re: [PATCH v7 04/24] mm: Move readahead nr_pages check into read_pages
From: Zi Yan @ 2020-02-20 14:36 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-xfs, linux-kernel, linux-f2fs-devel, cluster-devel,
linux-mm, ocfs2-devel, linux-fsdevel, linux-ext4, linux-erofs,
linux-btrfs
In-Reply-To: <20200219210103.32400-5-willy@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]
On 19 Feb 2020, at 16:00, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Simplify the callers by moving the check for nr_pages and the BUG_ON
> into read_pages().
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> mm/readahead.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 61b15b6b9e72..9fcd4e32b62d 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -119,6 +119,9 @@ static void read_pages(struct address_space *mapping, struct file *filp,
> struct blk_plug plug;
> unsigned page_idx;
>
> + if (!nr_pages)
> + return;
> +
> blk_start_plug(&plug);
>
> if (mapping->a_ops->readpages) {
> @@ -138,6 +141,8 @@ static void read_pages(struct address_space *mapping, struct file *filp,
>
> out:
> blk_finish_plug(&plug);
> +
> + BUG_ON(!list_empty(pages));
> }
>
> /*
> @@ -180,8 +185,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * contiguous pages before continuing with the next
> * batch.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages,
> + read_pages(mapping, filp, &page_pool, nr_pages,
> gfp_mask);
> nr_pages = 0;
> continue;
> @@ -202,9 +206,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * uptodate then the caller will launch readpage again, and
> * will then handle the error.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> - BUG_ON(!list_empty(&page_pool));
> + read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> }
>
> /*
> --
> 2.25.0
Looks good to me. Thanks.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply
* Re: [PATCH] mm: memcontrol: asynchronous reclaim for memory.high
From: Johannes Weiner @ 2020-02-20 14:41 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Tejun Heo, Roman Gushchin,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, cgroups-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, kernel-team-b10kYP2dOMg
In-Reply-To: <20200220094639.GD20509-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On Thu, Feb 20, 2020 at 10:46:39AM +0100, Michal Hocko wrote:
> On Wed 19-02-20 16:17:35, Johannes Weiner wrote:
> > On Wed, Feb 19, 2020 at 08:53:32PM +0100, Michal Hocko wrote:
> > > On Wed 19-02-20 14:16:18, Johannes Weiner wrote:
> [...]
> > > > [ This is generally work in process: for example, if you isolate
> > > > workloads with memory.low, kswapd cpu time isn't accounted to the
> > > > cgroup that causes it. Swap IO issued by kswapd isn't accounted to
> > > > the group that is getting swapped.
> > >
> > > Well, kswapd is a system activity and as such it is acceptable that it
> > > is accounted to the system. But in this case we are talking about a
> > > memcg configuration which influences all other workloads by stealing CPU
> > > cycles from them
> >
> > From a user perspective this isn't a meaningful distinction.
> >
> > If I partition my memory among containers and one cgroup is acting
> > out, I would want the culprit to be charged for the cpu cycles the
> > reclaim is causing. Whether I divide my machine up using memory.low or
> > using memory.max doesn't really matter: I'm choosing between the two
> > based on a *memory policy* I want to implement - work-conserving vs
> > non-conserving. I shouldn't have to worry about the kernel tracking
> > CPU cycles properly in the respective implementations of these knobs.
> >
> > So kswapd is very much a cgroup-attributable activity, *especially* if
> > I'm using memory.low to delineate different memory domains.
>
> While I understand what you are saying I do not think this is easily
> achievable with the current implementation. The biggest problem I can
> see is that you do not have a clear information who to charge for
> the memory shortage on a particular NUMA node with a pure low limit
> based balancing because the limit is not NUMA aware. Besides that the
> origin of the memory pressure might be outside of any memcg. You can
> punish/account all memcgs in excess in some manner, e.g. proportionally
> to their size/excess but I am not really sure how fair that will
> be. Sounds like an interesting project but also sounds like tangent to
> this patch.
>
> High/Max limits are quite different because they are dealing with
> the internal memory pressure and you can attribute it to the
> cgroup/hierarchy which is in excess. There is a clear domain to reclaim
> from. This is an easier model to reason about IMHO.
They're not different. memory.low is just a usage limit that happens
to be enforcecd lazily rather than immediately.
If I'm setting memory.high or memory.max and I allocate beyond it, my
memory will be reclaimed with the limit as the target.
If I'm setting memory.low and I allocate beyond it, my memory will
eventually be reclaimed with the limit as the target.
In either case, the cgroup who allocated the memory that is being
reclaimed is the one obviously responsible for the reclaim work. Why
would the time of limit enforcement change that?
If on the other hand an allocation reclaims you below your limit, such
as can happen with a NUMA-bound allocation, whether it's high, max, or
low, then that's their cost to pay. But it's not really that important
what we do in that case - the memcg settings aren't NUMA aware so that
whole scenario is out of the purview of the controller anyway.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index d6085115c7f2..24fe6e9e64b1 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2651,6 +2651,7 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
memcg = mem_cgroup_iter(target_memcg, NULL, NULL);
do {
struct lruvec *lruvec = mem_cgroup_lruvec(memcg, pgdat);
+ bool account_cpu = current_is_kswapd() || current_work();
unsigned long reclaimed;
unsigned long scanned;
@@ -2673,6 +2674,7 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
continue;
}
memcg_memory_event(memcg, MEMCG_LOW);
+ account_cpu = false;
break;
case MEMCG_PROT_NONE:
/*
@@ -2688,11 +2690,17 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
reclaimed = sc->nr_reclaimed;
scanned = sc->nr_scanned;
+ if (account_cpu)
+ use_cpu_of_cgroup(memcg->css.cgroup);
+
shrink_lruvec(lruvec, sc);
shrink_slab(sc->gfp_mask, pgdat->node_id, memcg,
sc->priority);
+ if (account_cpu)
+ unuse_cpu_of_cgroup();
+
/* Record the group's reclaim efficiency */
vmpressure(sc->gfp_mask, memcg, false,
sc->nr_scanned - scanned,
> > > without much throttling on the consumer side - especially when the
> > > memory is reclaimable without a lot of sleeping or contention on
> > > locks etc.
> >
> > The limiting factor on the consumer side is IO. Reading a page is way
> > more costly than reclaiming it, which is why we built our isolation
> > stack starting with memory and IO control and are only now getting to
> > working on proper CPU isolation.
> >
> > > I am absolutely aware that we will never achieve a perfect isolation due
> > > to all sorts of shared data structures, lock contention and what not but
> > > this patch alone just allows spill over to unaccounted work way too
> > > easily IMHO.
> >
> > I understand your concern about CPU cycles escaping, and I share
> > it. My point is that this patch isn't adding a problem that isn't
> > already there, nor is it that much of a practical concern at the time
> > of this writing given the state of CPU isolation in general.
>
> I beg to differ here. Ppu controller should be able to isolate user
> contexts performing high limit reclaim now. Your patch is changing that
> functionality to become unaccounted for a large part and that might be
> seen as a regression for those workloads which partition the system by
> using high limit and also rely on cpu controller because workloads are
> CPU sensitive.
>
> Without the CPU controller support this patch is not complete and I do
> not see an absolute must to marge it ASAP because it is not a regression
> fix or something we cannot live without.
I think you're still thinking in a cgroup1 reality, where you would
set a memory limit in isolation and then eat a ton of CPU pushing up
against it.
In comprehensive isolation setups implemented in cgroup2, "heavily"
reclaimed containers are primarily IO bound on page faults, refaults,
writeback. The reclaim cost is a small part of it, and as I said, in a
magnitude range for which the CPU controller is currently too heavy.
We can carry this patch out of tree until the CPU controller is fixed,
but I think the reasoning to keep it out is not actually based on the
practical reality of a cgroup2 world.
^ permalink raw reply related
* Re: [PATCH] gpio: mockup: coding-style fix
From: Linus Walleij @ 2020-02-20 14:41 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kent Gibson, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org, Bartosz Golaszewski
In-Reply-To: <20200210155059.29609-1-brgl@bgdev.pl>
On Mon, Feb 10, 2020 at 4:51 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The indentation is wrong in gpio_mockup_apply_pull(). This patch makes
> the code more readable.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> This fixes another indentation error introduced in v5.5 that I missed before.
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: w83627ehf crash in 5.6.0-rc2-00055-gca7e1fd1026c
From: Guenter Roeck @ 2020-02-20 14:40 UTC (permalink / raw)
To: Dr. David Alan Gilbert, Meelis Roos; +Cc: linux-hwmon, LKML, Chen Zhou
In-Reply-To: <20200220135709.GB18071@gallifrey>
On 2/20/20 5:57 AM, Dr. David Alan Gilbert wrote:
> * Meelis Roos (mroos@linux.ee) wrote:
>>> It looks like not all chips have temp_label, so I think we need to change w83627ehf_is_visible
>>> which has:
>>>
>>> if (attr == hwmon_temp_input || attr == hwmon_temp_label)
>>> return 0444;
>>>
>>> to
>>> if (attr == hwmon_temp_input)
>>> return 0444;
>>> if (attr == hwmon_temp_label) {
>>> if (data->temp_label)
>>> return 0444;
>>> else
>>> return 0;
Nitpick: else after return isn't necessary. Too bad I didn't notice that before;
static analyzers will have a field day :-)
>>> }
>>>
>>> Does that work for you?
>> Yes, it works - sensors are displayed as they should be, with nothing in dmesg.
>>
>> Thank you for so quick response!
>
> Great, I need to turn that into a proper patch; (I might need to wait till
> Saturday for that, although if someone needs it before then please shout).
>
We'll want this fixed in the next stable release candidate, so I wrote one up
and submitted it.
Thanks,
Guenter
^ permalink raw reply
* RE: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints
From: David Laight @ 2020-02-20 14:39 UTC (permalink / raw)
To: 'chris hyser', Parth Shah, vincent.guittot@linaro.org,
patrick.bellasi@matbug.net, valentin.schneider@arm.com,
dhaval.giani@oracle.com, dietmar.eggemann@arm.com
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
mingo@redhat.com, qais.yousef@arm.com, pavel@ucw.cz,
qperret@qperret.net, pjt@google.com, tj@kernel.org
In-Reply-To: <10f42efa-3750-491a-74fe-d84c9c4924e3@oracle.com>
From: chris hyser <chris.hyser@oracle.com>
> Sent: 19 February 2020 17:17
>
> On 2/19/20 6:18 AM, David Laight wrote:
> > From: chris hyser
> >> Sent: 18 February 2020 23:00
> > ...
> >> All, I was asked to take a look at the original latency_nice patchset.
> >> First, to clarify objectives, Oracle is not
> >> interested in trading throughput for latency.
> >> What we found is that the DB has specific tasks which do very little but
> >> need to do this as absolutely quickly as possible, ie extreme latency
> >> sensitivity. Second, the key to latency reduction
> >> in the task wakeup path seems to be limiting variations of "idle cpu" search.
> >> The latter particularly interests me as an example of "platform size
> >> based latency" which I believe to be important given all the varying size
> >> VMs and containers.
> >
> > From my experiments there are a few things that seem to affect latency
> > of waking up real time (sched fifo) tasks on a normal kernel:
>
> Sorry. I was only ever talking about sched_other as per the original patchset. I realize the term
> extreme latency
> sensitivity may have caused confusion. What that means to DB people is no doubt different than audio
> people. :-)
Shorter lines.....
ISTM you are making some already complicated code even more complex.
Better to make it simpler instead.
If you need a thread to run as soon as possible after it is woken
why not use the RT scheduler (eg SCHED_FIFO) that is what it is for.
If there are delays finding an idle cpu to migrate a process to
(especially on systems with large numbers of cpu) then that is a
general problem that can be addressed without extra knobs.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.