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  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]
Date:   Tue, 21 May 2019 00:20:13 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "davem@...emloft.net" <davem@...emloft.net>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "mroos@...ux.ee" <mroos@...ux.ee>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "namit@...are.com" <namit@...are.com>,
        "luto@...nel.org" <luto@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>
Subject: Re: [PATCH v2] vmalloc: Fix issues with flush flag

On Mon, 2019-05-20 at 15:48 -0700, David Miller wrote:
> From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
> Date: Mon, 20 May 2019 22:17:49 +0000
> 
> > Thanks for testing. So I guess that suggests it's the TLB flush
> > causing
> > the problem on sparc and not any lazy purge deadlock. I had sent
> > Meelis
> > another test patch that just flushed the entire 0 to ULONG_MAX
> > range to
> > try to always the get the "flush all" logic and apprently it didn't
> > boot mostly either. It also showed that it's not getting stuck
> > anywhere
> > in the vm_remove_alias() function. Something just hangs later.
> 
> I wonder if an address is making it to the TLB flush routines which
> is
> not page aligned.
I think vmalloc should force PAGE_SIZE alignment, but will double check
nothing got screwed up.

> Or a TLB flush is being done before the callsites
> are patched properly for the given cpu type.
Any idea how I could log when this is done? It looks like it's done
really early in boot assembly. This behavior shouldn't happen until
modules or BPF are being freed.

Powered by blists - more mailing lists