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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24684C27C4F for ; Sat, 22 Jun 2024 00:59:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EEF78D01AE; Fri, 21 Jun 2024 20:59:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79DCA8D0196; Fri, 21 Jun 2024 20:59:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63ECF8D01AE; Fri, 21 Jun 2024 20:59:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 45B418D0196 for ; Fri, 21 Jun 2024 20:59:44 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id ED8651A130A for ; Sat, 22 Jun 2024 00:59:43 +0000 (UTC) X-FDA: 82256717046.03.367A309 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf11.hostedemail.com (Postfix) with ESMTP id 4AE1340011 for ; Sat, 22 Jun 2024 00:59:42 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=cOq92MGl; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719017971; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gkwZ8YuGWXQX/nZIWfVnjg20uYthe41JbvscW1pRGZ4=; b=faC4lrTqU2vT+xEGQ1TVBXoWcxDHw5VEq4/Ur7VPEs0ZpkqZ/m1eFRk0RVSfiX7W9KeWIl xHloQC4RjCKK+GsbmtH9fMbl5/qWR7ISiv0DG8MhIBaqQINhLikRUmozRqvMN4jW1cbJ++ ZyIqCeRLe6UBAOxe6pn/eOIQVXbTFHk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719017971; a=rsa-sha256; cv=none; b=snYO6fYqmnCvSxg4QvcSoR+PWEFbt6mf3C19ecKmf58sP370pcGAtwoUMXBi3eWZLeMDTm z1FkAYly546eofUQQ5pENyjL5XCdIluFOFWobiicF7wNcMo4oXivkN0fRyJ3XuW9UktXlO DZdD3qihfqykuiV69SzPiNX0Q7z2T3M= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=cOq92MGl; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7366F625F1; Sat, 22 Jun 2024 00:59:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC5D3C3277B; Sat, 22 Jun 2024 00:59:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1719017981; bh=l6E+/pOFYoPz0/65BUpxauVRh7+RaH5Xm9C9eF+VW2I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cOq92MGlyu8ofUwJuq3p0k9a1CQ9ZHqycqJ41yF0KLkHNM/aPVxEILaBIc9abxNfO OByVRBpGAGCZiN2Lin6Iz8uQEx+5a3K0Diwx8XsCt9JEM/CuTsvIUomageXp/JpB4l DSSgJf3ZxFmZO9QnbuN5xyFEjVxCMfEzFgrGYZG0= Date: Fri, 21 Jun 2024 17:59:40 -0700 From: Andrew Morton To: Matthew Wilcox Cc: Shivamurthy Shastri , linux-kernel@vger.kernel.org, linux-mm@kvack.org, vbabka@suse.cz, hannes@cmpxchg.org, anna-maria@linutronix.de, tglx@linutronix.de Subject: Re: [PATCH] mm/vmstat: Fix -Wenum-enum-conversion warning in vmstat.h Message-Id: <20240621175940.dd080730047a3f5f5a190ea0@linux-foundation.org> In-Reply-To: References: <20240621111604.25330-1-shivamurthy.shastri@linutronix.de> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4AE1340011 X-Stat-Signature: jwa9ye4tch7byu5w6uy4cuiqhocxahme X-HE-Tag: 1719017982-750288 X-HE-Meta: U2FsdGVkX18kBl+y+JRrONwxSDwLKfA8Zlq1kXZgtFJ6eDXXFDpnbQGotV9MrqZxLQ4ZuWLGBaiAtDyRjhbKyxS9ijKa/Qh6c3O54zhtZketURT7H5KSTcdOHVgUuMwYFD0NVeJKWkzyDheBpP7hrJYZ7oeaMhQ8C3/xAae2CRSFh4SltgpTaTklGRxFFayRv6uyVNkGgZ2IH52ulgNz8ZZdWL8hvvXzbedwy3JEE9LizPctT/gpP6C/aeLvFpsyoG21ZndoYLA7N7HtmAByHLt3y+fuPSXobt52yOr4LrBtgAR9/P/VdUC/88tMQ+Rkw2n5D7yiZEFLaHREudw6hmDQa15JBjk2N4Kw36EYyeg2o9BrT75TIOeljYNz/99aeC/bQ3P/QHrGqpa6VoyQNGFLkhTQQiFTb6Ha0nUDeSHUctP4ikME0nDkUshY1pm3rMpRCEcFl44y0Ns+z9IlXNi54qiZfSlBPmi3hWa1GfWPwseTmEQxHraEEDjnuujemFZZuHO/j2HhgVbEJc+eFCi+JeMn9d9gmOrUV8/CqKP7q0Drgok/mBHgY1RGSGbU8KsV+nHniAL4c8PTIDu6KBd1z7G1bImvsEYl7qufogF9LVDnZZ/haT9JEw8avz/zf+SrBZ+f5dOpCaVuPKxNlkFNU0++XKDKFdf6ZsLISHIwa9emHNbrTkalaqxqmGcIFfChan6GbcYHa/1tYXqqSWnaNYzfu/b3hDxJPQ348zV8/rsBMnAX5dh0BAvfx/nDA8EOT2o0d51zf9C3EMAlpa4TzhHciyO2PfNK9DcllBsPlnNV69mmJMujPpLquApbDED/5LLK9d8KYgk++2DBbwiR9ik7RQptzX8sOroAUGrUL+VVxb6+LbMNbwF74MRtYj/e8Nk7drDUd/0GUYK4slc+PXYVUF1FrASah4tZvSSD/fe4ERy1MRfM9ir8z0hID6iHpJ+/KXGkQAWMDaH EDbZFWoW BmJ4Uq9QTfsUcxpfhXnwv0+AYfJwAq00jqYi6y4qWQnmfj7qrtQ/J8U2pubTE2yb/qNHTwrBNzDhCp2QkBvLZmdYOFQfJWn1ElbF+xzTxIWhVLqbG1WJmIWDrDGavFggvw159p61ATe/f1G4oAjt1roeIwkfXbItblK8xT5aAJO+ShPyE1+TUZDSDG2FoslJy5yItpFDLAGgEJGqpm/d2YbZ6VPx9QaY2vobeVwUYbaNiDZ9JtjDY2HcXi+D5xGRqaX1UUqrvk08pxJA27qyy0uZ6XQUsa6mLTmMJ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 21 Jun 2024 19:13:57 +0100 Matthew Wilcox wrote: > On Fri, Jun 21, 2024 at 01:16:04PM +0200, Shivamurthy Shastri wrote: > > A W=1 build with -Wenum-enum-conversion enabled, results in the > > following build warning due to an arithmetic operation between different > > enumeration types 'enum node_stat_item' and 'enum lru_list': > > OK, but why do we want -Wenum-enum-conversion enabled? The code looks > perfectly fine before, and now it looks ugly. What bugs does this > warning catch? > > > static inline const char *lru_list_name(enum lru_list lru) > > { > > - return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" > > + return node_stat_name(NR_LRU_BASE + (enum node_stat_item)lru) + 3; // skip "nr_" > > } > > and honestly, I'd convert it to an int instead of enum node_stat_item. > Because it is not a node_stat_item, and it wouldn't make sense to > add two node_stat_items together. Just like it doesn't make sense to > add two pointers together (but it does make sense to add an integer to a > pointer). Yeah, I suppose so. The calling code iterates across enums with an int, imaginatively called `i'. Then again, it seems right that a function called lru_list_name() takes an enum lru_list.