Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp955923imm; Wed, 15 Aug 2018 08:57:07 -0700 (PDT) X-Google-Smtp-Source: AA+uWPz0GgiOIpKhSgj+Vp6AfO6bw//F3uPC/N8eRILAKXXhnS3VqJlAABJxxan87rDIO5MTxdCc X-Received: by 2002:a17:902:20e9:: with SMTP id v38-v6mr25162235plg.107.1534348627245; Wed, 15 Aug 2018 08:57:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534348627; cv=none; d=google.com; s=arc-20160816; b=b11KcEPN2eTBcmahKoncFfJHZ95DTULCBon3grYQXwiEG6PkG/v/YCaf+m+ReMFsy/ THdCiysJSseYLva2FRVbpY7ox8H8Z9GOyNWK+CR+2z/QPJnlHELdvY/UlekIbrXiD2ix tF21BMUx4Vr7tgK/BxQ8gwkd0xPhf/HuAPiMqeswhYGmIJIWjiWND/8mYR6fVNwbAy6a UmASND7ESVp1aYeGBy0143+opxsaOrbzaRaAhTVxTinZwbpYLAz8f8w0dw8l4s0T37uq 29rFcTl5XOa8qTxrO5cmDiZMfT+76Z9LuFWis8S5qJI+ruzysgjNuQa76/XMhNcGWCMk 9TYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=SonRT2KdE09A9/BANuoG9h4nqkf0C/dWjC4ct1MLFJc=; b=YG372uwSGb77gmqmO7j2m3mMDqv5kKHamJoQOju2nJ1jA8KHxyxfgn78NXTfoA8BiQ AFm2EkMPanMteZybm3KSAU1fs3AJmEeb6/rZaYLtbUeJiajCPCSC4eRknp9gGsCRG9Tu BLVXc7roqUBZ/TOMCRDQ2AxOg2TMQ4ydH3g3IuZiqSyBU3dh4bcqGd4irj0YspG+bNeC fQ7g3tk66j0LOKAArcoeC01we1zYLBCsvl0JEfMf8RqvvDblGhbZzmlsilyPYj1EdBwx btrvLB/nAl01fDQeOMC4M3KkdLyqpl2f1pV7GGNC4f3gUxZjKUZk1xfbCy4F8G+oKmNC FyZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k62-v6si2529409pfk.199.2018.08.15.08.56.31; Wed, 15 Aug 2018 08:57:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729423AbeHOSrp (ORCPT + 99 others); Wed, 15 Aug 2018 14:47:45 -0400 Received: from mail.skyhub.de ([5.9.137.197]:32816 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729300AbeHOSrp (ORCPT ); Wed, 15 Aug 2018 14:47:45 -0400 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id clZifKvmhkFe; Wed, 15 Aug 2018 17:54:45 +0200 (CEST) Received: from nazgul.tnic (95-42-132-194.ip.btc-net.bg [95.42.132.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id D11F11EC0104; Wed, 15 Aug 2018 17:54:44 +0200 (CEST) Date: Wed, 15 Aug 2018 17:54:52 +0200 From: Borislav Petkov To: "Ghannam, Yazen" Cc: "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "tony.luck@intel.com" , "x86@kernel.org" Subject: Re: [PATCH 2/2] x86/MCE/AMD: Skip creating kobjects with NULL names Message-ID: <20180815155452.GB28669@nazgul.tnic> References: <20180809140834.59264-1-Yazen.Ghannam@amd.com> <20180809140834.59264-2-Yazen.Ghannam@amd.com> <20180809161806.GB20928@nazgul.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 09, 2018 at 06:46:26PM +0000, Ghannam, Yazen wrote: > This patch makes it so that we don't fail init just because some banks don't > have names. The data caching we do is useful even if we fail to create sysfs > entries for some banks. The interrupt handler can work fine without a sysfs > entry for every bank. It seems like overkill to deallocate all the structures > and sysfs entries for all the banks just because we fail to create entries for > some banks that don't have names. Maybe I'm missing the big picture here but why, all of a sudden, are some banks without names? This clearly is new because it wasn't like that before, so what is it? Maybe you should explain the bigger picture first. And if banks don't have names, then we should generate some for them instead. Because this code is already ugly and recursive - we certainly don't want to add more conditionals to it because that thing is a mess as it is now. > In other words, I think we should decouple the interrupt handler from the > sysfs interface. The interface is nice to have but not necessary for the HW > and OS to handle threshold interrupts. If we do so, then new HW with new, > unnamed types will work with older versions of Linux. To tell you the truth, I'm not at all psyched about telling the future. We can try to be future-proof to a certain degree but this should not be the determining factor how we design things. But the aspect of decoupling sysfs representation from handler makes sense. It just needs to be done cleanly. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --