From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9BE3F5473B for ; Wed, 22 Jan 2025 01:58:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737511120; cv=none; b=IVS5RUZTZvjCeiBW0cVPAByc3jnMudDMDuNiJIccEA1hFcPGgwTAwYnlPEtOAIOgGyNeU7GH/ig8W19XzGNREgRvy24oW6GSXeVCLJvRGfIBxZkxCS5KWcVp8YpbX6p/Rhm0c5e0YlNLGdpMpjNSM0cOpxR6ZCHqx1XkZIeWDWs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737511120; c=relaxed/simple; bh=ErFyElTBld4DvSgGLbrVmJmKJFWufwhxdSlD7rQrheI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oz/Wcv/kWOZOBdEq5Se5yvInvfkKp35J/CkQIjo11PLufs27/5qLPH/BZEGQxlBKHPUsvpUJ0iiLemBhxnYq7sMS47VWaQd4/ITWgPqKz4MTdfaAmgNgMuo8+amAbQrUevam2zIgfFmiDoBp3Ypa+3X7fwDpLwP5RKczPcQe8GY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=intelfx.name; spf=pass smtp.mailfrom=intelfx.name; dkim=pass (1024-bit key) header.d=intelfx.name header.i=@intelfx.name header.b=dMI7JEOz; arc=none smtp.client-ip=209.85.167.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=intelfx.name Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intelfx.name Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=intelfx.name header.i=@intelfx.name header.b="dMI7JEOz" Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-54025432becso7099783e87.1 for ; Tue, 21 Jan 2025 17:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intelfx.name; s=google; t=1737511115; x=1738115915; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=DxyXF8Hr8QolPU/FAk8yF622zpC5hPC6gkSHqzztZZ4=; b=dMI7JEOzIIfMgtaI49c7F6b5+j1xifN+QzXYDUvUYo0Z1Sz/4F3MnTpmlCSyuZEDbL nA9QxvzKTI2NJERLpo6TOst1TlZZlakunaX372v+kDU1KBNYlDbMSwDqRiqIAFgxBNB3 LPrlYt3Pn/XEr0trUNjd6KiA7IjwnJihp3WlM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737511115; x=1738115915; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DxyXF8Hr8QolPU/FAk8yF622zpC5hPC6gkSHqzztZZ4=; b=KplmaTvBxejUMVVRPxCjj/XNu7izzF1bBojX4eXvoi6jmqA8sa4nfiyu4jXjPjFcX9 ve/KWnYFmqvFxDoAcGyuTKEUkHqMYwbaxZvoXB4bezb11xVz90yWXEgwb0TfBBdvR7Hp QEoFv9jG17509GBO9oahGeRWiMSQ186HOSwE8sOdOH22i4jqV7Z3hyP3dxuK+a+BDV3q exTCy5JNy3BjetvmbDfjLtSArVXEYyyUbWixeAE0I9jbDHAixzKJyMW/O9HUK9xueoE/ svK5lGxQz4fHKuUkzaS/Au83AzqxqaFy5ddrhYGBxwII6DloASCI0oLTfxuzKP5uJu5S E2MA== X-Forwarded-Encrypted: i=1; AJvYcCX7lHJbwWFpPcFWtQefrYZE36HW8QWLGFFnEScyB095AeVuI7zPJVxjWvtqpeEozHxTJKx6KF992Y2wX7Y=@vger.kernel.org X-Gm-Message-State: AOJu0Yw6uwab3kfWASpNw2MnQHdjtoXX2N35ioh6xrDIGzYM8IXfj26e 8VubPUdckAtIsZ+EnkdQPVPXAXhu1/FdAbdvRONdSvgF6//zhcr7bE8zd8sztdg= X-Gm-Gg: ASbGnctn+B+hZjIvBuC9YPgE6QjZvYcEqpfIJaNbBbpcXh6NwkrKwxvW5uaadcFXhQG 5+NU1fUtIegVUsf5/80qu8GhvoCKAJcwNasuwTPpSYeUC95glt/ozIECp3w6b5Vj6rT7CqfDkS0 9fEJ65iWFuiW3PDAZvXJAJV3E69Hg1TACPWOXlirKFvZdvb7O6BLkw3g8xFbQfJOlFnGdrXbT11 RzX/ByM7OIlQbCSl8DwK1JXb1kttFUg22hhaS3dkNP6w3Rkzw5c3e/IBtRSr3D7zln7T/anh0Aq dnZssBZUEM4Zr3i8CLC0GJXcBz23Mlk/YgrGzDyGjy8= X-Google-Smtp-Source: AGHT+IEbm3i2l9ctO/977rtxU4PTr1BHePcWsRUqHDQP1K8679iQ6Z1uySlSBXPdUBoeSUal2DMlMQ== X-Received: by 2002:ac2:5541:0:b0:542:2335:c43a with SMTP id 2adb3069b0e04-5439c246321mr4899214e87.21.1737511115328; Tue, 21 Jan 2025 17:58:35 -0800 (PST) Received: from stratofortress.vigil.i.intelfx.name (vigil.intelfx.name. [193.106.93.116]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5439af60ba9sm2079110e87.113.2025.01.21.17.58.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jan 2025 17:58:33 -0800 (PST) From: Ivan Shapovalov To: Andrew Morton Cc: Ivan Shapovalov , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Pasha Tatashin , David Rientjes , David Hildenbrand , Vlastimil Babka , Joel Granados , Sourav Panda , Bart Van Assche , Kaiyang Zhao , Johannes Weiner , Konstantin Khlebnikov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev Subject: Re: [PATCH] mm/vmstat: Fix a W=1 clang compiler warning Date: Wed, 22 Jan 2025 04:57:15 +0300 Message-ID: <20250122015818.3308696-1-intelfx@intelfx.name> X-Mailer: git-send-email 2.48.1.5.g9188e14f140 In-Reply-To: <20241212182425.ad1f7894cd0f00b2e34bbaed@linux-foundation.org> References: <20241212182425.ad1f7894cd0f00b2e34bbaed@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > Spose so. One always suspects that adding a typecast is a sign that we > screwed things up somehow. The relationship between enums lru_list and > node_stat_item is foggy, and I'm unsure whether this is the place to > make the transition it. Perhaps lru_list_name() should take an > `unsigned int' arg instead. All of these *_name() functions do seem to expect arguments in range of the corresponding enums, so perhaps keep those args typed as a form of self-documenting code, and do this instead? --- >From f8960df01b7f4fdc8d09a366886563385aed7f18 Mon Sep 17 00:00:00 2001 From: Ivan Shapovalov Date: Wed, 22 Jan 2025 04:10:59 +0300 Subject: [PATCH] mm: fix more clang compiler warnings In the similar vein as 30c2de0a267c ("mm/vmstat: fix a W=1 clang compiler warning"), fix several more sites that generate warnings with clang 19.1.7: ./include/linux/vmstat.h:504:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 504 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 505 | item]; | ~~~~ ./include/linux/vmstat.h:511:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 511 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 512 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/vmstat.h:524:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 524 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 525 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ 3 warnings generated. Similarly for mm_inline.h: ./include/linux/mm_inline.h:47:41: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 47 | __mod_lruvec_state(lruvec, NR_LRU_BASE + lru, nr_pages); | ~~~~~~~~~~~ ^ ~~~ ./include/linux/mm_inline.h:49:22: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 49 | NR_ZONE_LRU_BASE + lru, nr_pages); | ~~~~~~~~~~~~~~~~ ^ ~~~ 2 warnings generated. Additionally, change the lru_list_name() and mm_inline.h sites to use the same `(int)ENUMERATOR + ...` idiom to match the three first fixes above for consistency. Everywhere else is's semantically more correct thing to do because we are not really treating any of these enums as other enums but rather treating all of those as indices. Link: https://lore.kernel.org/all/20241212213126.1269116-1-bvanassche@acm.org/ Fixes: 9d7ea9a297e6 ("mm/vmstat: add helpers to get vmstat item names for each enum type") Fixes: 30c2de0a267c ("mm/vmstat: fix a W=1 clang compiler warning") Signed-off-by: Ivan Shapovalov --- include/linux/mm_inline.h | 4 ++-- include/linux/vmstat.h | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h index 1b6a917fffa4..5a2328728b21 100644 --- a/include/linux/mm_inline.h +++ b/include/linux/mm_inline.h @@ -44,9 +44,9 @@ static __always_inline void __update_lru_size(struct lruvec *lruvec, lockdep_assert_held(&lruvec->lru_lock); WARN_ON_ONCE(nr_pages != (int)nr_pages); - __mod_lruvec_state(lruvec, NR_LRU_BASE + lru, nr_pages); + __mod_lruvec_state(lruvec, (int)NR_LRU_BASE + lru, nr_pages); __mod_zone_page_state(&pgdat->node_zones[zid], - NR_ZONE_LRU_BASE + lru, nr_pages); + (int)NR_ZONE_LRU_BASE + lru, nr_pages); } static __always_inline void update_lru_size(struct lruvec *lruvec, diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h index 9f3a04345b86..545568a4ea16 100644 --- a/include/linux/vmstat.h +++ b/include/linux/vmstat.h @@ -501,27 +501,27 @@ static inline const char *zone_stat_name(enum zone_stat_item item) #ifdef CONFIG_NUMA static inline const char *numa_stat_name(enum numa_stat_item item) { - return vmstat_text[NR_VM_ZONE_STAT_ITEMS + + return vmstat_text[(int)NR_VM_ZONE_STAT_ITEMS + item]; } #endif /* CONFIG_NUMA */ static inline const char *node_stat_name(enum node_stat_item item) { - return vmstat_text[NR_VM_ZONE_STAT_ITEMS + + return vmstat_text[(int)NR_VM_ZONE_STAT_ITEMS + NR_VM_NUMA_EVENT_ITEMS + item]; } static inline const char *lru_list_name(enum lru_list lru) { - return node_stat_name(NR_LRU_BASE + (enum node_stat_item)lru) + 3; // skip "nr_" + return node_stat_name((int)NR_LRU_BASE + lru) + 3; // skip "nr_" } #if defined(CONFIG_VM_EVENT_COUNTERS) || defined(CONFIG_MEMCG) static inline const char *vm_event_name(enum vm_event_item item) { - return vmstat_text[NR_VM_ZONE_STAT_ITEMS + + return vmstat_text[(int)NR_VM_ZONE_STAT_ITEMS + NR_VM_NUMA_EVENT_ITEMS + NR_VM_NODE_STAT_ITEMS + NR_VM_STAT_ITEMS + -- 2.48.1.5.g9188e14f140