Re: [bug report] scsi: sd_zbc: emulate ZONE_APPEND commands

[Michal Hocko <mhocko@suse.com>]

On Wed 17-02-21 09:41:58, Johannes Thumshirn wrote:
> On 17/02/2021 10:36, Michal Hocko wrote:
> > On Wed 17-02-21 09:08:07, Johannes Thumshirn wrote:
> >> On 17/02/2021 09:03, Michal Hocko wrote:
> >>>> No I don't think so. A mutex isn't a spinlock so we can sleep on the allocation.
> >>>> We can't use GFP_KERNEL as we're about to do I/O. blk_revalidate_disk_zones() called
> >>>> a few line below also does the memalloc_noio_{save,restore}() dance.
> >>>
> >>> You should be extending noio scope then if this allocation falls into
> >>> the same category. Ideally the scope should start at the recursion place
> >>> and end where the scope really ened.
> >>
> >> That means all callers of blk_revalidate_disk_zones() should do 
> >> memalloc_noio_{save,restore}?
> > 
> > I am not really familiar with the IO area to answer this. The base idea
> > is to start the NOIO scope at the boundary which defines "unsafe to
> > re-enter or cannot deal with a new IO" from the reclaim path.
> > 
> >> If yes, can we somehow runtime assert that this is done, so we don't
> >> end up with bad surprises?
> > 
> > Could you elaborate?
> 
> I though of lifting the noio scope into the callers of 
> blk_revalidate_disk_zones() and then "check" in blk_revalidate_disk_zones()
> this has been done. But it looks like memalloc_noio_save() can handle nesting,
> so this is actually unneeded.

Yes, it can handle nesting. As to where to start the scope, this should
be at the boundary of "do not reenter IO path from the reclaim". This
can be a lock which is held for the allocation which will be needed for
an IO induced by the reclaim or any other resouce that will block from
the IO path. Is this more clear now?
-- 
Michal Hocko
SUSE Labs