linux-kernel - [bug] __blk_mq_run_hw_queue suspicious rcu usage

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1909041434580.160038@chino.kir.corp.google.com>
Date:   Wed, 4 Sep 2019 14:40:44 -0700 (PDT)
From:   David Rientjes <rientjes@...gle.com>
To:     Tom Lendacky <thomas.lendacky@....com>,
        Brijesh Singh <brijesh.singh@....com>,
        Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>,
        Ming Lei <ming.lei@...hat.com>
cc:     Peter Gonda <pgonda@...gle.com>, Jianxiong Gao <jxgao@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: [bug] __blk_mq_run_hw_queue suspicious rcu usage

Hi Christoph, Jens, and Ming,

While booting a 5.2 SEV-enabled guest we have encountered the following 
WARNING that is followed up by a BUG because we are in atomic context 
while trying to call set_memory_decrypted:

 WARNING: suspicious RCU usage
 5.2.0 #1 Not tainted
 -----------------------------
 include/linux/rcupdate.h:266 Illegal context switch in RCU read-side critical section!
 
 other info that might help us debug this:
 
 
 rcu_scheduler_active = 2, debug_locks = 1
 3 locks held by kworker/0:1H/97:
  #0: 0000000016e1b654 ((wq_completion)kblockd){+.+.}, at: process_one_work+0x1b5/0x5e0
  #1: 00000000002674ff ((work_completion)(&(&hctx->run_work)->work)){+.+.}, at: process_one_work+0x1b5/0x5e0
  #2: 00000000addb6aba (rcu_read_lock){....}, at: hctx_lock+0x17/0xe0
 
 stack backtrace:
 CPU: 0 PID: 97 Comm: kworker/0:1H Not tainted 5.2.0 #1
 Workqueue: kblockd blk_mq_run_work_fn
 Call Trace:
  dump_stack+0x67/0x90
  ___might_sleep+0xfb/0x180
  _vm_unmap_aliases+0x3e/0x1f0
  __set_memory_enc_dec+0x7b/0x120
  dma_direct_alloc_pages+0xcc/0x100
  dma_pool_alloc+0xcf/0x1e0
  nvme_queue_rq+0x5fb/0x9f0
  blk_mq_dispatch_rq_list+0x350/0x5a0
  blk_mq_do_dispatch_sched+0x76/0x110
  blk_mq_sched_dispatch_requests+0x119/0x170
  __blk_mq_run_hw_queue+0x6c/0xf0
  process_one_work+0x23b/0x5e0
  worker_thread+0x3d/0x390
  kthread+0x121/0x140
  ret_from_fork+0x27/0x50

hctx_lock() in __blk_mq_run_hw_queue() takes rcu_read_lock or 
srcu_read_lock depending on BLK_MQ_F_BLOCKING.

dma_direct_alloc_pages() can then call set_memory_decrypted() which must 
be allowed to block.

Any ideas on how to address this?