From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F216BCD5BA4 for ; Tue, 19 May 2026 12:44:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jO8lU9nZfaIXvi4aM14Apu8W/4/KaBQAgvYJVbl8iHA=; b=JfDh1Pqhx+Ex4Xx/cABqMrAbqu RhS0vx48I397TWh1gE3uPyOk/Hor2XHNK3bGCpJnxbRjs7Nh8qraENCBuTV1uP2K+DwllqXe/z3d7 6RH4w8+8lDLn4Gzwmr87Mg6w5pZJcfnLs9sZX7WhuO2pMrYMO18q/bXtUf/p23CdOMgi8iqoYdBcp w7NV8XSSLaJlUD0RYwW4eNN1NTHPNuPB3qb6tI8m9Myrk7wyjbjHr/WYs9c2eRJ5Za1gk0o+Hjp3G Nb2gyorZOd49nmD/2dKtxpl54Q3F40n7040pzPOng0CJCnEbRQ4fW5jwaPiTPyESjDTTeCAJEwY6c jYBmLg1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPJno-00000001Vxe-2NEC; Tue, 19 May 2026 12:44:04 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPJnn-00000001Vx0-3F9B; Tue, 19 May 2026 12:44:03 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 395EA60129; Tue, 19 May 2026 12:44:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23CD8C2BCC6; Tue, 19 May 2026 12:43:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779194642; bh=kMUFbNwBqvJpO+Bjd3l9GBxXRf0w6ZacFORzSNgGrqw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bfo4BDRfvA9myn7305sBhrTH2J0JJJLZN41DyiCsBL5RaW4yJzwWoRjqEv4bw7XRu 3sS6wrONgvzJAEmXQdyWNoxP7IRgXT+BwOJdEatfiHb5tGo3e7Wv57MRVS0Mfl/KwF x37oBTK95eNvN0DhfsqWoIm8NOxS3mlo/N7lra4/86d92nRL8dOyMRTzXe4aNafoSP zmYFhFt5OepkId8YyQ/JRMelvQ33s7dDez4kr7Q7tGi40FybpnQQzZ966Ac5xeTssH 5GqAFt9tX2CAZo6ci+b6JD7q1AC8DXMlEmsrGOnNr7zIOL1N/xCP/W2AdAHZDtwZKR +0JGj8KZOVUKg== Date: Tue, 19 May 2026 13:43:52 +0100 From: Lorenzo Stoakes To: Barry Song Cc: Matthew Wilcox , surenb@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, mhocko@suse.com, jack@suse.cz, pfalcato@suse.de, wanglian@kylinos.cn, chentao@kylinos.cn, lianux.mm@gmail.com, kunwu.chan@gmail.com, liyangouwen1@oppo.com, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, Nanzhe Zhao Subject: Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance Message-ID: References: <20260430040427.4672-1-baohua@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, May 18, 2026 at 07:25:54PM +0800, Barry Song wrote: > On Mon, May 18, 2026 at 5:47 PM Lorenzo Stoakes wrote: > > > > On Sun, May 17, 2026 at 04:45:15PM +0800, Barry Song wrote: > > > On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox wrote: > > > > > > > > On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote: > > > > > On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox wrote: > > > > > > > > > > > > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote: > > > > > > > 1. There is no deterministic latency for I/O completion. It depends on > > > > > > > both the hardware and the software stack (bio/request queues and the > > > > > > > block scheduler). Sometimes the latency is short; at other times it can > > > > > > > be quite long. In such cases, a high-priority thread performing operations > > > > > > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait > > > > > > > for an unpredictable amount of time. > > > > > > > > > > > > But does that actually happen? I find it hard to believe that thread A > > > > > > unmaps a VMA while thread B is in the middle of taking a page fault in > > > > > > that same VMA. mprotect() and madvise() are more likely to happen, but > > > > > > it still seems really unlikely to me. > > > > > > > > > > It doesn’t have to involve unmapping or applying mprotect to > > > > > the entire VMA—just a portion of it is sufficient. > > > > > > > > Yes, but that still fails to answer "does this actually happen". How much > > > > performance is all this complexity in the page fault handler buying us? > > > > If you don't answer this question, I'm just going to go in and rip it > > > > all out. > > > > > > > > > > Hi Matthew (and Lorenzo, Jan, and anyone else who may be > > > waiting for answers), > > > > > > As promised during LSF/MM/BPF, we conducted thorough > > > testing on Android phones to determine whether performing > > > I/O in `filemap_fault()` can block `vma_start_write()`. > > > I wanted to give a quick update on this question. > > > > > > Nanzhe at Xiaomi created tracing scripts and ran various > > > applications on Android devices with I/O performed under > > > the VMA lock in `filemap_fault()`. We found that: > > > > > > 1. There are very few cases where unmap() is blocked by > > > page faults. I assume this is due to buggy user code > > > or poor synchronization between reads and unmap(). > > > So I assume it is not a problem. > > > > > > 2. We observed many cases where `vma_start_write()` > > > is blocked by page-fault I/O in some applications. > > > The blocking occurs in the `dup_mmap()` path during > > > fork(). > > > > > > With Suren's commit fb49c455323ff ("fork: lock VMAs of > > > the parent process when forking"), we now always hold > > > `vma_write_lock()` for each VMA. Note that the > > > `mmap_lock` write lock is also held, which could lead to > > > chained waiting if page-fault I/O is performed without > > > releasing the VMA lock. > > > > Hm but did you observe this 'chained waiting'? And what were the latencies? > > We have clearly observed that the `fork()` operations of many > popular Android apps, such as iQiyi, Baidu Tieba, and 10086, > end up waiting on page-fault (PF) I/O when the VMA lock is > held during I/O operations. This has already become a > practical issue. I also believe this can lead to chained > waiting, since the global `mmap_lock` blocks all threads that > need to acquire it. I asked about the chained waiting :) I'm aware you've observed contention on write lock, you said so in your LSF talk. So have you observed that or is this a theory? > > > > > > > > > > My gut feeling is that Suren's commit may be overshooting, > > > so my rough idea is that we might want to do something like > > > the following (we haven't tested it yet and it might be > > > wrong): > > > > Yeah I'm really not sure about that. > > > > Prior to the VMA locks, the mmap write lock would have guaranteed no concurrent > > page faults, which is really what Fb49c455323ff is about. > > > > So Suren's patch was essentially restoring the _existing_ forking behaviour, and > > now you're saying 'let's change the forking behaviour that's been like that for > > forever'. > > > I am afraid not. Before we introduced the per-VMA lock, we > were not performing I/O while holding `mmap_lock`. A page fault > that needed I/O would drop the `mmap_lock` read lock and allow > `fork()` to proceed. Err I'm talking about fork? The patch you reference is a change to fork? So you're saying that Fb49c455323ff which explicitly takes the VMA write lock on fork, was somehow an addendum after fork didnt take the mmap write lock? I must be imagining https://elixir.bootlin.com/linux/v6.0/source/kernel/fork.c#L590 then in v6.0 pre-vma locks :) I suspect that's _not_ what you're saying, so now what you're suggesting as I stated above, is to fundamentally change fork behaviour to account for the existing per-VMA lock behaviour on the fault path? Again I state - are you really sure you want to fundamentally change fork behaviour for this? I am extremely concerned about doing that. > > Now, you are suggesting performing I/O while holding the VMA > lock, which changes the requirements and introduces this > problem. > > > > > I think you would _really_ have to be sure that's safe. And forking is a very > > dangerous time in terms of complexity and sensitivity and 'weird stuff' > > happening so I'd tread _very_ carefully here. > > Yep. I think my original proposal did not require any changes > to `fork()`, since it simply preserved the current behavior of > dropping the VMA lock before performing I/O. In that model, > `fork()` would not end up waiting on I/O at all. > > What you are suggesting now appears to be performing I/O while > holding the VMA lock, which in turn introduces the need to > change `fork()`. Again, you're saying we should fundamentally change the way fork has worked forever to work around something else. At LSF I raised the fact that Josef himself suggested we simply drop this I/O waiting behaviour for file-backed mapppings. Isn't there a way forward that way rather than 'hey let's drop locks and hope for the best!' I am really reticent about this because we've seen HORRIBLE bugs come from fork behaviour, especially edge cases, and mm testing isn't great so I am basically opposed to this, and you're not really convincing me here. > > > > > > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > > index 2311ae7c2ff4..5ddaf297f31a 100644 > > > --- a/mm/mmap.c > > > +++ b/mm/mmap.c > > > @@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct > > > *mm, struct mm_struct *oldmm) > > > for_each_vma(vmi, mpnt) { > > > struct file *file; > > > > > > - retval = vma_start_write_killable(mpnt); > > > + /* > > > + * For anonymous or writable private VMAs, prevent > > > + * concurrent CoW faults. > > > + */ > > > > To nit pick I think the comment's confusing but also tells you you don't need to > > specific anon check - writable private is sufficient. And it's not really just > > CoW that's the issue, it's anon_vma population _at all_ as well as CoW. > > > > > + if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) && > > > + (mpnt->vm_flags & VM_WRITE))) > > > + retval = vma_start_write_killable(mpnt); > > > > I think this has to be VM_MAYWRITE, because somebody could otherwise mprotect() > > it R/W. > > > > I also don't understand why !mpnt->vm_file for a read-only anon mapping (more > > likely PROT_NONE) is here, just do the second check? > > > > (Also please use the new interface, so !vma_test(mpnt, VMA_SHARED_BIT) && > > vma_test(mpnt, VMA_MAYWRITE_BIT)) > > Yep, I can definitely refine the check further. But before > doing that, I'd first like to confirm that we are aligned on > the direction. > > If you still intend to hold the VMA lock while performing I/O, > then I think we should fix `fork()` to avoid taking > `vma_start_write()`. Yeah or we could do something different, it isn't a case of you get to do one of two options you propose - the maintainers decide which way is appropriate. Of the two options dropping the lock on the fault path rather than this fork insanity is my preference but I wonder if we can't find another way. Let me read through the series and give more thoughts I guess. > > > > > > if (retval < 0) > > > goto loop_out; > > > if (mpnt->vm_flags & VM_DONTCOPY) { > > > > > > Based on the above, we may want to re-check whether fork() > > > can be blocked by page faults. At the same time, if Suren, > > > you, or anyone else has any comments, please feel free to > > > share them. > > > > > > Best Regards > > > Barry > > > > Technical commentary above is sort of 'just cos' :) because I really question > > doing this honestly. > > I think we either need to fix `fork()`, or keep the current > behavior of dropping the VMA lock before performing I/O. Yup you said :) > > > > > I'd also like to get Suren's input, however. > > Yes. of course. > > > > > Thanks, Lorenzo > > Best Regards > Barry Thanks, Lorenzo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D91E1CD5BA6 for ; Tue, 19 May 2026 12:44:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bujXT0INzW35tpL3W3XGaZ5azhra7UIHds8k7xovrAM=; b=zp4mj5PF0h5Z60 FBUrXhv0LSJtmB4dwWABvJ+sSELmS1VyuX8QmUnD0Ur18aj/rrr0V74OkQ6PZf0vfDOpoYCAjiWD+ vFoTXwT3O5bQ73T8r5dOYwoPLTYu6T6viMfpMyWQ3hBTEDLjaOh/W8HJirTI7HEkJ7qOdRoBM8PNZ J9SO1Cb4CDewoJmo30kxY4eDCjeOUvZuedeXlBlYmndm4FO2CRRXsQpq/FKA8G1feU3zcL/uqJ9hw eaN2NTU6yrQPUdqJD3vmbqbgeM2QqFLbLSZnbtlJ7IjawsaBzafGztG21Ji8dTTodskCQ5Lo6/QkK ZBkdTqI6jYQryL1gTlFw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPJno-00000001Vxs-33Xs; Tue, 19 May 2026 12:44:04 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPJnn-00000001Vx0-3F9B; Tue, 19 May 2026 12:44:03 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 395EA60129; Tue, 19 May 2026 12:44:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23CD8C2BCC6; Tue, 19 May 2026 12:43:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779194642; bh=kMUFbNwBqvJpO+Bjd3l9GBxXRf0w6ZacFORzSNgGrqw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bfo4BDRfvA9myn7305sBhrTH2J0JJJLZN41DyiCsBL5RaW4yJzwWoRjqEv4bw7XRu 3sS6wrONgvzJAEmXQdyWNoxP7IRgXT+BwOJdEatfiHb5tGo3e7Wv57MRVS0Mfl/KwF x37oBTK95eNvN0DhfsqWoIm8NOxS3mlo/N7lra4/86d92nRL8dOyMRTzXe4aNafoSP zmYFhFt5OepkId8YyQ/JRMelvQ33s7dDez4kr7Q7tGi40FybpnQQzZ966Ac5xeTssH 5GqAFt9tX2CAZo6ci+b6JD7q1AC8DXMlEmsrGOnNr7zIOL1N/xCP/W2AdAHZDtwZKR +0JGj8KZOVUKg== Date: Tue, 19 May 2026 13:43:52 +0100 From: Lorenzo Stoakes To: Barry Song Cc: Matthew Wilcox , surenb@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, mhocko@suse.com, jack@suse.cz, pfalcato@suse.de, wanglian@kylinos.cn, chentao@kylinos.cn, lianux.mm@gmail.com, kunwu.chan@gmail.com, liyangouwen1@oppo.com, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, Nanzhe Zhao Subject: Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance Message-ID: References: <20260430040427.4672-1-baohua@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gTW9uLCBNYXkgMTgsIDIwMjYgYXQgMDc6MjU6NTRQTSArMDgwMCwgQmFycnkgU29uZyB3cm90 ZToKPiBPbiBNb24sIE1heSAxOCwgMjAyNiBhdCA1OjQ34oCvUE0gTG9yZW56byBTdG9ha2VzIDxs anNAa2VybmVsLm9yZz4gd3JvdGU6Cj4gPgo+ID4gT24gU3VuLCBNYXkgMTcsIDIwMjYgYXQgMDQ6 NDU6MTVQTSArMDgwMCwgQmFycnkgU29uZyB3cm90ZToKPiA+ID4gT24gU2F0LCBNYXkgMiwgMjAy NiBhdCAxOjU44oCvQU0gTWF0dGhldyBXaWxjb3ggPHdpbGx5QGluZnJhZGVhZC5vcmc+IHdyb3Rl Ogo+ID4gPiA+Cj4gPiA+ID4gT24gU2F0LCBNYXkgMDIsIDIwMjYgYXQgMDE6NDQ6MzRBTSArMDgw MCwgQmFycnkgU29uZyB3cm90ZToKPiA+ID4gPiA+IE9uIEZyaSwgTWF5IDEsIDIwMjYgYXQgMTA6 NTfigK9QTSBNYXR0aGV3IFdpbGNveCA8d2lsbHlAaW5mcmFkZWFkLm9yZz4gd3JvdGU6Cj4gPiA+ ID4gPiA+Cj4gPiA+ID4gPiA+IE9uIEZyaSwgTWF5IDAxLCAyMDI2IGF0IDA2OjQ5OjU4QU0gKzA4 MDAsIEJhcnJ5IFNvbmcgd3JvdGU6Cj4gPiA+ID4gPiA+ID4gMS4gVGhlcmUgaXMgbm8gZGV0ZXJt aW5pc3RpYyBsYXRlbmN5IGZvciBJL08gY29tcGxldGlvbi4gSXQgZGVwZW5kcyBvbgo+ID4gPiA+ ID4gPiA+IGJvdGggdGhlIGhhcmR3YXJlIGFuZCB0aGUgc29mdHdhcmUgc3RhY2sgKGJpby9yZXF1 ZXN0IHF1ZXVlcyBhbmQgdGhlCj4gPiA+ID4gPiA+ID4gYmxvY2sgc2NoZWR1bGVyKS4gU29tZXRp bWVzIHRoZSBsYXRlbmN5IGlzIHNob3J0OyBhdCBvdGhlciB0aW1lcyBpdCBjYW4KPiA+ID4gPiA+ ID4gPiBiZSBxdWl0ZSBsb25nLiBJbiBzdWNoIGNhc2VzLCBhIGhpZ2gtcHJpb3JpdHkgdGhyZWFk IHBlcmZvcm1pbmcgb3BlcmF0aW9ucwo+ID4gPiA+ID4gPiA+IHN1Y2ggYXMgbXByb3RlY3QsIHVu bWFwLCBwcmN0bF9zZXRfdm1hLCBvciBtYWR2aXNlIG1heSBiZSBmb3JjZWQgdG8gd2FpdAo+ID4g PiA+ID4gPiA+IGZvciBhbiB1bnByZWRpY3RhYmxlIGFtb3VudCBvZiB0aW1lLgo+ID4gPiA+ID4g Pgo+ID4gPiA+ID4gPiBCdXQgZG9lcyB0aGF0IGFjdHVhbGx5IGhhcHBlbj8gIEkgZmluZCBpdCBo YXJkIHRvIGJlbGlldmUgdGhhdCB0aHJlYWQgQQo+ID4gPiA+ID4gPiB1bm1hcHMgYSBWTUEgd2hp bGUgdGhyZWFkIEIgaXMgaW4gdGhlIG1pZGRsZSBvZiB0YWtpbmcgYSBwYWdlIGZhdWx0IGluCj4g PiA+ID4gPiA+IHRoYXQgc2FtZSBWTUEuICBtcHJvdGVjdCgpIGFuZCBtYWR2aXNlKCkgYXJlIG1v cmUgbGlrZWx5IHRvIGhhcHBlbiwgYnV0Cj4gPiA+ID4gPiA+IGl0IHN0aWxsIHNlZW1zIHJlYWxs eSB1bmxpa2VseSB0byBtZS4KPiA+ID4gPiA+Cj4gPiA+ID4gPiBJdCBkb2VzbuKAmXQgaGF2ZSB0 byBpbnZvbHZlIHVubWFwcGluZyBvciBhcHBseWluZyBtcHJvdGVjdCB0bwo+ID4gPiA+ID4gdGhl IGVudGlyZSBWTUHigJRqdXN0IGEgcG9ydGlvbiBvZiBpdCBpcyBzdWZmaWNpZW50Lgo+ID4gPiA+ Cj4gPiA+ID4gWWVzLCBidXQgdGhhdCBzdGlsbCBmYWlscyB0byBhbnN3ZXIgImRvZXMgdGhpcyBh Y3R1YWxseSBoYXBwZW4iLiAgSG93IG11Y2gKPiA+ID4gPiBwZXJmb3JtYW5jZSBpcyBhbGwgdGhp cyBjb21wbGV4aXR5IGluIHRoZSBwYWdlIGZhdWx0IGhhbmRsZXIgYnV5aW5nIHVzPwo+ID4gPiA+ IElmIHlvdSBkb24ndCBhbnN3ZXIgdGhpcyBxdWVzdGlvbiwgSSdtIGp1c3QgZ29pbmcgdG8gZ28g aW4gYW5kIHJpcCBpdAo+ID4gPiA+IGFsbCBvdXQuCj4gPiA+ID4KPiA+ID4KPiA+ID4gSGkgTWF0 dGhldyAoYW5kIExvcmVuem8sIEphbiwgYW5kIGFueW9uZSBlbHNlIHdobyBtYXkgYmUKPiA+ID4g d2FpdGluZyBmb3IgYW5zd2VycyksCj4gPiA+Cj4gPiA+IEFzIHByb21pc2VkIGR1cmluZyBMU0Yv TU0vQlBGLCB3ZSBjb25kdWN0ZWQgdGhvcm91Z2gKPiA+ID4gdGVzdGluZyBvbiBBbmRyb2lkIHBo b25lcyB0byBkZXRlcm1pbmUgd2hldGhlciBwZXJmb3JtaW5nCj4gPiA+IEkvTyBpbiBgZmlsZW1h cF9mYXVsdCgpYCBjYW4gYmxvY2sgYHZtYV9zdGFydF93cml0ZSgpYC4KPiA+ID4gSSB3YW50ZWQg dG8gZ2l2ZSBhIHF1aWNrIHVwZGF0ZSBvbiB0aGlzIHF1ZXN0aW9uLgo+ID4gPgo+ID4gPiBOYW56 aGUgYXQgWGlhb21pIGNyZWF0ZWQgdHJhY2luZyBzY3JpcHRzIGFuZCByYW4gdmFyaW91cwo+ID4g PiBhcHBsaWNhdGlvbnMgb24gQW5kcm9pZCBkZXZpY2VzIHdpdGggSS9PIHBlcmZvcm1lZCB1bmRl cgo+ID4gPiB0aGUgVk1BIGxvY2sgaW4gYGZpbGVtYXBfZmF1bHQoKWAuIFdlIGZvdW5kIHRoYXQ6 Cj4gPiA+Cj4gPiA+IDEuIFRoZXJlIGFyZSB2ZXJ5IGZldyBjYXNlcyB3aGVyZSB1bm1hcCgpIGlz IGJsb2NrZWQgYnkKPiA+ID4gICAgcGFnZSBmYXVsdHMuIEkgYXNzdW1lIHRoaXMgaXMgZHVlIHRv IGJ1Z2d5IHVzZXIgY29kZQo+ID4gPiAgICBvciBwb29yIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVu IHJlYWRzIGFuZCB1bm1hcCgpLgo+ID4gPiBTbyBJIGFzc3VtZSBpdCBpcyBub3QgYSBwcm9ibGVt Lgo+ID4gPgo+ID4gPiAyLiBXZSBvYnNlcnZlZCBtYW55IGNhc2VzIHdoZXJlIGB2bWFfc3RhcnRf d3JpdGUoKWAKPiA+ID4gICAgaXMgYmxvY2tlZCBieSBwYWdlLWZhdWx0IEkvTyBpbiBzb21lIGFw cGxpY2F0aW9ucy4KPiA+ID4gICAgVGhlIGJsb2NraW5nIG9jY3VycyBpbiB0aGUgYGR1cF9tbWFw KClgIHBhdGggZHVyaW5nCj4gPiA+ICAgIGZvcmsoKS4KPiA+ID4KPiA+ID4gV2l0aCBTdXJlbidz IGNvbW1pdCBmYjQ5YzQ1NTMyM2ZmICgiZm9yazogbG9jayBWTUFzIG9mCj4gPiA+IHRoZSBwYXJl bnQgcHJvY2VzcyB3aGVuIGZvcmtpbmciKSwgd2Ugbm93IGFsd2F5cyBob2xkCj4gPiA+IGB2bWFf d3JpdGVfbG9jaygpYCBmb3IgZWFjaCBWTUEuIE5vdGUgdGhhdCB0aGUKPiA+ID4gYG1tYXBfbG9j a2Agd3JpdGUgbG9jayBpcyBhbHNvIGhlbGQsIHdoaWNoIGNvdWxkIGxlYWQgdG8KPiA+ID4gY2hh aW5lZCB3YWl0aW5nIGlmIHBhZ2UtZmF1bHQgSS9PIGlzIHBlcmZvcm1lZCB3aXRob3V0Cj4gPiA+ IHJlbGVhc2luZyB0aGUgVk1BIGxvY2suCj4gPgo+ID4gSG0gYnV0IGRpZCB5b3Ugb2JzZXJ2ZSB0 aGlzICdjaGFpbmVkIHdhaXRpbmcnPyBBbmQgd2hhdCB3ZXJlIHRoZSBsYXRlbmNpZXM/Cj4KPiBX ZSBoYXZlIGNsZWFybHkgb2JzZXJ2ZWQgdGhhdCB0aGUgYGZvcmsoKWAgb3BlcmF0aW9ucyBvZiBt YW55Cj4gcG9wdWxhciBBbmRyb2lkIGFwcHMsIHN1Y2ggYXMgaVFpeWksIEJhaWR1IFRpZWJhLCBh bmQgMTAwODYsCj4gZW5kIHVwIHdhaXRpbmcgb24gcGFnZS1mYXVsdCAoUEYpIEkvTyB3aGVuIHRo ZSBWTUEgbG9jayBpcwo+IGhlbGQgZHVyaW5nIEkvTyBvcGVyYXRpb25zLiBUaGlzIGhhcyBhbHJl YWR5IGJlY29tZSBhCj4gcHJhY3RpY2FsIGlzc3VlLiBJIGFsc28gYmVsaWV2ZSB0aGlzIGNhbiBs ZWFkIHRvIGNoYWluZWQKPiB3YWl0aW5nLCBzaW5jZSB0aGUgZ2xvYmFsIGBtbWFwX2xvY2tgIGJs b2NrcyBhbGwgdGhyZWFkcyB0aGF0Cj4gbmVlZCB0byBhY3F1aXJlIGl0LgoKSSBhc2tlZCBhYm91 dCB0aGUgY2hhaW5lZCB3YWl0aW5nIDopIEknbSBhd2FyZSB5b3UndmUgb2JzZXJ2ZWQgY29udGVu dGlvbiBvbgp3cml0ZSBsb2NrLCB5b3Ugc2FpZCBzbyBpbiB5b3VyIExTRiB0YWxrLgoKU28gaGF2 ZSB5b3Ugb2JzZXJ2ZWQgdGhhdCBvciBpcyB0aGlzIGEgdGhlb3J5PwoKPgo+Cj4gPgo+ID4gPgo+ ID4gPiBNeSBndXQgZmVlbGluZyBpcyB0aGF0IFN1cmVuJ3MgY29tbWl0IG1heSBiZSBvdmVyc2hv b3RpbmcsCj4gPiA+IHNvIG15IHJvdWdoIGlkZWEgaXMgdGhhdCB3ZSBtaWdodCB3YW50IHRvIGRv IHNvbWV0aGluZyBsaWtlCj4gPiA+IHRoZSBmb2xsb3dpbmcgKHdlIGhhdmVuJ3QgdGVzdGVkIGl0 IHlldCBhbmQgaXQgbWlnaHQgYmUKPiA+ID4gd3JvbmcpOgo+ID4KPiA+IFllYWggSSdtIHJlYWxs eSBub3Qgc3VyZSBhYm91dCB0aGF0Lgo+ID4KPiA+IFByaW9yIHRvIHRoZSBWTUEgbG9ja3MsIHRo ZSBtbWFwIHdyaXRlIGxvY2sgd291bGQgaGF2ZSBndWFyYW50ZWVkIG5vIGNvbmN1cnJlbnQKPiA+ IHBhZ2UgZmF1bHRzLCB3aGljaCBpcyByZWFsbHkgd2hhdCBGYjQ5YzQ1NTMyM2ZmIGlzIGFib3V0 Lgo+ID4KPiA+IFNvIFN1cmVuJ3MgcGF0Y2ggd2FzIGVzc2VudGlhbGx5IHJlc3RvcmluZyB0aGUg X2V4aXN0aW5nXyBmb3JraW5nIGJlaGF2aW91ciwgYW5kCj4gPiBub3cgeW91J3JlIHNheWluZyAn bGV0J3MgY2hhbmdlIHRoZSBmb3JraW5nIGJlaGF2aW91ciB0aGF0J3MgYmVlbiBsaWtlIHRoYXQg Zm9yCj4gPiBmb3JldmVyJy4KPgo+Cj4gSSBhbSBhZnJhaWQgbm90LiBCZWZvcmUgd2UgaW50cm9k dWNlZCB0aGUgcGVyLVZNQSBsb2NrLCB3ZQo+IHdlcmUgbm90IHBlcmZvcm1pbmcgSS9PIHdoaWxl IGhvbGRpbmcgYG1tYXBfbG9ja2AuIEEgcGFnZSBmYXVsdAo+IHRoYXQgbmVlZGVkIEkvTyB3b3Vs ZCBkcm9wIHRoZSBgbW1hcF9sb2NrYCByZWFkIGxvY2sgYW5kIGFsbG93Cj4gYGZvcmsoKWAgdG8g cHJvY2VlZC4KCkVyciBJJ20gdGFsa2luZyBhYm91dCBmb3JrPyBUaGUgcGF0Y2ggeW91IHJlZmVy ZW5jZSBpcyBhIGNoYW5nZSB0byBmb3JrPwoKU28geW91J3JlIHNheWluZyB0aGF0IEZiNDljNDU1 MzIzZmYgd2hpY2ggZXhwbGljaXRseSB0YWtlcyB0aGUgVk1BIHdyaXRlIGxvY2sgb24KZm9yaywg d2FzIHNvbWVob3cgYW4gYWRkZW5kdW0gYWZ0ZXIgZm9yayBkaWRudCB0YWtlIHRoZSBtbWFwIHdy aXRlIGxvY2s/CgpJIG11c3QgYmUgaW1hZ2luaW5nCmh0dHBzOi8vZWxpeGlyLmJvb3RsaW4uY29t L2xpbnV4L3Y2LjAvc291cmNlL2tlcm5lbC9mb3JrLmMjTDU5MCB0aGVuIGluIHY2LjAKcHJlLXZt YSBsb2NrcyA6KQoKSSBzdXNwZWN0IHRoYXQncyBfbm90XyB3aGF0IHlvdSdyZSBzYXlpbmcsIHNv IG5vdyB3aGF0IHlvdSdyZSBzdWdnZXN0aW5nIGFzIEkKc3RhdGVkIGFib3ZlLCBpcyB0byBmdW5k YW1lbnRhbGx5IGNoYW5nZSBmb3JrIGJlaGF2aW91ciB0byBhY2NvdW50IGZvciB0aGUKZXhpc3Rp bmcgcGVyLVZNQSBsb2NrIGJlaGF2aW91ciBvbiB0aGUgZmF1bHQgcGF0aD8KCkFnYWluIEkgc3Rh dGUgLSBhcmUgeW91IHJlYWxseSBzdXJlIHlvdSB3YW50IHRvIGZ1bmRhbWVudGFsbHkgY2hhbmdl IGZvcmsKYmVoYXZpb3VyIGZvciB0aGlzPwoKSSBhbSBleHRyZW1lbHkgY29uY2VybmVkIGFib3V0 IGRvaW5nIHRoYXQuCgo+Cj4gTm93LCB5b3UgYXJlIHN1Z2dlc3RpbmcgcGVyZm9ybWluZyBJL08g d2hpbGUgaG9sZGluZyB0aGUgVk1BCj4gbG9jaywgd2hpY2ggY2hhbmdlcyB0aGUgcmVxdWlyZW1l bnRzIGFuZCBpbnRyb2R1Y2VzIHRoaXMKPiBwcm9ibGVtLgo+Cj4gPgo+ID4gSSB0aGluayB5b3Ug d291bGQgX3JlYWxseV8gaGF2ZSB0byBiZSBzdXJlIHRoYXQncyBzYWZlLiBBbmQgZm9ya2luZyBp cyBhIHZlcnkKPiA+IGRhbmdlcm91cyB0aW1lIGluIHRlcm1zIG9mIGNvbXBsZXhpdHkgYW5kIHNl bnNpdGl2aXR5IGFuZCAnd2VpcmQgc3R1ZmYnCj4gPiBoYXBwZW5pbmcgc28gSSdkIHRyZWFkIF92 ZXJ5XyBjYXJlZnVsbHkgaGVyZS4KPgo+IFllcC4gSSB0aGluayBteSBvcmlnaW5hbCBwcm9wb3Nh bCBkaWQgbm90IHJlcXVpcmUgYW55IGNoYW5nZXMKPiB0byBgZm9yaygpYCwgc2luY2UgaXQgc2lt cGx5IHByZXNlcnZlZCB0aGUgY3VycmVudCBiZWhhdmlvciBvZgo+IGRyb3BwaW5nIHRoZSBWTUEg bG9jayBiZWZvcmUgcGVyZm9ybWluZyBJL08uIEluIHRoYXQgbW9kZWwsCj4gYGZvcmsoKWAgd291 bGQgbm90IGVuZCB1cCB3YWl0aW5nIG9uIEkvTyBhdCBhbGwuCj4KPiBXaGF0IHlvdSBhcmUgc3Vn Z2VzdGluZyBub3cgYXBwZWFycyB0byBiZSBwZXJmb3JtaW5nIEkvTyB3aGlsZQo+IGhvbGRpbmcg dGhlIFZNQSBsb2NrLCB3aGljaCBpbiB0dXJuIGludHJvZHVjZXMgdGhlIG5lZWQgdG8KPiBjaGFu Z2UgYGZvcmsoKWAuCgpBZ2FpbiwgeW91J3JlIHNheWluZyB3ZSBzaG91bGQgZnVuZGFtZW50YWxs eSBjaGFuZ2UgdGhlIHdheSBmb3JrIGhhcyB3b3JrZWQKZm9yZXZlciB0byB3b3JrIGFyb3VuZCBz b21ldGhpbmcgZWxzZS4KCkF0IExTRiBJIHJhaXNlZCB0aGUgZmFjdCB0aGF0IEpvc2VmIGhpbXNl bGYgc3VnZ2VzdGVkIHdlIHNpbXBseSBkcm9wIHRoaXMgSS9PCndhaXRpbmcgYmVoYXZpb3VyIGZv ciBmaWxlLWJhY2tlZCBtYXBwcGluZ3MuIElzbid0IHRoZXJlIGEgd2F5IGZvcndhcmQgdGhhdCB3 YXkKcmF0aGVyIHRoYW4gJ2hleSBsZXQncyBkcm9wIGxvY2tzIGFuZCBob3BlIGZvciB0aGUgYmVz dCEnCgpJIGFtIHJlYWxseSByZXRpY2VudCBhYm91dCB0aGlzIGJlY2F1c2Ugd2UndmUgc2VlbiBI T1JSSUJMRSBidWdzIGNvbWUgZnJvbSBmb3JrCmJlaGF2aW91ciwgZXNwZWNpYWxseSBlZGdlIGNh c2VzLCBhbmQgbW0gdGVzdGluZyBpc24ndCBncmVhdCBzbyBJIGFtIGJhc2ljYWxseQpvcHBvc2Vk IHRvIHRoaXMsIGFuZCB5b3UncmUgbm90IHJlYWxseSBjb252aW5jaW5nIG1lIGhlcmUuCgo+Cj4g Pgo+ID4gPgo+ID4gPiBkaWZmIC0tZ2l0IGEvbW0vbW1hcC5jIGIvbW0vbW1hcC5jCj4gPiA+IGlu ZGV4IDIzMTFhZTdjMmZmNC4uNWRkYWYyOTdmMzFhIDEwMDY0NAo+ID4gPiAtLS0gYS9tbS9tbWFw LmMKPiA+ID4gKysrIGIvbW0vbW1hcC5jCj4gPiA+IEBAIC0xNzYyLDcgKzE3NjIsMTMgQEAgX19s YXRlbnRfZW50cm9weSBpbnQgZHVwX21tYXAoc3RydWN0IG1tX3N0cnVjdAo+ID4gPiAqbW0sIHN0 cnVjdCBtbV9zdHJ1Y3QgKm9sZG1tKQo+ID4gPiAgICAgICAgIGZvcl9lYWNoX3ZtYSh2bWksIG1w bnQpIHsKPiA+ID4gICAgICAgICAgICAgICAgIHN0cnVjdCBmaWxlICpmaWxlOwo+ID4gPgo+ID4g PiAtICAgICAgICAgICAgICAgcmV0dmFsID0gdm1hX3N0YXJ0X3dyaXRlX2tpbGxhYmxlKG1wbnQp Owo+ID4gPiArICAgICAgICAgICAgICAgLyoKPiA+ID4gKyAgICAgICAgICAgICAgICAqIEZvciBh bm9ueW1vdXMgb3Igd3JpdGFibGUgcHJpdmF0ZSBWTUFzLCBwcmV2ZW50Cj4gPiA+ICsgICAgICAg ICAgICAgICAgKiBjb25jdXJyZW50IENvVyBmYXVsdHMuCj4gPiA+ICsgICAgICAgICAgICAgICAg Ki8KPiA+Cj4gPiBUbyBuaXQgcGljayBJIHRoaW5rIHRoZSBjb21tZW50J3MgY29uZnVzaW5nIGJ1 dCBhbHNvIHRlbGxzIHlvdSB5b3UgZG9uJ3QgbmVlZCB0bwo+ID4gc3BlY2lmaWMgYW5vbiBjaGVj ayAtIHdyaXRhYmxlIHByaXZhdGUgaXMgc3VmZmljaWVudC4gQW5kIGl0J3Mgbm90IHJlYWxseSBq dXN0Cj4gPiBDb1cgdGhhdCdzIHRoZSBpc3N1ZSwgaXQncyBhbm9uX3ZtYSBwb3B1bGF0aW9uIF9h dCBhbGxfIGFzIHdlbGwgYXMgQ29XLgo+ID4KPiA+ID4gKyAgICAgICAgICAgICAgIGlmICghbXBu dC0+dm1fZmlsZSB8fCAoIShtcG50LT52bV9mbGFncyAmIFZNX1NIQVJFRCkgJiYKPiA+ID4gKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChtcG50LT52bV9mbGFncyAmIFZN X1dSSVRFKSkpCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIHJldHZhbCA9IHZtYV9zdGFy dF93cml0ZV9raWxsYWJsZShtcG50KTsKPiA+Cj4gPiBJIHRoaW5rIHRoaXMgaGFzIHRvIGJlIFZN X01BWVdSSVRFLCBiZWNhdXNlIHNvbWVib2R5IGNvdWxkIG90aGVyd2lzZSBtcHJvdGVjdCgpCj4g PiBpdCBSL1cuCj4gPgo+ID4gSSBhbHNvIGRvbid0IHVuZGVyc3RhbmQgd2h5ICFtcG50LT52bV9m aWxlIGZvciBhIHJlYWQtb25seSBhbm9uIG1hcHBpbmcgKG1vcmUKPiA+IGxpa2VseSBQUk9UX05P TkUpIGlzIGhlcmUsIGp1c3QgZG8gdGhlIHNlY29uZCBjaGVjaz8KPiA+Cj4gPiAoQWxzbyBwbGVh c2UgdXNlIHRoZSBuZXcgaW50ZXJmYWNlLCBzbyAhdm1hX3Rlc3QobXBudCwgVk1BX1NIQVJFRF9C SVQpICYmCj4gPiB2bWFfdGVzdChtcG50LCBWTUFfTUFZV1JJVEVfQklUKSkKPgo+IFllcCwgSSBj YW4gZGVmaW5pdGVseSByZWZpbmUgdGhlIGNoZWNrIGZ1cnRoZXIuIEJ1dCBiZWZvcmUKPiBkb2lu ZyB0aGF0LCBJJ2QgZmlyc3QgbGlrZSB0byBjb25maXJtIHRoYXQgd2UgYXJlIGFsaWduZWQgb24K PiB0aGUgZGlyZWN0aW9uLgo+Cj4gSWYgeW91IHN0aWxsIGludGVuZCB0byBob2xkIHRoZSBWTUEg bG9jayB3aGlsZSBwZXJmb3JtaW5nIEkvTywKPiB0aGVuIEkgdGhpbmsgd2Ugc2hvdWxkIGZpeCBg Zm9yaygpYCB0byBhdm9pZCB0YWtpbmcKPiBgdm1hX3N0YXJ0X3dyaXRlKClgLgoKWWVhaCBvciB3 ZSBjb3VsZCBkbyBzb21ldGhpbmcgZGlmZmVyZW50LCBpdCBpc24ndCBhIGNhc2Ugb2YgeW91IGdl dCB0byBkbyBvbmUgb2YKdHdvIG9wdGlvbnMgeW91IHByb3Bvc2UgLSB0aGUgbWFpbnRhaW5lcnMg ZGVjaWRlIHdoaWNoIHdheSBpcyBhcHByb3ByaWF0ZS4KCk9mIHRoZSB0d28gb3B0aW9ucyBkcm9w cGluZyB0aGUgbG9jayBvbiB0aGUgZmF1bHQgcGF0aCByYXRoZXIgdGhhbiB0aGlzIGZvcmsKaW5z YW5pdHkgaXMgbXkgcHJlZmVyZW5jZSBidXQgSSB3b25kZXIgaWYgd2UgY2FuJ3QgZmluZCBhbm90 aGVyIHdheS4KCkxldCBtZSByZWFkIHRocm91Z2ggdGhlIHNlcmllcyBhbmQgZ2l2ZSBtb3JlIHRo b3VnaHRzIEkgZ3Vlc3MuCgo+Cj4gPgo+ID4gPiAgICAgICAgICAgICAgICAgaWYgKHJldHZhbCA8 IDApCj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIGdvdG8gbG9vcF9vdXQ7Cj4gPiA+ICAg ICAgICAgICAgICAgICBpZiAobXBudC0+dm1fZmxhZ3MgJiBWTV9ET05UQ09QWSkgewo+ID4gPgo+ ID4gPiBCYXNlZCBvbiB0aGUgYWJvdmUsIHdlIG1heSB3YW50IHRvIHJlLWNoZWNrIHdoZXRoZXIg Zm9yaygpCj4gPiA+IGNhbiBiZSBibG9ja2VkIGJ5IHBhZ2UgZmF1bHRzLiBBdCB0aGUgc2FtZSB0 aW1lLCBpZiBTdXJlbiwKPiA+ID4geW91LCBvciBhbnlvbmUgZWxzZSBoYXMgYW55IGNvbW1lbnRz LCBwbGVhc2UgZmVlbCBmcmVlIHRvCj4gPiA+IHNoYXJlIHRoZW0uCj4gPiA+Cj4gPiA+IEJlc3Qg UmVnYXJkcwo+ID4gPiBCYXJyeQo+ID4KPiA+IFRlY2huaWNhbCBjb21tZW50YXJ5IGFib3ZlIGlz IHNvcnQgb2YgJ2p1c3QgY29zJyA6KSBiZWNhdXNlIEkgcmVhbGx5IHF1ZXN0aW9uCj4gPiBkb2lu ZyB0aGlzIGhvbmVzdGx5Lgo+Cj4gSSB0aGluayB3ZSBlaXRoZXIgbmVlZCB0byBmaXggYGZvcmso KWAsIG9yIGtlZXAgdGhlIGN1cnJlbnQKPiBiZWhhdmlvciBvZiBkcm9wcGluZyB0aGUgVk1BIGxv Y2sgYmVmb3JlIHBlcmZvcm1pbmcgSS9PLgoKWXVwIHlvdSBzYWlkIDopCgo+Cj4gPgo+ID4gSSdk IGFsc28gbGlrZSB0byBnZXQgU3VyZW4ncyBpbnB1dCwgaG93ZXZlci4KPgo+IFllcy4gb2YgY291 cnNlLgo+Cj4gPgo+ID4gVGhhbmtzLCBMb3JlbnpvCj4KPiBCZXN0IFJlZ2FyZHMKPiBCYXJyeQoK VGhhbmtzLCBMb3JlbnpvCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpsaW51eC1yaXNjdiBtYWlsaW5nIGxpc3QKbGludXgtcmlzY3ZAbGlzdHMuaW5mcmFk ZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4 LXJpc2N2Cg==