linux-kernel - Re: [RFC 0/5] x86/intel

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]

Message-ID: <20170918211027.2ede5164@gandalf.local.home>
Date:   Mon, 18 Sep 2017 21:10:27 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
        Boris Petkov <bp@...e.de>, Fenghua Yu <fenghua.yu@...el.com>,
        Reinette Chatre <reinette.chatre@...el.com>,
        Vikas Shivappa <vikas.shivappa@...el.com>
Subject: Re: [RFC 0/5] x86/intel_rdt: Better diagnostics

On Mon, 18 Sep 2017 15:18:38 -0700
"Luck, Tony" <tony.luck@...el.com> wrote:

> From: Tony Luck <tony.luck@...el.com>
> 
> Chatting online with Boris to diagnose why his test cases for RDT
> weren't working, we came up with either a good idea (in which case
> I credit Boris) or a dumb one (in which case this is all my fault).
> 
> The basic problem is that there aren't many good error codes for
> a file system interface to pass back to the user.  I'd resisted
> adding printk() calls because it is a pain to parse the console
> log, doubly so if you want to do it from a shell script that is
> actually issuing the commands to RDT.
> 
> The answer is to add new file in the "info" directory that gives
> the status of the last "command" to RDT (either a mkdir, or a
> write to one of the control files).
> 
> I used the seq_buf* framework because I initially thought a single
> command might result in multiple messages. But currently that isn't
> true and we could potentially just use "strcpy()/sprintf()" to a
> fixed buffer.  I didn't switch to that because the seq_buf* seems
> very lightweight and allows for future extra messages while including
> checking for exceeding the length of the buffer.
> 
> Tony Luck (5):
>   x86/intel_rdt: Add framework for better RDT UI diagnostics
>   x86/intel_rdt: Add diagnostics when writing the schemata file
>   x86/intel_rdt: Add diagnostics when writing the tasks file
>   x86/intel_rdt: Add diagnostics when writing the cpus file
>   x86/intel_rdt: Add diagnostics when making directories
> 
>  arch/x86/kernel/cpu/intel_rdt.h             |  6 ++
>  arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 61 +++++++++++++++----
>  arch/x86/kernel/cpu/intel_rdt_rdtgroup.c    | 93 +++++++++++++++++++++++++----
>  3 files changed, 137 insertions(+), 23 deletions(-)
> 

They all look fine to me.

Acked-by: Steven Rostedt (VMware) <rostedt@...dmis.org>

-- Steve