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] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.23.453.2007291631040.3120473@chino.kir.corp.google.com>
Date:   Wed, 29 Jul 2020 16:32:46 -0700 (PDT)
From:   David Rientjes <rientjes@...gle.com>
To:     "Zhang, Qiang" <Qiang.Zhang@...driver.com>
cc:     "cl@...ux.com" <cl@...ux.com>,
        "penberg@...nel.org" <penberg@...nel.org>,
        "iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: 回复: [PATCH] mm/slab.c: add node spinlock protect in __cache_free_alien

On Wed, 29 Jul 2020, Zhang, Qiang wrote:

> > From: Zhang Qiang <qiang.zhang@...driver.com>
> >
> > We should add node spinlock protect "n->alien" which may be
> > assigned to NULL in cpuup_canceled func. cause address access
> > exception.
> >
> 
> >Hi, do you have an example NULL pointer dereference where you have hit
> >this?
> 

If you have a NULL pointer dereference or a GPF that occurred because of 
this, it would be helpful to provide as rationale.

> >This rather looks like something to fix up in cpuup_canceled() since it's
> >currently manipulating the alien cache for the canceled cpu's node.
> 
> yes , it is fix up in cpuup_canceled  it's
> currently manipulating the alien cache for the canceled cpu's node which  may be the same as the node being operated on in the __cache_free_alien func.
> 
> void cpuup_canceled
> {
>         n = get_node(cachep, node);
>         spin_lock_irq(&n->list_lock);
>         ...
>         n->alien = NULL;
>         spin_unlock_irq(&n->list_lock);
>          ....
> }
> 

Right, so the idea is that this should be fixed in cpuup_canceled() 
instead -- why would we invaliate the entire node's alien cache because a 
single cpu failed to come online?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ