Message ID | 20230120233814.368803-1-gshan@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp483620wrn; Fri, 20 Jan 2023 15:40:40 -0800 (PST) X-Google-Smtp-Source: AMrXdXtoVJpwtYXMhwTRsOkuXu4DqH86SuZHmz8v2GgsVLV7L8ZLRto9OLk7pN61fIbPJeas5MkI X-Received: by 2002:a05:6a00:e15:b0:58d:dbd0:f39f with SMTP id bq21-20020a056a000e1500b0058ddbd0f39fmr12628822pfb.27.1674258039755; Fri, 20 Jan 2023 15:40:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674258039; cv=none; d=google.com; s=arc-20160816; b=CzjRT96EuQj0M/Y1SoIh//vlXCyRN4ZWB1Tn7ep49b7MOZwlzH8F0Ow/WGbvj9DQ8c RAPSLlXs9EVL15yNbLVGXRBZGJHXmu9b9NBSaGIS6iOk0DkcZN2DKRq6jPsjKFxNNpuE wPWJUwjjYt8r/BHuBUtkBUwCqskJ9OK6M5FggDfwFgtPZp9Fzidcxv7rK+FinK0jEpU5 3fZ4sKe/x0K9MTqUKA3eqWuiwvAPE6cmGBF/3XPeEj2NkdRznT4/dCJc8sakKu1dQwhR DyrurQ/GvbrNbfmpIwAsQkZMfAWq8zv8BDG05wTTGxbP/nuu0SMKP+Tblq+qdmw71ZvA DWUw== 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:dkim-signature; bh=eQABDFnHgbtrqYImAs8JujABVEskMqaC41YW4ab4b4o=; b=G5G3L012mmINjgFncxbV4PcKQhuL+24VKGspB7UcDohNUJRlJtcwfa3L65P03ix+9d H5pzwqr1o0nK77csGIMiCi0qS1jBKgwHOJjVuwWFWh4D2mBls+PlCeVttoMa9t5oBsc9 Jk4YY0amKwhlt05mMmqUgqHvvIubnDKuDrZFTCR8c47s56zps5LqGzCSeVX10L0dmRpH 5S0i2g0O27nakauWIUVZNV1sH4VRquPCSXOQaFzKomAwGuy+ZzoIpJuECF58hjcoQJUj h6WmT+fr1HaRo/o6jUG5jhfjPdVmgS+QR7FAWD+nfDhLU7bQr3AXSkbNB9Vef1JoqG14 E6jQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="hdt/8ADh"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d2-20020a056a0010c200b0058dd7b77abfsi11889632pfu.255.2023.01.20.15.40.25; Fri, 20 Jan 2023 15:40:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="hdt/8ADh"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229737AbjATXj1 (ORCPT <rfc822;forouhar.linux@gmail.com> + 99 others); Fri, 20 Jan 2023 18:39:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229500AbjATXjV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 20 Jan 2023 18:39:21 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75A696E0DA for <linux-kernel@vger.kernel.org>; Fri, 20 Jan 2023 15:38:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674257913; h=from:from: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; bh=eQABDFnHgbtrqYImAs8JujABVEskMqaC41YW4ab4b4o=; b=hdt/8ADhmxMjQfHjXH7cn7VObeJS7eWFc5qOTG3NE9vDEExKzmjVHbraY0BSOXqdw3yb3E e8UGGDfiLfsCDUveLyFzy2roDi2uWYTFxFfE/YDI08pxBHaMf3thVT42NTOaKdGFxadUWt 6PjnBnlhPG1pPul3E47I7V9fxDyq2Eg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-450-1HqXXzKmNvmnGNSzx2WArA-1; Fri, 20 Jan 2023 18:38:29 -0500 X-MC-Unique: 1HqXXzKmNvmnGNSzx2WArA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F376101A521; Fri, 20 Jan 2023 23:38:29 +0000 (UTC) Received: from gshan.redhat.com (vpn2-54-98.bne.redhat.com [10.64.54.98]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6AF1140C2064; Fri, 20 Jan 2023 23:38:26 +0000 (UTC) From: Gavin Shan <gshan@redhat.com> To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, david@redhat.com, osalvador@suse.de, gregkh@linuxfoundation.org, rafael@kernel.org, shan.gavin@gmail.com Subject: [PATCH v2] drivers/base/memory: Use array to show memory block state Date: Sat, 21 Jan 2023 07:38:14 +0800 Message-Id: <20230120233814.368803-1-gshan@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755520111869254773?= X-GMAIL-MSGID: =?utf-8?q?1755586797825295308?= |
Series |
[v2] drivers/base/memory: Use array to show memory block state
|
|
Commit Message
Gavin Shan
Jan. 20, 2023, 11:38 p.m. UTC
Use an array to show memory block state from '/sys/devices/system/
memory/memoryX/state', to simplify the code. Besides, WARN_ON()
is removed since the warning can be caught by the return value,
which is "ERROR-UNKNOWN-%ld\n". A system reboot caused by WARN_ON()
is definitely unexpected as Greg mentioned.
No functional change intended.
Signed-off-by: Gavin Shan <gshan@redhat.com>
---
v2: Drop WARN_ON() (Greg)
---
drivers/base/memory.c | 25 ++++++-------------------
1 file changed, 6 insertions(+), 19 deletions(-)
Comments
On 21.01.23 00:38, Gavin Shan wrote: > Use an array to show memory block state from '/sys/devices/system/ > memory/memoryX/state', to simplify the code. Besides, WARN_ON() > is removed since the warning can be caught by the return value, > which is "ERROR-UNKNOWN-%ld\n". A system reboot caused by WARN_ON() > is definitely unexpected as Greg mentioned. > > No functional change intended. > > Signed-off-by: Gavin Shan <gshan@redhat.com> > --- Reviewed-by: David Hildenbrand <david@redhat.com>
On Sat, Jan 21, 2023 at 07:38:14AM +0800, Gavin Shan wrote: > Use an array to show memory block state from '/sys/devices/system/ > memory/memoryX/state', to simplify the code. But does it really? Now you have an implicit binding between the order of this specific string array and an enumerated type that is defined in some other location. This makes any future changes really really hard to determine that you got this correct. Besides, WARN_ON() > is removed since the warning can be caught by the return value, > which is "ERROR-UNKNOWN-%ld\n". A system reboot caused by WARN_ON() > is definitely unexpected as Greg mentioned. > > No functional change intended. > > Signed-off-by: Gavin Shan <gshan@redhat.com> > --- > v2: Drop WARN_ON() (Greg) > --- > drivers/base/memory.c | 25 ++++++------------------- > 1 file changed, 6 insertions(+), 19 deletions(-) > > diff --git a/drivers/base/memory.c b/drivers/base/memory.c > index b456ac213610..0fdacdc79806 100644 > --- a/drivers/base/memory.c > +++ b/drivers/base/memory.c > @@ -141,28 +141,15 @@ static ssize_t state_show(struct device *dev, struct device_attribute *attr, > char *buf) > { > struct memory_block *mem = to_memory_block(dev); > - const char *output; > + static const char *const mem_state_str[] = { > + NULL, "online", "going-offline", NULL, "offline", > + }; > > - /* > - * We can probably put these states in a nice little array > - * so that they're not open-coded > - */ > - switch (mem->state) { > - case MEM_ONLINE: > - output = "online"; > - break; > - case MEM_OFFLINE: > - output = "offline"; > - break; > - case MEM_GOING_OFFLINE: > - output = "going-offline"; > - break; > - default: > - WARN_ON(1); > + if (mem->state >= ARRAY_SIZE(mem_state_str) || > + !mem_state_str[mem->state]) > return sysfs_emit(buf, "ERROR-UNKNOWN-%ld\n", mem->state); > - } > > - return sysfs_emit(buf, "%s\n", output); > + return sysfs_emit(buf, "%s\n", mem_state_str[mem->state]); Overall, the current code is simpler and easier to maintain and understand over time. You don't have to mess with an array length, or anything else like that. I'm all for removing the WARN_ON() if you want to do that, but I think this is a regression in the ability to maintain this code for the next 40+ years, sorry. greg k-h
diff --git a/drivers/base/memory.c b/drivers/base/memory.c index b456ac213610..0fdacdc79806 100644 --- a/drivers/base/memory.c +++ b/drivers/base/memory.c @@ -141,28 +141,15 @@ static ssize_t state_show(struct device *dev, struct device_attribute *attr, char *buf) { struct memory_block *mem = to_memory_block(dev); - const char *output; + static const char *const mem_state_str[] = { + NULL, "online", "going-offline", NULL, "offline", + }; - /* - * We can probably put these states in a nice little array - * so that they're not open-coded - */ - switch (mem->state) { - case MEM_ONLINE: - output = "online"; - break; - case MEM_OFFLINE: - output = "offline"; - break; - case MEM_GOING_OFFLINE: - output = "going-offline"; - break; - default: - WARN_ON(1); + if (mem->state >= ARRAY_SIZE(mem_state_str) || + !mem_state_str[mem->state]) return sysfs_emit(buf, "ERROR-UNKNOWN-%ld\n", mem->state); - } - return sysfs_emit(buf, "%s\n", output); + return sysfs_emit(buf, "%s\n", mem_state_str[mem->state]); } int memory_notify(unsigned long val, void *v)