EROFS: Detecting atomic contexts

[Gao Xiang]

Hi Sandeep,

On 2023/6/21 04:38, Sandeep Dhavale wrote:
> Hi,
> I think we are under RCU read lock in the stack at
> blk_mq_flush_plug_list+0x2b0/0x354
> 
> blk_mq_flush_plug_list calls blk_mq_run_dispatch_ops
> which is a macro in block/blk-mq.h
> 
> /* run the code block in @dispatch_ops with rcu/srcu read lock held */
> #define __blk_mq_run_dispatch_ops(q, check_sleep, dispatch_ops) \
> do {                                                            \
>          if ((q)->tag_set->flags & BLK_MQ_F_BLOCKING) {          \
>                  struct blk_mq_tag_set *__tag_set = (q)->tag_set; \
>                  int srcu_idx;                                   \
>                                                                  \
>                  might_sleep_if(check_sleep);                    \
>                  srcu_idx = srcu_read_lock(__tag_set->srcu);     \
>                  (dispatch_ops);                                 \
>                  srcu_read_unlock(__tag_set->srcu, srcu_idx);    \
>          } else {                                                \
>                  rcu_read_lock();                                \
>                  (dispatch_ops);                                 \
>                  rcu_read_unlock();                              \
>          }                                                       \
> } while (0)
> 
> #define blk_mq_run_dispatch_ops(q, dispatch_ops)                \
>          __blk_mq_run_dispatch_ops(q, true, dispatch_ops)        \
> 
> As you can see if BLK_MQ_F_BLOCKING is not set then dispatch_ops is
> called with rcu_read_lock().
> 
> rcu_read_lock()
>          __rcu_read_lock()
>                  rcu_preempt_read_enter()
> 
> In rcu_preempt_read_enter() increments the rcu_read_lock_nesting which
> is detected later during mutex_lock() as a warning.

Thanks for your analysis. That is much helpful to me.
So it seems a new path which calls end_io under rcu read lock.

> 
> Regarding use of !in_task(), that cannot detect rcu_read_lock_nesting
> as far as I can tell so that may not be sufficient.

rcu_preempt_depth is a too low level api, I'm not sure if it's a good
way but we really don't want to trigger another workqueue here,
could we just use:

"!in_task() || irqs_disabled() || rcu_read_lock_any_held()"

Or do you have better ideas?

Thanks,
Gao Xiang

> 
> Thanks,
> Sandeep.