lkml.org 
[lkml]   [2020]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] mm: slub: reinitialize random sequence cache on slab object update
From
Date
On 3/5/20 6:48 AM, vjitta@codeaurora.org wrote:
> On 2020-02-27 22:23, Vlastimil Babka wrote:
>>
>> This is even more nasty as it doesn't seem to require that no objects
>> exist.
>> Also there is no synchronization against concurrent allocations/frees?
>> Gasp.
>
> Since, random sequence cache is only used to update the freelist in
> shuffle_freelist
> which is done only when a new slab is created incase if objects
> allocations are
> done without a need of new slab creation they will use the existing
> freelist which
> should be fine as object size doesn't change after order_store() and
> incase if a new
> slab is created we will get the updated freelist. so in both cases i
> think it should
> be fine.

I have some doubts. With reinit_cache_random_seq() for SLUB, s->random_seq will
in turn:
cache_random_seq_destroy()
- point to an object that's been kfree'd
- point to NULL
init_cache_random_seq()
cache_random_seq_create()
- point to freshly allocated zeroed out object
freelist_randomize()
- the object is gradually initialized
- the indices are gradually transformed to page offsets

At any point of this, new slab can be allocated in parallel and observe
s->random_seq in shuffle_freelist(), and it's only ok if it's currently NULL.

Could it be fixed? In the reinit part you would need to
- atomically update a valid s->random_seq to another valid s->random_seq
(perhaps with NULL in between which means some freelist won't be perhaps randomized)
- write barrier
- call calculate_sizes() with updated flags / new order, make sure all the
fields of s-> are updated in a safe order and with write barries (i.e. update
s->oo and s->flags would be probably last, but maybe that's not all) so that
anyone allocating a new slab will always get something valid (maybe that path
would need also new read barriers?)

No, I don't think it's worth the trouble?

\
 
 \ /
  Last update: 2020-03-05 13:40    [W:0.042 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site