[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <af19e771-062f-6ed7-0b9a-e8cd8d0fdb6a@web.de>
Date: Wed, 29 Apr 2020 18:42:55 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Waiman Long <longman@...hat.com>, Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
Changbin Du <changbin.du@...il.com>,
Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] mm/slub: Fix incorrect interpretation of s->offset
> In a couple of places in the slub memory allocator, the code uses
> "s->offset" as a check to see if the free pointer is put right after the
> object. That check is no longer true with commit 3202fa62fb43 ("slub:
> relocate freelist pointer to middle of object").
Will any further collateral evolution become interesting?
…
> +++ b/mm/slub.c
> @@ -551,15 +551,32 @@ static void print_section(char *level, char *text, u8 *addr,
…
> +static inline unsigned int get_info_end(struct kmem_cache *s)
> +{
> + if (freeptr_outside_object(s))
> + return s->inuse + sizeof(void *);
> + else
> + return s->inuse;
> +}
How do you think about the following source code variants?
+ return freeptr_outside_object(s)
+ ? s->inuse + sizeof(void *)
+ : s->inuse;
> static struct track *get_track(struct kmem_cache *s, void *object,
> enum track_item alloc)
> {
> struct track *p;
>
> - if (s->offset)
> - p = object + s->offset + sizeof(void *);
> - else
> - p = object + s->inuse;
> + p = object + get_info_end(s);
>
> return p + alloc;
> }
+ struct track *p = object + get_info_end(s);
return p + alloc;
Regards,
Markus
Powered by blists - more mailing lists