linux-kernel - Re: [PATCH] Raise maximum number of memory controllers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 28 Sep 2018 00:03:55 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     Russ Anderson <rja@....com>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Justin Ernst <justin.ernst@....com>, russ.anderson@....com,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org,
        Aristeu Rozanski Filho <arozansk@...hat.com>
Subject: Re: [PATCH] Raise maximum number of memory controllers

On Thu, Sep 27, 2018 at 02:44:01PM -0700, Luck, Tony wrote:
> The problem with your patch that gets rid of EDAC_MAX_MCS is making
> device links under /sys/bus/edac.  Which is hinted at in some of the
> code your patch deleted:
> 
> -       /*
> -        * The memory controller needs its own bus, in order to avoid
> -        * namespace conflicts at /sys/bus/edac.
> -        */
> -       name = kasprintf(GFP_KERNEL, "mc%d", mci->mc_idx);
> -       if (!name)
> -               return -ENOMEM;
> -
> -       mci->bus->name = name;

Yes, and that needed to go because I am using a single bus. Which kinda
makes sense because you want to have a single bus and multiple devices
on it. I mean, if we *have* to have a bus.

I think this whole /sys/bus/edac thing is crap and needs to go. We
have a perfectly fine hierarchy under /sys/devices/system/edac and
duplicating it under /sys/bus/edac is just bollocks. IMHO. Feel free to
correct me with, but but, this is useful for...

> which seemed to work.

Right.

> But then I began wondering what are ABI expectations
> from applications that read the EDAC /sys files?
> 
> Is this this current source repository?  https://github.com/grondo/edac-utils
> 
> This code doesn't seem to know about the "dimm*" directories below the
> "mc*" level. It just looks for the csrow* entries.

I guess this is a question for Mauro. I never really needed any special
edac tool to get info and if you ask me, we probably should try to keep
it simple and grep sysfs. So that you can always get the info without
having to install any special tools. Like ftrace works on every system
with just a shell and basic tools. I think this is very powerful. But
this is old spartan me only thinking out loud.

In any case, I'm more than fine with dropping the bus hierarchy if
nothing uses it.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.