mm: slub: reinitialize random sequence cache on slab object update
Random sequence cache is precomputed during slab object creation
based up on the object size and no of objects per slab. These could
be changed when flags like SLAB_STORE_USER, SLAB_POISON are updated
from sysfs. So when shuffle_freelist is called during slab_alloc it
uses updated object count to access the precomputed random sequence
cache. This could result in incorrect access of the random sequence
cache which could further result in slab corruption. Fix this by
reinitializing the random sequence cache up on slab object update.
A sample panic trace when write to slab_store_user was attempted.
Call trace0:
exception
set_freepointer(inline)
shuffle_freelist(inline)
new_slab+0x688/0x690
___slab_alloc+0x548/0x6f8
kmem_cache_alloc+0x3dc/0x418
zs_malloc+0x60/0x578
zram_bvec_rw+0x66c/0xaa0
zram_make_request+0x190/0x2c8
generic_make_request+0x1f8/0x420
submit_bio+0x140/0x1d8
submit_bh_wbc+0x1a0/0x1e0
__block_write_full_page+0x3a0/0x5e8
block_write_full_page+0xec/0x108
blkdev_writepage+0x2c/0x38
__writepage+0x34/0x98
write_cache_pages+0x33c/0x598
generic_writepages+0x54/0x98
blkdev_writepages+0x24/0x30
do_writepages+0x90/0x138
__filemap_fdatawrite_range+0xc0/0x128
file_write_and_wait_range+0x44/0xa0
blkdev_fsync+0x38/0x68
__arm64_sys_fsync+0x6c/0xb8.
Change-Id: Ia87ff808d23ff8dbb721d3cc3e3b29771200ec5a
Signed-off-by:
Vijayanand Jitta <vjitta@codeaurora.org>
Loading
Please register or sign in to comment