linux-kernel - Re: [RT LATENCY] 249 microsecond latency caused by slub's unfreeze

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: <CAOJsxLH2axjptbMj9caH0Wo_OqPZRVB20q7uT6f9dVtPZZxb_w@mail.gmail.com>
Date:	Wed, 10 Apr 2013 09:31:10 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Christoph Lameter <cl@...ux.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	LKML <linux-kernel@...r.kernel.org>,
	RT <linux-rt-users@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Clark Williams <clark@...hat.com>
Subject: Re: [RT LATENCY] 249 microsecond latency caused by slub's
 unfreeze_partials() code.

On Mon, Apr 8, 2013 at 3:32 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
>> > Index: linux/mm/slub.c
>> > ===================================================================
>> > --- linux.orig/mm/slub.c    2013-03-28 12:14:26.958358688 -0500
>> > +++ linux/mm/slub.c 2013-04-01 10:23:24.677584499 -0500
>> > @@ -1498,6 +1498,7 @@ static inline void *acquire_slab(struct
>> >     void *freelist;
>> >     unsigned long counters;
>> >     struct page new;
>> > +   unsigned long objects;
>> >
>> >     /*
>> >      * Zap the freelist and set the frozen bit.
>> > @@ -1507,6 +1508,7 @@ static inline void *acquire_slab(struct
>> >     freelist = page->freelist;
>> >     counters = page->counters;
>> >     new.counters = counters;
>> > +   objects = page->inuse;
>> >     if (mode) {
>> >             new.inuse = page->objects;
>> >             new.freelist = NULL;
>> > @@ -1524,6 +1526,7 @@ static inline void *acquire_slab(struct
>> >             return NULL;
>> >
>> >     remove_partial(n, page);
>> > +   page->lru.next = (void *)objects;
>> >     WARN_ON(!freelist);
>> >     return freelist;
>> >  }
>>
>> Good. I like your method which use lru.next in order to hand over
>> number of objects.
>
> I hate it ;-)
>
> It just seems to be something that's not very robust and can cause hours
> of debugging in the future. I mean, there's not even a comment
> explaining what is happening. The lru is a union with other slub
> partials structs that is not very obvious. If something is out of order,
> it can easily break, and there's nothing here that points to why.
>
> Just pass the damn objects pointer by reference and use that. It's easy
> to understand, read and is robust.

Christoph, Joonsoo, comments?

                                Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/