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> Signed-off-by: Marco Zhang <zhangx@codeaurora.org>tirimbino
parent
3db6f4c3b1
commit
dd81863f39
Loading…
Reference in new issue