Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5964296pxb; Thu, 27 Jan 2022 03:36:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJxKiQXUFdjZIAptORggba77mor4wdohNiautYZ9C0tgPGGY9YE43OZE3bFktF0zfYXsM3eQ X-Received: by 2002:a17:907:7412:: with SMTP id gj18mr2471796ejc.379.1643283390555; Thu, 27 Jan 2022 03:36:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643283390; cv=none; d=google.com; s=arc-20160816; b=0LsSVWsM0D/UZlHzJwW3DHtQ/mAKyeMoOVodbE3B1V/oVUH39c0nW41Pfz0xt/agyL 9a3wwhgXeSY7qSK+VxOzWROnXmYfxT1nB2wwaTYfx/PYUZyb6qnr2uq4TmpQO7WOxYJ1 6875t2fYRyeke7Wru7zLeRBJ15dea1u5MSv0CRtNFhVz5B4GQ7rlWSWVojoPZrJfUNwB Y2yOyMJVBwhMl/2A9oHjD8Oh0RNeVkdxaAobjlbUBfx+zRAci4YuAoNtXL2jbiOa+syu HaYmkIyh4gigGno5Ct38Hr7tT+5snHf7nc1G+PRsOfUKhVaObJ75h6KNgOt0f7mJLbYC v5Sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=ffmSPPmF7X0xEZi/Ae6oaYCWzzA1QQ2hzdHlZoefG50=; b=VXRn9yH39eIQbXQlnY+bYU4S10wSf2EWVQ2WoumgB6Te99OE7Z1ntsXsWM0ujXaAh5 SKymFc51rCN4WH8KbTP5s258/hy80yLvw2AI0XYrHbzn0KR28mHJenO5pBp81FNwsKBR cUXr4ihOWlmauyZuXl38RDYatmSG/0XIlPBlaJVxd43NSw/pRCPiJ/8BvnB4AlLWpbhv pBa0XOguQ4spNErN2hemyOwN8fE748YO7yIL0vjnpHAi883ThELBKiHsWQkQpZQWKHEv xsKQ0xitt1NLvYVvMBjYRx1pKh1QOcYeBOfyx7IM+cYtBz1+ysEMmXnz+8Z1ZlP/Q8ZH qtKw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q8si1389963edd.115.2022.01.27.03.36.05; Thu, 27 Jan 2022 03:36:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235994AbiA0EQU (ORCPT + 99 others); Wed, 26 Jan 2022 23:16:20 -0500 Received: from foss.arm.com ([217.140.110.172]:33780 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235900AbiA0EQT (ORCPT ); Wed, 26 Jan 2022 23:16:19 -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 C4BD31FB; Wed, 26 Jan 2022 20:16:18 -0800 (PST) Received: from [10.163.42.218] (unknown [10.163.42.218]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 14F723F7D8; Wed, 26 Jan 2022 20:16:16 -0800 (PST) Subject: Re: [RFC V1 01/31] mm/debug_vm_pgtable: Directly use vm_get_page_prot() To: Christoph Hellwig Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org References: <1643029028-12710-1-git-send-email-anshuman.khandual@arm.com> <1643029028-12710-2-git-send-email-anshuman.khandual@arm.com> From: Anshuman Khandual Message-ID: <1f75e638-7b72-1c1b-c493-eb4b62dcf280@arm.com> Date: Thu, 27 Jan 2022 09:46:23 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/26/22 12:45 PM, Christoph Hellwig wrote: >> + * >> + * Protection based vm_flags combinatins are always linear >> + * and increasing i.e VM_NONE ..[VM_SHARED|READ|WRITE|EXEC]. >> */ >> - for (idx = 0; idx < ARRAY_SIZE(protection_map); idx++) { >> + for (i = VM_NONE; i <= (VM_SHARED | VM_READ | VM_WRITE | VM_EXEC); ix++) { >> pte_basic_tests(&args, idx); >> pmd_basic_tests(&args, idx); >> pud_basic_tests(&args, idx); > > This looks rather convoluted. I'd prefer to add a helper for the body > of this loop, and then explicitly call it for all the valid > combinations. Right now all are valid, so this dosn't change a thing > except for generating larger code due to the explicit loop unrolling, > but I think it is much easier to follow and maintain. IIUC, then will just keep this unchanged.