Skip to content
  • Vasily Gorbik's avatar
    s390/kasan: increase instrumented stack size to 64k · 9fed920e
    Vasily Gorbik authored
    Increase kasan instrumented kernel stack size from 32k to 64k. Other
    architectures seems to get away with just doubling kernel stack size under
    kasan, but on s390 this appears to be not enough due to bigger frame size.
    The particular pain point is kasan inlined checks (CONFIG_KASAN_INLINE
    vs CONFIG_KASAN_OUTLINE). With inlined checks one particular case hitting
    stack overflow is fs sync on xfs filesystem:
    
     #0 [9a0681e8]  704 bytes  check_usage at 34b1fc
     #1
    
     [9a0684a8]  432 bytes  check_usage at 34c710
     #2 [9a068658]  1048 bytes  validate_chain at 35044a
     #3 [9a068a70]  312 bytes  __lock_acquire at 3559fe
     #4 [9a068ba8]  440 bytes  lock_acquire at 3576ee
     #5 [9a068d60]  104 bytes  _raw_spin_lock at 21b44e0
     #6 [9a068dc8]  1992 bytes  enqueue_entity at 2dbf72
     #7 [9a069590]  1496 bytes  enqueue_task_fair at 2df5f0
     #8 [9a069b68]  64 bytes  ttwu_do_activate at 28f438
     #9 [9a069ba8]  552 bytes  try_to_wake_up at 298c4c
     #10 [9a069dd0]  168 bytes  wake_up_worker at 23f97c
     #11 [9a069e78]  200 bytes  insert_work at 23fc2e
     #12 [9a069f40]  648 bytes  __queue_work at 2487c0
     #13 [9a06a1c8]  200 bytes  __queue_delayed_work at 24db28
     #14 [9a06a290]  248 bytes  mod_delayed_work_on at 24de84
     #15 [9a06a388]  24 bytes  kblockd_mod_delayed_work_on at 153e2a0
     #16 [9a06a3a0]  288 bytes  __blk_mq_delay_run_hw_queue at 158168c
     #17 [9a06a4c0]  192 bytes  blk_mq_run_hw_queue at 1581a3c
     #18 [9a06a580]  184 bytes  blk_mq_sched_insert_requests at 15a2192
     #19 [9a06a638]  1024 bytes  blk_mq_flush_plug_list at 1590f3a
     #20 [9a06aa38]  704 bytes  blk_flush_plug_list at 1555028
     #21 [9a06acf8]  320 bytes  schedule at 219e476
     #22 [9a06ae38]  760 bytes  schedule_timeout at 21b0aac
     #23 [9a06b130]  408 bytes  wait_for_common at 21a1706
     #24 [9a06b2c8]  360 bytes  xfs_buf_iowait at fa1540
     #25 [9a06b430]  256 bytes  __xfs_buf_submit at fadae6
     #26 [9a06b530]  264 bytes  xfs_buf_read_map at fae3f6
     #27 [9a06b638]  656 bytes  xfs_trans_read_buf_map at 10ac9a8
     #28 [9a06b8c8]  304 bytes  xfs_btree_kill_root at e72426
     #29 [9a06b9f8]  288 bytes  xfs_btree_lookup_get_block at e7bc5e
     #30 [9a06bb18]  624 bytes  xfs_btree_lookup at e7e1a6
     #31 [9a06bd88]  2664 bytes  xfs_alloc_ag_vextent_near at dfa070
     #32 [9a06c7f0]  144 bytes  xfs_alloc_ag_vextent at dff3ca
     #33 [9a06c880]  1128 bytes  xfs_alloc_vextent at e05fce
     #34 [9a06cce8]  584 bytes  xfs_bmap_btalloc at e58342
     #35 [9a06cf30]  1336 bytes  xfs_bmapi_write at e618de
     #36 [9a06d468]  776 bytes  xfs_iomap_write_allocate at ff678e
     #37 [9a06d770]  720 bytes  xfs_map_blocks at f82af8
     #38 [9a06da40]  928 bytes  xfs_writepage_map at f83cd6
     #39 [9a06dde0]  320 bytes  xfs_do_writepage at f85872
     #40 [9a06df20]  1320 bytes  write_cache_pages at 73dfe8
     #41 [9a06e448]  208 bytes  xfs_vm_writepages at f7f892
     #42 [9a06e518]  88 bytes  do_writepages at 73fe6a
     #43 [9a06e570]  872 bytes  __writeback_single_inode at a20cb6
     #44 [9a06e8d8]  664 bytes  writeback_sb_inodes at a23be2
     #45 [9a06eb70]  296 bytes  __writeback_inodes_wb at a242e0
     #46 [9a06ec98]  928 bytes  wb_writeback at a2500e
     #47 [9a06f038]  848 bytes  wb_do_writeback at a260ae
     #48 [9a06f388]  536 bytes  wb_workfn at a28228
     #49 [9a06f5a0]  1088 bytes  process_one_work at 24a234
     #50 [9a06f9e0]  1120 bytes  worker_thread at 24ba26
     #51 [9a06fe40]  104 bytes  kthread at 26545a
     #52 [9a06fea8]             kernel_thread_starter at 21b6b62
    
    To be able to increase the stack size to 64k reuse LLILL instruction
    in __switch_to function to load 64k - STACK_FRAME_OVERHEAD - __PT_SIZE
    (65192) value as unsigned.
    
    Reported-by: default avatarBenjamin Block <bblock@linux.ibm.com>
    Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    9fed920e