Hi Ming,
Don't find any IO block after apply your patch.
Tested-by: Guangwu Zhang <guazhang@xxxxxxxxxx>
Ming Lei <ming.lei@xxxxxxxxxx> 于2023年8月10日周四 16:14写道：
>
> On Thu, Aug 10, 2023 at 12:04:11PM +0530, Kanchan Joshi wrote:
> > On Wed, Aug 09, 2023 at 03:53:35PM +0800, Ming Lei wrote:
> > > On Wed, Aug 09, 2023 at 12:29:20PM +0530, Kanchan Joshi wrote:
> > > > On Wed, Aug 09, 2023 at 10:04:40AM +0800, Ming Lei wrote:
> > > > > Now nvme_ns_chr_uring_cmd_iopoll() has switched to request based io
> > > > > polling, and the associated NS is guaranteed to be live in case of
> > > > > io polling, so request is guaranteed to be valid because blk-mq uses
> > > > > pre-allocated request pool.
> > > > >
> > > > > Remove the rcu read lock in nvme_ns_chr_uring_cmd_iopoll(), which
> > > > > isn't needed any more after switching to request based io polling.
> > > >
> > > > > Fix "BUG: sleeping function called from invalid context" because
> > > > > set_page_dirty_lock() from blk_rq_unmap_user() may sleep.
> > > > >
> > > > > Fixes: 585079b6e425 ("nvme: wire up async polling for io passthrough commands")
> > > > > Reported-by: Guangwu Zhang <guazhang@xxxxxxxxxx>
> > > >
> > > > Thanks Ming. Looks fine, but any link to this report?
> > > > I don't see this breaking in my tests. So I wonder how to reproduce and
> > > > improve the coverage.
> > >
> > > It is reported in RH BZ2227639, and follows the stack trace:
> >
> > Tried to access, but no luck.
> > Any chance that steps can be posted here?
>
> It is reported by Guang Wu, and I think it can be triggered by:
>
> 1) enable CONFIG_DEBUG_ATOMIC_SLEEP
>
> 2) run some nvme pt read workload, and fio should be fine, but
> don't pass --fixedbufs
>
> Just run a quick trace on set_page_dirty_lock() in non-debug kernel, which is
> really called from bio_poll()<-nvme_ns_chr_uring_cmd_iopoll().
>
> Thanks,
> Ming
>
--
Guangwu Zhang
Thanks
