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 3F138C74A5B for ; Tue, 21 Mar 2023 10:58:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 780346B0075; Tue, 21 Mar 2023 06:58:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 730246B0078; Tue, 21 Mar 2023 06:58:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 645246B007B; Tue, 21 Mar 2023 06:58:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 561F96B0075 for ; Tue, 21 Mar 2023 06:58:23 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 197A9812C0 for ; Tue, 21 Mar 2023 10:58:23 +0000 (UTC) X-FDA: 80592606486.16.2090C21 Received: from harvie.cz (harvie.cz [77.87.242.242]) by imf27.hostedemail.com (Postfix) with ESMTP id 3C10F40005 for ; Tue, 21 Mar 2023 10:58:20 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (imf27.hostedemail.com: 77.87.242.242 is neither permitted nor denied by domain of tomas.mudrunka@gmail.com) smtp.mailfrom=tomas.mudrunka@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679396301; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KOPFN9ePJo8DE6nthb7E72kQArqlbjHUzvNNmjkFbnY=; b=Bt5jg37ML7MUSM1FDh47vblMFOP6PnlW4tuABnMmsjfmQFTEFotYBHkDU3ktha1rIkG9kD YPMWjSl4MZj6BBienwuVR9yv1azlhvT00MK+nD5hpk8eH/kG27vs3R/OFHy4ruTmTXbuo8 agVvOg6euRLU4RZ77bZT5BiTFMY5f+w= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (imf27.hostedemail.com: 77.87.242.242 is neither permitted nor denied by domain of tomas.mudrunka@gmail.com) smtp.mailfrom=tomas.mudrunka@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679396301; a=rsa-sha256; cv=none; b=Ea9TkN5bp5n9JI9y8Ovd0uuLnRSVCuyW6lVoN0D9UsAjXlyvpj0QmUDX1gWJSyZ7wa1NIX 2/CkM7A+wXUHVb5+IAbWdXnaAMcaRzh2Kba4DAIIIlWk6xfiXtx2ZJCUMk0/MeZIrmKZ5s nTyZVC+jEgaaFJjcAfQPpFbx0nv8BaE= Received: from anemophobia.amit.cz (unknown [31.30.84.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by harvie.cz (Postfix) with ESMTPSA id A641818037F; Tue, 21 Mar 2023 11:58:19 +0100 (CET) From: Tomas Mudrunka To: akpm@linux-foundation.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, rppt@kernel.org, linux-doc@vger.kernel.org, corbet@lwn.net, tomas.mudrunka@gmail.com Subject: Re: Re: [PATCH] Add results of early memtest to /proc/meminfo Date: Tue, 21 Mar 2023 11:58:12 +0100 Message-Id: <20230321105812.9257-1-tomas.mudrunka@gmail.com> X-Mailer: git-send-email 2.40.0 In-Reply-To: <20230317165637.6be5414a3eb05d751da7d19f@linux-foundation.org> References: <20230317165637.6be5414a3eb05d751da7d19f@linux-foundation.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3C10F40005 X-Stat-Signature: i6xzsmqg5bfg3z4afu4sukoqyreic7ya X-HE-Tag: 1679396300-299318 X-HE-Meta: U2FsdGVkX1+N9jBcyyJuZGelY8Cb3zvnO3FFkLVdnwuaU1TU+LRx9nL/ECDc/z+m+jmu1su1kB4NVQ9stQLKOLlfmU3n9uLrEw9q+9VKIbEeMiOYHd+bKSc6hQUyD7jyJnoFad2P9htaZhpYESCn+y9oFYpB38GdXRZqNOXoAlBx/K7STmafHiaZFOOa74S9Naa0W1hsDZy0UxiFeIxUYEEoYTznL35ikc8lt6yASV9eSyOiF+AIODFyBTxHtTlRsnvERucsPU04nMgbfWXXimI2TE4wF77Vt1Dy16n1SuySuTBp3IGFjq5uLMtuo57WoO++VhnRe5LzSgpXwA7wBJoZZYf6MuKCK5kjyHJQ0dbJbKAeqmMo88tFjjXX/yLw5AXyA6hyR+wkz6MEbiTuQl2W8ammNhUeM+hTygpeQlgCaZM0np1fj8D5Vu9lNXXaRL+IaKFOm4axwqRciQf00WvBcCD53FYXhyE6i73qv24ZKrcIV9js35GJT2aHi2C36lGDs35GVvyediZYgWvRPeseZGrEyHHTJu5Rn6abDGoab8UHYdW+DA97Eb5L6Rkot45+6xjngI3cWOmUx4U7wARe4s8g1/DrjMU8UEUfaq7KC4p2WrP2mr6kcp7WYbRNI/mTpyjy+5zQwNM7GwzvgiYUdp3FDJ0qgSychlETojvI0H4FojOpTS49IW2Rmkz0eKXJTCMWS63TtE3BxqTLS1YH5iEnVunqFhvgeDjA6q3te94A3olS9eO2PgQP2by4+q6pnn1/NuMupJFCQ8GTWZLZF4bHFkPY4ddod4NVchuTpYvqHwffU94psn0erkAHE7HyRgHS+FlKep+zII9l8vPeAyv+YGbTJI/0nS5EmNScGqw3lz5jYWDubtRlQHWQ/GLufhoAhfwoORLDYrGg0OACEUFm/TyUsHG4n4V3kE5f4RhDucQIG5yGNnP2qzwT6StKXVGByL5q2zxI9F+ ii/0pOq4 uoboQIizCEQx0dAf+kTOrzcgJaL3OcpDrTX/0UdbB6zIQKpEZghmiv1IV80nK0uCEFPLRizmfQSJPfpudj+6az0ce/7KN9BDZi7F+5wOdJZ1jtJGmuYM1ZFWtro6JgL+hYpowzj9JgvELY6o/5utMtgDpEmtz7XTP5F9xOeob3/Z3+s+JrPrNs/5gLvLQNVRAfWtwiW5pw4LxyVMeG2u5y16KmtTdqUlCLPzNPZIfEjukjStDEKFq0IXx2nQTUTIn2cVa3zolURycsZeNhjgYVVpYdswfvGkuNMrk4IjXsZ7ODMWRVdDdC6wjfq9HrLi4JaOMhi+F7+o7NQLH8ydH/njfpyTskGunllh8zQIVQ2kVYVsYkuACT+PRXg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > meminfo is rather top-level and important. Is this data sufficiently > important to justify a place there? There is already "HardwareCorrupted" which is similar, but for errors reported by ECC, so it makes sense to have both in single place. > Please describe the value. The use-case(s). Why would people want > this? When running large fleet of devices without ECC RAM it's currently not easy to do bulk monitoring for memory corruption. You have to parse dmesg, but that's ring buffer so the error might disappear after some time. In general i do not consider dmesg to be great API to query RAM status. In several companies i've seen such errors remain undetected and cause issues for way too long. So i think it makes sense to provide monitoring API, so that we can safely detect and act upon them. > Comment layout is unconventional. Fixed in PATCH v2 > Coding style is unconventional (white spaces). > I expect this code would look much cleaner if some temporaries were used. Fixed in PATCH v2 > I don't understand this logic anyway. Why not just print the value of > early_memtest_bad_size>>10 and be done with it. I think 0 should be reported only when there was no error found at all. If memtest detect 256 corrupt bytes it would report 0 kB without such logic. Rounding down to 0 like that is not a good idea in my opinion, because it will hide the fact something is wrong with the RAM in such case. Therefore i've added logic that prevents rounding down to 0. > The name implies a bool, but the comment says otherwise. Fixed in PATCH v2 > It's a counter, but it's used as a boolean. Why not make it bool, and do Fixed in PATCH v2 > Also, your email client is replacing tabs with spaces. Fixed in PATCH v2