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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5293C33CA4 for ; Fri, 10 Jan 2020 18:39:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C26BC2072E for ; Fri, 10 Jan 2020 18:39:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728556AbgAJSjL (ORCPT ); Fri, 10 Jan 2020 13:39:11 -0500 Received: from foss.arm.com ([217.140.110.172]:49848 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728083AbgAJSjK (ORCPT ); Fri, 10 Jan 2020 13:39:10 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ED92330E; Fri, 10 Jan 2020 10:39:09 -0800 (PST) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E2C323F6C4; Fri, 10 Jan 2020 10:39:06 -0800 (PST) Subject: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo To: Bhupesh Sharma Cc: linux-kernel@vger.kernel.org, bhupesh.linux@gmail.com, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kexec@lists.infradead.org, Mark Rutland , Will Deacon , Steve Capper , Catalin Marinas , Ard Biesheuvel , Dave Anderson , Kazuhito Hagio References: <1575057559-25496-1-git-send-email-bhsharma@redhat.com> <1575057559-25496-3-git-send-email-bhsharma@redhat.com> <63d6e63c-7218-d2dd-8767-4464be83603f@arm.com> From: James Morse Message-ID: Date: Fri, 10 Jan 2020 18:39:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bhupesh, On 25/12/2019 19:01, Bhupesh Sharma wrote: > On 12/12/2019 04:02 PM, James Morse wrote: >> On 29/11/2019 19:59, Bhupesh Sharma wrote: >>> vabits_actual variable on arm64 indicates the actual VA space size, >>> and allows a single binary to support both 48-bit and 52-bit VA >>> spaces. >>> >>> If the ARMv8.2-LVA optional feature is present, and we are running >>> with a 64KB page size; then it is possible to use 52-bits of address >>> space for both userspace and kernel addresses. However, any kernel >>> binary that supports 52-bit must also be able to fall back to 48-bit >>> at early boot time if the hardware feature is not present. >>> >>> Since TCR_EL1.T1SZ indicates the size offset of the memory region >>> addressed by TTBR1_EL1 (and hence can be used for determining the >>> vabits_actual value) it makes more sense to export the same in >>> vmcoreinfo rather than vabits_actual variable, as the name of the >>> variable can change in future kernel versions, but the architectural >>> constructs like TCR_EL1.T1SZ can be used better to indicate intended >>> specific fields to user-space. >>> >>> User-space utilities like makedumpfile and crash-utility, need to >>> read/write this value from/to vmcoreinfo >> >> (write?) > > Yes, also write so that the vmcoreinfo from an (crashing) arm64 system can be used for > analysis of the root-cause of panic/crash on say an x86_64 host using utilities like > crash-utility/gdb. I read this as as "User-space [...] needs to write to vmcoreinfo". >>> for determining if a virtual address lies in the linear map range. >> >> I think this is a fragile example. The debugger shouldn't need to know this. > > Well that the current user-space utility design, so I am not sure we can tweak that too much. > >>> The user-space computation for determining whether an address lies in >>> the linear map range is the same as we have in kernel-space: >>> >>>    #define __is_lm_address(addr)    (!(((u64)addr) & BIT(vabits_actual - 1))) >> >> This was changed with 14c127c957c1 ("arm64: mm: Flip kernel VA space"). If user-space >> tools rely on 'knowing' the kernel memory layout, they must have to constantly be fixed >> and updated. This is a poor argument for adding this to something that ends up as ABI. > > See above. The user-space has to rely on some ABI/guaranteed hardware-symbols which can be > used for 'determining' the kernel memory layout. I disagree. Everything and anything in the kernel will change. The ABI rules apply to stuff exposed via syscalls and kernel filesystems. It does not apply to kernel internals, like the memory layout we used yesterday. 14c127c957c1 is a case in point. A debugger trying to rely on this sort of thing would have to play catchup whenever it changes. I'm looking for a justification that isn't paper-thin. Putting 'for guessing the memory map' in the commit message gives the impression we can support that. >> I think a better argument is walking the kernel page tables from the core dump. >> Core code's vmcoreinfo exports the location of the kernel page tables, but in the example >> above you can't walk them without knowing how T1SZ was configured. > > Sure, both makedumpfile and crash-utility (which walks the kernel page tables from the > core dump) use this (and similar) information currently in the user-space. [...] >> (From-memory: one of vmcore/kcore is virtually addressed, the other physically. Does this >> fix your poblem in both cases?) >> >> >>> diff --git a/arch/arm64/kernel/crash_core.c b/arch/arm64/kernel/crash_core.c >>> index ca4c3e12d8c5..f78310ba65ea 100644 >>> --- a/arch/arm64/kernel/crash_core.c >>> +++ b/arch/arm64/kernel/crash_core.c >>> @@ -7,6 +7,13 @@ >>>   #include >>>   #include >> >> You need to include asm/sysreg.h for read_sysreg(), and asm/pgtable-hwdef.h for the macros >> you added. > > Ok. Will check as I did not get any compilation errors without the same and build-bot also > did not raise a flag for the missing include files. Don't trust the header jungle! >>> +static inline u64 get_tcr_el1_t1sz(void); > >> Why do you need to do this? > > Without this I was getting a missing declaration error, while compiling the code. Missing declaration? >>> +static inline u64 get_tcr_el1_t1sz(void) >>> +{ >>> +    return (read_sysreg(tcr_el1) & TCR_T1SZ_MASK) >> TCR_T1SZ_OFFSET; >>> +} Here it is! (I must be going mad...) Thanks, James 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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E853AC282DD for ; Fri, 10 Jan 2020 18:41:14 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 692E32072E for ; Fri, 10 Jan 2020 18:41:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 692E32072E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 47vWyv5C4DzDqgx for ; Sat, 11 Jan 2020 05:41:11 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arm.com (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=james.morse@arm.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=arm.com Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lists.ozlabs.org (Postfix) with ESMTP id 47vWwd6DtvzDqgl for ; Sat, 11 Jan 2020 05:39:11 +1100 (AEDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ED92330E; Fri, 10 Jan 2020 10:39:09 -0800 (PST) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E2C323F6C4; Fri, 10 Jan 2020 10:39:06 -0800 (PST) Subject: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo To: Bhupesh Sharma References: <1575057559-25496-1-git-send-email-bhsharma@redhat.com> <1575057559-25496-3-git-send-email-bhsharma@redhat.com> <63d6e63c-7218-d2dd-8767-4464be83603f@arm.com> From: James Morse Message-ID: Date: Fri, 10 Jan 2020 18:39:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit 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: Mark Rutland , Ard Biesheuvel , linux-doc@vger.kernel.org, Will Deacon , x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Kazuhito Hagio , Dave Anderson , Catalin Marinas , bhupesh.linux@gmail.com, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, Steve Capper Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Bhupesh, On 25/12/2019 19:01, Bhupesh Sharma wrote: > On 12/12/2019 04:02 PM, James Morse wrote: >> On 29/11/2019 19:59, Bhupesh Sharma wrote: >>> vabits_actual variable on arm64 indicates the actual VA space size, >>> and allows a single binary to support both 48-bit and 52-bit VA >>> spaces. >>> >>> If the ARMv8.2-LVA optional feature is present, and we are running >>> with a 64KB page size; then it is possible to use 52-bits of address >>> space for both userspace and kernel addresses. However, any kernel >>> binary that supports 52-bit must also be able to fall back to 48-bit >>> at early boot time if the hardware feature is not present. >>> >>> Since TCR_EL1.T1SZ indicates the size offset of the memory region >>> addressed by TTBR1_EL1 (and hence can be used for determining the >>> vabits_actual value) it makes more sense to export the same in >>> vmcoreinfo rather than vabits_actual variable, as the name of the >>> variable can change in future kernel versions, but the architectural >>> constructs like TCR_EL1.T1SZ can be used better to indicate intended >>> specific fields to user-space. >>> >>> User-space utilities like makedumpfile and crash-utility, need to >>> read/write this value from/to vmcoreinfo >> >> (write?) > > Yes, also write so that the vmcoreinfo from an (crashing) arm64 system can be used for > analysis of the root-cause of panic/crash on say an x86_64 host using utilities like > crash-utility/gdb. I read this as as "User-space [...] needs to write to vmcoreinfo". >>> for determining if a virtual address lies in the linear map range. >> >> I think this is a fragile example. The debugger shouldn't need to know this. > > Well that the current user-space utility design, so I am not sure we can tweak that too much. > >>> The user-space computation for determining whether an address lies in >>> the linear map range is the same as we have in kernel-space: >>> >>>    #define __is_lm_address(addr)    (!(((u64)addr) & BIT(vabits_actual - 1))) >> >> This was changed with 14c127c957c1 ("arm64: mm: Flip kernel VA space"). If user-space >> tools rely on 'knowing' the kernel memory layout, they must have to constantly be fixed >> and updated. This is a poor argument for adding this to something that ends up as ABI. > > See above. The user-space has to rely on some ABI/guaranteed hardware-symbols which can be > used for 'determining' the kernel memory layout. I disagree. Everything and anything in the kernel will change. The ABI rules apply to stuff exposed via syscalls and kernel filesystems. It does not apply to kernel internals, like the memory layout we used yesterday. 14c127c957c1 is a case in point. A debugger trying to rely on this sort of thing would have to play catchup whenever it changes. I'm looking for a justification that isn't paper-thin. Putting 'for guessing the memory map' in the commit message gives the impression we can support that. >> I think a better argument is walking the kernel page tables from the core dump. >> Core code's vmcoreinfo exports the location of the kernel page tables, but in the example >> above you can't walk them without knowing how T1SZ was configured. > > Sure, both makedumpfile and crash-utility (which walks the kernel page tables from the > core dump) use this (and similar) information currently in the user-space. [...] >> (From-memory: one of vmcore/kcore is virtually addressed, the other physically. Does this >> fix your poblem in both cases?) >> >> >>> diff --git a/arch/arm64/kernel/crash_core.c b/arch/arm64/kernel/crash_core.c >>> index ca4c3e12d8c5..f78310ba65ea 100644 >>> --- a/arch/arm64/kernel/crash_core.c >>> +++ b/arch/arm64/kernel/crash_core.c >>> @@ -7,6 +7,13 @@ >>>   #include >>>   #include >> >> You need to include asm/sysreg.h for read_sysreg(), and asm/pgtable-hwdef.h for the macros >> you added. > > Ok. Will check as I did not get any compilation errors without the same and build-bot also > did not raise a flag for the missing include files. Don't trust the header jungle! >>> +static inline u64 get_tcr_el1_t1sz(void); > >> Why do you need to do this? > > Without this I was getting a missing declaration error, while compiling the code. Missing declaration? >>> +static inline u64 get_tcr_el1_t1sz(void) >>> +{ >>> +    return (read_sysreg(tcr_el1) & TCR_T1SZ_MASK) >> TCR_T1SZ_OFFSET; >>> +} Here it is! (I must be going mad...) Thanks, James 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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A575AC33CA4 for ; Fri, 10 Jan 2020 18:39:26 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 6E5C62072E for ; Fri, 10 Jan 2020 18:39:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jly6NVFw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E5C62072E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NNmS7YQDx5c+HkTwfdOv2d4esaOa6+e+hdrNNn14TBM=; b=jly6NVFwUbTu/z mLCHMs7DT9u0rDXoCqRrIpJyqcv1/Cd5XZBIV990wLRAXFGsiciOUugKdf3ye+0RS2gGSdBpS64l9 c2irmjBo4uEf1vz0esj755gXe83aRTTUzOyOVTghAv6PN4Rm1ACeMfE0Lq/qsy2pDhowKgDp4YABt W/mFchjAGNhlP8bUDQ+qlXi5aEOYhN34qko3oBKkwxXVRSM5RPGM879kyJjUQQZ3tIJTd7SxrEsH2 /p4EBz8F8e+DQ3dmouoY5yu5k6CtSwF2/pKPWZtztuIeSnGiNGBNajb3CUaYwjyHjUiZM46XRvgAm PHckZqD4bdbyZ7FZXUuw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ipzBq-0003ih-SP; Fri, 10 Jan 2020 18:39:22 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ipzBe-0003Wl-D8; Fri, 10 Jan 2020 18:39:12 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ED92330E; Fri, 10 Jan 2020 10:39:09 -0800 (PST) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E2C323F6C4; Fri, 10 Jan 2020 10:39:06 -0800 (PST) Subject: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo To: Bhupesh Sharma References: <1575057559-25496-1-git-send-email-bhsharma@redhat.com> <1575057559-25496-3-git-send-email-bhsharma@redhat.com> <63d6e63c-7218-d2dd-8767-4464be83603f@arm.com> From: James Morse Message-ID: Date: Fri, 10 Jan 2020 18:39:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200110_103910_552413_1AC5B89A X-CRM114-Status: GOOD ( 23.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Ard Biesheuvel , linux-doc@vger.kernel.org, Will Deacon , x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Kazuhito Hagio , Dave Anderson , Catalin Marinas , bhupesh.linux@gmail.com, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, Steve Capper Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org SGkgQmh1cGVzaCwKCk9uIDI1LzEyLzIwMTkgMTk6MDEsIEJodXBlc2ggU2hhcm1hIHdyb3RlOgo+ IE9uIDEyLzEyLzIwMTkgMDQ6MDIgUE0sIEphbWVzIE1vcnNlIHdyb3RlOgo+PiBPbiAyOS8xMS8y MDE5IDE5OjU5LCBCaHVwZXNoIFNoYXJtYSB3cm90ZToKPj4+IHZhYml0c19hY3R1YWwgdmFyaWFi bGUgb24gYXJtNjQgaW5kaWNhdGVzIHRoZSBhY3R1YWwgVkEgc3BhY2Ugc2l6ZSwKPj4+IGFuZCBh bGxvd3MgYSBzaW5nbGUgYmluYXJ5IHRvIHN1cHBvcnQgYm90aCA0OC1iaXQgYW5kIDUyLWJpdCBW QQo+Pj4gc3BhY2VzLgo+Pj4KPj4+IElmIHRoZSBBUk12OC4yLUxWQSBvcHRpb25hbCBmZWF0dXJl IGlzIHByZXNlbnQsIGFuZCB3ZSBhcmUgcnVubmluZwo+Pj4gd2l0aCBhIDY0S0IgcGFnZSBzaXpl OyB0aGVuIGl0IGlzIHBvc3NpYmxlIHRvIHVzZSA1Mi1iaXRzIG9mIGFkZHJlc3MKPj4+IHNwYWNl IGZvciBib3RoIHVzZXJzcGFjZSBhbmQga2VybmVsIGFkZHJlc3Nlcy4gSG93ZXZlciwgYW55IGtl cm5lbAo+Pj4gYmluYXJ5IHRoYXQgc3VwcG9ydHMgNTItYml0IG11c3QgYWxzbyBiZSBhYmxlIHRv IGZhbGwgYmFjayB0byA0OC1iaXQKPj4+IGF0IGVhcmx5IGJvb3QgdGltZSBpZiB0aGUgaGFyZHdh cmUgZmVhdHVyZSBpcyBub3QgcHJlc2VudC4KPj4+Cj4+PiBTaW5jZSBUQ1JfRUwxLlQxU1ogaW5k aWNhdGVzIHRoZSBzaXplIG9mZnNldCBvZiB0aGUgbWVtb3J5IHJlZ2lvbgo+Pj4gYWRkcmVzc2Vk IGJ5IFRUQlIxX0VMMSAoYW5kIGhlbmNlIGNhbiBiZSB1c2VkIGZvciBkZXRlcm1pbmluZyB0aGUK Pj4+IHZhYml0c19hY3R1YWwgdmFsdWUpIGl0IG1ha2VzIG1vcmUgc2Vuc2UgdG8gZXhwb3J0IHRo ZSBzYW1lIGluCj4+PiB2bWNvcmVpbmZvIHJhdGhlciB0aGFuIHZhYml0c19hY3R1YWwgdmFyaWFi bGUsIGFzIHRoZSBuYW1lIG9mIHRoZQo+Pj4gdmFyaWFibGUgY2FuIGNoYW5nZSBpbiBmdXR1cmUg a2VybmVsIHZlcnNpb25zLCBidXQgdGhlIGFyY2hpdGVjdHVyYWwKPj4+IGNvbnN0cnVjdHMgbGlr ZSBUQ1JfRUwxLlQxU1ogY2FuIGJlIHVzZWQgYmV0dGVyIHRvIGluZGljYXRlIGludGVuZGVkCj4+ PiBzcGVjaWZpYyBmaWVsZHMgdG8gdXNlci1zcGFjZS4KPj4+Cj4+PiBVc2VyLXNwYWNlIHV0aWxp dGllcyBsaWtlIG1ha2VkdW1wZmlsZSBhbmQgY3Jhc2gtdXRpbGl0eSwgbmVlZCB0bwo+Pj4gcmVh ZC93cml0ZSB0aGlzIHZhbHVlIGZyb20vdG8gdm1jb3JlaW5mbwo+Pgo+PiAod3JpdGU/KQo+IAo+ IFllcywgYWxzbyB3cml0ZSBzbyB0aGF0IHRoZSB2bWNvcmVpbmZvIGZyb20gYW4gKGNyYXNoaW5n KSBhcm02NCBzeXN0ZW0gY2FuIGJlIHVzZWQgZm9yCj4gYW5hbHlzaXMgb2YgdGhlIHJvb3QtY2F1 c2Ugb2YgcGFuaWMvY3Jhc2ggb24gc2F5IGFuIHg4Nl82NCBob3N0IHVzaW5nIHV0aWxpdGllcyBs aWtlCj4gY3Jhc2gtdXRpbGl0eS9nZGIuCgpJIHJlYWQgdGhpcyBhcyBhcyAiVXNlci1zcGFjZSBb Li4uXSBuZWVkcyB0byB3cml0ZSB0byB2bWNvcmVpbmZvIi4KCgo+Pj4gZm9yIGRldGVybWluaW5n IGlmIGEgdmlydHVhbCBhZGRyZXNzIGxpZXMgaW4gdGhlIGxpbmVhciBtYXAgcmFuZ2UuCj4+Cj4+ IEkgdGhpbmsgdGhpcyBpcyBhIGZyYWdpbGUgZXhhbXBsZS4gVGhlIGRlYnVnZ2VyIHNob3VsZG4n dCBuZWVkIHRvIGtub3cgdGhpcy4KPiAKPiBXZWxsIHRoYXQgdGhlIGN1cnJlbnQgdXNlci1zcGFj ZSB1dGlsaXR5IGRlc2lnbiwgc28gSSBhbSBub3Qgc3VyZSB3ZSBjYW4gdHdlYWsgdGhhdCB0b28g bXVjaC4KPiAKPj4+IFRoZSB1c2VyLXNwYWNlIGNvbXB1dGF0aW9uIGZvciBkZXRlcm1pbmluZyB3 aGV0aGVyIGFuIGFkZHJlc3MgbGllcyBpbgo+Pj4gdGhlIGxpbmVhciBtYXAgcmFuZ2UgaXMgdGhl IHNhbWUgYXMgd2UgaGF2ZSBpbiBrZXJuZWwtc3BhY2U6Cj4+Pgo+Pj4gwqDCoCAjZGVmaW5lIF9f aXNfbG1fYWRkcmVzcyhhZGRyKcKgwqDCoCAoISgoKHU2NClhZGRyKSAmIEJJVCh2YWJpdHNfYWN0 dWFsIC0gMSkpKQo+Pgo+PiBUaGlzIHdhcyBjaGFuZ2VkIHdpdGggMTRjMTI3Yzk1N2MxICgiYXJt NjQ6IG1tOiBGbGlwIGtlcm5lbCBWQSBzcGFjZSIpLiBJZiB1c2VyLXNwYWNlCj4+IHRvb2xzIHJl bHkgb24gJ2tub3dpbmcnIHRoZSBrZXJuZWwgbWVtb3J5IGxheW91dCwgdGhleSBtdXN0IGhhdmUg dG8gY29uc3RhbnRseSBiZSBmaXhlZAo+PiBhbmQgdXBkYXRlZC4gVGhpcyBpcyBhIHBvb3IgYXJn dW1lbnQgZm9yIGFkZGluZyB0aGlzIHRvIHNvbWV0aGluZyB0aGF0IGVuZHMgdXAgYXMgQUJJLgo+ IAo+IFNlZSBhYm92ZS4gVGhlIHVzZXItc3BhY2UgaGFzIHRvIHJlbHkgb24gc29tZSBBQkkvZ3Vh cmFudGVlZCBoYXJkd2FyZS1zeW1ib2xzIHdoaWNoIGNhbiBiZQo+IHVzZWQgZm9yICdkZXRlcm1p bmluZycgdGhlIGtlcm5lbCBtZW1vcnkgbGF5b3V0LgoKSSBkaXNhZ3JlZS4gRXZlcnl0aGluZyBh bmQgYW55dGhpbmcgaW4gdGhlIGtlcm5lbCB3aWxsIGNoYW5nZS4gVGhlIEFCSSBydWxlcyBhcHBs eSB0bwpzdHVmZiBleHBvc2VkIHZpYSBzeXNjYWxscyBhbmQga2VybmVsIGZpbGVzeXN0ZW1zLiBJ dCBkb2VzIG5vdCBhcHBseSB0byBrZXJuZWwgaW50ZXJuYWxzLApsaWtlIHRoZSBtZW1vcnkgbGF5 b3V0IHdlIHVzZWQgeWVzdGVyZGF5LiAxNGMxMjdjOTU3YzEgaXMgYSBjYXNlIGluIHBvaW50LgoK QSBkZWJ1Z2dlciB0cnlpbmcgdG8gcmVseSBvbiB0aGlzIHNvcnQgb2YgdGhpbmcgd291bGQgaGF2 ZSB0byBwbGF5IGNhdGNodXAgd2hlbmV2ZXIgaXQKY2hhbmdlcy4KCkknbSBsb29raW5nIGZvciBh IGp1c3RpZmljYXRpb24gdGhhdCBpc24ndCBwYXBlci10aGluLiBQdXR0aW5nICdmb3IgZ3Vlc3Np bmcgdGhlIG1lbW9yeQptYXAnIGluIHRoZSBjb21taXQgbWVzc2FnZSBnaXZlcyB0aGUgaW1wcmVz c2lvbiB3ZSBjYW4gc3VwcG9ydCB0aGF0LgoKCj4+IEkgdGhpbmsgYSBiZXR0ZXIgYXJndW1lbnQg aXMgd2Fsa2luZyB0aGUga2VybmVsIHBhZ2UgdGFibGVzIGZyb20gdGhlIGNvcmUgZHVtcC4KPj4g Q29yZSBjb2RlJ3Mgdm1jb3JlaW5mbyBleHBvcnRzIHRoZSBsb2NhdGlvbiBvZiB0aGUga2VybmVs IHBhZ2UgdGFibGVzLCBidXQgaW4gdGhlIGV4YW1wbGUKPj4gYWJvdmUgeW91IGNhbid0IHdhbGsg dGhlbSB3aXRob3V0IGtub3dpbmcgaG93IFQxU1ogd2FzIGNvbmZpZ3VyZWQuCj4gCj4gU3VyZSwg Ym90aCBtYWtlZHVtcGZpbGUgYW5kIGNyYXNoLXV0aWxpdHkgKHdoaWNoIHdhbGtzIHRoZSBrZXJu ZWwgcGFnZSB0YWJsZXMgZnJvbSB0aGUKPiBjb3JlIGR1bXApIHVzZSB0aGlzIChhbmQgc2ltaWxh cikgaW5mb3JtYXRpb24gY3VycmVudGx5IGluIHRoZSB1c2VyLXNwYWNlLgoKWy4uLl0KCj4+IChG cm9tLW1lbW9yeTogb25lIG9mIHZtY29yZS9rY29yZSBpcyB2aXJ0dWFsbHkgYWRkcmVzc2VkLCB0 aGUgb3RoZXIgcGh5c2ljYWxseS4gRG9lcyB0aGlzCj4+IGZpeCB5b3VyIHBvYmxlbSBpbiBib3Ro IGNhc2VzPykKPj4KPj4KPj4+IGRpZmYgLS1naXQgYS9hcmNoL2FybTY0L2tlcm5lbC9jcmFzaF9j b3JlLmMgYi9hcmNoL2FybTY0L2tlcm5lbC9jcmFzaF9jb3JlLmMKPj4+IGluZGV4IGNhNGMzZTEy ZDhjNS4uZjc4MzEwYmE2NWVhIDEwMDY0NAo+Pj4gLS0tIGEvYXJjaC9hcm02NC9rZXJuZWwvY3Jh c2hfY29yZS5jCj4+PiArKysgYi9hcmNoL2FybTY0L2tlcm5lbC9jcmFzaF9jb3JlLmMKPj4+IEBA IC03LDYgKzcsMTMgQEAKPj4+IMKgICNpbmNsdWRlIDxsaW51eC9jcmFzaF9jb3JlLmg+Cj4+PiDC oCAjaW5jbHVkZSA8YXNtL21lbW9yeS5oPgo+Pgo+PiBZb3UgbmVlZCB0byBpbmNsdWRlIGFzbS9z eXNyZWcuaCBmb3IgcmVhZF9zeXNyZWcoKSwgYW5kIGFzbS9wZ3RhYmxlLWh3ZGVmLmggZm9yIHRo ZSBtYWNyb3MKPj4geW91IGFkZGVkLgo+IAo+IE9rLiBXaWxsIGNoZWNrIGFzIEkgZGlkIG5vdCBn ZXQgYW55IGNvbXBpbGF0aW9uIGVycm9ycyB3aXRob3V0IHRoZSBzYW1lIGFuZCBidWlsZC1ib3Qg YWxzbwo+IGRpZCBub3QgcmFpc2UgYSBmbGFnIGZvciB0aGUgbWlzc2luZyBpbmNsdWRlIGZpbGVz LgoKRG9uJ3QgdHJ1c3QgdGhlIGhlYWRlciBqdW5nbGUhCgoKPj4+ICtzdGF0aWMgaW5saW5lIHU2 NCBnZXRfdGNyX2VsMV90MXN6KHZvaWQpOwo+IAo+PiBXaHkgZG8geW91IG5lZWQgdG8gZG8gdGhp cz8KPiAKPiBXaXRob3V0IHRoaXMgSSB3YXMgZ2V0dGluZyBhIG1pc3NpbmcgZGVjbGFyYXRpb24g ZXJyb3IsIHdoaWxlIGNvbXBpbGluZyB0aGUgY29kZS4KCk1pc3NpbmcgZGVjbGFyYXRpb24/Cgo+ Pj4gK3N0YXRpYyBpbmxpbmUgdTY0IGdldF90Y3JfZWwxX3Qxc3oodm9pZCkKPj4+ICt7Cj4+PiAr wqDCoMKgIHJldHVybiAocmVhZF9zeXNyZWcodGNyX2VsMSkgJiBUQ1JfVDFTWl9NQVNLKSA+PiBU Q1JfVDFTWl9PRkZTRVQ7Cj4+PiArfQoKSGVyZSBpdCBpcyEgKEkgbXVzdCBiZSBnb2luZyBtYWQu Li4pCgoKVGhhbmtzLAoKSmFtZXMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJu ZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK