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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A8FA5CD4F52 for ; Mon, 18 May 2026 09:47:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 153206B0092; Mon, 18 May 2026 05:47:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 12AFB6B0093; Mon, 18 May 2026 05:47:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 067F36B0098; Mon, 18 May 2026 05:47:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E90A96B0092 for ; Mon, 18 May 2026 05:47:11 -0400 (EDT) Received: from smtpin02.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B81231C1E3D for ; Mon, 18 May 2026 09:47:11 +0000 (UTC) X-FDA: 84780062262.02.6CF2D7E Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf27.hostedemail.com (Postfix) with ESMTP id 0054B4000A for ; Mon, 18 May 2026 09:47:09 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vQJ0arCr; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of ljs@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=ljs@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1779097630; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ET333FRP9aSoxb7NhOmP9XopJpnV8U7OLN71bw9AvnU=; b=MCKv1SM1Z7RjmKohN8HjU9foLgkR4A0uyrAt90P+BD5QSafkhpCbnKonhptffA7/RhHiHV lMIZpQyKxcVFRuSz28E4GXHR5IO/SI/JizmKzZwt5TacTAp8qCxC0Nf0nNhqZ82k8ZzEKB DqcNZ3ZNtHnYoix4uhMQ3+CDBsmgjHs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1779097630; a=rsa-sha256; cv=none; b=73fz5zyd7b+txMmoMKT2yoqB8ccbUNIdmz5tAr3Dd3fp9LszTZ5i0cKi/hOySMEK7OpdLs KVCP2FIcYAXbDwfBHWF/co0pEGKtMIvZDzhwwEc90dZj2Uns7c3Hi9+Glt9aJvGP8bHFtN rAfGYIZw4My5ePeN4qzAqphD5pRShwk= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vQJ0arCr; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of ljs@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=ljs@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 00EBB44018; Mon, 18 May 2026 09:47:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68AFAC2BCB7; Mon, 18 May 2026 09:47:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779097628; bh=TG4jY49etADdd0W92AOWeHiLbA5nZOb/ARZcjnb31oU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vQJ0arCrP/xBPlP5xYCcSSm/fS+QQUbWLyhqiDIrU88DmvTAFFSm30+Xht992Kwkr skPTdxS4IrMJ+p5tztV/luY0iNJBbYXUE/c8+gstKuaH8hi9y+Mgq2xBBpJ3ADVJs7 ZCI2TQ1MeRf+U2+0uF/4b9BlIJuAH+0Z2Wi/G40INZkrBzkH/PD0+ypSZP4/Fk+Kxe Xp/7tp+4rG7efDwwY87OsxwuUVOB9eHt9qUSqLvldLdv2/QVprIE0DCJVhFMfpWFP/ hXJ3evSbQlYMMWAjGszf1ccS6LkTIDY+CHhyS99vXL1+9ZkBTzfrKsyfLU8JAER3+q xVpAdvt8jECkg== Date: Mon, 18 May 2026 10:46:59 +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-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 0054B4000A X-Stat-Signature: tcyzzitiunr9xmookmpn9wqh5yzkyf4b X-Rspam-User: X-HE-Tag: 1779097629-407442 X-HE-Meta: U2FsdGVkX1/uCIWCKCQ4xR49W3bkO9KXfSD4e0FwRY6zm2IegDCWrRVSnhx2yVZlPjfXNPoDUQcxpVGIV6uzaxzC9H8hxEkcEzgU21VCUuFtpvVthFAHeTUbOdJWAoCOefCFMx913cVh04GJNwYstLlp+1hF8pwgS2Xnj5YhG3dEmVG5HM3+5KOEs5G+QqevTLCCialzkaT03za/CzZA6io8/ck9UBzNAFu5y5/QYAwe9LwmCdm32C7jQOFn11DG0pc98XhGG1FupUggxv5e5g1edyvaecRd3fz/SXFoOfOvS0Nu4IfvjYAQCJdvqdD10sE+8lFFhKjy636jxzI9LZmAECP9tfbBJtTNZrxxrch9ii9eEn7BCI+h4TVnwg+/D1aj5HBZa8aC0tkA61a8JjJEXqzXR53DgBdE5ofRbnsSeLrzAXpvryBrCxE01OAXBaNNOiRK/uz6bMiwl4spPqcSHGuR4Po+JKUNxD1VCfNjGtEm5ZhNFRye4vrU42o7xnV+zctHtbEepan9kosf/LzfTitVtnvMNA4PbdeQzILpiiL6Of6gZr95zL4OP+73PsjJklAWGEZq7wjPLV+zFavtGdQqQgO808MFi+4N8zJax/v1saW5E5wB9Jr3u1UOKMV74POd4XAOGNweN32eGgxLvIZ0rxb04Vwskq3QGNq6+B/OaNpDMEuf1wnlhvx9XSScaQHCpjxUQMh5JRnNcO7+T0U3cfvmD6V0Bfsp7OTXB9Vmd0P0t+xH2P1ZqSWVNItqFmG0QmKgwCrlUsTIk9+o5+PvcsXPRGi+DE6PFrwID8ze+N2ANmauf6HjadE0yWsiOcI+dGXa8g3yQ+5SG8xrUn9Oos9RpiSYx3c7oMEehNhetjSkjJ6hi8mQUMnat5QIae69/T4WVgprKK/ArBtOmpIZ+cJR4990e2lkSRBJDk2bQaSHEKqI8fZyiRz1x82F9bLSdlraT3xNxlT O6QRIyCy jY1P+5JoU0jSbeNoAXRTkfA+aVENH9tklUyAmkSKkFv6O0dfhQpubjHMK2YSWWYA4ojmYfaUBNle6ZGIChY1A9zD+m/6vj2ET/MRRNO7kKzNyu6GefAfJAnJHigQr9lua9JczVlJeL09vSPYfy/Okn8W9UuflQuv8WcQ8dlOKbH69TX/hBFmBvHUavVpEBWmP54MrDSdUiUfai2q6D53hht1pcusQcT541J0hPViRmhNqdZELFOSsoPFJF1Kc4OYe09B8aUNEsF+6Llb494L9fE/7wDU3QdxZ9nusFMle30PJViU7fUHqzk3G16XZQj1hfMlxb2tik1BqCDtAdLIXCbI7wV3PBzGThoZqWUBhAUUqkB9CzG9bZqMASWdr7Rkotc/Jen/BinWn3n3Td2RIVF3sLPlImZW4k/6HP0e6Co4CyNFXbEKGsOB+VLM/XqDCRTKs0Ww2HqyV/tg= Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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? > > 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 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. > > 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)) > 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'd also like to get Suren's input, however. 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 D55CFCD4F3C for ; Mon, 18 May 2026 09:47:25 +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=lygwUe7a4wGXRJwDx4oPOlS5vyqYudEm2cj9rKZcesY=; b=tlHqMyh5SOlYxW 0BKkYbhD/T/rqH0wrXjnVTKQLD/4PoX+ZvHbH839iMZUyqXf0+bFCdT7udz8EF2kY+LGIPFf8Mkgm 16OVNVXha3VUzRPVQCbxcyvq1OGiUT/ytvfJLmnI2W8BkXSwm1MD+Qb12ZyOJPXwOwt0HYbrgNcQs eM8yzc1hNXocxIJJiJ12cSOmaADtOpPHiWFrbbOedtKwF/r4f3QFr0OM3j/zrK3wEwCI0i23PlxFU 7b5FbjRe/n4KOXlcJnvP4Oz9zngiKNXlL+L0PyZGJAhzarpFEuDJXWr/z+2z98kqe4qX5W6VzdtfY EqBbJCXxAoHIv9Pv2Mgg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wOuZA-0000000F5F9-2k86; Mon, 18 May 2026 09:47:16 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wOuZ7-0000000F5D6-0zTs; Mon, 18 May 2026 09:47:14 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 00EBB44018; Mon, 18 May 2026 09:47:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68AFAC2BCB7; Mon, 18 May 2026 09:47:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779097628; bh=TG4jY49etADdd0W92AOWeHiLbA5nZOb/ARZcjnb31oU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vQJ0arCrP/xBPlP5xYCcSSm/fS+QQUbWLyhqiDIrU88DmvTAFFSm30+Xht992Kwkr skPTdxS4IrMJ+p5tztV/luY0iNJBbYXUE/c8+gstKuaH8hi9y+Mgq2xBBpJ3ADVJs7 ZCI2TQ1MeRf+U2+0uF/4b9BlIJuAH+0Z2Wi/G40INZkrBzkH/PD0+ypSZP4/Fk+Kxe Xp/7tp+4rG7efDwwY87OsxwuUVOB9eHt9qUSqLvldLdv2/QVprIE0DCJVhFMfpWFP/ hXJ3evSbQlYMMWAjGszf1ccS6LkTIDY+CHhyS99vXL1+9ZkBTzfrKsyfLU8JAER3+q xVpAdvt8jECkg== Date: Mon, 18 May 2026 10:46:59 +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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260518_024713_315765_D6D8482A X-CRM114-Status: GOOD ( 47.94 ) 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 T24gU3VuLCBNYXkgMTcsIDIwMjYgYXQgMDQ6NDU6MTVQTSArMDgwMCwgQmFycnkgU29uZyB3cm90 ZToKPiBPbiBTYXQsIE1heSAyLCAyMDI2IGF0IDE6NTjigK9BTSBNYXR0aGV3IFdpbGNveCA8d2ls bHlAaW5mcmFkZWFkLm9yZz4gd3JvdGU6Cj4gPgo+ID4gT24gU2F0LCBNYXkgMDIsIDIwMjYgYXQg MDE6NDQ6MzRBTSArMDgwMCwgQmFycnkgU29uZyB3cm90ZToKPiA+ID4gT24gRnJpLCBNYXkgMSwg MjAyNiBhdCAxMDo1N+KAr1BNIE1hdHRoZXcgV2lsY294IDx3aWxseUBpbmZyYWRlYWQub3JnPiB3 cm90ZToKPiA+ID4gPgo+ID4gPiA+IE9uIEZyaSwgTWF5IDAxLCAyMDI2IGF0IDA2OjQ5OjU4QU0g KzA4MDAsIEJhcnJ5IFNvbmcgd3JvdGU6Cj4gPiA+ID4gPiAxLiBUaGVyZSBpcyBubyBkZXRlcm1p bmlzdGljIGxhdGVuY3kgZm9yIEkvTyBjb21wbGV0aW9uLiBJdCBkZXBlbmRzIG9uCj4gPiA+ID4g PiBib3RoIHRoZSBoYXJkd2FyZSBhbmQgdGhlIHNvZnR3YXJlIHN0YWNrIChiaW8vcmVxdWVzdCBx dWV1ZXMgYW5kIHRoZQo+ID4gPiA+ID4gYmxvY2sgc2NoZWR1bGVyKS4gU29tZXRpbWVzIHRoZSBs YXRlbmN5IGlzIHNob3J0OyBhdCBvdGhlciB0aW1lcyBpdCBjYW4KPiA+ID4gPiA+IGJlIHF1aXRl IGxvbmcuIEluIHN1Y2ggY2FzZXMsIGEgaGlnaC1wcmlvcml0eSB0aHJlYWQgcGVyZm9ybWluZyBv cGVyYXRpb25zCj4gPiA+ID4gPiBzdWNoIGFzIG1wcm90ZWN0LCB1bm1hcCwgcHJjdGxfc2V0X3Zt YSwgb3IgbWFkdmlzZSBtYXkgYmUgZm9yY2VkIHRvIHdhaXQKPiA+ID4gPiA+IGZvciBhbiB1bnBy ZWRpY3RhYmxlIGFtb3VudCBvZiB0aW1lLgo+ID4gPiA+Cj4gPiA+ID4gQnV0IGRvZXMgdGhhdCBh Y3R1YWxseSBoYXBwZW4/ICBJIGZpbmQgaXQgaGFyZCB0byBiZWxpZXZlIHRoYXQgdGhyZWFkIEEK PiA+ID4gPiB1bm1hcHMgYSBWTUEgd2hpbGUgdGhyZWFkIEIgaXMgaW4gdGhlIG1pZGRsZSBvZiB0 YWtpbmcgYSBwYWdlIGZhdWx0IGluCj4gPiA+ID4gdGhhdCBzYW1lIFZNQS4gIG1wcm90ZWN0KCkg YW5kIG1hZHZpc2UoKSBhcmUgbW9yZSBsaWtlbHkgdG8gaGFwcGVuLCBidXQKPiA+ID4gPiBpdCBz dGlsbCBzZWVtcyByZWFsbHkgdW5saWtlbHkgdG8gbWUuCj4gPiA+Cj4gPiA+IEl0IGRvZXNu4oCZ dCBoYXZlIHRvIGludm9sdmUgdW5tYXBwaW5nIG9yIGFwcGx5aW5nIG1wcm90ZWN0IHRvCj4gPiA+ IHRoZSBlbnRpcmUgVk1B4oCUanVzdCBhIHBvcnRpb24gb2YgaXQgaXMgc3VmZmljaWVudC4KPiA+ Cj4gPiBZZXMsIGJ1dCB0aGF0IHN0aWxsIGZhaWxzIHRvIGFuc3dlciAiZG9lcyB0aGlzIGFjdHVh bGx5IGhhcHBlbiIuICBIb3cgbXVjaAo+ID4gcGVyZm9ybWFuY2UgaXMgYWxsIHRoaXMgY29tcGxl eGl0eSBpbiB0aGUgcGFnZSBmYXVsdCBoYW5kbGVyIGJ1eWluZyB1cz8KPiA+IElmIHlvdSBkb24n dCBhbnN3ZXIgdGhpcyBxdWVzdGlvbiwgSSdtIGp1c3QgZ29pbmcgdG8gZ28gaW4gYW5kIHJpcCBp dAo+ID4gYWxsIG91dC4KPiA+Cj4KPiBIaSBNYXR0aGV3IChhbmQgTG9yZW56bywgSmFuLCBhbmQg YW55b25lIGVsc2Ugd2hvIG1heSBiZQo+IHdhaXRpbmcgZm9yIGFuc3dlcnMpLAo+Cj4gQXMgcHJv bWlzZWQgZHVyaW5nIExTRi9NTS9CUEYsIHdlIGNvbmR1Y3RlZCB0aG9yb3VnaAo+IHRlc3Rpbmcg b24gQW5kcm9pZCBwaG9uZXMgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgcGVyZm9ybWluZwo+IEkvTyBp biBgZmlsZW1hcF9mYXVsdCgpYCBjYW4gYmxvY2sgYHZtYV9zdGFydF93cml0ZSgpYC4KPiBJIHdh bnRlZCB0byBnaXZlIGEgcXVpY2sgdXBkYXRlIG9uIHRoaXMgcXVlc3Rpb24uCj4KPiBOYW56aGUg YXQgWGlhb21pIGNyZWF0ZWQgdHJhY2luZyBzY3JpcHRzIGFuZCByYW4gdmFyaW91cwo+IGFwcGxp Y2F0aW9ucyBvbiBBbmRyb2lkIGRldmljZXMgd2l0aCBJL08gcGVyZm9ybWVkIHVuZGVyCj4gdGhl IFZNQSBsb2NrIGluIGBmaWxlbWFwX2ZhdWx0KClgLiBXZSBmb3VuZCB0aGF0Ogo+Cj4gMS4gVGhl cmUgYXJlIHZlcnkgZmV3IGNhc2VzIHdoZXJlIHVubWFwKCkgaXMgYmxvY2tlZCBieQo+ICAgIHBh Z2UgZmF1bHRzLiBJIGFzc3VtZSB0aGlzIGlzIGR1ZSB0byBidWdneSB1c2VyIGNvZGUKPiAgICBv ciBwb29yIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIHJlYWRzIGFuZCB1bm1hcCgpLgo+IFNvIEkg YXNzdW1lIGl0IGlzIG5vdCBhIHByb2JsZW0uCj4KPiAyLiBXZSBvYnNlcnZlZCBtYW55IGNhc2Vz IHdoZXJlIGB2bWFfc3RhcnRfd3JpdGUoKWAKPiAgICBpcyBibG9ja2VkIGJ5IHBhZ2UtZmF1bHQg SS9PIGluIHNvbWUgYXBwbGljYXRpb25zLgo+ICAgIFRoZSBibG9ja2luZyBvY2N1cnMgaW4gdGhl IGBkdXBfbW1hcCgpYCBwYXRoIGR1cmluZwo+ICAgIGZvcmsoKS4KPgo+IFdpdGggU3VyZW4ncyBj b21taXQgZmI0OWM0NTUzMjNmZiAoImZvcms6IGxvY2sgVk1BcyBvZgo+IHRoZSBwYXJlbnQgcHJv Y2VzcyB3aGVuIGZvcmtpbmciKSwgd2Ugbm93IGFsd2F5cyBob2xkCj4gYHZtYV93cml0ZV9sb2Nr KClgIGZvciBlYWNoIFZNQS4gTm90ZSB0aGF0IHRoZQo+IGBtbWFwX2xvY2tgIHdyaXRlIGxvY2sg aXMgYWxzbyBoZWxkLCB3aGljaCBjb3VsZCBsZWFkIHRvCj4gY2hhaW5lZCB3YWl0aW5nIGlmIHBh Z2UtZmF1bHQgSS9PIGlzIHBlcmZvcm1lZCB3aXRob3V0Cj4gcmVsZWFzaW5nIHRoZSBWTUEgbG9j ay4KCkhtIGJ1dCBkaWQgeW91IG9ic2VydmUgdGhpcyAnY2hhaW5lZCB3YWl0aW5nJz8gQW5kIHdo YXQgd2VyZSB0aGUgbGF0ZW5jaWVzPwoKPgo+IE15IGd1dCBmZWVsaW5nIGlzIHRoYXQgU3VyZW4n cyBjb21taXQgbWF5IGJlIG92ZXJzaG9vdGluZywKPiBzbyBteSByb3VnaCBpZGVhIGlzIHRoYXQg d2UgbWlnaHQgd2FudCB0byBkbyBzb21ldGhpbmcgbGlrZQo+IHRoZSBmb2xsb3dpbmcgKHdlIGhh dmVuJ3QgdGVzdGVkIGl0IHlldCBhbmQgaXQgbWlnaHQgYmUKPiB3cm9uZyk6CgpZZWFoIEknbSBy ZWFsbHkgbm90IHN1cmUgYWJvdXQgdGhhdC4KClByaW9yIHRvIHRoZSBWTUEgbG9ja3MsIHRoZSBt bWFwIHdyaXRlIGxvY2sgd291bGQgaGF2ZSBndWFyYW50ZWVkIG5vIGNvbmN1cnJlbnQKcGFnZSBm YXVsdHMsIHdoaWNoIGlzIHJlYWxseSB3aGF0IGZiNDljNDU1MzIzZmYgaXMgYWJvdXQuCgpTbyBT dXJlbidzIHBhdGNoIHdhcyBlc3NlbnRpYWxseSByZXN0b3JpbmcgdGhlIF9leGlzdGluZ18gZm9y a2luZyBiZWhhdmlvdXIsIGFuZApub3cgeW91J3JlIHNheWluZyAnbGV0J3MgY2hhbmdlIHRoZSBm b3JraW5nIGJlaGF2aW91ciB0aGF0J3MgYmVlbiBsaWtlIHRoYXQgZm9yCmZvcmV2ZXInLgoKSSB0 aGluayB5b3Ugd291bGQgX3JlYWxseV8gaGF2ZSB0byBiZSBzdXJlIHRoYXQncyBzYWZlLiBBbmQg Zm9ya2luZyBpcyBhIHZlcnkKZGFuZ2Vyb3VzIHRpbWUgaW4gdGVybXMgb2YgY29tcGxleGl0eSBh bmQgc2Vuc2l0aXZpdHkgYW5kICd3ZWlyZCBzdHVmZicKaGFwcGVuaW5nIHNvIEknZCB0cmVhZCBf dmVyeV8gY2FyZWZ1bGx5IGhlcmUuCgo+Cj4gZGlmZiAtLWdpdCBhL21tL21tYXAuYyBiL21tL21t YXAuYwo+IGluZGV4IDIzMTFhZTdjMmZmNC4uNWRkYWYyOTdmMzFhIDEwMDY0NAo+IC0tLSBhL21t L21tYXAuYwo+ICsrKyBiL21tL21tYXAuYwo+IEBAIC0xNzYyLDcgKzE3NjIsMTMgQEAgX19sYXRl bnRfZW50cm9weSBpbnQgZHVwX21tYXAoc3RydWN0IG1tX3N0cnVjdAo+ICptbSwgc3RydWN0IG1t X3N0cnVjdCAqb2xkbW0pCj4gICAgICAgICBmb3JfZWFjaF92bWEodm1pLCBtcG50KSB7Cj4gICAg ICAgICAgICAgICAgIHN0cnVjdCBmaWxlICpmaWxlOwo+Cj4gLSAgICAgICAgICAgICAgIHJldHZh bCA9IHZtYV9zdGFydF93cml0ZV9raWxsYWJsZShtcG50KTsKPiArICAgICAgICAgICAgICAgLyoK PiArICAgICAgICAgICAgICAgICogRm9yIGFub255bW91cyBvciB3cml0YWJsZSBwcml2YXRlIFZN QXMsIHByZXZlbnQKPiArICAgICAgICAgICAgICAgICogY29uY3VycmVudCBDb1cgZmF1bHRzLgo+ ICsgICAgICAgICAgICAgICAgKi8KClRvIG5pdCBwaWNrIEkgdGhpbmsgdGhlIGNvbW1lbnQncyBj b25mdXNpbmcgYnV0IGFsc28gdGVsbHMgeW91IHlvdSBkb24ndCBuZWVkIHRvCnNwZWNpZmljIGFu b24gY2hlY2sgLSB3cml0YWJsZSBwcml2YXRlIGlzIHN1ZmZpY2llbnQuIEFuZCBpdCdzIG5vdCBy ZWFsbHkganVzdApDb1cgdGhhdCdzIHRoZSBpc3N1ZSwgaXQncyBhbm9uX3ZtYSBwb3B1bGF0aW9u IF9hdCBhbGxfIGFzIHdlbGwgYXMgQ29XLgoKPiArICAgICAgICAgICAgICAgaWYgKCFtcG50LT52 bV9maWxlIHx8ICghKG1wbnQtPnZtX2ZsYWdzICYgVk1fU0hBUkVEKSAmJgo+ICsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobXBudC0+dm1fZmxhZ3MgJiBWTV9XUklURSkp KQo+ICsgICAgICAgICAgICAgICAgICAgICAgIHJldHZhbCA9IHZtYV9zdGFydF93cml0ZV9raWxs YWJsZShtcG50KTsKCkkgdGhpbmsgdGhpcyBoYXMgdG8gYmUgVk1fTUFZV1JJVEUsIGJlY2F1c2Ug c29tZWJvZHkgY291bGQgb3RoZXJ3aXNlIG1wcm90ZWN0KCkKaXQgUi9XLgoKSSBhbHNvIGRvbid0 IHVuZGVyc3RhbmQgd2h5ICFtcG50LT52bV9maWxlIGZvciBhIHJlYWQtb25seSBhbm9uIG1hcHBp bmcgKG1vcmUKbGlrZWx5IFBST1RfTk9ORSkgaXMgaGVyZSwganVzdCBkbyB0aGUgc2Vjb25kIGNo ZWNrPwoKKEFsc28gcGxlYXNlIHVzZSB0aGUgbmV3IGludGVyZmFjZSwgc28gIXZtYV90ZXN0KG1w bnQsIFZNQV9TSEFSRURfQklUKSAmJgp2bWFfdGVzdChtcG50LCBWTUFfTUFZV1JJVEVfQklUKSkK Cj4gICAgICAgICAgICAgICAgIGlmIChyZXR2YWwgPCAwKQo+ICAgICAgICAgICAgICAgICAgICAg ICAgIGdvdG8gbG9vcF9vdXQ7Cj4gICAgICAgICAgICAgICAgIGlmIChtcG50LT52bV9mbGFncyAm IFZNX0RPTlRDT1BZKSB7Cj4KPiBCYXNlZCBvbiB0aGUgYWJvdmUsIHdlIG1heSB3YW50IHRvIHJl LWNoZWNrIHdoZXRoZXIgZm9yaygpCj4gY2FuIGJlIGJsb2NrZWQgYnkgcGFnZSBmYXVsdHMuIEF0 IHRoZSBzYW1lIHRpbWUsIGlmIFN1cmVuLAo+IHlvdSwgb3IgYW55b25lIGVsc2UgaGFzIGFueSBj b21tZW50cywgcGxlYXNlIGZlZWwgZnJlZSB0bwo+IHNoYXJlIHRoZW0uCj4KPiBCZXN0IFJlZ2Fy ZHMKPiBCYXJyeQoKVGVjaG5pY2FsIGNvbW1lbnRhcnkgYWJvdmUgaXMgc29ydCBvZiAnanVzdCBj b3MnIDopIGJlY2F1c2UgSSByZWFsbHkgcXVlc3Rpb24KZG9pbmcgdGhpcyBob25lc3RseS4KCkkn ZCBhbHNvIGxpa2UgdG8gZ2V0IFN1cmVuJ3MgaW5wdXQsIGhvd2V2ZXIuCgpUaGFua3MsIExvcmVu em8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4 LXJpc2N2IG1haWxpbmcgbGlzdApsaW51eC1yaXNjdkBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6 Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtcmlzY3YK