Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1500376pxf; Fri, 9 Apr 2021 09:53:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxzefDO1fdUe6QxUXhJgKPaTnhY58sba++n/Z6JYC6m+ttou4nohnkbP0FLj8Ae4v8na4KK X-Received: by 2002:a17:906:f283:: with SMTP id gu3mr16739671ejb.91.1617987222580; Fri, 09 Apr 2021 09:53:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617987222; cv=none; d=google.com; s=arc-20160816; b=Auu/hpG5VqHpBpygCQkG6Zpq3MKMdJ6so7NZ9+JnSSlH7Cpj4ja4I6CvLTHNiuMwqC 5Tho0YWy3tf2ha25zTQ6lzYlaGXKezTH59TbzkGZYAIEznu0SyrusBuoVud6+GqGSNCW bwQ/ZCSj1QuENci94xuP6P77MGuABswtBIN+2O58MZWGcPynIOIvVQAGMdyza36c65G2 3qQy6h4staDlcuN20qKtwJ3ObBxUWrWer/BjIwX8r12mr7fpmIhBaCyRrlO6q715GT5v bAlmptni0dwjImlLYoAHihi1YvsYosDp/eUtAGHm5eAGyGDd7lnm8RFQ6aiCvQ5HN9HF DgVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=pIJQcLBXKEgMq8l/LdL9lJld0GXEbVJErfc4WhVZNSw=; b=y6PWEZTNfIvXO/7WENm1HFARiGGRNn4ztBu2tCDfzXJLkF4rvXFdW6c0f15bgpjKQ3 M5Ci99L0VVQ5HHGaHfkgbHM8EkJnnkBQZEJ1rvpqM0D7uwh5Qin44eAtJULP19QOS5MM NZ0hG6/fNvofLOj/PLbDg851P99ymUHgTZ4epYH3dwoxzmP/nLvlM0q/apoHVB6Ycoph c37fc2uZLtGrVU7fGt1brfCnkKywEkQuNj84QLZYpAmo/5Bl60y5gvbi1GhUNjmdlelG rCufEQmlqjyp1RL6I1FuRuqKtAPCFD5eH7yqgVRrFHXdBAaQcFPF+MEQCmwDBMEDvEIX gKdw== 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=vmware.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m13si2279968ejc.676.2021.04.09.09.53.19; Fri, 09 Apr 2021 09:53:42 -0700 (PDT) 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=vmware.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233977AbhDIQwK (ORCPT + 99 others); Fri, 9 Apr 2021 12:52:10 -0400 Received: from ex13-edg-ou-001.vmware.com ([208.91.0.189]:3092 "EHLO EX13-EDG-OU-001.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233038AbhDIQwI (ORCPT ); Fri, 9 Apr 2021 12:52:08 -0400 Received: from sc9-mailhost3.vmware.com (10.113.161.73) by EX13-EDG-OU-001.vmware.com (10.113.208.155) with Microsoft SMTP Server id 15.0.1156.6; Fri, 9 Apr 2021 09:51:48 -0700 Received: from vertex.localdomain (unknown [10.16.119.23]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 4078520DB0; Fri, 9 Apr 2021 09:51:52 -0700 (PDT) From: Zack Rusin To: CC: Andrew Morton , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Subject: [PATCH v2] mm/mapping_dirty_helpers: Guard hugepage pud's usage Date: Fri, 9 Apr 2021 12:51:51 -0400 Message-ID: <20210409165151.694574-1-zackr@vmware.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Received-SPF: None (EX13-EDG-OU-001.vmware.com: zackr@vmware.com does not designate permitted sender hosts) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mapping dirty helpers have, so far, been only used on X86, but a port of vmwgfx to ARM64 exposed a problem which results in a compilation error on ARM64 systems: mm/mapping_dirty_helpers.c: In function ‘wp_clean_pud_entry’: mm/mapping_dirty_helpers.c:172:32: error: implicit declaration of function ‘pud_dirty’; did you mean ‘pmd_dirty’? [-Werror=implicit-function-declaration] This is due to the fact that mapping_dirty_helpers code assumes that pud_dirty is always defined, which is not the case for architectures that don't define CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD. ARM64 arch is a little inconsistent when it comes to PUD hugepage helpers, e.g. it defines pud_young but not pud_dirty but regardless of that the core kernel code shouldn't assume that any of the PUD hugepage helpers are available unless CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD is defined. This prevents compilation errors whenever one of the drivers is ported to new architectures. Signed-off-by: Zack Rusin Cc: Andrew Morton Cc: Thomas Hellström (Intel) Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org --- mm/mapping_dirty_helpers.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/mapping_dirty_helpers.c b/mm/mapping_dirty_helpers.c index b59054ef2e10..b890854ec761 100644 --- a/mm/mapping_dirty_helpers.c +++ b/mm/mapping_dirty_helpers.c @@ -165,10 +165,12 @@ static int wp_clean_pud_entry(pud_t *pud, unsigned long addr, unsigned long end, return 0; } +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD /* Huge pud */ walk->action = ACTION_CONTINUE; if (pud_trans_huge(pudval) || pud_devmap(pudval)) WARN_ON(pud_write(pudval) || pud_dirty(pudval)); +#endif return 0; } -- 2.27.0