linux-kernel - RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

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 for Android: free password hash cracker in your pocket

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

Message-ID: <3908561D78D1C84285E8C5FCA982C28F7F66C849@ORSMSX115.amr.corp.intel.com>
Date:   Mon, 15 Jun 2020 20:56:15 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Andy Lutomirski <luto@...capital.net>,
        "Yu, Fenghua" <fenghua.yu@...el.com>
CC:     Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        H Peter Anvin <hpa@...or.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        Frederic Barrat <fbarrat@...ux.ibm.com>,
        Andrew Donnellan <ajd@...ux.ibm.com>,
        Felix Kuehling <Felix.Kuehling@....com>,
        Joerg Roedel <joro@...tes.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
        "Mehta, Sohil" <sohil.mehta@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        x86 <x86@...nel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        amd-gfx <amd-gfx@...ts.freedesktop.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

> Are we planning to keep PASID live once a task has used it once or are we going to swap it lazily?  If the latter, a percpu variable might be better.

Current plan is "touch it once and the task owns it until exit(2)"

Maybe someday in the future when we have data on how applications
actually use accelerators we could look at something more complex
if usage patterns look like it would be beneficial.

-Tony