linux-kernel - Re: [RFC 02/15] slub: Add isolate() and migrate() methods

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190308200842.GF373@cisco>
Date:   Fri, 8 Mar 2019 13:08:42 -0700
From:   Tycho Andersen <tycho@...ho.ws>
To:     "Tobin C. Harding" <me@...in.cc>
Cc:     Christopher Lameter <cl@...ux.com>,
        "Tobin C. Harding" <tobin@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Pekka Enberg <penberg@...helsinki.fi>,
        Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 02/15] slub: Add isolate() and migrate() methods

On Sat, Mar 09, 2019 at 06:53:22AM +1100, Tobin C. Harding wrote:
> On Fri, Mar 08, 2019 at 09:22:37AM -0700, Tycho Andersen wrote:
> > On Fri, Mar 08, 2019 at 04:15:46PM +0000, Christopher Lameter wrote:
> > > On Fri, 8 Mar 2019, Tycho Andersen wrote:
> > > 
> > > > On Fri, Mar 08, 2019 at 03:14:13PM +1100, Tobin C. Harding wrote:
> > > > > diff --git a/mm/slab_common.c b/mm/slab_common.c
> > > > > index f9d89c1b5977..754acdb292e4 100644
> > > > > --- a/mm/slab_common.c
> > > > > +++ b/mm/slab_common.c
> > > > > @@ -298,6 +298,10 @@ int slab_unmergeable(struct kmem_cache *s)
> > > > >  	if (!is_root_cache(s))
> > > > >  		return 1;
> > > > >
> > > > > +	/*
> > > > > +	 * s->isolate and s->migrate imply s->ctor so no need to
> > > > > +	 * check them explicitly.
> > > > > +	 */
> > > >
> > > > Shouldn't this implication go the other way, i.e.
> > > >     s->ctor => s->isolate & s->migrate
> > > 
> > > A cache can have a constructor but the object may not be movable (I.e.
> > > currently dentries and inodes).
> > 
> > Yep, thanks. Somehow I got confused by the comment.
> 
> I removed code here from the original RFC-v2, if this comment is
> confusing perhaps we are better off without it.

I'd say leave it, unless others have objections. I got lost in the
"no need" and return true for unmergable too-many-nots goop, but it's
definitely worth noting that one implies the other. An alternative
might be to move it to a comment on the struct member instead.

Tycho