linux-kernel - Re: [RFC 08/10] platform/x86/intel/ifs: Add IFS sysfs interface

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: <CAPcyv4h7E5mJ5FAhO3pkqyJPTSnRs-3+0e8zFXbX3FcW838ctA@mail.gmail.com>
Date:   Mon, 7 Mar 2022 13:28:04 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     "Joseph, Jithu" <jithu.joseph@...el.com>
Cc:     "hdegoede@...hat.com" <hdegoede@...hat.com>,
        "markgross@...nel.org" <markgross@...nel.org>,
        "corbet@....net" <corbet@....net>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "patches@...ts.linux.dev" <patches@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "hpa@...or.com" <hpa@...or.com>, "bp@...en8.de" <bp@...en8.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC 08/10] platform/x86/intel/ifs: Add IFS sysfs interface

On Mon, Mar 7, 2022 at 12:56 PM Joseph, Jithu <jithu.joseph@...el.com> wrote:
>
>
>
> On 3/7/2022 12:25 PM, Dan Williams wrote:
>
> >
> > I am speaking of the state of the case where 2 threads are doing
> > run_test and polling for results. Unless you can guarantee that run2
> > does not start before the results of run1 have been collected then
> > they are lost in that scenario. No amount of kernel locking can
> > resolve that race to collect previous result which would not be a
> > problem in the first place if there was an atomic way to log test
> > results.
>
>
> Yes "status" shows the status of the latest run. You cannot get the status of the previous run.
>
> Also some context on test frequency: Hardware has  strict rate limiting of tests.
> Every core can be tested only once in every 30 minutes. So it is pointless to test at high frequency.

Is that enforced in the ABI? Did I miss that detail in the
documentation? Does that per-core time limitation also mitigate the
race to read the global status? I.e. back-to-back tests on the same
core may need to be spaced by 30 minutes, but between different cores
as well. Again, these are questions that can not even be posed with an
ABI that eliminates the possibility of result races like uevent.
Please think through that suggestion, that's my main motivation for
continuing to poke at this ABI as currently presented.