From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerald Schaefer Date: Mon, 09 Sep 2019 16:51:21 +0000 Subject: Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers Message-Id: <20190909185121.6271e9be@thinkpad> List-Id: References: <1567497706-8649-1-git-send-email-anshuman.khandual@arm.com> <1567497706-8649-2-git-send-email-anshuman.khandual@arm.com> <20190904221618.1b624a98@thinkpad> <20e3044d-2af5-b27b-7653-cec53bdec941@arm.com> <20190905190629.523bdb87@thinkpad> <3c609e33-afbb-ffaf-481a-6d225a06d1d0@arm.com> <20190906210346.5ecbff01@thinkpad> <3d5de35f-8192-1c75-50a9-03e66e3b8e5c@arm.com> In-Reply-To: <3d5de35f-8192-1c75-50a9-03e66e3b8e5c@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Anshuman Khandual Cc: Mark Rutland , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , James Hogan , Tetsuo Handa , Heiko Carstens , Michal Hocko , linux-mm@kvack.org, Dave Hansen , Paul Mackerras , sparclinux@vger.kernel.org, Thomas Gleixner , linux-s390@vger.kernel.org, Michael Ellerman , x86@kernel.org, Russell King - ARM Linux , Matthew Wilcox , Steven Price , Jason Gunthorpe , linux-arm-kernel@lists.infradead.org, linux-snps-arc@lists.infradead.org, Kees Cook , Masahiro Yamada , Mark Brown , Dan Williams , Vlastimil Babka , Sri Krishna chowdary , Ard Biesheuvel , Greg Kroah-Hartman , linux-mips@vger.kernel.org, Ralf Baechle , linux-kernel@vger.kernel.org, Paul Burton , Mike Rapoport , Vineet Gupta , Martin Schwidefsky , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" On Mon, 9 Sep 2019 11:56:50 +0530 Anshuman Khandual wrote: [..] > > > > Hmm, I simply used this on my system to make pud_clear_tests() work, not > > sure if it works on all archs: > > > > pud_val(*pudp) |= RANDOM_NZVALUE; > > Which compiles on arm64 but then fails on x86 because of the way pmd_val() > has been defined there. on arm64 and s390 (with many others) pmd_val() is > a macro which still got the variable that can be used as lvalue but that is > not true for some other platforms like x86. > > arch/arm64/include/asm/pgtable-types.h: #define pmd_val(x) ((x).pmd) > arch/s390/include/asm/page.h: #define pmd_val(x) ((x).pmd) > arch/x86/include/asm/pgtable.h: #define pmd_val(x) native_pmd_val(x) > > static inline pmdval_t native_pmd_val(pmd_t pmd) > { > return pmd.pmd; > } > > Unless I am mistaken, the return value from this function can not be used as > lvalue for future assignments. > > mm/arch_pgtable_test.c: In function ‘pud_clear_tests’: > mm/arch_pgtable_test.c:156:17: error: lvalue required as left operand of assignment > pud_val(*pudp) |= RANDOM_ORVALUE; > ^~ > AFAICS pxx_val() were never intended to be used as lvalue and using it that way > might just happen to work on all those platforms which define them as macros. > They meant to just provide values for an entry as being determined by the platform. > > In principle pxx_val() on an entry was not supposed to be modified directly from > generic code without going through (again) platform helpers for any specific state > change (write, old, dirty, special, huge etc). The current use case is a deviation > for that. > > I originally went with memset() just to load up the entries with non-zero value so > that we know pxx_clear() are really doing the clearing. The same is being followed > for all pxx_same() checks. > > Another way for fixing the problem would be to mark them with known attributes > like write/young/huge etc instead which for sure will create non-zero entries. > We can do that for pxx_clear() and pxx_same() tests and drop RANDOM_NZVALUE > completely. Does that sound good ? Umm, not really. Those mkwrite/young/huge etc. helpers do only exist for page table levels where we can also have large mappings, at least on s390. Also, we do (on s390) again check for certain sanity before actually setting the bits. Good news is that at least for the pxx_same() checks the memset() is no problem, because pxx_same() does not do any checks other than the same check. For the pxx_clear_tests(), maybe it could be an option to put them behind the pxx_populate_tests(), and rely on them having properly populated (non-clear) values after that? [...] > > > > Actually, using get_unmapped_area() as suggested by Kirill could also > > solve this issue. We do create a new mm with 3-level page tables on s390, > > and the dynamic upgrade to 4 or 5 levels is then triggered exactly by > > arch_get_unmapped_area(), depending on the addr. But I currently don't > > see how / where arch_get_unmapped_area() is set up for such a dummy mm > > created by mm_alloc(). > > Normally they are set during program loading but we can set it up explicitly > for the test mm_struct if we need to but there are some other challenges. > > load_[aout|elf|flat|..]_binary() > setup_new_exec() > arch_pick_mmap_layout(). > > I did some initial experiments around get_unmapped_area(). Seems bit tricky > to get it working on a pure 'test' mm_struct. It expects a real user context > in the form of current->mm. Yes, that's where I stopped because it looked rather complicated :-) Not sure why Kirill suggested it initially, but if using get_unmapped_area() would only be necessary to get properly initialized page table levels on s390, you could also defer this to a later add-on patch. Regards, Gerald 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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no 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 D33C1C49ED6 for ; Mon, 9 Sep 2019 16:51:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AA50820828 for ; Mon, 9 Sep 2019 16:51:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387950AbfIIQvk convert rfc822-to-8bit (ORCPT ); Mon, 9 Sep 2019 12:51:40 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:11572 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727006AbfIIQvj (ORCPT ); Mon, 9 Sep 2019 12:51:39 -0400 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x89Gl8QE075060 for ; Mon, 9 Sep 2019 12:51:38 -0400 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2uwtehrj1s-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 09 Sep 2019 12:51:37 -0400 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 9 Sep 2019 17:51:35 +0100 Received: from b06avi18626390.portsmouth.uk.ibm.com (9.149.26.192) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 9 Sep 2019 17:51:24 +0100 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x89GoxbI41157048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Sep 2019 16:50:59 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 85A0311C050; Mon, 9 Sep 2019 16:51:23 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 387CA11C04C; Mon, 9 Sep 2019 16:51:22 +0000 (GMT) Received: from thinkpad (unknown [9.152.212.222]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 9 Sep 2019 16:51:22 +0000 (GMT) Date: Mon, 9 Sep 2019 18:51:21 +0200 From: Gerald Schaefer To: Anshuman Khandual Cc: linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Greg Kroah-Hartman , Thomas Gleixner , Mike Rapoport , Jason Gunthorpe , Dan Williams , Peter Zijlstra , Michal Hocko , Mark Rutland , Mark Brown , Steven Price , Ard Biesheuvel , Masahiro Yamada , Kees Cook , Tetsuo Handa , Matthew Wilcox , Sri Krishna chowdary , Dave Hansen , Russell King - ARM Linux , Michael Ellerman , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , "David S. Miller" , Vineet Gupta , James Hogan , Paul Burton , Ralf Baechle , linux-snps-arc@lists.infradead.org, linux-mips@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers In-Reply-To: <3d5de35f-8192-1c75-50a9-03e66e3b8e5c@arm.com> References: <1567497706-8649-1-git-send-email-anshuman.khandual@arm.com> <1567497706-8649-2-git-send-email-anshuman.khandual@arm.com> <20190904221618.1b624a98@thinkpad> <20e3044d-2af5-b27b-7653-cec53bdec941@arm.com> <20190905190629.523bdb87@thinkpad> <3c609e33-afbb-ffaf-481a-6d225a06d1d0@arm.com> <20190906210346.5ecbff01@thinkpad> <3d5de35f-8192-1c75-50a9-03e66e3b8e5c@arm.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-TM-AS-GCONF: 00 x-cbid: 19090916-0020-0000-0000-00000369E0CB X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19090916-0021-0000-0000-000021BF62C6 Message-Id: <20190909185121.6271e9be@thinkpad> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-09_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909090170 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 9 Sep 2019 11:56:50 +0530 Anshuman Khandual wrote: [..] > > > > Hmm, I simply used this on my system to make pud_clear_tests() work, not > > sure if it works on all archs: > > > > pud_val(*pudp) |= RANDOM_NZVALUE; > > Which compiles on arm64 but then fails on x86 because of the way pmd_val() > has been defined there. on arm64 and s390 (with many others) pmd_val() is > a macro which still got the variable that can be used as lvalue but that is > not true for some other platforms like x86. > > arch/arm64/include/asm/pgtable-types.h: #define pmd_val(x) ((x).pmd) > arch/s390/include/asm/page.h: #define pmd_val(x) ((x).pmd) > arch/x86/include/asm/pgtable.h: #define pmd_val(x) native_pmd_val(x) > > static inline pmdval_t native_pmd_val(pmd_t pmd) > { > return pmd.pmd; > } > > Unless I am mistaken, the return value from this function can not be used as > lvalue for future assignments. > > mm/arch_pgtable_test.c: In function ‘pud_clear_tests’: > mm/arch_pgtable_test.c:156:17: error: lvalue required as left operand of assignment > pud_val(*pudp) |= RANDOM_ORVALUE; > ^~ > AFAICS pxx_val() were never intended to be used as lvalue and using it that way > might just happen to work on all those platforms which define them as macros. > They meant to just provide values for an entry as being determined by the platform. > > In principle pxx_val() on an entry was not supposed to be modified directly from > generic code without going through (again) platform helpers for any specific state > change (write, old, dirty, special, huge etc). The current use case is a deviation > for that. > > I originally went with memset() just to load up the entries with non-zero value so > that we know pxx_clear() are really doing the clearing. The same is being followed > for all pxx_same() checks. > > Another way for fixing the problem would be to mark them with known attributes > like write/young/huge etc instead which for sure will create non-zero entries. > We can do that for pxx_clear() and pxx_same() tests and drop RANDOM_NZVALUE > completely. Does that sound good ? Umm, not really. Those mkwrite/young/huge etc. helpers do only exist for page table levels where we can also have large mappings, at least on s390. Also, we do (on s390) again check for certain sanity before actually setting the bits. Good news is that at least for the pxx_same() checks the memset() is no problem, because pxx_same() does not do any checks other than the same check. For the pxx_clear_tests(), maybe it could be an option to put them behind the pxx_populate_tests(), and rely on them having properly populated (non-clear) values after that? [...] > > > > Actually, using get_unmapped_area() as suggested by Kirill could also > > solve this issue. We do create a new mm with 3-level page tables on s390, > > and the dynamic upgrade to 4 or 5 levels is then triggered exactly by > > arch_get_unmapped_area(), depending on the addr. But I currently don't > > see how / where arch_get_unmapped_area() is set up for such a dummy mm > > created by mm_alloc(). > > Normally they are set during program loading but we can set it up explicitly > for the test mm_struct if we need to but there are some other challenges. > > load_[aout|elf|flat|..]_binary() > setup_new_exec() > arch_pick_mmap_layout(). > > I did some initial experiments around get_unmapped_area(). Seems bit tricky > to get it working on a pure 'test' mm_struct. It expects a real user context > in the form of current->mm. Yes, that's where I stopped because it looked rather complicated :-) Not sure why Kirill suggested it initially, but if using get_unmapped_area() would only be necessary to get properly initialized page table levels on s390, you could also defer this to a later add-on patch. Regards, Gerald 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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no 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 E6532C4740C for ; Mon, 9 Sep 2019 16:53:29 +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 35F3221479 for ; Mon, 9 Sep 2019 16:53:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 35F3221479 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=de.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46RvPL5mjpzDqP5 for ; Tue, 10 Sep 2019 02:53:26 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=de.ibm.com (client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com; envelope-from=gerald.schaefer@de.ibm.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=de.ibm.com Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 46RvMM1fLGzDqLb for ; Tue, 10 Sep 2019 02:51:42 +1000 (AEST) Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x89GkpFw089836 for ; Mon, 9 Sep 2019 12:51:38 -0400 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2uwteh0jbe-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 09 Sep 2019 12:51:38 -0400 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 9 Sep 2019 17:51:35 +0100 Received: from b06avi18626390.portsmouth.uk.ibm.com (9.149.26.192) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 9 Sep 2019 17:51:24 +0100 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x89GoxbI41157048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Sep 2019 16:50:59 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 85A0311C050; Mon, 9 Sep 2019 16:51:23 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 387CA11C04C; Mon, 9 Sep 2019 16:51:22 +0000 (GMT) Received: from thinkpad (unknown [9.152.212.222]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 9 Sep 2019 16:51:22 +0000 (GMT) Date: Mon, 9 Sep 2019 18:51:21 +0200 From: Gerald Schaefer To: Anshuman Khandual Subject: Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers In-Reply-To: <3d5de35f-8192-1c75-50a9-03e66e3b8e5c@arm.com> References: <1567497706-8649-1-git-send-email-anshuman.khandual@arm.com> <1567497706-8649-2-git-send-email-anshuman.khandual@arm.com> <20190904221618.1b624a98@thinkpad> <20e3044d-2af5-b27b-7653-cec53bdec941@arm.com> <20190905190629.523bdb87@thinkpad> <3c609e33-afbb-ffaf-481a-6d225a06d1d0@arm.com> <20190906210346.5ecbff01@thinkpad> <3d5de35f-8192-1c75-50a9-03e66e3b8e5c@arm.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 x-cbid: 19090916-0020-0000-0000-00000369E0CB X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19090916-0021-0000-0000-000021BF62C6 Message-Id: <20190909185121.6271e9be@thinkpad> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909090170 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 , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , James Hogan , Tetsuo Handa , Heiko Carstens , Michal Hocko , linux-mm@kvack.org, Dave Hansen , Paul Mackerras , sparclinux@vger.kernel.org, Thomas Gleixner , linux-s390@vger.kernel.org, x86@kernel.org, Russell King - ARM Linux , Matthew Wilcox , Steven Price , Jason Gunthorpe , linux-arm-kernel@lists.infradead.org, linux-snps-arc@lists.infradead.org, Kees Cook , Masahiro Yamada , Mark Brown , Dan Williams , Vlastimil Babka , Sri Krishna chowdary , Ard Biesheuvel , Greg Kroah-Hartman , linux-mips@vger.kernel.org, Ralf Baechle , linux-kernel@vger.kernel.org, Paul Burton , Mike Rapoport , Vineet Gupta , Martin Schwidefsky , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, 9 Sep 2019 11:56:50 +0530 Anshuman Khandual wrote: [..] > >=20 > > Hmm, I simply used this on my system to make pud_clear_tests() work, not > > sure if it works on all archs: > >=20 > > pud_val(*pudp) |=3D RANDOM_NZVALUE; =20 >=20 > Which compiles on arm64 but then fails on x86 because of the way pmd_val() > has been defined there. on arm64 and s390 (with many others) pmd_val() is > a macro which still got the variable that can be used as lvalue but that = is > not true for some other platforms like x86. >=20 > arch/arm64/include/asm/pgtable-types.h: #define pmd_val(x) ((x).pmd) > arch/s390/include/asm/page.h: #define pmd_val(x) ((x).pmd) > arch/x86/include/asm/pgtable.h: #define pmd_val(x) native_pmd_val(= x) >=20 > static inline pmdval_t native_pmd_val(pmd_t pmd) > { > return pmd.pmd; > } >=20 > Unless I am mistaken, the return value from this function can not be used= as > lvalue for future assignments. >=20 > mm/arch_pgtable_test.c: In function =E2=80=98pud_clear_tests=E2=80=99: > mm/arch_pgtable_test.c:156:17: error: lvalue required as left operand of = assignment > pud_val(*pudp) |=3D RANDOM_ORVALUE; > ^~ > AFAICS pxx_val() were never intended to be used as lvalue and using it th= at way > might just happen to work on all those platforms which define them as mac= ros. > They meant to just provide values for an entry as being determined by the= platform. >=20 > In principle pxx_val() on an entry was not supposed to be modified direct= ly from > generic code without going through (again) platform helpers for any speci= fic state > change (write, old, dirty, special, huge etc). The current use case is a = deviation > for that. >=20 > I originally went with memset() just to load up the entries with non-zero= value so > that we know pxx_clear() are really doing the clearing. The same is being= followed > for all pxx_same() checks. >=20 > Another way for fixing the problem would be to mark them with known attri= butes > like write/young/huge etc instead which for sure will create non-zero ent= ries. > We can do that for pxx_clear() and pxx_same() tests and drop RANDOM_NZVAL= UE > completely. Does that sound good ? Umm, not really. Those mkwrite/young/huge etc. helpers do only exist for page table levels where we can also have large mappings, at least on s390. Also, we do (on s390) again check for certain sanity before actually setting the bits. Good news is that at least for the pxx_same() checks the memset() is no problem, because pxx_same() does not do any checks other than the same chec= k. For the pxx_clear_tests(), maybe it could be an option to put them behind t= he pxx_populate_tests(), and rely on them having properly populated (non-clear) values after that? [...] > >=20 > > Actually, using get_unmapped_area() as suggested by Kirill could also > > solve this issue. We do create a new mm with 3-level page tables on s39= 0, > > and the dynamic upgrade to 4 or 5 levels is then triggered exactly by > > arch_get_unmapped_area(), depending on the addr. But I currently don't > > see how / where arch_get_unmapped_area() is set up for such a dummy mm > > created by mm_alloc(). =20 >=20 > Normally they are set during program loading but we can set it up explici= tly > for the test mm_struct if we need to but there are some other challenges. >=20 > load_[aout|elf|flat|..]_binary() > setup_new_exec() > arch_pick_mmap_layout(). >=20 > I did some initial experiments around get_unmapped_area(). Seems bit tric= ky > to get it working on a pure 'test' mm_struct. It expects a real user cont= ext > in the form of current->mm. Yes, that's where I stopped because it looked rather complicated :-) Not sure why Kirill suggested it initially, but if using get_unmapped_area() would only be necessary to get properly initialized page table levels on s390, you could also defer this to a later add-on patch. Regards, Gerald From mboxrd@z Thu Jan 1 00:00:00 1970 From: gerald.schaefer@de.ibm.com (Gerald Schaefer) Date: Mon, 9 Sep 2019 18:51:21 +0200 Subject: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers In-Reply-To: <3d5de35f-8192-1c75-50a9-03e66e3b8e5c@arm.com> References: <1567497706-8649-1-git-send-email-anshuman.khandual@arm.com> <1567497706-8649-2-git-send-email-anshuman.khandual@arm.com> <20190904221618.1b624a98@thinkpad> <20e3044d-2af5-b27b-7653-cec53bdec941@arm.com> <20190905190629.523bdb87@thinkpad> <3c609e33-afbb-ffaf-481a-6d225a06d1d0@arm.com> <20190906210346.5ecbff01@thinkpad> <3d5de35f-8192-1c75-50a9-03e66e3b8e5c@arm.com> List-ID: Message-ID: <20190909185121.6271e9be@thinkpad> To: linux-snps-arc@lists.infradead.org On Mon, 9 Sep 2019 11:56:50 +0530 Anshuman Khandual wrote: [..] > > > > Hmm, I simply used this on my system to make pud_clear_tests() work, not > > sure if it works on all archs: > > > > pud_val(*pudp) |= RANDOM_NZVALUE; > > Which compiles on arm64 but then fails on x86 because of the way pmd_val() > has been defined there. on arm64 and s390 (with many others) pmd_val() is > a macro which still got the variable that can be used as lvalue but that is > not true for some other platforms like x86. > > arch/arm64/include/asm/pgtable-types.h: #define pmd_val(x) ((x).pmd) > arch/s390/include/asm/page.h: #define pmd_val(x) ((x).pmd) > arch/x86/include/asm/pgtable.h: #define pmd_val(x) native_pmd_val(x) > > static inline pmdval_t native_pmd_val(pmd_t pmd) > { > return pmd.pmd; > } > > Unless I am mistaken, the return value from this function can not be used as > lvalue for future assignments. > > mm/arch_pgtable_test.c: In function ?pud_clear_tests?: > mm/arch_pgtable_test.c:156:17: error: lvalue required as left operand of assignment > pud_val(*pudp) |= RANDOM_ORVALUE; > ^~ > AFAICS pxx_val() were never intended to be used as lvalue and using it that way > might just happen to work on all those platforms which define them as macros. > They meant to just provide values for an entry as being determined by the platform. > > In principle pxx_val() on an entry was not supposed to be modified directly from > generic code without going through (again) platform helpers for any specific state > change (write, old, dirty, special, huge etc). The current use case is a deviation > for that. > > I originally went with memset() just to load up the entries with non-zero value so > that we know pxx_clear() are really doing the clearing. The same is being followed > for all pxx_same() checks. > > Another way for fixing the problem would be to mark them with known attributes > like write/young/huge etc instead which for sure will create non-zero entries. > We can do that for pxx_clear() and pxx_same() tests and drop RANDOM_NZVALUE > completely. Does that sound good ? Umm, not really. Those mkwrite/young/huge etc. helpers do only exist for page table levels where we can also have large mappings, at least on s390. Also, we do (on s390) again check for certain sanity before actually setting the bits. Good news is that at least for the pxx_same() checks the memset() is no problem, because pxx_same() does not do any checks other than the same check. For the pxx_clear_tests(), maybe it could be an option to put them behind the pxx_populate_tests(), and rely on them having properly populated (non-clear) values after that? [...] > > > > Actually, using get_unmapped_area() as suggested by Kirill could also > > solve this issue. We do create a new mm with 3-level page tables on s390, > > and the dynamic upgrade to 4 or 5 levels is then triggered exactly by > > arch_get_unmapped_area(), depending on the addr. But I currently don't > > see how / where arch_get_unmapped_area() is set up for such a dummy mm > > created by mm_alloc(). > > Normally they are set during program loading but we can set it up explicitly > for the test mm_struct if we need to but there are some other challenges. > > load_[aout|elf|flat|..]_binary() > setup_new_exec() > arch_pick_mmap_layout(). > > I did some initial experiments around get_unmapped_area(). Seems bit tricky > to get it working on a pure 'test' mm_struct. It expects a real user context > in the form of current->mm. Yes, that's where I stopped because it looked rather complicated :-) Not sure why Kirill suggested it initially, but if using get_unmapped_area() would only be necessary to get properly initialized page table levels on s390, you could also defer this to a later add-on patch. Regards, Gerald 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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no 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 49726C4740C for ; Mon, 9 Sep 2019 16:51:50 +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 1C84020828 for ; Mon, 9 Sep 2019 16:51:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="dIR7XWMN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C84020828 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=de.ibm.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:Message-Id:MIME-Version:References: In-Reply-To:Subject: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=fcS6X7xNVb3o/cigMSlVuA3dbBBpi1EJJdICzlB0NmQ=; b=dIR7XWMN1U889n r/uyvamIBOiSLKfbtk0CXAl8FyUbbfocDE/rNeS7YOQ9EjkPrArn0Bg4xPyXm2CWzDoSJBO1D4z1e 09nGrxx/QIigyBHNDIiZ3xLI20tTXI1UFSElGRWmTC4dZCROPNSCksU/OdDOfls+ZHY8ecDRvhvLl MwHyuDuSSedFB73ih3/X47OfwZVDup6CokVjqlJF7K/g9t0SLQ+gSKcJDX0nVG3HfNlq6uCh3iRog Mdrj3isHB9+SI4ESgtWCzafd/m2s7RpQY5Ek35ZReKbmDEdTGS788spogvMM2DyCUn8NY1P/3eqM0 crzsMHfo6FP3HMOoR2uQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i7MtE-00057u-0Q; Mon, 09 Sep 2019 16:51:44 +0000 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5] helo=mx0a-001b2d01.pphosted.com) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i7MtA-00056v-Eq for linux-arm-kernel@lists.infradead.org; Mon, 09 Sep 2019 16:51:42 +0000 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x89GkILt112470 for ; Mon, 9 Sep 2019 12:51:37 -0400 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0b-001b2d01.pphosted.com with ESMTP id 2uwrrpnj1v-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 09 Sep 2019 12:51:37 -0400 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 9 Sep 2019 17:51:35 +0100 Received: from b06avi18626390.portsmouth.uk.ibm.com (9.149.26.192) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 9 Sep 2019 17:51:24 +0100 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x89GoxbI41157048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Sep 2019 16:50:59 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 85A0311C050; Mon, 9 Sep 2019 16:51:23 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 387CA11C04C; Mon, 9 Sep 2019 16:51:22 +0000 (GMT) Received: from thinkpad (unknown [9.152.212.222]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 9 Sep 2019 16:51:22 +0000 (GMT) Date: Mon, 9 Sep 2019 18:51:21 +0200 From: Gerald Schaefer To: Anshuman Khandual Subject: Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers In-Reply-To: <3d5de35f-8192-1c75-50a9-03e66e3b8e5c@arm.com> References: <1567497706-8649-1-git-send-email-anshuman.khandual@arm.com> <1567497706-8649-2-git-send-email-anshuman.khandual@arm.com> <20190904221618.1b624a98@thinkpad> <20e3044d-2af5-b27b-7653-cec53bdec941@arm.com> <20190905190629.523bdb87@thinkpad> <3c609e33-afbb-ffaf-481a-6d225a06d1d0@arm.com> <20190906210346.5ecbff01@thinkpad> <3d5de35f-8192-1c75-50a9-03e66e3b8e5c@arm.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-TM-AS-GCONF: 00 x-cbid: 19090916-0020-0000-0000-00000369E0CB X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19090916-0021-0000-0000-000021BF62C6 Message-Id: <20190909185121.6271e9be@thinkpad> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909090170 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190909_095140_619943_247D11FC X-CRM114-Status: GOOD ( 35.79 ) 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 , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , James Hogan , Tetsuo Handa , Heiko Carstens , Michal Hocko , linux-mm@kvack.org, Dave Hansen , Paul Mackerras , sparclinux@vger.kernel.org, Thomas Gleixner , linux-s390@vger.kernel.org, Michael Ellerman , x86@kernel.org, Russell King - ARM Linux , Matthew Wilcox , Steven Price , Jason Gunthorpe , linux-arm-kernel@lists.infradead.org, linux-snps-arc@lists.infradead.org, Kees Cook , Masahiro Yamada , Mark Brown , Dan Williams , Vlastimil Babka , Sri Krishna chowdary , Ard Biesheuvel , Greg Kroah-Hartman , linux-mips@vger.kernel.org, Ralf Baechle , linux-kernel@vger.kernel.org, Paul Burton , Mike Rapoport , Vineet Gupta , Martin Schwidefsky , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" 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 T24gTW9uLCA5IFNlcCAyMDE5IDExOjU2OjUwICswNTMwCkFuc2h1bWFuIEtoYW5kdWFsIDxhbnNo dW1hbi5raGFuZHVhbEBhcm0uY29tPiB3cm90ZToKClsuLl0KPiA+IAo+ID4gSG1tLCBJIHNpbXBs eSB1c2VkIHRoaXMgb24gbXkgc3lzdGVtIHRvIG1ha2UgcHVkX2NsZWFyX3Rlc3RzKCkgd29yaywg bm90Cj4gPiBzdXJlIGlmIGl0IHdvcmtzIG9uIGFsbCBhcmNoczoKPiA+IAo+ID4gcHVkX3ZhbCgq cHVkcCkgfD0gUkFORE9NX05aVkFMVUU7ICAKPiAKPiBXaGljaCBjb21waWxlcyBvbiBhcm02NCBi dXQgdGhlbiBmYWlscyBvbiB4ODYgYmVjYXVzZSBvZiB0aGUgd2F5IHBtZF92YWwoKQo+IGhhcyBi ZWVuIGRlZmluZWQgdGhlcmUuIG9uIGFybTY0IGFuZCBzMzkwICh3aXRoIG1hbnkgb3RoZXJzKSBw bWRfdmFsKCkgaXMKPiBhIG1hY3JvIHdoaWNoIHN0aWxsIGdvdCB0aGUgdmFyaWFibGUgdGhhdCBj YW4gYmUgdXNlZCBhcyBsdmFsdWUgYnV0IHRoYXQgaXMKPiBub3QgdHJ1ZSBmb3Igc29tZSBvdGhl ciBwbGF0Zm9ybXMgbGlrZSB4ODYuCj4gCj4gYXJjaC9hcm02NC9pbmNsdWRlL2FzbS9wZ3RhYmxl LXR5cGVzLmg6CSNkZWZpbmUgcG1kX3ZhbCh4KQkoKHgpLnBtZCkKPiBhcmNoL3MzOTAvaW5jbHVk ZS9hc20vcGFnZS5oOgkJI2RlZmluZSBwbWRfdmFsKHgpCSgoeCkucG1kKQo+IGFyY2gveDg2L2lu Y2x1ZGUvYXNtL3BndGFibGUuaDoJCSNkZWZpbmUgcG1kX3ZhbCh4KSAgICAgICBuYXRpdmVfcG1k X3ZhbCh4KQo+IAo+IHN0YXRpYyBpbmxpbmUgcG1kdmFsX3QgbmF0aXZlX3BtZF92YWwocG1kX3Qg cG1kKQo+IHsKPiAgICAgICAgIHJldHVybiBwbWQucG1kOwo+IH0KPiAKPiBVbmxlc3MgSSBhbSBt aXN0YWtlbiwgdGhlIHJldHVybiB2YWx1ZSBmcm9tIHRoaXMgZnVuY3Rpb24gY2FuIG5vdCBiZSB1 c2VkIGFzCj4gbHZhbHVlIGZvciBmdXR1cmUgYXNzaWdubWVudHMuCj4gCj4gbW0vYXJjaF9wZ3Rh YmxlX3Rlc3QuYzogSW4gZnVuY3Rpb24g4oCYcHVkX2NsZWFyX3Rlc3Rz4oCZOgo+IG1tL2FyY2hf cGd0YWJsZV90ZXN0LmM6MTU2OjE3OiBlcnJvcjogbHZhbHVlIHJlcXVpcmVkIGFzIGxlZnQgb3Bl cmFuZCBvZiBhc3NpZ25tZW50Cj4gICBwdWRfdmFsKCpwdWRwKSB8PSBSQU5ET01fT1JWQUxVRTsK PiAgICAgICAgICAgICAgICAgIF5+Cj4gQUZBSUNTIHB4eF92YWwoKSB3ZXJlIG5ldmVyIGludGVu ZGVkIHRvIGJlIHVzZWQgYXMgbHZhbHVlIGFuZCB1c2luZyBpdCB0aGF0IHdheQo+IG1pZ2h0IGp1 c3QgaGFwcGVuIHRvIHdvcmsgb24gYWxsIHRob3NlIHBsYXRmb3JtcyB3aGljaCBkZWZpbmUgdGhl bSBhcyBtYWNyb3MuCj4gVGhleSBtZWFudCB0byBqdXN0IHByb3ZpZGUgdmFsdWVzIGZvciBhbiBl bnRyeSBhcyBiZWluZyBkZXRlcm1pbmVkIGJ5IHRoZSBwbGF0Zm9ybS4KPiAKPiBJbiBwcmluY2lw bGUgcHh4X3ZhbCgpIG9uIGFuIGVudHJ5IHdhcyBub3Qgc3VwcG9zZWQgdG8gYmUgbW9kaWZpZWQg ZGlyZWN0bHkgZnJvbQo+IGdlbmVyaWMgY29kZSB3aXRob3V0IGdvaW5nIHRocm91Z2ggKGFnYWlu KSBwbGF0Zm9ybSBoZWxwZXJzIGZvciBhbnkgc3BlY2lmaWMgc3RhdGUKPiBjaGFuZ2UgKHdyaXRl LCBvbGQsIGRpcnR5LCBzcGVjaWFsLCBodWdlIGV0YykuIFRoZSBjdXJyZW50IHVzZSBjYXNlIGlz IGEgZGV2aWF0aW9uCj4gZm9yIHRoYXQuCj4gCj4gSSBvcmlnaW5hbGx5IHdlbnQgd2l0aCBtZW1z ZXQoKSBqdXN0IHRvIGxvYWQgdXAgdGhlIGVudHJpZXMgd2l0aCBub24temVybyB2YWx1ZSBzbwo+ IHRoYXQgd2Uga25vdyBweHhfY2xlYXIoKSBhcmUgcmVhbGx5IGRvaW5nIHRoZSBjbGVhcmluZy4g VGhlIHNhbWUgaXMgYmVpbmcgZm9sbG93ZWQKPiBmb3IgYWxsIHB4eF9zYW1lKCkgY2hlY2tzLgo+ IAo+IEFub3RoZXIgd2F5IGZvciBmaXhpbmcgdGhlIHByb2JsZW0gd291bGQgYmUgdG8gbWFyayB0 aGVtIHdpdGgga25vd24gYXR0cmlidXRlcwo+IGxpa2Ugd3JpdGUveW91bmcvaHVnZSBldGMgaW5z dGVhZCB3aGljaCBmb3Igc3VyZSB3aWxsIGNyZWF0ZSBub24temVybyBlbnRyaWVzLgo+IFdlIGNh biBkbyB0aGF0IGZvciBweHhfY2xlYXIoKSBhbmQgcHh4X3NhbWUoKSB0ZXN0cyBhbmQgZHJvcCBS QU5ET01fTlpWQUxVRQo+IGNvbXBsZXRlbHkuIERvZXMgdGhhdCBzb3VuZCBnb29kID8KClVtbSwg bm90IHJlYWxseS4gVGhvc2UgbWt3cml0ZS95b3VuZy9odWdlIGV0Yy4gaGVscGVycyBkbyBvbmx5 IGV4aXN0IGZvcgpwYWdlIHRhYmxlIGxldmVscyB3aGVyZSB3ZSBjYW4gYWxzbyBoYXZlIGxhcmdl IG1hcHBpbmdzLCBhdCBsZWFzdCBvbiBzMzkwLgpBbHNvLCB3ZSBkbyAob24gczM5MCkgYWdhaW4g Y2hlY2sgZm9yIGNlcnRhaW4gc2FuaXR5IGJlZm9yZSBhY3R1YWxseSBzZXR0aW5nCnRoZSBiaXRz LgpHb29kIG5ld3MgaXMgdGhhdCBhdCBsZWFzdCBmb3IgdGhlIHB4eF9zYW1lKCkgY2hlY2tzIHRo ZSBtZW1zZXQoKSBpcyBubwpwcm9ibGVtLCBiZWNhdXNlIHB4eF9zYW1lKCkgZG9lcyBub3QgZG8g YW55IGNoZWNrcyBvdGhlciB0aGFuIHRoZSBzYW1lIGNoZWNrLgoKRm9yIHRoZSBweHhfY2xlYXJf dGVzdHMoKSwgbWF5YmUgaXQgY291bGQgYmUgYW4gb3B0aW9uIHRvIHB1dCB0aGVtIGJlaGluZCB0 aGUKcHh4X3BvcHVsYXRlX3Rlc3RzKCksIGFuZCByZWx5IG9uIHRoZW0gaGF2aW5nIHByb3Blcmx5 IHBvcHVsYXRlZCAobm9uLWNsZWFyKQp2YWx1ZXMgYWZ0ZXIgdGhhdD8KClsuLi5dCj4gPiAKPiA+ IEFjdHVhbGx5LCB1c2luZyBnZXRfdW5tYXBwZWRfYXJlYSgpIGFzIHN1Z2dlc3RlZCBieSBLaXJp bGwgY291bGQgYWxzbwo+ID4gc29sdmUgdGhpcyBpc3N1ZS4gV2UgZG8gY3JlYXRlIGEgbmV3IG1t IHdpdGggMy1sZXZlbCBwYWdlIHRhYmxlcyBvbiBzMzkwLAo+ID4gYW5kIHRoZSBkeW5hbWljIHVw Z3JhZGUgdG8gNCBvciA1IGxldmVscyBpcyB0aGVuIHRyaWdnZXJlZCBleGFjdGx5IGJ5Cj4gPiBh cmNoX2dldF91bm1hcHBlZF9hcmVhKCksIGRlcGVuZGluZyBvbiB0aGUgYWRkci4gQnV0IEkgY3Vy cmVudGx5IGRvbid0Cj4gPiBzZWUgaG93IC8gd2hlcmUgYXJjaF9nZXRfdW5tYXBwZWRfYXJlYSgp IGlzIHNldCB1cCBmb3Igc3VjaCBhIGR1bW15IG1tCj4gPiBjcmVhdGVkIGJ5IG1tX2FsbG9jKCku ICAKPiAKPiBOb3JtYWxseSB0aGV5IGFyZSBzZXQgZHVyaW5nIHByb2dyYW0gbG9hZGluZyBidXQg d2UgY2FuIHNldCBpdCB1cCBleHBsaWNpdGx5Cj4gZm9yIHRoZSB0ZXN0IG1tX3N0cnVjdCBpZiB3 ZSBuZWVkIHRvIGJ1dCB0aGVyZSBhcmUgc29tZSBvdGhlciBjaGFsbGVuZ2VzLgo+IAo+IGxvYWRf W2FvdXR8ZWxmfGZsYXR8Li5dX2JpbmFyeSgpCj4gCXNldHVwX25ld19leGVjKCkKPiAJCWFyY2hf cGlja19tbWFwX2xheW91dCgpLgo+IAo+IEkgZGlkIHNvbWUgaW5pdGlhbCBleHBlcmltZW50cyBh cm91bmQgZ2V0X3VubWFwcGVkX2FyZWEoKS4gU2VlbXMgYml0IHRyaWNreQo+IHRvIGdldCBpdCB3 b3JraW5nIG9uIGEgcHVyZSAndGVzdCcgbW1fc3RydWN0LiBJdCBleHBlY3RzIGEgcmVhbCB1c2Vy IGNvbnRleHQKPiBpbiB0aGUgZm9ybSBvZiBjdXJyZW50LT5tbS4KClllcywgdGhhdCdzIHdoZXJl IEkgc3RvcHBlZCBiZWNhdXNlIGl0IGxvb2tlZCByYXRoZXIgY29tcGxpY2F0ZWQgOi0pCk5vdCBz dXJlIHdoeSBLaXJpbGwgc3VnZ2VzdGVkIGl0IGluaXRpYWxseSwgYnV0IGlmIHVzaW5nIGdldF91 bm1hcHBlZF9hcmVhKCkKd291bGQgb25seSBiZSBuZWNlc3NhcnkgdG8gZ2V0IHByb3Blcmx5IGlu aXRpYWxpemVkIHBhZ2UgdGFibGUgbGV2ZWxzCm9uIHMzOTAsIHlvdSBjb3VsZCBhbHNvIGRlZmVy IHRoaXMgdG8gYSBsYXRlciBhZGQtb24gcGF0Y2guCgpSZWdhcmRzLApHZXJhbGQKCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVs IG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDov L2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==