From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3445053BA for ; Wed, 5 Jul 2023 10:53:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688554418; x=1720090418; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=IBLKigB688l4z6znm/BvrWmSXP37deMHsQcHbbqjCj4=; b=glGD/4oRoI4J0pb/kCEUvpQoBtlb6qLXx6ZlUpub8DsKVNrNACRWPyLU hz9kIP3UYH5z6437nip4ImsnCgesA3D3L8ydkKehKHJ0ONDtqDomyNc/F hv2/tNGtZU0fO2nEVq1UWNXMp8Qj9rLSbGLbB5eQs8cbn23TiTQ6j4gTH I+rdcmzJY9ZI4eg8O1Gsnw0sql5wxlInNdRQmqhemofI35Ky+u2SqRQYi ibMoYEgWxg/bMHvQXN+dmqaEPsYb5WHcyaK6bOUnhLE6mgN2xAiIdhhfp WaDEOvgQz2ARvg5xy2c2HEMlEroVHhZruH95ddMTjsVusCnDKjfaPxYDN A==; X-IronPort-AV: E=McAfee;i="6600,9927,10761"; a="394063291" X-IronPort-AV: E=Sophos;i="6.01,182,1684825200"; d="scan'208";a="394063291" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2023 03:53:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10761"; a="809217086" X-IronPort-AV: E=Sophos;i="6.01,182,1684825200"; d="scan'208";a="809217086" Received: from jialinji-mobl4.ccr.corp.intel.com (HELO localhost) ([10.255.30.200]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2023 03:53:33 -0700 Date: Wed, 5 Jul 2023 18:53:43 +0800 From: Yu Zhang To: David Stevens Cc: Sean Christopherson , Marc Zyngier , Michael Ellerman , Peter Xu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org Subject: Re: [PATCH v7 2/8] KVM: Introduce __kvm_follow_pfn function Message-ID: <20230705105343.iounmlflfued7lco@linux.intel.com> References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-3-stevensd@google.com> <20230705031002.xrxk42hli6oavtlt@linux.intel.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 On Wed, Jul 05, 2023 at 06:22:59PM +0900, David Stevens wrote: > On Wed, Jul 5, 2023 at 12:10 PM Yu Zhang wrote: > > > > > @@ -2514,35 +2512,26 @@ static bool hva_to_pfn_fast(unsigned long addr, bool write_fault, > > > * The slow path to get the pfn of the specified host virtual address, > > > * 1 indicates success, -errno is returned if error is detected. > > > */ > > > -static int hva_to_pfn_slow(unsigned long addr, bool *async, bool write_fault, > > > - bool interruptible, bool *writable, kvm_pfn_t *pfn) > > > +static int hva_to_pfn_slow(struct kvm_follow_pfn *foll, kvm_pfn_t *pfn) > > > { > > > - unsigned int flags = FOLL_HWPOISON; > > > + unsigned int flags = FOLL_HWPOISON | FOLL_GET | foll->flags; > > > struct page *page; > > > int npages; > > > > > > might_sleep(); > > > > > > - if (writable) > > > - *writable = write_fault; > > > - > > > - if (write_fault) > > > - flags |= FOLL_WRITE; > > > - if (async) > > > - flags |= FOLL_NOWAIT; > > > - if (interruptible) > > > - flags |= FOLL_INTERRUPTIBLE; > > > - > > > - npages = get_user_pages_unlocked(addr, 1, &page, flags); > > > + npages = get_user_pages_unlocked(foll->hva, 1, &page, flags); > > > if (npages != 1) > > > return npages; > > > > > > + foll->writable = (foll->flags & FOLL_WRITE) && foll->allow_write_mapping; > > > + > > > /* map read fault as writable if possible */ > > > - if (unlikely(!write_fault) && writable) { > > > + if (unlikely(!foll->writable) && foll->allow_write_mapping) { > > > > I guess !foll->writable should be !(foll->flags & FOLL_WRITE) here. > > The two statements are logically equivalent, although I guess using > !(foll->flags & FOLL_WRITE) may be a little clearer, if a little more > verbose. Well, as the comment says, we wanna try to map the read fault as writable whenever possible. And __gfn_to_pfn_memslot() will only set the FOLL_WRITE for write faults. So I guess using !foll->writable will not allow this. Did I miss anything? > > > +kvm_pfn_t __gfn_to_pfn_memslot(const struct kvm_memory_slot *slot, gfn_t gfn, > > > + bool atomic, bool interruptible, bool *async, > > > + bool write_fault, bool *writable, hva_t *hva) > > > +{ > > > + kvm_pfn_t pfn; > > > + struct kvm_follow_pfn foll = { > > > + .slot = slot, > > > + .gfn = gfn, > > > + .flags = 0, > > > + .atomic = atomic, > > > + .allow_write_mapping = !!writable, > > > + }; > > > + > > > + if (write_fault) > > > + foll.flags |= FOLL_WRITE; > > > + if (async) > > > + foll.flags |= FOLL_NOWAIT; > > > + if (interruptible) > > > + foll.flags |= FOLL_INTERRUPTIBLE; > > > + > > > + pfn = __kvm_follow_pfn(&foll); > > > + if (pfn == KVM_PFN_ERR_NEEDS_IO) { > > > > Could we just use KVM_PFN_ERR_FAULT and foll.flags here? I.e., > > if (pfn == KVM_PFN_ERR_FAULT && (foll.flags & FOLL_NOWAIT))? > > Setting pfn to KVM_PFN_ERR_NEEDS_IO just to indicate an async fault > > seems unnecessary. > > There are the cases where the fault does not fall within a vma or when > the target vma's flags don't support the fault's access permissions. > In those cases, continuing to try to resolve the fault won't cause > problems per-se, but it's wasteful and a bit confusing. Having > hva_to_pfn detect whether or not it may be possible to resolve the > fault asynchronously and return KVM_PFN_ERR_NEEDS_IO if so seems like > a good idea. It also matches what the existing code does. Got it. Sounds reasonable. And thanks! :) B.R. Yu 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 794E8EB64DA for ; Wed, 5 Jul 2023 10:54:37 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=khcTuNNK; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4QwxPR6dB7z3br5 for ; Wed, 5 Jul 2023 20:54:35 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=khcTuNNK; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.intel.com (client-ip=192.55.52.88; helo=mga01.intel.com; envelope-from=yu.c.zhang@linux.intel.com; receiver=lists.ozlabs.org) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4QwxNP6kzjz3031 for ; Wed, 5 Jul 2023 20:53:40 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688554422; x=1720090422; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=IBLKigB688l4z6znm/BvrWmSXP37deMHsQcHbbqjCj4=; b=khcTuNNKVThjmc9/ty8p2K//Z8NNDLTTEb1ZAniOk06lHfKTYoawpMIe dguCbWN4t2wHdwi30EfwD9JpTZHhDE/NpTzqbHDWxuuXlnPATMJSwQlgT qZKcMGTOtkAk1kkszS0lQX5QutpgaG0xBCqIGqVFhbhmEzpHHKZ55JJ+S tAvhdfGMwfxzKVs4tArcF1jd0cKW0k+FUQxnV1YUx9TRYCpIhu4LodpS2 a8QQoq2282+0XISzWWXgdFArjFdgEq9Y9cUCFUnfotnIWAK2QiCk50l7z jAFYp6o/rQttqwUIRJzaN4xoNac2fzusL8iiMBgsZT3cKbrX0dzBi91dn Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10761"; a="394063294" X-IronPort-AV: E=Sophos;i="6.01,182,1684825200"; d="scan'208";a="394063294" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2023 03:53:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10761"; a="809217086" X-IronPort-AV: E=Sophos;i="6.01,182,1684825200"; d="scan'208";a="809217086" Received: from jialinji-mobl4.ccr.corp.intel.com (HELO localhost) ([10.255.30.200]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2023 03:53:33 -0700 Date: Wed, 5 Jul 2023 18:53:43 +0800 From: Yu Zhang To: David Stevens Subject: Re: [PATCH v7 2/8] KVM: Introduce __kvm_follow_pfn function Message-ID: <20230705105343.iounmlflfued7lco@linux.intel.com> References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-3-stevensd@google.com> <20230705031002.xrxk42hli6oavtlt@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , kvm@vger.kernel.org, Sean Christopherson , linux-kernel@vger.kernel.org, Peter Xu , kvmarm@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Jul 05, 2023 at 06:22:59PM +0900, David Stevens wrote: > On Wed, Jul 5, 2023 at 12:10 PM Yu Zhang wrote: > > > > > @@ -2514,35 +2512,26 @@ static bool hva_to_pfn_fast(unsigned long addr, bool write_fault, > > > * The slow path to get the pfn of the specified host virtual address, > > > * 1 indicates success, -errno is returned if error is detected. > > > */ > > > -static int hva_to_pfn_slow(unsigned long addr, bool *async, bool write_fault, > > > - bool interruptible, bool *writable, kvm_pfn_t *pfn) > > > +static int hva_to_pfn_slow(struct kvm_follow_pfn *foll, kvm_pfn_t *pfn) > > > { > > > - unsigned int flags = FOLL_HWPOISON; > > > + unsigned int flags = FOLL_HWPOISON | FOLL_GET | foll->flags; > > > struct page *page; > > > int npages; > > > > > > might_sleep(); > > > > > > - if (writable) > > > - *writable = write_fault; > > > - > > > - if (write_fault) > > > - flags |= FOLL_WRITE; > > > - if (async) > > > - flags |= FOLL_NOWAIT; > > > - if (interruptible) > > > - flags |= FOLL_INTERRUPTIBLE; > > > - > > > - npages = get_user_pages_unlocked(addr, 1, &page, flags); > > > + npages = get_user_pages_unlocked(foll->hva, 1, &page, flags); > > > if (npages != 1) > > > return npages; > > > > > > + foll->writable = (foll->flags & FOLL_WRITE) && foll->allow_write_mapping; > > > + > > > /* map read fault as writable if possible */ > > > - if (unlikely(!write_fault) && writable) { > > > + if (unlikely(!foll->writable) && foll->allow_write_mapping) { > > > > I guess !foll->writable should be !(foll->flags & FOLL_WRITE) here. > > The two statements are logically equivalent, although I guess using > !(foll->flags & FOLL_WRITE) may be a little clearer, if a little more > verbose. Well, as the comment says, we wanna try to map the read fault as writable whenever possible. And __gfn_to_pfn_memslot() will only set the FOLL_WRITE for write faults. So I guess using !foll->writable will not allow this. Did I miss anything? > > > +kvm_pfn_t __gfn_to_pfn_memslot(const struct kvm_memory_slot *slot, gfn_t gfn, > > > + bool atomic, bool interruptible, bool *async, > > > + bool write_fault, bool *writable, hva_t *hva) > > > +{ > > > + kvm_pfn_t pfn; > > > + struct kvm_follow_pfn foll = { > > > + .slot = slot, > > > + .gfn = gfn, > > > + .flags = 0, > > > + .atomic = atomic, > > > + .allow_write_mapping = !!writable, > > > + }; > > > + > > > + if (write_fault) > > > + foll.flags |= FOLL_WRITE; > > > + if (async) > > > + foll.flags |= FOLL_NOWAIT; > > > + if (interruptible) > > > + foll.flags |= FOLL_INTERRUPTIBLE; > > > + > > > + pfn = __kvm_follow_pfn(&foll); > > > + if (pfn == KVM_PFN_ERR_NEEDS_IO) { > > > > Could we just use KVM_PFN_ERR_FAULT and foll.flags here? I.e., > > if (pfn == KVM_PFN_ERR_FAULT && (foll.flags & FOLL_NOWAIT))? > > Setting pfn to KVM_PFN_ERR_NEEDS_IO just to indicate an async fault > > seems unnecessary. > > There are the cases where the fault does not fall within a vma or when > the target vma's flags don't support the fault's access permissions. > In those cases, continuing to try to resolve the fault won't cause > problems per-se, but it's wasteful and a bit confusing. Having > hva_to_pfn detect whether or not it may be possible to resolve the > fault asynchronously and return KVM_PFN_ERR_NEEDS_IO if so seems like > a good idea. It also matches what the existing code does. Got it. Sounds reasonable. And thanks! :) B.R. Yu 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 34679EB64DA for ; Thu, 6 Jul 2023 01:40:18 +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=2cerRR9r0ZRN/4aEWKINd0s17q9+g6v01trlySBuE0A=; b=V240uyCB1UM51p 8sXo3Unn6gRi+hVsuWdmUQnF6CsCB1iU9QD0N5Kyv7ALgC4gTKKrsb/D89W+rusKdzaTQ2lJlB2mJ qnhKKamPPrDXC027M4h3rRcNzY0SgyzDACkqSGe40Q8DqnVH9Gn0ozFJ1NIpn5lpcUm814OWPTSP9 jJGBvOT7L9kFzBaDcQXNMg89giO7JoEzL1DA294aN96mFdSuEcsWskvodYP/xGxWcZKNPBw1r820N 65dPccpLb2x1+34G1gbQC/QHn8k1+AVoHKtg8vR2vSFN5YjbeU0srmiujeO+49UgyEhFBbKMqrfg8 yqcKzC8CJ5n6o1GUmLxQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qHDyP-00Hayi-0s; Thu, 06 Jul 2023 01:39:57 +0000 Received: from mga01.intel.com ([192.55.52.88]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qHDyK-00HasH-0k for linux-arm-kernel@lists.infradead.org; Thu, 06 Jul 2023 01:39:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688607592; x=1720143592; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=IBLKigB688l4z6znm/BvrWmSXP37deMHsQcHbbqjCj4=; b=PYEymVs3A8ulBfj1HnX3yYsTUxLd1/y+r/X/Vogptjg7G9ZI1NUGXshI DEmMc/LX7NHbunxxjFKwByDzt2NlZN7GBNDCb0ujpEDUcdOSWhBT90nsQ xmj3NajMg2w+EY1u/5zybarXQBGG9Jrf1RAIL1zmdi3hYTP5dnUzDKcJ/ BjfrzR1bw4YOMcUfDXos/720M9mS7AB0u5opMoBRsLJlsgryZnYaQE3jD QuMTWejWZdlw+4Gu1Mh2rLmaNuKrBQgwsFHZkLbVZ1sc3w4Wb7VRpDaa6 jGl2D/6/EGyw+5MBGPNrBVmqb3JZB9PpjPPcGV7LhBYeP0wL3Scd7cyNA w==; X-IronPort-AV: E=McAfee;i="6600,9927,10761"; a="394063292" X-IronPort-AV: E=Sophos;i="6.01,182,1684825200"; d="scan'208";a="394063292" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2023 03:53:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10761"; a="809217086" X-IronPort-AV: E=Sophos;i="6.01,182,1684825200"; d="scan'208";a="809217086" Received: from jialinji-mobl4.ccr.corp.intel.com (HELO localhost) ([10.255.30.200]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2023 03:53:33 -0700 Date: Wed, 5 Jul 2023 18:53:43 +0800 From: Yu Zhang To: David Stevens Cc: Sean Christopherson , Marc Zyngier , Michael Ellerman , Peter Xu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org Subject: Re: [PATCH v7 2/8] KVM: Introduce __kvm_follow_pfn function Message-ID: <20230705105343.iounmlflfued7lco@linux.intel.com> References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-3-stevensd@google.com> <20230705031002.xrxk42hli6oavtlt@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230705_183952_299477_8D74EC47 X-CRM114-Status: GOOD ( 25.88 ) 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gV2VkLCBKdWwgMDUsIDIwMjMgYXQgMDY6MjI6NTlQTSArMDkwMCwgRGF2aWQgU3RldmVucyB3 cm90ZToKPiBPbiBXZWQsIEp1bCA1LCAyMDIzIGF0IDEyOjEw4oCvUE0gWXUgWmhhbmcgPHl1LmMu emhhbmdAbGludXguaW50ZWwuY29tPiB3cm90ZToKPiA+Cj4gPiA+IEBAIC0yNTE0LDM1ICsyNTEy LDI2IEBAIHN0YXRpYyBib29sIGh2YV90b19wZm5fZmFzdCh1bnNpZ25lZCBsb25nIGFkZHIsIGJv b2wgd3JpdGVfZmF1bHQsCj4gPiA+ICAgKiBUaGUgc2xvdyBwYXRoIHRvIGdldCB0aGUgcGZuIG9m IHRoZSBzcGVjaWZpZWQgaG9zdCB2aXJ0dWFsIGFkZHJlc3MsCj4gPiA+ICAgKiAxIGluZGljYXRl cyBzdWNjZXNzLCAtZXJybm8gaXMgcmV0dXJuZWQgaWYgZXJyb3IgaXMgZGV0ZWN0ZWQuCj4gPiA+ ICAgKi8KPiA+ID4gLXN0YXRpYyBpbnQgaHZhX3RvX3Bmbl9zbG93KHVuc2lnbmVkIGxvbmcgYWRk ciwgYm9vbCAqYXN5bmMsIGJvb2wgd3JpdGVfZmF1bHQsCj4gPiA+IC0gICAgICAgICAgICAgICAg ICAgICAgICBib29sIGludGVycnVwdGlibGUsIGJvb2wgKndyaXRhYmxlLCBrdm1fcGZuX3QgKnBm bikKPiA+ID4gK3N0YXRpYyBpbnQgaHZhX3RvX3Bmbl9zbG93KHN0cnVjdCBrdm1fZm9sbG93X3Bm biAqZm9sbCwga3ZtX3Bmbl90ICpwZm4pCj4gPiA+ICB7Cj4gPiA+IC0gICAgIHVuc2lnbmVkIGlu dCBmbGFncyA9IEZPTExfSFdQT0lTT047Cj4gPiA+ICsgICAgIHVuc2lnbmVkIGludCBmbGFncyA9 IEZPTExfSFdQT0lTT04gfCBGT0xMX0dFVCB8IGZvbGwtPmZsYWdzOwo+ID4gPiAgICAgICBzdHJ1 Y3QgcGFnZSAqcGFnZTsKPiA+ID4gICAgICAgaW50IG5wYWdlczsKPiA+ID4KPiA+ID4gICAgICAg bWlnaHRfc2xlZXAoKTsKPiA+ID4KPiA+ID4gLSAgICAgaWYgKHdyaXRhYmxlKQo+ID4gPiAtICAg ICAgICAgICAgICp3cml0YWJsZSA9IHdyaXRlX2ZhdWx0Owo+ID4gPiAtCj4gPiA+IC0gICAgIGlm ICh3cml0ZV9mYXVsdCkKPiA+ID4gLSAgICAgICAgICAgICBmbGFncyB8PSBGT0xMX1dSSVRFOwo+ ID4gPiAtICAgICBpZiAoYXN5bmMpCj4gPiA+IC0gICAgICAgICAgICAgZmxhZ3MgfD0gRk9MTF9O T1dBSVQ7Cj4gPiA+IC0gICAgIGlmIChpbnRlcnJ1cHRpYmxlKQo+ID4gPiAtICAgICAgICAgICAg IGZsYWdzIHw9IEZPTExfSU5URVJSVVBUSUJMRTsKPiA+ID4gLQo+ID4gPiAtICAgICBucGFnZXMg PSBnZXRfdXNlcl9wYWdlc191bmxvY2tlZChhZGRyLCAxLCAmcGFnZSwgZmxhZ3MpOwo+ID4gPiAr ICAgICBucGFnZXMgPSBnZXRfdXNlcl9wYWdlc191bmxvY2tlZChmb2xsLT5odmEsIDEsICZwYWdl LCBmbGFncyk7Cj4gPiA+ICAgICAgIGlmIChucGFnZXMgIT0gMSkKPiA+ID4gICAgICAgICAgICAg ICByZXR1cm4gbnBhZ2VzOwo+ID4gPgo+ID4gPiArICAgICBmb2xsLT53cml0YWJsZSA9IChmb2xs LT5mbGFncyAmIEZPTExfV1JJVEUpICYmIGZvbGwtPmFsbG93X3dyaXRlX21hcHBpbmc7Cj4gPiA+ ICsKPiA+ID4gICAgICAgLyogbWFwIHJlYWQgZmF1bHQgYXMgd3JpdGFibGUgaWYgcG9zc2libGUg Ki8KPiA+ID4gLSAgICAgaWYgKHVubGlrZWx5KCF3cml0ZV9mYXVsdCkgJiYgd3JpdGFibGUpIHsK PiA+ID4gKyAgICAgaWYgKHVubGlrZWx5KCFmb2xsLT53cml0YWJsZSkgJiYgZm9sbC0+YWxsb3df d3JpdGVfbWFwcGluZykgewo+ID4KPiA+IEkgZ3Vlc3MgIWZvbGwtPndyaXRhYmxlIHNob3VsZCBi ZSAhKGZvbGwtPmZsYWdzICYgRk9MTF9XUklURSkgaGVyZS4KPiAKPiBUaGUgdHdvIHN0YXRlbWVu dHMgYXJlIGxvZ2ljYWxseSBlcXVpdmFsZW50LCBhbHRob3VnaCBJIGd1ZXNzIHVzaW5nCj4gIShm b2xsLT5mbGFncyAmIEZPTExfV1JJVEUpIG1heSBiZSBhIGxpdHRsZSBjbGVhcmVyLCBpZiBhIGxp dHRsZSBtb3JlCj4gdmVyYm9zZS4KCldlbGwsIGFzIHRoZSBjb21tZW50IHNheXMsIHdlIHdhbm5h IHRyeSB0byBtYXAgdGhlIHJlYWQgZmF1bHQgYXMgd3JpdGFibGUKd2hlbmV2ZXIgcG9zc2libGUu IEFuZCBfX2dmbl90b19wZm5fbWVtc2xvdCgpIHdpbGwgb25seSBzZXQgdGhlIEZPTExfV1JJVEUK Zm9yIHdyaXRlIGZhdWx0cy4gU28gSSBndWVzcyB1c2luZyAhZm9sbC0+d3JpdGFibGUgd2lsbCBu b3QgYWxsb3cgdGhpcy4KRGlkIEkgbWlzcyBhbnl0aGluZz8KCj4gPiA+ICtrdm1fcGZuX3QgX19n Zm5fdG9fcGZuX21lbXNsb3QoY29uc3Qgc3RydWN0IGt2bV9tZW1vcnlfc2xvdCAqc2xvdCwgZ2Zu X3QgZ2ZuLAo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJvb2wgYXRvbWljLCBi b29sIGludGVycnVwdGlibGUsIGJvb2wgKmFzeW5jLAo+ID4gPiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGJvb2wgd3JpdGVfZmF1bHQsIGJvb2wgKndyaXRhYmxlLCBodmFfdCAqaHZhKQo+ ID4gPiArewo+ID4gPiArICAgICBrdm1fcGZuX3QgcGZuOwo+ID4gPiArICAgICBzdHJ1Y3Qga3Zt X2ZvbGxvd19wZm4gZm9sbCA9IHsKPiA+ID4gKyAgICAgICAgICAgICAuc2xvdCA9IHNsb3QsCj4g PiA+ICsgICAgICAgICAgICAgLmdmbiA9IGdmbiwKPiA+ID4gKyAgICAgICAgICAgICAuZmxhZ3Mg PSAwLAo+ID4gPiArICAgICAgICAgICAgIC5hdG9taWMgPSBhdG9taWMsCj4gPiA+ICsgICAgICAg ICAgICAgLmFsbG93X3dyaXRlX21hcHBpbmcgPSAhIXdyaXRhYmxlLAo+ID4gPiArICAgICB9Owo+ ID4gPiArCj4gPiA+ICsgICAgIGlmICh3cml0ZV9mYXVsdCkKPiA+ID4gKyAgICAgICAgICAgICBm b2xsLmZsYWdzIHw9IEZPTExfV1JJVEU7Cj4gPiA+ICsgICAgIGlmIChhc3luYykKPiA+ID4gKyAg ICAgICAgICAgICBmb2xsLmZsYWdzIHw9IEZPTExfTk9XQUlUOwo+ID4gPiArICAgICBpZiAoaW50 ZXJydXB0aWJsZSkKPiA+ID4gKyAgICAgICAgICAgICBmb2xsLmZsYWdzIHw9IEZPTExfSU5URVJS VVBUSUJMRTsKPiA+ID4gKwo+ID4gPiArICAgICBwZm4gPSBfX2t2bV9mb2xsb3dfcGZuKCZmb2xs KTsKPiA+ID4gKyAgICAgaWYgKHBmbiA9PSBLVk1fUEZOX0VSUl9ORUVEU19JTykgewo+ID4KPiA+ IENvdWxkIHdlIGp1c3QgdXNlIEtWTV9QRk5fRVJSX0ZBVUxUIGFuZCBmb2xsLmZsYWdzIGhlcmU/ IEkuZS4sCj4gPiAgICAgICAgIGlmIChwZm4gPT0gS1ZNX1BGTl9FUlJfRkFVTFQgJiYgKGZvbGwu ZmxhZ3MgJiBGT0xMX05PV0FJVCkpPwo+ID4gU2V0dGluZyBwZm4gdG8gS1ZNX1BGTl9FUlJfTkVF RFNfSU8ganVzdCB0byBpbmRpY2F0ZSBhbiBhc3luYyBmYXVsdAo+ID4gc2VlbXMgdW5uZWNlc3Nh cnkuCj4gCj4gVGhlcmUgYXJlIHRoZSBjYXNlcyB3aGVyZSB0aGUgZmF1bHQgZG9lcyBub3QgZmFs bCB3aXRoaW4gYSB2bWEgb3Igd2hlbgo+IHRoZSB0YXJnZXQgdm1hJ3MgZmxhZ3MgZG9uJ3Qgc3Vw cG9ydCB0aGUgZmF1bHQncyBhY2Nlc3MgcGVybWlzc2lvbnMuCj4gSW4gdGhvc2UgY2FzZXMsIGNv bnRpbnVpbmcgdG8gdHJ5IHRvIHJlc29sdmUgdGhlIGZhdWx0IHdvbid0IGNhdXNlCj4gcHJvYmxl bXMgcGVyLXNlLCBidXQgaXQncyB3YXN0ZWZ1bCBhbmQgYSBiaXQgY29uZnVzaW5nLiBIYXZpbmcK PiBodmFfdG9fcGZuIGRldGVjdCB3aGV0aGVyIG9yIG5vdCBpdCBtYXkgYmUgcG9zc2libGUgdG8g cmVzb2x2ZSB0aGUKPiBmYXVsdCBhc3luY2hyb25vdXNseSBhbmQgcmV0dXJuIEtWTV9QRk5fRVJS X05FRURTX0lPIGlmIHNvIHNlZW1zIGxpa2UKPiBhIGdvb2QgaWRlYS4gSXQgYWxzbyBtYXRjaGVz IHdoYXQgdGhlIGV4aXN0aW5nIGNvZGUgZG9lcy4KCkdvdCBpdC4gU291bmRzIHJlYXNvbmFibGUu IEFuZCB0aGFua3MhIDopCgpCLlIuCll1CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0t a2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFp bG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==