linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 2/2] x86/MCE/AMD: Skip creating kobjects with NULL names
Date: Wed, 15 Aug 2018 17:54:52 +0200	[thread overview]
Message-ID: <20180815155452.GB28669@nazgul.tnic> (raw)
In-Reply-To: <BN7PR12MB259395675EBD74400D9FEBE5F8250@BN7PR12MB2593.namprd12.prod.outlook.com>

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.
--

  reply	other threads:[~2018-08-15 15:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-09 14:08 [PATCH 1/2] x86/MCE/AMD: Check for NULL banks in THR interrupt handler Yazen Ghannam
2018-08-09 14:08 ` [PATCH 2/2] x86/MCE/AMD: Skip creating kobjects with NULL names Yazen Ghannam
2018-08-09 16:18   ` Borislav Petkov
2018-08-09 18:46     ` Ghannam, Yazen
2018-08-15 15:54       ` Borislav Petkov [this message]
2018-08-16 18:46         ` Ghannam, Yazen
2018-08-21 13:15           ` Borislav Petkov
2018-08-21 18:27             ` Ghannam, Yazen
2018-08-09 16:15 ` [PATCH 1/2] x86/MCE/AMD: Check for NULL banks in THR interrupt handler Borislav Petkov
2018-08-09 18:18   ` Ghannam, Yazen
2018-08-16 19:00     ` Ghannam, Yazen
2018-08-21 13:21       ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180815155452.GB28669@nazgul.tnic \
    --to=bp@alien8.de \
    --cc=Yazen.Ghannam@amd.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).