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 C5DC0E77197 for ; Thu, 9 Jan 2025 15:19:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4627B6B008C; Thu, 9 Jan 2025 10:19:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 411286B0092; Thu, 9 Jan 2025 10:19:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B1B26B0093; Thu, 9 Jan 2025 10:19:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C182F6B008C for ; Thu, 9 Jan 2025 10:19:52 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5CF5DC01A0 for ; Thu, 9 Jan 2025 15:19:52 +0000 (UTC) X-FDA: 82988273424.30.B583DD6 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf25.hostedemail.com (Postfix) with ESMTP id 0DF0AA0012 for ; Thu, 9 Jan 2025 15:19:49 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=MSMASKI1; spf=pass (imf25.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736435990; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eRtSquyKGkO5VxcHauXskkyGRsl2V7wKCAQNwjFunh0=; b=YUrfYcOXi8KO528sKsd/m6gcknNzQjZmetr6RZ1C1O0Ix8wXq1FoBQfoSprE3UOHhtR25Q yN2MTCeQqOqT8oeDZxSHHb0UOYDEo6P9Nq6kTm73qWdv+2K8SYk0wAwXm3ZSu2if2k8oKh B9YMNc8LgBI08dQgVkBbI00MO4ehoYo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736435990; a=rsa-sha256; cv=none; b=c/dbGlhr2UdAVXauqVC/tL9PIEu79Zb3UF4yfY8suKiwyqAZgB3LWj+g661YSBocwJt6b0 3ohiPaoaJ3qvjflz3DxiPq5Vg3l6XQaVWqrdyH+JRa/nDH3Gq+/wg7o/PlrWZ3AkyTpDaA w5SMgDiiVgYm4y+HzP390T6VKNDAdiY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=MSMASKI1; spf=pass (imf25.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 0CE2340E01F9; Thu, 9 Jan 2025 15:19:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tuK91XRnwJwF; Thu, 9 Jan 2025 15:19:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1736435983; bh=eRtSquyKGkO5VxcHauXskkyGRsl2V7wKCAQNwjFunh0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MSMASKI15NWKaVfiR4YFLTDuNJcQ7zUoJHND6KyAzhPYBIl7Nej56ZkbflXjDPccw SwZBaMflm8kkIYwWRdJdSBAk6qoXnWT+tXMcbHAe4oqr3Wevx8TMQ3C5tygnDc4yCI PxOPgdLj0AiZWKaJIDhkt/cLdoUrimgsahHFuu7muO+6o1e1J/vzx2BcEYtY6fa0D6 62JD39Ez58+GyiMMJcBMWW2yJgWmDDbHEopn6Bpb8a/UU3hObDoFf9QnShcJBLaqs5 3urjdMoyXTmhD8BhQKdQSJ8NXjvURv/J+Uzlk5MrSVpuGqKs8YEF7L5la7nyN6RfSD 7dz7xoPOHR+BsRWtHRzQKwX55Rq1iMHM1A+gUVzI9FB4qFZ9fB2fO9X3wOz903/qM4 VcyAAiDjiSbaTQS42DpS7hiubNZB3st7rxfgRPpsonFzXtMDqQdSpo0wNOSHMYbbya ZMlGBtQzu5GX2hYEhmVNkz0rlDLV1s4/VPv+X6FpI65+D55Iwszm79L/E7n026ae3D mY5uxowwdlXEZoLd7dfVW9vN9B+yX1mRQ4eKzrUe6Yd+0LSRcULioL5e6wls/n+PJW 3unbGU24+aG4hvQg9FZWe8LuTep+M1uuejAjE8rtUIeDwmBN69AAZ22coopsw7Ocgi Nsb2+btJbJBenmpuOo3x69Wk= Received: from zn.tnic (p200300eA971f933C329c23fffEA6A903.dip0.t-ipconnect.de [IPv6:2003:ea:971f:933c:329c:23ff:fea6:a903]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 3B79440E0288; Thu, 9 Jan 2025 15:19:00 +0000 (UTC) Date: Thu, 9 Jan 2025 16:18:54 +0100 From: Borislav Petkov To: Jonathan Cameron Cc: Shiju Jose , "linux-edac@vger.kernel.org" , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "tony.luck@intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "dan.j.williams@intel.com" , "dave@stgolabs.net" , "dave.jiang@intel.com" , "alison.schofield@intel.com" , "vishal.l.verma@intel.com" , "ira.weiny@intel.com" , "david@redhat.com" , "Vilas.Sridharan@amd.com" , "leo.duran@amd.com" , "Yazen.Ghannam@amd.com" , "rientjes@google.com" , "jiaqiyan@google.com" , "Jon.Grimm@amd.com" , "dave.hansen@linux.intel.com" , "naoya.horiguchi@nec.com" , "james.morse@arm.com" , "jthoughton@google.com" , "somasundaram.a@hpe.com" , "erdemaktas@google.com" , "pgonda@google.com" , "duenwen@google.com" , "gthelen@google.com" , "wschwartz@amperecomputing.com" , "dferguson@amperecomputing.com" , "wbs@os.amperecomputing.com" , "nifan.cxl@gmail.com" , tanxiaofei , "Zengtao (B)" , Roberto Sassu , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm Subject: Re: [PATCH v18 04/19] EDAC: Add memory repair control feature Message-ID: <20250109151854.GCZ3_o3rf6S24qUbtB@fat_crate.local> References: <20250106121017.1620-1-shiju.jose@huawei.com> <20250106121017.1620-5-shiju.jose@huawei.com> <20250109091915.GAZ3-Uk3rkuh38cQyy@fat_crate.local> <3b2d4275d1d24dbeacee0f192ac4d69b@huawei.com> <20250109123222.GBZ3_B1g3Esgu1-MPi@fat_crate.local> <20250109142433.00004ea7@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250109142433.00004ea7@huawei.com> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 0DF0AA0012 X-Stat-Signature: wyfmg8urrfhy9dzxsaqs4yt9hp7narhy X-Rspam-User: X-HE-Tag: 1736435989-526318 X-HE-Meta: U2FsdGVkX19+RYfTU0FNfop9T+MSs9JHW9K1nDcHQLUdmvYifgl1Atd1TRSYtWrD9RDV0rPSAQbZogRF4L3CvkkfP6jO1cmoIUbui9xv0GeATiZwr4ttdeP5OA2orofBA9zvFCE3ZU5R1btXNzv9aObd3Gpatw+pZlr+NhRbWiYmuwJHyCi+OEPCM7lxE5uyLp2lYPi2jNR+smSd9IO1FTWXF+fsZUS7ClIEF8rx1RczYc0rAR6q5QKXvITiLHSqjzIJZuvEEXa32aKFpPiJldnRCJVZeCy6eHiSwjzonvAeWDjuDdOFSJyAlx9JXNapRXwT9QkZEhtL5RyoAro+o0cO68ILHxn/aQpwD0MVmpdzFFckFyyi5KA3XwQN+HPbKjWHM15ZwSyeFNnms9ZXSS2riaSDmNDg1d1hhO9MZRCNkKaReGFMVoGRasdrY9+3RJ+5++5afpOrgqXNGxDqq+UwW/embb7gvfazBAYad//N7m1Yfe1jRSBP50gvlyReVQk1Qx51PJczfIB6AObWrRO4211LShQvv5w72hKGSD9MRnWdMIEJKo5bHqEOCQZ7H1zc5vzUDSj6XaTZKM3JBgS2IUW2dXWrJt5KWKdqwHKgVJUHbKPvLtFl7U9NBYWsDdlnJMkDNWBbP3CgT5A88tuI2kdYKyEBrCiEEgUpfV5fXs0x+03D/ZQh/zsSsMTTyHgXozst4ls2S5Uhc8qsUAe+7SEmXmLnNud8Dqnf+jdwjwMWL8uE7yD46+z/wLBJi8onQjfxs+J1FGOVyaeyBmEMeBsP2IalLqbD64raiZmEw6tdHAVFafvMnnf9Xg06nuR4WhIXW46AUO3FL/K5jyjHtjGQ33FIacLCS7bkhuQYYCdCCnUkrWI6C+Ipr4w9hnj7kmEEPhRgkHOko4qFke6LhOj4V8YyjDeBhct1tfQ8oeMG2K6HQGtXNelTlhhXcDNyoEZBKZYFxsV2A9K GyxEAypA UJxOGGiRoyHkj/joSTDZ/HNHAvcIwHrc2kVmnRBMjfnYsuXjJvO1eVQGgds5YIwQoe9A+ouD2g8gZTgDKUz2CbU8aPmMmZ8KDc7aqeE+2c00Bu7vIl50hvYgWmdEe8CB+a78f+eTmJtcEYvkWyTKFIG/WoRUGICSU5U4LcYwNMF50gZF93wSIZAGbtGvYHR7dWDjKPvA3goCd1++61WZP8MyPZo+4eUpuP7cwAu76r18cMkce9CC86O9RHA7C96WKso17pvbIzNwMqx/QYShb4SFf4bRGekAOR/979llpLa/kLucXLpRe/+vrBeN0iZfQHSjBS/XtgbmgKkF+nX8aZvRwX7jBJO5hEF4V6y69O47kMGI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001645, 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 Thu, Jan 09, 2025 at 02:24:33PM +0000, Jonathan Cameron wrote: > To my thinking that would fail the test of being an intuitive interface. > To issue a repair command requires that multiple attributes be configured > before triggering the actual repair. > > Think of it as setting the coordinates of the repair in a high dimensional > space. Why? You can write every attribute in its separate file and have a "commit" or "start" file which does that. Or you can designate a file which starts the process. This is how I'm injecting errors on x86: see readme_msg here: arch/x86/kernel/cpu/mce/inject.c More specifically: "flags:\t Injection type to be performed. Writing to this file will trigger a\n" "\t real machine check, an APIC interrupt or invoke the error decoder routines\n" "\t for AMD processors.\n" So you set everything else, and as the last step you set the injection type *and* you also trigger it with this one write. > Sure. In this case the addition of min/max was perhaps a wrong response to > your request for a way to those ranges rather than just rejecting a write > of something out of range as earlier version did. > > We can revisit in future if range discovery becomes necessary. Personally > I don't think it is given we are only taking these actions in response error > records that give us precisely what to write and hence are always in range. My goal here was to make this user-friendly. Because you need some way of knowing what valid ranges are and in order to trigger the repair, if it needs to happen for a range. Or, you can teach the repair logic to ignore invalid ranges and "clamp" things to whatever makes sense. Again, I'm looking at it from the usability perspective. I haven't actually needed this scrub+repair functionality yet to know whether the UI makes sense. So yeah, collecting some feedback from real-life use cases would probably give you a lot better understanding of how that UI should be designed... perhaps you won't ever need the ranges, whow knows. So yes, preemptively designing stuff like that "in the dark" is kinda hard. :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette