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 ED95ECD4F5B for ; Tue, 19 May 2026 13:12:19 +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=4iyoWRaoAjssAMcZ3T8TXfOV+ORYjaRo+vLhGU1M3cw=; b=BbLi7p92EkeqMtf4gg3YALzKPj oRx0D3wdqlsHUSYkoT7Qk5mfigYOzdp59jgJtuzzSiNHG8M9UjmVJmOb2xP8qQd/0GvLRgvWLKXKf CVxS4426KIsl/CahxDzUMcrctcpS0Vdg/XV26y4xNDO5ZkC/uHv0IinK/uKzfsTRv2Acn2kz+bVj7 WnrolnNoETskFGcY720u8r3i+akoYYE3OGVSigY4u8Ypy3WzftuSdqeEFYNhihkauxYrf9FSm/mwr WJRl9kcHBChfp1l8D1XjcOQ71WB0rLvyyMh+x9SGoUfa5mKQqIT160k2hFovjRjFLLCW70qIqZ5cb 1beuA3hQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPKF3-00000001b2k-48PF; Tue, 19 May 2026 13:12:13 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPKF1-00000001b1c-0nbU; Tue, 19 May 2026 13:12:12 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6E0204074F; Tue, 19 May 2026 13:12:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4764BC2BCB3; Tue, 19 May 2026 13:12:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779196330; bh=sJ8oiAvqmhr7uHBQf9pYBhQP+kTq5NdeaE/VXHC2rqs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YSGPE6UN5Qmce16ldLx9NKEWS+Et8MZjoQPtOf59P5nkhc8U2lrZGD8JkDxEHS0w+ jmmMI6+gtKWvDpALbh1cbwf4TAObuSvXatbUzcJkwup0oefI+MAyALMqPabU8jsEVy o3SyWVoBrJpJUBQZ8O+WCJXIGAuAdZa15ZTa4vV/Z5WyNvz77F6F/2+C10LuVJSSFj lZkaneaf1fdSE0EGWCsZZNXbeZR9y51LQPA0IEloovoGevsLaeOHToqEwaUoMlq3z2 GXR9n8QZ5VYTJzXhHzeyp2ncWhm/filX4zLxr0FaNcgJ0UEFKIolD9obziY7jvEIAS jmPLXidQ+Gx2Q== Date: Tue, 19 May 2026 14:12:00 +0100 From: Lorenzo Stoakes To: Yang Shi Cc: Barry Song , 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260519_061211_661029_9284AA59 X-CRM114-Status: GOOD ( 60.75 ) 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 02:21:14PM -0700, Yang Shi wrote: > On Sun, May 17, 2026 at 1:45 AM 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. > > > > 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): > > > > 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. > > + */ > > + if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) && > > + (mpnt->vm_flags & VM_WRITE))) > > + retval = vma_start_write_killable(mpnt); > > if (retval < 0) > > goto loop_out; > > if (mpnt->vm_flags & VM_DONTCOPY) { > > Maybe a little bit off topic. This is an interesting idea. It seems > possible we don't have to take vma write lock unconditionally. IIUC > the write lock is mainly used to serialize against page fault and > madvise, right? I got a crazy idea off the top of my head. We may be Err no, it serialises against literally any modification or read of any characteristic of VMAs. > able to just take vma write lock iff vma->anon_vma is not NULL. Except if we don't take it and vma->anon_vma is NULL, then somebody can anon_vma_prepare() and change vma->anon_vma midway through a fork and completely screw up the anon_vma fork hierarchy. So no. > > First of all, write mmap_lock is held, so the vma can't go or be > changed under us. vma->anon_vma can be changed. > > Secondly, if vma->anon_vma is NULL, it basically means either no page > fault happened or no cow happened, so there is no page table to copy, > this is also what copy_page_range() does currently. So we can shrink > the critical section to: Firstly, with no VMA write lock, !vma->anon_vma means a fault can race and secondly copy_page_range() checks vma_needs_copy(), there are other cases - PFN maps, mixed maps, UFFD W/P (ugh), guard regions. So yeah this isn't sufficient. > > if (vma->anon_vma) { > vma_start_write_killable(src_vma); > anon_vma_fork(dst_vma, src_vma); > copy_page_range(dst_vma, src_vma); > } Yeah that's totally broken fo reasons above as I said :) > > But page fault can happen before write mmap_lock is taken, when we > check vma->anon_vma, it is possible it has not been set up yet. But it > seems to be equivalent to page fault after fork and won't break the > semantic. It will totally break how the anon_vma hierarchy works :) See the links at the top of https://ljs.io/talks for a link to various slides on anon_vma behaviour (it's really a pain to think about because it's a super broken abstraction). You could end up with a CoW mapping that's unreachable from rmap and you could get some nasty issues with page table entries pointing at freed folios :) > > Anyway, just a crazy idea, I may miss some corner cases. Yeah sorry to push back here but this is just not a viable approach. And this is forgetting that we have relied on page faults being blocked by fork _forever_, who knows what else has baked in assumptions about that serialisation. Forking is one of the nastiest parts of mm and has had multiple, subtle, corner case breakages that have been a nightmare to deal with. So I'm very much against changing this behaviour to try to fix something in the fault path. We should address the fault path issues in the fault path :) > > Thanks, > Yang > > } > > > > > 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 > > Cheers, 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 D3F2DCD5BA4 for ; Tue, 19 May 2026 13:12:22 +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=Py/1jHfUJvsdiYPIoiJw5OIJl3gJpLUNcxZG79E6AXQ=; b=2lWbps3PQK7mxe Im543skzyzMWRMMemnyhEHUR1iswAYojTI928Ay7x9euJhz4zjd2qWTqfqC+cl3QGNhkle8AfRQBZ 5sldGVwSAI3msHvCa+8auSPcbc+m3ynxfy2/0WJhRji1TV6l1Ixj2EAoJG4SKpupGfwH6aNEws2lT D1CCVMRNJHzEbQz+VDqdUAFdQn9Gk1HiQwe2AsrakZHlYuoCW6Lpm6B3aZVE5/OFgVBSwGgp3xaBq 4g+/IfJfwSdV0oIK3Wo3KF/tNvGaRvXWsukFHTcvmCTA+OKGvaDqGtH6d0sHGg9slkvrGfEabrJD4 YlIWoHiPult2Zy6kus6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPKF4-00000001b30-0KaU; Tue, 19 May 2026 13:12:14 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPKF1-00000001b1c-0nbU; Tue, 19 May 2026 13:12:12 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6E0204074F; Tue, 19 May 2026 13:12:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4764BC2BCB3; Tue, 19 May 2026 13:12:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779196330; bh=sJ8oiAvqmhr7uHBQf9pYBhQP+kTq5NdeaE/VXHC2rqs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YSGPE6UN5Qmce16ldLx9NKEWS+Et8MZjoQPtOf59P5nkhc8U2lrZGD8JkDxEHS0w+ jmmMI6+gtKWvDpALbh1cbwf4TAObuSvXatbUzcJkwup0oefI+MAyALMqPabU8jsEVy o3SyWVoBrJpJUBQZ8O+WCJXIGAuAdZa15ZTa4vV/Z5WyNvz77F6F/2+C10LuVJSSFj lZkaneaf1fdSE0EGWCsZZNXbeZR9y51LQPA0IEloovoGevsLaeOHToqEwaUoMlq3z2 GXR9n8QZ5VYTJzXhHzeyp2ncWhm/filX4zLxr0FaNcgJ0UEFKIolD9obziY7jvEIAS jmPLXidQ+Gx2Q== Date: Tue, 19 May 2026 14:12:00 +0100 From: Lorenzo Stoakes To: Yang Shi Cc: Barry Song , 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260519_061211_661029_9284AA59 X-CRM114-Status: GOOD ( 60.75 ) 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 T24gTW9uLCBNYXkgMTgsIDIwMjYgYXQgMDI6MjE6MTRQTSAtMDcwMCwgWWFuZyBTaGkgd3JvdGU6 Cj4gT24gU3VuLCBNYXkgMTcsIDIwMjYgYXQgMTo0NeKAr0FNIEJhcnJ5IFNvbmcgPGJhb2h1YUBr ZXJuZWwub3JnPiB3cm90ZToKPiA+Cj4gPiBPbiBTYXQsIE1heSAyLCAyMDI2IGF0IDE6NTjigK9B TSBNYXR0aGV3IFdpbGNveCA8d2lsbHlAaW5mcmFkZWFkLm9yZz4gd3JvdGU6Cj4gPiA+Cj4gPiA+ IE9uIFNhdCwgTWF5IDAyLCAyMDI2IGF0IDAxOjQ0OjM0QU0gKzA4MDAsIEJhcnJ5IFNvbmcgd3Jv dGU6Cj4gPiA+ID4gT24gRnJpLCBNYXkgMSwgMjAyNiBhdCAxMDo1N+KAr1BNIE1hdHRoZXcgV2ls Y294IDx3aWxseUBpbmZyYWRlYWQub3JnPiB3cm90ZToKPiA+ID4gPiA+Cj4gPiA+ID4gPiBPbiBG cmksIE1heSAwMSwgMjAyNiBhdCAwNjo0OTo1OEFNICswODAwLCBCYXJyeSBTb25nIHdyb3RlOgo+ ID4gPiA+ID4gPiAxLiBUaGVyZSBpcyBubyBkZXRlcm1pbmlzdGljIGxhdGVuY3kgZm9yIEkvTyBj b21wbGV0aW9uLiBJdCBkZXBlbmRzIG9uCj4gPiA+ID4gPiA+IGJvdGggdGhlIGhhcmR3YXJlIGFu ZCB0aGUgc29mdHdhcmUgc3RhY2sgKGJpby9yZXF1ZXN0IHF1ZXVlcyBhbmQgdGhlCj4gPiA+ID4g PiA+IGJsb2NrIHNjaGVkdWxlcikuIFNvbWV0aW1lcyB0aGUgbGF0ZW5jeSBpcyBzaG9ydDsgYXQg b3RoZXIgdGltZXMgaXQgY2FuCj4gPiA+ID4gPiA+IGJlIHF1aXRlIGxvbmcuIEluIHN1Y2ggY2Fz ZXMsIGEgaGlnaC1wcmlvcml0eSB0aHJlYWQgcGVyZm9ybWluZyBvcGVyYXRpb25zCj4gPiA+ID4g PiA+IHN1Y2ggYXMgbXByb3RlY3QsIHVubWFwLCBwcmN0bF9zZXRfdm1hLCBvciBtYWR2aXNlIG1h eSBiZSBmb3JjZWQgdG8gd2FpdAo+ID4gPiA+ID4gPiBmb3IgYW4gdW5wcmVkaWN0YWJsZSBhbW91 bnQgb2YgdGltZS4KPiA+ID4gPiA+Cj4gPiA+ID4gPiBCdXQgZG9lcyB0aGF0IGFjdHVhbGx5IGhh cHBlbj8gIEkgZmluZCBpdCBoYXJkIHRvIGJlbGlldmUgdGhhdCB0aHJlYWQgQQo+ID4gPiA+ID4g dW5tYXBzIGEgVk1BIHdoaWxlIHRocmVhZCBCIGlzIGluIHRoZSBtaWRkbGUgb2YgdGFraW5nIGEg cGFnZSBmYXVsdCBpbgo+ID4gPiA+ID4gdGhhdCBzYW1lIFZNQS4gIG1wcm90ZWN0KCkgYW5kIG1h ZHZpc2UoKSBhcmUgbW9yZSBsaWtlbHkgdG8gaGFwcGVuLCBidXQKPiA+ID4gPiA+IGl0IHN0aWxs IHNlZW1zIHJlYWxseSB1bmxpa2VseSB0byBtZS4KPiA+ID4gPgo+ID4gPiA+IEl0IGRvZXNu4oCZ dCBoYXZlIHRvIGludm9sdmUgdW5tYXBwaW5nIG9yIGFwcGx5aW5nIG1wcm90ZWN0IHRvCj4gPiA+ ID4gdGhlIGVudGlyZSBWTUHigJRqdXN0IGEgcG9ydGlvbiBvZiBpdCBpcyBzdWZmaWNpZW50Lgo+ ID4gPgo+ID4gPiBZZXMsIGJ1dCB0aGF0IHN0aWxsIGZhaWxzIHRvIGFuc3dlciAiZG9lcyB0aGlz IGFjdHVhbGx5IGhhcHBlbiIuICBIb3cgbXVjaAo+ID4gPiBwZXJmb3JtYW5jZSBpcyBhbGwgdGhp cyBjb21wbGV4aXR5IGluIHRoZSBwYWdlIGZhdWx0IGhhbmRsZXIgYnV5aW5nIHVzPwo+ID4gPiBJ ZiB5b3UgZG9uJ3QgYW5zd2VyIHRoaXMgcXVlc3Rpb24sIEknbSBqdXN0IGdvaW5nIHRvIGdvIGlu IGFuZCByaXAgaXQKPiA+ID4gYWxsIG91dC4KPiA+ID4KPiA+Cj4gPiBIaSBNYXR0aGV3IChhbmQg TG9yZW56bywgSmFuLCBhbmQgYW55b25lIGVsc2Ugd2hvIG1heSBiZQo+ID4gd2FpdGluZyBmb3Ig YW5zd2VycyksCj4gPgo+ID4gQXMgcHJvbWlzZWQgZHVyaW5nIExTRi9NTS9CUEYsIHdlIGNvbmR1 Y3RlZCB0aG9yb3VnaAo+ID4gdGVzdGluZyBvbiBBbmRyb2lkIHBob25lcyB0byBkZXRlcm1pbmUg d2hldGhlciBwZXJmb3JtaW5nCj4gPiBJL08gaW4gYGZpbGVtYXBfZmF1bHQoKWAgY2FuIGJsb2Nr IGB2bWFfc3RhcnRfd3JpdGUoKWAuCj4gPiBJIHdhbnRlZCB0byBnaXZlIGEgcXVpY2sgdXBkYXRl IG9uIHRoaXMgcXVlc3Rpb24uCj4gPgo+ID4gTmFuemhlIGF0IFhpYW9taSBjcmVhdGVkIHRyYWNp bmcgc2NyaXB0cyBhbmQgcmFuIHZhcmlvdXMKPiA+IGFwcGxpY2F0aW9ucyBvbiBBbmRyb2lkIGRl dmljZXMgd2l0aCBJL08gcGVyZm9ybWVkIHVuZGVyCj4gPiB0aGUgVk1BIGxvY2sgaW4gYGZpbGVt YXBfZmF1bHQoKWAuIFdlIGZvdW5kIHRoYXQ6Cj4gPgo+ID4gMS4gVGhlcmUgYXJlIHZlcnkgZmV3 IGNhc2VzIHdoZXJlIHVubWFwKCkgaXMgYmxvY2tlZCBieQo+ID4gICAgcGFnZSBmYXVsdHMuIEkg YXNzdW1lIHRoaXMgaXMgZHVlIHRvIGJ1Z2d5IHVzZXIgY29kZQo+ID4gICAgb3IgcG9vciBzeW5j aHJvbml6YXRpb24gYmV0d2VlbiByZWFkcyBhbmQgdW5tYXAoKS4KPiA+IFNvIEkgYXNzdW1lIGl0 IGlzIG5vdCBhIHByb2JsZW0uCj4gPgo+ID4gMi4gV2Ugb2JzZXJ2ZWQgbWFueSBjYXNlcyB3aGVy ZSBgdm1hX3N0YXJ0X3dyaXRlKClgCj4gPiAgICBpcyBibG9ja2VkIGJ5IHBhZ2UtZmF1bHQgSS9P IGluIHNvbWUgYXBwbGljYXRpb25zLgo+ID4gICAgVGhlIGJsb2NraW5nIG9jY3VycyBpbiB0aGUg YGR1cF9tbWFwKClgIHBhdGggZHVyaW5nCj4gPiAgICBmb3JrKCkuCj4gPgo+ID4gV2l0aCBTdXJl bidzIGNvbW1pdCBmYjQ5YzQ1NTMyM2ZmICgiZm9yazogbG9jayBWTUFzIG9mCj4gPiB0aGUgcGFy ZW50IHByb2Nlc3Mgd2hlbiBmb3JraW5nIiksIHdlIG5vdyBhbHdheXMgaG9sZAo+ID4gYHZtYV93 cml0ZV9sb2NrKClgIGZvciBlYWNoIFZNQS4gTm90ZSB0aGF0IHRoZQo+ID4gYG1tYXBfbG9ja2Ag d3JpdGUgbG9jayBpcyBhbHNvIGhlbGQsIHdoaWNoIGNvdWxkIGxlYWQgdG8KPiA+IGNoYWluZWQg d2FpdGluZyBpZiBwYWdlLWZhdWx0IEkvTyBpcyBwZXJmb3JtZWQgd2l0aG91dAo+ID4gcmVsZWFz aW5nIHRoZSBWTUEgbG9jay4KPiA+Cj4gPiBNeSBndXQgZmVlbGluZyBpcyB0aGF0IFN1cmVuJ3Mg Y29tbWl0IG1heSBiZSBvdmVyc2hvb3RpbmcsCj4gPiBzbyBteSByb3VnaCBpZGVhIGlzIHRoYXQg d2UgbWlnaHQgd2FudCB0byBkbyBzb21ldGhpbmcgbGlrZQo+ID4gdGhlIGZvbGxvd2luZyAod2Ug aGF2ZW4ndCB0ZXN0ZWQgaXQgeWV0IGFuZCBpdCBtaWdodCBiZQo+ID4gd3JvbmcpOgo+ID4KPiA+ IGRpZmYgLS1naXQgYS9tbS9tbWFwLmMgYi9tbS9tbWFwLmMKPiA+IGluZGV4IDIzMTFhZTdjMmZm NC4uNWRkYWYyOTdmMzFhIDEwMDY0NAo+ID4gLS0tIGEvbW0vbW1hcC5jCj4gPiArKysgYi9tbS9t bWFwLmMKPiA+IEBAIC0xNzYyLDcgKzE3NjIsMTMgQEAgX19sYXRlbnRfZW50cm9weSBpbnQgZHVw X21tYXAoc3RydWN0IG1tX3N0cnVjdAo+ID4gKm1tLCBzdHJ1Y3QgbW1fc3RydWN0ICpvbGRtbSkK PiA+ICAgICAgICAgZm9yX2VhY2hfdm1hKHZtaSwgbXBudCkgewo+ID4gICAgICAgICAgICAgICAg IHN0cnVjdCBmaWxlICpmaWxlOwo+ID4KPiA+IC0gICAgICAgICAgICAgICByZXR2YWwgPSB2bWFf c3RhcnRfd3JpdGVfa2lsbGFibGUobXBudCk7Cj4gPiArICAgICAgICAgICAgICAgLyoKPiA+ICsg ICAgICAgICAgICAgICAgKiBGb3IgYW5vbnltb3VzIG9yIHdyaXRhYmxlIHByaXZhdGUgVk1Bcywg cHJldmVudAo+ID4gKyAgICAgICAgICAgICAgICAqIGNvbmN1cnJlbnQgQ29XIGZhdWx0cy4KPiA+ ICsgICAgICAgICAgICAgICAgKi8KPiA+ICsgICAgICAgICAgICAgICBpZiAoIW1wbnQtPnZtX2Zp bGUgfHwgKCEobXBudC0+dm1fZmxhZ3MgJiBWTV9TSEFSRUQpICYmCj4gPiArICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKG1wbnQtPnZtX2ZsYWdzICYgVk1fV1JJVEUpKSkK PiA+ICsgICAgICAgICAgICAgICAgICAgICAgIHJldHZhbCA9IHZtYV9zdGFydF93cml0ZV9raWxs YWJsZShtcG50KTsKPiA+ICAgICAgICAgICAgICAgICBpZiAocmV0dmFsIDwgMCkKPiA+ICAgICAg ICAgICAgICAgICAgICAgICAgIGdvdG8gbG9vcF9vdXQ7Cj4gPiAgICAgICAgICAgICAgICAgaWYg KG1wbnQtPnZtX2ZsYWdzICYgVk1fRE9OVENPUFkpIHsKPgo+IE1heWJlIGEgbGl0dGxlIGJpdCBv ZmYgdG9waWMuIFRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgaWRlYS4gSXQgc2VlbXMKPiBwb3NzaWJs ZSB3ZSBkb24ndCBoYXZlIHRvIHRha2Ugdm1hIHdyaXRlIGxvY2sgdW5jb25kaXRpb25hbGx5LiBJ SVVDCj4gdGhlIHdyaXRlIGxvY2sgaXMgbWFpbmx5IHVzZWQgdG8gc2VyaWFsaXplIGFnYWluc3Qg cGFnZSBmYXVsdCBhbmQKPiBtYWR2aXNlLCByaWdodD8gSSBnb3QgYSBjcmF6eSBpZGVhIG9mZiB0 aGUgdG9wIG9mIG15IGhlYWQuIFdlIG1heSBiZQoKRXJyIG5vLCBpdCBzZXJpYWxpc2VzIGFnYWlu c3QgbGl0ZXJhbGx5IGFueSBtb2RpZmljYXRpb24gb3IgcmVhZCBvZiBhbnkKY2hhcmFjdGVyaXN0 aWMgb2YgVk1Bcy4KCj4gYWJsZSB0byBqdXN0IHRha2Ugdm1hIHdyaXRlIGxvY2sgaWZmIHZtYS0+ YW5vbl92bWEgaXMgbm90IE5VTEwuCgpFeGNlcHQgaWYgd2UgZG9uJ3QgdGFrZSBpdCBhbmQgdm1h LT5hbm9uX3ZtYSBpcyBOVUxMLCB0aGVuIHNvbWVib2R5IGNhbgphbm9uX3ZtYV9wcmVwYXJlKCkg YW5kIGNoYW5nZSB2bWEtPmFub25fdm1hIG1pZHdheSB0aHJvdWdoIGEgZm9yayBhbmQgY29tcGxl dGVseQpzY3JldyB1cCB0aGUgYW5vbl92bWEgZm9yayBoaWVyYXJjaHkuCgpTbyBuby4KCj4KPiBG aXJzdCBvZiBhbGwsIHdyaXRlIG1tYXBfbG9jayBpcyBoZWxkLCBzbyB0aGUgdm1hIGNhbid0IGdv IG9yIGJlCj4gY2hhbmdlZCB1bmRlciB1cy4KCnZtYS0+YW5vbl92bWEgY2FuIGJlIGNoYW5nZWQu Cgo+Cj4gU2Vjb25kbHksIGlmIHZtYS0+YW5vbl92bWEgaXMgTlVMTCwgaXQgYmFzaWNhbGx5IG1l YW5zIGVpdGhlciBubyBwYWdlCj4gZmF1bHQgaGFwcGVuZWQgb3Igbm8gY293IGhhcHBlbmVkLCBz byB0aGVyZSBpcyBubyBwYWdlIHRhYmxlIHRvIGNvcHksCj4gdGhpcyBpcyBhbHNvIHdoYXQgY29w eV9wYWdlX3JhbmdlKCkgZG9lcyBjdXJyZW50bHkuIFNvIHdlIGNhbiBzaHJpbmsKPiB0aGUgY3Jp dGljYWwgc2VjdGlvbiB0bzoKCkZpcnN0bHksIHdpdGggbm8gVk1BIHdyaXRlIGxvY2ssICF2bWEt PmFub25fdm1hIG1lYW5zIGEgZmF1bHQgY2FuIHJhY2UgYW5kCnNlY29uZGx5IGNvcHlfcGFnZV9y YW5nZSgpIGNoZWNrcyB2bWFfbmVlZHNfY29weSgpLCB0aGVyZSBhcmUgb3RoZXIgY2FzZXMgLSBQ Rk4KbWFwcywgbWl4ZWQgbWFwcywgVUZGRCBXL1AgKHVnaCksIGd1YXJkIHJlZ2lvbnMuCgpTbyB5 ZWFoIHRoaXMgaXNuJ3Qgc3VmZmljaWVudC4KCj4KPiBpZiAodm1hLT5hbm9uX3ZtYSkgewo+ICAg ICB2bWFfc3RhcnRfd3JpdGVfa2lsbGFibGUoc3JjX3ZtYSk7Cj4gICAgIGFub25fdm1hX2Zvcmso ZHN0X3ZtYSwgc3JjX3ZtYSk7Cj4gICAgIGNvcHlfcGFnZV9yYW5nZShkc3Rfdm1hLCBzcmNfdm1h KTsKPiB9CgpZZWFoIHRoYXQncyB0b3RhbGx5IGJyb2tlbiBmbyByZWFzb25zIGFib3ZlIGFzIEkg c2FpZCA6KQoKPgo+IEJ1dCBwYWdlIGZhdWx0IGNhbiBoYXBwZW4gYmVmb3JlIHdyaXRlIG1tYXBf bG9jayBpcyB0YWtlbiwgd2hlbiB3ZQo+IGNoZWNrIHZtYS0+YW5vbl92bWEsIGl0IGlzIHBvc3Np YmxlIGl0IGhhcyBub3QgYmVlbiBzZXQgdXAgeWV0LiBCdXQgaXQKPiBzZWVtcyB0byBiZSBlcXVp dmFsZW50IHRvIHBhZ2UgZmF1bHQgYWZ0ZXIgZm9yayBhbmQgd29uJ3QgYnJlYWsgdGhlCj4gc2Vt YW50aWMuCgpJdCB3aWxsIHRvdGFsbHkgYnJlYWsgaG93IHRoZSBhbm9uX3ZtYSBoaWVyYXJjaHkg d29ya3MgOikgU2VlIHRoZSBsaW5rcyBhdCB0aGUKdG9wIG9mIGh0dHBzOi8vbGpzLmlvL3RhbGtz IGZvciBhIGxpbmsgdG8gdmFyaW91cyBzbGlkZXMgb24gYW5vbl92bWEgYmVoYXZpb3VyCihpdCdz IHJlYWxseSBhIHBhaW4gdG8gdGhpbmsgYWJvdXQgYmVjYXVzZSBpdCdzIGEgc3VwZXIgYnJva2Vu IGFic3RyYWN0aW9uKS4KCllvdSBjb3VsZCBlbmQgdXAgd2l0aCBhIENvVyBtYXBwaW5nIHRoYXQn cyB1bnJlYWNoYWJsZSBmcm9tIHJtYXAgYW5kIHlvdSBjb3VsZApnZXQgc29tZSBuYXN0eSBpc3N1 ZXMgd2l0aCBwYWdlIHRhYmxlIGVudHJpZXMgcG9pbnRpbmcgYXQgZnJlZWQgZm9saW9zIDopCgo+ Cj4gQW55d2F5LCBqdXN0IGEgY3JhenkgaWRlYSwgSSBtYXkgbWlzcyBzb21lIGNvcm5lciBjYXNl cy4KClllYWggc29ycnkgdG8gcHVzaCBiYWNrIGhlcmUgYnV0IHRoaXMgaXMganVzdCBub3QgYSB2 aWFibGUgYXBwcm9hY2guCgpBbmQgdGhpcyBpcyBmb3JnZXR0aW5nIHRoYXQgd2UgaGF2ZSByZWxp ZWQgb24gcGFnZSBmYXVsdHMgYmVpbmcgYmxvY2tlZCBieSBmb3JrCl9mb3JldmVyXywgd2hvIGtu b3dzIHdoYXQgZWxzZSBoYXMgYmFrZWQgaW4gYXNzdW1wdGlvbnMgYWJvdXQgdGhhdApzZXJpYWxp c2F0aW9uLgoKRm9ya2luZyBpcyBvbmUgb2YgdGhlIG5hc3RpZXN0IHBhcnRzIG9mIG1tIGFuZCBo YXMgaGFkIG11bHRpcGxlLCBzdWJ0bGUsIGNvcm5lcgpjYXNlIGJyZWFrYWdlcyB0aGF0IGhhdmUg YmVlbiBhIG5pZ2h0bWFyZSB0byBkZWFsIHdpdGguCgpTbyBJJ20gdmVyeSBtdWNoIGFnYWluc3Qg Y2hhbmdpbmcgdGhpcyBiZWhhdmlvdXIgdG8gdHJ5IHRvIGZpeCBzb21ldGhpbmcgaW4gdGhlCmZh dWx0IHBhdGguCgpXZSBzaG91bGQgYWRkcmVzcyB0aGUgZmF1bHQgcGF0aCBpc3N1ZXMgaW4gdGhl IGZhdWx0IHBhdGggOikKCj4KPiBUaGFua3MsCj4gWWFuZwo+Cj4gfQo+Cj4gPgo+ID4gQmFzZWQg b24gdGhlIGFib3ZlLCB3ZSBtYXkgd2FudCB0byByZS1jaGVjayB3aGV0aGVyIGZvcmsoKQo+ID4g Y2FuIGJlIGJsb2NrZWQgYnkgcGFnZSBmYXVsdHMuIEF0IHRoZSBzYW1lIHRpbWUsIGlmIFN1cmVu LAo+ID4geW91LCBvciBhbnlvbmUgZWxzZSBoYXMgYW55IGNvbW1lbnRzLCBwbGVhc2UgZmVlbCBm cmVlIHRvCj4gPiBzaGFyZSB0aGVtLgo+ID4KPiA+IEJlc3QgUmVnYXJkcwo+ID4gQmFycnkKPiA+ CgpDaGVlcnMsIExvcmVuem8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCmxpbnV4LXJpc2N2IG1haWxpbmcgbGlzdApsaW51eC1yaXNjdkBsaXN0cy5pbmZy YWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGlu dXgtcmlzY3YK