Re: [PATCH] mm: fix sleeping function warning in alloc_swap_info

[Aaron Lu <aaron.lu@linux.alibaba.com>]

On Tue, Jan 29, 2019 at 05:01:50PM -0800, Andrew Morton wrote:
> On Wed, 30 Jan 2019 09:42:06 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
> 
> > > >
> > > > If we want to allow vfree() to sleep, at least we need to test with
> > > > kvmalloc() == vmalloc() (i.e. force kvmalloc()/kvfree() users to use
> > > > vmalloc()/vfree() path). For now, reverting the
> > > > "Context: Either preemptible task context or not-NMI interrupt." change
> > > > will be needed for stable kernels.
> > > 
> > > So, the comment for vfree "May sleep if called *not* from interrupt
> > > context." is wrong?
> > 
> > Commit bf22e37a641327e3 ("mm: add vfree_atomic()") says
> > 
> >     We are going to use sleeping lock for freeing vmap.  However some
> >     vfree() users want to free memory from atomic (but not from interrupt)
> >     context.  For this we add vfree_atomic() - deferred variation of vfree()
> >     which can be used in any atomic context (except NMIs).
> > 
> > and commit 52414d3302577bb6 ("kvfree(): fix misleading comment") made
> > 
> >     - * Context: Any context except NMI.
> >     + * Context: Either preemptible task context or not-NMI interrupt.
> > 
> > change. But I think that we converted kmalloc() to kvmalloc() without checking
> > context of kvfree() callers. Therefore, I think that kvfree() needs to use
> > vfree_atomic() rather than just saying "vfree() might sleep if called not in
> > interrupt context."...
> 
> Whereabouts in the vfree() path can the kernel sleep?

(Sorry for the late reply.)

Adding Andrey Ryabinin, author of commit 52414d3302577bb6
("kvfree(): fix misleading comment"), maybe Andrey remembers
where vfree() can sleep.

In the meantime, does "cond_resched_lock(&vmap_area_lock);" in
__purge_vmap_area_lazy() count as a sleep point?
__purge_vmap_area_lazy() can be called if mutex_trylock on
vmap_purge_lock succeed.