Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
Date:   Mon, 15 Jun 2020 13:51:39 -0700
Message-Id: <C41D099B-BE2E-4D0E-A7B5-7CE587E11930@amacapital.net>
References: <20200615201735.GE13792@romley-ivt3.sc.intel.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        H Peter Anvin <hpa@zytor.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Lu Baolu <baolu.lu@linux.intel.com>,
        Frederic Barrat <fbarrat@linux.ibm.com>,
        Andrew Donnellan <ajd@linux.ibm.com>,
        Felix Kuehling <Felix.Kuehling@amd.com>,
        Joerg Roedel <joro@8bytes.org>,
        Dave Hansen <dave.hansen@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Ashok Raj <ashok.raj@intel.com>,
        Jacob Jun Pan <jacob.jun.pan@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        Yu-cheng Yu <yu-cheng.yu@intel.com>,
        Sohil Mehta <sohil.mehta@intel.com>,
        Ravi V Shankar <ravi.v.shankar@intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        x86 <x86@kernel.org>, iommu@lists.linux-foundation.org,
        amd-gfx <amd-gfx@lists.freedesktop.org>,
        linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
In-Reply-To: <20200615201735.GE13792@romley-ivt3.sc.intel.com>
To:     Fenghua Yu <fenghua.yu@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jun 15, 2020, at 1:17 PM, Fenghua Yu <fenghua.yu@intel.com> wrote:
>=20
> =EF=BB=BFHi, Peter,
>=20
>> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
>>> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>>>=20
>>> Or do you suggest to add a random new flag in struct thread_info instead=

>>> of a TIF flag?
>>=20
>> Why thread_info? What's wrong with something simple like the below. It
>> takes a bit from the 'strictly current' flags word.
>>=20
>>=20
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index b62e6aaf28f0..fca830b97055 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -801,6 +801,9 @@ struct task_struct {
>>    /* Stalled due to lack of memory */
>>    unsigned            in_memstall:1;
>> #endif
>> +#ifdef CONFIG_PCI_PASID
>> +    unsigned            has_valid_pasid:1;
>> +#endif
>>=20
>>    unsigned long            atomic_flags; /* Flags requiring atomic acces=
s. */
>>=20
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 142b23645d82..10b3891be99e 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -955,6 +955,10 @@ static struct task_struct *dup_task_struct(struct ta=
sk_struct *orig, int node)
>>    tsk->use_memdelay =3D 0;
>> #endif
>>=20
>> +#ifdef CONFIG_PCI_PASID
>> +    tsk->has_valid_pasid =3D 0;
>> +#endif
>> +
>> #ifdef CONFIG_MEMCG
>>    tsk->active_memcg =3D NULL;
>> #endif
>=20
> The PASID MSR is x86 specific although PASID is PCIe concept and per-mm.
> Checking if the MSR has valid PASID (bit31=3D1) is an x86 specifc work.
> The flag should be cleared in cloned()/forked() and is only set and
> read in fixup() in x86 #GP for heuristic. It's not used anywhere outside
> of x86.
>=20
> That's why we think the flag should be in x86 struct thread_info instead
> of in generice struct task_struct.
>=20

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

> Please advice.
>=20
> Thanks.
>=20
> -Fenghua