On Sun, Jan 31, 2021 at 09:24:37AM -0800, Andy Lutomirski wrote:
> Right now we treat the case of the kernel trying to execute from user
> memory more or less just like the kernel getting a page fault on a user
> access. In the failure path, we check for erratum #93, try to otherwise
> fix up the
On Mon, Feb 01, 2021 at 05:00:37PM -0800, Andy Lutomirski wrote:
> I defer to Boris as to exactly what condition we should check here.
Same as for erratum #91:
https://lkml.kernel.org/r/20210201203146.gc14...@zn.tnic
A single helper containing that check is probably a good idea.
Thx.
--
Regar
On Mon, Feb 1, 2021 at 1:08 AM Christoph Hellwig wrote:
>
> On Sun, Jan 31, 2021 at 09:24:37AM -0800, Andy Lutomirski wrote:
> > #if defined(CONFIG_X86_64) && defined(CONFIG_CPU_SUP_AMD)
> > + if (likely(boot_cpu_data.x86_vendor != X86_VENDOR_AMD
> > +|| boot_cpu_data.x86 != 0
On Sun, Jan 31, 2021 at 09:24:37AM -0800, Andy Lutomirski wrote:
> #if defined(CONFIG_X86_64) && defined(CONFIG_CPU_SUP_AMD)
> + if (likely(boot_cpu_data.x86_vendor != X86_VENDOR_AMD
> +|| boot_cpu_data.x86 != 0xf))
Same nitpick as for the other patch. Maybe we wan a little i
Right now we treat the case of the kernel trying to execute from user
memory more or less just like the kernel getting a page fault on a user
access. In the failure path, we check for erratum #93, try to otherwise
fix up the error, and then oops.
If we manage to jump to the user address space, wi
5 matches
Mail list logo
