Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd_range"

[Minchan Kim]

On Thu, Nov 05, 2020 at 05:16:02PM +0000, Matthew Wilcox wrote:
> On Thu, Nov 05, 2020 at 09:02:49AM -0800, Minchan Kim wrote:
> > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e.
> > 
> > While I was doing zram testing, I found sometimes decompression failed
> > since the compression buffer was corrupted. With investigation,
> > I found below commit calls cond_resched unconditionally so it could
> > make a problem in atomic context if the task is reschedule.
> 
> I don't think you're supposed to call unmap_kernel_range() from
> atomic context.  At least vfree() punts to __vfree_deferred() if
> in_interrupt() is true.  I forget the original reason for why that is.

It would be desirable, However, the logic was there for several years
and made regression from the commit in stable kernel for now.

Can't we have graceful shutdown if we want to deprecate the API usecase
in atomic context?