* Re: 484611357c19 introduces arbitrary kernel write bug (root-only)
From: Josef Bacik @ 2016-11-09 2:02 UTC (permalink / raw)
To: Jann Horn, Daniel Borkmann, Alexei Starovoitov, David S. Miller
Cc: security, netdev
In-Reply-To: <CAG48ez0mP4xwv6vnKRJ+rcdXYyA1wGnCWsbkKUgWGSBbMtgFMw@mail.gmail.com>
On 11/08/2016 07:23 PM, Jann Horn wrote:
> In 484611357c19 (not in any stable kernel yet), functionality is
> introduced that allows root (and afaics nobody else, since nobody else
> is allowed to perform pointer arithmetic) to basically write to (and
> read from) arbitrary kernel memory. There are multiple bugs in the
> validation logic:
>
> - A bitwise AND of values in the ranges [a,b] and [c,d] is assumed to
> always result in a value
> >= a&b. However, for the combination of ranges [1,1] and [1,2],
> this calculates a minimum of 1
> while actually, 1&2 is zero. This is the bug that my crasher
> (below) triggers.
Ugh crap. I had this logic right before, but changed it to deal with the case
of -value & -value which would make the min_value -value. Instead if min and
max are both positive then the min should be 0. I'll fix this up and add a
testcase, nice catch.
> - a%b is assumed to always be smaller than b-1. However, for b==0,
> this will calculate an upper
> limit of -1 while the values will actually always be zero.
Yup you're right.
> - I'm not sure about this, but I think that, when only one end of the
> range is bounded, the logic will
> incorrectly also treat the other end as a bounded, and because of
> the usage of bound
> placeholders that are smaller than the actual maximum values, this
> could be used to perform
> out-of-bounds accesses.
Yeah I think you're right, if we have register A min bounded at say
REGISTER_MAX_VALUE, and then have register B not min bounded at all so we
default to the REGISTER_MIN_VALUE we and did a add we could end up thinking the
minimum was 0, when it could be anything. I'll fix this as well.
Thanks for looking at all this, I'll get this fixed up in the morning with test
cases and send it out,
Josef
^ permalink raw reply
* Re: [PATCH 0/2] extend page_track for external usage
From: Zhenyu Wang @ 2016-11-09 2:03 UTC (permalink / raw)
To: Daniel Vetter, Paolo Bonzini
Cc: Jike Song, rkrcmar, kvm, Jani Nikula, Alex Williamson, intel-gfx
In-Reply-To: <CAKMK7uG7+k_=qg7ZWy_WQN=vuCpm3wrz2S=Pm57+ojOa71zx-w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]
On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote:
> >> Paolo, for this case, do you think it's feasible we pick them through
> >> drm/i915 merge path? As currently initial KVMGT patch sets require these
> >> exported symbols, that's why I ask how we should handle this dependency.
> >
> > Then it's actually a good thing that I dropped from kvm/queue! You can
> > certainly include these patches, but please do that through a topic branch.
> >
> > I've prepared a branch for you
> > (git://git.kernel.org/pub/scm/virt/kvm/kvm.git branch for-kvmgt). Once
> > Linus processes my outstanding pull request, the branch will only
> > include the three page-tracking patches. Please pull that topic branch
> > into your own branch, and ensure you have a merge commit when you send
> > the pull request to Daniel. The merge commit ensures that the workflow
> > was correct; use --no-ff if necessary.
> >
> > You can do the same for Jike's patches for the KVM-VFIO device, when
> > Alex reviews them, and I suppose you'll need a topic branch for mdev
> > too? I didn't know that KVMGT was planned for 4.10. In the future,
> > let's synchronize ahead so that we can prepare topic branches for you.
>
> Ok, back from the useless wifi at plumbers, I can mail again. Zhenyu
> confirmed on irc that the initial code pile only needs this. For the
> cross-maintainer topic tree I prefer a formal pull request with stable
> tag. Please also cc: intel-gfx on that, since I plan to merge that one
> directly into i915.
>
Paolo, could you help to do this for Daniel? Daniel would like to merge
current KVMGT required change for KVM directly, then I'd base KVMGT change
on that.
p.s, Daniel gave me this example https://lists.freedesktop.org/archives/intel-gfx/2015-December/082600.html,
which was for audio change merge.
Thanks
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
^ permalink raw reply
* Re: BUG: Hung task timeouts in for-4.10/dio
From: Jens Axboe @ 2016-11-09 2:02 UTC (permalink / raw)
To: Damien Le Moal, Christoph Hellwig
Cc: Logan Gunthorpe, linux-block, Mike Snitzer
In-Reply-To: <a6d1d368-04a2-e999-a610-abd96add81a9@fb.com>
On 11/08/2016 06:28 PM, Jens Axboe wrote:
> On 11/08/2016 06:25 PM, Damien Le Moal wrote:
>>
>> On 11/9/16 10:09, Christoph Hellwig wrote:
>>> Ok, sounds like I'm really the one to blame. I'll see if I can
>>> find a reproducer. Damien, or you using device mapper on that
>>> system?
>>
>> No LVM/md/dm used on boot. Mount is direct to the block device (SSDs
>> with ext4). The devices are simple SSDs, so no polling involved.
>>
>> The hangs suspiciously look like they are either background write or
>> flush. So I was wondering if it is indeed related to FLUSH/FUA as Logan
>> suggested or the background write stuff, rather than the direct-IO
>> optimization & polling.
>
> The background write stuff is not in either of those branches, plus the
> backtrace would have looked different. Yours is showing us waiting for a
> request. I don't think it's the direct-io or polling code, it looks like
> a generic issue.
>
>> Will try again/bisect to see if I can get more info.
>
> Maybe try and revert the one that Logan pointed his finger at, if that
> is doable.
It smells like an accounting error. One thing that I don't like with the
current scheme is the implicit knowledge that certain flags imply sync
as well. If we clear any of those flags, then we screw up accounting at
the end.
Does this make a difference?
diff --git a/block/blk-flush.c b/block/blk-flush.c
index c486b7aa62ee..d70983e28115 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -395,6 +395,8 @@ void blk_insert_flush(struct request *rq)
if (!(fflags & (1UL << QUEUE_FLAG_FUA)))
rq->cmd_flags &= ~REQ_FUA;
+ rq->cmd_flags |= REQ_SYNC;
+
/*
* An empty flush handed down from a stacking driver may
* translate into nothing if the underlying device does not
--
Jens Axboe
^ permalink raw reply related
* make-wifi-fast linuxplumbers talk summarized on lwn.net
From: Dave Taht @ 2016-11-09 1:59 UTC (permalink / raw)
To: linux-wireless, make-wifi-fast, bloat
and available here:
https://lwn.net/SubscriberLink/705884/1bdb9c4aa048b0d5/
After the talk I discussed with several folk about applying the same
debloating techniques to other chipsets.
I don't remember, unfortunately, who all those folk were, nor the
candidate chipsets!
--=20
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* Re: [PATCH v2] btrfs-progs: send-test: add checking of clone-src option
From: Tsutomu Itoh @ 2016-11-09 1:57 UTC (permalink / raw)
To: Qu Wenruo; +Cc: dsterba, linux-btrfs
In-Reply-To: <f66ad5e8-5443-c52a-0727-111959183643@cn.fujitsu.com>
On 2016/11/09 10:39, Qu Wenruo wrote:
>
>
> At 11/09/2016 09:25 AM, Tsutomu Itoh wrote:
>> Sending stream size of clone-src(-c) option is checked.
>> Fixed by "btrfs-progs: send: fix handling of -c option".
>>
>> Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
>> ---
>> V2: old sending stream image is used
>> ---
>> .../016-send-clone-src/send-stream-v4.8.2.img | Bin 0 -> 6299778 bytes
>
> The image seems quite large.
>
> How about compressing it? And the script seems only checking the size of the file, not the content.
>
> So it seems that we don't even need to upload the file.
Certainly, only the size of the image file is necessary, and we don't need image file.
But I want to keep the image file as a record.
Therefore, I'll post the version that compresses the image file soon.
Thanks,
Tsutomu
>
> Thanks,
> Qu
>
>> tests/misc-tests/016-send-clone-src/test.sh | 49 +++++++++++++++++++++
>> 2 files changed, 49 insertions(+)
>> create mode 100644 tests/misc-tests/016-send-clone-src/send-stream-v4.8.2.img
>> create mode 100755 tests/misc-tests/016-send-clone-src/test.sh
>>
(snip)
^ permalink raw reply
* RE: [PATCH v4] PM/devfreq: add suspend frequency support
From: MyungJoo Ham @ 2016-11-09 1:53 UTC (permalink / raw)
To: Lin Huang
Cc: Chanwoo Choi, dianders@chromium.org,
linux-rockchip@lists.infradead.org, linux-pm@vger.kernel.org,
dbasehore@chromium.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CGME20161108091840epcas3p21af60a1b0a4867306366633427567dc3@epcas3p2.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 5428 bytes --]
> Add suspend frequency support and if needed set it to
> the frequency obtained from the suspend opp (can be defined
> using opp-v2 bindings and is optional).
>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - use update_devfreq() instead devfreq_update_status()
> Changes in v3:
> - fix build error
> Changes in v4:
> - move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
>
> drivers/devfreq/devfreq.c | 15 +++++++++++++--
> drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
> include/linux/devfreq.h | 9 +++++++++
> 3 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index bf3ea76..d9d56e1 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -363,7 +363,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
> mutex_unlock(&devfreq->lock);
> return;
> }
> -
> + if (devfreq->suspend_freq) {
> + update_devfreq(devfreq);
> + devfreq->suspend_flag = true;
+ } else {
+ devfreq_update_status(devfreq, devfreq->previous_freq);
+ }
- devfreq_update_status(devfreq, devfreq->previous_freq);
update_devfreq() calls devfreq_update_status.
So let's call it only when update_devfreq is not called.
> devfreq->stop_polling = true;
> mutex_unlock(&devfreq->lock);
> @@ -394,7 +397,8 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
>
> devfreq->last_stat_updated = jiffies;
> devfreq->stop_polling = false;
> -
> + if (devfreq->suspend_freq)
> + devfreq->suspend_flag = false;
> if (devfreq->profile->get_cur_freq &&
> !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
> devfreq->previous_freq = freq;
> @@ -528,6 +532,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
> struct devfreq *devfreq;
> struct devfreq_governor *governor;
> int err = 0;
> + struct dev_pm_opp *suspend_opp;
>
> if (!dev || !profile || !governor_name) {
> dev_err(dev, "%s: Invalid parameters.\n", __func__);
> @@ -563,6 +568,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq->data = data;
> devfreq->nb.notifier_call = devfreq_notifier_call;
>
> + rcu_read_lock();
> + suspend_opp = dev_pm_opp_get_suspend_opp(dev);
> + if (suspend_opp)
> + devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
> + rcu_read_unlock();
> +
> if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
> mutex_unlock(&devfreq->lock);
> devfreq_set_freq_table(devfreq);
> diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
> index ae72ba5..84b3ce1 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
> struct devfreq_simple_ondemand_data *data = df->data;
> unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
>
> + /*
> + * if devfreq in suspend status and have suspend_freq,
> + * the frequency need to set to suspend_freq
> + */
> + if (df->suspend_flag) {
> + *freq = df->suspend_freq;
> + return 0;
> + }
> +
If this is because of the case when devfreq_simple_ondemand_func() is called
before cancel_delayed_work_sync() in devfreq_monitor_suspend() and
after update_devfreq() in devfreq_monitor_suspend(),
you can use devfreq->stop_polling (and move devfreq->stop_polling = true; a bit earlier).
You do not need to introduce yet another variable, suspend_flag, in the devfreq struct.
The semantics of "stop_polling" fits the purpose well enough.
> err = devfreq_update_stats(df);
> if (err)
> return err;
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 2de4e2e..c463ae1 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -172,6 +172,7 @@ struct devfreq {
> struct delayed_work work;
>
> unsigned long previous_freq;
> + unsigned long suspend_freq;
> struct devfreq_dev_status last_status;
>
> void *data; /* private data for governors */
> @@ -179,6 +180,7 @@ struct devfreq {
> unsigned long min_freq;
> unsigned long max_freq;
> bool stop_polling;
> + bool suspend_flag;
>
> /* information for device frequency transition */
> unsigned int total_trans;
> @@ -214,6 +216,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
> /* Helper functions for devfreq user device driver with OPP. */
> extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
> unsigned long *freq, u32 flags);
> +extern void devfreq_opp_get_suspend_opp(struct device *dev,
> + struct devfreq *devfreq);
No more required.
> extern int devfreq_register_opp_notifier(struct device *dev,
> struct devfreq *devfreq);
> extern int devfreq_unregister_opp_notifier(struct device *dev,
> @@ -348,6 +352,11 @@ static inline struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
> return ERR_PTR(-EINVAL);
> }
>
> +static inline void devfreq_opp_get_suspend_opp(struct device *dev,
> + struct devfreq *devfreq)
> +{
> +}
> +
No more required.
> static inline int devfreq_register_opp_notifier(struct device *dev,
> struct devfreq *devfreq)
> {
> --
> 2.6.6
>
>
>
^ permalink raw reply
* RE: [PATCH v4] PM/devfreq: add suspend frequency support
From: MyungJoo Ham @ 2016-11-09 1:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161108091840epcas3p21af60a1b0a4867306366633427567dc3@epcas3p2.samsung.com>
> Add suspend frequency support and if needed set it to
> the frequency obtained from the suspend opp (can be defined
> using opp-v2 bindings and is optional).
>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - use update_devfreq() instead devfreq_update_status()
> Changes in v3:
> - fix build error
> Changes in v4:
> - move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
>
> drivers/devfreq/devfreq.c | 15 +++++++++++++--
> drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
> include/linux/devfreq.h | 9 +++++++++
> 3 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index bf3ea76..d9d56e1 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -363,7 +363,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
> mutex_unlock(&devfreq->lock);
> return;
> }
> -
> + if (devfreq->suspend_freq) {
> + update_devfreq(devfreq);
> + devfreq->suspend_flag = true;
+ } else {
+ devfreq_update_status(devfreq, devfreq->previous_freq);
+ }
- devfreq_update_status(devfreq, devfreq->previous_freq);
update_devfreq() calls devfreq_update_status.
So let's call it only when update_devfreq is not called.
> devfreq->stop_polling = true;
> mutex_unlock(&devfreq->lock);
> @@ -394,7 +397,8 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
>
> devfreq->last_stat_updated = jiffies;
> devfreq->stop_polling = false;
> -
> + if (devfreq->suspend_freq)
> + devfreq->suspend_flag = false;
> if (devfreq->profile->get_cur_freq &&
> !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
> devfreq->previous_freq = freq;
> @@ -528,6 +532,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
> struct devfreq *devfreq;
> struct devfreq_governor *governor;
> int err = 0;
> + struct dev_pm_opp *suspend_opp;
>
> if (!dev || !profile || !governor_name) {
> dev_err(dev, "%s: Invalid parameters.\n", __func__);
> @@ -563,6 +568,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq->data = data;
> devfreq->nb.notifier_call = devfreq_notifier_call;
>
> + rcu_read_lock();
> + suspend_opp = dev_pm_opp_get_suspend_opp(dev);
> + if (suspend_opp)
> + devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
> + rcu_read_unlock();
> +
> if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
> mutex_unlock(&devfreq->lock);
> devfreq_set_freq_table(devfreq);
> diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
> index ae72ba5..84b3ce1 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
> struct devfreq_simple_ondemand_data *data = df->data;
> unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
>
> + /*
> + * if devfreq in suspend status and have suspend_freq,
> + * the frequency need to set to suspend_freq
> + */
> + if (df->suspend_flag) {
> + *freq = df->suspend_freq;
> + return 0;
> + }
> +
If this is because of the case when devfreq_simple_ondemand_func() is called
before cancel_delayed_work_sync() in devfreq_monitor_suspend() and
after update_devfreq() in devfreq_monitor_suspend(),
you can use devfreq->stop_polling (and move devfreq->stop_polling = true; a bit earlier).
You do not need to introduce yet another variable, suspend_flag, in the devfreq struct.
The semantics of "stop_polling" fits the purpose well enough.
> err = devfreq_update_stats(df);
> if (err)
> return err;
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 2de4e2e..c463ae1 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -172,6 +172,7 @@ struct devfreq {
> struct delayed_work work;
>
> unsigned long previous_freq;
> + unsigned long suspend_freq;
> struct devfreq_dev_status last_status;
>
> void *data; /* private data for governors */
> @@ -179,6 +180,7 @@ struct devfreq {
> unsigned long min_freq;
> unsigned long max_freq;
> bool stop_polling;
> + bool suspend_flag;
>
> /* information for device frequency transition */
> unsigned int total_trans;
> @@ -214,6 +216,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
> /* Helper functions for devfreq user device driver with OPP. */
> extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
> unsigned long *freq, u32 flags);
> +extern void devfreq_opp_get_suspend_opp(struct device *dev,
> + struct devfreq *devfreq);
No more required.
> extern int devfreq_register_opp_notifier(struct device *dev,
> struct devfreq *devfreq);
> extern int devfreq_unregister_opp_notifier(struct device *dev,
> @@ -348,6 +352,11 @@ static inline struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
> return ERR_PTR(-EINVAL);
> }
>
> +static inline void devfreq_opp_get_suspend_opp(struct device *dev,
> + struct devfreq *devfreq)
> +{
> +}
> +
No more required.
> static inline int devfreq_register_opp_notifier(struct device *dev,
> struct devfreq *devfreq)
> {
> --
> 2.6.6
>
>
>
^ permalink raw reply
* Reminder (US DAYLIGHT SAVING TIME CHANGE!): Toaster Weekly Meeting: 1-800-730-2996x7494529#
From: Reyna, David @ 2016-11-09 1:53 UTC (permalink / raw)
To: toaster@yoctoproject.org
[-- Attachment #1: Type: text/plain, Size: 2993 bytes --]
Join the weekly call for Toaster contributors.
Wednesday, Nov. 2, 2016 8:00 AM US Pacific Time
Call Details:
Tel: 1-800-730-2996
Passcode: 7494529#
The international conference numbers can be found below:
Meeting Order:
* Status updates
* Bug triage
* Action items and Opens
Triage bugs:
https://wiki.yoctoproject.org/wiki/Bug_Triage#YP_Toaster_Bugs_needing_Triage
Link to the wiki docs:
https://wiki.yoctoproject.org/wiki/Toaster
https://wiki.yoctoproject.org/wiki/Contribute_to_Toaster
https://wiki.yoctoproject.org/wiki/Toaster_and_bitbake_communications
The international phone numbers can be found here and below:
https://conf.cfer.com/portal.html?view=gos&onestepadd=false&nouserregsearch=false&autocreatesub=false
Global conference numbers:
Country Toll free number Toll number
ARGENTINA(ARG) 08008000015
AUSTRALIA(AUS) 1800706804 0390084305
AUSTRIA(AUT) 080088663241 1253021555
BELGIUM(BEL) 080039108 027924540
BRAZIL(BRA) 08000226021 01149497409
CANADA(CAN) 8007302996
CHILE(CHL) 12300200882 225994972
CHINA UNIFIED(CHU) 8008195022 4006929850
CZECH REPUBLIC(CZE) 800221225 225986504
DENMARK(DNK) 80888614 46944199
FINLAND(FIN) 0800773452 0923194990
FRANCE(FRA) 0800944161 0170394800
GERMANY(DEU) 08005890086 08922061395
HONG KONG(HKG) 800930494 30508787
INDIA(IND) 0008001008228
IRELAND(IRL) 1800949140 16530814
ISRAEL(ISR) 1809257987 37630335
ITALY(ITA) 800182739 0200617518
JAPAN(JPN) 00531190089 0345808178
MALAYSIA(MYS) 1800816012 0377240072
MEXICO(MEX) 0018005147990 5547772289
NORWAY(NOR) 80056455 21033688
PERU(PER) 800835193
PHILIPPINES(PHL) 180011101341
POLAND(POL) 008001124357 222953518
ROMANIA(ROM) 0800895593 800896685 318110774
RUSSIAN FEDERATION(RUS) 81080029611012
SINGAPORE(SGP) 8001012629 65792804
SLOVENIA(SVN) 080081574
SOUTH AFRICA(ZAF) 0800988879 218197049
SOUTH KOREA(KOR) 00798142061162 0234832820
SPAIN(ESP) 900803731 917699430
SWEDEN(SWE) 0201708451 0114966439
SWITZERLAND(CHE) 0800740028
TAIWAN(TWN) 0809083901 0226567358
UNITED KINGDOM(GBR) 08004960069 02079041865
UNITED STATES(USA) 8007302996 9139049836
URUGUAY(URY) 00040190558
[-- Attachment #2: Type: text/html, Size: 16969 bytes --]
^ permalink raw reply
* Re: btrfs support for filesystems >8TB on 32bit architectures
From: Qu Wenruo @ 2016-11-09 1:50 UTC (permalink / raw)
To: Marc MERLIN; +Cc: David Sterba, Hugo Mills, linux-btrfs
In-Reply-To: <20161108152429.GC24297@merlins.org>
At 11/08/2016 11:24 PM, Marc MERLIN wrote:
> On Tue, Nov 08, 2016 at 09:17:43AM +0800, Qu Wenruo wrote:
>>
>>
>> At 11/08/2016 09:06 AM, Marc MERLIN wrote:
>>> On Tue, Nov 08, 2016 at 08:43:34AM +0800, Qu Wenruo wrote:
>>>> That's strange, balance is done completely in kernel space.
>>>>
>>>> Unless we're calling vfs_* function we won't go through the extra check.
>>>>
>>>> What's the error reported?
>>>
>>> See below. Note however that is may be because btrfs received messed up the
>>> filesystem first.
>>
>> If receive can easily screw up the fs, then fsstress can also screw up
>> btrfs easily.
>>
>> So I didn't think that's the case. (Several years ago it's possible)
>
> So now I'm even more confused. I put the array back in my 64bit system and
> check --repair comes back clean, but scrub does not. Is that supposed to be possible?
Yeah, quite possible!
The truth is, current btrfs check only checks:
1) Metadata
while --check-data-csum option will check data, but still
follow the restriction 3).
2) Crossing reference of metadata (contents of metadata)
3) The first good mirror/backup
So quite a lot of problems can't be detected by btrfs check:
1) Data corruption (csum mismatch)
2) 2nd mirror corruption(DUP/RAID0/10) or parity error(RAID5/6)
For btrfsck to check all mirror and data, you could try out-of-tree
offline scrub patchset:
https://github.com/adam900710/btrfs-progs/tree/fsck_scrub
Which implements the kernel scrub equivalent in btrfs-progs.
Thanks,
Qu
>
> gargamel:~# btrfs check -p --repair /dev/mapper/crypt_bcache2 2>&1 | tee /mnt/dshelf1/other/btrfs2
> enabling repair mode
> Checking filesystem on /dev/mapper/crypt_bcache2
> UUID: 6692cf4c-93d9-438c-ac30-5db6381dc4f2
> checking extents [.]
> Fixed 0 roots.
> cache and super generation don't match, space cache will be invalidated
> checking fs roots [o]
> checking csums
> checking root refs
> found 14622791987200 bytes used err is 0
> total csum bytes: 14200176492
> total tree bytes: 78239416320
> total fs tree bytes: 59524497408
> total extent tree bytes: 3236872192
> btree space waste bytes: 10068589919
> file data blocks allocated: 18101311373312
> referenced 18038641020928
>
> Nov 8 06:55:40 gargamel kernel: [35631.988896] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 513, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988897] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 514, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988899] BTRFS warning (device dm-6): checksum error at logical 27885961216 on dev /dev/mapper/crypt_bcache2, sector 56578304, root 9461, inode 45837, offset 15459172352, length 4096, links 1 (path: system/mlocate/mlocate.db)
> Nov 8 06:55:40 gargamel kernel: [35631.988900] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 515, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988903] BTRFS warning (device dm-6): checksum error at logical 27887534080 on dev /dev/mapper/crypt_bcache2, sector 56581376, root 9461, inode 45837, offset 15460745216, length 4096, links 1 (path: system/mlocate/mlocate.db)
> Nov 8 06:55:40 gargamel kernel: [35631.988904] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27887009792 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988905] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27886878720 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988906] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 516, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988907] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27887837184 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988908] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 517, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988909] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 518, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988910] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27885830144 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988911] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27885961216 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988912] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27887534080 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988882] BTRFS warning (device dm-6): checksum error at logical 27887403008 on dev /dev/mapper/crypt_bcache2, sector 56581120, root 9461, inode 45837, offset 15460614144, length 4096, links 1 (path: system/mlocate/mlocate.db)
> Nov 8 06:55:40 gargamel kernel: [35631.988885] BTRFS warning (device dm-6): checksum error at logical 27887009792 on dev /dev/mapper/crypt_bcache2, sector 56580352, root 9461, inode 45837, offset 15460220928, length 4096, links 1 (path: system/mlocate/mlocate.db)
> Nov 8 06:55:40 gargamel kernel: [35631.988887] BTRFS warning (device dm-6): checksum error at logical 27886878720 on dev /dev/mapper/crypt_bcache2, sector 56580096, root 9461, inode 45837, offset 15460089856, length 4096, links 1 (path: system/mlocate/mlocate.db)
> Nov 8 06:55:40 gargamel kernel: [35631.988890] BTRFS warning (device dm-6): checksum error at logical 27887837184 on dev /dev/mapper/crypt_bcache2, sector 56581968, root 9461, inode 45837, offset 15461048320, length 4096, links 1 (path: system/mlocate/mlocate.db)
> Nov 8 06:55:40 gargamel kernel: [35631.988895] BTRFS warning (device dm-6): checksum error at logical 27885830144 on dev /dev/mapper/crypt_bcache2, sector 56578048, root 9461, inode 45837, offset 15459041280, length 4096, links 1 (path: system/mlocate/mlocate.db)
> Nov 8 06:55:40 gargamel kernel: [35631.988896] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 513, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988897] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 514, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988899] BTRFS warning (device dm-6): checksum error at logical 27885961216 on dev /dev/mapper/crypt_bcache2, sector 56578304, root 9461, inode 45837, offset 15459172352, length 4096, links 1 (path: system/mlocate/mlocate.db)
> Nov 8 06:55:40 gargamel kernel: [35631.988900] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 515, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988903] BTRFS warning (device dm-6): checksum error at logical 27887534080 on dev /dev/mapper/crypt_bcache2, sector 56581376, root 9461, inode 45837, offset 15460745216, length 4096, links 1 (path: system/mlocate/mlocate.db)
> Nov 8 06:55:40 gargamel kernel: [35631.988904] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27887009792 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988905] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27886878720 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988906] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 516, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988907] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27887837184 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988908] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 517, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988909] BTRFS error (device dm-6): bdev /dev/mapper/crypt_bcache2 errs: wr 0, rd 0, flush 0, corrupt 518, gen 0
> Nov 8 06:55:40 gargamel kernel: [35631.988910] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27885830144 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988911] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27885961216 on dev /dev/mapper/crypt_bcache2
> Nov 8 06:55:40 gargamel kernel: [35631.988912] BTRFS error (device dm-6): unable to fixup (regular) error at logical 27887534080 on dev /dev/mapper/crypt_bcache2
>
>
>
>>>
>>> BTRFS info (device dm-0): use zlib compression
>>> BTRFS info (device dm-0): disk space caching is enabled
>>> BTRFS info (device dm-0): has skinny extents
>>> BTRFS info (device dm-0): bdev /dev/mapper/crypt_bcache0 errs: wr 0, rd 0,
>>> flush 0, corrupt 512, gen 0
>>> BTRFS info (device dm-0): detected SSD devices, enabling SSD mode
>>> BTRFS info (device dm-0): continuing balance
>>> BTRFS info (device dm-0): The free space cache file (1593999097856) is
>>> invalid. skip it
>>>
>>> BTRFS info (device dm-0): The free space cache file (1671308509184) is
>>> invalid. skip it
>>>
>>> BTRFS info (device dm-0): relocating block group 13835461197824 flags 34
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 22825 at fs/btrfs/disk-io.c:520
>>> btree_csum_one_bio.isra.39+0xf7/0x100
>>
>> Dirty tree block's bytenr doesn't match with page's logical.
>> It seems that the tree block is not up-to-date, maybe corrupted.
>>
>> Seems not related to the 8T limit.
>>
>> Could you please add pr_info() to print out the 'found_start' and 'start'?
>> Also I'm not familiar with this code, the number may has a clue to show
>> what's going wrong.
>>
>> Thanks,
>> Qu
>>
>>> Modules linked in: bcache configs rc_hauppauge ir_kbd_i2c
>>> cpufreq_userspace cpufreq_powersave cpufreq_conservative autofs4
>>> snd_hda_codec_hdmi joydev snd_hda_codec_realtek snd_hda_codec_generic
>>> tuner_simple tuner_types tda9887 snd_hda_intel snd_hda_codec snd_hda_core
>>> snd_hwdep tda8290 coretemp snd_pcm_oss snd_mixer_oss tuner snd_pcm msp3400
>>> snd_seq_midi snd_seq_midi_event firewire_sbp2 saa7127 snd_rawmidi
>>> hwmon_vid dm_crypt dm_mod saa7115 snd_seq bttv hid_generic snd_seq_device
>>> snd_timer ehci_pci ivtv tea575x videobuf_dma_sg rc_core videobuf_core
>>> input_leds tveeprom cx2341x v4l2_common ehci_hcd videodev media
>>> acpi_cpufreq tpm_tis tpm_tis_core gpio_ich snd soundcore tpm psmouse
>>> lpc_ich evdev asus_atk0110 serio_raw lp parport raid456 async_raid6_recov
>>> async_pq async_xor async_memcpy async_tx multipath usbhid hid sr_mod cdrom
>>> sg firewire_ohci firewire_core floppy crc_itu_t i915 atl1 fjes mii
>>> uhci_hcd usbcore usb_common
>>> CPU: 0 PID: 22825 Comm: kworker/u9:2 Tainted: G W
>>> 4.8.5-ia32-20161028 #2
>>> Hardware name: System manufacturer P5E-VM HDMI/P5E-VM HDMI, BIOS 0604
>>> 07/16/2008
>>> Workqueue: btrfs-worker-high btrfs_worker_helper
>>> 00200286 00200286 d3d81e48 df414827 00000000 dfa12da5 d3d81e78 df05677a
>>> df9ed884 00000000 00005929 dfa12da5 00000208 df2cf067 00000208 f7463fa0
>>> f401a080 00000000 d3d81e8c df05684a 00000009 00000000 00000000 d3d81eb4
>>> Call Trace:
>>> [<df414827>] dump_stack+0x58/0x81
>>> [<df05677a>] __warn+0xea/0x110
>>> [<df2cf067>] ? btree_csum_one_bio.isra.39+0xf7/0x100
>>> [<df05684a>] warn_slowpath_null+0x2a/0x30
>>> [<df2cf067>] btree_csum_one_bio.isra.39+0xf7/0x100
>>> [<df2cf085>] __btree_submit_bio_start+0x15/0x20
>>> [<df2cdd10>] run_one_async_start+0x30/0x40
>>> [<df31286d>] btrfs_scrubparity_helper+0xcd/0x2d0
>>> [<df2cde70>] ? run_one_async_free+0x20/0x20
>>> [<df312bbd>] btrfs_worker_helper+0xd/0x10
>>> [<df06d05b>] process_one_work+0x10b/0x400
>>> [<df06d387>] worker_thread+0x37/0x4b0
>>> [<df06d350>] ? process_one_work+0x400/0x400
>>> [<df0722db>] kthread+0x9b/0xb0
>>> [<df799922>] ret_from_kernel_thread+0xe/0x24
>>> [<df072240>] ? kthread_stop+0x100/0x100
>>> ---[ end trace f461faff989bf258 ]---
>>> BTRFS: error (device dm-0) in btrfs_commit_transaction:2232: errno=-5 IO
>>> failure (Error while writing out transaction)
>>> BTRFS info (device dm-0): forced readonly
>>> BTRFS warning (device dm-0): Skipping commit of aborted transaction.
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 22318 at fs/btrfs/transaction.c:1854
>>> btrfs_commit_transaction+0x2f5/0xcc0
>>> BTRFS: Transaction aborted (error -5)
>>> Modules linked in: bcache configs rc_hauppauge ir_kbd_i2c
>>> cpufreq_userspace cpufreq_powersave cpufreq_conservative autofs4
>>> snd_hda_codec_hdmi joydev snd_hda_codec_realtek snd_hda_codec_generic
>>> tuner_simple tuner_types tda9887 snd_hda_intel snd_hda_codec snd_hda_core
>>> snd_hwdep tda8290 coretemp snd_pcm_oss snd_mixer_oss tuner snd_pcm msp3400
>>> snd_seq_midi snd_seq_midi_event firewire_sbp2 saa7127 snd_rawmidi
>>> hwmon_vid dm_crypt dm_mod saa7115 snd_seq bttv hid_generic snd_seq_device
>>> snd_timer ehci_pci ivtv tea575x videobuf_dma_sg rc_core videobuf_core
>>> input_leds tveeprom cx2341x v4l2_common ehci_hcd videodev media
>>> acpi_cpufreq tpm_tis tpm_tis_core gpio_ich snd soundcore tpm psmouse
>>> lpc_ich evdev asus_atk0110 serio_raw lp parport raid456 async_raid6_recov
>>> async_pq async_xor async_memcpy async_tx multipath usbhid hid sr_mod cdrom
>>> sg firewire_ohci firewire_core floppy crc_itu_t i915 atl1 fjes mii
>>> uhci_hcd usbcore usb_common
>>> CPU: 0 PID: 22318 Comm: btrfs-balance Tainted: G W
>>> 4.8.5-ia32-20161028 #2
>>> Hardware name: System manufacturer P5E-VM HDMI/P5E-VM HDMI, BIOS 0604
>>> 07/16/2008
>>> 00000286 00000286 d74a3ca4 df414827 d74a3ce8 dfa132ab d74a3cd4 df05677a
>>> dfa075cc d74a3d04 0000572e dfa132ab 0000073e df2d7de5 0000073e f698dc00
>>> e9173e70 fffffffb d74a3cf0 df0567db 00000009 00000000 d74a3ce8 dfa075cc
>>> Call Trace:
>>> [<df414827>] dump_stack+0x58/0x81
>>> [<df05677a>] __warn+0xea/0x110
>>> [<df2d7de5>] ? btrfs_commit_transaction+0x2f5/0xcc0
>>> [<df0567db>] warn_slowpath_fmt+0x3b/0x40
>>> [<df2d7de5>] btrfs_commit_transaction+0x2f5/0xcc0
>>> [<df096800>] ? prepare_to_wait_event+0xd0/0xd0
>>> [<df33334f>] prepare_to_relocate+0x12f/0x180
>>> [<df339a41>] relocate_block_group+0x31/0x790
>>> [<df0b1427>] ? vprintk_default+0x37/0x40
>>> [<df796ca0>] ? mutex_lock+0x10/0x30
>>> [<df2f8f45>] ? btrfs_wait_ordered_roots+0x1d5/0x1f0
>>> [<df14eed6>] ? printk+0x17/0x19
>>> [<df2a47b2>] ? btrfs_printk+0x102/0x110
>>> [<df33a388>] btrfs_relocate_block_group+0x1e8/0x2e0
>>> [<df308a9f>] btrfs_relocate_chunk.isra.29+0x3f/0xf0
>>> [<df30221f>] ? free_extent_buffer+0x4f/0xa0
>>> [<df30a555>] btrfs_balance+0xb05/0x1820
>>> [<df0b0afa>] ? console_unlock+0x40a/0x630
>>> [<df30b2c1>] balance_kthread+0x51/0x80
>>> [<df30b270>] ? btrfs_balance+0x1820/0x1820
>>> [<df0722db>] kthread+0x9b/0xb0
>>> [<df799922>] ret_from_kernel_thread+0xe/0x24
>>> [<df072240>] ? kthread_stop+0x100/0x100
>>> ---[ end trace f461faff989bf259 ]---
>>> BTRFS: error (device dm-0) in cleanup_transaction:1854: errno=-5 IO failure
>>> BTRFS info (device dm-0): delayed_refs has NO entry
>>>
>>
>>
>>
>
^ permalink raw reply
* Re: [RFC PATCH 20/24] ARM: vITS: handle INV command
From: Stefano Stabellini @ 2016-11-09 1:49 UTC (permalink / raw)
To: Andre Przywara; +Cc: xen-devel, Julien Grall, Stefano Stabellini
In-Reply-To: <20160928182457.12433-21-andre.przywara@arm.com>
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The INV command instructs the ITS to update the configuration data for
> a given LPI by re-reading its entry from the property table.
> We don't need to care so much about the priority value, but enabling
> or disabling an LPI has some effect: We remove or push virtual LPIs
> to their VCPUs, also propagate the enable bit to the hardware.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> xen/arch/arm/gic-its.c | 35 ++++++++++++++++++++
> xen/arch/arm/vgic-its.c | 74 +++++++++++++++++++++++++++++++++++++++++++
> xen/include/asm-arm/gic-its.h | 3 ++
> 3 files changed, 112 insertions(+)
>
> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> index 766a7cb..6f4329f 100644
> --- a/xen/arch/arm/gic-its.c
> +++ b/xen/arch/arm/gic-its.c
> @@ -215,6 +215,19 @@ static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid,
> return its_send_command(its, cmd);
> }
>
> +static int its_send_cmd_inv(struct host_its *its,
> + uint32_t deviceid, uint32_t eventid)
> +{
> + uint64_t cmd[4];
> +
> + cmd[0] = GITS_CMD_INV | ((uint64_t)deviceid << 32);
> + cmd[1] = eventid;
> + cmd[2] = 0x00;
> + cmd[3] = 0x00;
> +
> + return its_send_command(its, cmd);
> +}
> +
> int gicv3_its_map_device(struct host_its *hw_its, struct domain *d,
> int devid, int bits, bool valid)
> {
> @@ -655,6 +668,28 @@ uint32_t gicv3_lpi_lookup_lpi(struct domain *d, uint32_t host_lpi, int *vcpu_id)
> return hlpi.virt_lpi;
> }
>
> +void gicv3_lpi_set_enable(struct host_its *its,
> + uint32_t deviceid, uint32_t eventid,
> + uint32_t host_lpi, bool enabled)
> +{
> + host_lpi -= 8192;
> +
> + if ( host_lpi >= MAX_HOST_LPIS )
> + return;
> +
> + if ( !its )
> + return;
> +
> + if (enabled)
> + lpi_data.lpi_property[host_lpi] |= LPI_PROP_ENABLED;
> + else
> + lpi_data.lpi_property[host_lpi] &= ~LPI_PROP_ENABLED;
> +
> + __flush_dcache_area(&lpi_data.lpi_property[host_lpi], 1);
> +
> + its_send_cmd_inv(its, deviceid, eventid);
> + its_send_cmd_sync(its, 0);
> +}
> +
> void gicv3_its_dt_init(const struct dt_device_node *node)
> {
> const struct dt_device_node *its = NULL;
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index 028d234..74da8fc 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -223,6 +223,77 @@ out_unlock:
> return ret;
> }
>
> +/* For a given virtual LPI read the enabled bit from the virtual property
> + * table and update the virtual IRQ's state.
> + * This enables or disables the associated hardware LPI, also takes care
> + * of removing or pushing of virtual LPIs to their VCPUs.
> + */
> +static void update_lpi_enabled_status(struct virt_its* its,
> + struct vcpu *vcpu, uint32_t vlpi,
> + uint32_t deviceid, uint32_t eventid,
> + uint32_t hlpi)
> +{
> + struct pending_irq *pirq = lpi_to_pending(vcpu, vlpi, false);
> + uint8_t property = its->d->arch.vgic.proptable[vlpi - 8192];
We need to check vlpi before using to access an array. We also need a
barrier before using property.
> + if ( property & LPI_PROP_ENABLED )
> + {
> + if ( pirq )
> + {
> + unsigned long flags;
> +
> + set_bit(GIC_IRQ_GUEST_ENABLED, &pirq->status);
> + spin_lock_irqsave(&vcpu->arch.vgic.lock, flags);
> + if ( !list_empty(&pirq->inflight) &&
> + !test_bit(GIC_IRQ_GUEST_VISIBLE, &pirq->status) )
> + gic_raise_guest_irq(vcpu, vlpi, property & 0xfc);
> + spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
> +
> + }
> + gicv3_lpi_set_enable(its->hw_its, deviceid, eventid, hlpi, true);
> + }
> + else
> + {
> + if ( pirq )
> + {
> + clear_bit(GIC_IRQ_GUEST_ENABLED, &pirq->status);
> + gic_remove_from_queues(vcpu, vlpi);
> + }
> + gicv3_lpi_set_enable(its->hw_its, deviceid, eventid, hlpi, false);
> + }
> +}
> +
> +static int its_handle_inv(struct virt_its *its, uint64_t *cmdptr)
> +{
> + uint32_t devid = its_cmd_get_deviceid(cmdptr);
> + uint32_t eventid = its_cmd_get_id(cmdptr);
> + struct vits_itte *itte;
> + struct vcpu *vcpu;
> + uint32_t hlpi, vlpi;
> + int ret = -1;
> +
> + spin_lock(&its->its_lock);
> +
> + itte = get_devid_evid(its, devid, eventid);
> + if ( !itte )
> + goto out_unlock;
We need to check itte->collection before using it to access d->vcpu.
> + vcpu = its->d->vcpu[itte->collection];
> + vlpi = itte->vlpi;
> + hlpi = itte->hlpi;
> +
> + ret = 0;
> +
> + put_devid_evid(its, itte);
> +
> +out_unlock:
> + spin_unlock(&its->its_lock);
> +
> + if ( !ret )
> + update_lpi_enabled_status(its, vcpu, vlpi, devid, eventid, hlpi);
> +
> + return ret;
> +}
> +
> static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
> {
> uint32_t collid = its_cmd_get_collection(cmdptr);
> @@ -441,6 +512,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> case GITS_CMD_INT:
> its_handle_int(its, cmdptr);
> break;
> + case GITS_CMD_INV:
> + its_handle_inv(its, cmdptr);
> + break;
> case GITS_CMD_MAPC:
> its_handle_mapc(its, cmdptr);
> break;
> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
> index 3f5698d..2cdb3e1 100644
> --- a/xen/include/asm-arm/gic-its.h
> +++ b/xen/include/asm-arm/gic-its.h
> @@ -139,6 +139,9 @@ int gicv3_lpi_allocate_host_lpi(struct host_its *its,
> uint32_t gicv3_lpi_lookup_lpi(struct domain *d, uint32_t host_lpi,
> int *vcpu_id);
> int gicv3_lpi_change_vcpu(struct domain *d, uint32_t host_lpi, int new_vcpu_id);
> +void gicv3_lpi_set_enable(struct host_its *its,
> + uint32_t deviceid, uint32_t eventid,
> + uint32_t host_lpi, bool enabled);
> int gicv3_lpi_drop_host_lpi(struct host_its *its,
> uint32_t devid, uint32_t eventid,
> uint32_t host_lpi);
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH] PM / devfreq: correct comment typo.
From: Chanwoo Choi @ 2016-11-09 1:46 UTC (permalink / raw)
To: myungjoo.ham, linux-pm@vger.kernel.org
In-Reply-To: <698260245.615933.1478655561574.JavaMail.weblogic@ep2ml103c>
On 2016년 11월 09일 10:39, MyungJoo Ham wrote:
>
> The function name in the comment was incorrect.
>
> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> ---
> drivers/devfreq/devfreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index bf3ea76..a324801 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -850,7 +850,7 @@ int devfreq_add_governor(struct devfreq_governor *governor)
> EXPORT_SYMBOL(devfreq_add_governor);
>
> /**
> - * devfreq_remove_device() - Remove devfreq feature from a device.
> + * devfreq_remove_governor() - Remove devfreq feature from a device.
> * @governor: the devfreq governor to be removed
> */
> int devfreq_remove_governor(struct devfreq_governor *governor)
>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* Higher block layer latency in kernel v4.8-r6 vs. v4.4.16 for NVMe
From: Alana Alexander-Rutledge @ 2016-11-09 1:43 UTC (permalink / raw)
Hi,
I have been profiling the performance of the NVMe and SAS IO stacks on Linux. I used blktrace and blkparse to collect block layer trace points and a custom analysis script on the trace points to average out the latencies of each trace point interval of each IO.
I started with Linux kernel v4.4.16 but then switched to v4.8-r6. One thing that stood out is that for measurements at queue depth = 1, the average Q2D latency was quite a bit higher in the NVMe path with the newer version of the kernel.
The Q, G, I, and D below refer to blktrace/blkparse trace points (queued, get request, inserted, and issued).
Queue Depth = 1
Interval Average - v4.4.16 (us) Average - v4.8-rc6 (us)
Q2G 0.212 0.573
G2I 0.944 1.507
I2D 0.435 0.837
Q2D 1.592 2.917
For other queue depths, Q2D was similar for both versions of the kernel.
Queue Depth Average Q2D - v4.4.16 (us) Average Q2D - v4.8-rc6 (us)
2 1.893 1.736
4 1.289 1.38
8 1.223 1.162
16 1.14 1.178
32 1.007 1.425
64 0.964 0.978
128 0.915 0.941
I did not see this as a problem with the 12G SAS SSD that I measured.
Queue Depth = 1
Interval Average - v4.4.16 (us) Average - v4.8-rc6 (us)
Q2G 0.264 0.301
G2I 0.917 0.864
I2D 0.432 0.397
Q2D 1.613 1.561
Is this a known change or do you know what the reason for this is?
My data flows were 4KB random reads, 4KB aligned, generated with fio/libaio. I am running IOs against a 4G file on an ext4 file system. The above measurements are the averaged over 1 million IOs.
I am using a Ubuntu 16.04.1
I am running on a Supermicro server with an Intel Xeon CPU E5-2690 v3 @ 2.6 GHz, 12 cores. Hyperthreading is enabled and SpeedStep is disabled.
My NVMe drive is an Intel SSD P3700 Series, 400 GB.
Thanks,
Alana
^ permalink raw reply
* Higher block layer latency in kernel v4.8-r6 vs. v4.4.16 for NVMe
From: Alana Alexander-Rutledge @ 2016-11-09 1:43 UTC (permalink / raw)
To: linux-block@vger.kernel.org, linux-nvme@lists.infradead.org; +Cc: Stephen Bates
Hi,
I have been profiling the performance of the NVMe and SAS IO stacks on Linux. I used blktrace and blkparse to collect block layer trace points and a custom analysis script on the trace points to average out the latencies of each trace point interval of each IO.
I started with Linux kernel v4.4.16 but then switched to v4.8-r6. One thing that stood out is that for measurements at queue depth = 1, the average Q2D latency was quite a bit higher in the NVMe path with the newer version of the kernel.
The Q, G, I, and D below refer to blktrace/blkparse trace points (queued, get request, inserted, and issued).
Queue Depth = 1
Interval Average - v4.4.16 (us) Average - v4.8-rc6 (us)
Q2G 0.212 0.573
G2I 0.944 1.507
I2D 0.435 0.837
Q2D 1.592 2.917
For other queue depths, Q2D was similar for both versions of the kernel.
Queue Depth Average Q2D - v4.4.16 (us) Average Q2D - v4.8-rc6 (us)
2 1.893 1.736
4 1.289 1.38
8 1.223 1.162
16 1.14 1.178
32 1.007 1.425
64 0.964 0.978
128 0.915 0.941
I did not see this as a problem with the 12G SAS SSD that I measured.
Queue Depth = 1
Interval Average - v4.4.16 (us) Average - v4.8-rc6 (us)
Q2G 0.264 0.301
G2I 0.917 0.864
I2D 0.432 0.397
Q2D 1.613 1.561
Is this a known change or do you know what the reason for this is?
My data flows were 4KB random reads, 4KB aligned, generated with fio/libaio. I am running IOs against a 4G file on an ext4 file system. The above measurements are the averaged over 1 million IOs.
I am using a Ubuntu 16.04.1
I am running on a Supermicro server with an Intel Xeon CPU E5-2690 v3 @ 2.6 GHz, 12 cores. Hyperthreading is enabled and SpeedStep is disabled.
My NVMe drive is an Intel SSD P3700 Series, 400 GB.
Thanks,
Alana
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH] Avoid that SCSI device removal through sysfs triggers a deadlock
From: James Bottomley @ 2016-11-09 1:43 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Bart Van Assche, Martin K. Petersen, Greg Kroah-Hartman,
Hannes Reinecke, Johannes Thumshirn, Sagi Grimberg,
linux-scsi@vger.kernel.org
In-Reply-To: <87bmxpqxlb.fsf@xmission.com>
On Tue, 2016-11-08 at 18:57 -0600, Eric W. Biederman wrote:
> James Bottomley <jejb@linux.vnet.ibm.com> writes:
>
> > On Tue, 2016-11-08 at 13:13 -0600, Eric W. Biederman wrote:
[...]
> > > Is it really the dropping of the lock that is causing this?
> > > I don't see that when I read those traces.
> >
> > No, it's an ABBA lock inversion that causes this. The traces are
> > somewhat dense, but they say it here:
> >
> > Possible unsafe locking scenario:
> > CPU0 CPU1
> > ---- ----
> > lock(s_active#336);
> > lock(&shost->scan_mutex);
> > lock(s_active#336);
> > lock(&shost->scan_mutex);
> >
> > *** DEADLOCK ***
> >
> > The detailed explanation of this is here:
> >
> > http://marc.info/?l=linux-scsi&m=147855187425596
> >
> > The fix is ensuring that the CPU1 thread doesn't get into taking
> > s_active if CPU0 already has it using the KERNFS_SUICIDED/AL flag
> > as an indicator.
>
> So. The kernfs code does not look safe to have kernfs_remove_self
> and kernfs_remove_by_name_ns racing against each other I agree.
>
> The kernfs_remove_self path turns KERNFS_SUICIDAL into another
> blocking lock by another name, and without lockdep annotations so I
> don't know that it is safe.
Yes ... the number of hand rolled locks in that code make it super hard
to follow.
> The relevant bit from kernfs_remove_self is:
>
> if (!(kn->flags & KERNFS_SUICIDAL)) {
> kn->flags |= KERNFS_SUICIDAL;
> __kernfs_remove(kn);
> kn->flags |= KERNFS_SUICIDED;
> ret = true;
> } else {
> wait_queue_head_t *waitq = &kernfs_root(kn)
> ->deactivate_waitq;
> DEFINE_WAIT(wait);
>
> while (true) {
> prepare_to_wait(waitq, &wait,
> TASK_UNINTERRUPTIBLE);
>
> if ((kn->flags & KERNFS_SUICIDED) &&
> atomic_read(&kn->active) ==
> KN_DEACTIVATED_BIAS)
> break;
>
> mutex_unlock(&kernfs_mutex);
> schedule();
> mutex_lock(&kernfs_mutex);
> }
> finish_wait(waitq, &wait);
> WARN_ON_ONCE(!RB_EMPTY_NODE(&kn->rb));
> ret = false;
> }
>
> I am pretty certain that if you are going to make kernfs_remove_self
> and kernfs_remove_by_name_ns to be safe to race against each other,
> not just the KERNFS_SUICIDAL check, but the wait when KERNFS_SUICIDAL
> is set needs to be added ot kernfs_remove_by_name_ns.
I don't think you can do that: waiting for SUICIDED would introduce
another potential lock entanglement. I'm reasonably happy that the
deactivation offset coupled with kernfs_drain in the non self remove
path means that the necessary cleanup is done when the directory itself
is removed. That seems to be a common pattern in all non-self removes.
> And I suspect if you add the appropriate lockdep annotations to that
> mess you will find yourself in a similar but related ABBA deadlock.
I can't prove the negative, but as long as there's no waiting on the
SUICIDED/AL flags in the non-self remove path, I believe we're safe
with the current patch.
> Which is why I would like a simpler easier to understand mechanism if
> we can.
I don't disagree: If you want to clean out the Augean Stables, I can
lend you the thigh length rubber boots and the gas mask. However, I
think that what we're currently proposing: a simple patch to make
device_remove_file_self() actually work for everyone, along with
stringent testing is the better approach.
After all, if you look at
commit ac0ece9174aca9aa895ce0accc54f1f8ff12d117
Author: Tejun Heo <tj@kernel.org>
Date: Mon Feb 3 14:03:03 2014 -0500
scsi: use device_remove_file_self() instead of device_schedule_callback()
You'll see Tejun added all this stuff just to remove the async callback
we originally had. Simply restoring the async callback back makes us
quite considerably worse off because the device_remove_file_self()
mechanism is in use elsewhere. We need either to fix it and move on or
junk it and go back to the original.
James
^ permalink raw reply
* [GIT PULL] drm/fsl-dcu: fixes for v4.9-rc5
From: Stefan Agner @ 2016-11-09 1:42 UTC (permalink / raw)
To: airlied; +Cc: meng.yi, dri-devel, alison.wang
Hi Dave,
Yet antoher small batch of fixes. Two of the patches I had prepared
since quite some time, but they did not seem to affect operation in
a visible manner so far. Until recently, when I discovered the third
issue (disable planes before disabling CRTC), which made the two
previous fixes necessary.
--
Stefan
The following changes since commit 020a0bbc0d89c15693e69ed2063584ef7ec2d811:
Merge branch 'msm-fixes-4.9' of git://people.freedesktop.org/~robclark/linux into drm-fixes (2016-11-07 09:41:10 +1000)
are available in the git repository at:
http://git.agner.ch/git/linux-drm-fsl-dcu.git fixes-for-v4.9-rc5
for you to fetch changes up to 3d6f37102bd6e4b55a7f336d44974c0bd1c22a15:
drm/fsl-dcu: disable planes before disabling CRTC (2016-11-08 17:14:08 -0800)
----------------------------------------------------------------
Stefan Agner (3):
drm/fsl-dcu: do not update when modifying irq registers
drm/fsl-dcu: update all registers on flush
drm/fsl-dcu: disable planes before disabling CRTC
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 13 +++++++++++--
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 ----
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 5 -----
3 files changed, 11 insertions(+), 11 deletions(-)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v2 0/2] arm64: fix the bugs found in the hugetlb test
From: Huang Shijie @ 2016-11-09 1:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108163642.GE20591@arm.com>
Hi Will & Catalin,
On Tue, Nov 08, 2016 at 04:36:43PM +0000, Will Deacon wrote:
> On Tue, Nov 08, 2016 at 02:09:09PM +0000, Catalin Marinas wrote:
> > On Tue, Nov 08, 2016 at 01:44:37PM +0800, Huang Shijie wrote:
> > > (3) The test result in the Softiron and Juno-r1 boards:
> > >
> > > This detail test result shows below (both the "make func" & "make stress"):
> > >
> > > 4KB granule:
> > >
> > > 1.1) PTE + Contiguous bit : 4K x 16 = 64K (per huge page size)
> > > Test result : PASS
> > >
> > > 1.2) PMD : 2M x 1 = 2M (per huge page size)
> > > Test result : PASS
> > >
> > > 1.3) PMD + Contiguous bit : 2M x 16 = 32M (per huge page size)
> > > Test result : PASS
> > >
> > > 64KB granule:
> > >
> > > 3.1) PTE + Contiguous bit : 64K x 32 = 2M (per huge page size)
> > > Test result : PASS
> > >
> > > 3.2) PMD + Contiguous bit : 512M x 32 = 16G (per huge page size)
> > > Test result : no hardware to support this test
> >
> > Don't we have support for single (non-contiguous) PMD huge page with 64K
> > pages (512M per huge page)? I gave it a try and it seems to work (though
> > without your patches applied ;)).
Yes, it should be okay. This patch set does not affect the the single
PMD huge page.
> >
> > > Huang Shijie (2):
> > > arm64: hugetlb: remove the wrong pmd check in find_num_contig()
> > > arm64: hugetlb: fix the wrong address for several functions
> >
> > For these patches:
> >
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks you, Catalin.
> >
> > I'm not sure whether Will plans to push them into 4.9. AFAICT, the
> > contiguous huge pages never worked properly, so we may not count it as a
> > regression but a new feature. If Will doesn't take them, I'll queue the
> > patches for 4.10.
>
> Right, given that it's never worked and the failure only seems to crop up
> in synthetic testing, I think you can queue these for 4.10.
Okay. Thank for queue them for 4.10.
Thanks
Huang Shijie
^ permalink raw reply
* Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate
From: Ian Jackson @ 2016-11-09 1:41 UTC (permalink / raw)
To: Jeff King; +Cc: Jacob Keller, Git mailing list, Junio C Hamano, Paul Mackerras
In-Reply-To: <20161108215709.rvmsnz4fvhizbocl@sigill.intra.peff.net>
Jeff King writes ("Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate"):
> Yeah, I think git's config system was always designed to carry options
> for porcelains outside of git-core itself. So your new option fits into
> that.
Good, thanks.
> I think the two things I found weird were:
>
> - it's in the "log" section, which makes me think it's an option for
> git-log. But it's not. I'm not sure what the _right_ section is, but
> hopefully it would make it clear that this is command-agnostic.
>
> Something like "gui.abbrevTags" might be OK (and as you note, has
> precedence). But of course it's possible that a command like "tig"
> could learn to support it. I'm not sure if that counts as a GUI or
> not. :)
I don't really have an opinion about the name. gui.abbrevTags would
be a possibility. (It's a bit odd that implicitly, the default would
be `*'.)
> - The description talks about tag abbreviation, but doesn't really
> define it. Not being a gitk user, it was hard for me to figure out
> whether this was even relevant. Does it mean turning
> "refs/tags/v1.0" into "1.0"? From the rest of the series, it sounds
> like no. That should be more clear from the documentation.
I can do that, sure.
By default, gitk doesn't like to use much screen real estate for tags.
If there are long tag names, or many tags, it shows them all as a
single small indication saying just `<tag...|' or whatever with the
literal `tag...', not with the tag value.
Maybe a better name would be
gui.alwaysShowTags
?
I'm happy to be just told what the name ought to be, if the gitk and
git maintainers can agree. It seems largely a matter of taste.
Thanks,
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
^ permalink raw reply
* Re: task isolation discussion at Linux Plumbers
From: Paul E. McKenney @ 2016-11-09 1:40 UTC (permalink / raw)
To: Chris Metcalf
Cc: Gilad Ben Yossef, Steven Rostedt, Ingo Molnar, Peter Zijlstra,
Andrew Morton, Rik van Riel, Tejun Heo, Frederic Weisbecker,
Thomas Gleixner, Christoph Lameter, Viresh Kumar, Catalin Marinas,
Will Deacon, Andy Lutomirski, Daniel Lezcano, Francis Giraldeau,
Andi Kleen, Arnd Bergmann, linux-kernel
In-Reply-To: <1605b087-2b3b-77c1-01ac-084e378f5f28@mellanox.com>
On Sat, Nov 05, 2016 at 12:04:45AM -0400, Chris Metcalf wrote:
> A bunch of people got together this week at the Linux Plumbers
> Conference to discuss nohz_full, task isolation, and related stuff.
> (Thanks to Thomas for getting everyone gathered at one place and time!)
>
> Here are the notes I took; I welcome any corrections and follow-up.
[ . . . ]
> == Remote kernel TLB flush ==
>
> Andy then brought up the issue of remote kernel TLB flush, which I've
> been trying to sweep under the rug for the initial task isolation
> series. Remote TLB flush causes an interrupt on many systems (x86 and
> tile, for example, although not arm64), so to the extent that it
> occurs frequently, it becomes important to handle for task isolation.
> With the recent addition of vmap kernel stacks, this becomes suddenly
> much more important than it used to be, to the point where we now
> really have to handle it for task isolation.
>
> The basic insight here is that you can safely skip interrupting
> userspace cores when you are sending remote kernel TLB flushes, since
> by definition they can't touch the kernel pages in question anyway.
> Then you just need to guarantee to flush the kernel TLB space next
> time the userspace task re-enters the kernel.
>
> The original Tilera dataplane code handled this by tracking task state
> (kernel, user, or user-flushed) and manipulating the state atomically
> at TLB flush time and kernel entry time. After some discussion of the
> overheads of such atomics, Andy pointed out that there is already an
> atomic increment being done in the RCU code, and we should be able to
> leverage that word to achieve this effect. The idea is that remote
> cores would do a compare-exchange of 0 to 1, which if it succeeded
> would indicate that the remote core was in userspace and thus didn't
> need to be IPI'd, but that it was now tagged for a kernel flush next
> time the remote task entered the kernel. Then, when the remote task
> enters the kernel, it does an atomic update of its own dynticks and
> discovers the low bit set, it does a kernel TLB flush before
> continuing.
>
> It was agreed that this makes sense to do unconditionally, since it's
> not just helpful for nohz_full and task isolation, but also for idle,
> since interrupting an idle core periodically just to do repeated
> kernel tlb flushes isn't good for power consumption.
>
> One open question is whether we discover the low bit set early enough
> in kernel entry that we can trust that we haven't tried to touch any
> pages that have been invalidated in the TLB.
>
> Paul agreed to take a look at implementing this.
Please see a prototype at 49961e272333 at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
Or see below for the patch.
As discussed earlier, once I get this working, I hand it off to you
to add your code.
Thoughts?
Thanx, Paul
------------------------------------------------------------------------
commit 49961e272333ac720ac4ccbaba45521bfea259ae
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Tue Nov 8 14:25:21 2016 -0800
rcu: Maintain special bits at bottom of ->dynticks counter
Currently, IPIs are used to force other CPUs to invalidate their TLBs
in response to a kernel virtual-memory mapping change. This works, but
degrades both battery lifetime (for idle CPUs) and real-time response
(for nohz_full CPUs), and in addition results in unnecessary IPIs due to
the fact that CPUs executing in usermode are unaffected by stale kernel
mappings. It would be better to cause a CPU executing in usermode to
wait until it is entering kernel mode to
This commit therefore reserves a bit at the bottom of the ->dynticks
counter, which is checked upon exit from extended quiescent states. If it
is set, it is cleared and then a new rcu_dynticks_special_exit() macro
is invoked, which, if not supplied, is an empty single-pass do-while loop.
If this bottom bit is set on -entry- to an extended quiescent state,
then a WARN_ON_ONCE() triggers.
This bottom bit may be set using a new rcu_dynticks_special_set()
function, which returns true if the bit was set, or false if the CPU
turned out to not be in an extended quiescent state. Please note that
this function refuses to set the bit for a non-nohz_full CPU when that
CPU is executing in usermode because usermode execution is tracked by
RCU as a dyntick-idle extended quiescent state only for nohz_full CPUs.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index 4f9b2fa2173d..130d911e4ba1 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -33,6 +33,11 @@ static inline int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
return 0;
}
+static inline bool rcu_dynticks_special_set(int cpu)
+{
+ return false; /* Never flag non-existent other CPUs! */
+}
+
static inline unsigned long get_state_synchronize_rcu(void)
{
return 0;
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index dbf20b058f48..8de83830e86b 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -279,23 +279,36 @@ static DEFINE_PER_CPU(struct rcu_dynticks, rcu_dynticks) = {
};
/*
+ * Steal a bit from the bottom of ->dynticks for idle entry/exit
+ * control. Initially this is for TLB flushing.
+ */
+#define RCU_DYNTICK_CTRL_MASK 0x1
+#define RCU_DYNTICK_CTRL_CTR (RCU_DYNTICK_CTRL_MASK + 1)
+#ifndef rcu_dynticks_special_exit
+#define rcu_dynticks_special_exit() do { } while (0)
+#endif
+
+/*
* Record entry into an extended quiescent state. This is only to be
* called when not already in an extended quiescent state.
*/
static void rcu_dynticks_eqs_enter(void)
{
struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+ int seq;
/*
- * CPUs seeing atomic_inc() must see prior RCU read-side critical
- * sections, and we also must force ordering with the next idle
- * sojourn.
+ * CPUs seeing atomic_inc_return() must see prior RCU read-side
+ * critical sections, and we also must force ordering with the
+ * next idle sojourn.
*/
- smp_mb__before_atomic(); /* See above. */
- atomic_inc(&rdtp->dynticks);
- smp_mb__after_atomic(); /* See above. */
+ seq = atomic_inc_return(&rdtp->dynticks);
+ /* Better be in an extended quiescent state! */
+ WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
+ (seq & RCU_DYNTICK_CTRL_CTR));
+ /* Better not have special action (TLB flush) pending! */
WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
- atomic_read(&rdtp->dynticks) & 0x1);
+ (seq & RCU_DYNTICK_CTRL_MASK));
}
/*
@@ -305,17 +318,21 @@ static void rcu_dynticks_eqs_enter(void)
static void rcu_dynticks_eqs_exit(void)
{
struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+ int seq;
/*
- * CPUs seeing atomic_inc() must see prior idle sojourns,
+ * CPUs seeing atomic_inc_return() must see prior idle sojourns,
* and we also must force ordering with the next RCU read-side
* critical section.
*/
- smp_mb__before_atomic(); /* See above. */
- atomic_inc(&rdtp->dynticks);
- smp_mb__after_atomic(); /* See above. */
+ seq = atomic_inc_return(&rdtp->dynticks);
WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
- !(atomic_read(&rdtp->dynticks) & 0x1));
+ !(seq & RCU_DYNTICK_CTRL_CTR));
+ if (seq & RCU_DYNTICK_CTRL_MASK) {
+ atomic_and(~RCU_DYNTICK_CTRL_MASK, &rdtp->dynticks);
+ smp_mb__after_atomic(); /* Clear bits before acting on them */
+ rcu_dynticks_special_exit();
+ }
}
/*
@@ -326,7 +343,7 @@ int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
{
int snap = atomic_add_return(0, &rdtp->dynticks);
- return snap;
+ return snap & ~RCU_DYNTICK_CTRL_MASK;
}
/*
@@ -335,7 +352,7 @@ int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
*/
static bool rcu_dynticks_in_eqs(int snap)
{
- return !(snap & 0x1);
+ return !(snap & RCU_DYNTICK_CTRL_CTR);
}
/*
@@ -355,10 +372,33 @@ static bool rcu_dynticks_in_eqs_since(struct rcu_dynticks *rdtp, int snap)
static void rcu_dynticks_momentary_idle(void)
{
struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
- int special = atomic_add_return(2, &rdtp->dynticks);
+ int special = atomic_add_return(2 * RCU_DYNTICK_CTRL_CTR,
+ &rdtp->dynticks);
/* It is illegal to call this from idle state. */
- WARN_ON_ONCE(!(special & 0x1));
+ WARN_ON_ONCE(!(special & RCU_DYNTICK_CTRL_CTR));
+}
+
+/*
+ * Set the special (bottom) bit of the specified CPU so that it
+ * will take special action (such as flushing its TLB) on the
+ * next exit from an extended quiescent state. Returns true if
+ * the bit was successfully set, or false if the CPU was not in
+ * an extended quiescent state.
+ */
+bool rcu_dynticks_special_set(int cpu)
+{
+ int old;
+ int new;
+ struct rcu_dynticks *rdtp = &per_cpu(rcu_dynticks, cpu);
+
+ do {
+ old = atomic_read(&rdtp->dynticks);
+ if (old & RCU_DYNTICK_CTRL_CTR)
+ return false;
+ new = old | ~RCU_DYNTICK_CTRL_MASK;
+ } while (atomic_cmpxchg(&rdtp->dynticks, old, new) != old);
+ return true;
}
DEFINE_PER_CPU_SHARED_ALIGNED(unsigned long, rcu_qs_ctr);
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 3b953dcf6afc..c444787a3bdc 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -596,6 +596,7 @@ extern struct rcu_state rcu_preempt_state;
#endif /* #ifdef CONFIG_PREEMPT_RCU */
int rcu_dynticks_snap(struct rcu_dynticks *rdtp);
+bool rcu_dynticks_special_set(int cpu);
#ifdef CONFIG_RCU_BOOST
DECLARE_PER_CPU(unsigned int, rcu_cpu_kthread_status);
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] boot-serial-test: Add a test for the powernv machine
From: David Gibson @ 2016-11-09 1:02 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: Thomas Huth, Alexander Graf, qemu-ppc, qemu-devel
In-Reply-To: <772707af-cde3-7425-c13f-1058fc76756f@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]
On Tue, Nov 08, 2016 at 02:05:35PM +0100, Cédric Le Goater wrote:
> On 11/08/2016 01:36 PM, Thomas Huth wrote:
> > The new powernv machine ships with a firmware that outputs
> > some text to the serial console, so we can automatically
> > test this machine type in the boot-serial tester, too.
> > And to get some (very limited) test coverage for the new
> > POWER9 CPU emulation, too, this test is also started with
> > "-cpu POWER9".
>
> and we see the minimum :
>
> [8450016,6] CPU: P9 generation processor(max 4 threads/core)
>
> Reviewed-by: Cédric Le Goater <clg@kaod.org>
>
>
>
> With very minimal changes (definition of some SPRs and the use
> of the SHV mode), the guest would load the kernel.
Applied to ppc-for-2.8. Good to have this basic smoke test for
powernv.
>
> Thanks,
>
> C.
>
>
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > ---
> > tests/boot-serial-test.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
> > index d98c564..44c82e5 100644
> > --- a/tests/boot-serial-test.c
> > +++ b/tests/boot-serial-test.c
> > @@ -29,6 +29,7 @@ static testdef_t tests[] = {
> > { "ppc64", "ppce500", "", "U-Boot" },
> > { "ppc64", "prep", "", "Open Hack'Ware BIOS" },
> > { "ppc64", "pseries", "", "Open Firmware" },
> > + { "ppc64", "powernv", "-cpu POWER9", "SkiBoot" },
> > { "i386", "isapc", "-cpu qemu32 -device sga", "SGABIOS" },
> > { "i386", "pc", "-device sga", "SGABIOS" },
> > { "i386", "q35", "-device sga", "SGABIOS" },
> >
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] btrfs-progs: send-test: add checking of clone-src option
From: Qu Wenruo @ 2016-11-09 1:39 UTC (permalink / raw)
To: Tsutomu Itoh, dsterba; +Cc: linux-btrfs
In-Reply-To: <201611090125.AA00013@WIN-5MHF4RKU941.jp.fujitsu.com>
At 11/09/2016 09:25 AM, Tsutomu Itoh wrote:
> Sending stream size of clone-src(-c) option is checked.
> Fixed by "btrfs-progs: send: fix handling of -c option".
>
> Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
> ---
> V2: old sending stream image is used
> ---
> .../016-send-clone-src/send-stream-v4.8.2.img | Bin 0 -> 6299778 bytes
The image seems quite large.
How about compressing it? And the script seems only checking the size of
the file, not the content.
So it seems that we don't even need to upload the file.
Thanks,
Qu
> tests/misc-tests/016-send-clone-src/test.sh | 49 +++++++++++++++++++++
> 2 files changed, 49 insertions(+)
> create mode 100644 tests/misc-tests/016-send-clone-src/send-stream-v4.8.2.img
> create mode 100755 tests/misc-tests/016-send-clone-src/test.sh
>
> diff --git a/tests/misc-tests/016-send-clone-src/send-stream-v4.8.2.img b/tests/misc-tests/016-send-clone-src/send-stream-v4.8.2.img
> new file mode 100644
> index 0000000000000000000000000000000000000000..ab774171b9677344f59fbfdacf13aebe8929ccfc
> GIT binary patch
> literal 6299778
> zcmeF(ZOmk6eID>@pU2*reZgmaX3g3hD@1my$dNbp%(Gj+Db32RVkxA>5UH|hn<G2S
> z!9&Mu<n@aj0a=QIO%;U@2?>>0!Hq?o5XmG;Qa4t~QB_K*0r>@2l-dmu7-T7c`@tb<
> z!StT<_+@aUe({I-^7~6O&wb`xbIvut^L)N<y8X89)X`J7-!{MTmh4G#U3qQgNB`@t
> ztttm|>W-W4JbLQnjqjPZvpqSKyWe{IuRZ<TpZ$}6^Z8G{`?)LrUcZ%b_LXm}=5RUx
> znTH;|_@hr<a`nSUPL8g+_q?~CQ_dgUJ)L7i=8gaL=Kooh)q(Q)12<oA{p#f1-+u1!
> z{<Y(s`|oM?z2^A9@SW}#{`OdvQM$!)K5M7vmJhe{fsa33%8qmE?D%CzFF$(ec3JOP
> z{gyIE%4=W#<ZYk+?t0?TOP83o)7RJP9p&<e^8Anf`mws)^yN8sSRWb=Uv67&wE}wX
> zp}+j?Km3(PuKmab`@eYZb=Q1-1@!V4-}q{)Bd>h8`xDO2pWg89pIy7w8Edz=u-s^p
> zYZi~ccP+4Y?Fyr{^$MiU`yRdb{<ZL#CGfyYVpo;G;e6>+_dLE9SbtiVjeqsX`qNq+
> zuRpET@$Q59-QWE4$6jK;{OA?C4`%Df9?TVopM7CH@#=$_y}k$2^huSk{L%{tUi}rb
> z^=C9mO2iN#K!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB=Eb3p9OFW$Take4@%I-C{YPwzE3pq?}mI<dxO#v3CLl2oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FoHAfu>KY
> zeE3_>Us7e1Zn2zC+gY7)a(d6uX_AzPAwYlt0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0-G0T`lQOUw^ZM+GD^2t&Zq6H&Nw--
> zHME-~C1MB=AV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!CvJ1)4soa`K87uc<Ohw^+`n?X1qYG}|89O_CBZ1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZVDkb^pHzAH
> ztNWj<GD^2t&Zq6H&N%6}hjx>)+I&q72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+K+^O{m1}SK&iAW~(k+(rX*;VkPEMaO
> z_)L-#F$4$@AV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyKw$F%O`lYG@E0HXy(*)0i{*UU&gzVl6K4+XCP|4H0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyuz7)|PpW+K
> zL*MvBl~KCIaz1Tmb;hOH-l5$jDG@_}009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXzFVOT!l{?>c<Uo~Cy2WxnZD)1HNxye!
> zHz}*l*VKRj0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&oO`lZx;m)`IqRJ@UVmY6-vpVDC^l0#zBqd@95FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7e?<^`HQsdDc-
> zzj}3*QM$!)K5b`p#>t8DDl<t+#1J4rfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+0D;X5G<{NK`_ha4rphSYVmY6-vpVC_Y~Rps
> zl9Y%cK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pkn-^&Mq{>r|KhsqirCTiL({@&8ob>yKc9XK&d`%4q5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7dX()3A{XPRIC
> z<tn3ei{*UU&gzVl)B6XXNm3$)009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXFY+j)0lPa^bp4?w$ly0${Pup3YadP6o&~B2H
> zh#^3L009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0Ro#BX!@kemp*drXR3_SEtd0XJF7D;%?=LjCP|4H0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyuz7)|PpUL0`_EPx
> zrCTiL({@&8ob(5Wc9XK&d`%4q5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7dX()3A{-@0<Tzse}xVmY6-vpVDC^cx1BNm3$)
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXFY+j)0lPW*>qc1;EWt48QoKM?XopEyFtfAc`DG@_}009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXzFVOT!mAjt(xvt76
> z-C{YPwzE3p(ySWVO_CBZ1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZVDkdaiKNPde{kPhtBleumh)*lt20jeYG^k}O2iN#
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pkn-(}y3Y?ucoqhgtZIggAR+|Lm(9rF|@;=EokN?J5Yk|E(
> zU^rj47FdOMXLYqYPkivj=hwn#mcRphb^}+HKZnzP?T#1M0ta$158Qmg^{dFv{r5Ec
> zUvs?gHOH&mIk|56h5K&0{kHDZ(NnkIHox(ftZs2#d2Qv^bKiMJRlaoUj+^d0dg|nj
> z@0qqcd&=*5@-1&a>(+mG{#zco^zhq0bnxGPZmTrgzq(qP!{z*E9(wfRk3MzD)ej#z
> zIlAiJ^WJ_=Ie&2XbdC*~pIUzYuU4BUtXIDK+s_?duYAdsAA9q9<<;?l;XB<g{Oz%q
> zfA_4No?AZL&IdmJ^j1}FbnEQ+Wk)YRdg*pq?|F%9<+(3^^0rTZcRg|FmF*m+udmfR
> z%H<E``5*oDW5c!(<!CkMmI5z7{g>NL+vy7ExrhGpxBu{09=Y}-7wrGyxz}Cu^%c;|
> zPydatwmS04hso|g*q`3;?w?(|*5CaHyJqqDd)EU0|9`OeJ$mo`YvI595B8-`-ShZb
> zVEt)bHvZKk>rZQSy#BOS$GZ>acYpKGAA5=Y@}pPmKA5c^doWiVe)fg+#H$Zx_WB-7
> z)33Jf_{uN6aNyNnvAcE0>H(E0TX*!s!W#hs1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oTt?K+`8xw*Gj}C#sCnEtd0XJF7EJ
> z%8AuXURmuPdnZ7E009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0Ro#6X!@kehrjjwB~?c07R&jxoz)p9r}qq<CP|4H0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyuz7)|
> zPpUk7OZELKqjZbqeA>?HjFS^vL%T^*B8C6~0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PE+ipy`t;C$D(%nku7oi{*UU&gzUy
> zv+beXBq<R?fB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C7HZRchNtK7cy8p>4qjZbqeA>?HjFWzQXg4XV&DYd`009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXFBu$@G
> zx%P(de80*l-C{YPwzE3p<n$SX&m<`kLx2DQ0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1U4_w^huQmfANvut1?QrSk9;Itj;(&
> zapur&l9Y%cK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pkn-^&Mq{=5h^o>tc8Kqk+=hJppXIz@?9okKj5-|h_5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV6UA0!^P(
> zx$|8|4pbSXTP)|(c2;Mc^m~VPld{@;O$`VTAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!8Bf^huQ;?tJSns*KVtmh)*lt20hc
> zj|QJfQX+-`0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5(bUZCldD)+wgt5;VUrCTiL({@&8oSZ1HGLxi43;_ZJ2oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5ZJsx(<fE7
> zFTLn*s*KVtmh)*lt1~Xm_6_YONr@N&1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNB!d4Z-+syy}hGhLNYy2WxnZD)1HNxyGs
> zHz}*l*VKRj0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&oO`lYGrup?>t};ruSk9;Itj;(&y?^kTBqd@95FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7e?<^`HQsWLn3
> z$^BJE=@!fRw4K!%CnpXJ?IuZy7y<+c5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAh3CXrcbJT=_AK}rphSYVmY6-vpVC_?BLLD
> zl9Y%cK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pkn-^&Mq)KzL|7?{}y2WxnZD)1HNq=x?Hz}*l*VKRj0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&oO`lZxtt+Sd
> ztBleumh)*lt20hczhUs1Bqd@95FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7e?<^`HQsq%wA`tlQ1M(GyI`LvzY87C*s8rn^g
> z5-|h_5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV6UA0!^P(x$D`V>#B^>Etd0XJF7D;&8nf@Bq<R?fB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7HZRbeNUA*e2lu_T
> z$|&7pIiI$(I^(3ThIW&rL<|7}1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNB!X@Mi9z}b1z+2=3UHVHUm
> zwMjq@4c#s*?~{D<_-~xG7T7xkhVx}>fmL{SR#&U@#0Ot|el2`v2|Tc8H*i(?b2#nS
> z?s#!6a3BZsz|9w2zl!YKe^0ajHOKp2b9`ROZRa2Ts}KBHm3_H&cKnK?(@T$Dx?S$G
> z{nCBTEs=e>`1kL7*N;UGy|NL)&asj>oS#~L{;yV>A*@%p``gbQUaxS;l^=WadWF?-
> z)35ecc<Lwq`*&ac9XrF`3gu#}DSIpQ!@?T@0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBn=ut3u%RknY0!TYO>(k+(rX}eQr
> zoRkx*nY^;vJ@!t3009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXzCD8Oqm3u$^<bSI&O1D_fr|nLiadLXk&}ovCh#^3L009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0Ro#B
> zX!@keH-GZty2>csVmY6-J9Wm%iLIgCBq<R?fB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7HZRchNtIh~f96wFM(GyI`Lx}s
> zGcL`xhjx>sL<|7}1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oTu3K+`8x{=>&E`Uh1;=@!fRwB4yQPWtVk-K4BGUsD4D1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNBU
> zG<{O#=MR6mt};ruSk9;IPMvXb`i#M6l9Y%cK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pkn-^&Mq{{E_`S{OQ8Kqk+=hJql
> z&Nw-7=Fo1El!zfffB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009D<7ijvV%KeY_@2@gSw^+`n?M|I>X|{K0H%Usw5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7csfz1mv
> zeNyGFpFZ~8Dx-9Z<$T)i)EOuJ-l5&3tTta$0|EpH5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAdobDQsoEl|J*yOjM6QZ^J%+N
> zXPlfK4L*~kL<|7}1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oTu3K+`8xK77&t{dZMH=@!fRwB4yQPEM3pnMqP2h5!Kq1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72y9-U
> z>60p3@7q7AGD^2t&Zq58opEWlZ)i73O2iN#K!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB=Eb3p9OF<txAQ;s>jY(k+(rX}eQr
> zob>yKc9XK&d`%4q5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7dX()3A{r~m1v9;q@)w^+`n?M|I>a(e&ZGf7Is5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7csfz1mv
> zeNtuTn&-b)Wt48QoKM@GI^*QTfuY?bDG@_}009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXzFVOT!l`sCMBac=YrCTiL({`uM
> zxHLOBw3{R)Vh9i*K!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfWYPjnm(!WrVGFE&#H{lEtd0XyHjVJ^aqD_ld{@;O$`VTAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!8Bf
> z^huSE-c^6E$|&7pIiI#Wb;il*Hw-?Lq(lq>0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBn=yg<_@Retz`?_5@8ly0${Purb3
> z<K)CyL%T^*B8C6~0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PE+ipy`t;cRqOj2dj+IEtd0XyHjUenpH!)Nm3$)009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXFY+j%_
> zkyLsAse{*48Kqk+=hJql&N%6-q1_}Y5kr6g0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5(bTHr`2aCUy}
> zqA&mRwM_!fSZxxJLqoR<%ljmEzxeP^t_AiEf#H1FT3{94oz>Oq{QE~PE;|govgN>;
> zCGfzW-N04l&*9v6VE?~f3mnM7JaF>`*RLX%T=}s#?_WE<^}P?gdEaY}SGjX?-SP|f
> z-E{kH-KnFeZoh4Q<1Ja;;=1zM%46@l=zmn@OQ-I*>CU64PTu&QSv%WPe$TPV@vUR`
> zKk<+M<L~^7BUk_LJ5O(wW^Y(st<2$a{xc6fdhth}y5#DIkDMG`b?<p^Kc}2OxO+Os
> zhRo-7epq%>NY*R=%b)n(h3l37{(q@|dcE@M_`LF+?Y!mxTzh?$eYtgZ{PLsIouij-
> zmm6%oM00M5?8_IvaQx{XiyV3hviyYCSE1=w+d<s?w*8mCOkXZJYzI+pyqdBdL_aLN
> z5g<T-009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7csfei~ZeNyGKpLy}YDx-9Z<$Tu8>Wq_eVl|UjR=daE2@oJafB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+z@`M6KB;p2o7MSM
> zM(GyI`K+DQ87HUr44o!Pi5LO|2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FoI5fu>KY+;Hpj|GCO2-C{YPwX-_o<iys{ZjzLU
> zAwYlt0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0-G0T`lQMeSM7OEl~KCIaz1Nkb;hOH_RwyUl!zfffB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009D<7ijvV${AmK;p<gK
> z=@!fRtew>v|G#$b?$wsFFa!8=az19A<d`?kB*w$UkDMU3X-=BVP9SM6vLh+d55<<I
> zL_}62%rt`&O^kXWLJyJ)FN`11QhJeIg=*7_YE#-?6f=}4#DG>qr4)rq3tDQi7ZqBi
> z(%ExFx4G@b-25KcYrn&K_FB*W{Q++>pIp~9%W3<W77!pnfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+0D+{Plae34qkg`m$}moS
> zx9{rgl1rynpC(x<LVy4P0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1hyAw=cMG?x8DEBk}AVE_1(U!vr7(7uj`s*sR#iA1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oTs_
> zpq-PF8=kn~GbL4qaq7E$S7)~@JF~89lBFU92oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkKcdx3UNO1{*8=dO|}!#MTbzN@oK
> z<}>TMW;ty?(*gnn2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5Fn7Wb5e5O?dLyMQe_yYzT0<ocFCn`^=Xo&A_NE!AV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyKwx`;c1}v}
> z7~c3;NtI!o`flIV*(Ha|&yprtDnft&0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0tB`fXy>Hlx$f&<D5)}xQ{U~oI=f}r*>zo$
> zEEOR@fB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009Eq3$$}mGQM=-fs!i2IQ8AWtFueyv+KHMIc-1F0s;gG5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAds|kQu5IG4?R*+
> zWf-Tv+jn(#$)zh-pC(x<LVy4P0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1hyAw=cMH0=We;Xq{=W(eYfxG?2^N))^$y?RD=Kl
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PE*|(9TK8V^6;LnvyERIQ8AWtFv2{om<y6$x;yl1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNB!y+AuBC7+(|eX^v=Fiw59
> z@9ON5`P{m$Sx(!}w15Bs0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PCPUoRr*h*O%`usWOaH-|f3PyX4X<R-YzWDnft&0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0tB`f
> zXy>Hl@Y&nHRZ?Xbr@q^Fb#}?&)$6(@St>$+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjZJ7ij0C<i&5#50q3H#;Nc2U7g*s
> ztgP#rWT^-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBn=UZ6cpN<MYd=MGD%4CB;y`>xI|najGaNtTKbAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0$U4QzYKU~&cEst&mX%a;MCD20l8+~cGL3O<kUyL^4(*FGizaef4N%VsC+p`
> zpH}CqPdxJAvGVDq@brnxg?pA?*XHoHNAEpWxGLxJ^ure(JgU6mi}lS{9((S07j8cL
> zvgf1Tb$Q$L!c*^h|NDl=FFyYM_w^4wlB2J9+wyZoZv3-<8_V)XkAL7@AH4YZdmehU
> z+aH`*{-4)9d;ed2?XOS&^0V*w`{&;I_J9BK70a@#k3Mb5wafdT{qq-Z`P4uB;+y{F
> z`u9}#eDwTpUbnn|?(*BYW9_`|si$8$x;)|d<afXJdp8}Q{LnMgt;Z)HJ)d9x=45{D
> z2X9_r&gQ+{op)Wl{ovwlCzmg{;>R?vUMgqv!V7nP<7X<@{PgaI|KEgmKDrL#;orFO
> zu4DA;br8!JA7!}?VqOnk2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+z{UdYoRob2vp@PwNtI!o`flIV*(J*xM`?a?y8P^w
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXFY$ednNy(l6T5c$*GK^E-?Yla=<kE?CQ<E$eAwYlt0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0^19;b5ip5_x|VeB~^xT
> z>brecXO|pav94>9r6L3f5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV6Syfp$(xzIM-vM@y;<<J5QiuFh^*c5+?UBuhmI5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7e?
> z_5$skl$`pf@Bed2m0_IvZr|0}CG*L3U9+6FpJ@RB0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBmF+Bqrt;XCT*OR5ax)OY)?
> z&MvuhYV~Q7r6L3f5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV6Syfp$(xu6^tMpDd{|j8ot3yE?n%@btQ_NtTKbAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5;&?FHI7
> zDY@Z^8$MG~Wf-Tv+jn(#%d#`;x+YmFLVy4P0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1hyAw=cMFI{devvsWOaH-|f3PyJSAI
> zu4|Ul_A@OYK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pkNjoPc_uYQ}V<lCFaq7E$S7(=8s#c#SSt>$+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjZJ7ij0C<c{Hu
> zkCjvz#;Nc2U7cNWxcn?>lBFU92oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkKcdx3UNN}lV!{)Lh%!#MTbzN@oamYrSKHOW#D
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyu)RP#Cne)c7al07GK^E-?Yla=WInsDYnIdYGc6!MfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C?J0~R%o&V4yB~^xT
> z>brecXO~>Ma`kDFr6L3f5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV6Syfp$(xK7Q_&yGyDJ<J5QiuFftwylP$7BuhmI5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7e?
> z_5$sklsxw2i?1oEGK^E-?Yla=W!brPU6U*oAwYlt0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0^19;b5io@>E0(xstn`Qcl)l+
> zE}74*>zd`X{Y(o85FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7dX(#}cAEq8tS?vg6QIQ8AWtFucky<+uglBFU92oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkKcdx3UN
> zN)DgB{aYnfhH>h<eOG6f9A3SyYm%iR1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZV0(dfPD)<<_WVFem0_IvZr|0}Ez8Qf
> zu1S`P5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7csf$as_!=&U>H+}A~q{=W(eYfxG?2@^x>zZV#2mt~F2oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FoI%!1c?3SLXbyKJomqO9D<ET@sLM)@?T}uT4&U<SXAjRyea3*7ujI1&+#>bM$F-
> zzWT%?4<0L@UJ6g2xLmkr`E_j$Z+rCKV}+}7E>Ayv;lZQI8@^cIeC4s{es|&KvoCu-
> zzw}P#bNTIyC1>;A?#{a}-hRi$+fFXubMnXE^XjE?Hh=Z2Z~Didsa*4uix3X(SQ^*n
> zbx%G0($QrI$0xk|wcoqx_=Ja^nQlEk;pn-YkM33&Z}|Cd{`CJiSnpO?KI|yV-3s%1
> z@Irt90RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t7Y|Xy>Hlx&Qs<TS}@7<J5QigF3rpdE+R}PfnMgy%HcmfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+0D-Lp+Bqq?<4<q-
> zpOPxWIQ8BBpw2G2bYk7qBuhmI5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7e?_5$sklstIhr5j7C4CB;y`-3{W<nW4hU6U*o
> zAwYlt0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0^19;b5ios2QU0VNtI!o`fh(vXSXanxvp!Hr6L3f5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV6Syfp$(xPXFQ8PnT2~
> z#;Nc22X%JId~#jaET`>fT0npR0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0tAwFPD+08s@rcYsWOaH-|Y|T?2=2TR-YzWDnft&
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0tB`fXy>Hlx|6^Afs!i2IQ8BBpw2EiJiV@KlBFU92oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkKcdx3UNN?!BAy>BV0GK^E-
> z?GNhgmStzwbxpEVga82o1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72y8FV&PmCOKlkD{OR5ax)OY)XI=f^(v#x8F)AlnhAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0!ce3C5IpWrLm;SFiw59Kd7@yE>){flPnb>K!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk+Y7XFQgY`nocjHeD#JMS-Tt7?
> zE;(F&mNdyy5ds7V5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAh5kaJ0~Td|Gn?OzNE@9PJOpOsIyy^on6;8$x;yl1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNB!y+AuB
> zB@h4ciO-f)8OEva_6K!#$$WNQ*DR;)XIemj009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjY)c1}uu=eOSe(UK~|IQ8BBpw2G2
> zbmi*PBuhmI5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
> z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7e?_5$sklzig8@{N)z!#MTb{-Dk-IlO9J*Cb0t2oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+!1e;|oRmB|
> zf9JnTstn`Qcl(1nyJgwAbzPGz6(K-?009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0Rr0#v~yDOCpX^ka7mS6oceBmP-mCS=hk)2
> za@u~T1q28XAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyKp<)7q~ziU{^J`ZRfciuyZu3(U2^Fat51_G6(K-?009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0Rr0#v~yB&-;e53
> zB~^xT>bw0xon3Nx^}4P}mWmJ{K!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
> zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
> zAV7cs0RjXF5FkK+009C72oNAZfB=E*1==|&`O-80^4XFq!#MTb{-DloSyt9{O|n#k
> z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
> zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
> z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
> z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
> z0RjXFY%kCrCM9qF!Rvp$q{=W(eYZcTvrFc(u4|H|A_NE!AV7cs0RjXF5FkK+009C7
> z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!Cv3
> z0@p7CUYQTy`p*A4c1gggqe}vE&ARQT<+aHl{mKvj?pWc>T3Fv-t`;~dU(V5|)%nZ6
> zeeU67<<m>y=@XX=_bk7z&HY!u`h&*`SLIxue)z(JN0o=3nQp!EWzT0{_I%X4E^nJ&
> Hc<TQEiO|s7
>
> literal 0
> HcmV?d00001
>
> diff --git a/tests/misc-tests/016-send-clone-src/test.sh b/tests/misc-tests/016-send-clone-src/test.sh
> new file mode 100755
> index 0000000..c6f0abc
> --- /dev/null
> +++ b/tests/misc-tests/016-send-clone-src/test.sh
> @@ -0,0 +1,49 @@
> +#!/bin/bash
> +#
> +# test for sending stream size of clone-src option
> +
> +source $TOP/tests/common
> +
> +check_prereq mkfs.btrfs
> +check_prereq btrfs
> +
> +setup_root_helper
> +prepare_test_dev 1g
> +
> +run_check $TOP/mkfs.btrfs -f $IMAGE
> +run_check_mount_test_dev
> +
> +here=`pwd`
> +cd "$TEST_MNT" || _fail "cannot chdir to TEST_MNT"
> +
> +run_check $SUDO_HELPER $TOP/btrfs subvolume create subv-parent1
> +for i in 1 2 3; do
> + run_check $SUDO_HELPER dd if=/dev/zero of=subv-parent1/file1_$i bs=1M count=1
> + run_check $SUDO_HELPER $TOP/btrfs subvolume snapshot -r subv-parent1 subv-snap1_$i
> +done
> +
> +run_check $SUDO_HELPER $TOP/btrfs subvolume create subv-parent2
> +for i in 1 2 3; do
> + run_check $SUDO_HELPER dd if=/dev/zero of=subv-parent2/file2_$i bs=1M count=1
> + run_check $SUDO_HELPER $TOP/btrfs subvolume snapshot -r subv-parent2 subv-snap2_$i
> +done
> +
> +truncate -s0 "$here"/send-stream.img
> +chmod a+w "$here"/send-stream.img
> +run_check $SUDO_HELPER $TOP/btrfs send -f "$here"/send-stream.img \
> + -c subv-snap1_1 -c subv-snap2_1 subv-snap1_[23] subv-snap2_[23]
> +
> +old_stream_size=`stat --format=%s "$here"/send-stream-v4.8.2.img`
> +stream_size=`stat --format=%s "$here"/send-stream.img`
> +
> +if [ $old_stream_size -lt $stream_size ]; then
> + run_check ls -l "$here"/send-stream-v4.8.2.img "$here"/send-stream.img
> + _fail "sending stream size is bigger than old stream"
> +fi
> +
> +run_check rm -f "$here"/send-stream.img
> +
> +cd "$here" || _fail "cannot chdir back to test directory"
> +
> +run_check_umount_test_dev
> +
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v5 0/4] POWER9 TCG enablements - BCD functions part I
From: David Gibson @ 2016-11-09 1:16 UTC (permalink / raw)
To: Jose Ricardo Ziviani; +Cc: qemu-ppc, qemu-devel, nikunj, bharata
In-Reply-To: <1478623825-8460-1-git-send-email-joserz@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
On Tue, Nov 08, 2016 at 02:50:21PM -0200, Jose Ricardo Ziviani wrote:
> v5:
> - reuse bcd_cmp_zero function
> - improve zoned loop by using one index
>
> v4:
> - throws invalid for any instruction not implemented by default
> - creates a function to compare bcd value to zero
>
> v3:
> - generates invalid instruction excpetion when opc4 is not handled/invalid
> - changes get_national ret. type to uint16_t to handle invalid encoding
> - small improvements
>
> v2:
> - implements all fixes and suggestions
>
> This serie contains 4 new instructions for POWER9 ISA3.0
Applied to ppc-for-2.8. Note that there was a conflict in
vmx-ops.inc.c. It was pretty simple to resolve, but in future please
try to make sure your series are rebased on top of the latest
ppc-for-2.8.
>
> bcdcfn.: Decimal Convert From National
> bcdctn.: Decimal Convert To National
> bcdcfz.: Decimal Convert From Zoned
> bcdctz.: Decimal Convert to Zoned
>
>
> Jose Ricardo Ziviani (4):
> target-ppc: Implement bcdcfn. instruction
> target-ppc: Implement bcdctn. instruction
> target-ppc: Implement bcdcfz. instruction
> target-ppc: Implement bcdctz. instruction
>
> target-ppc/helper.h | 4 +
> target-ppc/int_helper.c | 186 ++++++++++++++++++++++++++++++++++++
> target-ppc/translate/vmx-impl.inc.c | 73 ++++++++++++++
> target-ppc/translate/vmx-ops.inc.c | 4 +-
> 4 files changed, 265 insertions(+), 2 deletions(-)
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] PM / devfreq: correct comment typo.
From: MyungJoo Ham @ 2016-11-09 1:39 UTC (permalink / raw)
To: linux-pm@vger.kernel.org
In-Reply-To: <CGME20161109013921epcms1p7e3a7f9daf4899a395dc0e73b1aa762df@epcms1p7>
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
The function name in the comment was incorrect.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
---
drivers/devfreq/devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index bf3ea76..a324801 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -850,7 +850,7 @@ int devfreq_add_governor(struct devfreq_governor *governor)
EXPORT_SYMBOL(devfreq_add_governor);
/**
- * devfreq_remove_device() - Remove devfreq feature from a device.
+ * devfreq_remove_governor() - Remove devfreq feature from a device.
* @governor: the devfreq governor to be removed
*/
int devfreq_remove_governor(struct devfreq_governor *governor)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4] phy: rcar-gen3-usb2: add sysfs for usb role swap
From: Peter Chen @ 2016-11-09 1:39 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: kishon, gregkh, balbi, Peter.Chen, linux-kernel, linux-usb,
linux-renesas-soc
In-Reply-To: <1478603698-21133-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
On Tue, Nov 08, 2016 at 08:14:58PM +0900, Yoshihiro Shimoda wrote:
> This patch adds sysfs "role" for usb role swap. This parameter can be
> read and write. If you use this file as the following, you can swap
> the usb role.
>
> For example:
> 1) Connect a usb cable using 2 Salvator-x boards
> 2) On A-Device (ID pin is low), you input the following command:
> # echo peripheral > /sys/devices/platform/soc/ee080200.usb-phy/role
> 3) On B-Device (ID pin is high), you input the following command:
> # echo host > /sys/devices/platform/soc/ee080200.usb-phy/role
>
> Then, the A-device acts as a peripheral and the B-device acts as a host.
> Please note that A-Device must input the following command if you
> want the board to act as a host again. (even if you disconnect the usb
> cable, since id state may be the same, the A-Device keeps to act as
> peripheral.)
> # echo host > /sys/devices/platform/soc/ee080200.usb-phy/role
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> This patch is based on the latest linux-phy.git / next branch.
> (commit id = 7809cd2ce6abd4f431e4b14e6b1276a7cc842ac4)
>
> Since this patch is related to usb, I added email addresses of Greg, Felipe,
> Peter and USB ML as CC. (This patch doesn't use USB OTG FSM though.)
>
> Changes from v3:
> - Clean up redundant conditions in role_store().
>
> Changes from v2:
> - Modify the sysfs file name to "role", and the argument is "host" or
> "peripheral". Peter suggested this. Thank you!
>
> Changes from v1:
> - rebase the latest next branch.
>
> .../ABI/testing/sysfs-platform-phy-rcar-gen3-usb2 | 15 +++
> drivers/phy/phy-rcar-gen3-usb2.c | 118 ++++++++++++++++++++-
> 2 files changed, 132 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2 b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> new file mode 100644
> index 0000000..6212697
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> @@ -0,0 +1,15 @@
> +What: /sys/devices/platform/<phy-name>/role
> +Date: October 2016
> +KernelVersion: 4.10
> +Contact: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> +Description:
> + This file can be read and write.
> + The file can show/change the phy mode for role swap of usb.
> +
> + Write the following strings to change the mode:
> + "host" - switching mode from peripheral to host.
> + "peripheral" - switching mode from host to peripheral.
> +
> + Read the file, then it shows the following strings:
> + "host" - The mode is host now.
> + "peripheral" - The mode is peripheral now.
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
> index 3d97ead..3f712b4 100644
> --- a/drivers/phy/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
> @@ -70,6 +70,7 @@
> #define USB2_LINECTRL1_DP_RPD BIT(18)
> #define USB2_LINECTRL1_DMRPD_EN BIT(17)
> #define USB2_LINECTRL1_DM_RPD BIT(16)
> +#define USB2_LINECTRL1_OPMODE_NODRV BIT(6)
>
> /* ADPCTRL */
> #define USB2_ADPCTRL_OTGSESSVLD BIT(20)
> @@ -161,6 +162,43 @@ static void rcar_gen3_init_for_peri(struct rcar_gen3_chan *ch)
> schedule_work(&ch->work);
> }
>
> +static void rcar_gen3_init_for_b_host(struct rcar_gen3_chan *ch)
> +{
> + void __iomem *usb2_base = ch->base;
> + u32 val;
> +
> + val = readl(usb2_base + USB2_LINECTRL1);
> + writel(val | USB2_LINECTRL1_OPMODE_NODRV, usb2_base + USB2_LINECTRL1);
> +
> + rcar_gen3_set_linectrl(ch, 1, 1);
> + rcar_gen3_set_host_mode(ch, 1);
> + rcar_gen3_enable_vbus_ctrl(ch, 0);
> +
> + val = readl(usb2_base + USB2_LINECTRL1);
> + writel(val & ~USB2_LINECTRL1_OPMODE_NODRV, usb2_base + USB2_LINECTRL1);
> +}
> +
> +static void rcar_gen3_init_for_a_peri(struct rcar_gen3_chan *ch)
> +{
> + rcar_gen3_set_linectrl(ch, 0, 1);
> + rcar_gen3_set_host_mode(ch, 0);
> + rcar_gen3_enable_vbus_ctrl(ch, 1);
> +}
> +
> +static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
> +{
> + void __iomem *usb2_base = ch->base;
> + u32 val;
> +
> + val = readl(usb2_base + USB2_OBINTEN);
> + writel(val & ~USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
> +
> + rcar_gen3_enable_vbus_ctrl(ch, 0);
> + rcar_gen3_init_for_host(ch);
> +
> + writel(val | USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
> +}
> +
> static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
> {
> return !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
> @@ -174,6 +212,65 @@ static void rcar_gen3_device_recognition(struct rcar_gen3_chan *ch)
> rcar_gen3_init_for_peri(ch);
> }
>
> +static bool rcar_gen3_is_host(struct rcar_gen3_chan *ch)
> +{
> + return !(readl(ch->base + USB2_COMMCTRL) & USB2_COMMCTRL_OTG_PERI);
> +}
> +
> +static ssize_t role_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> + bool is_b_device, is_host, new_mode_is_host;
> +
> + if (!ch->has_otg || !ch->phy->init_count)
> + return -EIO;
> +
> + /*
> + * is_b_device: true is B-Device. false is A-Device.
> + * If {new_mode_}is_host: true is Host mode. false is Peripheral mode.
> + */
> + is_b_device = rcar_gen3_check_id(ch);
> + is_host = rcar_gen3_is_host(ch);
> + if (!strncmp(buf, "host", strlen("host")))
> + new_mode_is_host = true;
> + else if (!strncmp(buf, "peripheral", strlen("peripheral")))
> + new_mode_is_host = false;
> + else
> + return -EINVAL;
> +
> + /* If current and new mode is the same, this returns the error */
> + if (is_host == new_mode_is_host)
> + return -EINVAL;
> +
> + if (new_mode_is_host) { /* And is_host must be false */
> + if (!is_b_device) /* A-Peripheral */
> + rcar_gen3_init_from_a_peri_to_a_host(ch);
> + if (is_b_device) /* B-Peripheral */
> + rcar_gen3_init_for_b_host(ch);
Why not use if-else? The same to below.
After fixing it, you can add my:
Reviewed-by: Peter Chen <peter.chen@nxp.com>
Peter
> + } else { /* And is_host must be true */
> + if (!is_b_device) /* A-Host */
> + rcar_gen3_init_for_a_peri(ch);
> + if (is_b_device) /* B-Host */
> + rcar_gen3_init_for_peri(ch);
> + }
> +
> + return count;
> +}
> +
> +static ssize_t role_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> +
> + if (!ch->has_otg || !ch->phy->init_count)
> + return -EIO;
> +
> + return sprintf(buf, "%s\n", rcar_gen3_is_host(ch) ? "host" :
> + "peripheral");
> +}
> +static DEVICE_ATTR_RW(role);
> +
> static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
> {
> void __iomem *usb2_base = ch->base;
> @@ -351,21 +448,40 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
> channel->vbus = NULL;
> }
>
> + platform_set_drvdata(pdev, channel);
> phy_set_drvdata(channel->phy, channel);
>
> provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> - if (IS_ERR(provider))
> + if (IS_ERR(provider)) {
> dev_err(dev, "Failed to register PHY provider\n");
> + } else if (channel->has_otg) {
> + int ret;
> +
> + ret = device_create_file(dev, &dev_attr_role);
> + if (ret < 0)
> + return ret;
> + }
>
> return PTR_ERR_OR_ZERO(provider);
> }
>
> +static int rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
> +{
> + struct rcar_gen3_chan *channel = platform_get_drvdata(pdev);
> +
> + if (channel->has_otg)
> + device_remove_file(&pdev->dev, &dev_attr_role);
> +
> + return 0;
> +};
> +
> static struct platform_driver rcar_gen3_phy_usb2_driver = {
> .driver = {
> .name = "phy_rcar_gen3_usb2",
> .of_match_table = rcar_gen3_phy_usb2_match_table,
> },
> .probe = rcar_gen3_phy_usb2_probe,
> + .remove = rcar_gen3_phy_usb2_remove,
> };
> module_platform_driver(rcar_gen3_phy_usb2_driver);
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
^ permalink raw reply
* Re: [PATCH 5/7] pci/msi: Provide pci_alloc_irq_vectors_affinity()
From: Christoph Hellwig @ 2016-11-09 1:38 UTC (permalink / raw)
To: tglx; +Cc: axboe, linux-block, linux-pci, linux-kernel
In-Reply-To: <1478654107-7384-6-git-send-email-hch@lst.de>
And the subject for this should be PCI/MSI like for the others, sorry.
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
From: Matt Roper @ 2016-11-09 1:38 UTC (permalink / raw)
To: Paulo Zanoni; +Cc: intel-gfx, stable
In-Reply-To: <1478636531-6081-1-git-send-email-paulo.r.zanoni@intel.com>
On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> The previous spec version said "double Ytile planes minimum lines",
> and I interpreted this as referring to what the spec calls "Y tile
> minimum", but in fact it was referring to what the spec calls "Minimum
> Scanlines for Y tile". I noticed that Mahesh Kumar had a different
> interpretation, so I sent and email to the spec authors and got
> clarification on the correct meaning. Also, BSpec was updated and
> should be clear now.
>
> Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the memory bandwidth WA")
> Cc: stable@vger.kernel.org
> Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
This seems to match my reading of the spec update from Nov 4th, so:
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index cc9e0c0..653525f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
> y_min_scanlines = 4;
> }
>
> + if (apply_memory_bw_wa)
> + y_min_scanlines *= 2;
> +
> plane_bytes_per_line = width * cpp;
> if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> @@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
> plane_blocks_per_line);
>
> y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
> - if (apply_memory_bw_wa)
> - y_tile_minimum *= 2;
>
> if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> --
> 2.7.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
^ 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.